このドキュメントでは、複数のリージョン ロードバランサと Google DNS ルーティング ポリシーを組み合わせて、グローバル ロード バランシング アーキテクチャを作成する方法について説明します。このドキュメントは、ネットワーク エンジニア、ソリューション アーキテクト、運用の専門家を対象としています。Google Compute Engine の基本的な知識があり、ロードバランサや DNS ルックアップなどのネットワークのコンセプトに精通していることを前提としています。
はじめに
複数のリージョンで実行されるアプリケーションとして実装されるグローバル サービスをビルドする場合、位置情報 DNS ルーティング ポリシーを使用して、リージョン ロードバランサのグローバル DNS エンドポイントを設定できます。このアプローチでは、最も近いローカル サービスにトラフィックをルーティングするグローバル エンドポイントを作成します。
使用しているロードバランサの種類によっては、グローバル プロキシベースのロード バランシング オプションを使用してこのシナリオを実現できる場合があります。ただし、サービスが UDP トラフィックを処理する場合など、一部のユースケースではリージョン ロード バランシング プロダクトを使用する必要があります。位置情報 DNS ルーティング ポリシーは、他のクラウド サービス プロバイダやオンプレミス デプロイメントと並行して Google Cloud を使用するハイブリッド アプリケーションに単一の DNS エンドポイントを提供する場合にも役立ちます。
アーキテクチャ
次の図は、3 つの異なるリージョンで 3 つのリージョン ロードバランサを使用するサンプル アーキテクチャを示しています。リージョンは DNS ルーティング ポリシーを使用して統合されています。
上の図は、オレゴン、ドイツ、シンガポールのクライアントが www.example.com の Cloud DNS に DNS ルックアップを行う方法を示しています。リクエストは各クライアントに近いリージョン ロードバランサにルーティングされ、3 つの異なるリージョンでホストされているアプリケーションに到達します。
位置情報 DNS ルーティング ポリシーのユースケース
このセクションでは、位置情報 DNS ルーティング ポリシーを使用して、複数のリージョン ロードバランサからグローバル サービスを作成するユースケースについて説明します。
- グローバルにアクセス可能でグローバルに分散した内部サービス
- TCP と UDP をサポートする外部サービスのグローバル DNS エンドポイント
- ハイブリッド サービスのグローバル DNS エンドポイント
グローバルにアクセス可能でグローバルに分散した内部サービス
位置情報 DNS ルーティング ポリシーを使用して複数のリージョン内部ロードバランサを組み合わせることで、グローバルにアクセス可能でグローバルに分散された内部サービスを作成できます。内部パススルー ネットワーク ロードバランサまたは内部アプリケーション ロードバランサのいずれかを使用できます。DNS ルーティング ポリシーがない場合、内部アプリケーション ロードバランサはリージョン エンドポイントのみを使用できます。グローバル アクセスを使用する内部パススルー ネットワーク ロードバランサを使用すると、サービスをグローバルに利用可能にできます。その場合、バックエンドは単一のリージョンにのみ存在できます。ただし、DNS ルーティング ポリシーを使用する場合は、複数のリージョンにバックエンドを設定できます。
次の図は、このアーキテクチャを示しています。
上図は、複数のリージョンの内部クライアントが Cloud DNS を使用して service.corp.example.com を解決する方法を示しています。クライアントは常に、クライアントのリージョンにある内部パススルー ネットワーク ロードバランサに属する IP アドレスを含むレスポンスを受信します。ロードバランサは同じリージョンにあるアプリケーションをポイントします。（この例では、アプリケーションは Google Kubernetes Engine（GKE）で実行されますが、これは要件ではありません）。クライアントはアプリケーションのローカル インスタンスにアプリケーション トラフィックを送信しますが、クライアントはすべて同じ service.corp.example.com DNS エンドポイントを使用します。
この構成は、次の手順で作成できます。
- 各リージョンに内部ロードバランサを作成します。内部パススルー ネットワーク ロードバランサを使用する場合は、他のリージョンのクライアントがサービスに接続できるように、グローバル アクセスを有効にする必要があります。
DNS ルーティング ポリシーを作成します。このポリシーでは、タイプを
GEOに設定し、--routing-policy-data値を、対応する内部ロードバランサにマッピングされたターゲット リージョンのリストに設定します。図に示すセットアップを作成するには、次のコマンドを使用します。gcloud beta dns record-sets create service.corp.example.com \ --ttl=30 \ --type=A \ --zone=my-zone \ --routing-policy-type=GEO \ --routing-policy-data="europe-west4=fr-eu-w4;asia-east1=fr-as-e1;us-central1=fr-us-c1" \ --enable-health-checking
この例では、ポリシーが変更されたときにクライアントが DNS レコードを頻繁に更新できるように、TTL 値を 30 秒に設定してレコードが作成されています。
DNS ルーティング ポリシーを使用すると、各クライアントは、リージョン内の内部ロードバランサの IP アドレスを含む DNS レスポンスを受け取ります。内部ロードバランサが定義されているリージョンの外部にある場合、クライアントは最も近いリージョンにある内部ロードバランサの IP アドレスを受け取ります。
DNS ルーティング ポリシーは、最も近い内部ロードバランサのリージョンに基づいてトラフィックをルーティングします。そのリージョンのバックエンドの 80% 以上が正常ではなく、ヘルスチェックの機能を位置情報 DNS ルーティング ポリシーで使用している場合、トラフィックはリージョン間でフェイルオーバーします。
リージョン間でのフェイルオーバーが必要ない場合は、次のようにコマンドを変更できます。
--enable-health-checkingフラグを削除します。- 内部ロードバランサの各転送ルールの名前を IP アドレスに置き換えます。
TCP と UDP をサポートする外部サービスのグローバル エンドポイント
また、位置情報 DNS ルーティング ポリシーを使用して複数のリージョン外部ロードバランサを組み合わせることで、外部サービスのグローバル DNS エンドポイントを作成できます。最も一般的なユースケースは、TCP ベースまたは UDP ベースのアプリケーションに外部パススルー ネットワーク ロードバランサを使用することです。このアプローチは、UDP を使用するアプリケーションに特に役立ちます。Google Cloud では UDP 用のグローバルなロード バランシング オプションがないためです。
外部プロキシ ネットワーク ロードバランサまたは外部アプリケーション ロードバランサでサポートされている TCP トラフィックを使用するアプリケーションでは、DNS エンドポイントではなくグローバル ロード バランサのインスタンスを使用できる場合があります。これらのロードバランサは、すべてのバックエンド インスタンスのフロントエンドとして単一の IP アドレスを提供するエニーキャストを使用してクロスリージョン ロード バランシングを提供します。
DNS エンドポイントにグローバル ロード バランシング オプションを使用する利点は次のとおりです。
- フェイルオーバーがすぐに実行されます。フェイルオーバーは、ユーザー側からのトラフィック フローの目に見える変化を発生させずに行われます。
- インターネット ルーティングがロード バランシングのターゲットを決定します。Cloud DNS がターゲット ロケーションを選択するのではなく、インターネット ルーティング プロトコルが最短のパスに基づいてトラフィックを転送します。
- クロスリージョン ロード バランシング。Google のグローバル ロード バランシングは、リージョン間のフェイルオーバーをサポートします。一方、外部パススルー ネットワーク ロードバランサを使用する場合、DNS ルーティング ポリシーではヘルスチェックは行われません。
したがって、アプリケーションが TCP ベースであり、これらのプロダクトでサポートされている場合は、Google のグローバル ロード バランシング オプションを使用することをおすすめします。
次の図は、グローバル DNS エンドポイントを使用するアーキテクチャを示しています。
上の図は、複数のリージョンの外部クライアントが Cloud DNS を使用して www.example.com を解決する方法を示しています。クライアントは、クライアントのリージョンにあるネットワーク TCP/UDP ロードバランサに属する IP アドレスでレスポンスを受け取ります。これにより、クライアントは、同じリージョン内で実行中のアプリケーションに接続できます。各クライアントはサービスのローカル インスタンスにアプリケーション トラフィックを送信しますが、クライアントはすべて同じ www.example.com DNS エンドポイントを使用します。
この構成は、次の手順で作成できます。
- 各リージョンにネットワーク TCP/UDP ロードバランサを作成します。
DNS ルーティング ポリシーを作成します。このポリシーでは、タイプを
GEOに設定し、--routing-policy-data値を、対応するネットワーク TCP/UDP ロードバランサにマッピングされたターゲット リージョンのリストに設定します。図に示すセットアップを作成するには、次のコマンドを使用します。gcloud dns record-sets create www.example.com \ --ttl=30 \ --type=A \ --zone=my-zone \ --routing-policy-type=GEO \ --routing-policy-data="europe-west4=192.0.2.5;asia-east1=198.51.100.10;us-central1=203.0.113.33"
このポリシーの適用後、クライアントが DNS リクエストを行うと、各クライアントは、そのクライアントに最も近いリージョンにある外部パススルー ネットワーク ロードバランサの IP アドレスを含む DNS レスポンスを受信します。
外部パススルー ネットワーク ロードバランサを使用するとヘルスチェックが行われないため、リージョン間のトラフィックを自動的にフェイルオーバーするためにグローバル エンドポイント www.example.com を使用することはできません。DNS レコードを変更して手動でフェイルオーバーをトリガーする必要があります。
このアプローチで対処できるもう 1 つのユースケースは、データにリージョンに関する要件がある HTTP(S) を使用するアプリケーションで、グローバル エンドポイントを使用してデータを提供する必要がある場合です。このシナリオは、位置情報 DNS ルーティング ポリシーを使用して複数のリージョン外部アプリケーション ロードバランサ インスタンスを組み合わせることによって実装できます。リージョン要件がない場合は、グローバル外部アプリケーション ロードバランサを使用できます。
ハイブリッド サービスのグローバル DNS エンドポイント
場合によっては、位置情報 DNS ルーティング ポリシーを使用して、ハイブリッド アプリケーション用に単一のエンドポイントを提供できます。
次の図は、このアーキテクチャを示しています。
上の図は、複数のリージョンの外部クライアントが Cloud DNS を使用して www.example.com を解決する方法を示しています。Cloud DNS は、アジアと米国のインターネット ユーザーを、ユーザーの近くのリージョンにあるネットワーク TCP/UDP ロードバランサに属する IP アドレスにポイントします。ロードバランサがポイントするアプリケーションは、同じリージョンの GKE で実行されています。ヨーロッパのインターネット ユーザーの場合、Cloud DNS は、アプリケーションが GKE on VMware でホストされているヨーロッパのオンプレミス データセンターにあるロードバランサを指す IP アドレスを返します（この例では、アプリケーションは GKE on VMware と GKE で実行されますが、これは必須要件ではありません）。
この構成は、次の手順で作成できます。
- 各リージョンでネットワーク TCP/UDP ロードバランサとオンプレミス ロードバランサを作成します。
DNS ルーティング ポリシーを作成します。このポリシーでは、タイプを
GEOに設定し、--routing-policy-data値を、対応するネットワーク TCP/UDP ロードバランサにマッピングされたターゲット リージョンのリストに設定します。図に示すセットアップを作成するには、次のコマンドを使用します。gcloud dns record-sets create www.example.com \ --ttl=30 \ --type=A \ --zone=my-zone \ --routing-policy-type=GEO \ --routing-policy-data="europe-west4=192.0.2.51;asia-east1=198.51.100.10;us-central1=203.0.113.33"
--routing-policy-data フラグを設定すると、最も近い Google Cloud リージョンに基づいて異なる IP アドレスを返すように Cloud DNS を設定できます。ただし、クライアントの正確な国や地理的リージョンに基づいてトラフィックをルーティングすることはできません。上記の例では、ほとんどのユーザーがリージョンまたは大陸にあるオンプレミス データセンターに送信されます。ただし、Cloud DNS が最も近い Google Cloud リージョンの特定に使用するアルゴリズムが、特定の国または地理的境界と一致しない場合があります。したがって、位置情報 DNS ルーティング ポリシーはコンプライアンスのユースケースに使用できません。
この例に示されている大陸レベルの粒度よりも細かい粒度を必要とするほかのユースケースは、このハイブリッド アプローチでは不可能です。たとえば、Google Cloud リージョンが存在しない国にオンプレミス データセンターがある場合、その国または地域のユーザーにオンプレミスでトラフィックを送信することはできません。最も近い Google Cloud リージョンに基づいて IP アドレスを返すようにのみロードバランサを構成できます。正確な地理的場所や国に基づいてトラフィックを制限またはルーティングする場合は、DNS ベースのグローバル サーバー ロード バランシング（GSLB）サービスを提供するサードパーティ プロバイダを使用できます。
次のステップ
- DNS ルーティング ポリシーを管理する。
- DNS のベスト プラクティス。
- ロードバランサの機能。
- ロード バランシングによるアプリケーション レイテンシの最適化。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。