2019-04-18 thu. 第 7 回 Google Cloud INSIDE Games & Apps 株式会社グレンジ 村田 浩士氏、稲垣 悟氏の登壇スライドです。

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

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

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

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

5. GCP移行概要

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

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

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

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

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

12. 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

13. 技術検証とインフラ構築開始
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
● オーケストレーションツール検証
● マネージド・サービス検証
● メトリクスツール検証

14. 本番構成の構築完了と負荷試験
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の本番構成で問題無いことを確認できた

15. 社内ツール移行、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人追加

16. ● 開発環境移行、移行リハーサル
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
● 開発環境移行
● 再度、負荷試験
● 移行リハーサル

17. 本番環境の移行
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日 本番環境の移行完了

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

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

20. 移行指針

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

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

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

24. サーバ構成

25. サーバ構成 - 移行前（プライベートクラウド）
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
マスタ

26. サーバ構成 - 移行後（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
マスタ

27. サーバ構成 - 移行後（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
マスタ

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

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

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

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

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

33. 移行順序

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

35. 負荷試験

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

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

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

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

40. 移行リハーサル

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

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

43. 社内エンジニア行動指針

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

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

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

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

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

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

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

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

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

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

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

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

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

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

58. GCP移行後に得られたこと

59. インフラコスト

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

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

62. GCPのさらなる活用

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

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

65. グレンジのこれから

66. todo kickflight軽く紹介

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

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

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

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