リスナーは、設定された転送ルールに基づいて、指定されたサーバーグループにサービスリクエストをルーティングします。サーバーグループは、スケジューリングアルゴリズムを使用して、バックエンドサーバーにサービストラフィックを分散します。
仕組み
サーバーグループのタイプ
サーバーグループのタイプ | デフォルトサーバーグループ | vServer グループ | プライマリ/セカンダリサーバーグループ |
タイプの説明 | 各 Classic Load Balancer (CLB) インスタンスに 1 つのデフォルトサーバーグループが含まれます (厳密に 1 つ) | ユーザーが作成および管理 | ユーザーが作成および管理 |
バックエンドサーバーの数 | 1 つ以上 | 1 つ以上 | 2 つ (プライマリ 1 つ、セカンダリ 1 つ) |
特徴 |
|
|
|
利用シーン | すべてのリクエストが同じバックエンドサーバーグループに転送されるシンプルなアーキテクチャ | ドメイン名やポートによってサービスリクエストを分散するなど、複雑なアーキテクチャ | データベースやコア API など、固定のアクティブ/パッシブモードを必要とするサービス |
サポートされるリスナータイプ | TCP/UDP/HTTP/HTTPS | TCP/UDP/HTTP/HTTPS | TCP/UDP のみ |
重みの設定
スケジューリングアルゴリズムは、CLB が受信リクエストを複数のバックエンドサーバーにどのように分散するかを決定します。重みは、各サーバーに割り当てられるトラフィックの割合を制御するために、加重アルゴリズムで使用されるパラメーターです。
適用範囲：加重スケジューリングアルゴリズムを使用する場合にのみ適用されます。ラウンドロビンアルゴリズムでは効果がありません。
範囲：0～100、デフォルト値は 100 です。
重みが 0 の場合の動作：サーバーは新しいリクエストトラフィックの受信を停止します。既存の接続は正常に閉じるまで継続され、ヘルスチェックは引き続き実行されます。これは一般的にグレースフルシャットダウンに使用されます。
重み変更の影響：重みの調整は新しい接続にのみ適用され、既存の接続には影響しません。持続的接続のシナリオでは、重み変更後のトラフィックの再分散はゆっくりと行われます。
トラフィック分散比率：加重ラウンドロビン (WRR) アルゴリズムでは、各バックエンドサーバーはその重みに比例したトラフィックを受信します。たとえば、2 つのサーバーの重みがそれぞれ 100 と 1 (合計重み：101) の場合、重み 1 のサーバーは全リクエストの約 1/101 (1% 未満) を受信します。
説明サーバーグループにすでに重みの高いバックエンドサーバー (例：重み 100) が存在する場合、新しく追加された重みの低いサーバー (例：重み 1) は、長期間にわたって目に見えるトラフィックを受信しないことがあります。これは WRR の想定される動作です。トラフィックが少ない状況では、重みの低いサーバーに割り当てられた少数のリクエストが長期間観測されないことがあります。
推奨事項：新しいバックエンドサーバーを追加する際は、初期の重みを少なくとも 10 に設定することを推奨します。サーバーが正常にトラフィックを受信することを確認した後、ビジネスニーズに応じて重みを調整してください。
サービスの可用性
CLB のヘルスチェックを有効にして、定期的にリクエストを送信し、サーバーのステータスを確認します。
ヘルスチェック成功：サーバーは正常であり、CLB はトラフィックをそのサーバーに転送します。
ヘルスチェック失敗：サーバーは異常であり、CLB は回復するまで新しいリクエストトラフィックの送信を停止します。
CLB のヘルスチェックは、100.64.0.0/10 CIDR ブロックから発信されます。バックエンドサーバーの iptables やその他のサードパーティのセキュリティソフトウェアがこの CIDR ブロックをブロックしないようにしてください。ブロックすると、ヘルスチェックが失敗し、サービスの中断を引き起こす可能性があります。プライマリ/セカンダリサーバーグループは、自動フェイルオーバーのためにヘルスチェックに依存しています：
プライマリサーバーがヘルスチェックに失敗した場合、トラフィックはセカンダリサーバーに切り替わります。デフォルトでは、セカンダリサーバーはヘルスチェックを受けないため、シームレスなフェイルオーバーを保証するために手動でその可用性を確認する必要があります。
フェイルオーバー時間は、設定されたヘルスチェックの応答タイムアウト期間に依存します。プライマリサーバーが回復すると、トラフィックは自動的にプライマリサーバーに戻ります。
適用範囲
関連付け関係：
リスナーとサーバーグループは、CLB インスタンスにスコープされたリソースです。リスナーとサーバーグループに関する情報は、異なる CLB インスタンス間で共有されません。
1 つのサーバーグループは複数のリスナーにバインドできますが、1 つのリスナーは一度に 1 つのサーバーグループにしかバインドできません。
CLB のレイヤー 4 リスナーでは、同じ Elastic Compute Service (ECS) インスタンスをバックエンドサーバーとクライアントの両方として使用することはできません。必要な場合は、代わりにレイヤー 7 リスナーを使用してください。
バックエンドサーバーのアタッチ：
CLB は、同じアカウントおよびリージョンのバックエンドサーバーのみのアタッチをサポートします。
プライベートネットワーク CLB インスタンス：CLB インスタンスの VPC 内のバックエンドサーバーのみをアタッチできます。
パブリックネットワーク CLB インスタンス：アタッチされるすべてのバックエンドサーバーは、同じ VPC に属している必要があります。
すべての CLB サーバーグループタイプは、Elastic Compute Service (ECS)、Elastic Network Interface (ENI)、および Elastic Container Instance (ECI) のアタッチをサポートします。
すでに ECS インスタンスにアタッチされている ENI のみを追加できます。ENI のプライマリプライベート IP アドレスと補助プライベート IP アドレスの両方がサポートされます。
バックエンドサーバーとして使用される ECS インスタンスがホットマイグレーションされると、CLB の持続的接続が切断されることがあります。再接続後にサービスは再開します。アプリケーションに自動再接続メカニズムが実装されていることを確認してください。
設定の変更可能性：
設定の変更可能性
サーバーグループの追加/削除
ポートの変更
重みの変更
デフォルトサーバーグループ
リスナーを作成して関連付けた後、ポートは変更できません
vServer グループ
プライマリ/セカンダリサーバーグループ
プライマリ/セカンダリの役割の変更はサポートされていません
サーバーグループの設定
コンソール
デフォルトサーバーグループ
作成は不要です。各 CLB インスタンスには 1 つのデフォルトサーバーグループが含まれています。
サーバーの追加：
[CLB] – [インスタンス] ページに移動し、ターゲットインスタンスの ID をクリックし、デフォルトのサーバーグループ タブを選択して、追加 をクリックします。
サーバータイプ と リソースグループ を設定して、利用可能なリソースを絞り込みます。
ENI を追加するには、まず詳細モードを有効にし、アタッチされた ENI を持つ ECS インスタンスの横にあるプラスアイコンをクリックしてターゲット ENI を見つけます。ENI を選択し、IP を選択します。
ポートと重みの設定：
ポートの設定：リスナー タブに移動し、リスナーの作成 をクリックします。バックエンド サーバー ウィザードページで、デフォルトサーバーグループ内のサーバーの ポート を設定します。同じリスナー配下のデフォルトサーバーグループ内のすべてのサーバーは、同じポートを使用する必要があります。
ポートはリスナー追加時にのみ指定でき、後で変更することはできません。
重みの設定：選択したサーバーの 重み を設定します。
vServer グループ
[CLB] – [インスタンス] ページに移動し、ターゲットインスタンスの ID をクリックし、仮想サーバーグループ を選択して、VServer Group の作成 をクリックします。
追加 サーバー：
サーバータイプ と リソースグループ を設定して、利用可能なリソースをフィルタリングします。
ENI を追加するには、まず詳細モードを有効にし、アタッチされた ENI を持つ ECS インスタンスの横にあるプラスアイコンをクリックしてターゲット ENI を見つけます。ENI を選択し、IP を選択します。
選択したサーバーのポートと重みを設定します。ポートの追加をクリックして、同じバックエンドサーバーに複数の異なるポートを割り当てます。
プライマリ/セカンダリサーバーグループ
[CLB] – [インスタンス] ページに移動し、ターゲットインスタンスの ID をクリックし、マスタースレーブサーバグループ を選択して、マスタースレーブサーバーグループを作成する をクリックします。
追加 サーバー：
サーバータイプ と リソースグループ を設定して、利用可能なリソースをフィルタリングします。
ENI を追加するには、まず詳細モードを有効にし、アタッチされた ENI を持つ ECS インスタンスの横にあるプラスアイコンをクリックしてターゲット ENI を見つけます。ENI を選択し、IP を選択します。
追加できるバックエンドサーバーは 2 つだけです。
選択したサーバーの ポート を設定します。ポートの追加 をクリックして、同じバックエンドサーバーに複数の異なるポートを割り当てます。追加後、サーバー を選択して、プライマリ/セカンダリの関係を定義します。
API
デフォルトサーバーグループ
AddBackendServers を呼び出してバックエンドサーバーを追加します。
SetBackendServers を呼び出してバックエンドサーバーの重みを設定します。
RemoveBackendServers を呼び出してバックエンドサーバーを削除します。
vServer グループ
CreateVServerGroup を呼び出して vServer グループを作成し、ポートと重みの設定を持つバックエンドサーバーを追加します。
AddVServerGroupBackendServers / RemoveVServerGroupBackendServers を呼び出して、指定した vServer グループからバックエンドサーバーを追加または削除します。
DeleteVServerGroup を呼び出して vServer グループを削除します。
プライマリ/セカンダリサーバーグループ
CreateMasterSlaveServerGroup を呼び出してプライマリ/セカンダリサーバーグループを作成します。
DeleteMasterSlaveServerGroup を呼び出してプライマリ/セカンダリサーバーグループを削除します。
よくある質問
CLB インスタンスの実行中に ECS インスタンスの数を調整できますか？
デフォルトサーバーグループと vServer グループ：いつでもバックエンドの ECS インスタンスを追加または削除し、異なる ECS インスタンス間で切り替えることができます。サービスの安定性を確保するため、これらの操作を実行する前にヘルスチェックを有効にし、バックエンドに少なくとも 1 つの正常な ECS インスタンスが残っていることを確認してください。
プライマリ/セカンダリサーバーグループ：サポートされていません。
バックエンドの ECS インスタンスは異なるオペレーティングシステムを使用できますか？
異なる場合があります。
CLB は、アプリケーションサービスとデータが一致している限り、バックエンドの ECS インスタンスのオペレーティングシステムを制限しません。管理とメンテナンスを容易にするために、同じオペレーティングシステムを使用することを推奨します。
異なるリージョンの ECS インスタンスをバックエンドサーバーとして使用できますか？
CLB は、クロスリージョンのバックエンドサーバーを直接アタッチすることをサポートしていません。クロスリージョンデプロイメントを実装するには、次のいずれかのソリューションを使用します：
CLB の上に Global Traffic Manager (GTM) をデプロイし、リージョンをまたいで複数の CLB インスタンスをデプロイします。CLB インスタンスを切り替えることで、クロスリージョンアタッチを実現します。
Application Load Balancer (ALB) または Network Load Balancer (NLB) を使用します。これらはクロスリージョンのバックエンドアタッチをサポートしています。
ECS インスタンスに 100 で始まる IP からの頻繁なリクエストがあるのはなぜですか？
これらのリクエストは、ロードバランサーのヘルスチェックと可用性モニタリングからのものです。
ソース：Alibaba Cloud の予約済み CIDR ブロック
100.64.0.0/10。セキュリティ：この CIDR ブロックは Alibaba Cloud によって予約されており、他のユーザーに割り当てられることはないため、セキュリティリスクはありません。
推奨事項：サービスの可用性を維持するために、バックエンドサーバーの iptables やその他のサードパーティのセキュリティソフトウェアがこの CIDR ブロックをブロックしないようにしてください。
ヘルスチェックが失敗した場合、「ヘルスチェックの失敗をトラブルシューティングする方法」をご参照ください。
ECS インスタンスで圧縮が有効になっていないのに、CLB からの HTTP 応答が圧縮されているのはなぜですか？
理由：CLB リスナーの設定で Gzip 圧縮が有効になっており、クライアントブラウザが圧縮をサポートしているためです。
対処法：無効にするには、CLB コンソールのリスナー設定で Gzip 圧縮をオフにするか、TCP リスナーに切り替えます。
HTTP/1.0 を使用する ECS インスタンスはチャンク転送エンコーディングをサポートしていますか？
はい。
CLB バックエンドの ECS インスタンスが User-Agent KeepAliveClient のリクエストを頻繁に受信するのはなぜですか？
観測：バックエンドの ECS は、内部 IP アドレスから User-Agent が
KeepAliveClientの GET リクエストを多数受信します。理由：リスナープロトコルは TCP ですが、ヘルスチェックプロトコルが HTTP に設定されています。TCP リスナーが HTTP ヘルスチェックを使用する場合、デフォルトで GET メソッドが使用されます。
解決策：リスナープロトコルとヘルスチェックプロトコルを一致させます (例：両方とも TCP を使用するか、両方とも HTTP を使用する)。
デフォルトサーバーグループのサーバーポートを変更できますか？
直接の変更はサポートされていません。
制限：デフォルトサーバーグループのポートはリスナー作成時にのみ設定でき、同じリスナー配下のすべてのバックエンドサーバーは同じポートを使用する必要があります。
解決策：同じリスナーに対して異なるバックエンドポートを設定するには、vServer グループを使用します。
CLB のレイヤー 4 リスナーは、同じ ECS インスタンスをバックエンドサーバーとクライアントの両方として使用することをサポートしていますか？
いいえ。この構成はループを引き起こします。
代替案：
CLB のレイヤー 7 リスナー (HTTP/HTTPS) を使用します。
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 秒) に入り、高同時実行性下で急速に蓄積されます。Application Load Balancer (ALB)：デフォルトで HTTP 持続的接続 (keep-alive) をサポートします。単一の TCP 接続で複数のリクエストを処理するため、接続の切断が減り、TIME-WAIT 接続も減少します。
TIME-WAIT の蓄積を減らすには、以下のオプションを検討してください：
CLB のレイヤー 4 (TCP) リスナーに切り替えます。レイヤー 4 のヘルスチェックは、ハンドシェイク成功後に RST パケットを送信して接続を閉じるため、TIME-WAIT 状態にはなりません。
ALB に移行して、デフォルトの HTTP 持続的接続の再利用メカニズムを活用します。
バックエンドサーバー間でトラフィックが不均等に分散されるのはなぜですか？
一般的な原因 | 説明 | トラブルシューティングと解決策 |
セッション維持 | セッション維持が有効な場合、同じクライアントからのリクエストは常に同じバックエンドサーバーに送られます。クライアントが少ない場合 (例：限られたクライアントでのストレステスト中)、トラフィックは特定のサーバーに集中します。 | セッション維持が有効になっているか確認し、サービスで本当に必要かどうかを評価します。 |
持続的接続 | 確立された持続的接続は、重みが変更されても再分散されません。持続的接続のシナリオでは、重み調整後のトラフィックの移行はゆっくりと行われます。 |
|
ヘルスチェックの失敗または変動 | 一部のバックエンドサーバーがヘルスチェックに失敗してリクエストを受け入れられない、またはヘルスステータスが正常と異常の間で変動し、トラフィック分散が不安定になります。 |
|
総リクエスト量が少ない | CLB の監視メトリクスを確認します。総リクエスト量が少ない場合、わずかな不均衡は正常です。 | リクエスト量を増やした後のトラフィック分散を観察します。高負荷下でも不均衡が続く場合は、他の原因を調査します。 |
不適切な重み設定 | サーバーの重みが実際の処理能力と一致しておらず、一部のサーバーが過負荷になり、他のサーバーがアイドル状態になります。 |
|
コンシステントハッシュ (CH) スケジューリングアルゴリズム | リスナーがソース IP ベースのコンシステントハッシュ (CH) スケジューリングアルゴリズムを使用する場合、同じソース IP からのリクエストは常に同じバックエンドサーバーに転送されます。クライアント数が少ないか、ソース IP が集中している場合、一部のバックエンドサーバーはトラフィックを受信しないことがあります。CH は、クライアント IP が均等に分散されたセッションアフィニティが必要なシナリオに適しています。ソース IP が集中している場合は、別のスケジューリングアルゴリズムへの切り替えを検討してください。 | CLB コンソールにログインし、インスタンス詳細ページに移動し、リスナー タブをクリックし、ターゲットリスナーをクリックして詳細を表示し、[スケジューリングアルゴリズム] が [コンシステントハッシュ (CH)] に設定されているか確認します。その場合は、[加重ラウンドロビン (WRR)] または [ラウンドロビン (RR)] に切り替えてトラフィック分散を改善することを検討してください。 |
バックエンドの ECS インスタンスを CLB から安全に削除する方法は？
ECS インスタンスを直接削除すると、一時的な接続切断が発生する可能性があります。まず、ECS インスタンスの重みを 0 に設定します。既存の接続が完了するのを待ってから、インスタンスを削除します。重みを 0 に設定した場合の動作の詳細については、上記の「重みの設定」セクションをご参照ください。
ECS インスタンスを削除した後もビジネスリクエストが続く場合は、以下を確認してください：
ECS インスタンスが他の CLB インスタンスにもアタッチされているかどうか。
ECS インスタンスが他のサービスを直接提供しているかどうか。
netstatコマンドを使用してポートのリスニング状態を確認します。
新しく追加したバックエンドサーバーにトラフィックが転送されないのはなぜですか？
CLB が新しく追加したバックエンドサーバーにトラフィックを転送しない場合は、以下を確認してください：
ヘルスチェックの失敗：バックエンドサーバーのポートに到達できない、またはアプリケーションが期待されるポートでリッスンしていないため、ヘルスチェックが失敗します。CLB コンソールでサーバーのヘルスチェックステータスを確認し、バックエンドサーバーでポートのリスニングとアプリケーションの状態を確認します。ヘルスチェックが失敗した場合、「ヘルスチェックの失敗をトラブルシューティングする方法」をご参照ください。
重みが 0 に設定されている：重みが 0 のサーバーは新しいリクエストトラフィックを受信しません。サーバーグループ内のサーバーの重みを確認し、0 より大きいことを確認します。詳細については、上記の「重みの設定」セクションをご参照ください。
間違ったサーバーグループに追加されている：各 CLB リスナーは特定のサーバーグループ (デフォルトまたは vServer グループ) にバインドされています。新しいサーバーがターゲットリスナーにバインドされていないグループに追加された場合、そのリスナーのトラフィックは受信しません。リスナーに実際にバインドされているサーバーグループを確認し、正しいグループにサーバーを追加します。
iptables またはサードパーティのセキュリティソフトウェアがヘルスチェックの CIDR ブロックをブロックしている：CLB のヘルスチェックは
100.64.0.0/10CIDR ブロックを使用します。バックエンドサーバー上の iptables やその他のサードパーティのセキュリティソフトウェアがこの CIDR ブロックをブロックすると、ヘルスチェックが失敗し、CLB はサーバーを異常と見なします。関連するルールがこの CIDR ブロックをブロックしていないことを確認してください。ヘルスチェックウィンドウに達していない：バックエンドサーバーを追加した後、CLB はトラフィックを転送する前にヘルスチェックが成功するのを待ちます。しばらく待ってから、トラフィックが正常に流れるか確認してください。
コンシステントハッシュ (CH) スケジューリングアルゴリズムがトラフィック割り当てを妨げている：リスナーがソース IP ベースのコンシステントハッシュ (CH) スケジューリングアルゴリズムを使用する場合、リクエストはソース IP のハッシュ結果に基づいて特定のサーバーに割り当てられます。新しいサーバーを追加した後、ソース IP のハッシュが新しいサーバーにマッピングされるリクエストのみがそのサーバーに転送されます。クライアント数が少ないか、ソース IP が集中している場合、新しいサーバーは長期間トラフィックを受信しないことがあります。CLB コンソールで、インスタンス詳細ページに移動し、リスナー タブをクリックし、対応するリスナーのスケジューリングアルゴリズムを確認します。それが [コンシステントハッシュ (CH)] に設定されている場合は、[加重ラウンドロビン (WRR)] または [ラウンドロビン (RR)] に切り替えることを検討してください。
レイヤー 7 リスナーの場合、CLB はどのプロトコルを使用してバックエンドサーバーにリクエストを転送しますか？
レイヤー 7 リスナーが HTTP または HTTPS を使用するかにかかわらず、CLB は常に HTTP プロトコルを使用してバックエンドサーバーにリクエストを転送します。HTTP バージョンのマッピングは次のとおりです：
クライアントリクエストが HTTP/1.1 または HTTP/2.0 を使用する場合、レイヤー 7 リスナーは HTTP/1.1 を使用してバックエンドサーバーにアクセスします。
クライアントリクエストが HTTP/1.1 または HTTP/2.0 以外のバージョンを使用する場合、レイヤー 7 リスナーは HTTP/1.0 を使用してバックエンドサーバーにアクセスします。