スマートフォン向けソーシャルゲームではクライアントのリッチ化が進行し、開発の主眼はますますクライアント側にシフトしている。一方でサーバー側では目立った大きな変化はないもののマネージドサービスが充実・成熟し普及が進んだ。

こうした背景をふまえ、これからのバックエンド開発ではゲームモデルにあわせて可能な限りマネージド比率を高めてサーバー側の開発・運用コストを下げていくことで、より小さな規模で高速な開発が可能にしていくことが重要となる。この記事では主要なサービスや技術要素を解説しそれらをゲームモデルに合わせてどう選択していくべきか考える。

 

サービスの紹介

データベース

各データベースのおおまかな特性を表にしめし、それぞれについて解説する。

	パラダイム	ホスティング	Read response	Write response	スループットの調節
MySQL	RDBMS	専用	低い	低い	複雑
DynamoDB	KVS	共用	5ms-	50ms-	容易
Cloud Datastore	KVS	共用	50ms-	100ms-	全自動
Cloud Spanner	RDBMS	専用	低い	10ms-	容易

※Read / Write のレスポンスタイムは大まかに計測した値のため適切な設定ができていない場合もあることをご了承ください

MySQL

信頼と実績のあるRDBMS。新規タイトルの場合AWSではAurora、GCPではCloud SQLを利用することで運用の手間をある程度減らすことができる。分散システムではないため1クラスタでの書込性能には限界があり、ソーシャルゲームのように大規模なwrite処理がある用途では水平/垂直分割が必要になり、そのための設計とコーディングが煩雑になりがちである。またインスタンスのスケールアップ・ダウンで対応しきれない場合のクラスタの分割・統合のオペレーションは複雑なものになる。

スケールアップ・ダウンやnodeのメンテナンスなどでMaster nodeを切替える際には不通時間が発生してしまうため、安全のためゲーム自体をメンテナンス状態にする必要が発生する。

※自前でのMySQL運用では無停止でのMaster切り替えも要件によっては可能であるがマネージドサービスを利用する場合にはそういった対応は難しい/可能な場合でもオペレーションコストをかんがみて実施しない。

[AWS] DynamoDB

Managed Key-Value Store。弊社ではアナザーエデンなどで利用している。正しく設計するとスケーラビリティが得ることができる。反面トランザクションや参照時のクエリの制約がとても大きいため、ソーシャル要素が加わった場合にはRDBMSを利用した方が良い場合が多い。またインスタンスを他のテナントと共用するせいか、レスポンスタイムは専有型のDBと比べると比較的遅めである。アナザーエデンでは通信の大半がブロッキングではなくバックグラウンドによるリクエストのため、レイテンシがさほど問題にならず最適であった。

料金は読込/書込のcapacity unitを事前にprovisioningしておき、それに対して価格が付いているモデルとなっている。auto scalingなどの機能も充実してきたが、突発的な負荷でcapacityを超えてしまうとエラーとなってしまうことがある。そのため大きめのバッファーをとっておいたり、サービスの特性に合わせてcapacityを細かく調整するツールをつくるなどの工夫が必要となる。

[GCP] Cloud Datastore

Managed Key-Value Store。公開されている有名な他社事例としてポケモンGOやアイドルマスターミリオンライブシアターデイズなどがある。基本的な特性は前述のDynamoと同様だがレスポンスタイムはさらに遅く、通信モデルを十分に考慮して、徹底的に非同期にするなど工夫することでユーザーは通信時間の長さへのストレスを減らす必要がでてくる。

Dynamoとは異なり読込/書込のアクセスに対しての課金でありcapacity provisioningが不要であることはとても良い。

[GCP] Cloud Spanner

分散型のRDBMS。十分なスケーラビリティを持ちながら、トランザクション機能やそこそこ充実したインデックスや集計機能があるため、ソーシャル要素の実装も従来のRDBMSの感覚でできる。

また子テーブル機能により、単一テーブルを行単位で複数nodeに分散しつつ、それぞれの行に1:1や1:nで紐付いたデータを集約できる。これにより例えば1人のユーザーが所持しているカードの全件取得などがMySQLでの水平分割と比較して直感的かつ効率的に実装できる。

インスタンスは専有で良好なレスポンスタイムが得られる。

現在明示的なバックアップ機能が存在しないがStack Overflowでの担当者とみられる人物の投稿によるとGCP内部ではバックアップが保持されているとのこと。

Redis

補助的に用いられるデータベース。AWS、GCPそれぞれでマネージドサービスが存在する。他データベースで苦手とするランキング実装に主に用いられる。シングルスレッドで動作するため1CPUが上限でそれ以上のスケールアップができないという問題点があり、Memcachedの代わりなどとして使うと想像以上にすぐに刺さる。

Webサーバー

VM

Webサーバーを構築する場合の基本となる選択肢。

Heroku

以前から存在するPaaS環境。極めて簡単なセットアップで劇的に構築・オペレーションコストを削減できるがリージョンが米国東部とヨーロッパにしか存在しないことや割高なことからソーシャルゲームでの採用は難しい。

[GCP] Google App Engine / Standard Environment

Googleが提供するPaaS環境。GAEと略される。設定不要で完全自動のオートスケーリングと秒単位でのインスタンスの追加など他にない魅力的な機能を持つ。以前からあるサービスであるが制約が多く、動作する言語の数が少なく、かつバージョンアップが行われない（例えばPHPは今でも5.5）という問題があったため敬遠されてきた。最近ではGo言語に関してのみ積極的なバージョンアップが実施されるようになり採用事例も急速に増えている。

Dockerベース

AWSではECS、GCPではGKEがある。VMベースと比較してプロセス単位でのモジュール化がしやすい、比較的provisioningが速く更新もやりやすいなどのメリットがある。これまではDockerを動かすVMについても引き続き意識して管理する必要があり2重管理の問題があったが、VM管理が不要で高速に起動するAWS Fargateの登場などで状況は変化してきている。VMベースで既存の運用システムが存在する場合にはわざわざ移行する強いメリットがあるとは言い難いが、新規の場合には検討する価値がある。

Serverless

Serverless / FaaS は話題になっている技術で、弊社でも内部オペレーションでAWS Lambdaを多用している。ただしWebサーバーとしての利用についてはspin upに時間がかかることやAPI Gatewayを経由する関係などのせいか、VMと比較してレスポンスタイムがあまり良好でない傾向が見られる。またデバッグや周辺ツールの整備も日々改善しているものの一段難易度があがってしまう印象がある。

Google Cloud Functionsについては現在ベータ版という位置づけでTokyoリージョンではサービスがない。また動作言語はnode.jsのみがサポートされている。

今後環境が整っていくと最初に検討される候補になっていくのではないだろうか。

ゲームモデルに合わせたアーキテクチャの選択

ソロプレイ型

他プレイヤーとのゲーム上でのつながりがないソロプレイ型では、チート行為が他ユーザーへの迷惑となる可能性が減少するため、データの処理をクライアント側がプライマリとして持ち、サーバーにはセーブデータのように送信するタイプの通信モデルが可能となる。

この場合Cloud DatastoreとGAEを組み合わせることで通常プレイ中は裏側でデータを送信することでユーザーに見える通信待ちを減らしつつ、サーバー側実装を大幅にへらすことができる。

決済やくじなど重要な処理については例外としてサーバーで処理して不正をある程度防止すると良い。

ソーシャル型（フレンド・RAID・PvP・GvG）

他プレイヤーとゲーム上でつながりがある場合にはチート行為が他プレイヤーに迷惑を与えたり、他人がチート行為をしているという事実が顕在化することで不快感を与えるといった問題が発生しやすいため、ソロプレイ型よりも対策を強化する必要がある。データの処理はサーバがプライマリとなり不正を可能な限り排除していくことが求められる。また、単一ユーザーに閉じないリレーショナルなデータが増えるためそういったものを扱いやすいデータベースが優位となる。

この場合データベースにはSpannerやMySQL、WebサーバーにはVMやDocker、GAEが考えられる。ソロプレイ型と比較してサーバーサイドのコード量が大きく増加しそこの生産性の重要度が増すため、GAE/Goだけでなく自社で開発リソースが確保しやすい別の言語やフレームワークを選択することが合理的な場合も多くなる。