Elastic Load Balancing がロードバランサーのトラフィックを不均等にルーティングするのはなぜですか?

最終更新日: 2019 年 12 月 12 日

インスタンス間またはアベイラビリティーゾーン間で、トラフィックを均等にルーティングするようにロードバランサーを設定しました。しかし、Elastic Load Balancing (ELB) が、1 つのインスタンスまたはアベイラビリティーゾーンに他のインスタンスよりも多くのトラフィックをルーティングします。こうした問題が発生する理由と、解決方法を教えてください。

簡単な説明

以下の場合、ELB はトラフィックをターゲットに不均等にルーティングすることがあります。

  • クライアントが、TTL の有効期限が切れた DNS レコードを持つロードバランサーノードの誤った IP アドレスに、リクエストをルーティングしている。
  • スティッキーセッション (セッションアフィニティ) が、ロードバランサーに対して有効になっている。スティッキーセッションでは Cookie を使用して、クライアントが Cookie の有効期間にわたって同じインスタンスへの接続を維持するため、時間の経過とともに不均衡が発生する可能性があります。
  • 利用可能な正常なインスタンスが、アベイラビリティーゾーン間で均等に分散されていない。
  • 特定のキャパシティータイプのインスタンスが、アベイラビリティーゾーン間で均等に分散されていない。
  • クライアントとインスタンスの間に、存続期間の長い TCP 接続がある。

解決方法

トラフィックの不均衡を確認する

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 の有効期限を設定します。詳細については以下をご参照ください。

個々のアプリケーションからセッション維持を設定する場合、可能な限り、永続的な Cookie ではなくセッション Cookie を使用します。詳細については、「アプリケーション制御のセッション維持設定」(Classic Load Balancer) をご参照ください。

アベイラビリティーゾーン間の正常なインスタンス分散を確認する

アベイラビリティーゾーンの使用可能な正常なインスタンス数が均等でなく、クロスゾーン負荷分散が無効になっている場合、ELB は影響を受けるアベイラビリティーゾーンの少数のインスタンス間でリクエストのバランスをとる必要があります。残りの正常なインスタンスは、より多くのリクエストを処理して補正するため、パフォーマンスに悪影響を及ぼす可能性があります。
注: インスタンスまたはアベイラビリティーゾーン間のトラフィック負荷の不均衡は、必ずしもリソースの使用率も不均衡であることを意味するとは限りません。たとえば、ロードバランサーの背後にある複数のインスタンスが他のインスタンスより速くリクエストを処理すると、不均衡が発生することがあります。

有効な各アベイラビリティーゾーンに、等しい数のインスタンスを維持します。ロードバランサーのターゲットとしてインスタンスを追加するには、以下をご参照ください。

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 パターンとその他の関連するメトリクスを確認します。詳細については以下をご参照ください。


この記事はお役に立ちましたか?

改善できることはありますか?


さらにサポートが必要な場合