1. 私たちがGCPを
使い始めた本当 理由
2019年11月18日
堀口 真司
グリー株式会社
開発本部 インフラストラクチャ部
ディベロップメントオペレーションズグループ
リードエンジニア

2. 堀口 真司
グリー株式会社 開発本部 インフラストラクチャ部
• 家庭用 普通 ゲーム（ 1年） → 国内MMORPG などオンラインゲーム
開発、支援、販売（５年） → 主にアーケードゲーム基盤開発（２年） → グ
リー８年目
• クラウド系やゲーム系勉強会など多数講演
• 主にインフラ 運用効率改善（データベース、クラウド系全部）
• 社内で AWS 2014～ GCP 2017～
• アプリ開発・設計 お手伝い

3. もくじ
•開発開始まで 社内事情
•GCP に期待されること
•結果や課題など
•これから こと
30分だと思ってたら20分だった

4. じめに
•会社 方針や組織全体 認識
で ない こと
•AWS より優れているとか、イケ
てないとか、そういう比較 で な
い こと

5. • 消滅都市スピンオフ
• アニメもやってたよ！
• ストーリー重視
• ターン制バトル
• そこそこ 規模 ゲームで
初めて GCP

6. OnPre
GCP
2014 2019
AWS
AFTERLOST 消滅都市
消滅都市0.
開発や運営メンバー 同じ。
効率よく運用することが求められた

7. 開発開始まで 社内事情

8. VM 中心 クラウド環境 理想的な運用に
なりつつあった！
•Chef Cookbook によって符号化されたサーバ環境
• インフラ担当、セキュリティ担当、モニタリング担当、ゲーム開発者それぞれ
チームが独立してコミットできる
•CloudFormation や多数 運用ツールを使って簡略化
•マネージドサービスを多用し自動復旧や Pager 削減
•大量 メトリクスを収集して最適化や問題解決 高 化
•ゲーム開発開始から、サービスクローズまで手順化
•ゲームで ありきたりな LAMP 環境

9. Backend
DB Replica
Auto Scale
…
commit
VM Image
…
DB
Master
Launch
Admin
Serverless
Asset
・Pager
・Chat
・Mail
・Logging
・Monitoring
DB Replica
…
DB
Master
・Redis
・Memcache
App
Operator
Developer
Deploy
build
CDN
LoadBalancer
Serverless

10. VM を中心とした環境 課題
•僅かな修正で VM イメージ 作り直しと入れ替えに手間がかかりデ
プロイ手法 氾濫、学習コスト増加
• Packer, Capistrano, s3 sync, Code Deploy
•管理コストを抑えるために VM イメージ 共通化
• 多様性 低下、開発者 裁量低下、基盤検証コスト 増加
•スケールアウトに時間がかかる で余裕を持ったキャパシティ設計
でコスト増加
•VM を支えるため クラウドサービスへ 依存

11. GCP に期待されること

12. •ゲームで ない別件で 柔軟性とス
ピード感重視で GAE と GKE を選択し
た
•雑ながらも結果的に上手くいき、ゲー
ムで 活用も視野に いった
•ビルドフローやモニタリング、データ分
析まで一通りできた
• VM 時代 課題 ほとんどない
• 2018/2月時点 人気手法とりいれた
• App Engine (Go) 2000 req/sec ～
• Kubernetes Engine 1000 req/sec ～

13. Kubernetes cluster
GKE
Dashboard
Ingress
HTTPS
GKE
Support
GKE
Channel
GKE
Redis
GKE
Web
GKE
Certificate Manager
Cloud DNS
reality.wrightflyer.net
Identity Aware
Proxy
GKE
Jenkins
GKE
Web-stg
GKE
Collab
GKE
Comment
GKE
Video
GKE
Comment Monitor
GKE
Comment Summarizer
GKE
PHPMyAdmin
User
Cloud SQL
Streaming
Cloud Datastore
CloudFront
Lambda
App Engine
GKE ワークロード 40種類ぐらい。 200 Pods ～。
動画配信・コミュニティプラットフォームな で
ゲームより だいぶ複雑なも を運用して慣れてきた。

14. ゲームでもコンテナを使いたかった
•VM イメージ構築 期待通りに動作していたし、既存 手法でも大き
な不満 なかった
•VM で Immutable を目指すとスピード感が落ちる。どちらか トレー
ドオフになりがち
•インフラ部が VM イメージを管理するより 、開発チームに任せて裁
量と責任を寄せたい。でもノウハウ 共有したい
•AFTERLOST 消滅都市案件で 想定規模も控えめで、開発チーム
も前向きに GKE を検討

15. Kubernetes Engine で運用したかった
•Kubernetes を運用したいわけで ない
• Kubernetes が問題を起こしたときに対処しにくい（できない）
• よってマネージド Kubernetes 以外ありえない。独自 CRD も消極的
• Google Origin だし GKE 相性良さそうな気がした
• svc 仕様変更で iptables が壊れたり、 ingress-gce バグ踏んだりしたけど。
•Compute Engine 利用 避けたかった
• VM イメージ 管理が増える 暗い未来が待っている
• VM に SSH して運用できるようにすると、考えなけれ いけないことが膨大
になる

16. と いえ、劇的にアーキテクチャを変えたい
というわけで なかった
•ガチャとかあるし、（新規事業に比べて）売り上げ規模 割合 大き
いし、保守コスト かけたくないし。
•AppEngine や Spanner 検討せず。
•他 マネージドサービスもありふれたも を利用
• RDS → CloudSQL (MySQL)
• CloudWatch → Stackdriver
• S3 → CloudStorage
• Lambda → Functions
• BQ 使わず、慣れた内製ツール（Kinesis EMR）を利用
• 開発チーム側がログやテーブルを設計し、クエリも打つため

17. かなり大きい運用負担になる
構築、運用 手間
オーバーヘッド費用
地域ごと 負荷 波
※実際 サービス地域と 異なります
2days、日本を除く

18. 課題や結果など
ここから tips など

19. docker コンテナ化 期待通り
VM
Apache
PHP
Ubuntu
Monitoring
Application
VM
Monitoring
Application
Middleware
any OS
anything…
VM で OS や
ミドルウェア イ
ンフラ部で
対応
コンテナで OS
やミドルウェアを開
発チームで自由に
選べる。
新しい開発言語や
OS など積極的に
取り入れることが
でき、インフラ 負
担も減らせる。
VM Image

20. API
Container EngineApp
afterlost.wfs.games
Cloud DNS
HTTPS-Ingress
Cloud Load Balancing
Certificate
Manager
Container
Something
Logging
Alert
Monitoring
Batch
Container Engine
Admin
Container Engine
Admin
Cloud IAP
Developer
Customer
Service
User-1
Cloud SQL
Notify
Cloud Pub/Sub
Stg-API
Container Engine
Stg-Admin
Container Engine
Stg-Admi
n
Cloud IAP
To-slack
Cloud Functions
Asset
Cloud Storage
Kubernetes
cluster
production1
Kubernetes
cluster
monitoring
HTTPS-Ingress
Cloud Load Balancing
Grafana
Container Engine
Grafana
Cloud IAP
Ops
Stackdriver
Prometheus
Container
PagerDuty
Slack
Kinesis
User-N
Cloud SQL
Masterdata
Container
Registory

21. 東京リージョン み運用
手抜きで ない
遅い地域でも 300ms 程度

22. DNS 問題 起こらなかった
Pod
API
dnsmasq
fluentd
database.afterlost.wfs.games.
最後 ドットもちゃんとつけて
リゾルバ search suffix を回避。
GKE 環境 ndots が 5 で高め。
念 ため
sidecar
IPv4 が っきりしているなら
AAAA レコード 引かない。
(CloudSQL VPC IP 不変らしい)

23. CloudSQL リリース初日に方針変更
Cloud
SQL
Cloud
SQL
Cloud
SQL
Cloud
SQL
master
failover
replica-1
replica-N
Behind
Replication スレッド 一つ
innodb_flush_log_at_trx_commit = 1
更新系性能がスケールしにくい
Cloud
SQL
Cloud
SQLmaster failover
Cloud
SQL
Cloud
SQLmaster failover
Cloud
SQL
Cloud
SQLmaster failover
replica による分散に頼らず
水平・垂直分割でし ぐ。
Behind も気にせずアプリも開発しやすい
運用 ちょっとめんどう。

24. Production 環境 Kustomize 廃止
base
production
QA-1
Dev-1
Dev-N
real
テンプレ化できるほど
単純で なかった。
運用事故を防ぐためにも
専用に管理
helm 化や json 風 .js を nodejs に通すやり方などやってみ
たけど、なるべく raw に近い Kustomize が使いやすかった。
GKE コンソールで編集もできるし。

25. よかった
• スケジュール通り
• 開発チーム Kubernetes 理解
度が高かった
• 海外レイテンシが良かった
• 過去 GCP 経験 活かせた
• CI/CD 環境もバッチリできた
改善したい
• 情報 共有が少なかった
• DNS が弱かった
• Stackdriver ログ代が高かった
• CloudSQL 負荷が予想以上だった
• サービスアカウントが乱立してた
• 固定 IP 必須と相性が悪かった
• Request/Limit 精査してなかった
• 特定 タイミングに Pod 増やしたかった
• ノードが減りにくかった
• チャットボットが居なかった
リリース直後 反省会など 意見

26. これから こと

27. 多様な選択肢
• 分析 BQ、 CDN に CF(+Lambda)と Akamai 、 GKE から
DynamoDB などハイブリッド化 進んでます
•開発チームやみんな スキル、趣向などを取り入れて自由様々にえ
らんでます
• 今 Spanner へ 感度が大変高くなっており、社内勉強会なども積極的に
開催されてます

28. • インフラ部で 自社ゲームだけで
なくグループ・関連企業全体 運
用を行っています。たくさんプロ
ジェクト・案件あります
• 規模も様々で、 Cloud Run で済
むも から数千vCPUクラスま
で！
• GCP を採用した裏 理由も聞けます
ご清聴ありがとうございました