内部パススルー ネットワーク ロードバランサのトラフィック分散

このページでは、内部パススルー ネットワーク ロードバランサがトラフィックを分散する方法について理解を深め、カスタマイズするために役立つ次のコンセプトについて説明します。セッション アフィニティ、接続トラッキング、UDP フラグメンテーション、フェイルオーバー。

内部パススルー ネットワーク ロードバランサの新しい接続の分散方法は、フェイルオーバーを構成しているかどうかによって異なります。

• フェイルオーバーを構成していない場合、少なくとも 1 つのバックエンド VM が正常であれば、内部パススルー ネットワーク ロードバランサによって正常なバックエンド VM に新しい接続が分散されます。すべてのバックエンド VM が正常でない場合は、最後の手段としてロードバランサによりすべてのバックエンドの間で新しい接続が分散されます。この場合、ロードバランサにより正常でないバックエンド VM にそれぞれ新しい接続が転送されます。

• フェイルオーバーを構成している場合、内部パススルー ネットワーク ロードバランサは、構成したフェイルオーバー ポリシーに従って、アクティブ プール内の VM 間で新しい接続を分散します。すべてのバックエンド VM が正常でない場合は、次のいずれかの動作から選択できます。

  • （デフォルト）ロードバランサは、プライマリ VM にのみトラフィックを分散します。これは最後の手段です。バックアップ VM は、この最後の接続分散から除外されます。
  • ロードバランサは、トラフィックをドロップするように構成されています。

新しい接続の分散方法は、ロードバランサのセッション アフィニティの設定によって異なります。

ヘルスチェックの状態によって、新しい接続の分散が制御されます。デフォルトでは、TCP 接続は異常なバックエンドで維持されます。詳細とこの動作を変更する方法については、異常なバックエンドでの接続の永続性をご覧ください。

バックエンドの選択と接続トラッキング

内部パススルー ネットワーク ロードバランサでは、構成可能なバックエンドの選択と接続トラッキング アルゴリズムを使用して、トラフィックをバックエンド VM に分散する方法が決定されます。内部パススルー ネットワーク ロードバランサでは、次のアルゴリズムを使用して、（フェイルオーバーを構成している場合は、アクティブ プール内の）バックエンド VM 間にパケットが分散されます。

1. ロードバランサに、受信パケットの特性と一致する接続トラッキング テーブルがある場合、パケットは接続トラッキング テーブルのエントリで指定されたバックエンドに送信されます。パケットは、以前に確立した接続の一部と見なされるため、ロードバランサによって接続トラッキング テーブルに以前に決定され記録されたバックエンド VM に送信されます。

2. ロードバランサで対応する接続トラッキング エントリがないパケットを受信した場合、ロードバランサでは次が行われます。

   1. ロードバランサでバックエンドが選択されます。 ロードバランサは、構成されたセッション アフィニティに基づいてハッシュを計算します。このハッシュを使用してバックエンドを選択します。

      • 少なくとも 1 つのバックエンドが正常な場合、ハッシュは正常なバックエンドのいずれかを選択します。
      • すべてのバックエンドが異常な状態の場合で、フェイルオーバー ポリシーが設定されていない場合、ハッシュはいずれかのバックエンドを選択します。
      • すべてのバックエンドが異常な状態の場合で、フェイルオーバー ポリシーが構成されており、この状況でフェイルオーバー ポリシーがトラフィックをドロップするように構成されていない場合、ハッシュはプライマリ VM バックエンドの 1 つを選択します。

      デフォルトのセッション アフィニティ NONE は、パケットの送信元 IP アドレス、送信元ポート、宛先 IP アドレス、宛先ポート、プロトコルの 5 タプルハッシュを使用します。

      バックエンドの選択は、使用する情報が少ないハッシュ アルゴリズムを使用してカスタマイズできます。サポートされているすべてのオプションについては、セッション アフィニティのオプションをご覧ください。

   2. ロードバランサにより、接続トラッキング テーブルにエントリが追加されます。このエントリによって、パケット接続用に選択されたバックエンドが記録されるため、この接続からの以降のパケットがすべて同じバックエンドに送信されます。接続トラッキングを使用するかどうかは、プロトコルによって異なります。

      TCP パケットと UDP パケットの場合、接続トラッキングは常に有効になっています。オフにすることはできません。デフォルトでは、接続トラッキングは 5 タプルですが、5 タプル未満に構成することもできます。

      接続トラッキング ハッシュが 5 タプルの場合、TCP SYN パケットは常に接続トラッキング テーブルに新しいエントリを作成します。
      
      デフォルトの 5 タプル接続トラッキングは、次の場合に使用されます。

      • トラッキング モードが PER_CONNECTION（すべてのセッション アフィニティ）の場合。または、
      • トラッキング モードが PER_SESSIONでセッション アフィニティが NONEの場合。または、
      • トラッキング モードが PER_SESSION であり、セッション アフィニティが CLIENT_IP_PORT_PROTO の場合。

      接続トラッキングが有効にされている場合と、接続トラッキングが有効な場合のトラッキング方法の詳細については、接続トラッキング モードをご覧ください。

      さらに、次の点に留意してください。

      • デフォルトでは、接続トラッキング テーブル内のエントリは、ロードバランサがエントリに一致した最後のパケットを処理してから 600 秒後に失効します。アイドル タイムアウトをカスタマイズする方法については、アイドル タイムアウトをご覧ください。
      • プロトコルによっては、バックエンドが正常な状態ではなくなると、ロードバランサによって接続トラッキング テーブルのエントリが削除される場合があります。この動作の詳細とカスタマイズ方法については、異常なバックエンドでの接続の永続性をご覧ください。

セッション アフィニティのオプション

セッション アフィニティは、クライアントからロードバランサのバックエンド VM への新しい接続の分散を制御します。バックエンド VM がクライアントの状態情報を追跡する必要がある場合は、セッション アフィニティを設定します。これは、ウェブ アプリケーションの一般的な要件です。

セッション アフィニティはベストエフォート ベースで機能します。

内部パススルー ネットワーク ロードバランサは、バックエンド インスタンス グループではなく、内部バックエンド サービス全体に指定する次に示すセッション アフィニティのオプションをサポートします。

• なし（NONE）。送信元 IP アドレス、送信元ポート、プロトコル、宛先 IP アドレス、宛先ポートの 5 タプルハッシュ
• クライアント IP、宛先なし（CLIENT_IP_NO_DESTINATION）。送信元 IP アドレスからのみ作成された 1 タプルハッシュ
• クライアント IP（CLIENT_IP）。送信元 IP アドレスと宛先 IP アドレスの 2 タプルハッシュです。外部パススルー ネットワーク ロードバランサは、このセッション アフィニティのクライアント IP、宛先 IP　オプションを呼び出します。
• クライアント IP、宛先 IP、プロトコル（CLIENT_IP_PROTO）。送信元 IP アドレス、宛先 IP アドレス、プロトコルの 3 タプルハッシュ
• クライアント IP、クライアント ポート、宛先 IP、宛先ポート、プロトコル（CLIENT_IP_PORT_PROTO）。送信元 IP アドレス、送信元ポート、プロトコル、宛先 IP アドレス、宛先ポートの 5 タプルハッシュ

ロードバランサをカスタム静的ルートのネクストホップとして使用しない限り、パケットの宛先 IP アドレスは、パケットをロードバランサに配信するためのロードバランサ転送ルールの IP アドレスと一致する必要があります。ロードバランサをカスタム静的ルートのネクストホップとして使用する場合の考慮事項については、セッション アフィニティとネクストホップの内部パススルー ネットワーク ロードバランサをご覧ください。

注: 内部 UDP ロードバランサの場合、セッション アフィニティの設定は、gcloud CLI と API でサポートされています。 Google Cloud コンソールを使用して、UDP トラフィックにセッション アフィニティを設定することはできません。

セッション アフィニティとネクストホップの内部パススルー ネットワーク ロードバランサ

ネクストホップの内部パススルー ネットワーク ロードバランサを使用するように静的ルートを構成すると、ロードバランサは前述のバックエンドの選択と接続のトラッキングの方法を使用します。バックエンドの選択は、構成されたセッション アフィニティに従ってハッシュを計算することで引き続き行われます。CLIENT_IP_NO_DESTINATION セッション アフィニティを除き、バックエンド選択ハッシュは、パケットの宛先 IP アドレスに部分的に依存します。

内部パススルー ネットワーク ロードバランサ ロードバランサが静的ルートのネクストホップの場合、宛先 IP アドレスはロードバランサの転送ルールの IP アドレスに限定されません。代わりに、パケットの宛先 IP アドレスは、静的ルートの宛先範囲内に収まる任意の IP アドレスにできます。

構成済みで正常なバックエンド VM の数が一定の場合（フェイルオーバーが構成されていない場合、またはフェイルオーバーが構成されていても、フェイルオーバー イベントまたはフェイルバック イベントが発生しない場合）、ロードバランサは次のように動作します。

• 構成済みで正常なバックエンド VM が 1 つだけある場合（フェイルオーバーが構成されている場合はアクティブ プール内）、すべてのハッシュが 1 つのバックエンド VM にマッピングされるため、使用するセッション アフィニティは重要ではありません。

• 構成済みで正常なバックエンド VM が 2 つ以上ある場合（フェイルオーバーが構成されている場合はアクティブ プール内）、セッション アフィニティの選択が重要になります。

  • パケットの宛先 IP アドレスに関係なく、パケットの送信元 IP アドレスのみに基づいて、クライアントからのすべてのパケットを同じバックエンド VM で処理する必要がある場合は、CLIENT_IP_NO_DESTINATION セッション アフィニティを使用します。トラフィック パターンによっては、一部のバックエンド VM が他のバックエンド VM よりも多くのパケットまたは接続を受信する場合があります。

  • CLIENT_IP_NO_DESTINATION 以外のセッション アフィニティ オプションを使用する場合、ロードバランサは、少なくともパケットの送信元 IP アドレスと宛先 IP アドレスの両方を含む情報に基づいてバックエンド VM を選択します。送信元 IP アドレスが同じでも宛先 IP アドレスが異なれば、同じクライアントから送信されたパケットが異なるバックエンド VM にルーティングされる場合があります。

接続トラッキング ポリシー

このセクションでは、内部パススルー ネットワーク ロードバランサの接続トラッキング動作を制御する設定について説明します。接続トラッキング ポリシーには次の設定が含まれます。

• トラッキング モード
• 異常なバックエンドでの接続の永続性
• アイドル タイムアウト

接続トラッキング モード

トラッキング モードでは、使用する接続トラッキング アルゴリズムを指定します。トラッキング モードには、PER_CONNECTION（デフォルト）と PER_SESSION の 2 つがあります。

• PER_CONNECTION（デフォルト）。このモードでは、TCP トラフィックと UDP トラフィックはセッション アフィニティの設定に関係なく、常に 5 タプルごとにトラッキングされます。これは、接続トラッキングのキー（5 タプル）が、構成されたセッション アフィニティの設定（たとえば、CLIENT_IP_PROTO 設定の 3 タプル）と異なることを意味します。その結果、セッション アフィニティが分割され、バックエンドのセットや状態が変更されたときに、セッションの新しい接続が別のバックエンドを選択する場合があります。

• PER_SESSION。このモードでは、構成されたセッション アフィニティに従って TCP と UDP のトラフィックを追跡します。つまり、セッション アフィニティが CLIENT_IP または CLIENT_IP_PROTO の場合、このモードを構成すると、それぞれ 2 タプルと 3 タプルの接続トラッキングが行われます。これは、アフィニティの消失が高コストで、バックエンドの追加後も回避すべきシナリオでは望ましい場合があります。

セッション アフィニティが NONE または CLIENT_IP_PORT_PROTO に設定されている場合、接続トラッキング モードの設定は冗長です。プロトコルごとに異なるセッション アフィニティが設定されているこれらのトラッキング モードの動作については、次の表をご覧ください。

バックエンドの選択		接続トラッキング モード
セッション アフィニティの設定	バックエンド選択のハッシュ方法	PER_CONNECTION（デフォルト）	PER_SESSION
デフォルト: セッション アフィニティなし NONE	5 タプルハッシュ	5 タプル接続トラッキング	5 タプル接続トラッキング
クライアント IP、宛先なし CLIENT_IP_NO_DESTINATION	1 タプルハッシュ	5 タプル接続トラッキング	1 タプル接続トラッキング
クライアント IP CLIENT_IP （外部パススルー ネットワーク ロードバランサのクライアント IP、宛先 IP と同じ）	2 タプルハッシュ	5 タプル接続トラッキング	2 タプル接続トラッキング
クライアント IP、宛先 IP、プロトコル CLIENT_IP_PROTO	3 タプルハッシュ	5 タプル接続トラッキング	3 タプル接続トラッキング
クライアント IP、クライアント ポート、宛先 IP、宛先ポート、プロトコル CLIENT_IP_PORT_PROTO	5 タプルハッシュ	5 タプル接続トラッキング	5 タプル接続トラッキング

接続トラッキング モードを変更する方法については、接続トラッキング ポリシーを構成するをご覧ください。

異常なバックエンドでの接続の永続性

正常でないバックエンドでの接続の永続性の設定は、バックエンドが異常になった後（バックエンドがロードバランサの構成済みバックエンド インスタンス グループに残っている限り）、選択したバックエンドで既存の接続を持続するかどうかを制御します。

このセクションで説明する動作は、バックエンド VM をインスタンス グループから削除する場合、またはインスタンス グループをバックエンド サービスから削除する場合には適用されません。このような場合、確立された接続はコネクション ドレインの有効化で説明されている内容に基づいてのみ維持されます。

使用できる接続の永続性に関するオプションは次のとおりです。

• DEFAULT_FOR_PROTOCOL（デフォルト）
• NEVER_PERSIST
• ALWAYS_PERSIST

次の表には、接続の永続性のオプションと、さまざまなプロトコル、セッション アフィニティのオプション、トラッキング モードのために接続を維持する方法がまとめられています。

異常なバックエンド オプションでの接続の永続性	接続トラッキング モード
	PER_CONNECTION	PER_SESSION
DEFAULT_FOR_PROTOCOL	TCP: 異常なバックエンドで接続が維持されます（すべてのセッション アフィニティ） UDP: 異常なバックエンドで接続が持続することはありません	TCP: セッション アフィニティが NONE または CLIENT_IP_PORT_PROTO の場合に、異常なバックエンドで接続が維持されます UDP: 異常なバックエンドで接続が持続することはありません
NEVER_PERSIST	TCP、UDP: 異常なバックエンドで接続が持続することはありません
ALWAYS_PERSIST	TCP、UDP: 異常なバックエンドで接続が維持されます（すべてのセッション アフィニティ） このオプションは、高度なユースケースにのみ使用してください。	構成が不可能

接続の永続性の動作を変更する方法については、接続トラッキング ポリシーを構成するをご覧ください。

注: ロードバランサが異常なバックエンドから接続を移動すると、ロードバランサによって新しいトラッキング テーブル エントリが作成されます。新しいエントリは、設定したセッション アフィニティに基づいて別のバックエンドに接続をマッピングします。新しいエントリは、他のエントリと同様に有効な状態を保持します。異常なバックエンドが正常な状態に戻っても、それだけでは接続トラッキング テーブルのエントリは削除されません。（ただし、フェイルバックがトリガーされ、フェイルオーバー時のコネクション ドレインとフェイルバックが無効になっている場合は除きます）。

アイドル タイムアウト

デフォルトでは、接続トラッキング テーブル内のエントリは、ロードバランサがエントリに一致した最後のパケットを処理してから 600 秒後に失効します。このデフォルトのアイドル タイムアウト値は、接続トラッキングが 5 タプル未満の場合（つまり、セッション アフィニティが CLIENT_IP または CLIENT_IP_PROTO に構成されている場合）にのみ変更できます。トラッキング モードは PER_SESSION です）。

構成可能なアイドル タイムアウトの最大値は 57,600 秒（16 時間）です。

アイドル タイムアウト値を変更する方法については、接続トラッキング ポリシーの構成をご覧ください。

単一クライアントのデプロイの接続

クライアントが 1 つのみ存在する内部パススルー ネットワーク ロードバランサの IP アドレスへの接続をテストする場合は、次の点に注意してください。

• クライアント VM がロード バランシングされる VM でない場合（つまり、バックエンド VM でもない場合）、新しい接続はロードバランサの正常なバックエンド VM に配信されます。ただし、すべてのセッション アフィニティ オプションは、少なくともクライアント システムの IP アドレスに依存するため、同じクライアントからの接続が、想定よりも頻繁に同じバックエンド VM に分散される可能性があります。

  実地面では、単一クライアントから内部パススルー ネットワーク ロードバランサに接続した場合、これを介したトラフィック分散を正確にモニタリングできないことになります。トラフィック分散のモニタリングに必要なクライアント数は、ロードバランサの種類、トラフィックの種類、正常なバックエンドの数によって異なります。

• クライアント VM がロードバランサのバックエンド VM でもある場合、ロードバランサの転送ルールの IP アドレスに送信される接続には、常に同じバックエンド VM（クライアント VM でもある）が応答します。この現象は、バックエンド VM が正常であるかどうかにかかわらず、ロードバランサの内部転送ルールで指定されたプロトコルとポート上のトラフィックだけではなく、ロードバランサの IP アドレスに送信されたすべてのトラフィックで発生します。

  詳細については、負荷分散された VM からのリクエストの送信をご覧ください。

コネクション ドレイン

コネクション ドレインは、次の場合に確立済みの接続に適用されるプロセスです。

• VM またはエンドポイントがバックエンド（インスタンス グループまたは NEG）から削除された場合。
• バックエンドが VM またはエンドポイントを削除する場合（置換、放棄、ローリング アップグレード、スケールダウンにより）。

デフォルトでは、コネクション ドレインは無効になっています。無効にすると、確立された接続はできる限り早く終了します。コネクション ドレインを有効にすると、確立された接続は設定可能なタイムアウトまで維持され、その時間が経過するとバックエンド VM インスタンスは終端されます。

コネクション ドレインのトリガーとコネクション ドレインを有効にする方法の詳細については、コネクション ドレインの有効化をご覧ください。

UDP の断片化

内部パススルー ネットワーク ロードバランサは、断片化された UDP パケットと断片化されていない UDP パケットの両方を処理できます。断片化された UDP パケットをアプリケーションで使用する場合は、次の点に留意してください。

• UDP パケットは、 Google CloudVPC ネットワークに到達する前に断片化される場合があります。
• Google Cloud VPC ネットワークでは、到達した UDP フラグメントが（すべてのフラグメントの到達を待たずに）転送されます。
• Google Cloud 以外のネットワークとオンプレミス ネットワーク機器では、UDP フラグメントが到達すると転送される可能性、すべてのフラグメントが到達するまで断片化された UDP パケットが遅延される可能性、または断片化された UDP パケットが破棄される可能性があります。詳しくは、ネットワーク プロバイダまたはネットワーク機器のドキュメントをご覧ください。

断片化された UDP パケットを処理する可能性があり、それを同じバックエンドにルーティングする必要がある場合は、次の転送ルールとバックエンド サービスの構成パラメータを使用します。

• 転送ルールの構成: ロード バランシングされた IP アドレスごとに UDP 転送ルールを 1 つだけ使用し、すべてのポートでトラフィックを受信するように転送ルールを構成します。これで、すべてのフラグメントが同じ転送ルールに渡されるようになります。断片化されたパケット（最初のフラグメント以外）には宛先ポートがありませんが、すべてのポートのトラフィックを処理する転送ルールを構成すると、ポート情報がない UDP フラグメントも受信するように構成されます。すべてのポートを構成するには、Google Cloud CLI を使用して --ports=ALL を設定するか、API を使用して allPorts を True に設定します。

• バックエンド サービスの構成: バックエンド サービスのセッション アフィニティを CLIENT_IP（2 タプルハッシュ）または CLIENT_IP_PROTO（3 タプルハッシュ）に設定し、ポート情報を含む UDP パケットとポート情報がない UDP フラグメント（最初のフラグメント以外）に同じポートが選択されるようにします。バックエンド サービスの接続トラッキング モードを PER_SESSION に設定して、接続トラッキング テーブルのエントリが同じ 2 タプルハッシュまたは 3 タプルハッシュを使用して構築されるようにします。

フェイルオーバー

内部パススルー ネットワーク ロードバランサを使用すると、一部のバックエンドをフェイルオーバー バックエンドとして指定できます。これらのバックエンドは、プライマリ バックエンド インスタンス グループの正常な VM の数が、構成可能なしきい値を下回る場合にのみ使用されます。デフォルトでは、すべてのプライマリ VM とフェイルオーバー VM が異常な状態になると、最後の手段として、Google Cloud はすべてのプライマリ VM 間でのみ新しい接続トラフィックを分散します。

内部パススルー ロードバランサのバックエンド サービスにバックエンドを追加すると、デフォルトでは、そのバックエンドがプライマリ バックエンドになります。バックエンドは、ロードバランサのバックエンド サービスに追加するときに指定できます。また、後でバックエンド サービスを編集して、フェイルオーバー バックエンドに指定することもできます。

内部パススルー ネットワーク ロードバランサのフェイルオーバーのコンセプトの概要については、内部パススルー ネットワーク ロードバランサのフェイルオーバーをご覧ください。

次のステップ

• フェイルオーバーを使用する内部パススルー ネットワーク ロードバランサを構成してテストする。内部パススルー ネットワーク ロードバランサにフェイルオーバーを構成するをご覧ください。
• 内部パススルー ネットワーク ロードバランサを構成してテストする。内部パススルー ネットワーク ロードバランサを設定するをご覧ください。