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

サーバーグループの種類

重みの設定

スケジューリングアルゴリズムは、CLB が複数のバックエンドサーバーに対して着信リクエストをどのように分散するかを決定します。重みは、「重み付き」アルゴリズムを使用する場合に、各サーバーに割り当てるトラフィックの割合を制御します。

• 適用範囲：重み付きスケジューリングアルゴリズムを使用する場合のみ有効です。ラウンドロビン方式では無効です。

• 有効値：0 ～ 100。デフォルト値は 100 です。

• 重みを 0 に設定した場合：サーバーは新しいリクエストの受付を停止します。既存の接続は通常終了まで継続されます。ヘルスチェックは引き続き実行されます。これは、グレースフルシャットダウンに一般的に使用されます。

• 重み変更の影響：変更は新規接続にのみ適用されます。既存の接続には影響しません。持続的接続のシナリオでは、重みを調整した後にトラフィックが徐々に移行します。

サービスの高可用性

CLB のヘルスチェックを有効化すると、定期的にリクエストを送信してサーバーの状態を検証できます。

• ヘルスチェックが成功した場合：サーバーは正常です。CLB はそのサーバーにトラフィックを転送します。

• ヘルスチェックが失敗した場合：サーバーは異常です。CLB はサーバーが回復するまで、新しいリクエストを送信しません。

CLB のヘルスチェックは 100.64.0.0/10 CIDR ブロックを使用します。バックエンドサーバーのセキュリティグループルールが、この CIDR ブロックからのトラフィックを許可していることを確認してください。許可されていない場合、ヘルスチェックが失敗し、サービス中断を引き起こす可能性があります。

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

• プライマリサーバーのヘルスチェックが失敗した場合、トラフィックはセカンダリサーバーに切り替わります。デフォルトでは、セカンダリサーバーに対するヘルスチェックは実行されません。フェールオーバー前に、セカンダリサーバーが利用可能であることを確認する必要があります。

• フェールオーバー時間は「ヘルスチェック応答タイムアウト」設定に依存します。プライマリサーバーが回復した後、トラフィックは自動的に元のプライマリサーバーに戻ります。

CLB インスタンスの稼働中に、ECS インスタンスの台数を調整できますか？

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

• プライマリ/セカンダリサーバーグループ：対応していません。

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

異なる場合があります。

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

異なるリージョンの ECS インスタンスをバックエンドサーバーとして使用できますか？

CLB は、クロスリージョンのバックエンドサーバーの関連付けをネイティブでサポートしていません。クロスリージョンデプロイメントを実現するには、以下のいずれかのオプションをご利用ください：

• 複数のリージョンに展開された CLB インスタンスの前方に Global Traffic Manager (GTM) を配置します。GTM がトラフィックを異なる CLB インスタンスにルーティングすることで、クロスリージョンのロードバランシングを実現します。詳細については、「Global Traffic Manager」をご参照ください。

• Application Load Balancer (ALB) または Network Load Balancer (NLB) をご利用ください。これらは、クロスリージョンのバックエンドサーバーの関連付けをサポートしています。詳細については、「Application Load Balancer」または「Network Load Balancer」をご参照ください。

100 で始まる IP アドレスが頻繁に私の ECS インスタンスにアクセスするのはなぜですか？

これらのリクエストは、CLB のヘルスチェックおよび可用性監視から発生しています。

• ソース: 予約済みの Alibaba Cloud CIDR ブロック 100.64.0.0/10。

• セキュリティ：この CIDR ブロックは、Alibaba Cloud の内部用途専用に予約されています。他のユーザーはこの範囲の IP アドレスを割り当てることができないため、セキュリティ上のリスクはありません。

• 推奨事項：サービスの可用性を確保するため、セキュリティグループルールでこの CIDR ブロックからのトラフィックを許可してください。

ECS インスタンスで圧縮を構成していないのに、CLB からの HTTP 応答が圧縮されるのはなぜですか？

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

• 対処方法：CLB コンソールのリスナー構成で Gzip 圧縮を無効化するか、TCP リスナーをご利用ください。

HTTP 1.0 を使用する ECS インスタンスは、チャンク転送エンコーディングをサポートしますか？

サポートしています。

CLB インスタンスのバックエンド ECS インスタンスが、User-Agent 「KeepAliveClient」で多数のリクエストを頻繁に受信するのはなぜですか？

• 症状：バックエンド ECS インスタンスが、Alibaba Cloud の内部 IP アドレスから多数の GET リクエストを受信し、User-Agent が KeepAliveClient となっています。

• 原因：リスナーのプロトコルが TCP ですが、ヘルスチェックのプロトコルが HTTP です。TCP リスナーで HTTP ヘルスチェックを使用すると、デフォルトで GET リクエストが送信されます。

• 解決策：リスナーとヘルスチェックで同一のプロトコル（TCP または HTTP）をご利用ください。

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

直接変更することはできません。

• 制限事項：ポートはリスナー作成時にのみ設定可能です。同一リスナーのデフォルトサーバーグループに属するすべてのバックエンドサーバーは、同一ポートを使用する必要があります。

• 解決策：同一リスナーで異なるバックエンドポートを構成するには、vServer グループをご利用ください。

CLB のレイヤー 4 リスナーは、ECS インスタンスをバックエンドサーバーおよびクライアントの両方として使用することをサポートしますか？

いいえ。この構成はループバック状態を引き起こします。

代替ソリューション：

• CLB のレイヤー 7 リスナー（HTTP または HTTPS）をご利用ください。

• NLB インスタンスをご利用になり、サーバーグループの「クライアント IP の保持」機能を無効化してください。詳細については、「NLB インスタンスで、サーバーグループ内の ECS インスタンスをバックエンドサーバーおよびクライアントの両方として動作させるにはどうすればよいですか？」をご参照ください。