grasys blog

最適なゲームインフラを構築するために考えておくべきこと

文●grasys 編集● ASCII

  • この記事をはてなブックマークに追加
  • 本文印刷

本記事はgrasys が提供する「grasys blog」に掲載された最適なゲームインフラを構築するために考えておくべきこと」を再編集したものです。

 ゲームに関する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は設計において注意すべきポイントがいくつかあるので、それらも学んでから構築することが必要です。

実際のアーキテクチャー例

 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が適切なのか話し合います。どれだけステートを持っていなければいけないのかも検討し、ステートやワークロードに合わせて選択する必要があります。

※この記事は2021年4月13日に放送された Google Cloud INSIDE Games & Appsのセッション内容をもとに作成しています。

■関連サイト

過去記事アーカイブ

2021年
03月
04月
05月
06月
07月
2020年
04月
05月
08月
09月
10月
11月
12月
2018年
09月
2017年
06月
2014年
07月