Spanner から GKE、Spinnaker、そして SRE まで、コロプラが今挑戦していること[Google Cloud INSIDE Games & Apps]

Spanner から GKE、Spinnaker、そして SRE まで、コロプラが今挑戦していること[Google Cloud INSIDE Games & Apps]
Confidential & Proprietary Spanner から GKE、Spinnaker、そして SRE までコロプラが今挑戦していること
Confidential & Proprietary Agenda ● マイグレーションについて ● 新しいアーキテクチャー ○ GKEについて ○ Spinnakerについて ○ Spannerについて ● SREの取り組み
Confidential & Proprietary 實方和幸業務推進部インフラグループ第1インフラチームリーダーマイグレーションについて
Confidential & Proprietary コロプラのゲームインフラ構成
Confidential & Proprietary 従来までのマイグレーション方法
Confidential & Proprietary 従来までのマイグレーション方法
Confidential & Proprietary 従来までのマイグレーション方法 auto increment を上げる
Confidential & Proprietary マイグレーション時の問題 VPN通信のパケット数上限にあたる (PPS問題)
Confidential & Proprietary マイグレーション時の問題 x
Confidential & Proprietary 解決策居合抜き
Confidential & Proprietary 居合抜き 1. 既存環境とGCP環境をVPN接続 2. GCP環境にAPP/PVP/KVS/DBを構築 3. DBをVPN経由でレプリケーション設定 4. 既存環境にPROXYを追加 5. GCP環境DBMASTERのAuto incrementを上げる 6. 既存環境のPROXYにリダイレクト設定を入れ、リロード
Confidential & Proprietary 居合抜き 1. 既存環境とGCP環境をVPN接続 2. GCP環境にAPP/PVP/KVS/DBを構築 3. DBをVPN経由でレプリケーション設定 4. 既存環境にPROXYを追加 5. GCP環境DBMASTERのAuto incrementを上げる 6. 既存環境のPROXYにリダイレクト設定を入れ、リロード
Confidential & Proprietary 従来までのマイグレーション
Confidential & Proprietary 居合抜き
Confidential & Proprietary 居合抜き ● メリット ○ 一瞬で切り替わる ● デメリット ○ 後戻りできない
Confidential & Proprietary 邵正（しょうせい）業務推進部インフラグループ第2インフラチームリーダー github.com/axot 新しいアーキテクチャー
Confidential & Proprietary コロプラのゲームインフラ構成
Confidential & Proprietary この構成の問題点 ● オートスケールの実現が難しい ● 自動復旧しない ● 構成の管理が難しい ● DBが単一障害点
Confidential & Proprietary コロプラのゲームインフラ新構成
Confidential & Proprietary まとめ ● オートスケールの実現が難しい→GKE + Spinnaker ● 自動復旧しない→GKE ● 構成の管理が難しい→Spanner + GKE ● DBが単一障害点→Spanner
Confidential & Proprietary 奥村開里 GKEについて業務推進部インフラグループ第2インフラチーム新しいアーキテクチャー
Confidential & Proprietary 今から話す部分 GKE
Confidential & Proprietary GKEにする我々の主な理由 ● 主に次の３つを導入したいため ○ 自動復旧 ○ インフラ構成のコード化 ○ オートスケール ● 全てKubernetesで解決できそうではある ○ 結局Kubernetesクラスタ自体の管理は大変 → GKEでマネージドなKubernetes
Confidential & Proprietary 自動復旧 ● 今までの問題 ○ ロードバランサーからのヘルスチェックだけだと復旧しない ■ ロードバランサーから切り離すだけ ■ プロセス再起動等の復旧は試みない ■ 応答の無いプロセスが存在してリソースが無駄になる可能性
Confidential & Proprietary 自動復旧 ● 今までの問題 ○ ロードバランサーの配下に無いコンポーネントは自己監視の仕組みがない ■ 外部から監視する必要 ■ 外部から復旧を試みるのは難しい
Confidential & Proprietary 解決策 Kubernetesに監視してもらう
Confidential & Proprietary 自動復旧 ● Kubernetesの自己監視の仕組みを使用 ○ 異常を検知すると退避ではなく、復旧 ○ Kubernetes管理下にすればロードバランサーに関係なく自己監視 ○ フォールバックの仕組みと組み合わせればエラー出すことなく自動復旧
Confidential & Proprietary インフラのコード化 ● 今までの問題 ○ VMを使い捨て運用できていない ■ 現在稼働しているインフラとコードの差分がわからない ○ アプリケーションの設定とミドルウェアの設定が分離 ■ 開発は用意されたインフラを信じてデプロイ ■ どんなミドルウェア設定で動くのかアプリケーションには書いてない
Confidential & Proprietary 解決策 Kubernetesのリソースとして全て管理
Confidential & Proprietary インフラのコード化 ● コンテナ化による恩恵 ○ アプリケーションとミドルウェアのパッケージ化 ■ 動く保証のあるミドルウェアとアプリケーションの組み合わせをデプロイ ○ Immutableなインフラ ■ コード化されたものと稼働しているものが一致している保証
Confidential & Proprietary インフラのコード化 ● Kubernetesによって ○ インフラ構成 ○ ミドルウェア設定 ■ 双方の差分の検知が容易
Confidential & Proprietary オートスケール ● なぜ必要なのか ○ ゲームではリクエスト数が跳ねる ■ イベント ■ 時間帯 ○ 人力スケールは難しい ○ インフラコストの適正化をしたい
Confidential & Proprietary オートスケール ● 我々が必要としていた要件と直面した問題 ○ ゲームだとイベント等により大幅なスパイク ■ 手動でのスケーリングとの両立が必要
Confidential & Proprietary オートスケール ● 我々が必要としていた要件と直面した問題 ○ 頻繁なデプロイを行う ■ デプロイ中にスケールすると差分がでてしまう ■ デプロイ中にスケーリングの発動を止めたり等が煩雑に
Confidential & Proprietary 解決策 Kubernetesによるオートスケーリングとコンテナによるデプロイ
Confidential & Proprietary オートスケール ● リクエストが増加 ● CPU使用率増加
Confidential & Proprietary オートスケール ● コンテナ（Pod）を同じ設定で起動して追加
Confidential & Proprietary オートスケール ● 新しいコンテナ（Pod)を追加できなくなる ● Node（インスタンス）を追加
Confidential & Proprietary オートスケール ● 新しく起動したNode(インスタンス)にPod(コンテナ)を追加
Confidential & Proprietary オートスケール ● この方式ならば現在稼働しているコンテナのイメージで起動するので最新であることが保証される ○ 頻繁なデプロイが可能 ● 手動でのスケールもKubernetesならば容易 ○ 手動及び自動でのスケールの両立
Confidential & Proprietary まとめ ● 自動復旧 ○ Kubernetesの自己監視、自己復旧により実現 ● インフラのコード化 ○ コンテナ化によるインフラとアプリケーションのパッケージング、Kubernetesによる設定管理により実現 ● オートスケール ○ コンテナ化、デプロイ方式の変更により実現
Confidential & Proprietary 問題 ● 各種コンテナイメージのバージョン管理が煩雑になりがち ● 手動でのスケールも現在の状態を可視化する必要 ● デプロイツールがなく、コンテナイメージのIDなどの管理をしていると破綻する
Confidential & Proprietary 解決策 Spinnakerによる可視化と CI/CD、可視化
Confidential & Proprietary 邵正（しょうせい） Spinnakerについて業務推進部インフラグループ第2インフラチームリーダー github.com/axot 新しいアーキテクチャー
Confidential & Proprietary Spinnakerのメリット ● 柔軟な設定が可能なパイプライン ● 可視化とリソースマッピング ● バージョン管理
Confidential & Proprietary
Confidential & Proprietary CI/CDのフロー
Confidential & Proprietary 粟田大樹 Spannerについてクリエイティブ本部第1エンジニアリング部第4グループ新しいアーキテクチャー
Confidential & Proprietary コロプラの運用とSpanner ● メンテナンスを入れずに運用するのに適している！ ● スケーリングが容易 ○ Cloud Spanner の最も大きな恩恵！ ○ ダウンタイムなし ○ 素早い反映（〜1分） ● スキーマのオンライン更新が容易
Confidential & Proprietary コロプラの運用とSpanner
Confidential & Proprietary アプリケーション側からの観点 ● 開発段階で MySQL から Spanner への移行 ● DB分割が不要に ○ 水平分割や master / slave を意識したコードが不要になりすっきり ● インタリーブとの相性 ○ 特定データを同じ分散領域に保存する機能 ○ ゲームのデータはユーザーに紐付いたものが多い ○ インタリーブの特性が活かせる
Confidential & Proprietary アプリケーション側からの観点 ● PHP との連携 ○ Spanner は PDO 非対応のため、独自 driver を開発 PDO Laravel DB driver 社内独自 Mapper 独自 driver Laravel DB driver 社内独自 Mapper google/cloud-spanner
Confidential & Proprietary アプリケーション側からの観点 ● Spanner Client Library for PHP ○ Github で疑問点や不具合の報告がすぐできる ○ エンジニアからすぐにレスポンスがあり非常にやりやすかった！
Confidential & Proprietary アプリケーション側からの観点 ● MySQL からの移行はさくっとはいかない ● 考え方を変える必要がある ○ Spanner を「すごい MySQL」と思わないこと ○ 特にPK, Index, Transactionの特性 ● ノウハウをサーバーエンジニアにレクチャー
Confidential & Proprietary アプリケーション側からの観点 ● マスタデータの更新 ○ （開発時） INSERT / UPDATE / DELETE のSQL文がない ○ 更新系は API でやる必要がある ○ 運営がデータ更新したい場合に困る ○ 環境間の差分を Spanner に反映するツールを開発 ■ 開発環境でテスト ■ OKであれば本番環境と差分をとって反映
Confidential & Proprietary Spanner Tips ● CREATE DATABASE, CREATE TABLE は同時にする ○ extra_statements[] に DDL を入れる ○ 個別にやるよりはるかに速い！ ● ログ・集計系は BigQuery 等にまかせる ○ Cloud Spanner は集計苦手 ● (PHP) SessionPoolCache, AuthCache 指定する ○ パフォーマンス出すためには必須 ● etc...
Confidential & Proprietary 関根秀治クリエイティブ本部第1エンジニアリング部第5グループ SREの取り組み
Confidential & Proprietary なぜ SRE なのか
Confidential & Proprietary コロプラの運用体制
Confidential & Proprietary 運用における課題サーバーアプリケーション - 機能実装が優先 ● 運用の効率化が後手になり手作業が多い ● パフォーマンスへの意識が薄くなりがちインフラ - プロジェクトから遠い ● イベントスケジュールやユーザー様の熱量が分からない ● サービス固有の機能や実装について把握しきれない
Confidential & Proprietary 運用における課題 ● イベントや新機能リリース時のサービスの信頼性 ● 運用の効率化個人のスキル / 努力に依存してなりたっている仕組み化しよう
Confidential & Proprietary SRE サイトリライアビリティエンジニアリングというワードを掲げ模索が始まる
Confidential & Proprietary SREとは
Confidential & Proprietary SREとは “Google社が提唱、実践しているシステム管理とサービス運用の方法論である” - Wikipedia “SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるものです。” “私たちは業界用語のDevOpsとは一線を画しています。私たちも確かにインフラストラクチャをコードとして捉えてはいますが、私たちが焦点を当てているのは信頼性です。” - SRE サイトリライアビリティエンジニアリング
Confidential & Proprietary SREをやろうとすればするほど分からなくなってきた
Confidential & Proprietary 何をすればよいのか SLO SLI エラーバジェット自動化トイルポストモーテムモニタリングリリースエンジニアリングオンコール
Confidential & Proprietary 誰がどういう立ち位置でインフラが? サーバーアプリケーションが? 新しいチームが? ● インフラだとサービスから遠い ● サーバーアプリケーションだと権限がない ● 新しいチーム…時間がかかる
Confidential & Proprietary ゲームに適用できるのか SREの守備範囲はどこか ● 運用の範囲 ○ ゲームでは運用と開発が混然一体となった運営 ● 信頼性を保障する範囲 ○ クライアント / アセット / 仕様 / 設定は?
Confidential & Proprietary SLO Workshop
Confidential & Proprietary SLO Workshop Google CREによるワークショップ ● 非英語圏では初の開催 ● 本家本元のSREについて知ることができる ● SLI / SLO / エラーバジェットがテーマ ○ “SRE needs SLO”
Confidential & Proprietary SLI (Service Level Indicator) ユーザーが満足に利用できているかを計測する指標重要なUserJourneyに対して設定する ● Good: エラー率 / レスポンスタイム ● Bad: CPU使用率等のシステムメトリクス SLO (Service Level Objective) SLIに対する数値目標 ● SLOを満たしている = happy ● SLOを割り込む = unhappy
Confidential & Proprietary エラーバジェット許容可能なエラー率エラーバジェットが枯渇した場合は何らかの信頼性回復のアクションが求められる exp. 可用性SLO 99.9% → 0.1%は許容
Confidential & Proprietary コロプラでのSRE
Confidential & Proprietary 何をすればよいのか ● SLI/SLOがSREにおけるコア ● ここの策定と実装が優先事項
Confidential & Proprietary どういう体制か
Confidential & Proprietary ゲームに適用できるのか SREの範囲 ● 運用の範囲 ○ システム的な運用の範囲 / コンテンツ運用は行わない ● 信頼性を保障する範囲 ○ サーバーではなくユーザー体験にフォーカスエラー率 / レイテンシーフレームレート / クライアントの遷移時間 etc... ○ SREだけでは対応不能な事象は他人を頼る
Confidential & Proprietary 具体的な活動 ● SLI/SLOの策定とモニタリング仕組み実装 ○ Stackdriver Logging / BigQuery 他 ● 信頼性向上 ○ パフォーマンス維持/改善 ■ 設計/実装レビュー ■ 継続的監視と改善 ○ SLIに影響がある(と思われる)エラー解消 ● 開発の効率化
Confidential & Proprietary 新しい仲間を募集中コロプラでは一緒に働くサーバーサイドエンジニアインフラエンジニアを募集しています皆様のご応募お待ちしております
Confidential & Proprietary Thank you

Check these out next

Spanner から GKE、Spinnaker、そして SRE まで、コロプラが今挑戦していること[Google Cloud INSIDE Games & Apps]

Recommended

More Related Content

Slideshows for you(20)

Similar to Spanner から GKE、Spinnaker、そして SRE まで、コロプラが今挑戦していること[Google Cloud INSIDE Games & Apps](20)

More from Google Cloud Platform - Japan(20)

Recently uploaded(20)

Spanner から GKE、Spinnaker、そして SRE まで、コロプラが今挑戦していること[Google Cloud INSIDE Games & Apps]