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

Confidential & Proprietary
Spanner から GKE、Spinnaker、そして SRE まで
コロプラが今挑戦していること

Agenda
● マイグレーションについて
● 新しいアーキテクチャー
○ GKEについて
○ Spinnakerについて
○ Spannerについて
● SREの取り組み

實方和幸
業務推進部インフラグループ第1インフラチームリーダー
マイグレーションについて

コロプラのゲームインフラ構成

従来までのマイグレーション方法

従来までのマイグレーション方法
auto increment
を上げる

マイグレーション時の問題
VPN通信のパケット数上限にあたる
(PPS問題)

マイグレーション時の問題
x

解決策
居合抜き

居合抜き
1. 既存環境とGCP環境をVPN接続
2. GCP環境にAPP/PVP/KVS/DBを構築
3. DBをVPN経由でレプリケーション設定
4. 既存環境にPROXYを追加
5. GCP環境DBMASTERのAuto incrementを上げる
6. 既存環境のPROXYにリダイレクト設定を入れ、リロード

従来までのマイグレーション

居合抜き

居合抜き
● メリット
○ 一瞬で切り替わる
● デメリット
○ 後戻りできない

邵正（しょうせい）
github.com/axot
新しいアーキテクチャー

この構成の問題点
● オートスケールの実現が難しい
● 自動復旧しない
● 構成の管理が難しい
● DBが単一障害点

コロプラのゲームインフラ新構成

まとめ
● オートスケールの実現が難しい→GKE + Spinnaker
● 自動復旧しない→GKE
● 構成の管理が難しい→Spanner + GKE
● DBが単一障害点→Spanner

奥村開里
GKEについて
業務推進部インフラグループ第2インフラチーム

今から話す部分 GKE

GKEにする我々の主な理由
● 主に次の３つを導入したいため
○ 自動復旧
○ インフラ構成のコード化
○ オートスケール
● 全てKubernetesで解決できそうではある
○ 結局Kubernetesクラスタ自体の管理は大変
→ GKEでマネージドなKubernetes

自動復旧
● 今までの問題
○ ロードバランサーからの
ヘルスチェックだけだと復旧しない
■ ロードバランサーから
切り離すだけ
■ プロセス再起動等の復旧は
試みない
■ 応答の無いプロセスが存在
してリソースが無駄に
なる可能性

自動復旧
○ ロードバランサーの配下に無い
コンポーネントは自己監視の仕組みがな
い
■ 外部から監視する必要
■ 外部から復旧を試みるのは難しい

解決策
Kubernetesに監視してもらう

自動復旧
● Kubernetesの自己監視の仕組み
を使用
○ 異常を検知すると退避ではなく、
復旧
○ Kubernetes管理下にすればロード
バランサーに関係なく自己監視
○ フォールバックの仕組みと組み合わせれ
ばエラー出すことなく自動復旧

インフラのコード化
○ VMを使い捨て運用できていない
■ 現在稼働しているインフラとコードの差分
がわからない
○ アプリケーションの設定とミドルウェアの設定が分離
■ 開発は用意されたインフラを信じてデプロイ
■ どんなミドルウェア設定で動くのか
アプリケーションには書いてない

解決策
Kubernetesのリソースとして全て管理

● コンテナ化による恩恵
○ アプリケーションとミドルウェアのパッケージ化
■ 動く保証のあるミドルウェアとアプリケーションの組み
合わせをデプロイ
○ Immutableなインフラ
■ コード化されたものと稼働しているものが一致している
保証

● Kubernetesによって
○ インフラ構成
○ ミドルウェア設定
■ 双方の差分の検知
が容易

オートスケール
● なぜ必要なのか
○ ゲームではリクエスト数
が跳ねる
■ イベント
■ 時間帯
○ 人力スケールは難しい
○ インフラコストの
適正化をしたい

● 我々が必要としていた
要件と直面した問題
○ ゲームだとイベント等により
大幅なスパイク
■ 手動でのスケーリングと
の両立が必要

● 我々が必要としていた要件と直面した問題
○ 頻繁なデプロイを行う
■ デプロイ中にスケールすると差分がでてしまう
■ デプロイ中にスケーリングの発動を止めたり等が煩雑
に

解決策
Kubernetesによるオートスケーリングとコ
ンテナによるデプロイ

● リクエストが増加
● CPU使用率増加

● コンテナ（Pod）を同じ
設定で起動して追加

● 新しいコンテナ（Pod)を追
加できなくなる
● Node（インスタンス）を追
加

● 新しく起動したNode(イ
ンスタンス)にPod(コン
テナ)を追加

● この方式ならば現在稼働しているコンテナのイメージで起動す
るので最新であることが保証される
○ 頻繁なデプロイが可能
● 手動でのスケールもKubernetesならば容易
○ 手動及び自動でのスケールの両立

まとめ
● 自動復旧
○ Kubernetesの自己監視、自己復旧により実現
● インフラのコード化
○ コンテナ化によるインフラとアプリケーションの
パッケージング、Kubernetesによる設定管理
により実現
● オートスケール
○ コンテナ化、デプロイ方式の変更により実現

問題
● 各種コンテナイメージのバージョン管理が
煩雑になりがち
● 手動でのスケールも現在の状態を可視化する必要
● デプロイツールがなく、コンテナイメージのIDなどの管理をして
いると破綻する

解決策
Spinnakerによる可視化と
CI/CD、可視化

邵正（しょうせい）
Spinnakerについて
github.com/axot

Spinnakerのメリット
● 柔軟な設定が可能なパイプライン
● 可視化とリソースマッピング
● バージョン管理

CI/CDのフロー

粟田大樹
Spannerについて
クリエイティブ本部第1エンジニアリング部第4グループ

コロプラの運用とSpanner
● メンテナンスを入れずに運用するのに適している！
● スケーリングが容易
○ Cloud Spanner の最も大きな恩恵！
○ ダウンタイムなし
○ 素早い反映（〜1分）
● スキーマのオンライン更新が容易

コロプラの運用とSpanner

アプリケーション側からの観点
● 開発段階で MySQL から Spanner への移行
● DB分割が不要に
○ 水平分割や master / slave を意識したコードが不要にな
りすっきり
● インタリーブとの相性
○ 特定データを同じ分散領域に保存する機能
○ ゲームのデータはユーザーに紐付いたものが多い
○ インタリーブの特性が活かせる

● PHP との連携
○ Spanner は PDO 非対応のため、独自 driver を開発
PDO
Laravel DB driver
社内独自 Mapper
独自
driver
Laravel DB
driver
社内独自 Mapper
google/cloud-spanner

● Spanner Client Library for PHP
○ Github で疑問点や不具合の報告がすぐできる
○ エンジニアからすぐにレスポンスがあり
非常にやりやすかった！

● MySQL からの移行はさくっとはいかない
● 考え方を変える必要がある
○ Spanner を「すごい MySQL」と思わないこと
○ 特にPK, Index, Transactionの特性
● ノウハウをサーバーエンジニアにレクチャー

● マスタデータの更新
○ （開発時） INSERT / UPDATE / DELETE のSQL文がない
○ 更新系は API でやる必要がある
○ 運営がデータ更新したい場合に困る
○ 環境間の差分を Spanner に反映するツールを開発
■ 開発環境でテスト
■ OKであれば本番環境と差分をとって反映

Spanner Tips
● CREATE DATABASE, CREATE TABLE は同時にする
○ extra_statements[] に DDL を入れる
○ 個別にやるよりはるかに速い！
● ログ・集計系は BigQuery 等にまかせる
○ Cloud Spanner は集計苦手
● (PHP) SessionPoolCache, AuthCache 指定する
○ パフォーマンス出すためには必須
● etc...

関根秀治
クリエイティブ本部第1エンジニアリング部第5グループ
SREの取り組み

なぜ SRE なのか

コロプラの運用体制

運用における課題
サーバーアプリケーション - 機能実装が優先
● 運用の効率化が後手になり手作業が多い
● パフォーマンスへの意識が薄くなりがち
インフラ - プロジェクトから遠い
● イベントスケジュールやユーザー様の熱量が分からない
● サービス固有の機能や実装について把握しきれない

運用における課題
● イベントや新機能リリース時のサービスの信頼性
● 運用の効率化
個人のスキル / 努力に依存してなりたっている
仕組み化しよう

SRE
サイトリライアビリティエンジニアリング
というワードを掲げ模索が始まる

SREとは

SREとは
“Google社が提唱、実践しているシステム管理とサービス運用の方法論
である” - Wikipedia
“SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときに
できあがるものです。”
“私たちは業界用語のDevOpsとは一線を画しています。私たちも確かに
インフラストラクチャをコードとして捉えてはいますが、私たちが焦点を当
てているのは信頼性です。”
- SRE サイトリライアビリティエンジニアリング

SREをやろうとすればするほど
分からなくなってきた

何をすればよいのか
SLO
SLI
エラーバジェット
自動化
トイル
ポストモーテム
モニタリング
リリースエンジニアリング
オンコール

誰がどういう立ち位置で
インフラが? サーバーアプリケーションが? 新しいチームが?
● インフラだとサービスから遠い
● サーバーアプリケーションだと権限がない
● 新しいチーム…時間がかかる

ゲームに適用できるのか
SREの守備範囲はどこか
● 運用の範囲
○ ゲームでは運用と開発が混然一体となった運営
● 信頼性を保障する範囲
○ クライアント / アセット / 仕様 / 設定は?

SLO Workshop

SLO Workshop
Google CREによるワークショップ
● 非英語圏では初の開催
● 本家本元のSREについて知ることができる
● SLI / SLO / エラーバジェットがテーマ
○ “SRE needs SLO”

SLI (Service Level Indicator)
ユーザーが満足に利用できているかを計測する指標
重要なUserJourneyに対して設定する
● Good: エラー率 / レスポンスタイム
● Bad: CPU使用率等のシステムメトリクス
SLO (Service Level Objective)
SLIに対する数値目標
● SLOを満たしている = happy
● SLOを割り込む = unhappy

エラーバジェット
許容可能なエラー率
エラーバジェットが枯渇した場合は何らかの信頼性回復のアクショ
ンが求められる
exp. 可用性SLO 99.9% → 0.1%は許容

コロプラでのSRE

何をすればよいのか
● SLI/SLOがSREにおけるコア
● ここの策定と実装が優先事項

どういう体制か

ゲームに適用できるのか
SREの範囲
● 運用の範囲
○ システム的な運用の範囲 / コンテンツ運用は行わない
● 信頼性を保障する範囲
○ サーバーではなくユーザー体験にフォーカス
エラー率 / レイテンシー
フレームレート / クライアントの遷移時間 etc...
○ SREだけでは対応不能な事象は他人を頼る

具体的な活動
● SLI/SLOの策定とモニタリング仕組み実装
○ Stackdriver Logging / BigQuery 他
● 信頼性向上
○ パフォーマンス維持/改善
■ 設計/実装レビュー
■ 継続的監視と改善
○ SLIに影響がある(と思われる)エラー解消
● 開発の効率化

新しい仲間を募集中
コロプラでは一緒に働く
サーバーサイドエンジニア
インフラエンジニア
を募集しています
皆様のご応募お待ちしております

Thank you

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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

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

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

Plus de Google Cloud Platform - Japan

Plus de Google Cloud Platform - Japan (20)

Dernier

Dernier (11)

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