この記事では、Compute Engine リソースに使用する Google Cloud リージョンを選択する際に考慮すべき基準について説明します。この決定は一般にクラウド アーキテクトやエンジニアリング管理部門が行います。このドキュメントは主に選択プロセスのレイテンシの側面に焦点を当てており、モバイルアプリ、ウェブアプリ、ゲームなどのエンドユーザーが利用するアプリを対象としていますが、そのコンセプトの多くは他のユースケースにも適用できます。
Google は、Compute Engine リソースをデプロイするため、世界各地に複数のリージョンを提供しています。リージョンの選択に影響を与える要因には次のようなものがあります。
- リージョンに固有の制限
- リージョンによるユーザー レイテンシ
- アプリのレイテンシ要件
- レイテンシをどの程度制御できるか
- 低レイテンシとシンプルさのバランス
用語
- リージョン
- デベロッパーのリソースを実行する独立した地理的地域。各リージョンはゾーンで構成されており、通常は少なくとも 3 つのゾーンがあります。
- ゾーン
- リージョン内の Google Cloud リソースのデプロイエリア。リージョン内の異なるゾーンにリソースを置くと、すべてのリソースに同時に影響するインフラストラクチャ停止のリスクを軽減できます。
- Compute Engine リソース
- 仮想マシン インスタンスなどの Compute Engine リソースは、リージョン内のゾーンにデプロイされます。Google Kubernetes Engine や Dataflow などのプロダクトは Compute Engine リソースを使用するため、同じリージョンやゾーンにデプロイできます。
- ラウンドトリップ時間（RTT）
- IP パケットを送信してから確認応答を受信するまでの時間。
Compute Engine リージョンをいつ選択するか
アプリのアーキテクチャ フェーズの早い段階で、どの Compute Engine リージョンをいくつ使用するかを決定します。リージョンの選択は、たとえば次のようにアプリに影響を与える可能性があります。
- 同じユーザーが異なる時点で異なるリージョンから接続できるため、複数のコピー間でデータを同期させる場合、アプリのアーキテクチャが変わる可能性があります。
- 価格はリージョンによって異なります。
- アプリとそのデータをリージョン間で移動するプロセスは煩雑であり、多額のコストがかかる場合もあるため、アプリの公開後は避ける方が安全です。
リージョンを選択する際に考慮すべき要因
ほとんどの人は自分が所在しているリージョンにデプロイしがちですが、それにより最良のユーザー エクスペリエンスが得られるとは限りません。たとえば、グローバルなユーザーベースを持つヨーロッパの企業が単一のリージョンにデプロイしようとしているとします。このようなケースでは、ほとんどの場合、ヨーロッパのリージョンにデプロイすることが検討されますが、他のリージョンとの接続数が最も多いのは米国なので、通常はいずれかの米国リージョンでアプリをホストするのが最適です。
アプリのデプロイ場所に影響を与える要因は複数存在します。
レイテンシ
考慮すべき主な要因は、ユーザーが体感するレイテンシです。しかし、ユーザー レイテンシはキャッシュや負荷分散メカニズムなどの複数の側面によって影響を受けるため、これは複雑な問題です。
エンタープライズ ユースケースでは、オンプレミス システムへのレイテンシ、またはある一部のユーザーやパートナーが体感するレイテンシがより重要な検討事項になります。たとえば、デベロッパーに最も近いリージョン、または Google Cloud と相互接続されたオンプレミス データベース サービスに最も近いリージョンを選択することが決め手となる場合があります。
料金
Google Cloud リソースの費用はリージョンによって異なります。次のリソースを使用して料金を見積もることができます。
複数のリージョンにデプロイする場合は、リージョン間で同期されるデータに対してネットワーク下り（外向き）の料金がかかることに注意してください。
他の Google Cloud サービスとのコロケーション
可能であれば、Compute Engine リソースを他の Google Cloud サービスとコロケーションを行います。レイテンシの影響を受けやすいサービスはすべてのリージョンで使用できますが、中には特定のロケーションでしか使用できないサービスもあります。
マシンタイプの利用可能性
すべてのリージョンですべての CPU プラットフォームとマシンタイプが利用できるわけではありません。特定の CPU プラットフォームまたは特定のインスタンス タイプを利用できるかどうかはリージョンによって異なり、ゾーンによって異なることもあります。特定のマシンタイプを使用してリソースをデプロイする場合は、それらのリソースがゾーンで使用できるかどうかを確認してください。
リソースの割り当て
Compute Engine リソースのデプロイ量はリージョン別のリソースの割り当てによって制限されるため、デプロイを予定しているリージョンの十分な割り当て量をリクエストしてください。特に大規模なデプロイを計画している場合は、早めにセールスチームに連絡してリージョンの選択について話し合い、十分な割り当て量を確保してください。
カーボンフリー エネルギー パーセンテージ
Google Cloud の各リージョンに電力を供給するために、Google はリージョンが配置されている電力網からの電力を使用しています。この電力の生産では、電力網内の発電所の種類や Google が消費する時期に応じて程度の差はありますが、炭素が排出されます。Google では 2030 年までに、すべての Google Cloud リージョンで 1 日 24 時間、アプリケーションに必要な電力をカーボンフリーの電力で調達するという目標を設定しています。
この目標を達成するまで、各 Google Cloud リージョンでは、1 時間ごとにカーボンベースとカーボンフリーのエネルギー源から混合して電力が供給されます。この指標をカーボンフリー エネルギー パーセンテージ（CFE%）と呼び、Google Cloud リージョンでは CFE% を公開しています。Google Cloud の新しいアプリケーションの場合は、この表を使用して、アーキテクチャの決定に二酸化炭素の影響を組み入れることができます。CFE % が高いリージョンを選択すると、平均で、アプリケーションの実行時にカーボンフリー エネルギーの割合が増加し、そのアプリケーションの総二酸化炭素排出量が削減されます。
レイテンシ要件を評価する
ユーザー レイテンシが長くなるとユーザー エクスペリエンスの低下につながる可能性があるため、レイテンシはしばしばリージョン選択において重要な考慮事項となります。レイテンシの一部の側面はデベロッパー側でコントロールできますが、デベロッパー側ではどうにもならない面もあります。
レイテンシを最適化するとき、多くのシステム アーキテクトはネットワーク レイテンシ、またはユーザーの ISP と仮想マシン インスタンスとの距離のみを考慮します。ただし、次の図からわかるように、これはユーザー レイテンシに影響する多くの要因の 1 つにすぎません。
アプリ アーキテクトは、リージョンの選択とアプリのレイテンシは最適化できますが、ユーザーのラストマイルと、最も近い Google のエッジ接続拠点（POP）へのレイテンシをコントロールすることはできません。
リージョンの選択は、レイテンシ全体ではなく、Compute Engine リージョンへのレイテンシにのみ影響します。ユースケースによっては、これはレイテンシ全体のほんの一部である場合があります。たとえば、ユーザーが主にモバイル ネットワークを使用している場合、リージョンの最適化を試みることは無駄である可能性があります。これはユーザーの全体的なレイテンシにほとんど影響しないためです。
ラストマイルのレイテンシ
このセグメントのレイテンシは、インターネットへのアクセスに使用される技術によって異なります。たとえば、最新のネットワークの場合、ISP に到達するまでの標準的なレイテンシは 1～10 ミリ秒です。逆に、3G モバイル ネットワークの一標準的なレイテンシは 100～500 ミリ秒、DSL プロバイダとケーブル プロバイダのレイテンシは約 10～60 ミリ秒です。
Google フロントエンドおよびエッジ POP のレイテンシ
デプロイモデルによっては、Google のネットワーク エッジへのレイテンシも重要です。グローバル負荷分散プロダクトはここで TCP セッションや SSL セッションを終端し、Cloud CDN はキャッシュに保存された結果をここから配信します。提供するコンテンツにもよりますが、最終的に取得しなければならないのはデータのほんの一部だけなので、多くのラウンドトリップはここで早くも終了する可能性があります。スタンダード ネットワーク サービス階層を使用すると、このレイテンシが大幅に高くなる可能性があります。
Compute Engine リージョンのレイテンシ
ユーザー リクエストはエッジ POP から Google のネットワークに入ります。Compute Engine リージョンは、リクエストを処理する Google Cloud リソースが存在する場所です。このセグメントはエッジ POP と Compute Engine リージョン間のレイテンシを表し、Google のグローバル ネットワーク内部で発生するものです。
アプリのレイテンシ
これはリクエストに対するアプリの応答によって生じるレイテンシであり、アプリがリクエストの処理に要する時間が含まれます。
レイテンシ要件はアプリによって異なります。レイテンシの問題がユーザーにとってそれほど重要視されないアプリもあります。非同期にやり取りするアプリや 100 ミリ秒以上の長いレイテンシしきい値を持つモバイルアプリは、単一のリージョンにデプロイしてもユーザー エクスペリエンスは損なわれない可能性があります。しかし、リアルタイム ゲームのようなアプリでは、数ミリ秒のレイテンシでもユーザー エクスペリエンスに大きな影響を及ぼす可能性があります。このようなタイプのアプリはユーザーに近い複数のリージョンにデプロイします。
グローバルなデプロイ パターン
このセクションでは、さまざまなデプロイモデルがレイテンシ要因にどのように影響するかについて説明します。
単一リージョンへのデプロイ
次の図は、単一リージョンへのデプロイを示しています。
アプリがグローバルなユーザーベースを持つ場合でも、多くの場合、単一のリージョンが最良の選択です。マルチリージョン デプロイにはレイテンシが低いという利点がありますが、その管理の複雑さという欠点を補うほどのメリットはないかもしれません。単一リージョンへのデプロイであっても、Cloud CDN やグローバル負荷分散などの最適化手法を使用してユーザー レイテンシを短縮することは可能です。バックアップや障害復旧の理由で 2 つ目のリージョンを使用することもできますが、これはアプリのサービス提供パスには影響しないため、ユーザー レイテンシには影響しません。
複数のリージョンの分散フロントエンドと単一リージョンのバックエンド
次の図は、複数のリージョンにフロントエンドを分散し、バックエンドを単一リージョンに限定するデプロイモデルを示しています。このモデルには、フロントエンド サーバーへのレイテンシが短縮されるとともに、複数のリージョン間でデータを同期する必要がないという利点があります。
このデプロイモデルの場合、平均的なユーザー リクエストが、アプリが結果を得るまでに中央のバックエンドに対してデータ要求をほとんどまたはまったく行わない場合、ユーザー レイテンシが低下します。たとえば、フロントエンドにインテリジェントなキャッシュ レイヤをデプロイしているアプリや、データの書き込みを非同期に処理するアプリが該当します。バックエンドへの完全なラウンドトリップが必要なアプリの場合、このモデルを使用するメリットはありません。
フロントエンドとバックエンドの複数リージョンへの分散
フロントエンドとバックエンドを複数のリージョンに分散させるデプロイモデルを使用すると、アプリのリクエストに対する応答処理をローカルで完結できるため、ユーザー レイテンシを最小限に抑えることができます。ただし、このモデルでは、すべてのデータをローカルに保存してアクセスできるようにしなければならないため、複雑さが増します。すべてのユーザー リクエストに応答するため、すべてのリージョン間でデータを完全に複製する必要があります。
グローバルに一貫したマネージド データベースである Cloud Spanner には、3 大陸のマルチリージョン オプションがあります。このオプションでは、米国の読み書きレプリカに加えて、ヨーロッパとアジアに 2 つのリードレプリカ（読み取りレプリカ）が配置されます。このオプションは、米国、ヨーロッパ、アジアにあるコンピューティング インスタンスに対する低レイテンシのデータ読み取りアクセスを提供します。サービスの対象地域が米国である場合は、米国内でレプリケーションを行うマルチリージョン オプションもあります。
Compute Engine でデベロッパー独自のデータベース サービスを実行する場合は、データを独力で複製する必要があります。世界中のデータを一貫して同期させることは非常に難しいため、このレプリケーションは大仕事です。1 つのリージョンのみで非同期書き込みによってデータベースへの書き込みを行い、他のリージョンではそのデータベースの読み取り専用レプリカをホストする方が管理は楽です。
リージョン間でのデータベースの複製は難しいため、この分野の経験が豊富な強力なパートナー（Cassandra レプリケーションの Datastax など）に協力を求めることをおすすめします。
複数の並列アプリ
アプリの性質によっては、前述の方法のバリエーションを使用して、データの常時レプリケーションの必要性を低減するとともに、低いユーザー レイテンシを維持できます。次の図に示す複数の並列アプリは、そのすべてがフロントエンドとバックエンドで構成されており、ユーザーは正しいアプリに振り向けられます。サイト間で共有されているデータはほんの一部だけです。
たとえば、小売ビジネスを営む場合、異なる国のドメインを通じて異なるリージョンでユーザーにサービスを提供し、必要なときにのみ製品やユーザーのデータを同期しながら、それらすべてのリージョンで並列サイトを運営できます。ローカルサイトではローカルの在庫状況を管理し、ユーザーは国のドメインを選択することでローカルにホストされたサイトに接続します。別の国のドメインにアクセスしたユーザーは、正しいドメインにリダイレクトされます。
別の例はリアルタイム ゲームです。たとえば、ロビーサービスのみをグローバルに提供してユーザーに自分のロケーションに近いゲームルームやゲームワールドを選択してもらい、ゲームルームやゲームワールド間でデータを共有しないようにすることができます。
3 つ目の例は、異なるリージョンでの SaaS（Software-as-a-Service）の提供です。データの場所は、アカウントの作成時にユーザーのロケーションまたはユーザーの選択に基づいて決定します。ログインしたユーザーはロケーションに固有のサブドメインにリダイレクトされ、該当するリージョンのサービスを使用します。
ユーザーとリージョン間のレイテンシを最適化する
どのデプロイモデルを使用するかにかかわらず、最適化手法を組み合わせて、エンドユーザーが体感するレイテンシを短縮できます。これらの手法のいくつかは Google Cloud の機能ですが、Google Cloud 以外の手法ではアプリに変更を加える必要があります。
プレミアム ティア ネットワーキングを使用する
Google は、プレミアム（デフォルト）とスタンダードのネットワーク サービス階層を提供しています。スタンダード ティアのトラフィックは Google Cloud リージョンから複数のトランジット ISP を経由して配信されるのに対し、プレミアム ティアは、Google のグローバルなプライベート ファイバー ネットワークを通じてトラフィックを配信することで低レイテンシを実現します。プレミアム ティア ネットワーキングはユーザー レイテンシを短縮するため、アプリのサービス提供パスのすべての部分で使用することをおすすめします。また、Google のグローバル負荷分散プロダクトを使用するときにも、プレミアム階層ネットワーキングは不可欠です。
Cloud Load Balancing と Cloud CDN を使用する
HTTP(S) 負荷分散、TCP、SSL プロキシ負荷分散などの Cloud Load Balancing を使用すると、バックエンドの処理能力に余裕のある最も近いリージョンにユーザーを自動的にリダイレクトできます。
TCP および SSL セッションはネットワーク エッジで終端されるため、アプリが単一のリージョンにのみ存在する場合でも、Cloud Load Balancing を使用するとユーザー レイテンシが短縮されます。HTTP/2 や QUIC（Quick UDP Internet Connections）を使用すると、ユーザー トラフィックを簡単に終了できます。また、Cloud CDN を HTTP(S) 負荷分散と統合してネットワーク エッジから直接静的アセットを配信することで、ユーザー レイテンシをさらに短縮することもできます。
ローカルでキャッシュに保存する
フロントエンドのロケーションがバックエンドのロケーションと異なる場合は、可能な限りバックエンド サービスからの応答をキャッシュに保存してください。フロントエンドとバックエンドが同じリージョンにある場合は、時間のかかるクエリも少なくなるため、アプリのレイテンシは短縮されます。Memorystore for Redis は、アプリのキャッシュに使用できるフルマネージドのインメモリ データストアです。
アプリ クライアントまたはウェブ フロントエンドを最適化する
クライアント側（モバイルアプリまたはウェブ フロントエンド）でユーザー レイテンシを最適化する手法を使用できます。たとえば、一部のアセットを事前に読み込む、データをアプリ内にキャッシュ保存する、といった方法が考えられます。
また、可能であれば、リクエストの数を減らしたり、情報を並行して取得したりすることで、アプリが情報をフェッチする方法を最適化することもできます。
ユーザー レイテンシを測定する
レイテンシ要件のベースラインが確立されたら、ユーザーベースを調べて Google Cloud リソースの最適な配置を決定します。対象が新しいアプリか既存のアプリかによって、使用する戦略は異なります。
以下の戦略を使用して、アプリのサービス提供中にアクセスするパートナーへのレイテンシを測定するか、Cloud VPN または Dedicated Interconnect を使用して Google Cloud プロジェクトと相互接続するオンプレミス ネットワークへのレイテンシを測定します。
新しいワークロードのレイテンシを見積もる
新しいアプリと同様のユーザーベースを持つ既存のアプリがない場合は、予想されるユーザーベースの大まかな地域分布に基づいて、さまざまな Google Cloud リージョンからのレイテンシを見積もります。
ラウンドトリップ レイテンシは移動距離 100 km あたり 1 ミリ秒で見積もります。ネットワークは送信元から宛先までの理想的な経路をたどっていないため、通常は、実際の距離は地図上で測定した距離の 1.5～2 倍程度であると推測します。もちろん、より人口密度の低いリージョンでは、ネットワークが理想的な経路からもっと大きく離れている可能性もあります。ISP ネットワーク内の機器の通過によって増加するレイテンシは、リージョン間の距離を見るときには通常、無視してかまいません。
これらの数字は、エッジ POP や Cloud CDN ノードへのレイテンシ、およびネットワーク地図に示された世界中の Compute Engine リージョンへのレイテンシを見積もるのに役立ちます。
既存ユーザーへのレイテンシを測定する
同様のユーザーベースを持つ既存のアプリがある場合は、レイテンシをより正確に推定できるツールがいくつかあります。
- 代表ユーザー: 地理的分布のサンプルになりうるユーザーやパートナーに協力を求めることができる場合やそれらの国に従業員がいる場合は、さまざまな Google Cloud リージョンへのレイテンシを測定するよう依頼します。Google Cloud ping などのサードパーティ ウェブサイトも測定に役立つことがあります。
- アクセスログ: Google Cloud 以外でホストされている運用中のアプリがある場合は、アクセスログのデータを使用してユーザーの実態を大まかに把握します。ログには国や都市の情報が含まれる場合があり、これを使用してレイテンシを見積もることもできます。
- IP アドレス: ユーザーの IP アドレスにアクセスできる場合は、スクリプトを作成してさまざまな Google Cloud リージョンからの到達可能性とレイテンシをテストします。ファイアウォールによってプローブがブロックされる場合は、試しに最後の IP オクテットをランダム化して、アプリへのレイテンシが同程度である別のデバイスからレスポンスを取得してみます。
Google Cloud からのレイテンシ情報: Google Cloud に既存のアプリがある場合、レイテンシ情報を収集する方法がいくつかあります。
- ユーザー定義のリクエスト ヘッダー**: エンドユーザーの国、小区域、都市の情報や、ロードバランサとクライアント間の推定 RTT に対するヘッダーを有効にします。
- HTTP(S) ロード バランシングの Cloud Monitoring 指標: フロントエンドの RTT とバックエンドのレイテンシを含めます。
- VPC フローログ: 接続の両端間の TCP RTT を、提供されている指標の一部として取得します。
グローバルな接続性
レイテンシを見積もるときは、Google のグローバル ネットワークのトポロジに留意してください。
- POP: ユーザー トラフィックがネットワークに入る場所。
- Cloud CDN ノード: トラフィックがキャッシュされる場所。
- リージョン: リソースを配置できる場所。
- 接続性: POP とリージョン間の接続性。
Google が他の ISP と相互接続しているロケーションの一覧については、PeeringDB をご覧ください。
デプロイするリージョンを決定する際は、リージョン間のトポロジを考慮に入れてください。たとえば、グローバルなユーザーベースを持つアプリを単一のリージョンにデプロイする場合は通常、いずれかの米国リージョンでこのアプリをホストするのが最適です（米国は他のほとんどのリージョンに接続しているため）。多くの大陸間が直接接続されていますが、接続されていない大陸もあります。たとえばヨーロッパとアジア間は接続されていないため、ヨーロッパとアジア間のトラフィックは米国を経由します。
アプリが複数のリージョンでホストされており、データを同期する必要がある場合は、それらのリージョン間のレイテンシに注意してください。このレイテンシは時間とともに変化する可能性がありますが、通常は安定しています。可能性のあるすべてのリージョンでテスト インスタンスを起動してレイテンシを自分で測定するか、サードパーティ ウェブサイトを利用してリージョン間の現在のレイテンシを把握します。
すべてをまとめる
ここまで、レイテンシ要件、可能なデプロイモデル、ユーザーベースの地理的分布を見てきた中で、これらの要因が特定のリージョンへのレイテンシにどのように影響するかが理解できました。そこでいよいよ、アプリをリリースするリージョンを決定します。
さまざまな要因を評価する正しい方法というものはありませんが、以下の段階的な方法論がリージョンの決定に役立ちます。
- 特定のリージョンへのデプロイを妨げる、レイテンシに関連しない要因（価格やコロケーションなど）があるかどうかを確認します。そのような要因があれば、リージョンの候補リストから該当するリージョンを削除します。
- レイテンシ要件とアプリの一般的なアーキテクチャに基づいて、デプロイモデルを選択します。ほとんどのモバイルアプリやその他のレイテンシが重要でないアプリでは、単一リージョンへのデプロイモデルを採用して Cloud CDN によるキャッシュ可能コンテンツの配信とエッジでの SSL 終端を併用することが最適な選択肢となる場合があります。
選択したデプロイモデルに基づき、ユーザーベースの地理的分布とレイテンシの測定結果に基づいてリージョンを選択します。
単一リージョン デプロイの場合:
- 企業構内への低レイテンシ アクセスが必要な場合は、このロケーションに最も近いリージョンにデプロイします。
- ユーザーの主な接続元が 1 つの国または地域である場合は、代表ユーザーに最も近いリージョンにデプロイします。
- ユーザーベースがグローバルな場合は、米国のリージョンにデプロイします。
マルチリージョン デプロイの場合:
- ユーザーの地理的分布とアプリのレイテンシ要件に基づいて、ユーザーに近いリージョンを選択します。アプリに応じて、レイテンシ中央値が特定の値となるように最適化を行うか、95～99% のユーザーで特定の目標レイテンシが達成されるようにします。ある特定の地理的場所のユーザーは、インフラストラクチャが制限されているという理由で、他の場所のユーザーよりレイテンシに対する忍耐力が高いことがよくあります。
ユーザー レイテンシが複数のリージョンでほぼ同じである場合は、料金が決め手になることがあります。
Compute Engine リージョンを選択するとき、レイテンシは考慮すべき最も大きな要因の 1 つです。レイテンシ要件を評価および測定して質の高いユーザー エクスペリエンスを提供し、ユーザーベースの地理的分布が変化した場合は同じプロセスを繰り返します。
次のステップ
- Compute Engine のリージョンとゾーンについて確認する。
負荷分散によるアプリケーション レイテンシの最適化について学習する。
グローバルなデータ分散に適したアーキテクチャの選択について確認する。
Cloud Performance Atlas 動画シリーズを見る。
ユーザー レイテンシを最適化する方法の詳細については、High-performance browser networking のサイトをご覧ください。
Google Cloud に関するリファレンス アーキテクチャ、図、チュートリアル、ベスト プラクティスを確認する。Cloud Architecture Center を確認します。