KubernetesとSpannerで 進化し続けるコロプラのゲーム開発
4 likes4,137 views
KubernetesとSpannerで 進化し続けるコロプラのゲーム開発
- 2. 2 About me
- 3. ● 奥村開里(おくむら かいり) ● 2016年に新卒として株式会社コロプラに入社 ● インフラチームメンバーとして三年目 ● GCPへのノーメンテナンスマイグレーション、新作の負荷対策、 アーキテクチャの刷新等を担当 ● 現在GKE周りやマイクロサービス化等をしています。 3 About me
- 4. 01 Problem 02 Backend 03 Frontend Today’s Agenda KubernetesとSpannerで 進化し続けるコロプラのゲーム開発 4 04 No SPOF 05 Deploy
- 5. 5 01 Problem 02 Backend 03 Frontend Today’s Agenda KubernetesとSpannerで 進化し続けるコロプラのゲーム開発 04 No SPOF 05 Deploy
- 9. 9 ● この構成でも行っていたインフラの取り組み ○ いつでもプレイ可能にする ○ 障害時間の減少 ○ スムースなLiveOpsの達成 コロプラの取り組み
- 10. LiveOps 10 What’s 『 LiveOps 』 ● ARPUを高く保ちつづける為の取り組み ○ イベントを打ち続ける ○ コミュニティからの反響に答える ○ …etc
- 11. LiveOps 11 スムースなLiveOpsの為に… ● ビジネスロジックへの集中 ● 余計な手間の削減 ● 種々コストの保持&低減
- 12. 12 ● Backend (DB) ○ データベースサーバーの切り替えコストの増大 ● Frontend (APP, PVP) ○ アプリケーションサーバーのキャパシティ プランニングが人力で厳しい ● No SPOF ○ システム各所に自動復旧しないコンポーネントが 存在すること 取り組む際の課題
- 13. 13 01 Problem 02 Backend 03 Frontend Today’s Agenda KubernetesとSpannerで 進化し続けるコロプラのゲーム開発 04 No SPOF 05 Deploy
- 15. 15 ● リリース時やイベント時には… ○ 多数のサーバー，スペックの高いサーバーを用意 ○ 安定期に入った後に使用するサーバーの台数， スペック等を調整 サービスをプレイできる環境を保証するために
- 16. 16 ● フロントエンド ○ ステートレスなので，切り替えは手間ではない ● バックエンド ○ データを保存しているので，切り替えが手間 ○ このバックエンドのスペック調整の手間がネック 切り替えの手間
- 17. 17 運用していたが…
- 18. 18 ● 開発とインフラ双方のオペレーションが必要 ○ インフラはテーブルの使い方等は把握していない ○ 開発にデータの使い方を確認しなければならない ● サーバーコストの大きさ ○ データが大きくなると構築にも時間がかかる ○ 併存期間が長くなる 切り替えにかかる種々のコスト
- 19. 19 ● 大量のバックエンドを用意するのは手間 ○ 単純作業でも馬鹿にならない人的コスト ○ 頻繁な切り替え作業は大変… 切り替えにかかる種々のコスト
- 20. 20 ● 結果として ○ キャパシティプランニングがおざなりに ○ 多くの人を巻き込む必要 ■ LiveOpsの弊害 人的コストが高いと
- 21. 21 Cloud Spanner
- 22. 22 ● Googleの提供する分散RDB ● RDBなのでSQL使用可能 ● 容易にスケールアウト、スケールイン ● ダウンタイムなし ○ 我々の取り組みにも非常にマッチ Cloud Spannerとは
- 23. 23 早速採用
- 24. 24
- 25. 25 ● Cloud Spannerの利点 ○ メンテナンスウィンドウなし ○ スケールアウト，スケールインがとても容易 ○ スキーマもオンラインで容易に変更可能 ■ 弊社の方針にマッチ インフラから
- 26. 26 ● DevからみたCloud Spannerの利点 ○ DBの分割いらない ○ MasterとSlaveの意識もいらない ○ 純粋にゲームロジックに集中できる ■ スムースなLiveOpsの一助 Devから
- 27. 27 ● サーバーコスト ○ 費用対効果はとても高い ○ GCEのインスタンスで運用していた環境と比べて 半額程度に抑えることができた Cost
- 28. 28 01 Problem 02 Backend 03 Frontend Today’s Agenda KubernetesとSpannerで 進化し続けるコロプラのゲーム開発 04 No SPOF 05 Deploy
- 30. 30 ● イベント，日時等の理由で大きく変動 ● 適正なキャパシティに保つのは人力では不可能 ● タイトルの増加に伴い時間が取られる ● インフラと開発のリクエスト予想数の認識の差異 ゲームリクエスト
- 34. 34 ● スムースなLiveOpsの実現の為には頻繁なデプロイを伴う ○ デプロイ中にスケールすると差分が出る ○ デプロイ中のスケーリングの発動を止める ■ 冪等性の担保が難しい デプロイとオートスケール
- 35. 35 ● 頻繁なデプロイが可能 ● マニュアルスケールとオートスケールの両立 ● 煩雑な制御は無いまま オートスケールへの要件
- 36. 36 GKE
- 37. 37
- 38. 38 ● GKE環境では どのようにオートスケールさせるのか ○ オートスケールとマニュアルスケールの両立 ○ 冪等性の担保はどのように行われるのか GKEのオートスケール
- 44. 44 PVPは？
- 45. 45
- 46. 46 ● PVP内部をマイクロサービス化し， コンテナとして扱いやすいアーキテクチャに ● プロセス自身に終了前に自身のコネクションが 無くなるまで待機する機構 ○ APPと同様にオートスケール ○ デプロイもAPPと同様の感覚 GKEによるPVPのオートスケール
- 47. 47 01 Problem 02 Backend 03 Frontend Today’s Agenda KubernetesとSpannerで 進化し続けるコロプラのゲーム開発 04 No SPOF 05 Deploy
- 49. 49
- 50. 50
- 52. 52 ● ノード単位での退避から プロセス単位での自動復旧 ● Kubernetes管理下にすれば ロードバランサー配下に無くとも 監視可能 ● フォールバックの仕組みと 組み合わせることによって エラーを抑えて自動復旧が可能 Kubernetesの自己監視
- 54. 54 ● Cloud Spannerは計算ノードを 3台以上にすることでHA構成になる ● インスタンスの物理故障の恐怖から開放 Cloud SpannerのHA構成
- 56. 56 まとめ
- 57. 57 ● フロントエンド ○ GKEにより自動復旧するように ○ オートスケール ● バックエンド ○ Cloud SpannerによりHA化 ○ スケールの手間ほぼ０ まとめ
- 58. 58 ● サービス全体として ○ 外側からの挙動を監視するアラートで十分になった ○ スムースなLiveOpsを実現 まとめ
- 60. 60 01 Problem 02 Backend 03 Frontend Today’s Agenda KubernetesとSpannerで 進化し続けるコロプラのゲーム開発 04 No SPOF 05 Deploy
- 61. 61 About me
- 62. ● 邵 正(しょう せい) ● 2015年に新卒として株式会社コロプラに入社 ● クライアントとサーバーサイドエンジニアを担当, その後インフラチームに参画 ● セキュリティ，パフォーマンスチューニング， ストレステスト，新技術導入を担当 62 About me
- 64. ● RsyncによるDeploy ○ sshdがない ○ autoscaleによる 台数増減 64 GCPでの本番Deploy
- 65. 65 kubernetes上でのDeployための要件 ● ApplicationのソースコードDeploy ○ 我々のニーズ ■ Canary Deploy，時限式Deployなど ■ Autoscaleの対応 ■ Deploy進捗の把握
- 66. What is Spinnaker ● Netflixが開発したマルチクラウド対応のCDツール ● GKE対応 ● 目玉機能 ○ Pipeline ○ Versioning
- 67. 67 kubernetes上でのDeployための要件 ● ApplicationのソースコードDeploy ○ 我々のニーズ ■ Canary Deploy，時限式Deployなど ■ Autoscaleの対応 ■ Deploy進捗の把握
- 68. 68 Pipeline
- 69. 69 本番Deploy
- 70. 70 本番Deploy
- 71. 71 本番Deploy
- 72. 72 本番Deploy
- 73. 73 Kubernetes上でのDeployための要件 ● ApplicationのソースコードDeploy ○ 我々のニーズ ■ Canary Deploy，時限式Deployなど ■ Autoscaleの対応 ■ Deploy進捗の把握
- 74. 74 可視化
- 75. 75 可視化
- 76. 76 可視化
- 77. 77 可視化
- 78. 78 可視化
- 81. CI/CDのflow
- 82. CI/CDのflow
- 83. CI/CDのflow
- 84. CI/CDのflow
- 85. 85 Versioning
- 88. 88 Kubernetes上でのDeploy Git Commit b Commit a Commit b 旧 新 Commit b Commit a
- 89. 89 Kubernetes上でのDeploy ● インフラのDeployに新たな要件 ○ k8sでの設定ファイルのバージョン管理 ■ git管理されている設定ファイル ■ 動作中ミドルウェアの設定ファイル
- 90. 90 ● バージョン管理が可能 ○ Rollbackが簡単 ○ サービスインのAppに 影響しない V1 V1 V2 V2 V2 Versioning
- 91. 91 Spinnakerの課題と対策 ● Versioningしたくないリソースがあった ○ strategy.spinnaker.io/versioned: false ● Podが多いときにDeployがタイムアウト ○ 高負荷のマイクロサービスを専用ノードに移動 ● Pipelineのエラー調査が難しい ○ マイクロサービスごとに調査・確認をする
- 92. 92 まとめ ● Spinnakerによって ○ Pipelineを使ってのコロプラの要件の達成 ○ 動作中ミドルウェアの設定ファイルの バージョン管理 ○ CI/CDとの連携強化
- 93. 93 ● GKE, Spanner, Spinnakerを用いて ○ サービス全体の耐障害性向上 ○ キャパシティプランニングの手間ほぼ無し ○ デプロイへの種々要件の達成 まとめ
- 94. 94 スムースな LiveOps
- 95. Thank you!