長期運用タイトルの GCP 移行実例とグレンジのこれから | Google Cloud INSIDE Games & Apps

長期運用タイトルのGCP移行実例と
グレンジのこれから

発表者紹介
❏ サーバサイドエンジニア
❏ 「ポコロンダンジョンズ」の運用改善を担当
村田浩士（むらたひろし）

発表者紹介
❏ サーバサイドエンジニア
❏ GCP移行専任
❏ 新規アプリ「KickFlight」のインフラ構築
稲垣悟（いながきさとる）

Contents
1. GCP移行概要
2. ポコロンダンジョンズのGCP移行実例
3. GCP移行後に得られたこと
4. グレンジのこれから

もうすぐ５周年鋭意開発中
グレンジのアプリ

CAプライベートクラウド GCP
ポコロンダンジョンズは昨年GCPへ移行

なぜデータセンターを移行したのか
● CAプライベートクラウドの利用していた世代がクローズ
○ 老巧化による決定
○ コストの低さがとても魅力だった
○ ネットワークの逼迫

なぜGCPを選んだのか
● コスト
○ 他社と検討したがあまり差はなかった
● 将来性
○ ポコダンのみではなく新規アプリにもつなげたい
■ データベースの逼迫
■ アプリログの逼迫
■ データマイニングの効率化
■ コンテナの利用

移行プロジェクト開始から
本番環境の移行完了まで

10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7
2016
移行プロジェクト開始
● インフラ未経験のサーバエンジニア1人が挑戦
● サーバーエンジニアがインフラも管理する方針
● ゲーム事業の技術サポートチームから1人も加わりプロジェクト開始
2017 2018

技術検証とインフラ構築開始
10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7
2016 2017 2018
● オーケストレーションツール検証
● マネージド・サービス検証
● メトリクスツール検証

本番構成の構築完了と負荷試験
10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7
2016 2017 2018
● GCPの本番構成で問題無いことを確認できた

社内ツール移行、BigQueryログ転送開始
10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7
2016 2017 2018
● 社内ツールの移行
● ログサーバの容量逼迫により、BigQuery先行導入
● 2018年3月、7月の本番移行に向けてエンジニア2人追加

● 開発環境移行、移行リハーサル
10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7
2016 2017 2018
● 開発環境移行
● 再度、負荷試験
● 移行リハーサル

本番環境の移行
10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7
2016 2017 2018
● 2018年7月4日ステージング環境の移行完了
● 2018年7月5日本番環境の移行完了

ポコロンダンジョンズの
GCP移行実例

ポコロンダンジョンズのGCP移行実例
● 移行指針
● サーバ構成
● 移行順序
● 負荷試験
● 移行リハーサル
● 本番移行

移行指針 - 課題
● 障害
● メンテナンス時間

移行指針 - 検討項目
● サーバ構成を変えない
● ミドルウェアのバージョンは変更しない
● マネージドサービスの導入は最低限

移行指針
”最小限のリスクで
プライベートクラウドからGCPに移行をする”

サーバ構成 - 移行前（プライベートクラウド）
Mobile
Mobile
Mobile
DNS
Balancing
Balancing
Balancing
CDN コンテンツ
Web
Node.js
ログサー
バ
バッチ
Redis
pub/sub
マスタ
Memcached
マスタ
Redis
cache
マスタ
Storage
Redis
datastore
マスタ
mha
マネージャ
DB
スレーブ
DB
スタンバイ
Memcached
スタンバイ
Redis
cache
スタンバイ
Redis
datastore
スタンバイ
Redis
pub/sub
スタンバイ
DB
マスタ

サーバ構成 - 移行後（GCP）
Mobile
Mobile
Mobile
Cloud Load
Balancing
Cloud Load
Balancing
Cloud Load
Balancing
CDN コンテンツ
Web
Node.js
ログサー
バ
バッチ
Redis
pub/sub
Memcached
Redis
cache
Logging
Cloud
Storage
BigQuery
Redis
datastore
mha
マネージャ
DB
スレーブ
DB
スタンバイ
Redis
pub/sub
マスタ
Redis
cache
マスタ
Redis
datastore
マスタ
Redis
cache
スタンバイ
Redis
datastore
スタンバイ
Redis
pub/sub
スタンバイ
Memcached
マスタ
Memcached
スタンバイ
DNS
DB
マスタ

サーバ構成 - Stackdriver Logging
Stackdriver Logging
● ログの収集、検索、監視
● シンクを使用してログのエクスポート
● 除外フィルタによる、ログの分別・コスト削減
● google-fluentd

サーバ構成 - BigQuery
BigQuery
● ビッグデータ解析
● 高速な集計・分析
● データマイニングで活用
● ユーザ追跡ログの移行

サーバ構成 - Cloud SQLの導入は断念
Cloud SQL
● 高パフォーマンス
● スケラービリティ
● 高可用性

サーバ構成 - Cloud SQLの導入は断念
● 不定期に行われるメンテナンス
● レプリケーションができない
○ メンテナンス時間を削減するため、レプリが必須
○ MariaDBのバージョンにより、レプリができない
○ サードパーティのOSSでレプリが追いつかない

サーバ移行 - 導入したサービス

移行順序
社内ツール
開発環境
本番環境
● Redmine
● GitLab
● メールサーバ
データマイニングサーバ

負荷試験 - コンセプト
移行前
移行後
移行後
負荷
負荷
x ４

負荷試験 - コンセプト
● レイテンシベースのパフォーマンス比較
● メトリックは異常値以外は対象外

負荷試験 - 結果
移行後
4倍の負荷の
レスポンスタイム
API・URI
移行前
移行後
移行前のレスポンスタイムと
移行後のレスポンスタイムの比較
4倍のトラフィックのレスポンスタイムの比較

負荷試験 - 結果
現行4倍の
トラフィックの
レイテンシ
API・URI
プライベート
クラウド
レイテンシ
現行
トラフィックの
レイテンシ
比較対象
● avg：レイテンシの平均値
● max：レイテンシの最大値
● p99：99パーセンタイルの値
内容
● 負荷試験結果のレイテンシ ÷ プライベートクラウドのレイテンシ
● 緑色：レイテンシ向上（濃い色ほど結果が良い）
4倍のトラフィックのレスポンスタイムの比較
移行後のレスポンスタイムの比較

移行リハーサル - 経緯
社内ツール
開発環境
本番環境
● Redmine
● GitLab
● メールサーバ
データマイニングサーバ

● 十分なリハーサルを実施しなかった
● 結果、作業時間が大幅に遅延
移行リハーサル - 目的

社内エンジニア行動指針

● プライベートクラウドに最小構成での疑似本番環境を構築
● GCPに最小構成での疑似本番環境を構築
● 本番DBのデータをプライベートクラウドの疑似本番環境に反映
（レプリケーション）
● 移行手順書を作成
● 移行リハーサルを実施
移行リハーサル - 手順

移行リハーサル - DBレプリケーション
Master
Standby Slave
Master
Standby Slave
Master
Standby Slave
Master
Standby Slave
本番リハーサル

移行リハーサル - 移行手順書

移行リハーサル - リハーサル実施手順
手順書作成手順書レビューリハーサル実施実施後レビュー
● レビュー反映 ● 机上確認
● 属人化確認
● 時間計測 ● 効率化
● 自動化
● 手順確認

本番移行
● リハーサル通り、移行作業は滞りなく完了
”最小限のリスクで
プライベートクラウドからGCPに移行”

移行後のトラブルと運用改善

● インスタンスの再起動によるアラートが多発
移行後 - トラブル

● 原因は、”ホストエラー”
● DBでフェイルオーバー
● 単一ゾーン構成
移行後 - トラブル - アラート頻発

● 同一リージョンのゾーン間のレイテンシを計測
移行後 - トラブル - DBゾーン分散
● 同一リージョンのゾーン間のレイテンシはほぼないに等しい
● MHA Manager、マスタ、スタンバイ、スレーブをゾーン分散

移行後 - トラブル - DBゾーン分散
● master と standby に MHA Manager を同居させない
● 単一ゾーン障害でサービスを停止させない
種別／Zone Zone A Zone B Zone C
master 〇
standby 〇
MHA Manager 〇
slave 〇

● Stackdriver Logging
移行後 - トラブル - ホストエラーを検知する
● Cloud Pub/Sub
● Cloud Functions
resource.type="gce_instance"
jsonPayload.event_subtype=("compute.instances.automaticRestart" OR "compute.instances.hostError")

移行後 - 運用改善 - スナップショット
スナップショット
● 高速に取得
● 差分取得
● 世代管理
● グローバルで利用可能
● スケジュール

移行後 - 運用改善 - スナップショットバックアップ
／ XtraBackup Snapshot
日別バックアップ回数１３
所要時間 7～8時間 30分
リストア時間 1時間～2時間 40分

GCP移行後に得られたこと

GCP移行前と移行後のインフラコスト比率
移行前
GCP移行
確約利用割引
Committed use discount
GCEインスタンス数と
マシンスペック見直し

サーバサイドの体制
● アプリ運用開発とインフラを兼務できてる
○ サーバサイドエンジニア４名
○ インフラ専任のエンジニアはいない
● GCP移行後インフラ操作も容易
○ GCPコンソール
○ gcloudコマンド

BigQueryの活用
● Spreadsheet × BigQuery
● データマイニングサーバ（GCE MariaDB）で毎日集計
○ BIツール × MariaDB × BigQuery
○ BigQueryだけで完結させる計画
○ 集計を高速にしたい

Cloud BuildでCI
● コンテナで静的コード解析、PHPUnitを実行
● 常時稼働GCEと比較
○ ビルド時間分だけコストがかかるためコストダウン
○ 並列実行
○ CIの順番待ちが無い

Kubernetes Engineの利用
● WebサーバなどはGKEの利用を進めていく
○ できる限り本番と開発の環境を同じにしたい
○ デプロイメントを改善したい（Blue-Green Deployment）
○ サーバの追加、削除にもっと素早く対応したい
● OpenMatchはGKEで動作

Open Match
● マッチメイキングフレームワーク
● ハロウィンのDoodleゲーム
● スケーラブル
● MMFだけ作ればいい

Cloud Spannerの利用
● 問題点
○ ゲームではデータベース容量が肥大化しやすい
○ その度にスケールアップ、スケールアウトを行っている
● KickFlightはSpannerを採用
○ スケールアウトが簡単
○ アプリのシャーディング対応不要
○ 高可用性
○ アプリ開発に集中できる

ご清聴ありがとうございました！

長期運用タイトルの GCP 移行実例とグレンジのこれから | Google Cloud INSIDE Games & Apps

More Related Content

What's hot

Similar to 長期運用タイトルの GCP 移行実例とグレンジのこれから | Google Cloud INSIDE Games & Apps

More from Google Cloud Platform - Japan

長期運用タイトルの GCP 移行実例とグレンジのこれから | Google Cloud INSIDE Games & Apps