※下の記事は2021年4月13日に放送された Google Cloud (GCP) INSIDE Games & Apps のセッション内容をもとに作成しています。
最適なゲームインフラを構築するために考えておくべきこと
ゲームに関する API やその API からアクセスされるデータベースを構築する時は、スケーラビリティを考慮することが重要です。新しくゲームをローンチしたタイミングで大量のユーザーが入ってきたり、毎日のピークタイムにアクティブユーザーが一時的に増えたりアクセスの増減が予想されるからです。また、それに加えて予期しないトラフィック増に備えることも重要です。
Google Cloud (GCP) がソリューション デザインパターンを公式サイトで公開していますが、その中にはゲームに関する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 は設計において注意すべきポイントがいくつかあるので、それらも学んでから構築することが必要です。
実際のアーキテクチャ例
grasys で実際に GKE と Cloud Spanner を組み合わせて活用している上記の事例では、共通ノード、コンテンツ固有ノード、監視専用ノードというようにノードごとに機能を分けています。Cloud Build でビルドを Shell でキックしてデプロイまで行い、Cloud Functions を利用してフックしています。
監視用のノードを使用していますが、一部では Cloud Monitoring を使用したり Cloud Logging に全てのログを流してそちらでまたフックをしたり用途に合わせて使い分けています。Cloud Spanner と Memorystore と Datastore でバックエンドサービスは切り分けて利用しています。Cloud Spanner もインスタンスはコンテンツごとに分けたり、スキーマで分けたりしています。
Cloud Spanner は運用コストがかかりません。ゲームはデータベースのシャーディングをして、ユーザーデータベースに逃すことが多いですが、シャーディングを考えなくても良いというのはインフラエンジニアにとって嬉しい点です。また、grasys では Cloud Spanner をを3、4年使用していますが、Cloud Spanner での障害は一度も起きていません。一見高価なサービスですが、実はエンジニアの工数を考慮して TOC （Total Ownership Cost）を考えると高くありません。今はエミュレータも出ているので開発環境でもチャレンジしやすいです。
GKE 運用における留意点
GKE にはオートスケール機能もありますが、grasys では Pod のスケールには HPA（Horizontal Pod Autoscaler）を使って Shell で叩いています。ゲームを運用しているとユーザーが流入するタイミングがある程度予測できるので、HPA を使ってミニマムのサイズを変えています。例えば8時くらいからユーザーが増える場合、7時半くらいに Shell でキックしてミニマムサイズを上げておき、深夜1時くらいなったらユーザーが減るのでミニマムサイズを下げるなどコストの最適化を図っています。
Pod は瞬間的には起動しないので、ある程度時間に余裕を持っておかないと急なアクセス増に耐えられません。常に HPA は入っていますが、ピークしやすい昼間や夜中の時間帯などに合わせて Pod 数をある程度事前調整しながら運用しています。
運用面での GKE の課題にも触れておくと、アップグレードにはかなりの工数がかかります。アップグレードをするために大きな問題に直面したことはないものの、アップグレードする際には検証が必要になり、人件費コストがかかるので、事前に準備しておくことが必要です。
GAE vs GCE vs GKEの選択方法
自前のインフラを構築する必要がない場合は GAE を利用して、grasys のような企業を利用しなくてもプログラマさんのみで完結することができます。GCE を選択するお客様ももちろんいらっしゃいます。GKE を使うにはどうしても学習コストがかかるので、学習コストをまかなえる開発リソースがある場合に GKE を使います。GKE を使う場合、Kubernetes をまず理解していなければその中身を作るのは難しいです。
一方で、Kubernetes を理解して、どのようなアーキテクチャでどう使いたいかがはっきりしているお客様ももちろんいらっしゃいます。ただし、ずっとセッションを持ち続けたり常にネットワークを張っていないければならない場合は、本当に GKE が適切なのか話し合います。どれだけステートを持っていなければいけないのかも検討し、ステートやワークロードに合わせて選択する必要があります。