※下の記事は2021年4月13日に放送された Google Cloud INSIDE Games & Apps のセッション内容をもとに作成しています。
最適なゲームインフラを構築するために考えておくべきこと
ゲームに関する API やその API からアクセスされるデータベースを構築する時は、スケーラビリティを考慮することが重要です。新しくゲームをローンチしたタイミングで大量のユーザーが入ってきたり、毎日のピークタイムにアクティブユーザーが一時的に増えたりアクセスの増減が予想されるからです。また、それに加えて予期しないトラフィック増に備えることも重要です。
Google Cloud がソリューション デザインパターンを公式サイトで公開していますが、その中にはゲームに関するAPI + データベース サーバーの構築パターンもあります。こういった資料を参考にアーキテクチャを考えるのも一つの手法です。
可用性の高いインフラを構築するためのサービス選択
API サーバーをホスティングする際は、GAE（Google App Engine）、Cloud Run、GCE (Google Compute Engine）、GKE（Google Kubernetes Engine）といった複数の選択肢がありますが、grasys では大規模ゲームの運用には GKE を採用することが多いです。今回は、GKE と Cloud Spanner を組み合わせるアーキテクチャについて考えます。
GKE と Cloud Spanner を組み合わせるアーキテクチャの特徴は、システムの可用性です。Cloud Spanner は計画的なメンテナンスがないため、24時間365日計画メンテナンスなしで運用できます。また、システムを停止することなくノード数を増減してユーザー数の増減に対応することができるというのいうのも特徴です。Kubernetes のスケーラビリティが優れている理由として、仮想マシンを増やしていくスピードよりも Pod がスケールしていくスピードの方が速いという点も挙げられます。
Kubernetes は頻繁にアップデートされていくので、そこに追従してどのように調整していくのか事前に計画を練っておくことが重要です。また、Cloud Spanner は設計において注意すべきポイントがいくつかあるので、それらも学んでから構築することが必要です。
実際のアーキテクチャ例
監視用のノードを使用していますが、一部では Cloud Monitoring を使用したり Cloud Logging に全てのログを流してそちらでまたフックをしたり用途に合わせて使い分けています。Cloud Spanner と Memorystore と Datastore でバックエンドサービスは切り分けて利用しています。Cloud Spanner もインスタンスはコンテンツごとに分けたり、スキーマで分けたりしています。
Cloud Spanner は運用コストがかかりません。ゲームはデータベースのシャーディングをして、ユーザーデータベースに逃すことが多いですが、シャーディングを考えなくても良いというのはインフラエンジニアにとって嬉しい点です。また、grasys では Cloud Spanner をを3、4年使用していますが、Cloud Spanner での障害は一度も起きていません。一見高価なサービスですが、実はエンジニアの工数を考慮して TOC （Total Ownership Cost）を考えると高くありません。今はエミュレータも出ているので開発環境でもチャレンジしやすいです。
GKE 運用における留意点
Pod は瞬間的には起動しないので、ある程度時間に余裕を持っておかないと急なアクセス増に耐えられません。常に HPA は入っていますが、ピークしやすい昼間や夜中の時間帯などに合わせて Pod 数をある程度事前調整しながら運用しています。
運用面での GKE の課題にも触れておくと、アップグレードにはかなりの工数がかかります。アップグレードをするために大きな問題に直面したことはないものの、アップグレードする際には検証が必要になり、人件費コストがかかるので、事前に準備しておくことが必要です。
GAE vs GCE vs GKEの選択方法
一方で、Kubernetes を理解して、どのようなアーキテクチャでどう使いたいかがはっきりしているお客様ももちろんいらっしゃいます。ただし、ずっとセッションを持ち続けたり常にネットワークを張っていないければならない場合は、本当に GKE が適切なのか話し合います。どれだけステートを持っていなければいけないのかも検討し、ステートやワークロードに合わせて選択する必要があります。
