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

» 2016年04月20日 05時00分公開

一般的なクラウドサービスとGoogle Cloud Platformの比較

ネットワーク

　ネットワークはGoogleクラウドの根幹を成すものであり、GCPユーザが直接的にメリットを享受できる要素でも有ります。本項ではGCPのネットワークに関連するメリットについて説明します。

●リージョンを超えたプライベートネットワーク

　アジアとヨーロッパ、北米をまたがったプライベートネットワークを組みたい場合、一般的にはVPNを経由して行う必要があります。一方、GCPではリージョンをまたがったプライベートネットワークをデフォルトの状態で構成することが可能です。これを可能にしているのは以下の2点です。

リージョンを超え世界中に張り巡らされたGoogle自社のネットワーク網
AndromedaネットワークのSDN（「データセンターネットワークに対するGoogleの取り組み - 最新世代のJupiterを紹介」）

　グローバルなゲームタイトルなどでリージョンをまたがったプライベートネットワークを構成する場合、GCPを使うとコスト面、速度面、運用容易性、障害性など多くのメリットを享受することが可能です。

●速度

　GCPはサービス内の通信も高速で安定しています。特にリージョンをまたがった通信に関してはGoogle専用網で通信が行える分、GCPの通信は顕著に高速です。また多くのネットワークベンダがGoogleのネットワーク網に直結しているためインターネットを経由する通信もホップ数が少なく相対的に安定・高速な通信が期待できるでしょう。

●安定性

　一般的なクラウドサービスでは、負荷をかけていくと負荷に応じてレスポンス性能は少しずつ劣化し、レイテンシのばらつきは大きくなっていく事が多いのですが、GCPはネットワークが安定しており性能の劣化が小さいのが特徴です。

　筆者が知るゲーム会社がテストした結果によると、ネットワーク性能に関してゲームをプレイヤが快適に遊べるかどうかは、ネットワークレイテンシそのものもありますが、むしろそのばらつき度合いに影響を受けるようです。たとえばレイテンシの平均値が小さくても、そのばらつきが大きければプレイヤはむしろパフォーマンスの悪いゲーム、という風に感じる傾向があるようです。

　GCPはこのネットワークレイテンシのばらつきやネットワーク性能劣化が小さいため、高負荷下のゲームであってもより高品質なユーザ体験を提供することができます。

●ロードバランサ

　GCPのロードバランシングは非常に強力で、事前の準備やウォーミングアップなくいきなり秒間100万リクエストがあっても処理可能です。これはGoogle社のgoogle.com検索など、他のサービスと同じロードバランサを使っているから実現可能なことであり、秒間100万リクエストも上限値ではなく検証値であって理論上はもっと多くのアクセスを処理できるでしょう。

　このGCPのロードバランシングを使うことでサイジングや運用にかける工数を極小化し、エンドユーザへの可用性の向上と運用工数の削減を同時に実現することが可能となります。

●グローバルロードバランシング（IPベースのロードバランシング）

　GCPではIPベースのロードバランシングを行うことができます。例えばあるグローバルIPにアクセスする時に北米からアクセスすると北米のデータセンタ、ヨーロッパからアクセスするとヨーロッパ、というかたちでアクセス元に近いデータセンタにルーティングするとこが可能です。これはGoogle Public DNSの「8.8.8.8」と「8.8.4.4」と同様の仕組みで、BGPによる経路情報がリージョンによって異なる運用をできる仕組みになっているため可能となっている機能です。

　グローバルで展開するゲームであれば、DNSの仕組みに依存せずに、地球規模で単一のグローバルIPによってリージョン間フェイルオーバーとロードバランシングを実現できることがメリットとなるでしょう。

VM

●起動速度

　GCEは、インスタンスの起動速度が速いというのが一つの大きな特徴です。インスタンスの数やリージョンに依らず、概ね30秒～40秒程度でインスタンスを起動できます。ゲームインフラにおける優位性は以下の通りです。

エンジニアの開発生産性の向上
インスタンスの起動が速いためゲームの特性によっては、トラフィックのピークにあわせて必要な時に立ち上げる・オートスケールさせるという運用設計がとれる

●インスタンスごとの品質ばらつき

　クラウドサービスでは同じサービスを使っていても各インスタンスのスペックが異なることがあり、目的のスペックをもつインスタンスを引き当てるのは運に頼る他なく、いわゆる「インスタンスガチャ」と呼ばれるスペックのばらつきが生じることがあります。

　GCPはインスタンス毎のこの性能のばらつきが非常に少なく、インスタンス毎の性能が均一だと言われています。また後述のライブマイグレーションの仕組みにより、少しずつ無停止で基盤スペックを入れ替えていくため、インスタンスガチャ自体が本質的に不要です。

　ただしGCPにおいてもリージョンによって提供されているCPU型番などが微妙に異なっていることもあるので注意が必要です。なお、どのリージョンでどういうマシンスペックのインスタンが作れるかについては公開されています（https://cloud.google.com/compute/docs/zones）。

ライブマイグレーション

　ライブマイグレーションはGCEにおいて最も差別化要因になる機能と言っても過言はないかもしれません。ライブマイグレーションとはハードウェアやホストOSなどのメンテナンスが発生した際にインスタンスを稼働させたまま、同一ゾーン内の別のサーバへ自動的に移動してくれる仕組みです。要はパッチ当てやハードウェア交換の際に計画停止やインスタンスの再起動を行わなくてすむようにしてくれる機能です。

　例えば2014年に公表されたOpenSSLの致命的な脆弱性である「Heartbleed」への対応の際も、他社クラウドではハイパーバイザなどへのパッチ適用のための再起動が多数発生したのに対し、GCPではライブマイグレーションによってGCEユーザにはほぼ何の影響もなくハイパーバイザなどへのパッチ適用対応を終えることができています（「ライブマイグレーションを使い、Google Compute Engineにダウンタイムのないサービスインフラストラクチャーを」）。

　ライブマイグレーションの仕組みの概要は以下の通りですが、ポイントはいかにブラックアウト期間（アクセス不能期間）を短くし、稼働しているアプリケーションに影響を与えずにVMを移動させるかです。

ライブマイグレーションの仕組み

　GCEのライブマイグレーションの仕組みはGoogle社によって公開されており、その処理の概要は以下の通りです（「ライブマイグレーションを使い、Google Compute Engineにダウンタイムのないサービスインフラストラクチャーを」）。

Step1．（A）を稼働させたままメモリのデータ等を（B）にコピーする
Step2．（A）の全ての動作を一瞬だけ停止し、Step1との更新差分を（B）にコピーする
Step3．（A）は移行後も存続しStep2の期間に受け取ったネットワークパケットを（B）に転送する
Step4．（A）を廃棄する

　ライブマイグレーションを実施するクラウドベンダはGoogle社以外にもありますが、大きく異なる点はその切り替えのシームレスさにあります。ライブマイグレーションといっても、一般的には1秒程度のブラックアウト期間が発生します。GCPはそのブラックアウト期間がより短く、ライブマイグレーション実施中に受け取ったパケットは移行後のVMに届けるため、パケットのロスがありません。またライブマイグレーションの安定性も一般的なライブマイグレーションの仕組みと比較して極めて高いと言われています。

　Rightscale社が行ったライブマイグレーションのテストでも、ライブマイグレーションの実行自体をほとんど認識できないレベルであったそうです（「ライブマイグレーションを使い、Google Compute Engineにダウンタイムのないサービスインフラストラクチャーを」）。これはGCE上に構築したデータベースに対して高負荷なトランザクションをかけている状態で明示的にライブマイグレーションを実行し実施後のVMをチェックするものでしたが、データの整合性はもちろんログファイルをチェックしてもGoogle社からの説明がなければライブマイグレーションが実施されたことを認識できなかったといいます。

　以下はテストを行ったRightscale社のコメントです。

「ログファイルを調べましたが、データベースの中の全データは……まったく異常ありません。もしインスタンスがマイグレートされていたことをGoogleが教えてくれていなかったとしたら、まったくわかりませんでした。すべてのログとデータは正常ですし、RightScaleのクラウド管理ダッシュボードには、ゾーン、インスタンスのサイズ、IP アドレス、リソースなど、いずれも変化はありませんでした」。

料金

　各クラウドサービスの機能性や品質が向上し汎用的なユースケースにおいてコモディティ化されてくると、コストはより重要な検討項目の一つとなってきます。GCPはその機能性や品質はもちろん、コスト面でも単価・支払い柔軟性の観点でも非常に使いやすい設定になっています。

●一分単位の課金

　GCPの課金単位は最低10分間の料金が課金され、それ以降は1分単位の課金となります。これにより開発、テストやバッチジョブなどのコストを抑えることが可能です。

●自動的に適用される割引と柔軟な価格体系

　GCPの割引には複数年契約や前払いによる割引の概念はなく、非常にシンプルです。GCPでは各VMの利用期間に応じて月ごとに自動的に割引が適用されます。具体的には月単位でサーバの稼働時間に応じて以下の割引率が自動適用されます。


0-25％ / 月の日数	正規料金の100％
25-50％ / 月の日数	正規料金の80％
50-75％ / 月の日数	正規料金の60％
75-100％ / 月の日数	正規料金の40％

　例えばあるVMインスタンスの1ヶ月（30日）の延べ起動日数が22.5日だとすると各期間による割引率は以下の通りとなります。

0日目～7.5日目まで・・・100％の課金
7.5日目～15日目まで・・・80％の課金
15日目～22.5日目まで・・・60％の課金

　この場合100％、80％、60％の利用日数に応じて課金を計算すると80％が支払い率となり、すなわち20％の割引と等しくなります。

　商用環境であれば通常立ち上げっぱなしであるため、上表の100％、80％、60％、40％の加重平均である70％が支払い率となり、すなわち定価の30％の割引が自動適用されたことになります。また複数の同じタイプのインスタンスを並行して稼働させていた場合、各々のインスタンスは断続的な使用であったとしても全体としての継続利用に対して割引が適用されるため無駄が少なくてすみます（詳細はGCPのドキュメントの「Inferred instances」の項を参照）。

　このように長期間にわたる利用コミットや先払いの必要がなく、割引が自動適用されるということは予算立案や管理の観点でプロジェクトの柔軟性を上げ、ベンダロックインのリスクを下げるのに大きな効果があります。

●Preemptible VM

　Preemptible VMは少し特殊なVMで70％割引で利用することが可能です。その特徴は以下の通りです。

最長24時間までしか稼働できない
24時間以内であっても連続稼働時間に保証はない
ライブマイグレーションは機能しない
その他は通常のVMと同じ

　こちらはAWSのスポットインスタンスのようにオークション形式ではなく、固定で70％オフとなっています。

　使い方としてはバッチサーバなど万が一落ちても再起動できればよいという割り切った用途や、負荷テストなどの各種テストで活用すればコスト的に大きなメリットがあるでしょう。またピーク時のフロントサーバなどで使うことも可能かも知れません。ただしPreemptible VMはあくまで該当ゾーンにおける余剰リソースを安価に提供しているサービスであり必要な時に必ず使えるとは限らない点には注意が必要です。

●カスタムマシンタイプ

　GCPではインスタンスを作成する際にコア数やメモリサイズを下限上限の範囲でサイズを自由に設定することができます。

　例えばCPUパワーだけが欲しくメモリはあまり不要といったケースに非常に有効です。あるいはサイジング上は12vCPU程度のCPU性能でよい場合には、8vCPUでは少なく16vCPUでは多いといった悩みもあると思います。こういった場合にカスタムマシンタイプを使うと性能要件に応じたインスタンスを構成することができます。この機能によって要求性能とプリセットインスタンスのサイズのミスマッチによる無駄なコストを削減することが可能となります。

　またこういったカスタムマシンタイプを利用する際には、サービス開始初期にはやや安全圏で高性能なインスタンスを利用し、負荷の推移に応じて柔軟にスケールダウンしていける点もGCPの強みです。

ユーザビリティ

　GCPは、エンジニアが大多数を占めているGoogle社から後発のサービスとして提供されたサービスということもあり、エンジニアにとっての使い勝手に関して評判の高いサービスです。

　GCPはそもそも高レイヤのマネージドのサービスを数多く提供するよりも、良質なコンピューティング素材を提供する事に長けているサービスであり、その素材を上手く料理できる環境をいかに用意できるのかがサービスの要でもあります。以下に開発生産性を向上させる便利な機能の例を紹介します。


サービス名	概要
アカウント管理	GCPはユーザ管理にGoogleアカウントを使用する仕組みになっている。そのアカウントに同期するかたちでsshのアカウントやキーが発行されるため、VMを作成後すぐにsshでログインすることが可能。
コマンドラインツール	gcloudコマンドラインからVMの各種操作をはじめとした細やかな設定を行うことができる。
Google Cloud Shell	ブラウザ上からVMにシェルでログインすることができる。これによりリモートログイン用の環境がなくてもブラウザさえあればVMにログインし操作することが可能。
メタタグ	インスタンスの各種メタ情報（ホスト名、IP、コンポーネント構成、イメージ名、起動スクリプトなど）を管理する仕組みがあり、ファイアウォールの設定や構成スクリプトを容易に管理することが可能。
GCPでの便利な管理のための仕組み

ゲームインフラにおけるGoogle Cloud Platformの課題

　ここまでGCPの特徴について紹介してきましたが、ではGCPを活用する上での障壁になる点について紹介します。

●書籍やWeb上での日本語での情報

　GCPは日本語での書籍やWeb上でのコンテンツが少なく、Google社が提供している公式ドキュメントも英語のものが多いのが現状です。こうした点は長い目で見れば改善されていくと思われますが、クラウド初心者が少し触ってみようという際には障壁になるかも知れません。

●ハードウェアをベースにしたチューニング

　さまざまなクラウドベンダで高性能なサービスはリリースされていますが、あるレベルを超えたチューニングを行いたい場合には「オンプレミス+Fusion-io」のようなハードウェアレベルの高速化はやはりクラウドでは難しいことが多いです。

　GCPでも極めて高性能なローカルSSD(4kbのランダムリードで68万QPS)の利用は可能ですが、ディスク自体の冗長化は行われていないためミドルウェア側でレプリケーションを意識した設計を行う必要があります（https://cloud.google.com/compute/docs/disks/local-ssd）。

●マネージドサービスの種類

　ゲームインフラという観点では、GCPには必要なコンポーネントは一通り存在していますが、マネージドサービスではまだ提供されていないサービスがあります。例えばAWSでいうところのCloudFrontやElastiCacheと同等のサービスはGCPではまだ提供されていないため、自社で構築する必要があります。マネージドサービスをフル活用してインフラ構築を行っている場合には障壁になる可能性があります。

●比較まとめ

　以下にこれまで解説した、他のクラウドとGCPとの比較についてまとめます。


GCPの強み	GCP利用にあたって注意すべき点
◯コスト優位性 - 価格優位性 - 料金体系の柔軟性 ◯高可用性（ライブマイグレーション） - 基本的に計画停止は無し ◯高いスケーラビリティ - グローバルプライベートネットワーク - 強力なグローバルロードバランサ ◯高品質・高性能 - インスタンスが高品質で起動が速い - ネットワークが高品質で高性能 ◯高い開発生産性 - 利便性の高い開発ツール群	◯AWSなどと比較して日本語の情報や書籍が少ない ◯ハードウェアレベルの細かなチューニングができないため、一定以上のIOが必要な場合、シャーディングやローカルSSD活用など工夫して設計する必要がある ◯ELBやElastiCacheなど一部で対応するマネージドサービスが存在しないものが存在し、Akamaiなどのサードパーティサービスを使ったり自前で構築する必要がある