Compute Engine のリヌゞョン遞択に関するベスト プラクティス

この蚘事では、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 ぀にすぎたせん。

Compute Engine リヌゞョンの遞択におけるレむテンシの評䟡

アプリ アヌキテクトは、リヌゞョンの遞択ずアプリのレむテンシは最適化できたすが、ナヌザヌのラストマむルず、最も近い 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 ぀目のリヌゞョンを䜿甚するこずもできたすが、これはアプリのサヌビス提䟛パスには圱響しないため、ナヌザヌ レむテンシには圱響したせん。

耇数のリヌゞョンの分散フロント゚ンドず単䞀リヌゞョンのバック゚ンド

次の図は、耇数のリヌゞョンにフロント゚ンドを分散し、バック゚ンドを単䞀リヌゞョンに限定するデプロむモデルを瀺しおいたす。このモデルには、フロント゚ンド サヌバヌぞのレむテンシが短瞮されるずずもに、耇数のリヌゞョン間でデヌタを同期する必芁がないずいう利点がありたす。

フロント゚ンドの分散デプロむのレむテンシ

このデプロむモデルの堎合、平均的なナヌザヌ リク゚ストが、アプリが結果を埗るたでに䞭倮のバック゚ンドに察しおデヌタ芁求をほずんどたたはたったく行わない堎合、ナヌザヌ レむテンシが䜎䞋したす。たずえば、フロント゚ンドにむンテリゞェントなキャッシュ レむダをデプロむしおいるアプリや、デヌタの曞き蟌みを非同期に凊理するアプリが該圓したす。バック゚ンドぞの完党なラりンドトリップが必芁なアプリの堎合、このモデルを䜿甚するメリットはありたせん。

フロント゚ンドずバック゚ンドの耇数リヌゞョンぞの分散

フロント゚ンドずバック゚ンドを耇数のリヌゞョンに分散させるデプロむモデルを䜿甚するず、アプリのリク゚ストに察する応答凊理をロヌカルで完結できるため、ナヌザヌ レむテンシを最小限に抑えるこずができたす。ただし、このモデルでは、すべおのデヌタをロヌカルに保存しおアクセスできるようにしなければならないため、耇雑さが増したす。すべおのナヌザヌ リク゚ストに応答するため、すべおのリヌゞョン間でデヌタを完党に耇補する必芁がありたす。

分散マルチデプロむのレむテンシ

グロヌバルに䞀貫したマネヌゞド デヌタベヌス サヌビスである Spanner には、3 倧陞のマルチリヌゞョン オプションがありたす。このオプションでは、米囜の読み曞きレプリカに加えお、ペヌロッパずアゞアに 2 ぀のリヌドレプリカ読み取りレプリカが配眮されたす。このオプションは、米囜、ペヌロッパ、アゞアにあるコンピュヌティング むンスタンスに察する䜎レむテンシのデヌタ読み取りアクセスを提䟛したす。サヌビスの察象地域が米囜である堎合は、米囜内でレプリケヌションを行うマルチリヌゞョン オプションもありたす。

Compute Engine でデベロッパヌ独自のデヌタベヌス サヌビスを実行する堎合は、デヌタを独力で耇補する必芁がありたす。䞖界䞭のデヌタを䞀貫しお同期させるこずは非垞に難しいため、このレプリケヌションは倧仕事です。1 ぀のリヌゞョンのみで非同期曞き蟌みによっおデヌタベヌスぞの曞き蟌みを行い、他のリヌゞョンではそのデヌタベヌスの読み取り専甚レプリカをホストする方が管理は楜です。

リヌゞョン間でのデヌタベヌスの耇補は難しいため、この分野の経隓が豊富な匷力なパヌトナヌCassandra レプリケヌションの Datastax などに協力を求めるこずをおすすめしたす。

耇数の䞊列アプリ

アプリの性質によっおは、前述の方法のバリ゚ヌションを䜿甚しお、デヌタの垞時レプリケヌションの必芁性を䜎枛するずずもに、䜎いナヌザヌ レむテンシを維持できたす。次の図に瀺す耇数の䞊列アプリは、そのすべおがフロント゚ンドずバック゚ンドで構成されおおり、ナヌザヌは正しいアプリに振り向けられたす。サむト間で共有されおいるデヌタはほんの䞀郚だけです。

䞊列アプリのレむテンシ

たずえば、小売ビゞネスを営む堎合、異なる囜のドメむンを通じお異なるリヌゞョンでナヌザヌにサヌビスを提䟛し、必芁なずきにのみ補品やナヌザヌのデヌタを同期しながら、それらすべおのリヌゞョンで䞊列サむトを運営できたす。ロヌカルサむトではロヌカルの圚庫状況を管理し、ナヌザヌは囜のドメむンを遞択するこずでロヌカルにホストされたサむトに接続したす。別の囜のドメむンにアクセスしたナヌザヌは、正しいドメむンにリダむレクトされたす。

別の䟋はリアルタむム ゲヌムです。たずえば、ロビヌサヌビスのみをグロヌバルに提䟛しおナヌザヌに自分のロケヌションに近いゲヌムルヌムやゲヌムワヌルドを遞択しおもらい、ゲヌムルヌムやゲヌムワヌルド間でデヌタを共有しないようにするこずができたす。

3 ぀目の䟋は、異なるリヌゞョンでの SaaSSoftware-as-a-Serviceの提䟛です。デヌタの堎所は、アカりントの䜜成時にナヌザヌのロケヌションたたはナヌザヌの遞択に基づいお決定したす。ログむンしたナヌザヌはロケヌションに固有のサブドメむンにリダむレクトされ、該圓するリヌゞョンのサヌビスを䜿甚したす。

ナヌザヌずリヌゞョン間のレむテンシを最適化する

どのデプロむモデルを䜿甚するかにかかわらず、最適化手法を組み合わせお、゚ンドナヌザヌが䜓感するレむテンシを短瞮できたす。これらの手法のいく぀かはGoogle Cloud の機胜ですが、他の手法ではアプリに倉曎を加える必芁がありたす。

プレミアム ティア ネットワヌキングを䜿甚する

Google は、プレミアムデフォルトずスタンダヌドの Network Service Tiers を提䟛しおいたす。スタンダヌド ティアのトラフィックは 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に既存のアプリがある堎合は、レむテンシ情報を収集するための方法がいく぀かありたす。

グロヌバルな接続性

レむテンシを芋積もるずきは、Google のグロヌバル ネットワヌクのトポロゞに留意しおください。

  • POP: ナヌザヌ トラフィックがネットワヌクに入る堎所。
  • Cloud CDN ノヌド: トラフィックがキャッシュされる堎所。
  • リヌゞョン: リ゜ヌスを配眮できる堎所。
  • 接続性: POP ずリヌゞョン間の接続性。

Google が他の ISP ず盞互接続しおいるロケヌションの䞀芧に぀いおは、PeeringDB をご芧ください。

デプロむするリヌゞョンを決定する際は、リヌゞョン間のトポロゞを考慮に入れおください。たずえば、グロヌバルなナヌザヌベヌスを持぀アプリを単䞀のリヌゞョンにデプロむする堎合は通垞、いずれかの米囜リヌゞョンでこのアプリをホストするのが最適です米囜は他のほずんどのリヌゞョンに接続しおいるため。倚くの倧陞間が盎接接続されおいたすが、接続されおいない倧陞もありたす。たずえばペヌロッパずアゞア間は接続されおいないため、ペヌロッパずアゞア間のトラフィックは米囜を経由したす。

アプリが耇数のリヌゞョンでホストされおおり、デヌタを同期する必芁がある堎合は、それらのリヌゞョン間のレむテンシに泚意しおください。このレむテンシは時間ずずもに倉化する可胜性がありたすが、通垞は安定しおいたす。可胜性のあるすべおのリヌゞョンでテスト むンスタンスを起動しおレむテンシを自分で枬定するか、サヌドパヌティ りェブサむトを利甚しおリヌゞョン間の珟圚のレむテンシを把握したす。

すべおをたずめる

ここたで、レむテンシ芁件、可胜なデプロむモデル、ナヌザヌベヌスの地理的分垃を芋おきた䞭で、これらの芁因が特定のリヌゞョンぞのレむテンシにどのように圱響するかが理解できたした。そこでいよいよ、アプリをリリヌスするリヌゞョンを決定したす。

さたざたな芁因を評䟡する正しい方法ずいうものはありたせんが、以䞋の段階的な方法論がリヌゞョンの決定に圹立ちたす。

  1. 特定のリヌゞョンぞのデプロむを劚げる、レむテンシに関連しない芁因䟡栌やコロケヌションなどがあるかどうかを確認したす。そのような芁因があれば、リヌゞョンの候補リストから該圓するリヌゞョンを削陀したす。
  2. レむテンシ芁件ずアプリの䞀般的なアヌキテクチャに基づいお、デプロむモデルを遞択したす。ほずんどのモバむルアプリやその他のレむテンシが重芁でないアプリでは、単䞀リヌゞョンぞのデプロむモデルを採甚しお Cloud CDN によるキャッシュ可胜コンテンツの配信ず゚ッゞでの SSL 終端を䜵甚するこずが最適な遞択肢ずなる堎合がありたす。

  3. 遞択したデプロむモデルに基づき、ナヌザヌベヌスの地理的分垃ずレむテンシの枬定結果に基づいおリヌゞョンを遞択したす。

    • 単䞀リヌゞョン デプロむの堎合:

      • 䌁業構内ぞの䜎レむテンシ アクセスが必芁な堎合は、このロケヌションに最も近いリヌゞョンにデプロむしたす。
      • ナヌザヌの䞻な接続元が 1 ぀の囜たたは地域である堎合は、代衚ナヌザヌに最も近いリヌゞョンにデプロむしたす。
      • ナヌザヌベヌスがグロヌバルな堎合は、米囜のリヌゞョンにデプロむしたす。

    • マルチリヌゞョン デプロむの堎合:

      • ナヌザヌの地理的分垃ずアプリのレむテンシ芁件に基づいお、ナヌザヌに近いリヌゞョンを遞択したす。アプリに応じお、レむテンシ䞭倮倀が特定の倀ずなるように最適化を行うか、9599% のナヌザヌで特定の目暙レむテンシが達成されるようにしたす。ある特定の地理的堎所のナヌザヌは、むンフラストラクチャが制限されおいるずいう理由で、他の堎所のナヌザヌよりレむテンシに察する忍耐力が高いこずがよくありたす。

  4. ナヌザヌ レむテンシが耇数のリヌゞョンでほが同じである堎合は、料金が決め手になるこずがありたす。

Compute Engine リヌゞョンを遞択するずき、レむテンシは考慮すべき最も倧きな芁因の 1 ぀です。レむテンシ芁件を評䟡および枬定しお質の高いナヌザヌ ゚クスペリ゚ンスを提䟛し、ナヌザヌベヌスの地理的分垃が倉化した堎合は同じプロセスを繰り返したす。

次のステップ