外部アプリケーション ロードバランサのフェイルオーバー

プレビュー

このプロダクトまたは機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 一般提供前のプロダクトと機能は「現状のまま」ご利用いただけますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

このページでは、外部アプリケーション ロードバランサでフェイルオーバーが機能する仕組みについて説明します。フェイルオーバー構成には、プライマリ ロードバランサとバックアップ ロードバランサの 2 つのロードバランサが含まれます。ここでは、プライマリ ロードバランサは、フェイルオーバーを構成するロードバランサとします。バックアップ ロードバランサは、プライマリ ロードバランサがヘルスチェックに失敗したときに接続を受信するロードバランサです。

フェイルオーバーとフェイルバックは、ロードバランサ間でトラフィックを転送する自動プロセスです。Cloud DNS が停止を検出してプライマリ ロードバランサからバックアップ ロードバランサにトラフィックを転送するプロセスをフェイルオーバーといいます。Cloud DNS がこの逆の処理を行い、トラフィックをプライマリ ロードバランサにリダイレクトするプロセスをフェイルバックといいます。

フェイルオーバーの仕組み

外部アプリケーション ロードバランサのグローバルからリージョンへのフェイルオーバーは、トラフィックをフェイルオーバーするリージョンに 2 つ以上のリージョン外部アプリケーション ロードバランサを作成することで処理されます。バックアップ ロードバランサとして使用できるのは、リージョン外部アプリケーション ロードバランサのみです。リージョン外部アプリケーション ロードバランサは、個々の Google Cloud リージョン内で自己完結しているだけでなく、同じリージョンで実行されているグローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサのインフラストラクチャからも分離されています。

リージョン外部アプリケーション ロードバランサは、どちらも Envoy プロキシをベースにしています。トラフィックを非常によく似た方法で処理するため、グローバル外部アプリケーション ロードバランサのフェイルオーバー ロードバランサとして最適です。これは、トラフィックの処理方法に大きな違いがある従来のアプリケーション ロードバランサとは対照的です。

次のフェイルオーバー シナリオがサポートされています。

• グローバル外部アプリケーション ロードバランサからリージョン外部アプリケーション ロードバランサ
• リージョン外部アプリケーション ロードバランサからリージョン外部アプリケーション ロードバランサ
• 従来のアプリケーション ロードバランサからリージョン外部アプリケーション ロードバランサ

重要: このページで説明するフェイルオーバー構成は、プライマリ ロードバランサが使用できない場合にのみ、トラフィックがバックアップ ロードバランサにフェイルオーバーするアクティブ / パッシブ フェイルオーバー構成です。これは、Cloud DNS のフェイルオーバー ルーティング ポリシーを使用して実現します。リージョン外部アプリケーション ロードバランサは、アクティブ / アクティブ構成もサポートしています。これにより、複数のロードバランサを異なるリージョンにデプロイし、同時にトラフィックを処理できます。これは、Cloud DNS の位置情報ルーティング ポリシーを使用して構成できます。詳細については、リージョン外部アプリケーション ロードバランサの高可用性をご覧ください。

フェイルオーバーとフェイルバックのワークフロー

次の設定は、グローバル外部アプリケーション ロードバランサから 2 つのリージョン外部アプリケーション ロードバランサへのフェイルオーバーを示しています（グローバル ロードバランサがバックエンドをデプロイしたリージョンにそれぞれ 1 つずつあります）。

グローバル外部アプリケーション ロードバランサから 2 つのリージョン外部アプリケーション ロードバランサへのフェイルオーバー（クリックして拡大）

以降のセクションでは、フェイルオーバー構成にさまざまなコンポーネントが関係する一般的なワークフローについて説明します。

1. プライマリ ロードバランサの障害を検出する

   Google Cloud は、ヘルスチェックを使用して、プライマリ外部アプリケーション ロードバランサが正常かどうかを検出します。これらのヘルスチェックを構成して、3 つのソース リージョンからプローブを送信します。これらの 3 つのソース リージョンは、クライアントがロードバランサにアクセスするリージョンにする必要があります。たとえば、グローバル外部アプリケーション ロードバランサがあり、クライアント トラフィックのほとんどが北米とヨーロッパから発信される場合は、北米の 2 つのリージョンとヨーロッパの 1 つのリージョンから発信されるプローブを構成できます。

   これらのリージョンの 2 つ以上のリージョンから発信されたヘルスチェックが失敗すると、バックアップ リージョン外部アプリケーション ロードバランサへのフェイルオーバーがトリガーされます。

   追加情報:

   • ヘルスチェックを作成するときに、ソース リージョンを 3 つ指定する必要があります。ソース リージョンを指定できるのはグローバル ヘルスチェックのみです。
   • HTTP、HTTPS、TCP のヘルスチェックがサポートされています。
   • ヘルスチェック プローブは、構成された Google Cloud ソース リージョンから少し離れたインターネット上のポイント オブ プレゼンス（PoP）から発信されます。

2. バックアップ ロードバランサにトラフィックを転送する

   プライマリ ロードバランサでヘルスチェックが失敗すると、Google Cloud は Cloud DNS フェイルオーバー ルーティング ポリシーを使用して、バックアップ ロードバランサにトラフィックを転送する方法を決定します。

   停止時間（トラフィックがプライマリ ロードバランサからバックアップ ロードバランサにフェイルオーバーするまでの時間）は、DNS TTL 値、ヘルスチェック間隔、ヘルスチェックの異常しきい値によって決まります。推奨の設定については、ベスト プラクティスをご覧ください。

3. プライマリ ロードバランサにフェイルバックする

   ヘルスチェックに再び合格すると、プライマリ ロードバランサへのフェイルバックが自動的に行われます。バックアップ ロードバランサとプライマリ ロードバランサの両方がトラフィックを処理するため、フェイルバック中にダウンタイムが発生することはありません。

4. フェイルオーバーを定期的にテストする

   事業継続計画の一環として、フェイルオーバー ワークフローを定期的にテストすることをおすすめします。プライマリからバックアップ ロードバランサへのトラフィックの段階的シフトと即時シフトの両方をテストする必要があります。フェイルオーバーが機能していることを確認したら、フェイルバックをトリガーして、トラフィックが期待どおりにプライマリ ロードバランサにルーティングされることを確認します。

フェイルオーバーを構成する

フェイルオーバーを構成する手順は次のとおりです。

1. 既存のプライマリ ロードバランサの構成を確認し、プライマリ ロードバランサで使用されている機能（セキュリティ機能、トラフィック管理機能、ルーティング機能、CDN など）がバックアップ リージョン外部アプリケーション ロードバランサで使用できることを確認します。同様の機能を使用できない場合、このロードバランサはフェイルオーバーに適していない可能性があります。
2. プライマリ ロードバランサをできるだけミラーリングする構成で、バックアップ リージョン外部アプリケーション ロードバランサを作成します。
3. ヘルスチェックと DNS ルーティング ポリシーを作成して、障害を検出し、フェイルオーバー中にプライマリからバックアップ ロードバランサにトラフィックを転送するようにします。

プライマリ ロードバランサの構成を確認する

始める前に、バックアップ リージョン外部アプリケーション ロードバランサが、プライマリ ロードバランサで使用されているすべての機能をサポートしていることを確認します。

トラフィックの中断を回避するため、次の違いを確認してください。

• GKE の DeploymentGKE を利用している場合、GKE Gateway を使用してデプロイされたロードバランサは、GKE Ingress コントローラを使用してデプロイされたロードバランサよりも、このフェイルオーバー メカニズムとの互換性が高いことに注意してください。これは、GKE Gateway がグローバルとリージョンの両方の外部アプリケーション ロードバランサの構成をサポートしているためです。GKE Ingress コントローラは従来のアプリケーション ロードバランサのみをサポートしています。

  最適な結果を得るには、GKE Gateway を使用してプライマリ ロードバランサとバックアップ ロードバランサの両方をデプロイします。

• Cloud CDN。リージョン外部アプリケーション ロードバランサは Cloud CDN をサポートしていません。したがって、障害が発生した場合、Cloud CDN に依存するオペレーションも影響を受けます。冗長性を高めるには、Cloud CDN のフォールバックとして機能するサードパーティの CDN ソリューションを構成することをおすすめします。

• Google Cloud Armor。プライマリ ロードバランサに Google Cloud Armor を使用している場合は、バックアップ リージョン外部アプリケーション ロードバランサの構成時に同じ Google Cloud Armor 機能を構成してください。Google Cloud Armor には、リージョン スコープとグローバル スコープで使用できる機能があります。詳細については、Google Cloud Armor ドキュメントの次のセクションをご覧ください。

  • リージョン Google Cloud Armor セキュリティ ポリシー
  • グローバル Google Cloud Armor セキュリティ ポリシー

• SSL 証明書。プライマリ ロードバランサとバックアップ ロードバランサの両方に共通の SSL 証明書を使用する場合は、プライマリ ロードバランサで使用されている SSL 証明書のタイプが、バックアップ リージョン外部アプリケーション ロードバランサと互換性があることを確認します。グローバル ロードバランサ、リージョン ロードバランサ、従来のロードバランサで使用できる SSL 証明書の違いを確認します。詳しくは、次のセクションをご覧ください。

  • Compute Engine SSL 証明書
  • Certificate Manager SSL 証明書

• バックエンド バケット。リージョン外部アプリケーション ロードバランサは、バックエンドとして Cloud Storage バケットをサポートしていません。バックエンド バケットを使用してロードバランサのフェイルオーバーを設定することはできません。

バックアップ ロードバランサを構成する

バックアップ ロードバランサは、障害発生時にトラフィックをリダイレクトするリージョンに構成するリージョン外部アプリケーション ロードバランサです。

バックアップ ロードバランサを構成する際は、次の点に注意してください。

• トラフィックが両方のデプロイで同じように処理されるように、バックアップ リージョン外部アプリケーション ロードバランサの機能をプライマリ ロードバランサとできるだけ似た構成する必要があります。

  • グローバル外部アプリケーション ロードバランサ。リージョン外部アプリケーション ロードバランサは、いくつかの例外を除き、グローバル外部アプリケーション ロードバランサとほとんど同じ機能をサポートしています。リージョン ロードバランサは、グローバル ロードバランサと同じ高度なトラフィック管理機能をサポートしているため、プライマリ ロードバランサとバックアップ ロードバランサの同等性を簡単に実現できます。

  • 従来のアプリケーション ロードバランサ。従来のアプリケーション ロードバランサでは、プライマリ ロードバランサとバックアップ ロードバランサの機能の同等性を実現するのが困難です。これは、リージョン外部アプリケーション ロードバランサが、トラフィックを異なる方法で処理する Envoy ベースのロードバランサであるためです。本番環境にデプロイする前に、フェイルオーバーとフェイルバックを十分にテストしてください。

  リージョン、グローバル、従来のアプリケーション ロードバランサの特定の機能については、ロードバランサの機能の比較をご覧ください。

  Terraform などの自動化フレームワークを使用して、プライマリとバックアップのデプロイの両方でロードバランサ構成の一貫性を維持することをおすすめします。

• バックエンドがあるすべてのリージョンに、バックアップ リージョン外部アプリケーション ロードバランサを設定することをおすすめします。たとえば、5 つのリージョンにインスタンス グループがあるグローバル デプロイから 3 つのリージョンのバックアップ リージョン ロードバランサにフェイルオーバーする場合、残りの 2 つのリージョンのバックエンド サービスがアイドル状態である間に、これらの 3 つのリージョンのバックエンド サービスの負荷が高くなる可能性があります。

  また、プライマリ グローバル ロードバランサからこれらのバックアップ リージョン ロードバランサにフェイルオーバー トラフィックを再ルーティングするときに、重み付けラウンド ロビン ポリシーを使用するように Cloud DNS を構成することをおすすめします。異なるリージョンのバックエンド インスタンス グループの最大サイズを考慮して、各バックアップ ロードバランサに重みを割り当てます。

• リージョン外部アプリケーション ロードバランサは、プレミアムとスタンダードの両方の Network Service Tiers をサポートします。フェイルオーバー中のレイテンシが主な懸念事項でない場合は、スタンダード ティアを使用して、バックアップ リージョン外部アプリケーション ロードバランサを設定することをおすすめします。スタンダード ティアのインフラストラクチャを使用すると、グローバル外部アプリケーション ロードバランサで使用されるプレミアム ティアのインフラストラクチャからさらに分離されます。

• プライマリ ロードバランサとバックアップ ロードバランサの両方に同じバックエンドを使用する場合は、バックエンドがあるリージョンにバックアップ リージョン外部アプリケーション ロードバランサを作成します。バックエンド インスタンス グループで自動スケーリングを有効にしている場合は、デプロイ間でバックエンドを共有するための要件を満たす必要があります。

• 必要に応じて、リージョン外部アプリケーション ロードバランサ用に追加の Envoy プロキシを予約し、フェイルオーバー イベントの発生時に、追加のトラフィックが同じリージョン内の他のロードバランサのデプロイを妨げないようにします。詳細については、プロキシ専用サブネットの追加予約をご覧ください。

リージョン外部アプリケーション ロードバランサの構成方法については、VM インスタンス グループのバックエンドを使用してリージョン外部アプリケーション ロードバランサを設定するをご覧ください。

プロキシ専用サブネットの容量を追加で予約する

リージョンと VPC ネットワーク内の Envoy ベースのすべてのリージョン ロードバランサは、同じ Envoy プロキシのプールを共有します。フェイルオーバー イベントでは、バックアップ リージョン外部アプリケーション ロードバランサが、プライマリ ロードバランサからのフェイルオーバー トラフィックを処理するためにプロキシの使用量が増加します。バックアップ ロードバランサで常に容量を確保できるように、プロキシ専用サブネットのサイズを確認することをおすすめします。特定のリージョンでトラフィックを処理するために必要なプロキシ数の概算を計算し、必要に応じて容量を増やすことをおすすめします。また、フェイルオーバー イベントによって、同じリージョンとネットワーク内の他の Envoy ベースのリージョン ロードバランサが中断されないようにします。

通常、リージョン外部アプリケーション ロードバランサ プロキシは最大で次のものを管理できます。

• 1 秒あたり 600（HTTP）または 150（HTTPS）の新しい接続
• 3,000 のアクティブな接続
• 1 秒あたり 1,400 のリクエスト数

DNS ポリシーを使用して、異なるリージョンの複数のバックアップ ロードバランサにトラフィックを分割する場合は、リージョンとネットワークごとのプロキシ要件を見積も際に、この点を考慮する必要があります。プロキシ専用サブネットを大きくすると、必要に応じて Google Cloud がロードバランサに多くの Envoy プロキシを割り当てることができます。

プライマリ アドレス範囲と同じ方法（expand-ip-range コマンドを使用）で、プロキシ専用サブネットを拡張することはできません。代わりに、要件を満たすバックアップ プロキシ専用サブネットを作成し、アクティブなロールに昇格する必要があります。

プロキシ専用サブネットのサイズを変更する方法については、プロキシ専用サブネットのサイズまたはアドレス範囲を変更するをご覧ください。

プライマリ ロードバランサとバックアップ ロードバランサの間でバックエンドを共有する

インフラストラクチャの完全な冗長性を実現するには、ロードバランサ レベルとバックエンド レベルの両方で冗長性を確保する必要があります。バックアップ リージョン外部アプリケーション ロードバランサは、プライマリ ロードバランサと重複しないバックエンド（インスタンス グループまたはネットワーク エンドポイント グループ）で構成する必要があります。

ただし、プライマリとセカンダリのロードバランサ間でバックエンド インスタンス グループを共有し、インスタンス グループで自動スケーリングが有効になっている場合は、適切なフェイルオーバーが行われるように、次の要件を満たす必要があります。

• オートスケーラーは複数のシグナルで設定する必要があります。インスタンス グループには、CPU スケーリング シグナルとロードバランサの使用率シグナルを組み合わせて使用することをおすすめします。
• グローバル バックエンド サービスとリージョン バックエンド サービスの両方で、UTILIZATION バランシング モードのみを使用する必要があります。フェイルオーバー プロセスでインスタンスがグローバル ロードバランサとリージョン ロードバランサの両方から 2 倍のトラフィックを受信する可能性があるため、RATE バランシング モードの使用はおすすめしません。
• トラフィックがグローバル ロードバランサからリージョン ロードバランサに切り替わるダウンタイム中に、オートスケーラーがグループを早期にスケールダウンしないように、スケールイン制御を構成する必要があります。このダウンタイムは、DNS TTL と構成されたヘルスチェック間隔の合計になる場合があります。

自動スケーリングが正しく設定されていないと、フェイルオーバー中にグローバル ロードバランサからのトラフィックの損失により、インスタンス グループが急速に縮小するため、二次的な停止が発生する可能性があります。

Cloud DNS とヘルスチェックを構成する

このセクションでは、Cloud DNS と Google Cloud ヘルスチェックを使用して、Cloud Load Balancing 環境を構成し、障害を検出してバックアップ ロードバランサにトラフィックを転送する方法について説明します。

必要なヘルスチェック ポリシーとルーティング ポリシーを構成する手順は次のとおりです。

1. プライマリ ロードバランサの転送ルールの 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 に設定できます。

2. Cloud DNS で Cloud DNS レコードセットを作成し、ルーティング ポリシーを適用します。ドメイン名をプライマリ ロードバランサの転送ルールの IP アドレス、またはバックアップ ロードバランサの転送ルールの IP アドレスのいずれか（ヘルスチェックが失敗した場合）に解決するように、ルーティング ポリシーを構成する必要があります。

   gcloud beta dns record-sets create DNS_RECORD_SET_NAME \
       --ttl=TIME_TO_LIVE \
       --type=RECORD_TYPE \
       --zone="MANAGED_ZONE_NAME" \
       --routing-policy-type=FAILOVER \
       --routing-policy-primary-data=PRIMARY_LOAD_BALANCER_FORWARDING_RULE \
       --routing-policy-backup-data_type=GEO \
       --routing-policy-backup-data="BACKUP_REGION_1=BACKUP_LOAD_BALANCER_1_IP_ADDRESS[;BACKUP_REGION_2=BACKUP_LOAD_BALANCER_2_IP_ADDRESS;BACKUP_REGION_3=BACKUP_LOAD_BALANCER_3_IP_ADDRESS]" \
       --health-check=HEALTH_CHECK_NAME \
       --backup-data-trickle-ratio=BACKUP_DATA_TRICKLE_RATIO
   

   次のように置き換えます。

   • DNS_RECORD_SET_NAME: 追加するレコードセットの DNS またはドメイン名（例: test.example.com）
   • TIME_TO_LIVE: レコードセットの有効期間（TTL）の秒数。推奨される値については、ベスト プラクティスをご覧ください。
   • RECORD_TYPE: レコードタイプ（例: A）
   • MANAGED_ZONE_NAME: レコードセットを管理するマネージド ゾーンの名前（例: my-zone-name）
   • PRIMARY_LOAD_BALANCER_FORWARDING_RULE: プライマリ ロードバランサの転送ルール名
   • BACKUP_REGION: バックアップ ロードバランサがデプロイされているリージョン
   • BACKUP_LOAD_BALANCER_IP_ADDRESS: 各リージョンに対応するバックアップ ロードバランサの転送ルールの IP アドレス
   • BACKUP_DATA_TRICKLE_RATIO: プライマリ ロードバランサが正常な場合でも、バックアップ ロードバランサに送信するトラフィックの割合。この割合は 0～1 にする必要があります（0.1 など）。デフォルトは 0 に設定されています。

ベスト プラクティス

Cloud DNS レコードとヘルスチェックを構成する際のベスト プラクティスは次のとおりです。

• トラフィックがプライマリ ロードバランサからバックアップ ロードバランサにフェイルオーバーするまでの時間（つまり、停止時間）は、DNS TTL 値、ヘルスチェック間隔、ヘルスチェックの異常しきい値パラメータによって異なります。

  Google の Cloud DNS では、この期間の上限は次の式で計算できます。

  Duration of outage = DNS TTL + Health Check Interval * Unhealthy Threshold
  

  フェイルオーバー構成では、DNS TTL を 30～60 秒に設定することをおすすめします。TTL が長くなると、DNS がバックアップ リージョン外部アプリケーション ロードバランサにフェイルオーバーした後も、インターネット上のクライアントがプライマリ外部アプリケーション ロードバランサに引き続きアクセスするため、ダウンタイムが長くなります。

• 一時的なエラーによる不要なフェイルオーバーを回避するため、ヘルスチェックに正常しきい値と異常しきい値のパラメータを構成します。しきい値を高くすると、トラフィックがバックアップ ロードバランサにフェイルオーバーするまでの時間が長くなります。

• フェイルオーバー設定が期待どおりに機能するように、プライマリ ロードバランサが正常な場合でも、常にバックアップ ロードバランサに少量のトラフィックを送信するように DNS ルーティング ポリシーを設定できます。これを行うには、DNS レコードセットの作成時に --backup-data-trickle-ratio パラメータを使用します。

  バックアップに送信されるトラフィックの割合を、0～1 の割合で構成できます。一般的な値は 0.1 です。Cloud DNS では、トラフィックの 100% をバックアップ VIP アドレスに送信し、手動でフェイルオーバーをトリガーすることもできます。