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