このページでは、リージョン外部アプリケーション ロードバランサを使用して高可用性のデプロイを構成する方法について説明します。高可用性を実現するには、アプリケーションのトラフィックを最も適切にサポートするリージョンに、複数のリージョン外部アプリケーション ロードバランサをデプロイします。異なるリージョンのリージョン外部アプリケーション ロードバランサが相互に分離されているだけでなく、同じリージョンで実行されているグローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサのインフラストラクチャからも分離されているため、このようなことが可能になります。
Cloud DNS の位置情報ルーティング ポリシーを使用して、異なるリージョンの 2 つ以上のロードバランサにトラフィックを転送します。このポリシーは、クライアント リクエストの送信元に基づいて、最も近い使用可能なリージョンにトラフィックをルーティングします。また、ヘルスチェックを使用して、Google Cloud がリージョンの停止を検出し、正常なロードバランサにのみトラフィックを転送することをおすすめします。
次のサンプル設定では、2 つの異なるリージョンに 2 つのリージョン外部アプリケーション ロードバランサが構成されています。
以降のセクションでは、この構成にさまざまなコンポーネントが関係する一般的なワークフローについて説明します。
ヘルスチェックを使用してリージョン障害を検出する
Google Cloud は、ヘルスチェックを使用して、ロードバランサが正常かどうかを検出します。これらのヘルスチェックを構成して、3 つのソース リージョンからプローブを送信します。これらの 3 つのソース リージョンは、クライアントがロードバランサにアクセスするリージョンにする必要があります。たとえば、クライアント トラフィックの大部分が北米とヨーロッパから発信されるリージョン外部アプリケーション ロードバランサがある場合は、北米の 2 つ以上のリージョンとヨーロッパの 2 つ以上のリージョンからプローブを送信できます。
追加情報:
- ヘルスチェックを作成するときに、ソース リージョンを 3 つ指定する必要があります。ソース リージョンを指定できるのはグローバル ヘルスチェックのみです。
- HTTP、HTTPS、TCP のヘルスチェックがサポートされています。
- ヘルスチェック プローブは、構成された Google Cloud ソース リージョンから少し離れたインターネット上のポイント オブ プレゼンス（PoP）から発信されます。
正常なロードバランサにトラフィックを転送する
Google Cloud は、Cloud DNS の位置情報ルーティング ポリシーを使用して、ロードバランサにトラフィックをルーティングします。すべてのロードバランサが正常な場合、Cloud DNS は、クライアント リクエストの送信元に地理的に最も近いロードバランサにトラフィックを転送します。
特定のリージョンのロードバランサでヘルスチェックに失敗すると、トラフィックは他のリージョンで使用可能な正常なロードバランサに転送されます。
すべてのロードバランサを使用するフェイルバック
ヘルスチェックに再び合格すると、フェイルバックが自動的に実行されます。使用可能なロードバランサはすべてトラフィックを処理しているため、フェイルバック中にダウンタイムが発生することはありません。
クロスリージョン ロード バランシングを構成する
高可用性を実現するクロスリージョン デプロイを構成する手順は次のとおりです。
- アプリケーションのトラフィックに最適と判断したリージョンに、リージョン外部アプリケーション ロードバランサを作成します。これらのロードバランサは、同じトラフィック管理とセキュリティ構成にする必要があります。
- ヘルスチェックと DNS ルーティング ポリシーを作成して、クライアントのロケーションに基づいてトラフィックをロードバランサに転送し、停止した場合は異常なロードバランサから別のロードバランサにトラフィックを転送するようにします。
複数のリージョンにロードバランサを作成する
冗長なロードバランサを追加で構成する際は、次の点を考慮してください。
どのロードバランサがリクエストを処理するかに関係なく、トラフィックが一貫して処理されるように、すべてのリージョン外部アプリケーション ロードバランサに類似の機能を構成します。たとえば、すべてのリージョン外部アプリケーション ロードバランサで同じタイプの SSL 証明書、同じ Google Cloud Armor ポリシー、同じトラフィック管理設定を使用する必要があります。
Terraform などの自動化フレームワークを使用して、異なるリージョン デプロイ間でロードバランサ構成の一貫性を維持することをおすすめします。
アプリケーションのトラフィックに最適と判断したリージョンに、リージョン外部アプリケーション ロードバランサを設定することをおすすめします。
リージョン外部アプリケーション ロードバランサは、プレミアムとスタンダードの両方の Network Service Tiers をサポートします。低レイテンシを確保するには、プレミアム ティアに追加のリージョン外部アプリケーション ロードバランサを設定することをおすすめします。
リージョン外部アプリケーション ロードバランサの構成方法については、VM インスタンス グループのバックエンドを使用してリージョン外部アプリケーション ロードバランサを設定するをご覧ください。
Cloud DNS とヘルスチェックを構成する
このセクションでは、Cloud DNS と Google Cloud のヘルスチェックを使用して、Cloud Load Balancing 環境を構成し、停止を検出して他のリージョンのロードバランサにトラフィックを転送する方法について説明します。
必要なヘルスチェック ポリシーとルーティング ポリシーを構成する手順は次のとおりです。
プライマリ ロードバランサの転送ルールの IP アドレスのヘルスチェックを作成します。
gcloud beta compute health-checks create http HEALTH_CHECK_NAME \ --global \ --source-regions=SOURCE_REGION_1,SOURCE_REGION_2,SOURCE_REGION_3 \ --use-serving-port \ --check-interval=HEALTH_CHECK_INTERVAL \ --healthy-threshold=HEALTHY_THRESHOLD \ --unhealthy-threshold=UNHEALTHY_THRESHOLD \ --request-path=REQUEST_PATH次のように置き換えます。
HEALTH_CHECK_NAME: ヘルスチェックの名前SOURCE_REGION: ヘルスチェック プローブが送信される 3 つの Google Cloud リージョン。ソース リージョンは 3 つ指定する必要があります。HEALTH_CHECK_INTERVAL: 1 つのプローバーから発行されたプローブの開始から、同じプローバーから次に発行されたプローブの開始までの時間（秒単位）。サポートされている最小値は 30 秒です。推奨される値については、ベスト プラクティスをご覧ください。HEALTHY_THRESHOLD、UNHEALTHY_THRESHOLD: VM インスタンスが正常であるか、正常でないかを判定するために必要になるプローブの成功または失敗の連続回数を示します。いずれのしきい値も省略されている場合は、デフォルトの 2 が使用されます。REQUEST_PATH: Google Cloud によるヘルスチェック プローブ リクエストの送信先となる URL パス。省略した場合、Google Cloud ではプローブ リクエストがルートパス/に送信されます。ヘルスチェックの対象のエンドポイントがプライベートの場合（これは、外部転送ルールの IP アドレスに一般的ではありません）、このパスを/afhealthzに設定できます。
Cloud DNS でレコードセットを作成し、位置情報ルーティング ポリシーを適用します。
gcloud beta dns record-sets create DNS_RECORD_SET_NAME \ --ttl=TIME_TO_LIVE \ --type=RECORD_TYPE \ --zone="MANAGED_ZONE_NAME" \ --routing-policy-type="GEO" \ --routing-policy-data="FORWARDING_RULE_NAME_A@REGION_A;FORWARDING_RULE_NAME_B@REGION_B[,;FORWARDING_RULE_NAME_C@REGION_C]" \ --health-check=HEALTH_CHECK_NAME次のように置き換えます。
DNS_RECORD_SET_NAME: 追加するレコードセットの DNS またはドメイン名（例:test.example.com）TIME_TO_LIVE: レコードの有効期間（TTL）（秒単位）。推奨される値については、DNS の考慮事項をご覧ください。RECORD_TYPE: レコードタイプ（例:A）MANAGED_ZONE_NAME: レコードセットを管理するマネージド ゾーンの名前（例:my-zone-name）FORWARDING_RULE_NAME: 各REGIONのロードバランサの転送ルールの名前REGION: 各ロードバランサがデプロイされているリージョン
ベスト プラクティス
Cloud DNS レコードとヘルスチェックを構成する際のベスト プラクティスは次のとおりです。
異常なロードバランサから正常なロードバランサにトラフィックが転送されるまでの時間（つまり、停止の期間）は、DNS TTL 値、ヘルスチェック間隔、ヘルスチェックの異常しきい値パラメータによって異なります。
Google の Cloud DNS では、この期間の上限は次の式で計算できます。
Duration of outage = DNS TTL + Health Check Interval * Unhealthy ThresholdDNS TTL は 30～60 秒に設定することをおすすめします。DNS が他のリージョンにフェイルオーバーした後も、インターネット上のクライアントは正常でないロードバランサにアクセスし続けるため、TTL を長くするとダウンタイムが長くなります。
一時的なエラーによる不要なトラフィックの再ルーティングを回避するように、ヘルスチェックの正常しきい値と異常しきい値のパラメータを構成します。しきい値を高くすると、トラフィックが他のリージョンのロードバランサにシフトするまでの時間が長くなります。