AWS announces preview of AWS Interconnect - multicloud
AWS announces AWS Interconnect – multicloud (preview), providing simple, resilient, high-speed private connections to other cloud service providers. AWS Interconnect - multicloud is easy to configure and provides high-speed, resilient connectivity with dedicated bandwidth, enabling customers to interconnect AWS networking services such as AWS Transit Gateway, AWS Cloud WAN, and Amazon VPC to other cloud service providers with ease.
Elastic Load Balancing がロードバランサーのトラフィックを不均等にルーティングするのはなぜですか?
インスタンス間またはアベイラビリティーゾーン間で、トラフィックを均等にルーティングするようにロードバランサーを設定しました。しかし、Elastic Load Balancing (ELB) が、1 つのインスタンスまたはアベイラビリティーゾーンに他のインスタンスよりも多くのトラフィックをルーティングします。なぜこれが発生し、どうすれば修正できるでしょうか?
簡単な説明
以下の場合、ELB はトラフィックをターゲットに不均等にルーティングすることがあります。
- クライアントが、TTL の有効期限が切れた DNS レコードを持つロードバランサーノードの誤った IP アドレスに、リクエストをルーティングしている。
- スティッキーセッション (セッションアフィニティ) が、ロードバランサーに対して有効になっている。スティッキーセッションでは Cookie を使用して、クライアントが Cookie の有効期間にわたって同じインスタンスへの接続を維持するため、時間の経過とともに不均衡が発生する可能性があります。
- 利用可能な正常なインスタンスが、アベイラビリティーゾーン間で均等に分散されていない。
- 特定のキャパシティータイプのインスタンスが、アベイラビリティーゾーン間で均等に分散されていない。
- クライアントとインスタンスの間に、存続期間の長い TCP 接続がある。
- この接続は WebSocket を使用します。
解決方法
トラフィックの不均衡を確認する
ELB アクセスログを分析して、トラフィックの不均衡を確認します。コマンドラインツールを使用して、ロードバランサーが特定のアプリケーションにルーティングしているリクエスト数を見つけます。
Application Load Balancer の場合:
awk '{print $5}' *.log | awk -F ":" '{print $1}' | sort | uniq -c | sort -r
Classic Load Balancer の場合:
awk '{print $4}' *.log | awk -F ":" '{print $1}' | sort | uniq -c | sort -r
ELB は、各 ELB ノードの個々のファイルをバケットに追加します。特定の期間におけるアクセスログファイルの行数を比較できます。
DNS キャッシュをフラッシュする
古い DNS エントリに基づいてルーティングすると、異なるアベイラビリティーゾーンで RequestCount パターンが不均等になります。詳細については、「Application Load Balancer メトリクス」または「Classic Load Balancer メトリクス」を参照してください。クライアントの DNS キャッシュをフラッシュして、ロードバランサーノードの現在の DNS レコードを使用していることを確認します。
注: クロスゾーンの負荷分散が有効な場合でも、ロードバランサーはインスタンスレベルでリクエストを均等に分散できます。
DNS キャッシュに nscd を使用している Linux クライアントの場合には、次のいずれかのコマンドを実行してください。
sudo /etc/init.d/nscd restart
# service nscd restart
# service nscd reload
DNS キャッシュに dnsmasq を使用している Linux クライアントの場合には、次のいずれかのコマンドを実行してください。
$ sudo /etc/init.d/dnsmasq restart
# service dnsmasq restart
DNS キャッシュに BIND を使用している Linux クライアントの場合には、次のいずれかのコマンドを実行してください。
# /etc/init.d/named restart
# rndc restart
# rndc exec
Windows クライアントの場合は、次のコマンドを実行してください。
ipconfig /flushdns
注: クライアントの DNS キャッシュをクリアしてもキャッシュの問題が発生する場合は、クライアントアプリケーションが DNS レコードをキャッシュしていないことを確認してください。
スティッキーセッションの設定を確認する
期間ベースのセッション維持設定を使用する場合は、特定のユースケースに適切な Cookie の有効期限を設定します。詳細については、以下のトピックを参照してください。
- スティッキーセッション (Application Load Balancer)
- 期間ベースのセッション維持 (Classic Load Balancer)
個々のアプリケーションからセッション維持を設定する場合、可能な限り、永続的な Cookie ではなくセッション Cookie を使用します。詳細については、「アプリケーション制御のセッション維持設定」(Classic Load Balancer) を参照してください。
アベイラビリティーゾーン間の正常なインスタンス分散を確認する
アベイラビリティーゾーンの使用可能な正常なインスタンス数が均等でなく、クロスゾーン負荷分散が無効になっている場合、ELB は影響を受けるアベイラビリティーゾーンの少数のインスタンス間でリクエストのバランスをとる必要があります。残りの正常なインスタンスは、より多くのリクエストを処理して補正するため、パフォーマンスに悪影響を及ぼす可能性があります。
注: インスタンスまたはアベイラビリティーゾーン間のトラフィック負荷の不均衡は、必ずしもリソースの使用率も不均衡であることを意味するとは限りません。たとえば、ロードバランサーの背後にある複数のインスタンスが他のインスタンスより速くリクエストを処理すると、不均衡が発生することがあります。
有効な各アベイラビリティーゾーンに、等しい数のインスタンスを維持します。ロードバランサーのターゲットとしてインスタンスを追加するには、以下をご参照ください。
- ターゲットグループにターゲットを登録する (Application Load Balancer)
- ターゲットの登録または登録解除 (Network Load Balancer)
- Classic Load Balancer の EC2 インスタンスの登録または登録解除
Classic Load Balancer と Network Load Balancer の場合、クロスゾーン負荷分散を有効にして、アベイラビリティーゾーンレベルではなくインスタンスレベルでリクエストを分散することを検討してください。詳細については、「クロスゾーン負荷分散」(Network Load Balancer) または「Classic Load Balancer のクロスゾーン負荷分散を設定する」を参照してください。クロスゾーン負荷分散は Application Load Balancer で常に有効になっています。
インスタンスタイプの分散を確認する
HTTP または HTTPS リスナーを使用する Classic Load Balancer では、より容量の大きいインスタンスタイプに多くのトラフィックをルーティングする場合があります。このディストリビューションは、低容量のインスタンスタイプが未解決のリクエストを多く持ちすぎることを防ぐことを目的としています。詳細については、「インスタンスタイプ」を参照してください。キャパシティーのギャップやトラフィックの不均衡が起こる可能性を減らすために、同様のインスタンスタイプと設定を使用することを推奨します。
トラフィックの不均衡は、類似した容量のインスタンスが異なる Amazon マシンイメージ (AMI) で実行している場合にも発生します。このシナリオでは、より容量の大きいインスタンスタイプを優先するトラフィックの不均衡が望ましいです。
存続期間の長い TCP 接続を確認する
Elastic Load Balancing は、ラウンドロビンアルゴリズムを使用して TCP トラフィックをルーティングします。クライアントとインスタンス間の存続期間の長い TCP 接続は、設計上、不均等なトラフィックの負荷分散を引き起こします。その結果、新しいインスタンスは接続の平衡に達するまで時間がかかります。メトリクスをチェックして、問題の原因の可能性のある、存続期間の長い TCP 接続がないか確認してください。また、TCP リスナーではロードバランサーは接続レベルでのみトラフィックを分散します。これは、たとえば、複数の HTTP リクエストを送受信するために頻繁に接続を再利用しているクライアントが、インスタンスレベルで不均衡なトラフィックを生成する可能性があることを意味します。アプリケーションが HTTP、HTTPS、WebSocket、HTTP2 などの上位レイヤーのネットワークプロトコルをサポートしている場合は、レイヤー 7 ロードバランサーへの移行を検討してください。
ロードバランサーの RequestCount パターンとその他の関連するメトリクスを確認します。詳細については、以下のトピックを参照してください。
- Application Load Balancer メトリクス
- Network Load Balancer の CloudWatch メトリクス
- Classic Load Balancer メトリクス
WebSocket 接続の確認
WebSocket 接続でロードバランサーを使用するクライアントは、クライアントとターゲットの間で 1:1 の接続を使用します。この接続は WebSocket 接続の間、ターゲットに固定されたままになり、不均等なトラフィック分散が発生します。Application Load Balancer は WebSocket をネイティブにサポートします。WebSocket にアップグレードされた新しい HTTP リクエストだけが新しいターゲットに送られます。WebSocket は、Classic Load Balancer やレイヤー 4 リスナーを備えた Network Load Balancer とも連携します。
詳細については、「リスナーの設定」を参照してください。
- 言語
- 日本語

関連するコンテンツ
- 質問済み 9年前
- 質問済み 8年前