「今のピクシブは、AWS、GCP、オンプレのすべてがアツい」　パブリッククラウド活用における、未来のための取り組み

過去と現在のオンプレとクラウドの比率

sue445氏：次に、現在のピクシブの状態について話します。（スライドを示して）だいたいこんな感じのことを話そうと思います。

まず、オンプレとクラウドの比率について話します。

僕が入社した当時は、クラウドの利用率はだいたい2割弱でしたが、今現在は3割弱と、ちょっと増えています。

AWSのアカウント数とGCPのプロジェクト数の推移

次に、AWSのアカウント数とGCPのプロジェクト数の合計の推移について話します。

僕が入社した当時は、合わせてだいたい27とか28とかだったのですが、今現在は、合わせて100を超えました。

AWSのアカウントやGCPのプロジェクトはTerraformとGitLabで管理

次に、Terraformについて話します。僕が入社した以降に開設されたAWSのアカウントやGCPのプロジェクトは、基本的に全部TerraformとGitLabで管理しています。

最初にTerraformのリポジトリを作ったのは、冒頭で話したAWSのオートスケールRunnerのやつで、その時は2018年11月でした。それからTerraformのリポジトリをいろいろ作って、今現在だいたい60個ぐらいあります。

基本的には、AWSのアカウントやGCPのプロジェクト1個につき、Terraformのリポジトリが1個と、1対1対応しています。

ただ、本番環境と開発環境でAWSのアカウントを分けたいよという場合もわりとあるので、そのような時は、1個のTerraformのリポジトリで複数の環境を一緒に使えるようにしています。詳しくは、「pixiv inside」の記事に全部書きました。

Terraformを導入したことにより、インフラ部以外もインフラの設定に触る文化ができました。簡単な権限追加ぐらいなら他部署でも作業ができるので、権限の移譲がしやすくなりました。

Terraformを導入する前は、だいたい全部をインフラ部がやっていて、けっこうそのあたりで時間が取られていましたが、Terraformを導入したことにより、そのあたりが多少は改善されました。

僕の入社前からあったものに関しても、重要度が高いものから後追いでTerraformを導入していきました。

DNSのゾーンやレコードを1つずつTerraform管理下に移行

ここでちょっと思い出深いエピソードを話します。数百個あった「Route 53」のDNSレコードを全部Terraformに移行しました。移行した当時で、だいたい23ゾーン、約200レコードのDNS情報がRoute 53で管理されていましたが、これらはTerraformで管理されていませんでした。

Terraformで管理されていないと、コンソールでポチポチ作業しなくてはならず、また、Gitなどで履歴が管理されていないのはわりとつらいので、一念発起してTerraformに全部移行しました。Terraformの管理にするのも、わりとつらかったです。

やったことですが、まず不要なレコードを全部消しました。探したらだいたい5、60個ぐらい、要らないレコードがあったので全部消しました。

その後、移行が必要なものに関して、DNSのゾーンやレコードを1個ずつTerraformのimportコマンドでTerraformの管理下に移しました。今であれば、Terraformのimport blockを使うことでそれなりに楽はできますが、移行した当時は、このimport blockがなかったので、1個ずつimportコマンドを使いました。

集中力が切れると事故る可能性があったので、移行は多くても1日10個ぐらいにとどめました。これぐらいのペースで、全部を移行するのにだいたい2週間ぐらいかかりました。気づいている人がいるかもしれませんが、僕はあえて一括移行をしませんでした。

これの理由ですが、一応ツール（スライド中にあるTerraformer）は探して、あることは知っていたのですが、使い慣れていないツールを使って事故ると一瞬で会社の仕事が全部止まるので、ミスった時の被害を最小限にとどめるために1個ずつ丁寧に作業しました。

運用系便利ツール　AWSの予算アラート

次に、運用系の便利ツールについて紹介します。（スライドを示して）この2つを紹介したいと思います。

まず、予算アラートです。あらかじめ決めた予算を超過していないかとか、予算の消化スピードを監視するために、すべてのAWSのアカウントやGCPのプロジェクトで予算アラートを設定しています。メールだと気づけないので、すべての予算アラートをSlackに通知するようにしています。

AWSの予算アラートは、（スライドを示して）だいたいこんな感じです。これは、AWSの標準機能だけで実現できます。ここに書いている「Chatbot」というのが、AWSが標準で用意しているSlack通知の機能です。

ただ、Terraformの「AWS Provider」だと、Chatbotに対応していなかったので、下記のサードパーティー製のモジュールを利用しています。

次に、GCPの予算アラートについて紹介します。GCPの標準機能だけだと、予算アラートのSlack通知が実現できなかったので、予算アラートのPub/Subトピックを受け取って、Slackに通知する部分を「Cloud Functions」で作りました。

予算アラートを設定する時に名前を自由に決めることができるのですが、そこの予算の名前のところに、Slackのチャンネル名を書いておけば、（スライドを示して）ここに書いているチャンネルにいい感じに予算アラートが飛ぶ仕組みにしています。

ここでいくつかTipsを紹介します。監視対象のGCPのプロジェクトと予算アラートの通知先のPub/Subのトピックは、実は別プロジェクトでもよいので、予算アラート専用のGCPプロジェクトを1個作った上で、新しく作るプロジェクトに関しては、ここの予算アラート専用のプロジェクトに対して、Pub/Subのトピックをひもづけるのが運用的にはとても楽でした。

次のTipsです。予算アラートを設定する時は、だいたい50パーセント、90パーセント、100パーセントみたいなしきい値を設定するのですが、このしきい値を一度超えると、無限にPub/Subのトピックに通知が行くことになります。

例えば、50パーセントから51パーセント超えたとか、51パーセントから52パーセントになるとか、そういったタイミングで、Pub/Subのトピックの通知が行くのですが、素朴に実装すると、Slackに無限に通知が行くことになり、かなりウザいことになります。

そのため、Slackに通知したかどうかのフラグを「Firestore」に持たせています。

運用系便利ツール　「terraform-updater」

次に、「terraform-updater」というツールについて紹介します。先ほども話したとおり、うちにはTerraformのリポジトリが60個ぐらいあるので、それらを1個ずつ手でバージョンアップするのは現実的ではありません。自動化したいと思うのは、普通に考えて人情でしょう。

うちのGitLabには、「dependabot-script」というのがあって、こいつを使えばTerraformのProviderの自動バージョンアップ自体はできます。

ただ、それだとTerraform本体のバージョンアップができなかったので、Terraformの本体のバージョンアップも自動化するために、こういったツールを作りました。

みなさんは、GitLabじゃなくて「GitHub」のほうを使っていると思います。GitHubでやりたい場合には、僕の個人ブログに全部やり方が書いてあるので見てください。

プロダクト横断で特定の技術の知見を共有し合っている

次に、研修について紹介します。研修に関しては、AWSさんやGoogleさんのご厚意により、さまざまな研修を受けさせてもらっています。詳しくは「pixiv inside」の記事に全部書いています。

次に、互助会について話します。ピクシブの社内では、プロダクト横断で特定の技術の知見を共有し合う互助会の文化が根付いています。

例えば、Rails系サービスの互助会だったり、フロントエンドの互助会だったり、iOSやAndroidのアプリ会だったり、データエンジニアリングの互助会などがあります。

最近までは、AWSやGCP関係の互助会がなかったのですが、近年、これらを使うプロダクトが増えてきたので、2023年、クラウド互助会を設立しました。今は、隔週30分ずつぐらいのペースで開催していて、だいたい毎回15人前後ぐらい参加しています。

オンプレミス環境と各クラウドの閉域網接続に取り組んでいる

次に、今後の未来のために何をやっているかについて話します。

（スライドを示して）今はだいたいこんな感じのことをやっています。まずは、オンプレミス環境と各クラウドの閉域網接続をやっています。

現在、オンプレミス環境のデータセンターとAWS、オンプレミス環境とGCPをそれぞれ閉域網接続しようとしています。通常は、だいたいデータセンターとAWSを先にやって、その後にGCPという感じだと思いますが、なぜか同時進行でやっています。明らかにこれは正気じゃないです（笑）。

AWSのほうは、「Direct Connect Gateway」を使っています。本当は「Transit Gateway」のほうを使いたかったのですが、契約当時、データセンターのキャリアが対応しておらず、やむなくDirect Connect Gatewayを使っています。GCPのほうは、「Partner Interconnect」を使っています。

Direct Connectとデータセンターのつながりは、（スライドを示して）だいたいこんな感じになっています。GCPのほうは、こんな感じです。これを見ただけでは絶対わからないと思うので、気になる人は、後で話を聞きに来てください。

既存サービスを「Kubernetes」に移行中

次に、既存サービスの「Kubernetes」の移行を行っています。ピクシブの大半のサービスは、オンプレミスのデータセンターの中で動いています。オンプレのデータセンターの中にKubernetesのクラスタを構築して、既存のサービスを移行している真っ最中です。いくつかのサービスは、本番環境のKubernetesで動いています。