Upgrade to Pro — share decks privately, control downloads, hide ads and more …

コロプラにおけるLaunch Coordination Engineeringの取り組み / ...

halnique
December 03, 2021

コロプラにおけるLaunch Coordination Engineeringの取り組み / colopl-launch-coordination-engineering

Cloud Native Lounge #3「Kubernetesで実現する大規模サービス基盤運用」
登壇資料

halnique

December 03, 2021
Tweet

Other Decks in Technology

Transcript

  1. LCEってなんですか? Site Reliability Engineering / Chapter 27 - Reliable Product

    Launches at Scale https://sre.google/sre-book/reliable-product-launches/
  2. • プロダクトやサービスがGoogleの信頼性の基準とベストプラクティスに沿っ ているかを監査し、信頼性を高めるための具体的なアクションを提供する • ローンチに関わる複数のチーム間の連絡役として働く • タスクが滞り無く進んでいることを確認し、技術面からローンチを推進する • 門番の役目を果たし、ローンチが「安全」だという判断の承認を行う •

    開発者の学習速度を高めるために内部ドキュメントやトレーニング用のリ ソースを用意し、開発者に対してベストプラクティスやGoogleのサービスと 統合する方法についての教育を行う LCEってなんですか? Site Reliability Engineering / Chapter 27 - Reliable Product Launches at Scale https://sre.google/sre-book/reliable-product-launches/
  3. Q: いくつもゲーム出してるんだから、落ちないためのノウハウあるでしょ? A: それがなかなか難しいんです… • ローンチに携わった経験のある人が多くない • ローンチ時に最大トラフィックが来るようなマーケティング • ビッグバンリリース

    • ゲームによって異なるアーキテクチャ、アクセスパターンや負荷の特性 • ローンチ直前までクオリティアップの開発が行われていることもあり、ローンチそのものの準備に 開発の工数を割きづらい • 大規模ゲームの運用経験がない場合、負荷的な観点で開発をするのが難しいことも コロプラでLCEが必要な理由
  4. Q: いくつもゲーム出してるんだから、落ちないためのノウハウあるでしょ? A: それがなかなか難しいんです… • ローンチに携わった経験のある人が多くない • ローンチ時に最大トラフィックが来るようなマーケティング • ビッグバンリリース

    • ゲームによって異なるアーキテクチャ、アクセスパターンや負荷の特性 • ローンチ直前までクオリティアップの開発が行われていることもあり、ローンチそのものの準備に 開発の工数を割きづらい • 大規模ゲームの運用経験がない場合、負荷的な観点で開発をするのが難しいことも コロプラでLCEが必要な理由
  5. コロプラのLCEの業務とk8s • プロダクトやサービスがGoogleの信頼性の基準とベストプラクティスに沿っ ているかを監査し、信頼性を高めるための具体的なアクションを提供する • ローンチに関わる複数のチーム間の連絡役として働く • タスクが滞り無く進んでいることを確認し、技術面からローンチを推進する • 門番の役目を果たし、ローンチが「安全」だという判断の承認を行う

    • 開発者の学習速度を高めるために内部ドキュメントやトレーニング用のリ ソースを用意し、開発者に対してベストプラクティスやGoogleのサービスと 統合する方法についての教育を行う Site Reliability Engineering / Chapter 27 - Reliable Product Launches at Scale https://sre.google/sre-book/reliable-product-launches/
  6. コロプラのLCEの業務とk8s • プロダクトやサービスがGoogleの信頼性の基準とベストプラクティスに沿っ ているかを監査し、信頼性を高めるための具体的なアクションを提供する • ローンチに関わる複数のチーム間の連絡役として働く • タスクが滞り無く進んでいることを確認し、技術面からローンチを推進する • 門番の役目を果たし、ローンチが「安全」だという判断の承認を行う

    • 開発者の学習速度を高めるために内部ドキュメントやトレーニング用のリ ソースを用意し、開発者に対してベストプラクティスやGoogleのサービスと 統合する方法についての教育を行う Site Reliability Engineering / Chapter 27 - Reliable Product Launches at Scale https://sre.google/sre-book/reliable-product-launches/
  7. コロプラのLCEの業務とk8s 1. 実際にゲームをプレイ a. ユーザーの行動(アクセスパターン)を把握 b. ゲーム上重要な/特殊な仕様を把握 2. 負荷をかけるシナリオを検討・作成 a.

    リトライ戦略などゲームの実装も合わせて確認 3. 負荷試験に使う環境を構築 a. 負荷をかける側の環境も合わせて構築 b. DBのウォームアップ環境も兼ねる 4. ミニマムな規模から負荷試験を実施 a. リソースあたり処理できるユーザー数を見積もる 5. 想定の最大規模までスケールしながら実施 6. リリース 3~6 ヶ 月
  8. コロプラのLCEの業務とk8s 1. 実際にゲームをプレイ a. ユーザーの行動(アクセスパターン)を把握 b. ゲーム上重要な/特殊な仕様を把握 2. 負荷をかけるシナリオを検討・作成 a.

    リトライ戦略などゲームの実装も合わせて確認 3. 負荷試験に使う環境を構築 a. 負荷をかける側の環境も合わせて構築 b. DBのウォームアップ環境も兼ねる 4. ミニマムな規模から負荷試験を実施 a. リソースあたり処理できるユーザー数を見積もる 5. 想定の最大規模までスケールしながら実施 6. リリース 3~6 ヶ 月
  9. コロプラのLCEの業務とk8s 1. 実際にゲームをプレイ a. ユーザーの行動(アクセスパターン)を把握 b. ゲーム上重要な/特殊な仕様を把握 2. 負荷をかけるシナリオを検討・作成 a.

    リトライ戦略などゲームの実装も合わせて確認 3. 負荷試験に使う環境を構築 a. 負荷をかける側の環境も合わせて構築 b. DBのウォームアップ環境も兼ねる 4. ミニマムな規模から負荷試験を実施 a. リソースあたり処理できるユーザー数を見積もる 5. 想定の最大規模までスケールしながら実施 6. リリース 3~6 ヶ 月
  10. コロプラのLCEの業務とk8s Spanner から GKE、Spinnaker、そして SRE まで、コロプラが今挑戦していること [Google Cloud INSIDE Games

    & Apps] / SREの取り組み https://www.slideshare.net/GoogleCloudPlatformJP/spanner-gkespinnaker-sre-google-cloud-insid e-games-apps
  11. コロプラのLCEの業務とk8s 1. 実際にゲームをプレイ a. ユーザーの行動(アクセスパターン)を把握 b. ゲーム上重要な/特殊な仕様を把握 2. 負荷をかけるシナリオを検討・作成 a.

    リトライ戦略などゲームの実装も合わせて確認 3. 負荷試験に使う環境を構築 a. 負荷をかける側の環境も合わせて構築 b. DBのウォームアップ環境も兼ねる 4. ミニマムな規模から負荷試験を実施 a. リソースあたり処理できるユーザー数を見積もる 5. 想定の最大規模までスケールしながら実施 6. リリース 3~6 ヶ 月
  12. コロプラのLCEの業務とk8s • Application Cluster ◦ Application (PHP) Pods ◦ etc

    • Testing Tools Cluster ◦ Scenario Runner (Golang) Job ◦ Spanner Warm-Up Tools (Golang) Job/Deployment ◦ etc
  13. コロプラのLCEの業務とk8s • Application Cluster ◦ Application (PHP) Pods ◦ etc

    • Testing Tools Cluster ◦ Scenario Runner (Golang) Job ◦ Spanner Warm-Up Tools (Golang) Job/Deployment ◦ etc
  14. コロプラのLCEの業務とk8s • Golang • Helm charts • GitLab CI build

    manifest → Google Cloud Storage • Spinnaker deploy manifest
  15. コロプラのLCEの業務とk8s 1. 実際にゲームをプレイ a. ユーザーの行動(アクセスパターン)を把握 b. ゲーム上重要な/特殊な仕様を把握 2. 負荷をかけるシナリオを検討・作成 a.

    リトライ戦略などゲームの実装も合わせて確認 3. 負荷試験に使う環境を構築 a. 負荷をかける側の環境も合わせて構築 b. DBのウォームアップ環境も兼ねる 4. ミニマムな規模から負荷試験を実施 a. リソースあたり処理できるユーザー数を見積もる 5. 想定の最大規模までスケールしながら実施 6. リリース 3~6 ヶ 月
  16. コロプラのLCEの業務とk8s • Spanner Nodes x1 (Processing units x1000) • Application

    HPA min:1 ~ • Scenario users 1,000 ~ Spanner 1 nodeを基準として処理できるユーザー数や周辺の必要リソースを見積 もる 明らかにパフォーマンスが良くない箇所を確認・修正
  17. コロプラのLCEの業務とk8s 1. 実際にゲームをプレイ a. ユーザーの行動(アクセスパターン)を把握 b. ゲーム上重要な/特殊な仕様を把握 2. 負荷をかけるシナリオを検討・作成 a.

    リトライ戦略などゲームの実装も合わせて確認 3. 負荷試験に使う環境を構築 a. 負荷をかける側の環境も合わせて構築 b. DBのウォームアップ環境も兼ねる 4. ミニマムな規模から負荷試験を実施 a. リソースあたり処理できるユーザー数を見積もる 5. 想定の最大規模までスケールしながら実施 6. リリース 3~6 ヶ 月
  18. コロプラのLCEの業務とk8s 1. 実際にゲームをプレイ a. ユーザーの行動(アクセスパターン)を把握 b. ゲーム上重要な/特殊な仕様を把握 2. 負荷をかけるシナリオを検討・作成 a.

    リトライ戦略などゲームの実装も合わせて確認 3. 負荷試験に使う環境を構築 a. 負荷をかける側の環境も合わせて構築 b. DBのウォームアップ環境も兼ねる 4. ミニマムな規模から負荷試験を実施 a. リソースあたり処理できるユーザー数を見積もる 5. 想定の最大規模までスケールしながら実施 6. リリース 3~6 ヶ 月
  19. • リリース2日前 ◦ Spanner Warm-up • リリース1日前 ◦ Scale-out ◦

    Testing ◦ Delete data • リリース当日 ◦ Monitoring • リリース後 ◦ Clean up コロプラのLCEの業務とk8s