pixiv Cloud Journey #pixivmeetup

PIXIV MEETUP 2023( https://conference.pixiv.co.jp/2023/meetup )の発表資料です。

Transcript

1. pixiv Inc. pixiv Cloud Journey @sue445
2. Profile sue445 Engineer • Go Sueyoshi (a.k.a. sue445, sue さん) • 2018年7月　ピクシブ中途入社 • 技術開発本部　インフラ部 ソリューションアーキテクトチー ム所属
3. 業務内容 • AWSとGCPをだいたい全部 ◦ Organization owner, Solution Architect • 社内ツール(GitLabやSentry)の管理や運用 • github.com/pixiv owner • それ以外の雑用もだいたい全部
4. 今日話すこと ピクシブのこれまでのパブリッククラウド(AWS, GCP)活用 の取り組みの歩み
5. 今日話すこと • 今日は会社全体の取り組みを話しますが、発表内容の8割 くらいはsue445がやってきたことです • そのため、sue445が今のピクシブのAWSやGCPの形を 作ったと言っても過言ではないです
6. 諸注意 • 20分という持ち時間では圧倒的に時間が足りないので、詳 細はスライド中に引用している過去に書いた技術記事や発 表資料を読んでください • 詳しく聞きたい方はこの後話を聞きに来てください！
7. Agenda • Long ago (〜2018): sue445入社前 • Beginning (2018〜2022): sue445がやってきたこと • Now (2023): 現在のピクシブの状態 • Future (2023〜): 未来のために現在取り組んでいること
8. 最初にまとめ • sue445が入社してからAWSやGCPの足回りが格段に進歩し、近代化した • Infrastructure as a Codeの文化も根付いた • 研修や互助会などの仕組みも整備されてきた • 今後はオンプレミス環境も巻き込んでAWSやGCPを積極的に活用していく
9. Long ago (〜2018)
10. Long ago (sue445入社前) AWSアカウントやGCPプロジェクトはそれなりにあったが、 Terraformなどで管理されておらず野良運用されていた
11. Long ago (sue445入社前) • サービス数でいうと8割以上がオンプレミスで、実プロダ クトでのクラウド利用は少なめ • サーバ台数だとオンプレミスは9割以上 • Palcy(AWS), Pawoo(AWS), 広告(GCP), 分析(GCP BigQuery)くらい
12. Long ago (sue445入社前) イベントの特設サイトのように一時的な用途でクラウドを使 うことが多かった
13. Beginning (2018〜2022)
14. Beginning (sue445入社後) 1. GitLab CIをAWSでオートスケール化 2. Terraform導入 3. 運用フローの整備 4. SentryのGCP移行 5. GitLabのGCP移行
15. 1. GitLab CIをAWSでオートスケール化 Before (2018/10〜11) • GitLab Runnerのサーバが1台しかなかったので全社利用に耐えられな かった
16. 1. GitLab CIをAWSでオートスケール化 After (2018/12〜2022/9) • GitLab CIのジョブの数に応じてオートスケールするGitLab Runnerを AWSに構築
17. 詳細 https://speakerdeck.com/sue445/pixiv-tech-salon-number-pixivtechsalon
18. 2. Terraform導入
19. Terraformについて • Terraformとはクラウドの構成を設定ファイルで管理する ための、いわゆるInfrastructure as a Code (IaC)のツール ◦ https://www.terraform.io/ • 今でこそピクシブ社内でのデファクトになっているが、 sue445が初めて導入した
20. 他に比較検討したもの vs. Cloud Formation (AWS), Deployment Manager (GCP) • 入社時点でAWSとGCPの利用率はだいたい同じくらい • 同一のツールとエコシステムを利用した方が運用が楽なの で、両方に対応しているTerraformを採用した
21. 3. 運用フローの整備
22. クラウドを利用する時のフローについて • Before ◦ 特になし • After ◦ 2〜3年かけて少しずつ定まってきた（後述）
23. よくある流れ • 1. プロダクトチーム：クラウドを利用したい場合、まずはインフラ部に 相談 • 2. インフラ部：やりたいことをヒアリングして相談してアーキテクチャ を決定 ◦ ヒアリングのMTGの時点でアーキテクチャを2〜3案くらい出す ◦ 要件次第ではオンプレミスが合っていることもありうるのでクラウド にこだわりすぎない
24. よくある流れ • 3. プロダクトチーム：社内の申請フローに従ってクラウド利用に関する 承認をもらう ◦ 必要に応じてインフラ部がサポートを行なう
25. よくある流れ • 4. インフラ部：AWSアカウントやGCPプロジェクトを作成 ◦ GitLabにTerraformのリポジトリを作って、pushしたらCIで Terraformが自動実行されるようにするところまでは最低限作る ◦ 必要に応じてそれ以降のプロトタイプ部分も作る • 5. インフラ部：承認された金額をもとに予算アラートを設定する
26. 4. SentryのGCP移行
27. Sentryについて • Sentryとはエラー収集用のOSS • SaaS版(http://sentry.io)とSelf-Hosted版 (https://develop.sentry.dev/self-hosted/)があって、 ピクシブではSelf-Hosted版を利用している
28. 移行前後の比較 Before (2018〜2020/2) • オンプレミスのサーバ1台で動いていた • アプリケーション本体の他にPostgreSQLやRedisなど含めて全部入り
29. 移行前後の比較 After (2020/3〜) • Sentry本体はGKEで動かすようにし、負荷によっていい感じにオートス ケール • PostgreSQLやRedisなどはGCPのマネージドサービスを利用
30. 詳細 https://speakerdeck.com/sue445/migrated-to-gke-sentry-number-pixivdevmeetup
31. 5. GitLabのGCP移行
32. GitLabとは • GitのリポジトリをホスティングするためのOSS ◦ https://about.gitlab.com/ • SaaS版(https://gitlab.com/)とSelf-managed版があって、ピクシブで はSelf-managed版を利用している • 一部を除いて業務利用しているソースコードは社内のGitLabにある ◦ OSSの公開にはGitHub.comを利用
33. 移行前後の比較 Before (2013〜2022/9) • GitLab本体: オンプレミス • GitLab CI: AWS • 10年弱運用していたのでチリツモでツギハギな構成になっていた
34. 移行前後の比較 After (2022/10〜) • 全てGCPに移行 • 単なる移行にとどまらず、アーキテクチャを全て刷新した
35. 詳細 • 下記にまとめた ◦ 前編: https://inside.pixiv.blog/2022/11/29/110000 ◦ 中編: https://inside.pixiv.blog/2022/12/20/113000 ◦ 後編: https://inside.pixiv.blog/2022/12/22/110000 • 合計約4万文字（読了目安：1時間）
36. 【宣伝】Google Cloud Next Tokyo ’23 • 11/15(水)〜16(木)に東京ビッグサイトで開催予定の「Google Cloud Next Tokyo ’23」に登壇予定です！ ◦ https://cloudonair.withgoogle.com/events/next-tokyo • DAY 1: GitLabをGoogle Cloud へ。移行の Tips と振り返り ◦ https://cloudonair.withgoogle.com/events/next-tokyo?talk=d1 -inf-03
37. Now (2023)
38. Now (現在のピクシブの状態) • オンプレミスとクラウドの比率 • AWSアカウントとGCPプロジェクトの合計数の推移 • Terraform • 運用系便利ツール集 • 研修 • 互助会
39. オンプレミスと クラウドの比率
40. オンプレミスとクラウドを利用しているサービス数の比率
41. AWSアカウントとGCP プロジェクトの合計数の 推移
42. AWSアカウントとGCPプロジェクトの合計数の推移
43. Terraform
44. Terraform sue445入社以降に開設されたAWSアカウントやGCPプロ ジェクトに関しては、基本的に全てTerraformとGitLab の リポジトリで管理されている
45. Terraform • 一番最初にTerraformリポジトリを作ったのは2018年11月 ◦ 前述のGitLab CIのオートスケールRunnerで利用 • 2023年9月現在、Terraformリポジトリは約60個
46. Terraform 基本的にはAWSアカウント(GCPプロジェクト)1つにつき Terraformリポジトリは1つ
47. Terraform サービスによっては本番環境と開発環境でAWSアカウント (GCPプロジェクト)を分けたいこともあるので、1つの Terraformリポジトリで管理できるようにもしてる
48. Terraform 詳細：Terraform運用事例書きました - pixiv inside https://inside.pixiv.blog/2020/07/30/172828
49. Terraform • インフラ部以外もTerraformを触る文化ができた • 簡単な権限追加くらいなら他部署でも作業ができるので、 権限の移譲がしやすくなった
50. Terraform sue445入社前からあったものに関しても、重要度が高いも のから後追いでTerraformを導入
51. e.g. 数百個あったRoute53のDNSレコードをTerraform移行 背景 • 約23ゾーン、約200レコードのDNS情報がRoute53で管理されていたが Terraformで管理されていなかった • Terraformで管理されていないとつらいので全てTerraform管理にした
52. e.g. 数百個あったRoute53のDNSレコードをTerraform移行 やったこと • 移行不要なレコードを削除 (50〜60レコードくらい) • DNSのゾーンやレコードを1つずつterraform importコマ ンドでTerraform管理下に移した（移行当時はまだimport blockはなかった）
53. e.g. 数百個あったRoute53のDNSレコードをTerraform移行 やったこと • 集中力が切れると事故る可能性があったので、移行は多く ても1日10レコードずつにとどめた • だいたい2週間位かかった
54. e.g. 数百個あったRoute53のDNSレコードをTerraform移行 やらなかったこと • https://github.com/GoogleCloudPlatform/terraformer などを使っての 一括移行 • 使い慣れていないツールを利用して事故ると一瞬で会社の業務が止まるの で、ミスった時の被害を最小限に留めるために1レコードずつ移行した
55. 運用系便利ツール集
56. 運用系便利ツール集 • 予算アラート • terraform-updater
57. 予算アラート • 予め決めた予算を超過していないかや予算の消化スピード を監視するために、全てのAWSアカウントやGCPプロジェ クトで予算アラートを設定している • メールだと気づけないので全ての予算アラートをSlackに 通知するようにしている
58. AWSでの予算アラート AWSの標準機能(ChatBot + SNS)だけで実現できる • ref. https://docs.aws.amazon.com/ja_jp/cost-management/latest/userguide/sns-alert-chime.html
59. AWSでの予算アラート ただしTerraformのAWS providerだとChatBot対応してい ないため下記のmoduleを利用している • https://registry.terraform.io/modules/waveaccountin g/chatbot-slack-configuration/aws/latest
60. GCPでの予算アラート GCPの標準機能だけだと予算アラートのSlack通知が実現で きないため、予算アラートのPub/Subトピックを受け取って Slackに通知する部分をCloud Functionsで実装した (in-house tool)
61. GCPでの予算アラート 予算アラート設定時に予算名に通知先のSlackチャンネル名 を書いて、予算アラート用のPub/Subトピックに連携するだ けのお手軽設定
62. Tips 1 監視対象のGCPプロジェクトと予算アラートの通知先 Pub/Subのトピックは別プロジェクトであってもいいので、 予算アラート専用のGCPプロジェクトを作るのが便利
63. Tips 2 一度予算のしきい値を超えると定期的にPub/Subトピックに 通知がいくため、Slackへの多重投稿を防ぐ対策が必要。 （うちでは通知済フラグをFirestoreに保存）
64. terraform-updater (in-house tool) 前提：Terraformリポジトリが社内に60個近くあるので手で バージョンアップするのは現実的じゃないので自動化したい
65. terraform-updater (in-house tool) 社内GitLabに https://github.com/dependabot/dependabot-script を動 かしているのでTerraformのproviderの自動バージョンアッ プはできる
66. terraform-updater (in-house tool) しかしそれだとTerraform本体のバージョンアップができな いのでTerraformのバージョンアップも自動化するために terraform-updaterを作っている
67. BTW. GitHubでやりたい場合 https://sue445.hatenablog.com/entry/2022/08/06/13 1857 を参照
68. 研修
69. 研修 AWSさんやGoogleさんのご厚意で、AWS JumpStartや Google Cloud Innovators Gym Japan(G.I.G)の研修を受け させてもらっている
70. 研修 • Google Cloud Innovators Gym Japan にピクシブから3名の社員が参加 しました - pixiv inside ◦ https://inside.pixiv.blog/2021/03/24/120000 • 新卒11名が AWS のスペシャル研修 に参加した話 - pixiv inside ◦ https://inside.pixiv.blog/2021/06/24/101000
71. 互助会
72. 互助会 ピクシブ社内ではプロダクト横断で特定の技術の知見を共有しあう互助会 の文化が根付いている • e.g. Railsサービス互助会、フロントエンド互助会、iOSアプリ会、 Androidアプリ会、データエンジニアリング互助会など • https://inside.pixiv.blog/search?q=互助会
73. 互助会 AWSやGCPを利用しているプロダクトが増えてきたので今年 クラウド互助会を設立した • 隔週30分ずつ開催 • 参加人数は15人前後
74. Future (2023〜)
75. Doing • オンプレミス環境と各クラウドとの閉域網接続 • 既存サービスのKubernetes移行
76. オンプレミス環境と 各クラウドとの閉域網接続
77. オンプレミス環境と各クラウドとの閉域網接続 • 現在、オンプレミス環境のデータセンターとクラウド (AWS & GCP)を閉域網接続しようとしている ◦ AWSとGCPを同時進行とか正気か？？？？
78. オンプレミスと各クラウドとの閉域網接続 • AWSはDirect Connect Gatewayを利用 ◦ 本当はTransit Gatewayを使いたかったが、契約当時 キャリアが対応していなかった（今は対応してる） • GCPはPartner Interconnectを利用
79. AWS Direct Connect Gatewayのざっくり構成
80. GCP Partner Interconnectのざっくり構成
81. 既存サービスの Kubernetes移行
82. 既存サービスのKubernetes移行 • ピクシブの大半のサービスはオンプレミスのデータセン ター内で動いている • データセンター内にKubernetesのクラスタを構築し、既 存のサービスを移行している真っ最中
83. まとめ
84. まとめ • sue445が入社してからAWSやGCPの足回りが格段に進歩し、近代化した • Infrastructure as a Codeの文化も根付いた • 研修や互助会などの仕組みも整備されてきた • 今後はオンプレミス環境も巻き込んでAWSやGCPを積極的に活用していく
85. We are Hiring! 今のピクシブはAWS, GCP, オンプレミスの全てがアツいの で、興味ある人は是非話を聞きに来てください！！！！！