サーバーグループは、1 つ以上のバックエンドサーバーの論理的なグループです。Classic Load Balancer (CLB) は、ビジネスリクエストをサーバーグループに分散し、サーバーグループはリクエストを適切なバックエンドサーバーにルーティングします。CLB は、デフォルトサーバーグループ、vServer グループ、プライマリ/セカンダリサーバーグループなど、さまざまなタイプのサーバーグループをサポートしています。
サーバーグループタイプの違い
サーバーグループタイプ | デフォルトサーバーグループ | vServer グループ | プライマリ/セカンダリサーバーグループ |
説明 | 各 CLB インスタンスには、1 つのデフォルトサーバーグループのみが付属しています。 | 作成および管理できるサーバーグループです。 | 作成および管理できるサーバーグループです。 |
バックエンドサーバーの数 | 1 つ以上 | 1 つ以上 | 2 つ (1 つはプライマリ、1 つはセカンダリ) |
機能 |
|
|
|
シナリオ | すべてのリクエストが同じバックエンドサーバーのグループに転送される、シンプルなアプリケーションアーキテクチャ。リスナーやドメイン名ごとにカスタムのトラフィック分散は必要ありません。 | 複雑なアプリケーションアーキテクチャ。たとえば、HTTP と HTTPS のリクエストを別々に処理したり、リスナーのポートやドメイン名に基づいてトラフィックを異なるバックエンドサーバーグループに分散したりする必要があります。 | データベースサービスやコア API サービスなど、固定のプライマリセカンダリモードを使用する主要なアプリケーションやサービス。 |
サポートされるリスナータイプ | TCP/UDP/HTTP/HTTPS | TCP/UDP/HTTP/HTTPS | TCP/UDP のみ |
サーバーグループ使用上の注意
CLB インスタンス、リスナー、サーバーグループ間の関係:
リスナーとサーバーグループは CLB インスタンスのリソースです。リスナーとサーバーグループに関する情報は、異なる CLB インスタンス間では共有されません。
異なるリスナーを異なるサーバーグループに関連付けることができます。
1 つのサーバーグループは複数のリスナーにアタッチできますが、1 つのリスナーは 1 つのサーバーグループにしかアタッチできません。
アタッチされたバックエンドサーバーに関する制限:
CLB インスタンスと同じリージョンにあるバックエンドサーバーのみをアタッチできます。リージョンをまたいだサーバーはアタッチできません。
VPC 内の CLB インスタンスの場合、同じ VPC 内のバックエンドサーバーのみをアタッチできます。
VPC 内にない CLB インスタンスの場合、異なる VPC のバックエンドサーバーをアタッチできます。
すべてのタイプの CLB サーバーグループは、Elastic Computing Service (ECS) インスタンス、Elastic Network Interface (ENI)、および Elastic Container Instance (ECI) のアタッチをサポートしています。
バックエンドの ECS インスタンスがホットマイグレーションされた場合、CLB への持続的接続が切断されることがあります。接続を復元するには、アプリケーションが自動的に再接続するように構成されていることを確認してください。
インターネット向けの CLB インスタンスの場合、同じリージョン内の任意の VPC からバックエンドサーバーを追加できます。ただし、追加するすべてのバックエンドサーバーは同じ VPC に属している必要があります。
高可用性に関する推奨事項:
CLB のヘルスチェック機能を有効にし、CLB インスタンスに少なくとも 1 つの正常なバックエンドサーバーがあることを確認してください。
プライマリ/セカンダリサーバーグループでは、プライマリサーバーからセカンダリサーバーへのフェールオーバーはヘルスチェックによってトリガーされます。プライマリサーバーがヘルスチェックに失敗すると、トラフィックはセカンダリサーバーに切り替えられます。デフォルトでは、セカンダリサーバーではヘルスチェックは実行されません。フェールオーバー後にトラフィックを引き継げるように、セカンダリサーバーの可用性を確保する必要があります。
サーバーグループとバックエンドサーバーの管理
デフォルトサーバーグループ
各 CLB インスタンスには、デフォルトサーバーグループが 1 つだけあります。このグループに直接バックエンドサーバーを追加できます。
CLB インスタンスのすべてのリスナーがこのデフォルトサーバーグループを共有します。
複数のデフォルトサーバーグループを作成することはできません。
バックエンドサーバーの追加
リスナー作成時の [バックエンドサーバー] ステップ、またはインスタンス詳細の [サーバーグループ] ページから、デフォルトサーバーグループにバックエンドサーバーを追加できます。
バックエンドサーバーが CLB インスタンスと同じリージョンにあることを確認してください。
ECS インスタンスの追加
Elastic Computing Service (ECS) を選択します。
重みを構成します。
リスナーが重み付きラウンドロビン スケジューリングアルゴリズムを使用する場合、重みが大きいバックエンドサーバーほど多くのリクエストを受信します。詳細については、「Server Load Balancer スケジューリングアルゴリズム」をご参照ください。
重みを 0 に設定すると、サーバーは新しいリクエストを受信しません。
ENI の追加
ECS インスタンスにすでにアタッチされている ENI のみを追加できます。
ENI のプライマリプライベート IP アドレスとセカンダリプライベート IP アドレスを追加できます。
[アドバンストモード] を有効にし、アタッチされた ENI がある ECS インスタンスの横にあるプラス記号アイコンをクリックして、ターゲットの ENI を見つけます。
ターゲット ENI の例:
アタッチする ENI を選択し、プライマリプライベート IP アドレスまたはセカンダリプライベート IP アドレスを選択します。複数の IP アドレスをアタッチできます。
重みを構成します。
リスナーが重み付きラウンドロビン スケジューリングアルゴリズムを使用する場合、重みが大きいバックエンドサーバーほど多くのアクセスリクエストを受信します。詳細については、「Server Load Balancer スケジューリングアルゴリズム」をご参照ください。
重みを 0 に設定すると、サーバーは新しいリクエストを受信しません。
ECI の追加
Elastic Container Instance (ECI) を選択します。
重みを構成します。
リスナーが重み付きラウンドロビン スケジューリングアルゴリズムを使用する場合、重みが大きいバックエンドサーバーほど多くのアクセスリクエストを受信します。詳細については、「Server Load Balancer スケジューリングアルゴリズム」をご参照ください。
重みを 0 に設定すると、サーバーは新しいリクエストを受信しません。
デフォルトサーバーグループのポートの構成
[バックエンドサーバー] ウィザードで初めてリスナーを作成するときにのみ、デフォルトサーバーグループのサーバーポートを設定できます。そのリスナーのデフォルトサーバーグループ内のすべてのサーバーは、同じポートを使用する必要があります。
例:
リスナーを作成した後は、デフォルトサーバーグループのポートを変更することはできません。
リスナーが異なれば、デフォルトサーバーグループのポートも異なる場合があります。
例:
vServer グループ
vServer グループの作成
vServer グループは、次の方法で作成できます。
[リスナーの作成] ページ:
[インスタンス管理] ページ:
バックエンドサーバーの追加
リスナーを作成して新しいサーバーグループの作成を選択したとき、またはインスタンスの [サーバーグループ] ページでバックエンドサーバーを追加できます。
バックエンドサーバーが CLB インスタンスと同じリージョンにあることを確認してください。
バックエンドサーバーは複数の vServer グループに所属できます。
ECS インスタンスの追加
Elastic Computing Service (ECS) を選択します。
ポートと重みを構成します。
リスナーが重み付きラウンドロビン スケジューリングアルゴリズムを使用する場合、重みが大きいバックエンドサーバーほど多くのアクセスリクエストを受信します。詳細については、「Server Load Balancer スケジューリングアルゴリズム」をご参照ください。
重みを 0 に設定すると、サーバーは新しいリクエストを受信しません。
バックエンドサーバーごとに異なるポートを使用できます。同じバックエンドサーバーに複数の異なるポートを構成することもできます。
ENI の追加
ECS インスタンスにすでにアタッチされている ENI のみを追加できます。
ENI のプライマリプライベート IP アドレスとセカンダリプライベート IP アドレスを追加できます。
[アドバンストモード] を有効にします。次に、ENI がアタッチされている ECS インスタンスの右側にあるプラス記号アイコンをクリックして、ターゲットの ENI を見つけます。
ターゲット ENI の例:
アタッチする ENI を選択し、プライマリプライベート IP アドレスまたはセカンダリプライベート IP アドレスを選択します。複数の IP アドレスをアタッチできます。
ポートと重みを構成します。
リスナーが重み付きラウンドロビン スケジューリングアルゴリズムを使用する場合、重みが大きいバックエンドサーバーほど多くのアクセスリクエストを受信します。詳細については、「Server Load Balancer スケジューリングアルゴリズム」をご参照ください。
重みを 0 に設定すると、サーバーは新しいリクエストを受信しません。
バックエンドサーバーごとに異なるポートを使用できます。同じバックエンドサーバーに複数の異なるポートを構成することもできます。
ECI の追加
Elastic Container Instance (ECI) を選択します。
ポートと重みを構成します。
リスナーが重み付きラウンドロビン スケジューリングアルゴリズムを使用する場合、重みが大きいバックエンドサーバーほど多くのアクセスリクエストを受信します。詳細については、「Server Load Balancer スケジューリングアルゴリズム」をご参照ください。
重みを 0 に設定すると、サーバーは新しいリクエストを受信しません。
バックエンドサーバーごとに異なるポートを使用できます。同じバックエンドサーバーに複数の異なるポートを構成することもできます。
vServer グループの削除
vServer グループがリスナーまたは転送ルールに関連付けられている場合は、グループを削除する前に、まずリスナーまたは転送ルールとの関連付けを解除する必要があります。
プライマリ/セカンダリサーバーグループ
プライマリ/セカンダリサーバーグループの作成
プライマリ/セカンダリサーバーグループは、次の方法で作成できます。
[リスナーの作成] ページ:
[インスタンス管理] ページ:
バックエンドサーバーの追加
プライマリ/セカンダリサーバーグループを作成してサーバーを追加した後は、サーバー、ポート、またはプライマリ/セカンダリのロールを変更することはできません。変更するには、サーバーグループを再作成する必要があります。これらの設定は慎重に行ってください。
プライマリ/セカンダリサーバーグループでは、プライマリサーバーからセカンダリサーバーへのフェールオーバーはヘルスチェックによってトリガーされます。プライマリサーバーがヘルスチェックに失敗すると、トラフィックはセカンダリサーバーに切り替えられます。デフォルトでは、セカンダリサーバーではヘルスチェックは実行されません。フェールオーバー後にトラフィックを引き継げるように、セカンダリサーバーの可用性を確保する必要があります。
新しいプライマリ/セカンダリサーバーグループを作成するときに、バックエンドサーバーを追加できます。
プライマリ/セカンダリサーバーグループでは、1 つのサーバーをプライマリサーバーとして設定し、もう 1 つをセカンダリサーバーとして設定する必要があります。リスナーにプライマリ/セカンダリサーバーグループを選択すると、プライマリサーバーが正常な場合はトラフィックがプライマリサーバーに転送されます。プライマリサーバーがダウンした場合、トラフィックはセカンダリサーバーに切り替えられます。プライマリサーバーからセカンダリサーバーへの切り替えにかかる時間は、ヘルスチェックに設定した応答タイムアウト期間によって異なります。プライマリサーバーが再び正常になると、トラフィックは自動的にプライマリサーバーに切り替えられます。
バックエンドサーバーが CLB インスタンスと同じリージョンにあることを確認してください。
バックエンドサーバーは複数のプライマリ/セカンダリサーバーグループに所属できます。
ECS インスタンスの追加
Elastic Computing Service (ECS) を選択します。
ポートを構成します。
プライマリ/セカンダリサーバーグループには、正確に 2 つのバックエンドサーバーを追加する必要があります。
1 つのサーバーをプライマリサーバーとして選択します。
ENI の追加
ECS インスタンスにすでにアタッチされている ENI のみを追加できます。
ENI のプライマリプライベート IP アドレスとセカンダリプライベート IP アドレスを追加できます。
[アドバンストモード] を有効にし、ENI がアタッチされている ECS インスタンスの横にあるプラス記号 (+) をクリックして、ターゲットの ENI を見つけます。
ターゲット ENI の例:
アタッチする ENI を選択し、プライマリプライベート IP アドレスまたはセカンダリプライベート IP アドレスを選択します。複数の IP アドレスをアタッチできます。
ポートを構成します。
プライマリ/セカンダリサーバーグループには、正確に 2 つのバックエンドサーバーを追加する必要があります。
1 つのサーバーをプライマリサーバーとして選択します。
ECI の追加
Elastic Container Instance (ECI) を選択します。
ポートを構成します。
プライマリ/セカンダリサーバーグループには、正確に 2 つのバックエンドサーバーを追加する必要があります。
1 つのサーバーをプライマリサーバーとして選択します。
プライマリ/セカンダリサーバーグループの削除
プライマリ/セカンダリサーバーグループがリスナーに関連付けられている場合は、グループを削除する前に、まずリスナーとの関連付けを解除する必要があります。
よくある質問
CLB インスタンスの実行中に ECS インスタンスの数を調整できますか？
はい、できます。ただし、デフォルトサーバーグループまたは vServer グループを使用している場合に限ります。プライマリ/セカンダリサーバーグループ内のサーバーの数は調整できません。
デフォルトサーバーグループまたは vServer グループを使用している場合、いつでも負荷分散用のバックエンド ECS インスタンスの数を増減できます。また、異なる ECS インスタンス間で切り替えることもできます。サービスの安定性を確保するために、これらの操作を行う際には、負荷分散のヘルスチェック機能を有効にし、少なくとも 1 つのバックエンド ECS インスタンスが正常であることを確認してください。
バックエンド ECS インスタンスで異なるオペレーティングシステムを実行できますか？
はい、できます。
CLB は、アプリケーションサービスとデータがインスタンス間で一貫している限り、バックエンド ECS インスタンスが使用するオペレーティングシステムを制限しません。ただし、将来の管理とメンテナンスを簡素化するために、同じオペレーティングシステムを使用することをお勧めします。
異なるリージョンの ECS インスタンスをバックエンドサーバーとして使用できますか？
CLB は、ネイティブでは異なるリージョンのバックエンドサーバーのアタッチをサポートしていません。ただし、Global Traffic Manager (GTM) を CLB と これを実現できます。GTM を異なるリージョンの複数の CLB インスタンスの前にデプロイして、リージョン間の負荷分散を有効にすることができます。詳細については、「CLB と Global Traffic Manager を使用してリージョン間のサーバー負荷分散を実装する」をご参照ください。
Application Load Balancer (ALB) と Network Load Balancer (NLB) は、リージョン間のバックエンドサーバーのアタッチをサポートしています。詳細については、次の Topic をご参照ください。
100 で始まる IP アドレスが ECS インスタンスに頻繁にアクセスするのはなぜですか？
CLB システムは、外部リクエストをバックエンド ECS インスタンスに転送するだけでなく、ECS インスタンスのヘルスチェックと可用性モニタリングも実行します。これらのアクセスリクエストは CLB システムから発信されます。
CLB システムは 100.64.0.0/10 CIDR ブロックを使用します。これは Alibaba Cloud 内部サービス用に予約された CIDR ブロックです。他のユーザーはこの CIDR ブロックの IP アドレスを割り当てられないため、この方法はセキュリティリスクを防ぎます。したがって、100 で始まる IP アドレスから ECS インスタンスへのアクセスリクエストが表示されることがあります。
サービスの可用性を確保するために、これらの IP アドレスからのアクセスを許可するルールを構成していることを確認してください。
ECS インスタンスで圧縮が構成されていないのに、CLB からの HTTP 応答が圧縮されるのはなぜですか？
これは、クライアントブラウザが圧縮をサポートしているためである可能性があります。コンソールでリスナーを作成するときに Gzip 圧縮機能を無効にするか、代わりに TCP リスナーを使用できます。
HTTP 1.0 を使用する ECS インスタンスは、チャンク転送エンコーディングをサポートしていますか？
はい、サポートしています。
CLB インスタンスのバックエンド ECS インスタンスが、User-Agent 'KeepAliveClient' のリクエストを頻繁に受信するのはなぜですか？
症状: ユーザーアクセスがない場合でも、CLB インスタンスのバックエンド ECS インスタンスが頻繁に GET リクエストを受信します。ソース IP アドレスは Alibaba Cloud の内部 IP アドレスで、User-Agent は 'KeepAliveClient' です。
原因: リスナープロトコルは TCP に設定されていますが、ヘルスチェックプロトコルは HTTP に設定されています。TCP リスナーでヘルスチェックに HTTP プロトコルを使用すると、デフォルトでリクエストに GET メソッドが使用されます。
解決策: リスナープロトコルとヘルスチェックプロトコルが同じであることを確認してください。
デフォルトサーバーグループのサーバーポートを変更できますか？
シナリオ: 既存のリスナーの構成を変更する場合、デフォルトサーバーグループのサーバーポートは変更できません。デフォルトサーバーグループのサーバーポートは、リスナーを初めて作成するときの [バックエンドサーバー] ウィザードでのみ設定できます。同じリスナーの デフォルトサーバーグループ 内のすべてのサーバーは、同じポートを使用する必要があります。
解決策: 同じリスナーに異なるサーバーポートを構成するには、リスナーを構成するときに [バックエンドサーバー] ウィザードで [vServer グループ] を選択します。
CLB のレイヤー 4 リスナーは、バックエンドサーバーとクライアントの両方として機能する ECS インスタンスをサポートしていますか？
いいえ、サポートしていません。ただし、次のことができます。
CLB のレイヤー 7 リスナーを使用する。
NLB インスタンスを使用し、NLB サーバーグループの [クライアント IP の保持] 機能を無効にする。詳細については、「NLB で ECS インスタンスをバックエンドサーバーとクライアントの両方として機能させるにはどうすればよいですか？」をご参照ください。
CLB のバックエンドには TIME-WAIT 接続が多いのに、ALB のバックエンドには少ないのはなぜですか？
Classic Load Balancer (CLB) と Application Load Balancer (ALB) は、バックエンドサーバーと対話する際に異なる接続メカニズムを使用します。
Classic Load Balancer (CLB): デフォルトで短命の HTTP 接続を使用します。CLB がリクエストをバックエンドサーバーに転送する際、HTTP ヘッダーに
Connection: closeフィールドを挿入します。バックエンドサーバーはリクエストを処理した後、このヘッダーに基づいて能動的に FIN パケットを送信して接続を閉じます。接続が閉じられるたびに、TIME-WAIT 状態 (デフォルトで 60 秒) に入ります。高同時実行シナリオでは、多くの TIME-WAIT 接続が急速に蓄積される可能性があります。Application Load Balancer (ALB): デフォルトで HTTP 持続的接続 (keep-alive) をサポートします。単一の TCP 接続を再利用して複数のリクエストを処理できます。持続的接続を有効にすると、切断回数が減少し、その結果 TIME-WAIT 接続の数が減少します。