長期運営スマホゲームのクラウドマイグレーション

発表者紹介

❏ 株式会社グレンジ

ポコロンダンジョンズ担当

サーバサイド リードエンジニア

❏ 運営改善

開発の効率化

村田 浩士（むらた ひろし）

Contents

1. GCP移行概要

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

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

GCP移行概要

CyberAgent Group

〜 ５周年 〜２０１９年６月

鋭意開発中２０１９年 配信予定

グレンジのアプリ

CyberAgentプライベートクラウド

GCP

ポコロンダンジョンズは昨年GCPへ移行

Redmine GitLab

なぜデータセンターを移行したのか

● 利用していたプライベートクラウドの世代がクローズ

○ 老巧化による決定

○ コストの低さがとても魅力だった

○ ネットワークの逼迫

● パブリッククラウドのサービス拡充

○ 次はプライベートではなくパブリッククラウドへ

なぜGCPを選んだのか

● コスト

○ 他社と検討したがあまり差はなかった

● 将来性

○ ポコダンのみではなく新規アプリにもつなげたい

■ データベースのディスク容量逼迫

■ アプリログのディスク容量逼迫

■ データマイニングの効率化

■ コンテナの利用

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

10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 72016

移行プロジェクト開始

● インフラ未経験のサーバエンジニア1人が挑戦

● サーバーエンジニアがインフラも管理する方針

● CAゲーム事業の技術サポートチームから1人も加わりプロジェクト開始

2017 2018

技術検証とインフラ構築開始

10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 72016 2017 2018

● オーケストレーションツール検証

● マネージド・サービス検証

● メトリクスツール検証

ポコダン本番構成の構築完了と負荷試験

10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 72016 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 72016 2017 2018

● 社内ツールの移行

● ログサーバの容量逼迫により、BigQuery先行導入

● 2018年7月に本番移行の実施決定、3月からエンジニア2人追加

開発環境移行、移行リハーサル

10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 72016 2017 2018

● 開発環境移行

● 再度、負荷試験

● 移行リハーサル

本番環境の移行

10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 72016 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 LoadBalancing

Cloud LoadBalancing

Cloud LoadBalancing

CDN コンテンツ

Web

Node.js

ログサーバ

バッチ

Redis pub/sub

Memcached

Redis cache

Logging

CloudStorage

BigQuery

Redis datastore

mhaマネージャ

DBスレーブ

DBスタンバイ

Redis pub/subマスタ

Redis cacheマスタ

Redis datastoreマスタ

Redis cacheスタンバイ

Redis datastoreスタンバイ

Redis pub/subスタンバイ

Memcachedマスタ

Memcachedスタンバイ

DNS

DBマスタ

サーバ構成 - 移行後（GCP）

Mobile

Mobile

Mobile

Cloud LoadBalancing

Cloud LoadBalancing

Cloud LoadBalancing

CDN コンテンツ

Web

Node.js

ログサーバ

バッチ

Redis pub/sub

Memcached

Redis cache

Logging

CloudStorage

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● ログの収集、検索、監視

● シンクを使用してログのエクスポート

● 除外フィルタによる、ログの分別・コスト削減

● google-fluentd

○ fluentdベース

○ 元々fluentdを使っていたので置き換えた

サーバ構成 - BigQuery● ビッグデータ解析

● 高速な集計・分析

● データマイニングで活用

サーバ構成 - Cloud SQLの導入は断念

● 高パフォーマンス

● スケラービリティ

● 高可用性

● 検証したが、導入を断念

サーバ構成 - Cloud SQLをなぜ断念したか

● 不定期に行われるメンテナンス

● レプリケーションができない

○ メンテナンス時間を短くするため、レプリケーションが必須

○ 利用中のMariaDBのバージョンとCloud SQLは不可能だった

■ データレプリケーションエンジンを通したら、レプリケーションが追いつか

ない

移行順序

移行順序

社内ツール

開発環境

本番環境

● Redmine● GitLab

データマイニングサーバ

負荷試験

負荷試験

移行前

移行後

移行後

負荷

負荷

x ４

負荷試験 - 結果

移行後4倍の負荷の

レスポンスタイムAPI・URI 移行前

レスポンスタイム移行後

レスポンスタイム

移行前のレスポンスタイムと移行後のレスポンスタイムの比較

移行前のレスポンスタイムと4倍トラフィックのレスポンスタイムの比較

負荷試験 - 結果

現行4倍のトラフィックのレイテンシ

API・URI

プライベートクラウド

レイテンシ

現行トラフィックのレイテンシ

比較対象● avg：レスポンスタイムの平均値● max：レスポンスタイムの最大値● p99：99パーセンタイルの値

内容● GCP／プライベートクラウド● 緑色：レスポンスタイム向上（濃い色ほど結果が良い）

移行前のレスポンスタイムと4倍トラフィックのレスポンスタイムの比較

移行前のレスポンスタイムと移行後のレスポンスタイムの比較

移行リハーサル

● プライベートクラウドに最小構成での疑似本番環境を構築

● GCPに最小構成での疑似本番環境を構築

● 本番DBのデータをプライベートクラウドの疑似本番環境に反映

（レプリケーション）

● 移行手順書を作成

● 移行リハーサルを実施

移行リハーサル - 手順

移行リハーサル - DBレプリケーション

Master

Standby Slave

Master

Standby Slave

Master

Standby Slave

Master

Standby Slave

本番 リハーサル

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

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

移行リハーサル - リハーサル実施手順

手順書作成 手順書レビュー リハーサル実施 実施後レビュー

● レビュー反映 ● 机上確認● 属人化確認

● 時間計測 ● 効率化● 自動化● 手順確認

本番移行 - 手順 ● アプリのメンテナンス

● データベースのレプリケーションが追いついたことを確認

○ Seconds_Behind_Master: 0

● DNSのIPアドレス切替

● メンテナンス中にログイン可能な端末で動作確認

● アプリのメンテナンス解除

● 移行作業は約2時間

本番移行

● リハーサル通り、移行作業は滞りなく完了

最小限のリスクで

プライベートクラウドからGCPに移行

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

● インスタンスの再起動によるアラートが多発

移行後 - トラブル

● 原因は、”ホストエラー”

● DBでフェイルオーバー発生

○ 単一ゾーン構成を危惧する

移行後 - トラブル - アラート頻発

移行後 - トラブル - DBゾーン分散

● master と standby に MHA Manager を同居させない

● 単一ゾーン障害でサービスを停止させない

種別／Zone Zone A Zone B Zone C

master 〇

standby 〇

MHA Manager 〇

slave 〇

移行後 - トラブル WebSocketが接続できない

● Android 4.0.4以下の端末で発生

○ TLS / SSL 認証

○ アプリのライブラリ修正が困難

● Android 4.0.4以下用のサーバーを急遽用意

○ GCP移行前と同じ構成でサーバーにSSL証明書を配置

○ TCP LB● 現在はサポートを切ったので、近日サーバーを停止予定

GCP移行後に得られたこと

インフラコスト

GCP移行前と移行後のインフラコスト比率

移行前

GCP移行

確約利用割引Committed use discount

GCEインスタンス数とマシンスペック見直し

サーバサイドの体制

● アプリ運用開発とインフラを兼務できてる

○ サーバサイドエンジニア ４名○ インフラ専任のエンジニアはいない

● GCP移行後 インフラ操作も容易

○ GCPコンソール

○ gcloudコマンド

GCPのさらなる活用

Cloud BuildでCI● コンテナで静的コード解析、PHPUnitを実行

● 常時稼働GCEと比較

○ ビルド時間分だけコストがかかるためコストダウン

○ 並列実行

○ CIの順番待ちが無い

スナップショットスケジュール

● GCEのストレージを差分バックアップ

○ 頻度、時間を指定可能

○ 保存期間も指定可能、期間が過ぎると自動削除

● MariaDBのスレーブでは利用していない

○ 利用中のMariaDBのバージョンでは、

STOP SLAVEしてからでないとファイル間の整合性が取れない

BigQueryの活用

● Spreadsheet × BigQuery

● データマイニングサーバ（GCE MariaDB）で毎日集計

○ BIツール × MariaDB × BigQuery○ BigQueryだけで完結させる計画

○ 集計を高速にしたい

まとめ

● 移行前と移行後で変更点を減らすことのメリット

○ 移行時のリスクを減らせる

○ 検証中に比較も確認しやすい

● 移行後のマネージドサービス活用

○ 全サーバー移行後だと試しやすい

● 新規アプリにGCPの知見を活かせる

○ 魅力的なマネージドサービスGKE / Spanner

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