Contenu connexe
Similaire à グリー株式会社『私たちが GCP を使い始めた本当の理由』第 9 回 Google Cloud INSIDE Game & Apps (20)
Plus de Google Cloud Platform - Japan (20)
グリー株式会社『私たちが GCP を使い始めた本当の理由』第 9 回 Google Cloud INSIDE Game & Apps
- 2. 堀口 真司
グリー株式会社 開発本部 インフラストラクチャ部
• 家庭用 普通 ゲーム( 1年) → 国内MMORPG などオンラインゲーム
開発、支援、販売(5年) → 主にアーケードゲーム基盤開発(2年) → グ
リー8年目
• クラウド系やゲーム系勉強会など多数講演
• 主にインフラ 運用効率改善(データベース、クラウド系全部)
• 社内で AWS 2014~ GCP 2017~
• アプリ開発・設計 お手伝い
- 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 を支えるため クラウドサービスへ 依存
- 12. •ゲームで ない別件で 柔軟性とス
ピード感重視で GAE と GKE を選択し
た
•雑ながらも結果的に上手くいき、ゲー
ムで 活用も視野に いった
•ビルドフローやモニタリング、データ分
析まで一通りできた
• VM 時代 課題 ほとんどない
• 2018/2月時点 人気手法とりいれた
• App Engine (Go) 2000 req/sec ~
• Kubernetes Engine 1000 req/sec ~
- 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)を利用
• 開発チーム側がログやテーブルを設計し、クエリも打つため
- 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
- 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 増やしたかった
• ノードが減りにくかった
• チャットボットが居なかった
リリース直後 反省会など 意見
- 27. 多様な選択肢
• 分析 BQ、 CDN に CF(+Lambda)と Akamai 、 GKE から
DynamoDB などハイブリッド化 進んでます
•開発チームやみんな スキル、趣向などを取り入れて自由様々にえ
らんでます
• 今 Spanner へ 感度が大変高くなっており、社内勉強会なども積極的に
開催されてます