Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

KubernetesとSpannerで 進化し続けるコロプラのゲーム開発

3.428 Aufrufe

Veröffentlicht am

2018-11-22 thu.
第 6 回 Google Cloud INSIDE Games & Apps

株式会社コロプラ 邵 正 氏と奥村 開里 氏の登壇スライドです。

Veröffentlicht in: Technologie
  • Loggen Sie sich ein, um Kommentare anzuzeigen.

KubernetesとSpannerで 進化し続けるコロプラのゲーム開発

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

×