GREE Tech Conference 2021 で発表された資料です。 https://techcon.gree.jp/2021/session/Session-9

1. WFSにおける
Cloud Spannerと
GKEを中心とした
GCP導入事例の紹介
株式会社WFS リードエンジニア 藤田貴大

2. • 藤田貴大（ふじた たかひろ）
• 所属
• 株式会社WFS
Technology Development部
Engineering5グループ
リードエンジニア
• 職歴
• 組み込みエンジニアとしてネットワーク機器の開発に携わったのち、
2012年にグリー入社。インフラ、Webゲーム開発、QAを経て、
2017年よりサーバエンジニアとしてネイティブゲームの開発に携わ
っている。
自己紹介
2

3. 3
はじめに
• WFSでは、ゲームサーバとしてGoogle Cloud
Platform(GCP)の利用を進めています
• 現在GCPを利用してリリースされているタイトルは
”シドニアの騎士 掌位ノ絆”
• 他にも開発中タイトルが
控えています
©弐瓶勉・講談社／東亜重工重力祭運営局 © WFS

4. 4
本発表の概要
• どうしてGCP、GKE、Cloud Spannerを採用したのか
• 導入にあたって出た問題にどう対応したのか
• 実際につかってみてどうだったのか

5. 5
WFSのゲームについて
• ソーシャルゲーム
• 遊んでいる時は常にゲームサーバと通信している
• データがサーバ側にある
• 世界展開している
• さまざまな国に対してサービスを提供している
• サーバ負荷の変動が大きい

6. 6
WFSにおけるサーバへの要求
• ゲームなので、応答性能はある程度必要
• 応答速度はゲームの楽しさに影響がある
• サービスを提供する全地域に対して
ある程度のレイテンシで通信したい
• サーバリソースをできるだけ柔軟に変更したい

7. 7
ソーシャルゲームのサーバ規模について
• リリース直後や人気のイベントの開始など
アクセスが集中するタイミングがある
• 数倍、１０倍、、、
• イベントなどは月に数回

8. 8
リソース最適化
• できるだけ余剰リソースは作りたくない
• ゲームを止めたくない（メンテナンス）
• サービスを提供したままサーバリソースを調整したい

9. 9
いままではどうだったか
• ゲームサーバ
• 現在はKubernetesに頼っているのでできている
• それ以前、VMに直接デプロイしていた頃からオンラインで
実施可能
• MySQL
• メンテナンスが必要
• 弊社インフラチームにまかせればオンラインでDBの最適化
(マスタ分割/統合など)が可能であるが、数週間の準備が必要
• Memcached/Redis
• メンテナンスが必要

10. 10
GCP導入の理由
• レイテンシが短い
• Cloud Spannerが使えそうだった
• Google Kubernetes Engine

11. 11
レイテンシ

12. 12
実測したレイテンシ
• 他社クラウドを利用したゲームで海外展開する場合は
各地域(US、EU、etc…)にサーバを配置している
• GCPでは東京リージョンから各地域にサービスを提供できて
いる
東京リージョン <-> ブラジル
他社 1000msec以上
GCP 300msec未満

13. 13
さまざまな地域からのレイテンシが短いほうが良い理由
• あるいは、サーバの配置場所を選択できた方がいい理由
• １か所に集中していた方が管理がしやすい
• リソースの共有も可能
• 外部サービスとの連携
• WFSの認証・決済システムであるGamelib
• 独立したシステムでHTTPSにより通信している
• 海外リージョンにサーバを設置するために
Gamelibも海外サーバを作ってもらっている
ゲームサーバ
認証・決済
システム

14. 14
Cloud Spanner

15. 15
Cloud Spanner
• 水平分割しなくてよい
• メンテナンスコストが低い
• ランニングコストは高いかもしれない
• スプリット分割が難しそう
無制限のスケーリング、強整合性、最大 99.999% の可用性を備えたフルマネージド リレーショナル データベースです。
● 無制限のスケーリングによって、リレーショナル セマンティクスと SQL のすべてのメリットを享受
● 任意のサイズで開始し、ニーズの拡大に応じて制限なしでスケーリング
● 計画的ダウンタイムのない、オンラインによるスキーマ変更で高可用性を実現
● リージョンや大陸全体にわたる強整合性で高性能のトランザクションを提供
● 自動シャーディングなどの機能により手動のタスクを排除し、イノベーションに注力
Cloud Spanner
https://cloud.google.com/spanner/?hl=ja

16. 16
Cloud Spannerのコスト
• 他社MySQLサービスとの比較
• APIサーバに10,000RPSの負荷をかけたときの比較
1リクエスト当たりのDBアクセス ノード数 ノードコスト(比率)
他社MySQLサービス read:5 update/insert:4 8(※) 1
Cloud Spanner read:5 update/insert:4 20 1.3
※：実際に必要なノードは4。
ただし、障害に備えたスタンバイが必要であるためx2で8。
DB
ゲームサーバ 負荷測定ツール

17. 17
Cloud Spannerのコスト考察
• MySQLと比べたとき、スタンバイを考慮に入れると
そこまで大きく差は開かない
• Cloud Spannerはスケールアウト/スケールインが
オンラインで実施可能であるため、さらにコストダウンの
可能性がある

18. 18
Cloud Spannerのスプリット分割
• リクエスト処理にかなり大きく
影響する
• 基本的には制御できない
• 現在のスプリットの状態がわからない
• 予防的に事前に負荷をかけて
スプリット分割を促す
RPS
レイテンシ

19. 19
Spanner運用ツール
• インフラチームで開発
• この後のセッションで詳しい説明がありますので...
• 温める君
• 事前にスプリット分割を促す
• 上げ下げ君
• ノード数を自動で制御する

20. 20
Google Kubernetes Engine

21. 21
Google Kubernetes Engine
• 特徴的な機能
• Workload Identity
• プリエンプティブルインスタンス

22. 22
Workload Identity
• GKE(Kubernetes)のサービスアカウントと
GCPのサービスアカウントを紐づけて
Google Cloudサービスを利用する権限を管理する方法
• GCPのドキュメントでは”推奨される方法”というようになっ
ている
• だが、当初は利用できなかった
• PHP SDKの問題

23. 23
Workload Identity with PHP
• PHPのSDKに問題が多かった
• PHP側のキャッシュ管理にバグがあった
• podがスタートしてから一定時間でCloud Spannerへ通信できなく
なる
• アクセストークンの有効期限と
キャッシュ有効期限が連動していなかった
• Google様に連絡して修正していただきました
• https://github.com/googleapis/google-auth-library-php/issues/308
• 高負荷時、アクセストークンの更新に失敗する
• メタデータサーバからのアクセストークンの取得に失敗して
空の情報をキャッシュしていた
• こちらも、最新のSDKでは解消済み

24. 24
プリエンプティブルインスタンスの活用
• コスト面で非常に魅力的なので導入したい
• ゲームサーバはもともとステートレスなので
導入しようと思えばできるのではと考えていた
• 実際はそう簡単ではなかった
• 突然停止するとエラーになったり、Sidecarで回収している
ログが欠損したりする
プリエンプティブル VM インスタンスは、標準 VM の料金よりもはるかに低価格（60～91% 割引）で利用できます。ただし、他
のタスクがリソースを再利用する必要がある場合、Compute Engine がこのインスタンスを停止（プリエンプト）する可能性があ
ります。プリエンプティブル インスタンスは Compute Engine の余剰のキャパシティを利用する機能であり、使用できるかどう
かは利用状況に応じて異なります。
プリエンプティブル VM インスタンス
https://cloud.google.com/compute/docs/instances/preemptible?hl=ja

25. 25
GKE version 1.20
• 2021/09にStable
• Graceful Node Shutdown機能
• ApacheがGraceful Shutdownできる
• lifecycleのpreStopで後片付けができる
• 処理の中断、ログの欠損などが無くなった
• Cronjobは工夫が必要
• ノードの入れ替えを分散させる工夫を検討中
• 複数台同時に入れ替わると良くない
• 経験的に24時間で停止するので、そのあたりを調整できたら
と考えている

26. 26
実際にサービスを提供してみて
• Workload Identityを利用したCloud Spannerへの
アクセスは順調
• 事前のスプリット分割はうまくいって
実サービスでスプリット分割の兆候はみられなかった
• メンテナンスをせずにサーバリソースの最適化ができている
• さまざまな国に対して東京リージョンから
サービスを提供できている
（世界展開をしている別のゲームで）
• プリエンプティブルインスタンスも一部導入できている
• ノードの入れ替えを分散させられていない

27. 27
まとめ
• GKE + Cloud Spannerをつかったゲームを
提供することができた
• Cloud Spannerはスプリット分割など
難しいところもあるが、ツールを充実させるなどして
運用可能になった
• GKE 1.20になってプリエンプティブルVMが
サービスに使えるようになった
• PHP SDKは最初バグもあったが問題は解消されてきている

28. 28