長期運用タイトルの GCP 移行実例とグレンジのこれから | Google Cloud INSIDE Games & Apps
•
1 like•4,790 views
2019-04-18 thu. 第 7 回 Google Cloud INSIDE Games & Apps 株式会社グレンジ 村田 浩士氏、稲垣 悟氏の登壇スライドです。
More Related Content
What's hot
What's hot (20)
Similar to 長期運用タイトルの GCP 移行実例とグレンジのこれから | Google Cloud INSIDE Games & Apps
Similar to 長期運用タイトルの GCP 移行実例とグレンジのこれから | Google Cloud INSIDE Games & Apps (20)
More from Google Cloud Platform - Japan
More from Google Cloud Platform - Japan (20)
Recently uploaded
Recently uploaded (10)
長期運用タイトルの GCP 移行実例とグレンジのこれから | Google Cloud INSIDE Games & Apps
- 2. 発表者紹介 ❏ サーバサイドエンジニア ❏ 「ポコロンダンジョンズ」の運用改善を担当 村田 浩士（むらた ひろし）
- 3. 発表者紹介 ❏ サーバサイドエンジニア ❏ GCP移行専任 ❏ 新規アプリ「KickFlight」のインフラ構築 稲垣 悟（いながき さとる）
- 4. Contents 1. GCP移行概要 2. ポコロンダンジョンズのGCP移行実例 3. GCP移行後に得られたこと 4. グレンジのこれから
- 5. GCP移行概要
- 9. なぜデータセンターを移行したのか ● CAプライベートクラウドの利用していた世代がクローズ ○ 老巧化による決定 ○ コストの低さがとても魅力だった ○ ネットワークの逼迫
- 10. なぜGCPを選んだのか ● コスト ○ 他社と検討したがあまり差はなかった ● 将来性 ○ ポコダンのみではなく新規アプリにもつなげたい ■ データベースの逼迫 ■ アプリログの逼迫 ■ データマイニングの効率化 ■ コンテナの利用
- 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日 本番環境の移行完了
- 19. ポコロンダンジョンズのGCP移行実例 ● 移行指針 ● サーバ構成 ● 移行順序 ● 負荷試験 ● 移行リハーサル ● 本番移行
- 20. 移行指針
- 21. 移行指針 - 課題 ● 障害 ● メンテナンス時間
- 22. 移行指針 - 検討項目 ● サーバ構成を変えない ● ミドルウェアのバージョンは変更しない ● マネージドサービスの導入は最低限
- 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. 負荷試験
- 37. 負荷試験 - コンセプト ● レイテンシベースのパフォーマンス比較 ● メトリックは異常値以外は対象外
- 39. 負荷試験 - 結果 現行4倍の トラフィックの レイテンシ API・URI プライベート クラウド レイテンシ 現行 トラフィックの レイテンシ 比較対象 ● avg：レイテンシの平均値 ● max：レイテンシの最大値 ● p99：99パーセンタイルの値 内容 ● 負荷試験結果のレイテンシ ÷ プライベートクラウドのレイテンシ ● 緑色：レイテンシ向上（濃い色ほど結果が良い） 移行前のレスポンスタイムと 4倍のトラフィックのレスポンスタイムの比較 移行前のレスポンスタイムと 移行後のレスポンスタイムの比較
- 40. 移行リハーサル
- 41. 移行リハーサル - 経緯 社内ツール 開発環境 本番環境 ● Redmine ● GitLab ● メールサーバ データマイニングサーバ
- 43. 社内エンジニア行動指針
- 44. ● プライベートクラウドに最小構成での疑似本番環境を構築 ● GCPに最小構成での疑似本番環境を構築 ● 本番DBのデータをプライベートクラウドの疑似本番環境に反映 （レプリケーション） ● 移行手順書を作成 ● 移行リハーサルを実施 移行リハーサル - 手順
- 45. 移行リハーサル - DBレプリケーション Master Standby Slave Master Standby Slave Master Standby Slave Master Standby Slave 本番 リハーサル
- 46. 移行リハーサル - 移行手順書
- 47. 移行リハーサル - 移行手順書
- 48. 移行リハーサル - リハーサル実施手順 手順書作成 手順書レビュー リハーサル実施 実施後レビュー ● レビュー反映 ● 机上確認 ● 属人化確認 ● 時間計測 ● 効率化 ● 自動化 ● 手順確認
- 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. インフラコスト
- 61. サーバサイドの体制 ● アプリ運用開発とインフラを兼務できてる ○ サーバサイドエンジニア ４名 ○ インフラ専任のエンジニアはいない ● GCP移行後 インフラ操作も容易 ○ GCPコンソール ○ gcloudコマンド
- 62. GCPのさらなる活用
- 63. BigQueryの活用 ● Spreadsheet × BigQuery ● データマイニングサーバ（GCE MariaDB）で毎日集計 ○ BIツール × MariaDB × BigQuery ○ BigQueryだけで完結させる計画 ○ 集計を高速にしたい
- 64. Cloud BuildでCI ● コンテナで静的コード解析、PHPUnitを実行 ● 常時稼働GCEと比較 ○ ビルド時間分だけコストがかかるためコストダウン ○ 並列実行 ○ CIの順番待ちが無い
- 65. グレンジのこれから
- 67. Kubernetes Engineの利用 ● WebサーバなどはGKEの利用を進めていく ○ できる限り本番と開発の環境を同じにしたい ○ デプロイメントを改善したい（Blue-Green Deployment） ○ サーバの追加、削除にもっと素早く対応したい ● OpenMatchはGKEで動作
- 68. Open Match ● マッチメイキングフレームワーク ● ハロウィンのDoodleゲーム ● スケーラブル ● MMFだけ作ればいい
- 69. Cloud Spannerの利用 ● 問題点 ○ ゲームではデータベース容量が肥大化しやすい ○ その度にスケールアップ、スケールアウトを行っている ● KickFlightはSpannerを採用 ○ スケールアウトが簡単 ○ アプリのシャーディング対応不要 ○ 高可用性 ○ アプリ開発に集中できる
- 70. ご清聴ありがとうございました！