Compute Engine のリソースは、世界中の複数のロケーションでホストされています。これらのロケーションはリージョンとゾーンからなります。リージョンとは、リソースをホストできる特定の地理的なロケーションです。各リージョンには 1 つ以上のゾーンがあります。ほとんどのリージョンには 3 つ以上のゾーンがあります。たとえば、米国西海岸を指す us-west1 リージョンには us-west1-a、us-west1-b、us-west1-c の 3 つのゾーンがあります。
仮想マシン インスタンスやゾーン永続ディスクなど、ゾーンを有効範囲とするリソースはゾーンリソースと呼ばれます。静的外部 IP アドレスなど、それ以外のリソースはリージョン リソースです。リージョン リソースは、ゾーンを問わずそのリージョン内のすべてのリソースで使用できます。ゾーンリソースは、同じゾーンにある他のリソースでのみ使用できます。
たとえば、ゾーン永続ディスクをインスタンスに接続するには、この両方のリソースが同じゾーン内になければなりません。同様に、静的 IP アドレスをインスタンスに割り当てるには、そのインスタンスがその静的 IP アドレスと同じリージョン内になければなりません。
リージョン内の異なるゾーンにリソースを置くと、物理インフラストラクチャやハードウェア ソフトウェアで障害が発生した場合に、ほとんどの種類の障害からリソースを隔離できます。複数のリージョンにリソースを置けば、障害からの隔離をさらに強化できます。こうすることにより、複数のドメインにリソースを分散させた堅牢なシステムを設計できます。
リージョンまたはゾーン固有のリソースは、一部だけです。イメージなど、その他のリソースはグローバル リソースで、場所を問わずすべての他のリソースで使用できます。グローバル、リージョン、ゾーンの Compute Engine リソースについて詳しくは、グローバル リソース、リージョン リソース、ゾーンリソースをご覧ください。
ゾーンとクラスタ
Compute Engine は、ゾーンとそのゾーンがホストされている物理クラスタとの間に抽象化レイヤを実装します。クラスタは、データセンターに収容されている個別の物理インフラストラクチャを表します。クラスタごとに、独立したソフトウェア インフラストラクチャ、電源、冷却、ネットワーク、セキュリティ インフラストラクチャがあり、コンピューティング リソースとストレージ リソースの大規模なプールが含まれています。
各ゾーンは 1 つ以上のクラスタ内でホストされます。Compute Engine は組織ごとに個別にゾーンをクラスタにマッピングします。たとえば、ある組織の us-central1-a ゾーンは、別の組織の us-central1-a ゾーンと同じクラスタにはマッピングされていない可能性があります。
ゾーンをクラスタから分離すると、ユーザーにも Compute Engine にも数々のメリットをもたらします。
- Compute Engine がリージョン内のクラスタの間でリソースのバランスをとることができます。
- Compute Engine がクラスタを追加してリージョンを拡大し続けても、ゾーンの選択リストが管理しやすい状態に維持されます。
ほとんどの組織について、Compute Engine は組織内のすべてのプロジェクトで一貫したゾーンとクラスタのマッピングが使用されるようにします。組織のプロジェクトで、VPC ネットワーク ピアリングまたはプライベート サービス アクセスを使用して他の組織とネットワークあるいはサービスを共有している場合、Compute Engine はピアリングされたすべての組織でのゾーンとクラスタのマッピングの一貫性を確保するよう試みます。たとえば大規模な SaaS プロバイダの場合は、Compute Engine がピアリングされたすべての組織でのマッピングの一貫性を確保できない可能性があります。その場合、Compute Engine はピアリングされたプロジェクトでゾーンとクラスタのマッピングの一貫性を確保しようと試みます。
ロケーション
次の表に、Compute Engine のすべてのリージョンと各リージョンに関連付けられたゾーンのロケーションを記載します。ゾーンで使用可能なマシンの種類と機能の詳細については、使用可能なリージョンとゾーンのセクションをご覧ください。
| リージョン | ゾーン | ロケーション |
|---|---|---|
asia-east1 |
a、b、c | 彰化県（台湾） |
asia-east2 |
a、b、c | 香港 |
asia-northeast1 |
a、b、c | 東京（日本） |
asia-northeast2 |
a、b、c | 大阪（日本） |
asia-south1 |
a、b、c | ムンバイ（インド） |
asia-southeast1 |
a、b、c | ジュロンウェスト（シンガポール） |
australia-southeast1 |
a、b、c | シドニー（オーストラリア） |
europe-north1 |
a、b、c | ハミナ（フィンランド） |
europe-west1 |
b、c、d | サンギスラン（ベルギー） |
europe-west2 |
a、b、c | ロンドン（イギリス） |
europe-west3 |
a、b、c | フランクフルト（ドイツ） |
europe-west4 |
a、b、c | エームスハーヴェン（オランダ） |
europe-west6 |
a、b、c | チューリッヒ（スイス） |
northamerica-northeast1 |
a、b、c | ケベック州モントリオール（カナダ） |
southamerica-east1 |
a、b、c | サンパウロ州オザスコ（ブラジル） |
us-central1 |
a、b、c、f | アイオワ州カウンシル ブラフス（米国） |
us-east1 |
b、c、d | サウスカロライナ州モンクスコーナー（米国） |
us-east4 |
a、b、c | 北バージニア州アッシュバーン（米国） |
us-west1 |
a、b、c | オレゴン州ダラス（米国） |
us-west2 |
a、b、c | カリフォルニア州ロサンゼルス（米国） |
リージョンとゾーンの選択
リソースをホストするリージョンまたはゾーンを選択します。これによって、データが保存される場所、およびデータを使用する場所が決まります。リージョンとゾーンの選択が重要となる理由はいくつかあります。
- 障害対応
- サービスの停止を回避するには、複数のゾーンとリージョンにリソースを分散します。Google では、ゾーンが相互に依存しない設計を採用しています。通常、ゾーンの電源、冷却、ネットワーキング、コントロール プレーンは他のゾーンから独立しており、ほとんどの単一障害は他のゾーンに影響を与えません。そのため、あるゾーンが使用不能になっても、同じリージョン内の別ゾーンにトラフィックを転送することでサービスの実行を継続できます。同様に、あるリージョンで障害が発生しても、別のリージョンでバックアップ サービスが実行されます。リソースの分散および堅牢なシステムの設計の詳細については、堅牢なシステムの設計をご覧ください。
- ネットワーク レイテンシの短縮
- ネットワーク レイテンシを短縮するためには、サービス提供地点に近いリージョンまたはゾーンを選択することをおすすめします。たとえば、ほとんどの顧客が米国東海岸に存在する場合は、このエリアに近いリージョンとゾーンをプライマリとして選択し、バックアップ リージョンおよびゾーンもこのエリア近くにあるものを選択します。
リージョンとゾーンの識別
Compute Engine の各リージョンには、多数のゾーンが含まれています。ゾーン名は、そのゾーンの詳細を示す 2 つの部分で構成されます。ゾーン名の最初の部分がリージョンで、2 番目の部分がリージョン内のゾーンを示します。
リージョン
「リージョン」はゾーンの集まりです。ゾーンは、帯域幅が広く待ち時間が短いネットワークで同じリージョンの他のゾーンと接続されています。可用性が高いフォールト トレラントなアプリケーションをデプロイするには、複数のゾーンと複数のリージョンに対して行うことを推奨します。こうすることで、1 つのゾーンまたはリージョンでのみ発生する予期しないコンポーネントの故障の影響を受けにくくなります。
シナリオにとって合理的なリージョンを選択します。たとえば、米国にのみ顧客がいる場合、またはなんらかの理由によりデータの存在場所を米国内に制限する必要がある場合は、リージョン
us-central1またはリージョンus-east1のゾーンにリソースを保存することが合理的であると言えます。ゾーン
「ゾーン」とはリージョン内の分離されたロケーションです。ゾーンの完全修飾名は
<region>-<zone>の形式です。たとえば、リージョンus-central1のゾーンaの完全修飾名は、us-central1-aです。リソースを分散する範囲の広さによっては、冗長性を確保するために、複数リージョンの複数ゾーンでインスタンスを作成します。
使用可能なリージョンとゾーン
次の表に、リージョンとそのロケーション、そのリージョン内で利用できるゾーン、および利用できる機能を示します。
各ゾーンでは、Ivy Bridge、Sandy Bridge、Haswell、Broadwell、Skylake、Cascade Lake プラットフォームの組み合わせがサポートされます。ゾーンにインスタンスを作成すると、インスタンスはそのゾーンでサポートされているデフォルトのプロセッサを使用します。たとえば、us-central1-a ゾーンでインスタンスを作成する場合、別のオプションを指定しない限り、インスタンスはデフォルトで Haswell プロセッサを使用します。
必要に応じて、特定の CPU プラットフォームを選択することもできます。詳細については、VM インスタンスの最小 CPU プラットフォームの指定をご覧ください。
| リージョン名 | リージョンの説明 | ロケーション | ゾーン | 特徴 |
|---|---|---|---|---|
asia-east1 |
台湾 | 彰化県（台湾） |
asia-east1-a
|
|
asia-east1-b
|
|
|||
asia-east1-c
|
|
|||
asia-east2 |
香港 | 香港 |
asia-east2-aasia-east2-basia-east2-c
|
|
asia-northeast1 |
東京 | 東京（日本） |
asia-northeast1-a
|
|
asia-northeast1-b
|
|
|||
asia-northeast1-c
|
|
|||
asia-northeast2 |
大阪 | 大阪（日本） |
asia-northeast2-aasia-northeast2-basia-northeast2-c
|
|
asia-south1 |
ムンバイ | ムンバイ（インド） |
asia-south1-a
|
|
asia-south1-b
|
|
|||
asia-south1-c
|
|
|||
asia-southeast1 |
シンガポール | ジュロンウェスト（シンガポール） |
asia-southeast1-a
|
|
asia-southeast1-b
|
|
|||
asia-southeast1-c
|
|
|||
australia-southeast1 |
シドニー | シドニー（オーストラリア） |
australia-southeast1-aaustralia-southeast1-b
|
|
australia-southeast1-c
|
|
|||
europe-north1 |
フィンランド | ハミナ（フィンランド） |
europe-north1-aeurope-north1-c
|
|
europe-north1-b
|
|
|||
europe-west1 |
ベルギー | サンギスラン（ベルギー） | europe-west1-b |
|
europe-west1-c
|
|
|||
europe-west1-d
|
|
|||
europe-west2 |
ロンドン | ロンドン（イギリス） |
europe-west2-a
|
|
europe-west2-b
|
|
|||
europe-west2-c
|
|
|||
europe-west3 |
フランクフルト | フランクフルト（ドイツ） | ||
europe-west3-aeurope-west3-b
|
|
|||
europe-west3-c
|
|
|||
europe-west4 |
オランダ | エームスハーヴェン（オランダ） |
europe-west4-a
|
|
europe-west4-b
|
|
|||
europe-west4-c
|
|
|||
europe-west6 |
チューリッヒ | チューリッヒ（スイス） |
europe-west6-aeurope-west6-beurope-west6-c
|
|
northamerica-northeast1 |
モントリオール | ケベック州モントリオール（カナダ） |
northamerica-northeast1-a
|
|
northamerica-northeast1-bnorthamerica-northeast1-c
|
|
|||
southamerica-east1 |
オザスコ | サンパウロ州、オザスコ（ブラジル） |
southamerica-east1-a
|
|
southamerica-east1-b
|
|
|||
southamerica-east1-c
|
|
|||
us-central1 |
アイオワ | アイオワ州カウンシル ブラフス（米国） |
us-central1-a
|
|
us-central1-b
|
|
|||
us-central1-c
|
|
|||
us-central1-f |
|
|||
us-east1 |
サウスカロライナ | サウスカロライナ州モンクスコーナー（米国） |
us-east1-b
|
|
us-east1-c
|
|
|||
us-east1-d
|
|
|||
us-east4 |
北バージニア | バージニア州アッシュバーン（米国） |
us-east4-a
|
|
us-east4-bus-east4-c
|
|
|||
us-west1 |
オレゴン | オレゴン州ダラス（米国） |
us-west1-a
|
|
us-west1-b
|
|
|||
us-west1-c
|
|
|||
us-west2 |
ロサンゼルス | カリフォルニア州ロサンゼルス（米国） |
us-west2-a
|
|
us-west2-b
|
|
|||
us-west2-c
|
|
発表済みのリージョン
2019 年から 2020 年にかけて、Google では引き続き次のリージョンを新たに開設する予定です。
透過的メンテナンス
Google では、インフラストラクチャを定期的にメンテナンスしています。最新のソフトウェアを使用してシステムにパッチを適用し、ルーチンテストと予防的メンテナンスを実行し、全体として Google インフラストラクチャが可能な限り高速かつ効率的に機能していることを確認します。
デフォルトで、すべてのインスタンスは、メンテナンスがアプリケーションや作業負荷に影響を与えないように構成されます。Google は、データセンターの革新、運用上のベスト プラクティスを実施している他に、メンテナンスを避けて実行中の仮想マシン インスタンスを移動するライブ マイグレーション テクノロジーを採用しています。インスタンスは、利用者のアクションを必要とせずに、同じゾーン内で実行を続けます。
デフォルトでは、すべての仮想マシンがライブ マイグレーションを行うように設定されますが、仮想マシンを終了して再起動するように設定することもできます。この 2 つのオプションには、次のような違いがあります。
ライブ マイグレーション
実行中のインスタンスを Compute Engine が自動的に移行します。移行プロセスによってゲストのパフォーマンスが少し低下しますが、インスタンスは移行プロセス中もオンライン状態が継続されます。ゲストのパフォーマンスに与える正確な影響と影響を与える時間は、さまざまな要因によって変わりますが、ほとんどのアプリケーションおよび作業負荷では無視できる程度です。詳細については、ライブ マイグレーションをご覧ください。
終了して再起動
自動的に、Compute Engine がインスタンスにシャットダウンするよう信号を送り、インスタンスが完全にシャットダウンするのを待ってから、メンテナンスの終了後に再起動します。
インスタンスに上記のオプションを設定する方法について詳しくは、インスタンスのスケジュール オプションの設定をご覧ください。
ゾーンの使用中止
インフラストラクチャの大がかりな更新（電源、冷却、ネットワーク ファブリック、サーバーなど）を行うために既存のゾーンの廃止が必要になることは決してありません。インフラストラクチャの更新は頻繁に行われるものではなく、通常、更新は 3 年から 5 年の間隔で行われ、その間、ゾーンは稼働を続けます。この更新は、ユーザーに影響を与えることなく行われます。
万一、ゾーンのサポートを終了する必要が生じた場合は、Compute Engine がオフラインになる前に、仮想マシン インスタンスと作業負荷を移動できる十分な時間をもって、ユーザーに通知されます。
割り当て
静的 IP、イメージ、ファイアウォール ルール、ネットワークなど一部のリソースには、プロジェクト全体の割り当て上限とリージョンごとの割り当て上限が定義されます。これらのリソースを作成すると、関係するプロジェクト全体の割り当てまたはリージョンごとの割り当ての合計値が加算されます。関係する割り当て上限を超えると、そのプロジェクトまたはリージョンで同じタイプのリソースを追加することができなくなります。
プロジェクトに適用されている全体的な割り当てのリストを見るには、Google Cloud Platform Console の割り当てページを開いてください。
たとえば、グローバル ターゲット プールの割り当てが 50 個で、25 個のターゲット プールを example-region-1 で、25 個のターゲット プールを example-region-2 で作成した場合、プロジェクト全体の割り当てに達しているため、スペースを空けるまで、このプロジェクトではどのリージョンでもこれ以上のターゲット プールを作成できません。同様に、リージョンに割り当てられている IP アドレスが 7 個である場合、1 つのリージョンで予約できる IP アドレスは 7 個までです。この上限に達した場合は、新しいリージョンで IP アドレスを予約するか、現在のリージョンで一部の IP アドレスを解放する必要があります。
ヒント
ゾーンを選択するときは、次の点にご注意ください。
リージョン内およびリージョン間の通信には、別途費用が発生します。
通常、異なるリージョン間の通信と比較して、リージョン内の通信の方が安価で高速です。
重要なシステムは、複数のゾーンで冗長性を備えて設計します。
インスタンスは、予期しない障害の影響を受けることがあります。このような場合の影響を軽減するために、重要なシステムは複数のゾーンおよびリージョンに重複して展開することを推奨します。
たとえば、ゾーン
europe-west1-bとゾーンeurope-west1-cでインスタンスをホストすると、europe-west1-bで予期しない障害が発生した場合でも、ゾーンeurope-west1-cのインスタンスを利用できます。一方、すべてのインスタンスをeurope-west1-bでホストしていた場合は、europe-west1-bがオフラインになると、どのインスタンスにもアクセスできなくなります。また、複数のリージョンにまたがるようにリソースをホストすることも検討してください。たとえば、まれなケースですが、リージョンeurope-west1で障害が発生した場合に備えて、バックアップ インスタンスをリージョンeurope-west3のゾーンでホストすることを検討します。可用性の高いシステムを設計する方法に関するヒントについては、堅牢なシステムの設計をご覧ください。
次のステップ
- 利用可能なリージョンとゾーンを表示する方法を学習する。
- 地理とゾーンについて学習する。
- グローバル リソース、リージョン リソース、ゾーンリソースについて学習する。
- インスタンスについて学習する。
- Linux スタートガイドを実施する。
- Windows スタートガイドを実施する。
- デフォルトのプロジェクト、ゾーン、リージョンを設定する方法を学習する。
