サーバーグループは、クライアントリクエストをバックエンドサーバーにルーティングします。リスナーを追加する際、サーバーグループを指定する必要があります。リスナーは、設定されたプロトコルとポートに基づいて、対応するサーバーグループにトラフィックを転送します。Network Load Balancer (NLB) は、ヘルスチェックを使用してバックエンドサーバーの状態を監視します。
NLB サーバーグループのタイプ
サーバーグループタイプ | バックエンドサーバータイプ | 説明 |
サーバータイプ | Elastic Compute Service (ECS)、ENI、ECI インスタンスをバックエンドサーバーとして追加できます。 | バックエンドサーバーは、NLB インスタンスからのリクエストを受信するために、サーバーグループと同じ VPC にある必要があります。 |
IP タイプ | IP アドレスをバックエンドサーバーとして追加できます。 | IP アドレスは、サーバーグループが配置されている VPC の CIDR ブロックに限定されません。リージョンや VPC をまたいだサーバー、またはオンプレミスデータセンター内のサーバーの IP アドレスを追加できます。これらの IP アドレスは、NLB インスタンスからのリクエストを受信するバックエンドサーバーとして機能します。
プライベート IP アドレスのみがサポートされ、パブリック IP アドレスはサポートされていません。 |
サーバーがリリースされたり、プライベート IP アドレスが変更されたりしても、NLB はバックエンドサーバーの情報を自動的に更新しません。サービスの中断を防ぐため、サーバーをリリースしたり、設定を変更したりする前に、サーバーグループからサーバーを削除してください。
サーバーグループの作成
- NLBコンソールにログインします。
上部のナビゲーションバーで、NLBインスタンスがデプロイされています。
左側のナビゲーションウィンドウで、を選択します。
サーバーグループページで[サーバーグループの作成] をクリックします。
サーバーグループの作成 ダイアログボックスで、次の設定を行い、作成 をクリックします。
パラメーター
説明
[サーバーグループタイプ]
サーバーグループのタイプを選択します。
[サーバータイプ]：ECS、ENI、ECI インスタンスをバックエンドサーバーとして追加できます。
[IP アドレスタイプ]：IP アドレスをバックエンドサーバーとして追加できます。
プライベート IP アドレスのみ追加できます。パブリック IP アドレスはサポートされていません。
[VPC]
VPC ドロップダウンリストから VPC を選択します。
[バックエンドサーバープロトコル]
バックエンドプロトコルを選択します。
TCP：サーバーグループを TCP および TCP/SSL リスナーに関連付けます。
UDP：サーバーグループを UDP リスナーに関連付けます。
[スケジューリングアルゴリズム]
スケジューリングアルゴリズムを選択します。
[ラウンドロビン]：リクエストをバックエンドサーバーに順番に分散します。
[重み付けラウンドロビン] (デフォルト)：リクエストを重みに基づいてバックエンドサーバーに分散します。重みが大きいバックエンドサーバーほど多くのリクエストを受信します。
[ソース IP ハッシュ]：ソース IP アドレスに基づく Consistent Hashing を使用します。同じソース IP アドレスからのリクエストは、同じバックエンドサーバーにルーティングされます。
[4 タプルハッシュ]：4 タプル (送信元 IP、宛先 IP、送信元ポート、宛先ポート) に基づく Consistent Hashing を使用します。同じストリームからのパケットは、同じバックエンドサーバーにルーティングされます。
[QUIC ID ハッシュ]：QUIC 接続 ID に基づく Consistent Hashing を使用します。同じ QUIC ID を持つリクエストは、同じバックエンドサーバーにルーティングされます。
バックエンドプロトコルが UDP の場合にのみ、QUIC ID ハッシュを選択できます。
QUIC プロトコルは急速に進化しています。このアルゴリズムは draft-ietf-quic-transport-10 に基づいて実装されています。すべての QUIC バージョンとの互換性は保証されていません。本番環境でこのアルゴリズムを使用する前に、十分なテストを実施することを推奨します。
[重み付け最小接続]：各バックエンドサーバーの重みと実際の負荷 (接続数) の両方に基づいてリクエストを分散します。バックエンドサーバーの重みが同じ場合、接続数が最も少ないサーバーがより多くのリクエストを受信します。
[リソースグループ]
サーバーグループのリソースグループを選択します。
[タグ]
タグキー と タグ値 を設定します。
[IP バージョン]
IP バージョンを選択します。
IPv4 (デフォルト)：IPv4 バックエンドサーバーのみを追加できます。
[IPv4/IPv6 デュアルスタック]：IPv4 と IPv6 の両方のバックエンドサーバーを追加できます。
選択した VPC で IPv6 が有効になっていない場合は、IPv4 のみを選択できます。
[IP バージョンアフィニティ]
IP バージョン を IPv4/IPv6 デュアルスタック に設定した場合、IP バージョンアフィニティ を設定できます。
[アフィニティなし] (デフォルト)：リクエストは、ソースの IP バージョンに関係なく、スケジューリングアルゴリズムに基づいて正常なバックエンドサーバーに分散されます。
[アフィニティモード]：リクエストは、ソース IP バージョンに基づいてルーティングされます。IPv4 リクエストは IPv4 バックエンドサーバーにのみルーティングされ、IPv6 リクエストは IPv6 バックエンドサーバーにのみルーティングされます。
アフィニティモード を選択する場合は、バックエンドサーバーグループに正常な IPv4 と IPv6 の両方のターゲットが含まれていることを確認してください。そうでない場合、対応するプロトコルのリクエストは正常に転送できません。
[グレースフル・シャットダウン]
接続ドレインを有効にするかどうかを指定します。この機能はデフォルトで無効になっています。
接続ドレインを有効にする場合は、接続ドレインタイムアウト も設定する必要があります。タイムアウトは 0〜900 秒の範囲で設定できます。値が 0 の場合は、接続が即座にドレインされることを示します。
バックエンドサーバーが削除されたり、ヘルスチェックに失敗したりした場合：
接続ドレインが無効 (デフォルト) の場合、既存の接続はアクティブに中断されません。クライアントが切断するか、セッションが期限切れになった場合にのみ中断されます。
接続ドレインが有効な場合、既存の接続はタイムアウトが終了するまで維持されます。その後、接続はアクティブに閉じられ、スムーズなサービス移行を保証します。
[クライアントアドレスの保持]
クライアント IP の保持を有効にするかどうかを指定します。この機能を有効にすると、バックエンドサーバーはクライアントの送信元 IP アドレスを取得できます。
この機能を無効にすると、バックエンドサーバーはクライアントとして機能して NLB インスタンスにアクセスできます。クライアントの送信元 IP アドレスを取得するには、リスナーで Proxy Protocol を有効にしてください。
クライアントアドレスの保持を有効にした後、IP タイプのサーバーグループはクライアントの送信元アドレスを自動的に引き継ぐことをサポートしません。送信元アドレスを取得するには、リスナーで Proxy Protocol を設定してください。
[フルポート転送]
マルチポート転送を有効または無効にします。有効にすると、バックエンドサーバーを追加するときにポートを指定する必要がなくなり、NLB はフロントエンドのリクエストポートに従ってトラフィックをバックエンドサーバーに転送します。
リスナーで[マルチポート転送] 機能を有効にする場合は、バックエンドサーバーグループに対してもこの機能を有効にする必要があります。
[ヘルスチェック]
ヘルスチェックを有効にするかどうかを指定します。
[ヘルスチェックの設定]
ヘルスチェックを有効にする場合は、変更 をクリックしてヘルスチェック設定を変更できます。
[ヘルスチェックプロトコル]
ヘルスチェックのプロトコルを選択します。
TCP (デフォルト)：SYN パケットを送信して、サーバーポートに到達可能かどうかを確認します。
HTTP：HEAD または GET リクエストを送信して、サーバー上のアプリケーションが正常かどうかを確認します。
UDP：ICMP Echo Request および UDP プローブパケットを送信して、ステータス情報を取得します。
[ヘルスチェックプロトコル] に ヘルスチェックプロトコル を選択できるのは、サーバーグループのバックエンドプロトコルが [UDP] の場合のみです。
[ヘルスチェック方法]
ヘルスチェックメソッドを選択します。
GET：レスポンスパケットが 8 KB を超える場合、パケットは切り捨てられます。これはヘルスチェックの結果には影響しません。
HEAD：HTTP リスナーのヘルスチェックでは、デフォルトで HEAD が使用されます。バックエンドサーバーが HEAD リクエストをサポートしていることを確認してください。バックエンドアプリケーションが HEAD リクエストをサポートしていないか無効にしている場合、ヘルスチェックが失敗する可能性があります。この場合は、GET メソッドを使用してください。
このパラメーターは、ヘルスチェックプロトコルが [HTTP] の場合にのみ有効です。
[ヘルスチェックプロトコルバージョン]
HTTP バージョンを選択します：[HTTP/1.0] (デフォルト) または [HTTP/1.1]。
ヘルスチェックプロトコルのバージョンは、バックエンドアプリケーションがサポートする HTTP バージョンと一致する必要があります。そうでない場合、ヘルスチェックが失敗する可能性があります。バックエンドサーバーが：
HTTP 1.0 のみをサポートしている場合は、HTTP/1.0 を選択する必要があります。
HTTP 1.1 のみをサポートしている場合は、HTTP/1.1 を選択する必要があります。
HTTP 1.0 と HTTP 1.1 の両方をサポートしている場合は、どちらのバージョンも選択できます。
このパラメーターは、ヘルスチェックプロトコルが [HTTP] の場合にのみ有効です。
[ヘルスチェックポート]
ヘルスチェックサービスがバックエンドサーバーにアクセスするために使用するプローブポートを選択します。
[バックエンドサーバーポート]：デフォルトでは、ヘルスチェックサービスはバックエンドサーバーのポートを使用します。
[カスタムポート]：ヘルスチェック用のポートを指定します。
マルチポート転送を有効にする場合は、ヘルスチェックポートを指定する必要があります。
[ヘルスチェックパス]
ヘルスチェックページの URL を入力します。
このパラメーターは、ヘルスチェックプロトコルが [HTTP] の場合にのみ有効です。
[ヘルスチェックドメイン名]
ヘルスチェック用のドメイン名を入力します。
[バックエンドサーバーのイントラネット IP] (デフォルト)：バックエンドサーバーのプライベート IP アドレスがヘルスチェックのドメイン名として使用されます。
[カスタムドメイン名]：ドメイン名を入力します。
このパラメーターは、ヘルスチェックプロトコルが [HTTP] の場合にのみ有効です。
[ヘルスチェックステータスコード]
ヘルスチェックの成功を示すステータスコードを選択します。[http_2xx] (デフォルト)、[http_3xx]、[http_4xx]、および [http_5xx] を選択できます。
このパラメーターは、ヘルスチェックプロトコルが [HTTP] の場合にのみ有効です。
[カスタムリクエスト / レスポンス]
UDP リスナーのヘルスチェックを設定する際に、カスタムリクエスト / レスポンス を有効にできます。次に、カスタムリクエスト フィールドにリクエスト内容 (例：youraccountID) を入力し、カスタムレスポンス フィールドに期待するレスポンス (例：slb123) を入力します。
また、バックエンドサーバー上のアプリケーションに対応するヘルスチェックのレスポンスロジックを追加する必要があります。たとえば、アプリケーションが
youraccountID を含むリクエストを受信した場合、slb123 を含むレスポンスを返す必要があります。
NLB インスタンスがバックエンドサーバーから期待するレスポンスを受信した場合、ヘルスチェックは成功します。それ以外の場合、ヘルスチェックは失敗します。この方法は、UDP ヘルスチェックの信頼性を最大限に高めます。
このパラメーターは、ヘルスチェックプロトコルが [UDP] の場合にのみ有効です。
[応答タイムアウト期間]
ヘルスチェックリクエストへの応答を待つ期間。バックエンドサーバーが指定された期間内に応答しない場合、ヘルスチェックは失敗します。
[ヘルスチェック間隔]
ヘルスチェックが実行される間隔。
ヘルスチェックプロトコル を [UDP] に設定する場合は、ヘルスチェック間隔 の値が 応答タイムアウト間隔 の値以上であることを確認してください。これにより、タイムアウトによる UDP プローブの誤判定を防ぎます。
[正常しきい値]
バックエンドサーバーの状態を異常から正常に変更するために必要な、連続したヘルスチェックの成功回数。
[異常しきい値]
バックエンドサーバーのヘルスチェックステータスが正常から異常に変更されるまでに必要な、連続したヘルスチェックの失敗回数。
バックエンドサーバーの追加 (サーバータイプ)
サーバータイプのサーバーグループを作成した場合、受信リクエストを処理するためにバックエンドサーバーを追加する必要があります。マルチポート転送が有効になっているサーバーグループには、同じ ECS、ENI、または ECI インスタンスを複数回追加することはできません。
サーバーグループ ページで、管理したいサーバーグループを見つけ、次のいずれかの方法でバックエンドサーバーページを開きます。
操作 列で、バックエンドサーバーの変更 をクリックします。
サーバーグループ ID をクリックします。サーバーグループの詳細ページで、バックエンドサーバー タブをクリックします。
バックエンドサーバー タブで、バックエンドサーバーの追加 をクリックします。
バックエンドサーバーの追加 パネルで、サーバータイプ を選択し、次へ をクリックします。
サーバータイプが ECS/ENI の場合、ターゲットサーバーを選択するか、右上隅の ECS の購入 をクリックします。
ENI を選択するには、ターゲットの ECS インスタンスにセカンダリ ENI がアタッチされており、上級モード スイッチがオンになっていることを確認してください。次に、ターゲットの ECS インスタンス ID の右側にある
アイコンをクリックし、ENI を選択します。サーバーグループの IP バージョン が IPv4/IPv6 デュアルスタック の場合、IP 列ヘッダーの横にある設定アイコンをクリックします。IP アドレス ダイアログボックスで、IP アドレスポリシーを選択します。
[IPv4 優先]：利用可能なプライマリ IPv4 アドレスがデフォルトで選択されます。
[IPv6 優先]：利用可能な IPv6 アドレスがデフォルトで選択されます。ENI に複数の IPv6 アドレスがある場合、リストの順序に基づいて最初に使用可能なものが選択されます。
[デュアルスタック]：利用可能なプライマリ IPv4 アドレスと、最初に使用可能な IPv6 アドレスが選択されます。
このオプションは、ENI でデフォルトで選択される IP アドレスを設定するだけです。IP アドレス列で手動で選択を変更することもできます。
サーバータイプが ECI の場合、ターゲットサーバーを選択するか、右上隅の Elastic Container インスタンスの購入 をクリックします。
サーバーのポートと重みを設定し、OK をクリックします。
サーバーグループでマルチポート転送を有効にしている場合、バックエンドサーバーを追加する際にポートを指定する必要はありません。NLB は、フロントエンドのリクエストポートに従ってトラフィックをバックエンドサーバーに転送します。
デフォルトの重みは 100 です。重みが大きいサーバーほど多くのリクエストを受信します。
アイコンにカーソルを合わせると、複数のサーバーの重みとポートを一括で変更できます。下方向へコピー をクリック：現在のサーバーの重みまたはポートを変更すると、それより下のすべてのサーバーの重みまたはポートが同じ値に変更されます。
上方向へコピー をクリック：現在のサーバーの重みまたはポートを変更すると、それより上のすべてのサーバーの重みまたはポートが同じ値に変更されます。
すべてコピー をクリック：現在のサーバーの重みまたはポートを変更すると、サーバーグループ内のすべてのサーバーの重みまたはポートが同じ値に変更されます。
リセット をクリック：
重み の横にある リセット をクリックして、サーバーグループ内のすべてのサーバーのデフォルトの重みに復元します。
ポート の横にある リセット をクリックして、サーバーグループ内のすべてのサーバーのポート番号をクリアします。
警告サーバーの重みを 0 に設定すると、そのサーバーは新しいリクエストを受信しなくなります。
バックエンドサーバーの追加 (IP タイプ)
IP タイプのサーバーグループを作成した場合、受信リクエストを処理するためにバックエンドサーバーとして IP アドレスを追加する必要があります。マルチポート転送が有効になっているサーバーグループには、同じ IP アドレスを複数回追加することはできません。
同じ VPC 内の NLB インスタンスの仮想 IP アドレス (VIP)、または 以降に同じ VPC で作成された ALB インスタンスの VIP を追加することはできません。
プライベート IP アドレスのみがサポートされ、パブリック IP アドレスはサポートされていません。
サーバーグループ ページで、ターゲットのサーバーグループを見つけ、次のいずれかの方法で IP アドレスを追加します。
操作 列で、バックエンドサーバーの変更 をクリックします。
サーバーグループ ID をクリックします。
サーバーグループの詳細ページで、バックエンドサーバー タブをクリックし、IP アドレスの追加 をクリックします。
バックエンドサーバーの追加 パネルの サーバーの選択 タブで、IP アドレスを入力し、次へ をクリックします。
IP アドレスに複数のポートと重みを設定できます。
ポート/重み タブで、追加した IP アドレスのポートと重みを設定し、OK をクリックします。
サーバーグループでマルチポート転送を有効にしている場合、バックエンドサーバーを追加する際にポートを指定する必要はありません。NLB は、フロントエンドのリクエストポートに従ってトラフィックをバックエンドサーバーに転送します。
デフォルトの重みは 100 です。重みが大きいサーバーほど多くのリクエストを受信します。
アイコンにカーソルを合わせると、複数のサーバーの重みとポートを一括で変更できます。下方向へコピー をクリック：現在のサーバーの重みまたはポートを変更すると、それより下のすべてのサーバーの重みまたはポートが同じ値に変更されます。
上方向へコピー をクリック：現在のサーバーの重みまたはポートを変更すると、それより上のすべてのサーバーの重みまたはポートが同じ値に変更されます。
すべてコピー をクリック：現在のサーバーの重みまたはポートを変更すると、サーバーグループ内のすべてのサーバーの重みまたはポートが同じ値に変更されます。
リセット をクリック：
重み の横にある リセット をクリックして、サーバーグループ内のすべてのサーバーのデフォルトの重みに復元します。
ポート の横にある リセット をクリックして、サーバーグループ内のすべてのサーバーのポート番号をクリアします。
警告サーバーの重みを 0 に設定すると、そのサーバーは新しいリクエストを受信しなくなります。
その他の操作
アクション | 手順 |
基本情報の編集 | サーバーグループ ページで、ターゲットのサーバーグループを見つけて 基本情報の変更 をクリックします。基本情報の変更 ダイアログボックスで、スケジューリングアルゴリズム、IP バージョンアフィニティ (サーバーグループの IP バージョン が IPv4/IPv6 デュアルスタック の場合のみ利用可能)、接続ドレイン、およびクライアント IP の保持設定を変更できます。 |
ヘルスチェック設定の編集 | サーバーグループ ページで、ターゲットのサーバーグループを見つけて ヘルスチェック設定の変更 をクリックします。ヘルスチェック設定の変更 ダイアログボックスで、ヘルスチェック設定を変更します。 警告
|
バックエンドサーバーの削除 | 必要に応じて、サーバーグループからバックエンドサーバーを削除できます。 警告 サーバーグループからバックエンドサーバーを直接削除すると、サービスが中断される可能性があります。これを回避するには、まずサーバーの重みを 0 に設定してから、サーバーグループから削除してください。
|
サーバーグループの削除 | サーバーグループを削除できるのは、リスナーの転送ルールに関連付けられていない場合のみです。サーバーグループを削除しても、そのバックエンドサーバーには影響しません。バックエンドサーバーとして登録されていた ECS、ENI、または ECI インスタンスが不要になった場合は、停止またはリリースできます。 サーバーグループ ページで、ターゲットのサーバーグループを見つけます。操作 列で、 を選択し、OK をクリックします。 |
関連 API
CreateServerGroup： NLB インスタンスのサーバーグループを作成します。
DeleteServerGroup： NLB インスタンスのサーバーグループを削除します。
AddServersToServerGroup： NLB インスタンスのサーバーグループにバックエンドサーバーを追加します。
RemoveServersFromServerGroup： NLB インスタンスのサーバーグループからバックエンドサーバーを削除します。
UpdateServerGroupAttribute： NLB インスタンスのサーバーグループの設定を更新します。
よくある質問
NLBは、バックエンドの接続数しきい値にもとづく新規接続の転送制限をサポートしていますか？
いいえ。現在のスケジューリングアルゴリズム (重み付きラウンドロビン、ソース IP ハッシュ、4 タプルハッシュなど) は、接続数に基づいたトラフィックドレイン戦略を提供していません。ACS StatefulSet などのシナリオでバックエンド Pod への新規接続を制御するには、次の代替手段を使用できます。
ヘルスチェックフォールバック：サーバーグループに [ヘルスチェック] を設定します。バックエンド Pod が接続を使い果たしたためにプローブに応答できない場合、連続失敗回数が [異常しきい値] に達すると、NLB は自動的にバックエンドを異常と判断し、新しいリクエストの転送を停止します。バックエンドの例外をより速く検出し、トラフィック損失を減らすために、[間隔] を適切に短縮し、[異常しきい値] を低くすることを推奨します。
接続の正常な中断：サーバーグループを作成するときに [接続ドレイン] を有効にします。バックエンドがヘルスチェックによって削除された後、確立された TCP 長時間接続は、設定されたタイムアウト期間内に正常に送信を継続でき、すぐに中断されることはありません。
Pod側のアクティブ制御：Pod 内で接続数の監視を実装し、接続数が上限に近づいたときに新しい接続を積極的に拒否する (たとえば、エラー応答を返すか、リスニングポートを閉じる) ことを推奨します。これをヘルスチェックと組み合わせて使用することで、より正確なトラフィック制御を実現できます。