ゲーム開発が変わる！ Google Cloud Platform実践インフラ構築 第1章（3/3 ページ）

GCPの各サービスにおけるゲームインフラとしてのユースケース

　前項にてGCPを構成する各サービスの概要について紹介しました。しかし一般にゲームインフラでは全てのサービスを使っている訳ではなく、よく使われるサービスや余り使われないサービスがあります。本項ではゲームインフラという観点で、どのようにGCPの各サービスが活用されているかの概要について簡単に紹介します。

実行環境サービス

Google Compute Engine

　ゲームインフラの中で中核になるのが、アプリケーションの実行環境系のサービスであり、最も活用されるのはIaaSであるGCEです。この上でさまざまなアプリケーションやミドルウェアなどを構築します。

　一般的なクラウドサービスやオンプレミスシステムと比較した時の優位点は、まず他のクラウドサービスに比べて安価に使える点と、ライブマイグレーションという技術により、Google社が　無停止でハードウェアなどのメンテナンスを行ってくれる点にあります。その間ユーザは何らかの作業を行う必要があるどころかメンテナンスに気付くこともないでしょう。

　通常、クラウド・オンプレミスの利用者は、ハードウェアやOSなどの保守メンテナンスのために一定の期間毎にメンテナンス停止や再起動の必要などが必要です。運悪くDB系のインスタンスにメンテナンスが発生した場合などには、ゲームのユーザが利用できなくなるのみならず、インフラ側も大掛かりな対応が必要になります。しかし、GCEのライブマイグレーションの技術を使えば、これらのメンテナンスなしでサービスを継続させることが可能となります。

　またGCEも他のクラウドサービスと同じく、データセンタにリージョン（地域）の概念がありますが、GCEでは世界中に展開されたGoogle社の専用網を活用することで、これらのリージョンをまたがって簡単に高速なプライベートネットワークを構築できることが大きなメリットです。グローバルで展開するようなゲームインフラを構築する場合にはヨーロッパや北米、アジアなどの各データセンタ上にインフラを構築し、VPNなどでその拠点を構築することが多いかと思いますが、GCEを活用すればそういった手間やコスト、障害要素を極小化してインフラを構築することが可能になります。

Google App Engine

　ゲームインフラという観点では、GAEはHTTP（S）通信をベースとしたゲームに使うサービスです。GAEは非常にスケーラビリティの高いサービスですが、レイテンシの関係でリアルタイム性の高いサービスに関しては適用が難しいケースもあります。しかしながら、例えばパズルゲームなどリアルタイム通信の必要性の低いゲームで活用すると、メンテナンス性やスケーラビリティの観点で非常に高い効果を発揮します。

　一度アプリケーションをデプロイしてしまえば、後は負荷に応じて自動的にスケール（Go言語の場合数十ミリ秒でコンテナが追加起動）し、ピークが過ぎると自動的に縮退します。そのためメンテナンスもほぼ不要で、利用量に応じてのみ課金され、流行り廃りのあるゲームにおいて極めて投資対効果の高いインフラ投資を行うことができます。

　またゲームのランディングページでもそのスケーラブルな特性を存分に活かす事ができ、一度構築してしまえば計画停止はなく、ミドルウェアまでのメンテナンスも不要で、かつ非常に安価に使用することができます。

Google Container Engine

　GKEはDockerコンテナの管理サービスですが、コンテナ自体がまだゲームインフラマーケットの中では普及しておらず、自ずと開発環境のセットアップなど利用用途はまだ限られているようです。しかしながらマイクロサービス指向アーキテクチャへの期待の高まりやマルチクラウドの潮流、環境のポータビリティが重要視されつつある現在において、コンテナ技術はこれから増々重要になってくるでしょう。

ストレージサービス

Cloud SQL Second Generation

　高性能なマネージドのRDBMSです。ゲームインフラでは各種ゲームデータのDBとして活用できます。

Google Cloud Storage

　GCSはオブジェクトストレージサービスですが、Amazon社のS3などのオブジェクトストレージと比較すると価格が安くまた概してアップロード/ダウンロードの速度が速いです。ゲームインフラという観点では静的コンテンツのWebサーバとして活用できます。この利用方法でのGCSの特徴は「エッジキャッシュ」というコンテンツのキャシュ機能です。これは多くアクセスされるコンテンツをGoogleのエッジキャッシュでキャッシュし、オリジナルコンテンツへのアクセスを行わないため、CDN（Content Delivery Network）に類した使い方ができることがあります。

　キャッシュされたコンテンツにもオリジナルアクセスと同様の課金が発生するため、キャッシュによるコスト削減目的の使い方はできませんが、構成によってはCDNサービスを削減、もしくは無くしてしまうことでコストを削減できる可能性があります。

Google Cloud Storage Nearline

　NearlineはAmazon Glacierのようなアーカイブサービスですが一般的なコールドストレージサービスであれば取り出しに数時間程度かかるところが数秒でデータ取り出し可能なところが大きな特徴です。リアルタイムではなくコールドストレージですので、ゲームインフラそのものとしての活用ではなく、各種データやコンテンツのアーカイブ・バックアップなどの用途に適しています。特に過去のゲームリソースのアーカイブ用途に活用すると、過去のゲームタイトルの動画や画像ファイルなどを少し引き出して参照する、といった際に簡単に取り出すことが可能となります。即ち高速、低コスト、高可用性、ディザスタリカバリなどを同時に実現できます。これは他のコールドストレージサービスと比較して極めて大きな優位点になります。

Cloud DatastoreとCloud Bigtable

　DatastoreとBigtableは共にNoSQLのマネージドサービスで、RDBMSでは処理が難しい大量のデータやアクセスに対して使用されます。DatastoreはBigtableの上に構築されており、複数行にまたがったトランザクションなどの高度なデータベース機能を利用可能です。

　2つのサービスの使い分けですが、高度なデータベース機能を使いたい場合にはDatastoreを利用し、Bigtableはより性能が要求される場合で利用されます。

ネットワークサービス

ロードバランシング

　ロードバランシングはトラフィックが多いゲームインフラでは極めて重要なサービスです。GCPのロードバランシングは一般的なクラウドサービスでのロードバランサのように負荷に応じて都度インスタンスを起動するのではなく、Google社の各サービスが共用で使用しているロードバランシングの仕組みをそのまま使えるため極めて負荷への耐性が強く、例えば急に秒間100万リクエストというレベルのアクセスがあったとしても特別な対応を行う必要がありません。

　そのため運用・メンテナンスの作業を減らすことが可能です。またAnycastという仕組みにより、DNSラウンドロビンを使わなくても同一のグローバルIPでリージョン間のロードバランシングを行うことが可能です。

キャッシュサービス

　GCPではAWSにおけるCloudFrontにあたるサービスを持っていませんが、HTTP(S)ロードバランシング、GCS、GAEではエッジキャッシュを利用することができます。

　エッジキャッシュはベストエフォートサービスでありキャッシュコンテンツの細やかな制御が行えないため、AkamaiやCloudFrontなどのCDNを100%置き換えることは難しいと思われますが、追加の費用なく利用できるため、上手く活用すれば構成をシンプル化したり一部のコスト削減を行える可能性があります。

　またCDNについては、GoogleとAkamaiなどのCDNベンダがネットワークをダイレクト接続し、協業しているためネットワーク品質が向上したり、GCPサービスからAkamaiへのダウンロードコストが割引になる効果もあります。

データ処理サービス

BigQuery

　大量データを処理するためのマネージドのOLAP/DWHサービスです。ほぼSQLと同等の構文で何十億件という量のデータを処理することが可能です。一般的なOLAP/DWHエンジンと異なる点は、処理量に上限がなく、データをアップロードしてしまえばチューニングは不要で数万件でも数百億件でも10秒程度の応答速度で分析を行える点にあります。ゲームインフラという観点では、各種ログの調査、DAUやARPUなどのKPIの算出、ゲームプランナー・運営者によるユーザのアクションログ・アプリケーションログ分析などに活用できます。

Cloud DataflowとCloud Dataproc

　DataprocはHadoop/Sparkのマネージドサービスです。DataflowはGoogle提供のAPIでHadoop/Sparkのような大量データバッチ処理やストリーム処理を行うためのプラットフォームです。ゲームでは分析系での大量データ処理に使われることがあります。

　BigQueryとの使い分けとしてはETL（データ整形処理）やストリーム処理、機械学習等の複雑な分析ロジックの実行にはDataflowやDataprocを使い、データマート・集計処理にはBigQueryを使うイメージになります。しかしBigQueryのデータ処理能力のカバレッジが広いため複雑なETL処理を行うのでなければDataflowやDataprocを使う機会は少ないかもしれません。

Cloud Pub/Sub

　Cloud Pub/Subは高可用なMQサービスです。非同期処理全般で活用できますが、ゲームにおける利用用途としてはチャットやバッチ処理、ログメッセージの送受信といったケースが考えられます。ただしログ分析のアーキテクチャとしては「fluentd + BigQuery」という組合せがデファクトスタンダードとなっており、fluentdの方が無償で使え、また構築コストも低いため単純な要件であればこちらの方がよいでしょう。

その他

　Translate API、Prediction API、Endpointsはあまり汎用的にゲームインフラとして使われる事はないでしょう。

　Translate APIに関しては例えばゲーム中でのチャットを翻訳するなどの用途では使えるかも知れません。ただしあくまで機械翻訳ですので「簡易チャット翻訳」レベルとしてとらえておいた方がよいでしょう。

　EndpointsはバックエンドがGAEですのでプラットフォームとしての特性はGAEの項を参照下さい。シンプルなゲームや、クライアント処理がメインでスコアなどのプレイヤ情報をやりするレベルであれば開発生産性に貢献できる可能性があります。

「書籍転載」