インフラストラクチャの停止や構成エラーから保護するために、グローバル外部アプリケーション ロードバランサのフェイルオーバー戦略を設計できます。これらの戦略では、リージョン外部アプリケーション ロードバランサを使用し、グローバル外部アプリケーション ロードバランサからトラフィックをルーティングして、グローバル インフラストラクチャの停止や構成エラーが発生した場合でも高可用性を維持します。
フェイルオーバー アーキテクチャでは、プライマリ ロードバランサと 1 つ以上のバックアップ ロードバランサをデプロイします。
- プライマリ ロードバランサは、通常の運用中にクライアント トラフィックを処理するグローバル外部アプリケーション ロードバランサです。
- バックアップ ロードバランサは、プライマリ ロードバランサがヘルスチェックに失敗したときにトラフィックを受信するリージョン外部アプリケーション ロードバランサです。
フェイルオーバーとフェイルバックは、トラフィックを自動的に転送するプロセスです。
- フェイルオーバーは、Cloud DNS が停止を検出し、プライマリ ロードバランサからバックアップ ロードバランサにトラフィックを転送するときに発生します。
- フェイルバックは、Cloud DNS がこのルーティングを逆転させ、ヘルスチェックに合格した後でトラフィックをプライマリ ロードバランサにリダイレクトするときに発生します。
このドキュメントでは、グローバル外部アプリケーション ロードバランサからリージョン バックアップ ロードバランサへのフェイルオーバーについて説明します。異なるリージョンにまたがるリージョン外部アプリケーション ロードバランサ間のフェイルオーバーを構成する場合は、リージョン外部アプリケーション ロードバランサの高可用性をご覧ください。
フェイルオーバーにリージョン ロードバランサを使用する理由
リージョン外部アプリケーション ロードバランサは、次のプロパティがあるため、グローバル外部アプリケーション ロードバランサのフェイルオーバー ロードバランサとして最適です。
- リージョン外部アプリケーション ロードバランサは、個々のGoogle Cloud リージョン内で自己完結しており、同じリージョンで実行されているグローバル外部アプリケーション ロードバランサのインフラストラクチャからも分離されています。
- リージョン外部アプリケーション ロードバランサとグローバル外部アプリケーション ロードバランサはどちらも Envoy プロキシをベースにしており、トラフィックを同様の方法で処理します。
グローバル外部アプリケーション ロードバランサのグローバルからリージョンへのフェイルオーバーを実装するには、トラフィックをフェイルオーバーするリージョンに 2 つ以上のリージョン外部アプリケーション ロードバランサを作成します。
フェイルオーバー戦略
次の戦略を使用して、グローバル外部アプリケーション ロードバランサのフェイルオーバーを実装できます。
- アクティブ / パッシブ（グローバルからリージョンへのフェイルオーバー）: バックアップのみを目的として、1 つ以上のリージョン外部アプリケーション ロードバランサをデプロイします。定常状態では、Cloud DNS はグローバル外部アプリケーション ロードバランサの IP アドレスに解決されます。グローバル ロードバランサに障害が発生すると、Cloud DNS はトラフィックをバックアップ リージョン ロードバランサに転送します。この構成では、Cloud DNS のフェイルオーバー ルーティング ポリシーを使用します。
- アクティブ / アクティブ（グローバルからリージョンへのバイパス）: グローバル外部アプリケーション ロードバランサは、エッジ キャッシュなどの Cloud CDN 機能を提供するエッジ フロントエンドとして機能し、完全修飾ドメイン名（FQDN）を持つインターネット ネットワーク エンドポイント グループ（NEG）を使用して、リクエストをリージョン外部アプリケーション ロードバランサに転送します。安定状態では、トラフィックは両方のロード バランシング レイヤを順番に通過します。これは、Cloud DNS の位置情報ルーティング ポリシーを使用して構成できます。グローバル ロードバランサで停止が発生した場合、DNS ルーティング ポリシーはグローバル レイヤをバイパスし、クライアント トラフィックをリージョン ロードバランサに直接転送します。
ベスト プラクティスとして、アーキテクチャが容量認識型のグローバル バックエンド ロード バランシングに依存していない場合は、アクティブ / アクティブ戦略を優先します。ただし、アプリケーションでグローバル バックエンド ロード バランシングを使用して、バックエンド容量に基づいてリージョン間でトラフィックを分散およびスピルオーバーする必要がある場合は、アクティブ / パッシブ戦略を実装します。
フェイルオーバー戦略の比較
次の表に、アクティブ / パッシブとアクティブ / アクティブのフェイルオーバー戦略の比較を示します。
| 戦略属性 | アクティブ / パッシブ | アクティブ / アクティブ |
|---|---|---|
| 定常状態のトラフィック フロー | クライアント → グローバル外部アプリケーション ロードバランサ → バックエンド | クライアント → グローバル外部アプリケーション ロードバランサ → リージョン外部アプリケーション ロードバランサ → バックエンド |
| 障害状態のトラフィック フロー | クライアント → リージョン外部アプリケーション ロードバランサ → バックエンド。 サービスは引き続き利用できますが、エッジ パフォーマンスのメリットが失われるため、レイテンシが長くなる可能性があります。 |
クライアント → リージョン外部アプリケーション ロードバランサ → バックエンド（グローバル外部アプリケーション ロードバランサをバイパス）。 サービスは引き続き利用できますが、エッジ パフォーマンスのメリットが失われるため、レイテンシが長くなる可能性があります。 |
| 構成管理 | グローバル ロードバランサとリージョン ロードバランサ間で独立した構成を同期する必要があります。 | ほとんどのアプリケーション ロジックがリージョン ロードバランサに存在するため、グローバル レイヤに必要な構成は最小限です。ただし、両方のレイヤでエッジ セキュリティ ポリシー（Cloud Armor）と接続終了構成（TLS 証明書）を複製する必要があります。 |
| 信頼性の確認 | リージョン外部アプリケーション ロードバランサは定常状態でアイドル状態です。定期的なテストまたは DNS トリックル トラフィックをおすすめします。 | 定常状態のトラフィックは、リージョン外部アプリケーション ロードバランサを継続的にテストします。リージョン ロードバランサへの定期的なテストまたはトリクル トラフィックを直接行うことをおすすめします。 |
| プログレッシブ デプロイの安全性 | グローバル外部アプリケーション ロードバランサの構成変更はグローバルに適用されます。リージョン外部アプリケーション ロードバランサの変更は分離されますが、定常状態のトラフィックではテストされません。 | リージョン外部アプリケーション ロードバランサの変更は、リージョンごとに段階的に適用できます。リージョンで障害が発生した場合、グローバル レイヤはトラフィックを自動的に正常なリージョンに転送します。 |
| グローバル バックエンド ロード バランシング | サポート対象 グローバル外部アプリケーション ロードバランサは、容量に基づいて異なるリージョンのバックエンド間でトラフィックを分散できます。 |
限定的 グローバル外部アプリケーション ロードバランサは、トラフィックを最も近いリージョン外部アプリケーション ロードバランサに転送します。リージョン ロードバランサはトラフィックをローカルでのみ分散し、バックエンド容量に基づいてリージョン間でトラフィックを分散しません。 |
| 費用と請求 | データ処理手数料は、単一のロード バランシング レイヤに適用されます。定常状態では、費用はグローバル外部アプリケーション ロードバランサから発生します。リージョン外部アプリケーション ロードバランサの料金は、テストまたはフェイルオーバー イベントの期間にのみ適用されます。 | トラフィックは定常状態でグローバル ティアとリージョン ティアの両方を通過するため、両方のロード バランシング レイヤでデータ処理料金が同時に発生します。 |
| 推奨ユースケース | 高度なグローバル バックエンド ロード バランシングと、リージョン間の容量ベースのトラフィック スピルオーバーを必要とするワークロード。 | エッジ パフォーマンスとキャッシュ保存にグローバル レイヤを使用する、リージョン分離を中心に設計されたワークロード。 |
アクティブ / パッシブ戦略
アクティブ / パッシブ構成では、1 つ以上のリージョンに独立したリージョン外部アプリケーション ロードバランサを、プライマリ グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサとともにデプロイします。
アクティブ - パッシブ フェイルオーバーの仕組み
次の設定は、グローバル外部アプリケーション ロードバランサから 2 つのバックアップ リージョン外部アプリケーション ロードバランサへのフェイルオーバーを示しています（グローバル ロードバランサがバックエンドをデプロイしたリージョンにそれぞれ 1 つずつあります）。
アクティブ / パッシブ フェイルオーバーは、次のワークフローに従います。
- 定常状態: Cloud DNS は、すべてのクライアント トラフィックをグローバル外部アプリケーション ロードバランサに転送します。
- 障害検出: Google Cloud は、3 つのソース リージョンで構成されたヘルスチェックを使用して、プライマリ ロードバランサが正常かどうかを検出します。2 つ以上のソース リージョンから発信されたヘルスチェックが失敗すると、Cloud DNS はフェイルオーバーをトリガーします。
- フェイルオーバー: Cloud DNS フェイルオーバー ルーティング ポリシーは、クライアント トラフィックをバックアップ リージョン外部アプリケーション ロードバランサに直接転送します。フェイルオーバー中のレイテンシの影響: リージョン外部アプリケーション ロードバランサは特定の Google Cloud リージョン内で接続を終了するため、宛先リージョンから遠く離れたクライアントは、フェイルオーバーがアクティブな間、レイテンシと往復時間（RTT）が増加する可能性があります。
- フェイルバック: ヘルスチェックが再び成功すると、両方のロードバランサがトラフィックを処理しているため、Cloud DNS はダウンタイムなしでトラフィックをプライマリ ロードバランサに自動的に復元します。
アクティブ / アクティブ戦略（グローバルからリージョンへのバイパス）
アクティブ / アクティブ戦略では、グローバル外部アプリケーション ロードバランサはインターネット FQDN NEG（INTERNET_FQDN_PORT）を使用して、2 つ以上のリージョンのリージョン外部アプリケーション ロードバランサにトラフィックを送信します。
アクティブ - アクティブ バイパスの仕組み
次の設定は、グローバル外部アプリケーション ロードバランサから 2 つのバックアップ リージョン外部アプリケーション ロードバランサへのフェイルオーバーを示しています（グローバル ロードバランサがバックエンドをデプロイしたリージョンにそれぞれ 1 つずつあります）。
アクティブ / アクティブ フェイルオーバーは次のワークフローに従います。
- 定常状態: トラフィックはクライアントからグローバル外部アプリケーション ロードバランサに流れます。グローバル ロードバランサは、タイプ
INTERNET_FQDN_PORTのインターネット FQDN ネットワーク エンドポイント グループ（NEG）を使用して、トラフィックを最も近いリージョン外部アプリケーション ロードバランサに転送します。リージョン ロードバランサは、トラフィックをローカル バックエンドに配信します。 - 障害検出: 定常状態で、単一のリージョン外部アプリケーション ロードバランサまたはそのリージョンで障害が発生した場合、グローバル外部アプリケーション ロードバランサは、インターネット NEG の Cloud DNS ヘルスチェック ポリシーを使用して障害を検出します。グローバル ロードバランサは、異常なリージョンから正常なリージョン ロードバランサにトラフィックを自動的に転送します。
- バイパス: グローバル外部アプリケーション ロードバランサで停止が発生した場合、Cloud DNS フェイルオーバー ポリシーは障害を検出し、トラフィックをリージョン外部アプリケーション ロードバランサに直接転送して、グローバル レイヤを完全にバイパスします。バイパス中のレイテンシの影響: グローバル外部アプリケーション ロードバランサは、ユーザーに近い場所での接続の終端やエッジ キャッシュ保存などのエッジ パフォーマンスのメリットを提供します。トラフィックがグローバル ロードバランサをバイパスすると、クライアント接続はリージョン VIP と直接確立されます。これにより、地理的に離れたクライアントの接続レイテンシと RTT が増加する可能性があります。
- フェイルバック: グローバル ロードバランサが連続してヘルスチェックに合格すると、Cloud DNS は DNS レスポンスでグローバル エニーキャスト VIP の返信を自動的に再開し、グローバル エッジ ルーティング階層を復元します。
プライマリ ロードバランサの構成を確認する
フェイルオーバーを構成する前に、バックアップ リージョン外部アプリケーション ロードバランサがプライマリ ロードバランサで使用されている機能をサポートしていることを確認します。
- アクティブ / パッシブ モードでは、バックアップ リージョン ロードバランサは、停止時にトラフィックをシームレスに引き継ぐために、同様の機能をサポートする必要があります。
- アクティブ / アクティブ モードでは、コア ルーティングとセキュリティ ルールはリージョン ティアで直接構成する必要があります。一方、Cloud CDN などのグローバル エッジ機能は、グローバル停止時にバイパスされます。
| 機能 | 互換性要件 |
|---|---|
| Google Kubernetes Engine デプロイ | GKE Gateway を使用して、プライマリ ロードバランサとバックアップ ロードバランサの両方をデプロイします。これは、GKE Gateway を使用してデプロイされたロードバランサは、GKE Ingress コントローラを使用してデプロイされたロードバランサよりも、このフェイルオーバー メカニズムとの互換性が高いためです。GKE Ingress コントローラは、従来のアプリケーション ロードバランサのみをサポートしています。 |
| Cloud CDN | リージョン外部アプリケーション ロードバランサは Cloud CDN をサポートしていません。フェイルオーバーが発生すると、Cloud CDN に依存するオペレーションが影響を受けます。 |
| Cloud Armor | プライマリ ロードバランサで Cloud Armor を使用する場合は、バックアップ ロードバランサで同等のリージョン Cloud Armor セキュリティ ポリシーを構成します。Cloud Armor には、リージョン スコープとグローバル スコープで使用できる機能があります。詳細については、リージョン Cloud Armor セキュリティ ポリシーとグローバル Cloud Armor セキュリティ ポリシーをご覧ください。 |
| SSL 証明書 | プライマリ ロードバランサで使用されている SSL 証明書のタイプが、バックアップ リージョン外部アプリケーション ロードバランサと互換性があることを確認します。グローバル ロードバランサ、リージョン ロードバランサ、従来のロードバランサで使用できる SSL 証明書の違いを確認します。詳細については、Compute Engine SSL 証明書と Certificate Manager SSL 証明書をご覧ください。 |
リージョン ロードバランサに関する考慮事項
障害発生時にトラフィックをリダイレクトするリージョンに、リージョン外部アプリケーション ロードバランサを構成してデプロイします。
リージョン ロードバランサを構成する際は、フェイルオーバーまたはバイパス アーキテクチャに関する次の考慮事項に注意してください。
トラフィックが両方のデプロイで同じように処理されるように、バックアップ リージョン外部アプリケーション ロードバランサの機能をプライマリ ロードバランサとできるだけ似た構成する必要があります。
グローバル外部アプリケーション ロードバランサ。リージョン外部アプリケーション ロードバランサは、いくつかの例外を除き、グローバル外部アプリケーション ロードバランサとほとんど同じ機能をサポートしています。リージョン ロードバランサは、グローバル ロードバランサと同じ高度なトラフィック管理機能をサポートしているため、プライマリ ロードバランサとバックアップ ロードバランサの同等性を簡単に実現できます。
従来のアプリケーション ロードバランサ。従来のアプリケーション ロードバランサでは、プライマリ ロードバランサとバックアップ ロードバランサの機能の同等性を実現するのが困難です。これは、リージョン外部アプリケーション ロードバランサが、トラフィックを異なる方法で処理する Envoy ベースのロードバランサであるためです。本番環境にデプロイする前に、フェイルオーバーとフェイルバックを十分にテストしてください。
リージョン、グローバル、従来のアプリケーション ロードバランサの特定の機能については、ロードバランサの機能の比較をご覧ください。
Terraform などの自動化フレームワークを使用して、プライマリとバックアップのデプロイの両方でロードバランサ構成の一貫性を維持することをおすすめします。
リージョン外部アプリケーション ロードバランサは、プレミアムとスタンダードの両方の Network Service Tiers をサポートします。フェイルオーバー中のレイテンシが主な懸念事項でない場合は、スタンダード ティアを使用して、バックアップ リージョン外部アプリケーション ロードバランサを設定することをおすすめします。スタンダード ティアのインフラストラクチャを使用すると、グローバル外部アプリケーション ロードバランサで使用されるプレミアム ティアのインフラストラクチャからさらに分離されます。
プロキシ専用サブネットのサイズが、フェイルオーバー イベント中にトラフィックが増加しても、同じリージョンとネットワーク内の他のリージョン ロードバランサを中断しないように十分な大きさであることを確認します。詳細については、プロキシ専用サブネットの追加予約をご覧ください。
リージョン外部アプリケーション ロードバランサを構成する方法については、VM インスタンス グループのバックエンドを使用してリージョン外部アプリケーション ロードバランサを設定するをご覧ください。
プロキシ専用サブネットの容量を追加で予約する
リージョンと VPC ネットワーク内の Envoy ベースのすべてのリージョン ロードバランサは、同じ Envoy プロキシのプールを共有します。フェイルオーバー イベントでは、バックアップ リージョン外部アプリケーション ロードバランサが、プライマリ ロードバランサからのフェイルオーバー トラフィックを処理するためにプロキシの使用量が増加します。十分なプロキシ容量を予約すると、フェイルオーバー イベントによって、同じリージョンとネットワーク内の他の Envoy ベースのリージョン ロードバランサが中断されないようにできます。
バックアップ ロードバランサで常に容量を確保できるように、プロキシ専用サブネットのサイズを確認します。特定のリージョンでトラフィックを処理するために必要なプロキシ数の概算を計算し、必要に応じて容量を増やすことをおすすめします。プロキシ容量の上限とサイズ設定の計算の詳細については、「Cloud Load Balancing の料金」のプロキシ インスタンスの料金セクションをご覧ください。
DNS ポリシーを使用して、異なるリージョンの複数のバックアップ ロードバランサにトラフィックを分割する場合は、リージョンとネットワークごとのプロキシ要件を見積もる際に、この点を考慮する必要があります。プロキシ専用サブネットを大きくすると、必要に応じてGoogle Cloud がロードバランサに多くの Envoy プロキシを割り当てることができます。
プライマリ アドレス範囲と同じ方法（expand-ip-range コマンドを使用）で、プロキシ専用サブネットを拡張することはできません。代わりに、要件を満たすバックアップ プロキシ専用サブネットを作成し、アクティブなロールに昇格する必要があります。
プロキシ専用サブネットのサイズを変更する方法については、プロキシ専用サブネットのサイズまたはアドレス範囲を変更するをご覧ください。
プライマリ ロードバランサとバックアップ ロードバランサの間でバックエンドを共有する
インフラストラクチャの完全な冗長性を実現するには、ロードバランサ レベルとバックエンド レベルの両方で冗長性を確保する必要があります。バックアップ リージョン外部アプリケーション ロードバランサは、プライマリ ロードバランサと重複しないバックエンド（インスタンス グループまたはネットワーク エンドポイント グループ）で構成する必要があります。
プライマリ ロードバランサとバックアップ ロードバランサの両方に同じバックエンドを使用する場合は、バックエンドがあるリージョンに各バックアップ リージョン外部アプリケーション ロードバランサを作成する必要があります。また、インスタンス グループで自動スケーリングが有効になっている場合は、適切なフェイルオーバーが行われるように、次の要件を満たす必要があります。
- オートスケーラーは、CPU ベースのスケーリングのみで構成します。ロードバランサの使用率に基づく自動スケーリングはサポートされていません。
- グローバル バックエンド サービスとリージョン バックエンド サービスの両方で、
UTILIZATIONバランシング モードのみを使用する必要があります。フェイルオーバー プロセスでインスタンスがグローバル ロードバランサとリージョン ロードバランサの両方から 2 倍のトラフィックを受信する可能性があるため、RATEバランシング モードは使用しないでください。 - トラフィックがグローバル ロードバランサからリージョン ロードバランサに切り替わるダウンタイム中に、オートスケーラーがグループを早期にスケールダウンしないように、スケールイン制御を構成します。このダウンタイムは、DNS TTL（有効期間）と構成されたヘルスチェック間隔の合計になる場合があります。
自動スケーリングが正しく設定されていないと、フェイルオーバー中にグローバル ロードバランサからのトラフィックの損失により、リージョン ロードバランサが引き継ぐ前にインスタンス グループが急速に縮小するため、二次的な停止が発生する可能性があります。
アクティブ / パッシブ フェイルオーバーを構成する
アクティブ / パッシブ フェイルオーバーを構成する手順は次のとおりです。
- アーキテクチャの考慮事項を確認する: リソースを作成する前に、リージョン ロードバランサの考慮事項を確認して、機能の互換性、プロキシ容量、共有バックエンドの自動スケーリング要件を確認します。
- プライマリ ロードバランサを構成する: 1 つ以上のリージョンに分散されたバックエンド サービスを使用して、グローバル外部アプリケーション ロードバランサを設定します。グローバル外部アプリケーション ロードバランサの構成方法については、グローバル外部アプリケーション ロードバランサを設定するをご覧ください。
- プライマリ ロードバランサの構成を確認する: プライマリ ロードバランサで使用されている機能（セキュリティ機能、トラフィック管理機能、ルーティング機能、Cloud CDN など）がバックアップ リージョン外部アプリケーション ロードバランサで使用できることを確認します。同様の機能を使用できない場合、このロードバランサはフェイルオーバーに適していない可能性があります。
- バックアップ リージョン外部アプリケーション ロードバランサを構成する: トラフィックをフェイルオーバーするリージョンに、独立したリージョン外部アプリケーション ロードバランサを設定します。リージョン外部アプリケーション ロードバランサの構成方法については、VM インスタンス グループのバックエンドを使用してリージョン外部アプリケーション ロードバランサを設定するをご覧ください。
- DNS ルーティングとヘルスチェックを構成する: プライマリ ロードバランサのヘルスチェックを作成し、Cloud DNS フェイルオーバー ルーティング ポリシーを構成して、障害を検出し、クライアント トラフィックをバックアップ リージョン ロードバランサに転送します。
アクティブ / アクティブ バイパスを構成する
アクティブ / アクティブ アーキテクチャを構成する手順は次のとおりです。
アーキテクチャの考慮事項を確認する: リソースを作成する前に、リージョン ロードバランサの考慮事項を確認して機能の互換性を確認し、プロキシ専用サブネットの容量が定常状態とフェイルオーバー トラフィックを処理できることを確認します。
リージョン外部アプリケーション ロードバランサを構成する: リージョン ロードバランサを構成する前に、機能の互換性と制限事項を確認してください。バックエンド サービス、外部 IP アドレス、SSL 証明書、リージョン Cloud Armor セキュリティ ポリシーを使用して、2 つ以上のリージョンにリージョン外部アプリケーション ロードバランサをデプロイします。設定手順については、VM インスタンス グループのバックエンドを使用してリージョン外部アプリケーション ロードバランサを設定するをご覧ください。
リージョン ロードバランサの DNS を構成する: 位置情報またはレイテンシ ルーティング ポリシーを使用して、リージョン外部アプリケーション ロードバランサの外部 IP アドレスを参照する DNS レコード（
regional-api.example.comなど）を作成します。このレコードで DNS ヘルスチェックを有効にして、特定のリージョンで障害を検出し、トラフィックをそのリージョンから他の正常なリージョンに自動的に転送します。グローバル外部アプリケーション ロードバランサを構成する: グローバル外部 IP アドレスを予約し、タイプ
INTERNET_FQDN_PORTのグローバル インターネット ネットワーク エンドポイント グループ（NEG）を作成します。リージョン DNS レコードの FQDN（例:regional-api.example.com）を指すエンドポイントをインターネット NEG に追加します。グローバル外部アプリケーション ロードバランサのバックエンド サービスを構成し、インターネット NEG を接続して、必要に応じて Cloud CDN または Cloud Armor を有効にします。URL マップ、ターゲット HTTP(S) プロキシ、グローバル転送ルールを構成します。フェイルオーバーとヘルスチェック用に DNS を構成する:
FAILOVERルーティング ポリシーを使用して、メイン サービス DNS レコード（api.example.comなど）を作成します。レコードセットのプライマリ エンドポイントがグローバル外部アプリケーション ロードバランサの IP アドレスを指し、バックアップ エンドポイントがリージョン外部アプリケーション ロードバランサの外部 IP アドレスを指していることを確認します。DNS ヘルスチェックを構成して、グローバル外部アプリケーション ロードバランサをモニタリングします。
ベスト プラクティス
Cloud DNS レコードとヘルスチェックを構成する際は、次のベスト プラクティスに留意してください。
停止期間を計算する: トラフィックがプライマリ ロードバランサからバックアップ ロードバランサにフェイルオーバーするのに必要な時間は、DNS TTL、ヘルスチェック間隔、ヘルスチェックの異常しきい値パラメータによって異なります。
Google の Cloud DNS では、この期間の上限は次の式で計算できます。
Duration of outage = DNS TTL + Health Check Interval * Unhealthy ThresholdDNS TTL を 30 ～ 60 秒に設定します。TTL 値が大きいと、DNS がバックアップ リージョン外部アプリケーション ロードバランサにフェイルオーバーした後も、インターネット上のクライアントがプライマリ外部アプリケーション ロードバランサに引き続きアクセスするため、フェイルオーバー時間が長くなります。
ヘルスチェックのしきい値を構成する: 一時的なネットワーク エラーによるフェイルオーバーを回避するために、正常しきい値と異常しきい値のパラメータを設定します。しきい値を高くすると、トラフィックがバックアップ ロードバランサにフェイルオーバーするまでの時間が長くなります。
検証にトリクル トラフィックを使用する:
--backup-data-trickle-ratioフラグを構成して、プライマリ ロードバランサが正常な場合でも、バックアップ ロードバランサに少量のトラフィックを継続的に送信します。これにより、バックアップ インフラストラクチャがアクティブになり、トラフィックを処理できるようになります。バックアップ ロードバランサに送信されるトラフィックの割合を、0 ～ 1 の割合で構成できます。一般的な値は 0.1 です。Cloud DNS では、トラフィックの 100% をバックアップ VIP アドレスに送信し、手動でフェイルオーバーをトリガーすることもできます。フェイルオーバーとフェイルバックを定期的にテストする: 障害復旧計画にフェイルオーバー テストを含めます。プライマリ ロードバランサからバックアップ ロードバランサへのトラフィックの段階的シフトと突然のシフトの両方を確認し、フェイルバック後にトラフィックがプライマリ ロードバランサにスムーズに戻ることを確認します。