Compute Engine でフローティング IP アドレスを使用するパターン

Last reviewed 2024-01-29 UTC

このドキュメントでは、アプリケーションをオンプレミス ネットワーク環境から Compute Engine に移行する際に、フローティング IP アドレスの実装パターンを使用する方法について説明します。このドキュメントは、Google Cloud にアプリケーションを移行するネットワーク エンジニア、システム管理者、オペレーション エンジニアを対象としています。

フローティング IP アドレスは、共有 IP アドレスや仮想 IP アドレスとも呼ばれ、オンプレミス ネットワーク環境の可用性を高めるために使用されることがよくあります。フローティング IP アドレスを使用すると、同一構成の複数の物理サーバーや仮想サーバーに、同じ IP アドレスを渡せます。そうすることで、フェイルオーバーや本番環境ソフトウェアのアップグレードが可能になります。ただし、フローティング IP アドレスを Compute Engine 環境に直接実装するには、アーキテクチャをこのドキュメントで説明するパターンのいずれかに変更する必要があります。

このドキュメントに付随する GitHub リポジトリには、Terraform を使用して自動的にデプロイできる各パターンのサンプル デプロイが含まれています。

オンプレミス環境でのフローティング IP アドレス

フローティング IP アドレスはオンプレミス環境でよく使用されます。ユースケースの例を以下に示します。

• 複数のファイアウォールやロードバランサのセットなどの可用性の高い物理アプライアンスでは、フェイルオーバーのためにフローティング IP アドレスがよく使用されます。
• 通常、高可用性を必要とするサーバーでは、フローティング IP アドレスが使用されます。たとえば、プライマリ サーバーとバックアップ サーバーを使用するリレーショナル データベースなどです。一般的な例では、Microsoft SQL Server が AlwaysOn 可用性グループを使用します。これらのパターンを Google Cloud に実装する方法については、同期 commit を使用して SQL Server AlwaysOn 可用性グループを構成するをご覧ください。
• ロードバランサまたはリバース プロキシを実装する Linux 環境では、IP Virtual Server（IPVS）、HAProxy、および nginx などのフローティング IP アドレスを使用します。ノード障害を検出してインスタンス間でフローティング IP アドレスを移動する場合、これらの環境では Hartbeat、Pacemaker、または Keepalived などのデーモンを使用します。
• Windows Server フェイルオーバー クラスタリングを備えた高可用性の Windows サービスでは、高可用性を確保するためにフローティング IP アドレスが使用されます。Google Cloud でフェイルオーバー クラスタリングを使用して Windows サービスを実装するには、Windows Server フェイルオーバー クラスタリングの実行をご覧ください。

オンプレミス環境でフローティング IP アドレスを実装する方法は、いくつかあります。フローティング IP アドレスを共有するサーバーは通常、ハートビート メカニズムを介して状態情報を共有します。このメカニズムにより、サーバーは、お互いのヘルス ステータスをやり取りできます。プライマリ サーバーで障害が発生した場合にセカンダリ サーバーがフローティング IP アドレスを引き継ぐこともできます。このスキームは、ほとんどの場合、Virtual Router Redundancy Protocol を使用して実装されますが、他の同様のメカニズムを使用することもできます。

IP アドレス フェイルオーバーが開始されると、フローティング IP アドレスを引き継いだサーバーがそのアドレスをネットワーク インターフェースに追加します。サーバーは、Gratuitous Address Resolution Protocol（ARP）フレームを送信することで、レイヤ 2 を使用している他のデバイスにこの引き継ぎを通知します。または、IP アドレスが Open Shortest Path First（OSPF）などのルーティング プロトコルによって上流のレイヤ 3 ルーターに通知されることがあります。

次の図は、オンプレミス環境での一般的な設定を示しています。

上図は、同じスイッチに接続されたプライマリ サーバーとセカンダリ サーバーがハートビート メカニズムを介して応答性情報を交換する方法を示しています。プライマリ サーバーで障害が発生すると、セカンダリ サーバーが Gratuitous ARP フレームをスイッチに送信して、フローティング IP アドレスを取得します。

オンプレミス ロード バランシング ソリューション（Windows ネットワーク ロード バランシングや IPVS などの直接サーバー レスポンスを使用した Linux ロード バランシングなど）とは若干異なる設定を使用します。この場合、そのサービスも Gratuitous ARP フレームを送出しますが、もう一方のサーバーの MAC アドレスを Gratuitous ARP 送信元として送信します。実質上、このアクションは ARP フレームを偽装して、別のサーバーのソース IP アドレスを引き継ぎます。

この操作は、ある IP アドレスの負荷を異なるサーバーに分散するために行われます。ただし、このような設定はこのドキュメントの範囲外です。ほとんどの場合、フローティング IP アドレスをオンプレミス ロード バランシングに使用する場合は、Cloud Load Balancing に移行することをおすすめします。

フローティング IP アドレスを Compute Engine に移行する際の課題

Compute Engine は、Virtual Private Cloud（VPC）ネットワークで仮想化されたネットワーク スタックを使用するため、Google Cloud 側の変更がない一般的な実装メカニズムは機能しません。たとえば、VPC ネットワークはソフトウェア定義ネットワークで ARP リクエストを処理しますが、Gratuitous ARP フレームは無視します。加えて、OSPF や境界ゲートウェイ プロトコル（BGP）などの標準のルーティング プロトコルを使用して VPC ネットワーク ルーティング テーブルを直接変更することができません。フローティング IP アドレスの一般的な仕組みは、データリンク層によって処理される ARP リクエストか、OSPF や BGP でプログラムできるネットワーク層に依存します。したがって、Google Cloud では、こうした仕組みを使用して IP アドレスがフェイルオーバーされることはありません。オンプレミスのフローティング IP アドレスを使用して仮想マシン（VM）イメージを移行する場合は、アプリケーションを変更することなく、フローティング IP アドレスをフェイルオーバーすることはできません。

オーバーレイ ネットワークを使用すれば、ARP リクエストを使用した完全なレイヤ 2 通信と IP 引き継ぎを可能にする構成を作成できます。ただし、オーバーレイ ネットワークの設定は複雑なため、Compute Engine ネットワーク リソースの管理が難しくなります。この方法もこのドキュメントでは対象外です。代わりに、このドキュメントでは、オーバーレイ ネットワークを作成することなく Compute Engine ネットワーキング環境でフェイルオーバー シナリオを実装するためのパターンについて説明します。

可用性と信頼性に優れたアプリケーションを Compute Engine に実装するには、水平方向のスケーリング アーキテクチャを使用します。このタイプのアーキテクチャは、単一ノードの障害の影響を最小限に抑えます。

このドキュメントでは、フローティング IP アドレスを使用して、既存のアプリケーションをオンプレミスから Compute Engine に移行する複数のパターンについて説明します。このパターンには、次のものがあります。

• ロード バランシングを使用したパターン:
  • アクティブ - アクティブ ロード バランシング
  • フェイルオーバー グループとアプリケーションの公開ヘルスチェックを使用したロード バランシング
  • フェイルオーバー グループとハートビートの公開ヘルスチェックを使用したロード バランシング
• Google Cloud のルートを使用したパターン:
  • ECMP ルートの使用
  • 優先順位が異なるルートの使用
  • ハートビート メカニズムを使用したルートのネクストホップの切り替え
• 自動修復を使用したパターン:
  • 自動修復単一インスタンスの使用

VM インスタンス間で移動するエイリアス IP アドレスの使用は、高可用性要件を満たさないため、フェイルオーバーの仕組みとしてはおすすめしません。特定の障害シナリオ（ゾーン障害イベントなど）で、インスタンスからエイリアス IP アドレスを削除できない場合があります。したがって、別のインスタンスにその IP アドレスを追加できず、フェイルオーバーが不可能になる可能性があります。

ユースケースに対するパターンの選択

要件によっては、このソリューションで説明しているパターンの 1 つ以上がオンプレミス環境でフローティング IP アドレスの実装に利用できることがあります。

アプリケーションの使用に最適なパターンを決定する際は、次の要素を検討してください。

• フローティング内部またはフローティング外部 IP アドレス: フローティング IP アドレスを必要とするほとんどのアプリケーションは、フローティング内部 IP アドレスを使用します。通常、外部アプリケーションへのトラフィックはロード バランシングする必要があるため、フローティング外部 IP アドレスを使用するアプリケーションはほとんどありません。

  このセクションに後記する表には、フローティング内部 IP アドレスとフローティング外部 IP アドレスに使用できるおすすめのパターンを記載します。フローティング内部 IP アドレスに依存するユースケースでは、これらのパターンのいずれかがニーズを満たすことができます。ただし、フローティング外部 IP アドレスに依存するユースケースは、ロード バランシングを使用するパターンのいずれかに移行することをおすすめします。

• アプリケーション プロトコル: VM が TCP や UDP のみを使用している場合は、表にあるすべてのパターンを使用できます。IPv4 で他のプロトコルを使用して接続する場合は、一部のパターンしか適切ではありません。

• アクティブ - アクティブ デプロイの互換性: 一部のアプリケーションは、オンプレミスでフローティング IP アドレスを使用しながら、アクティブ - アクティブ デプロイモードで動作します。この機能では、プライマリ サーバーからセカンダリ サーバーへフェイルオーバーする必要がありません。このような種類のアプリケーションを Compute Engine に移行するパターンは他にもあります。常に 1 つのアプリケーション サーバーでのみトラフィックを受信する必要があるアプリケーションは、アクティブ - アクティブ デプロイとの互換性がありません。こうしたアプリケーションは、下表の一部のパターンでのみ実装できます。

• プライマリ VM 復旧後のフェイルバック動作: 元のプライマリ VM がフェイルオーバー後に復旧する場合、トラフィックの挙動は、使用されているパターンによって次の 2 つのいずれかになります。すぐに元のプライマリ VM に戻るか、フェイルバックが手動で開始されるまで、または新しいプライマリ VM に障害が発生するまで、新しいプライマリ VM に残ります。いずれの場合も、新しく開始された接続のみがフェイルバックします。既存の接続は、接続が終了するまで新しいプライマリ VM で持続します。

• ヘルスチェックの互換性: Compute Engine のヘルスチェックを使用して、アプリケーションが応答しているかどうかを確認することができない場合は、次の表で説明されているパターンを使用できません。

• インスタンス グループ: ヘルスチェックの互換性があるパターンは、インスタンス グループとも互換性があります。障害が発生したインスタンスを自動的に再作成するには、自動修復が有効なマネージド インスタンス グループを使用します。VM が状態を保持している場合は、ステートフル マネージド インスタンス グループを使用できます。VM を自動的に再作成できない場合や、手動のフェイルオーバーが必要な場合は、非マネージド インスタンス グループを使用して、フェイルオーバー中に VM を手動で再作成します。

• 既存のハートビート メカニズム: アプリケーションの高可用性設定ですでにハートビート メカニズムを使用してフェイルオーバー（Heartbeat、Pacemaker、Keepalived など）をトリガーしている場合、次の表に示すいくつかのパターンを使用できます。

次の表に、パターンの機能を示します。各パターンについては、次のセクションで説明します。

• ロード バランシングを使用したパターン
• Google Cloud のルートを使用したパターン
• 自動修復を使用したパターン

パターン名	IP アドレス	サポートされているプロトコル	デプロイモード	フェイルバック	アプリケーションのヘルスチェックの互換性が必要	ハートビート メカニズムを統合可能か
ロード バランシングを使用したパターン
アクティブ - アクティブ ロード バランシング	内部または外部	TCP / UDP のみ	アクティブ / アクティブ	なし	○	いいえ
フェイルオーバーとアプリケーションの公開ヘルスチェックを使用したロード バランシング	内部または外部	TCP / UDP のみ	アクティブ / パッシブ	即時（既存の接続を除く）	はい	いいえ
フェイルオーバーとハートビートの公開ヘルスチェックを使用したロード バランシング	内部または外部	TCP / UDP のみ	アクティブ / パッシブ	構成可能	いいえ	はい
Google Cloud のルートを使用したパターン
ECMP ルートの使用	内部	すべての IP プロトコル	アクティブ / アクティブ	なし	○	いいえ
優先順位が異なるルートの使用	内部	すべての IP プロトコル	アクティブ / パッシブ	即時（既存の接続を除く）	はい	いいえ
ハートビート メカニズムを使用したルートのネクストホップの切り替え	内部	すべての IP プロトコル	アクティブ / パッシブ	構成可能	いいえ	はい
自動修復を使用したパターン
自動修復単一インスタンスの使用	内部	すべての IP プロトコル	なし	なし	○	いいえ

ユースケースにどのパターンを使用するかは、複数の要因によって決まります。次のディシジョン ツリーは、選択肢を適切なオプションに絞り込むのに役立ちます。

この図は、次のステップの概要を示しています。

1. 単一自動修復インスタンスは、ニーズに十分対応できますか？
   1. 「はい」の場合は、このドキュメントに後述の自動修復単一インスタンスの使用をご覧ください。自動修復は、VM インスタンス グループ内の仕組みを使用して、問題のある VM インスタンスを自動的に置き換えます。
   2. 「いいえ」の場合、次の決定ポイントに進みます。
2. アプリケーションで IPv4 に加えて TCP と UDP 以外にプロトコルが必要ですか？
   1. 「はい」の場合、次の決定ポイントに進みます。
   2. 「いいえ」の場合、次の決定ポイントに進みます。
3. アプリケーションはアクティブ - アクティブ モードで動作しますか？
   1. 「はい」で、TCP と UDP 以外に IPv4 上のプロトコルが必要な場合は、このドキュメントに後述の等価コスト マルチパス（ECMP）ルートの使用をご覧ください。ECMP ルートは、ルート候補となるすべてのネクストホップにトラフィックを分散します。
   2. 「はい」の場合、TCP と UDP 以外の IPv4 の上にプロトコルを必要としない場合、このドキュメントの後半のアクティブ - アクティブ ロード バランシングをご覧ください。アクティブ - アクティブ ロード バランシングでは、VM を内部 TCP/UDP ロードバランサのバックエンドとして使用します。
   3. いずれの場合も、次の決定ポイントに進みます。
4. アプリケーションで Google Cloud ヘルスチェックを公開できますか？
   1. 「はい」の場合で、IPv4 に加えて TCP と UDP 以外にプロトコルが必要な場合は、このドキュメントの後半のフェイルオーバーとアプリケーションの公開ヘルスチェックによるロード バランシングをご覧ください。フェイルオーバーとアプリケーションの公開ヘルスチェックを使用したロード バランシングでは、VM を内部 TCP / UDP ロードバランサのバックエンドとして使用します。また、内部 TCP / UDP ロード バランシング IP アドレスを仮想 IP アドレスとして使用します。
   2. 「はい」で、TCP と UDP 以外に IPv4 上のプロトコルを必要としない場合は、このドキュメントに後述の異なる優先度ルートの使用をご覧ください。優先順位が異なるルートを使用すると、プライマリ インスタンスに障害が発生しない限り、常にトラフィックはプライマリ インスタンスに送信されます。
   3. 「いいえ」の場合で、IPv4 に加えて TCP と UDP 以外にプロトコルが必要な場合は、このドキュメントの後半のフェイルオーバーとハートビートの公開ヘルスチェックによるロード バランシングをご覧ください。フェイルオーバーとハートビートの公開ヘルスチェックを使用したロード バランシングのパターンでは、ヘルスチェックはアプリケーション自体ではなく、両方の VM 間で実行されるハートビート メカニズムによって公開されます。
   4. 「いいえ」で、TCP と UDP 以外に IPv4 上のプロトコルを必要としない場合は、このドキュメントに後述のハートビート メカニズムを使用してルートのネクストホップを切り替えるをご覧ください。ルートのネクストホップを切り替えるためにハートビート メカニズムを使用すると、ネクストホップがプライマリ VM インスタンスを指す単一の静的ルートが使用されます。

ロード バランシングを使用したパターン

通常、フローティング IP アドレスを使用するアプリケーションは、Cloud Load Balancing を使用する Google Cloud のアーキテクチャに移行できます。内部パススルー ネットワーク ロードバランサを使用できます。このオプションは、オンプレミスに移行されたサービスが内部でのみ公開されるユースケースに適しています。このセクションのすべての例と GitHub のサンプル デプロイでは、このロード バランシング オプションを使用します。他のリージョンからフローティング IP アドレスにアクセスするクライアントがある場合は、グローバル アクセス オプションを選択します。

アプリケーションが、IPv4 上のプロトコル（TCP や UDP 以外）を使用して通信する場合は、ロード バランシングを使用しないパターンを選択する必要があります。そうしたパターンについては、このドキュメントの後のセクションで説明します。

アプリケーションで HTTP(S) を使用する場合、内部アプリケーション ロードバランサを使用してアクティブ - アクティブ パターンを実装できます。

移行しようとしているサービスが外部から利用可能な場合は、外部パススルー ネットワーク ロードバランサを使用して、このセクションで説明するすべてのパターンを実装できます。アクティブ - アクティブ デプロイでは、アプリケーションが、これらのロード バランシング オプションでサポートされるプロトコルとポートを使用する場合、外部アプリケーション ロードバランサ、TCP プロキシ、または SSL プロキシも使用できます。

オンプレミスのフローティング IP アドレスに基づく実装と、すべてのロード バランシング ベースのパターンの違いは次のとおりです。

• フェイルオーバー時間: オンプレミス環境で Keepalived と Gratuitous ARP を合わせて使用すると、数秒で IP アドレスがフェイルオーバーすることがあります。Compute Engine 環境では、フェイルオーバーからの平均復旧時間は、設定したパラメータによって変わります。仮想マシン（VM）インスタンスまたは VM インスタンス サービスに障害が発生した場合、平均フェイルオーバー トラフィックは、Check Interval、Unhealthy Threshold などのヘルスチェック パラメータに依存します。これらのパラメータをデフォルト値に設定すると、フェイルオーバーには、通常 15～20 秒かかります。この時間は、パラメータ値を小さくすることで短縮できます。

  Compute Engine では、ゾーン内またはゾーン間のフェイルオーバーにも同じ時間がかかります。

• プロトコルとポート: オンプレミス設定では、フローティング IP アドレスはすべてのトラフィックを受け入れます。内部パススルー ネットワーク ロードバランサの内部転送ルールで、次のいずれかのポート仕様を選択します。

  • 1 個から 5 個までのポートを番号で指定します。
  • TCP または UDP のすべてのポートにトラフィックを転送するには、ALL を指定します。
  • 同じ IP アドレスを持つ複数の転送ルールを使用して、TCP と UDP トラフィックを混在させるか、単一の IP アドレスで 5 つを超えるポートを使用します。
    • TCP または UDP と 1～5 ポートのみ: 1 つの転送ルールを使用します。
    • TCP および UDP と 1～5 ポート: 複数の転送ルールを使用します。
    • 6 以上のポートと TCP または UDP: 複数の転送ルールを使用します。

• ヘルスチェック: オンプレミスで、マシン上のアプリケーションの応答性を次の方法で確認できます。

  • 他のホストから、まだ応答可能であることを示すシグナルを受信している。
  • 選択したハートビート メカニズム（Keepa やり取り、Pacemaker、ハートビート）を介してアプリケーションがまだ使用可能かどうかをモニタリングします。Compute Engine では、ホストの外部から gRPC、HTTP、HTTP/2、HTTPS、TCP、または SSL を介してヘルスチェックにアクセスできる必要があります。アクティブ - アクティブ ロード バランシングとフェイルオーバー グループとアプリケーションの公開ヘルスチェックを使用したロード バランシングパターンでは、アプリケーションがヘルスチェックを公開する必要があります。既存のハートビート メカニズムを使用してサービスを移行するには、フェイルオーバー グループとハートビートの公開ヘルスチェックを使用したロード バランシングパターンを使用できます。

アクティブ - アクティブ ロード バランシング

アクティブ / アクティブ ロード バランシング パターンでは、VM は内部パススルー ネットワーク ロードバランサのバックエンドです。内部パススルー ネットワーク ロードバランサの IP アドレスを仮想 IP アドレスとして使用します。トラフィックは、2 つのバックエンド インスタンス間で均等に分散されます。同じセッションに属するトラフィックは、セッション アフィニティの設定で定義されている同じバックエンド インスタンスに送信されます。

アクティブ / アクティブ ロード バランシング パターンは、アプリケーションが TCP と UDP に基づくプロトコルのみを使用し、マシン間のフェイルオーバーが不要な場合に使用します。このパターンは、リクエスト自体の内容に応じてアプリケーションがリクエストに応答できるシナリオで使用します。常に同期されていないマシンの状態がある場合は、このパターンを使用しないでください（プライマリ データベースやセカンダリ データベースなど）。

次の図は、アクティブ - アクティブ ロード バランシング パターンの実装を示しています。

上の図は、内部クライアントが内部パススルー ネットワーク ロードバランサを介して 2 つの VM で実行されるサービスにアクセスする方法を示しています。どちらの VM もインスタンス グループの一部です。

アクティブ - アクティブ ロード バランシング パターンでは、サポートされているヘルスチェック プロトコルのいずれかを使用してヘルスチェックを公開し、応答する VM のみがトラフィックを受信する必要があります。

このパターンの完全な実装例については、GitHub にある Terraform を使用したデプロイ例をご覧ください。

フェイルオーバーとアプリケーションの公開ヘルスチェックを使用したロード バランシング

アクティブ - アクティブ パターンと同様に、フェイルオーバーおよびアプリケーション公開ヘルスチェックによるロード バランシングでは、内部パススルー ネットワーク ロードバランサのバックエンドとして VM が使用されます。また、内部パススルー ネットワーク ロードバランサの IP アドレスを仮想 IP アドレスとして使用します。一度に 1 つの VM のみがトラフィックを受信するように、このパターンでは、内部パススルー ネットワーク ロードバランサのフェイルオーバーを適用します。

このパターンは、アプリケーションに TCP トラフィックまたは UDP トラフィックのみがあり、アクティブ / アクティブのデプロイをサポートしていない場合におすすめします。このパターンを適用すると、すべてのトラフィックがプライマリ VM またはフェイルオーバー VM のいずれかに流れます。

次の図は、フェイルオーバーとアプリケーションの公開ヘルスチェックを使用したロード バランシングのパターンの実装を示しています。

上の図は、内部クライアントが内部パススルー ネットワーク ロードバランサの背後にあるサービスにアクセスする方法を示しています。2 つの VM は、別々のインスタンス グループにあります。一方のインスタンス グループは、プライマリ バックエンドとして設定されます。他のインスタンス グループは、内部パススルー ネットワーク ロードバランサのフェイルオーバー バックエンドとして設定されます。

プライマリ VM 上のサービスが応答しなくなると、トラフィックはフェイルオーバー インスタンス グループに切り替わります。プライマリ VM が再び応答すると、トラフィックはプライマリ バックエンド サービスに自動的に戻ります。

このパターンの完全な実装例については、GitHub にある Terraform を使用したデプロイ例をご覧ください。

フェイルオーバーとハートビートの公開ヘルスチェックを使用したロード バランシング

フェイルオーバーとハートビートのヘルスチェックのパターンを使用したロード バランシングは、前のパターンと同じです。違いは、ヘルスチェックはアプリケーション自体ではなく、両方の VM 間で実行されるハートビート メカニズムによって公開されることです。

次の図は、フェイルオーバーとハートビートの公開ヘルスチェックを使用したロード バランシングのパターンの実装を示しています。

次の図は、内部クライアントが内部ロードバランサの背後にあるサービスにアクセスする方法を示しています。2 つの VM は、別々のインスタンス グループにあります。一方のインスタンス グループは、プライマリ バックエンドとして設定されます。他のインスタンス グループは、内部パススルー ネットワーク ロードバランサのフェイルオーバー バックエンドとして設定されます。Keepalive は VM ノード間のハートビート メカニズムとして使用されます。

VM ノードは、選択したハートビート メカニズムを使用してサービスのステータスに関する情報を交換します。各 VM ノードは自身のステータスを確認し、そのステータスをリモートノードに伝えます。ローカルノードのステータスとリモートノードが受信したステータスに応じて、1 つのノードがプライマリ ノードとして選択され、1 つのノードがバックアップ ノードとして選択されます。このステータス情報を使用して、ハートビート メカニズムでプライマリと見なされたノードが、内部パススルー ネットワーク ロードバランサからのトラフィックも受信するようにヘルスチェックの結果を公開できます。

たとえば、Keepalived では、ヘルスチェック ステータスを変更する notify_master、notify_backup、notify_fault 構成変数を使用してスクリプトを呼び出すことができます。プライマリ状態（Keepalived ではこの状態は master と呼ばれます）に移行すると、カスタム TCP ポートでリッスンするアプリケーションを起動できます。バックアップ状態または障害状態に移行する場合は、このアプリケーションを停止できます。その後、このカスタム TCP ポートが開いている場合、ヘルスチェックは成功する TCP ヘルスチェックになります。

このパターンは、アプリケーション公開ヘルスチェックでフェイルオーバーを使用するパターンよりも複雑です。ただし、より詳細に管理できます。たとえば、ハートビート メカニズムの実装の一環として、すぐにまたは手動でフェイルバックするように構成できます。

Keepalived を使用したこのパターンの完全な実装については、GitHub にある Terraform を使用したデプロイ例を参照してください。

Google Cloud のルートを使用したパターン

アプリケーションが TCP や UDP 以外の IPv4 上のプロトコルを使用している場合は、フローティング IP アドレスをルートに基づくパターンに移行できます。

このセクションでのルートの説明は、常に VPC ネットワークの一部である Google Cloud ルートを意味します。静的ルートへの参照は、常に Google Cloud の静的ルートを意味します。

これらのパターンのいずれかを使用して、特定の IP アドレスに複数の静的ルートを設定し、さまざまなインスタンスをネクストホップとして設定します。この IP アドレスは、すべてのクライアントが使用するフローティング IP アドレスになります。静的ルートは既存のサブネット ルートをオーバーライドできないため、すべての VPC サブネット IP アドレス範囲の外部に配置する必要があります。ターゲット インスタンスで IP アドレス転送を有効にする必要があります。IP アドレス転送を有効にすると、インスタンスに割り当てられていない IP アドレスのトラフィック（この場合はフローティング IP アドレス）を受け入れることができます。

フローティング IP アドレスのルートをピア VPC ネットワークから使用できるようにするには、カスタムルートをエクスポートして、フローティング IP アドレスのルートがすべてのピア VPC ネットワークに伝播されるようにします。

オンプレミス ネットワークから接続して、Cloud Interconnect または Cloud VPN を使用するには、カスタム IP アドレス ルート アドバタイズを使用して、フローティング IP アドレスをオンプレミスでアドバタイズする必要があります。

ルートベースのパターンには、ロード バランシング ベースのパターンに比べて次のような利点があります。

• プロトコルとポート: ルートベースのパターンは、特定の宛先に送信されるすべてのトラフィックに適用されます。ロード バランシング ベースのパターンでは、TCP トラフィックと UDP トラフィックのみが許可されます。

ルートベースのパターンには、ロード バランシング ベースのパターンに比べて次のようなデメリットがあります。

• ヘルスチェック: ヘルスチェックを Google Cloud ルートに接続することはできません。ルートは、基礎となる VM サービスの正常性に関係なく使用されます。VM が実行中であれば、サービスが正常でなくても、インスタンスにトラフィックを転送します。そうしたインスタンスに自動修復ポリシーを接続すると、指定した異常期間後にインスタンスが置き換えられます。ただし、これらのインスタンスが再起動すると、サービスが開始される前であっても、トラフィックはすぐに戻ります。このサービスの空白時間により、正常でないインスタンスがトラフィックを処理しているか、再起動しているときには、サービスエラーが発生する可能性があります。
• フェイルオーバー時間: VM インスタンスを削除または停止すると、Compute Engine はこのインスタンスを指す静的ルートをすべて無視します。ただし、ルートのヘルスチェックは行われないため、Compute Engine はインスタンスが利用可能である限り、静的ルートを使用します。加えて、インスタンスの停止には時間がかかるため、フェイルオーバー時間は、ロード バランシング ベースのパターンの場合よりもかなり長くなります。
• 内部フローティング IP アドレスのみ: 外部パススルー ネットワーク ロードバランサでロード バランシングを使用してパターンを実装し外部フローティング IP アドレスを作成できますが、ルートベース パターンは、内部フローティング IP アドレスでのみ機能します。
• フローティング IP アドレスの選択: ルートは、サブネットの一部ではない内部フローティング IP アドレスにのみ設定できます。Google Cloud ではサブネット ルートを上書きできません。こうしたフローティング IP アドレスは、誤って別のネットワークに割り振ることがないように追跡してください。
• ルートのネットワーク到達性: オンプレミス ネットワークまたはピア ネットワークから内部フローティング IP アドレスに到達できるようにするには、前述したように、これらの静的ルートを分散する必要があります。

等価コスト マルチパス（ECMP）ルートの使用

等価コスト マルチパス（ECMP）ルートパターンは、アクティブ - アクティブ ロード バランシング パターンと似ており、2 つのバックエンド インスタンス間でトラフィックが均等に分散されます。Google Cloud 静的ルートを使用する場合、ECMP はアフィニティ用に 5 タプルハッシュを使用して、すべてのルート候補のネクストホップにトラフィックを分散します。

このパターンを実装するには、Compute Engine インスタンスをネクストホップとして、同じ優先度の 2 つの静的ルートを作成します。

次の図では、ECMP ルートパターンの実装を示します。

上図は、内部クライアントが、サービスを実装する VM インスタンスを指すネクストホップを含む 2 つのルートのいずれかを使用してサービスにアクセスする仕組みを示しています。

一方の VM でサービスが応答しなくなった場合、応答しないインスタンスの再作成が自動修復によって試みられます。自動修復でインスタンスが削除されると、新しいインスタンスが作成される前に、削除されたインスタンスを指すルートが非アクティブになります。新しいインスタンスが作成されると、そのインスタンスを指すルートが自動的にすぐに使用され、トラフィックがインスタンス間で均等に分散されます。

ECMP ルートパターンでは、サービスによって、サポートされているプロトコルを使用するヘルスチェックが公開され、自動修復によって応答しない VM が自動的に置き換えられる必要があります。

このドキュメントに関連する GitHub リポジトリで、Terraform を使用するこのパターンの実装例を確認できます。

優先順位が異なるルートの使用

優先度の異なるルートパターンは前のパターンと似ていますが、優先度の静的ルートが異なるため、インスタンスに障害がない限り、トラフィックは常にプライマリ インスタンスに転送されます。

このパターンを実装するには、ECMP ルートパターンと同じ手順を行います。静的ルートを作成する際は、プライマリ インスタンスを指すネクストホップがあるルートに低い優先度の値（プライマリ ルート）を設定します。セカンダリ インスタンスを指すネクストホップがあるインスタンスには、高い優先度の値（セカンダリ ルート）を設定します。

次の図では、異なる優先度ルートパターンの実装を示します。

上図は、通常の状況で、サービスにアクセスする内部クライアントが、VM 1 を指す優先度値が 500 のプライマリ ルートをネクストホップとして使用する仕組みを示しています。2 番目のルートには、ネクストホップとして VM 2（セカンダリ VM）を指す優先度値が 1,000 のルートを使用できます。

プライマリ VM のサービスが応答しなくなると、自動修復はインスタンスの再作成を試みます。自動修復でインスタンスが削除されると、作成する新しいインスタンスが起動する前に、プライマリ インスタンスをネクストホップとするプライマリ ルートが非アクティブになります。このパターンは、セカンダリ インスタンスを含むルートをネクストホップとして使用します。新しいプライマリ インスタンスが起動すると、プライマリ ルートが再びアクティブになり、すべてのトラフィックがプライマリ インスタンスに流れます。

前のパターンと同様、異なる優先度ルートパターンを使用する場合は、サポートされているプロトコルを使用するヘルスチェックがサービスにより公開されるため、自動修復によって応答しない VM を自動的に置き換えることができます。

このドキュメントに付属の GitHub リポジトリで、Terraform を使用するこのパターンの実装例を確認できます。

ハートビート メカニズムを使用したルートのネクストホップの切り替え

アプリケーションに Keepalive などのハートビート メカニズムを実装してアプリケーションの応答性をモニタリングする場合、ハートビート メカニズム パターンを適用して静的ルートのネクストホップを変更できます。この場合、ネクストホップがプライマリ VM インスタンスを参照する静的ルートを 1 つだけ使用します。フェイルオーバー時には、ハートビート メカニズムによってセカンダリ VM へのルートのネクストホップがポイントされます。

次の図では、ルートのネクストホップ パターンを切り替えるハートビート メカニズムの実装を示します。

上図は、プライマリ VM を指すネクストホップがあるルートを使用して、内部クライアントがサービスにアクセスする仕組みを示しています。プライマリ VM は、Keepalived を介してセカンダリ VM とハートビート情報を交換します。フェイルオーバーの際、Keepalived は、API 呼び出しを使用する Cloud Functions の関数を呼び出して、セカンダリ VM のネクストホップを指すようにします。

ノードは、選択されたハートビート メカニズムを使用して、サービスのステータスに関する情報を相互に交換します。各 VM ノードは自身のステータスを確認し、そのステータスをリモート　VM　ノードに伝えます。ローカル VM ノードのステータスとリモートノードが受信したステータスに応じて、1 つの VM ノードがプライマリ ノードとして選択され、1 つの VM ノードがバックアップ ノードとして選択されます。ノードがプライマリになると、フローティング IP アドレスのルートのネクストホップが自身を指すようにします。Keepalived を使用する場合、API 呼び出しまたは Google Cloud CLI で静的ルートを置き換える notify_master 構成変数を使用してスクリプトを呼び出すことができます。

ルートのネクストホップ パターンを切り替えるハートビート メカニズムでは、VM がインスタンス グループに属している必要はありません。障害発生時に VM を自動的に置き換える場合は、それらの VM を自動修復インスタンス グループに配置できます。応答しない VM を手動で修復して再作成することもできます。

フェイルオーバーの際に次の手順を呼び出すと、ステップ 1 で単一の API 呼び出しが完了した後にトラフィックがフェイルオーバーするため、フェイルオーバー時間を最小限に抑えることができます。

1. フローティング IP アドレスを宛先とし、新しいプライマリ インスタンスをネクストホップとする新しい静的ルートを作成します。新しいルートは、元のルートとは異なるルート名とルート優先度（400 など）にする必要があります。
2. 古いプライマリ VM への元のルートを削除します。
3. 削除したルートと同じ名前と優先度を持つルートを作成します。そのルートが、ネクストホップとして新しいプライマリ VM を指すようにします。
4. 作成した新しい静的ルートを削除します。トラフィックが新しいプライマリ VM に確実に流れるようにするためには必要ありません。

元のルートが置き換えられるため、スプリット ネットワークが存在する場合でも、一度にアクティブになるルートは 1 つだけです。

ハートビート メカニズムを使用して、他のルートベースのパターンではなくルートの優先度パターンを切り替えると、フェイルオーバー時間を短縮できます。フェイルオーバーのために自動修復で VM の削除や置き換えを行う必要はありません。また、元のプライマリ サーバーが再度応答するようになった後にフェイルバックするタイミングも細かく制御できます。

このパターンの欠点の 1 つは、ハートビート メカニズムを自分で管理しなければならないことです。メカニズムを管理すると、複雑さが増す可能性があります。もう 1 つのデメリットは、ハートビート プロセスを実行している VM またはハートビート プロセスから呼び出されるサーバーレス関数のいずれかに、グローバル ルーティング テーブルを変更する権限を付与する必要があることです。グローバル ルーティング テーブルをサーバーレス関数に変更すると、VM に付与される権限の範囲が縮小されるため、安全性が高まります。ただし、このアプローチでは実装が複雑です。

Keepalived を使用したこのパターンの完全な実装については、GitHub にある Terraform を使用したデプロイ例を参照してください。

自動修復を使用したパターン

Compute Engine を使用する場合、復旧時間の要件によっては、単一の VM インスタンスに移行することが実現可能な選択肢になることがあります。この選択肢は、フローティング IP アドレスを使用する複数のサーバーがオンプレミスで使用された場合でも変わりません。VM の数が減少するとしてもこのパターンを使用することがある理由は、新しい Compute Engine インスタンスは数秒または数分で作成できるのに対し、通常、オンプレミスの障害は、その修復に数時間から数日かかることさえあるためです。

自動修復単一インスタンスの使用

このパターンを使用すると、VM インスタンス グループの自動修復メカニズムを利用して、問題のある VM インスタンスを自動的に置き換えます。アプリケーションがヘルスチェックを公開し、アプリケーションが正常でない場合は、自動修復により VM が自動的に置き換えられます。

次の図では、自動修復単一インスタンス パターンの実装を示します。

上図は、自動修復が有効で、サイズが 1 のマネージド インスタンス グループに配置された Compute Engine インスタンスに、内部クライアントが直接接続する仕組みを示しています。

ロード バランシングを使用するパターンと比較して、自動修復の単一インスタンス パターンには次の利点があります。

• トラフィック分散: インスタンスが 1 つしかないため、常にそのインスタンスがすべてのトラフィックを受信します。
• 使いやすさ: インスタンスは 1 つしかないため、このパターンは実装が最も複雑ではありません。
• コストの削減: 2 つではなく 1 つの VM インスタンスを使用することによって、実装コストを半減させることができます。

ただし、このパターンには次の欠点があります。

• フェイルオーバー時間: このプロセスは、ロードバランシングベースのパターンよりもはるかに遅くなります。ヘルスチェックでマシンの障害が検出された後、障害が発生したインスタンスの削除と再作成に少なくとも 1 分はかかり、それ以上かかることもよくあります。このパターンは、本番環境ではあまり見られません。ただし、内部サービスや試験運用サービスには、このフェイルオーバー時間で十分な場合もあります。
• ゾーン障害への対応: サイズが 1 のマネージド インスタンス グループは、ゾーン障害が発生すると存続できません。ゾーン障害に対応するには、サービスの失敗時の Cloud Monitoring アラートの追加を検討し、ゾーン障害の発生時に別のゾーンにインスタンス グループを作成します。この場合、同じ IP アドレスを使用できないため、Cloud DNS 限定公開ゾーンを使用して VM をアドレス指定し、DNS 名を新しい IP アドレスに切り替えます。

Terraform を使用するこのパターンのサンプル実装は、GitHub リポジトリをご覧ください。

次のステップ

• GitHub でこのドキュメントのデプロイ テンプレートを確認する。
• 内部パススルー ネットワーク ロードバランサについて学習する。
• 内部パススルー ネットワーク ロードバランサのフェイルオーバー オプションについて学習する。
• Compute Engine のルートについて理解する。
• SQL Server Always On 可用性グループ ソリューションを確認する。
• Windows Server フェイルオーバー クラスタリングの実行について学習する。
• Compute Engine で Microsoft SQL Server Always On 可用性グループを作成する方法について学習する。
• Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センターをご覧ください。