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

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

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

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

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

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

開発開始まで 社内事情

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

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

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

GCP に期待されること

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

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 ～。 動画配信・コミュニティプラットフォームな で ゲームより だいぶ複雑なも を運用して慣れてきた。

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

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

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

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

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

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

API Container Engine App 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

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

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

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 SQL master failover Cloud SQL Cloud SQL master failover Cloud SQL Cloud SQL master failover replica による分散に頼らず 水平・垂直分割でし ぐ。 Behind も気にせずアプリも開発しやすい 運用 ちょっとめんどう。

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

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

これから こと

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

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