すべてのプロダクト
Search
ドキュメントセンター

Server Load Balancer:GWLB サーバーグループ

最終更新日:May 06, 2026

サーバーグループは、Geneve プロトコルをサポートするバックエンドサーバーの論理グループです。各サーバーグループは、GWLB インスタンスから 1 つ以上のバックエンドサーバーにトラフィックをルーティングします。本トピックでは、サーバーグループの基本概念について説明します。

サーバーグループタイプ

GWLB は、Server および IP Address の 2 種類のサーバーグループをサポートしています。

サーバーグループタイプ

バックエンドサーバータイプ

説明

Server

ECS インスタンス、ENI、ECI インスタンスをバックエンドサーバーとして追加できます。

追加されたバックエンドサーバーは、サーバーグループと同じ VPC 内にデプロイされている必要があります。これらのバックエンドサーバーは、GWLB からのリクエストを受信します。

IP address

IP アドレスをバックエンドサーバーとして追加できます。

以下の CIDR ブロック内のプライベート IP アドレスを入力できます。

  • 10.0.0.0/8

  • 100.64.0.0/10

  • 172.16.0.0/12

  • 192.168.0.0/16

重要
  • GWLB インスタンスの Server タイプのサーバーグループに含まれるバックエンドサーバーがリリースされたり、そのプライベート IP アドレスが変更されたりした場合、GWLB はバックエンドサーバーを自動的に更新します。

  • GWLB インスタンスの IP タイプのサーバーグループに含まれるバックエンドサーバーがリリースされた場合、GWLB はサーバーグループを自動的に更新しません。GWLB インスタンスの IP タイプのサーバーグループに含まれるバックエンドサーバーをリリースまたは変更する前に、該当のバックエンドサーバーを GWLB サーバーグループから削除することを推奨します。これにより、サービスへの影響を回避できます。

トラフィックスケジューリングアルゴリズム

GWLB は、以下のトラフィックスケジューリングアルゴリズムをサポートしています。

  • 5 タプルハッシュ:5 タプル(送信元 IP アドレス、送信元ポート、宛先 IP アドレス、宛先ポート、IP プロトコル)をハッシュ化してリクエストをルーティングします。同じ 5 タプルを持つすべてのリクエストは、同一のバックエンドサーバーに送信されます。

  • 3 タプルハッシュ:3 タプル(送信元 IP アドレス、宛先 IP アドレス、IP プロトコル)をハッシュ化してリクエストをルーティングします。同じ 3 タプルを持つすべてのリクエストは、同一のバックエンドサーバーに送信されます。

  • 2 タプルハッシュ:2 タプル(送信元 IP アドレス、宛先 IP アドレス)をハッシュ化してリクエストをルーティングします。同じ 2 タプルを持つすべてのリクエストは、同一のバックエンドサーバーに送信されます。

接続ドレイン

バックエンドサーバーを削除する際に既存の接続を適切に処理できるよう、接続ドレインを有効化できます。接続ドレインタイムアウトを設定することで、進行中のリクエストが完了する時間を確保できます。

バックエンドサーバーが削除されると、GWLB インスタンスは、削除されたバックエンドサーバーに新しい接続リクエストをルーティングしなくなります。その後、GWLB インスタンスは、該当のバックエンドサーバーにルーティングされた既存の接続を次のように管理します。

  • 接続ドレインが無効の場合(デフォルト):アイドル接続タイムアウトが経過するまで既存の接続は維持されます。このタイムアウト後、GWLB はサーバーへのパケット転送を停止します。

  • 接続ドレインが有効の場合:既存の接続は、設定された接続ドレインタイムアウトの間維持されます。このタイムアウト後は、アイドル接続タイムアウトが適用されます。アイドルタイムアウトも超過した場合、GWLB は接続をクローズし、サーバーへのパケット転送を停止します。

ヘルスチェック

バックエンドサーバーの可用性をモニターするために、ヘルスチェックを設定できます。GWLB では、サーバーグループレベルで GWLB ヘルスチェック設定を定義できます。

  • サポートされるプロトコル:TCP および HTTP。

  • サーバーグループでは、ヘルスチェックがデフォルトで有効になっています。デフォルトのプロトコルは TCP、デフォルトのポートは 80 です。

  • ヘルスチェックが有効な場合、GWLB は新しい接続を正常なサーバーに自動的にルーティングし、グループ内のすべてのバックエンドサーバーを継続的にモニターします。サーバーは、連続して指定回数のヘルスチェックに合格した場合(ヘルスしきい値)にのみ正常とみなされます。複数回のチェックを要求することで誤検知を減らし、一時的な障害によるサービス中断を防止できます。

    • バックエンドサーバーがヘルスチェックに失敗した場合、GWLB は新しい接続をそのサーバーに送信せず、他の正常なバックエンドサーバーにルーティングします。既存の接続はアイドルタイムアウトが経過するまで継続できます。その後、GWLB は異常なサーバーへのパケット転送を停止します。

    • サーバーが回復してヘルスチェックに合格すると、GWLB はそのサーバーを GWLB サービスに復帰させます。

    • 各ヘルスチェックの実行後、GWLB は接続をクローズします。

関連ドキュメント