登壇者の自己紹介
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のプロジェクトがけっこう野良で運用されていた
まず、僕の入社前のことについて話します。
僕の入社前からも、AWSのアカウントやGCPのプロジェクトはそれなりにあったのですが、「Terraform」などでは特に管理されておらず、けっこう野良で運用されていました。
サービス数で言うと、8割以上がオンプレミスを使っています。実プロダクトでのクラウド利用は、2割ぐらいと若干少なめです。サーバーの台数はオンプレで9割以上占めています。
僕が入社した時点でクラウドをがっつり使っていたのが、「Palcy」「Pawoo」、広告、あとは分析ぐらいでした。
僕が入社した当時のクラウドといえば、イベントの特設サイトというように、一時的な用途に使うことが多かったと思います。
GitLab CIをAWSでオートスケール化した
次に、僕が入社して何をやったかを話そうと思います。
僕がやったことはいっぱいありますが、（スライドを示して）だいたいこのあたりにちょっと絞って話します。
まず、「GitLab CI」をAWSでオートスケール化しました。最初に作られたGitLabのCIは「Runner」のサーバーが1台しかなかったので、当然、全社の利用に耐えられず、けっこうあっぷあっぷな感じでした。
そこで、ジョブが増えるといい感じにAWSのサーバーが増えて、ジョブが減るとサーバーのほうが減るというオートスケールRunnerを作りました。（スライドを示して）こちらの発表資料に全部書いています。
Terraformを導入
次に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の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の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
（次回へつづく）
