
2025.02.18
AIが「嘘のデータ」を返してしまう アルペンが生成AI導入で味わった失敗と、その教訓
リンクをコピー
記事をブックマーク
sue445氏:「pixiv Cloud Journey」というタイトルで発表させてもらいます。
こちらの発表資料ですが、先ほど「X」にハッシュタグ付きで流しているので、後から見返したいという方は、そちらのURLをご覧ください。
自己紹介させてもらいます。末吉剛といいます。SNSでは「sue445(すえよんよんご)」というIDでやっていて、社内では「sueさん」と呼ばれています。2018年7月入社で、今はインフラ部に所属しています。
仕事は、「AWS」と「GCP」をだいたい全部やっています。主にOrganizationのオーナーとして組織の管理を行っていたり、ソリューションアーキテクトとして各プロダクトからの相談をもとに、アーキテクチャをいろいろ考えたり、システムを作ったり、運用を回したりしています。
あと、「GitLab」や「Sentry」といった社内ツールの運用もやっていたり、「github.com」のOrganizationのオーナーをやっていたり、そのほか、諸々雑用全部やっています。なので、雑にいろいろ投げられたものをいい感じにするのが僕の仕事です。
今日は、ピクシブのパブリッククラウド活用の取り組みについて話そうと思っています。
会社全体の取り組みを話しますが、発表内容の8割ぐらいは、僕が全部やったことです。なので、僕が今のピクシブのAWSやGCPの形を作ったと言っても過言ではないです。
(会場拍手)
20分という持ち時間では圧倒的に時間が足りないので、詳細はスライドの中に引用している記事のURLをご覧ください。詳しく聞きたい方は、この後のAsk the Speakerや懇親会で話を聞きに来てください。
(スライドを示して)まず、こんな感じのことを話そうと思っています。僕の入社前はどんな感じだったか。その後、僕が入社して何をやったかを話します。そして、現在のピクシブの状態を話して、未来のために現在取り組んでいることについて話そうと思います。
最初にまとめを話します。僕が入社してからAWSやGCPの足回りが格段に進歩して、近代化しました。そして、Infrastructure as a Codeの文化も根付きました。研修や互助会などの仕組みも整備されてきました。今後は、オンプレミス環境も巻き込んで、AWSやGCPを積極的に活用していきます。
まず、僕の入社前のことについて話します。
僕の入社前からも、AWSのアカウントやGCPのプロジェクトはそれなりにあったのですが、「Terraform」などでは特に管理されておらず、けっこう野良で運用されていました。
サービス数で言うと、8割以上がオンプレミスを使っています。実プロダクトでのクラウド利用は、2割ぐらいと若干少なめです。サーバーの台数はオンプレで9割以上占めています。
僕が入社した時点でクラウドをがっつり使っていたのが、「Palcy」「Pawoo」、広告、あとは分析ぐらいでした。
僕が入社した当時のクラウドといえば、イベントの特設サイトというように、一時的な用途に使うことが多かったと思います。
次に、僕が入社して何をやったかを話そうと思います。
僕がやったことはいっぱいありますが、(スライドを示して)だいたいこのあたりにちょっと絞って話します。
まず、「GitLab CI」をAWSでオートスケール化しました。最初に作られたGitLabのCIは「Runner」のサーバーが1台しかなかったので、当然、全社の利用に耐えられず、けっこうあっぷあっぷな感じでした。
そこで、ジョブが増えるといい感じにAWSのサーバーが増えて、ジョブが減るとサーバーのほうが減るというオートスケールRunnerを作りました。(スライドを示して)こちらの発表資料に全部書いています。
次にTerraformを導入しました。Terraformというのは、クラウドの構成を設定ファイルで管理するための、いわゆるInfrastructure as a Codeのためのツールです。今でこそ、うちのデファクトになっていますが、僕が初めてこの会社に導入しました。
ほかにも、AWSの「CloudFormation」だったり、GCPの「Deployment Manager」というツールがあります。入社した時点で、AWSとGCPの利用率はだいたい同じぐらいでした。同じツールとエコシステムを使ったほうが運用が圧倒的に楽なので、両方に対応しているTerraformを採用しました。
もし、これがAWSだけしか扱っていないとか、GCPだけしか扱っていないとかであれば、ちょっとまた別の答えになっていたかなと思います。
次に、運用のフローを整備しました。僕が入社した当時は、クラウドを利用する時のフローが特に定まってはいませんでしたが、2、3年かけて少しずつこのあたりのフローが定まってきました。
よくある流れについて話します。まず、クラウドを利用したい場合、プロダクトチームからインフラ部に相談が来ます。インフラ部は、プロダクトチームからやりたいことをヒアリングして、いろいろアーキテクチャを考えます。
ヒアリングのミーティングの時点で、アーキテクチャの案をだいたい2、3個考えて出しています。要件次第では、クラウドではなくオンプレのほうが合っていることも十分あり得るので、なるべくクラウドにこだわりすぎないようにしています。
アーキテクチャが決まった後、プロダクトチームが社内の申請フローに従ってクラウド利用に関する承認をもらいます。必要に応じて、インフラ部もこのあたりをサポートしています。
承認が下りた段階で、インフラ部がAWSのアカウントとGCPのプロジェクトを開設しています。GitLabにTerraformのリポジトリを作って、リポジトリにプッシュしたらCIでいい感じにTerraformが自動実行されるところまで、最低限をインフラ部が作っています。
そして、必要に応じて、プロトタイプの部分や開発環境の部分をインフラ部が作っています。それと並行して、先ほど承認された金額をもとに予算アラートも適宜設定します。
次に、SentryのGCP移行を行いました。Sentryというのは、エラー収集用のOSSです。このSentryには、「sentry.io」と呼ばれるSaaS版と、Dockerイメージなどを自分たちのサーバーで動かすSelf-Hosted版があって、ピクシブでは、後者のSelf-Hosted版を利用しています。
最初に作られたSentryは、オンプレミスのサーバー1台で動いていました。そしてこのサーバー1台にも、アプリケーション本体のほかに、「ポスグレ(PostgreSQL)」や「Redis」などが全部丸ごと入っていました。
あるプロダクトでエラーが大量に発生すると、この1台しかないSentryのサーバーに全部エラーが集中し、それにSentryが巻き込まれて障害になることもちょいちょいありました。
それだとまずいので、Sentryをリプレイスしました。リプレイス後は、GCPに移行しました。Sentryの本体は「GKE」で動かして、Sentryの負荷によっていい感じにオートスケールする感じにしました。その他ポスグレ、Redisなどは、GCPのマネージドサービスを利用しています。詳しくは、(スライドを示して)こちらの資料に全部書いています。
次に、GitLabのGCP移行を行いました。GitLabというのは、「Git」のリポジトリをホスティングするためのOSSです。
「gitlab.com」で提供されているSaaS版と、Dockerイメージなどを自分たちの環境で動かすSelf-managed版があり、ピクシブでは、Self-managed版を利用しています。一部を除いて業務で使っているソースコードは、全部社内のGitLabにあります。
移行前、最初にうちでGitLabが作られたのは2013年。約10年前でした。10年間の間にいろいろ構成が変わっていたのですが、移行直前の構成を言うと、GitLabの本体がオンプレミス環境にあって、GitLab CIが最初のほうに話したAWSにありました。
10年弱運用してきたので、けっこうチリツモ(塵も積もれば山となる)で、ツギハギな構成になっていました。
そこで、2022年にすべてGCPに移行しました。単なる移行にとどまらず、周辺のアーキテクチャを全部変えました。
詳しくは、(スライドを示して)こちらの「pixiv inside」の記事に書いています。前編、中編、後編の全部を読み切るのに1時間かかるので、「MEETUP」が終わってから読んでください。
(会場笑)
ちなみにですが、こちらのGitLabのGCP移行の話は、11月に開催される「Google Cloud Next Tokyo ‘23」で話す予定です。今絶賛発表資料を作り中で、40分の持ち時間でスライド200枚超えそうで、わりとヤバい感じです。ちなみに、5月に登壇した「RubyKaigi 2023」(※1)では(持ち時間が)30分でスライドは100枚弱でした。
(※1)https://rubykaigi.org/2023/presentations/sue445.html#day2
(次回へつづく)
関連タグ:
2025.02.13
“最近の新人は報連相をしない”という、管理職の他責思考 部下に対する「NG指示」から見る、認識のズレを防ぐコツ
2025.02.13
AIを使いこなせない人が直面する本当の課題 元マッキンゼー・赤羽雄二氏が“英語の情報”を追い続ける理由
2025.02.14
報連相ができない部下に対するコミュニケーションの取り方 「部下が悪い」で終わらせない、管理職のスキル向上のポイント
2025.02.12
マネージャーは「プレイング3割」が適切 チームの業績を上げるためのマネジメントと業務の比率
2025.02.13
上司からは丸投げ、部下からはハラスメント扱い、業務は増加…プレイングマネジャーを苦しめる「6つの圧力」とは
2025.02.12
何度言っても変わらない人への指示のポイント 相手が主体的に動き出す“お願い”の仕方
2025.02.13
「みんなで決めたから」を言い訳にして仲良しクラブで終わる組織 インパクトも多様性も両立させるソース原理
2025.02.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
2025.02.10
32歳で「すかいらーく」を創業、75歳で「高倉町珈琲」で再起業 「失敗したからすかいらーくができた」横川竟氏流の経営哲学
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
限られた時間で成果を上げるドイツ式仕事術
2025.01.21 - 2025.01.21
着想から2か月でローンチ!爆速で新規事業を立ち上げる方法
2025.01.21 - 2025.01.21
新人の報連相スキルはマネージメントで引きあげろ!~管理職の「他責思考」を排除~
2025.01.29 - 2025.01.29
【手放すTALK LIVE#45】人と組織のポテンシャルが継承されるソース原理 ~人と組織のポテンシャルが花開く「ソース原理」とは~
2024.12.09 - 2024.12.09
『これで採用はうまくいく』著者が語る、今こそ採用担当に届けたい「口説く」力のすべて
2024.11.29 - 2024.11.29