すべてのプロダクト
Search

このプロダクト

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

    ドキュメントセンター

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

    最終更新日:May 06, 2026

    リスナーは、転送ルールに基づいてリクエストを指定されたサーバーグループにルーティングします。その後、サーバーグループはスケジューリングアルゴリズムを使用して、バックエンドサーバー間でトラフィックを分散します。

    仕組み

    サーバーグループの種類

    サーバーグループの種類

    デフォルトサーバーグループ

    vServer グループ

    プライマリ/セカンダリサーバーグループ

    説明

    各クラシックロードバランサー (CLB) インスタンスには、デフォルトサーバーグループが 1 つ含まれます。

    これらのグループを作成および管理できます。

    これらのグループを作成および管理できます。

    バックエンドサーバー数

    1 台以上

    1 つ以上

    2 台 (プライマリ 1 台とセカンダリ 1 台)

    機能

    • インスタンスレベルでの共有：同一 CLB インスタンス内のすべてのリスナーがこのグループを共有します。

    • ポート制限：同一リスナーのすべてのバックエンドサーバーは同じポートを使用する必要があります。

    • 柔軟性：異なるリスナーを異なるサーバーグループにバインドできます。

    • マルチポート対応：同一 vServer グループに異なるポートを持つバックエンドサーバーを追加できます。

    • 高度なルーティング：ドメイン名や URL パスに基づく詳細なトラフィック分散が可能です。

    • 柔軟性：異なるリスナーを異なるサーバーグループにバインドできます。

    • 高可用性：プライマリサーバーとセカンダリサーバー間で自動フェイルオーバーを提供します。

    • マルチポート対応：同一プライマリ/セカンダリサーバーグループに異なるポートを持つバックエンドサーバーを追加できます。

    ユースケース

    すべてのリクエストを単一のバックエンドサーバーグループに転送するシンプルなアーキテクチャ。

    ドメイン名やポートに基づいてリクエストを分散するような複雑なアーキテクチャ。

    データベースやコア API など、固定のプライマリ/セカンダリアーキテクチャを必要とするサービス。

    サポートされるリスナータイプ

    TCP、UDP、HTTP、HTTPS

    TCP、UDP、HTTP、HTTPS

    TCP および UDP のみ

    重みの設定

    スケジューリングアルゴリズムは、CLB インスタンスが受信リクエストをバックエンドサーバーに分散する方法を決定します。重み付けをサポートするスケジューリングアルゴリズムでは、重みパラメーターにより各サーバーが受信するトラフィックの割合を制御します。

    • 適用範囲：重みの設定は、重み付けをサポートするスケジューリングアルゴリズムにのみ適用されます。ラウンドロビンアルゴリズムには適用されません。

    • 値の範囲：0 ～ 100。デフォルト値は 100 です。

    • 重みが 0 の場合の動作：サーバーは新しいリクエストの受信を停止します。ただし、確立済みの接続はクローズされるまで処理を継続し、ヘルスチェックも継続されます。これは通常、サーバーをサービスから安全に削除するために使用されます。

    • 重み変更の影響範囲：重みの変更は新しい接続にのみ影響し、既存の接続には影響しません。接続保持が有効なシナリオでは、重みを変更した後もトラフィック分散の調整は徐々に進行します。

    サービスの高可用性

    CLB はヘルスチェックを使用して定期的にリクエストを送信し、バックエンドサーバーのステータスを確認します。

    • ヘルスチェック成功：サーバーは正常であり、CLB インスタンスはトラフィックをそのサーバーに転送します。

    • ヘルスチェック失敗：サーバーは異常です。CLB インスタンスは、サーバーが回復するまで新しいリクエストの転送を停止します。

    CLB のヘルスチェックは 100.64.0.0/10 CIDR ブロックを使用します。バックエンドサーバーのセキュリティグループに、この CIDR ブロックからのアクセスを許可するルールを追加する必要があります。これを設定しないと、ヘルスチェックが失敗し、サービス中断が発生する可能性があります。

    プライマリ/セカンダリサーバーグループは、フェイルオーバーのためにヘルスチェックに依存します。

    • プライマリサーバーのヘルスチェックが失敗すると、CLB は自動的にトラフィックをセカンダリサーバーにルーティングします。デフォルトでは、CLB はセカンダリサーバーに対してヘルスチェックを実行しません。フェイルオーバー後にセカンダリサーバーがトラフィックを処理できる状態であることを保証する必要があります。

    • フェイルオーバー時間は、設定されたヘルスチェックの応答タイムアウトに依存します。プライマリサーバーが正常になると、CLB は自動的にトラフィックをプライマリサーバーに戻します。

    注意事項

    • 関連付け：

      • リスナーとサーバーグループは、特定の CLB インスタンスにスコープされたリソースです。これらの構成は、異なる CLB インスタンス間で共有されません。

      • サーバーグループは複数のリスナーにバインドできますが、リスナーは 1 つのサーバーグループにのみバインドできます。

      • レイヤー 4 リスナーでは、ECS インスタンスをバックエンドサーバーとクライアントの両方として使用することはできません。このような構成が必要な場合は、レイヤー 7 リスナーを使用してください。

    • バックエンドサーバーの追加：

      • CLB インスタンスと同じリージョンにあり、同じ Alibaba Cloud アカウントに属するバックエンドサーバーのみを追加できます。

        • 非公開 CLB インスタンス：CLB インスタンスと同じ VPC に属するバックエンドサーバーのみを追加できます。

        • パブリック CLB インスタンス：追加するすべてのバックエンドサーバーは同じ VPC に属している必要があります。

      • すべての CLB サーバーグループタイプは、バックエンドサーバーとして ECS、ENI、ECI インスタンスをサポートしています。

        • ENI を追加できるのは、すでに ECS インスタンスにバインドされている場合のみです。ENI のプライマリおよびセカンダリプライベート IP アドレスの両方を追加できます。

      • バックエンドサーバーとして機能する ECS インスタンスがホットマイグレーションを実行すると、CLB インスタンスへの接続保持中の接続が切断される可能性があります。再接続後にサービスが復旧します。アプリケーションに自動再接続メカニズムがあることを確認してください。

    • 構成の変更可能性：

      変更可能性

      サーバーグループの追加/削除

      ポートの変更

      重みの変更

      デフォルトサーバーグループ

      サポートされていません

      リスナーを作成してグループに関連付けた後は、ポートを変更できません。

      サポートされています

      vServer グループ

      サポートされています

      サポートされています

      サポートされています

      プライマリ/セカンダリサーバーグループ

      サポートされています

      サポートされていません

      プライマリとセカンダリのロールは変更できません。

    サーバーグループの設定

    コンソール

    デフォルトサーバーグループ

    1. デフォルトサーバーグループを作成する必要はありません。各 CLB インスタンスには、デフォルトで 1 つ含まれています。

    2. サーバーの追加：

      1. CLB インスタンスページに移動し、対象インスタンスの ID をクリックして、デフォルトのサーバーグループタブを選択し、追加をクリックします。

        • サーバータイプおよびリソースグループを設定して、利用可能なリソースを絞り込みます。

        • ENI を追加するには、まず詳細モードを有効化します。ENI がバインドされている ECS インスタンスの横にあるプラスアイコン (+) をクリックして、対象の ENI を見つけます。追加する ENI のチェックボックスをオンにし、IPを選択します。

      2. ポートと重みの設定：

        • ポートの設定：リスナータブを選択し、リスナーの作成をクリックします。ウィザードのバックエンド サーバーステップで、デフォルトサーバーグループ内のサーバーのポートを設定します。同一リスナーのデフォルトサーバーグループ内のすべてのサーバーは、同じポートを使用する必要があります。

          ポートはリスナーを追加する際にのみ指定できます。後から変更することはできません。

        • 重みの設定：選択したサーバーの重みを設定します。

    vServer グループ

    1. CLB インスタンスページに移動し、対象インスタンスの ID をクリックして、仮想サーバーグループを選択し、VServer Group の作成をクリックします。

    2. 追加サーバー：

      • サーバータイプおよびリソースグループを設定して、利用可能なリソースを絞り込みます。

      • ENI を追加するには、まず詳細モードを有効化します。ENI がバインドされている ECS インスタンスの横にあるプラスアイコン (+) をクリックして、対象の ENI を見つけます。追加する ENI のチェックボックスをオンにし、IPを選択します。

    3. 選択したサーバーのポートおよび重みを設定します。ポートの追加をクリックして、同一バックエンドサーバーに複数のポートを設定できます。

    プライマリ/セカンダリサーバーグループ

    1. CLB インスタンスページに移動し、対象インスタンスの ID をクリックして、マスタースレーブサーバグループを選択し、マスタースレーブサーバーグループを作成するをクリックします。

    2. 追加サーバー：

      • サーバータイプおよびリソースグループを設定して、利用可能なリソースを絞り込みます。

      • ENI を追加するには、まず詳細モードを有効化します。ENI がバインドされている ECS インスタンスの横にあるプラスアイコン (+) をクリックして、対象の ENI を見つけます。追加する ENI のチェックボックスをオンにし、IPを選択します。

      • バックエンドサーバーは 2 台のみ追加できます。

    3. 選択したサーバーのポートを設定します。ポートの追加をクリックして、同一バックエンドサーバーに複数のポートを設定できます。サーバーを追加した後、1 台をサーバーとして選択し、プライマリ/セカンダリの関係を設定します。

    API

    デフォルトサーバーグループ

    • AddBackendServers を呼び出して、バックエンドサーバーを追加します。

    • SetBackendServers を呼び出して、バックエンドサーバーの重みを設定します。

    • RemoveBackendServers を呼び出して、バックエンドサーバーを削除します。

    vServer グループ

    プライマリ/セカンダリサーバーグループ

    よくある質問

    実行中の CLB のバックエンド ECS インスタンスを調整できますか？

    • デフォルトサーバーグループおよび vServer グループ：はい。バックエンド ECS インスタンスをいつでも追加または削除でき、異なる ECS インスタンス間で切り替えることができます。サービスの安定性を確保するため、これらの操作を実行する前にヘルスチェックを有効化し、少なくとも 1 台のバックエンド ECS インスタンスが正常であることを確認してください。

    • プライマリ/セカンダリサーバーグループ：いいえ。インスタンス数を調整することはできません。

    バックエンド ECS インスタンスで異なるオペレーティングシステムを実行できますか？

    はい、実行できます。

    CLB はバックエンド ECS インスタンスのオペレーティングシステムを制限しませんが、すべてのインスタンスでアプリケーションサービスを一貫してデプロイし、データを同期する必要があります。ただし、管理とメンテナンスを簡素化するために、すべてのバックエンドインスタンスで同じオペレーティングシステムを使用することを推奨します。

    異なるリージョンのバックエンドサーバーを使用できますか？

    CLB は、異なるリージョンのバックエンドサーバーを直接追加することをサポートしていません。クロスリージョンデプロイメントを実装するには、以下のいずれかのソリューションをご検討ください。

    • Global Traffic Manager (GTM) を使用します。異なるリージョンに複数の CLB インスタンスをデプロイし、GTM をそれらの前方に配置することで、CLB インスタンス間の切り替えによりクロスリージョンの負荷分散を実現します。

    • Application Load Balancer (ALB) または Network Load Balancer (NLB) を使用します。どちらも異なるリージョンのバックエンドサーバーを追加できます。

    100 で始まる IP からの頻繁なアクセス

    これらのリクエストは、ロードバランサーのヘルスチェックおよび可用性モニタリングシステムから発生しています。

    • ソース：リクエストは Alibaba Cloud が予約済みの CIDR ブロック 100.64.0.0/10 から送信されています。

    • セキュリティ：Alibaba Cloud はこの CIDR ブロックを内部用途専用に予約しており、ユーザーに割り当てることはありません。したがって、これらのリクエストによるセキュリティリスクはありません。

    • 推奨事項：ヘルスチェックが正しく機能するように、セキュリティグループにこの CIDR ブロックからのトラフィックを許可するルールを追加してください。

    ヘルスチェックが失敗した場合は、「ヘルスチェックの例外をトラブルシューティングする方法」をご参照ください。

    HTTP 応答が圧縮されるのはなぜですか？

    • 原因：CLB リスナー構成で Gzip 圧縮が有効になっており、クライアントの Web ブラウザーが圧縮をサポートしているためです。

    • 解決策：この機能を無効にするには、CLB コンソールのリスナー設定で Gzip 圧縮をオフにするか、TCP リスナーに切り替えてください。

    HTTP 1.0 はチャンク転送エンコーディングをサポートしていますか？

    はい。

    User-Agent が 'KeepAliveClient' の頻繁なリクエスト

    • 症状：バックエンド ECS インスタンスが、内部 IP アドレスから User-Agent が KeepAliveClient に設定された多数の GET リクエストを受信しています。

    • 原因：リスナーを TCP 用に構成しましたが、ヘルスチェックを HTTP 用に設定しています。TCP リスナーが HTTP を使用してヘルスチェックを行う場合、デフォルトで GET リクエストを送信します。

    • 解決策：リスナーとそのヘルスチェックで同じプロトコルを使用するようにしてください。たとえば、両方を TCP に設定するか、両方を HTTP に設定します。

    デフォルトサーバーグループ：ポートを変更できますか？

    いいえ、ポートを直接変更することはできません。

    • 制限事項：デフォルトサーバーグループのポートは、そのリスナーを作成する際にのみ設定できます。そのリスナーに関連付けられたすべてのバックエンドサーバーは、同じポートを使用する必要があります。

    • 解決策：同一リスナーに対して異なるバックエンドポートを構成する必要がある場合は、vServer グループを使用してください。

    レイヤー 4 リスナー：ECS をクライアントとサーバーの両方として使用できますか？

    いいえ。この構成ではルーティングループが発生します。

    回避策：

    CLB と ALB：TIME-WAIT 接続

    クラシックロードバランサー (CLB) と Application Load Balancer (ALB) は、バックエンドサーバーとのやり取りにおいて異なる接続メカニズムを使用します。

    • クラシックロードバランサー (CLB)：デフォルトで短命の HTTP 接続を使用します。CLB インスタンスがリクエストをバックエンドサーバーに転送する際、Connection: close ヘッダーを挿入します。バックエンドサーバーがリクエストを処理した後、接続の終了を開始します。各終了により、接続は TIME-WAIT 状態になります (通常は 60 秒間)。同時実行数が高いシナリオでは、これにより TIME-WAIT 接続が急速に蓄積される可能性があります。

    • Application Load Balancer (ALB)：デフォルトで持続的な HTTP 接続 (キープアライブ) をサポートし、単一の TCP 接続を複数のリクエストで再利用します。

    TIME-WAIT 接続の蓄積を軽減するには、以下のいずれかのソリューションをご検討ください。

    • CLB レイヤー 4 (TCP) リスナーに切り替えます。ハンドシェイクが成功した後、レイヤー 4 のヘルスチェックは RST パケットをアクティブに送信して接続を閉じるため、接続が TIME-WAIT 状態になるのを防ぎます。

    • 持続的な HTTP 接続再利用メカニズムを活用するために、Application Load Balancer (ALB) に移行します。

    トラフィック分散の不均等

    一般的な原因

    説明

    解決策

    セッション維持

    セッション維持が有効になっている場合、CLB は同一クライアントからのすべてのリクエストを同じバックエンドサーバーにルーティングします。ストレステスト中などクライアント数が少ない場合、トラフィックが少数のサーバーに集中します。

    セッション維持が有効になっているかどうかを確認し、アプリケーションにとって必要かどうかを判断します。

    接続保持

    CLB は、サーバーの重みを変更しても既存の接続保持中の接続を再分散しません。このようなシナリオでは、重みを変更した後もトラフィック分散の調整は徐々に進行します。

    • オフピーク時にスケーリングまたは重み調整を実行し、古い接続が自然にクローズされるのを待ちます。

    • すべてのバックエンドサーバーで TCP Keepalive 設定を統一し、特定のサーバーに接続が蓄積しないようにします。

    ヘルスチェックの失敗またはフラッピング

    バックエンドサーバーがヘルスチェックに継続的に失敗し、リクエストを受信できません。あるいは、サーバーのヘルスステータスが正常と異常の間で頻繁に切り替わり、トラフィック分散が不安定になります。

    • ヘルスチェックログを確認し、ステータスの変動を特定します。

    • ヘルスチェックの間隔と異常しきい値を増加させ、偽陰性を減らします。

    • 期待されるヘルスチェック応答コードが正しく設定されていることを確認します。

    全体的なリクエスト量が少ない

    CLB インスタンスのモニタリングデータを確認します。リクエスト総数が少ない場合、トラフィック分散のわずかな不均衡は正常です。

    リクエスト量が増加するとトラフィック分散がより均等になるかどうかを観察します。高負荷下でも不均衡が続く場合は、他の潜在的な原因を調査します。

    重み設定の不適切さ

    バックエンドサーバーの重み設定が実際の処理能力と一致しておらず、一部のサーバーが過負荷になり、他のサーバーがアイドル状態になります。

    • 重み付けをサポートするスケジューリングアルゴリズムを使用していることを確認します。ラウンドロビンアルゴリズムは重みを無視します。

    • バックエンドサーバーの実際の処理能力を反映した重みを設定します。

    バックエンド ECS インスタンスの安全な削除

    ECS インスタンスを直接削除すると、一時的なサービス中断が発生する可能性があります。インスタンスの重みを 0 に設定し、既存のすべての接続を処理し終えるのを待ってから削除することを推奨します。重みが 0 のサーバーの動作の詳細については、「重みの設定」セクションをご参照ください。

    ECS インスタンスを削除した後もリクエストを受信し続ける場合は、以下を確認してください。

    • ECS インスタンスが他の CLB インスタンスに属しているかどうか。

    • ECS インスタンス自体が他のサービスを提供していないか。netstat コマンドを使用して、リッスンポートを確認できます。