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) を展開します。詳細については、「Global Traffic Manager」をご参照ください。

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

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 インスタンスを使用し、NLB サーバーグループの [クライアント IP の保持] 機能を無効化します。詳細については、「NLB インスタンスで、サーバーグループ内の ECS インスタンスをバックエンドサーバーおよびクライアントの両方として機能させるにはどうすればよいですか？」をご参照ください。

バックエンドサーバー間でトラフィックが均等に分散されないのはなぜですか？