web-dev-qa-db-ja.com

AWS Elastic Load Balancing：初期接続時間が非常に長い

Sslを介してリクエストを行うと、数日間、ELBへの初期接続時間が非常に長くなる（15秒から1.3分）ことがよくあります。奇妙なことに、私はこれをGoogle Chrome（SafariでもFirefoxでもcurlでもない）でしか観察できませんでした。

すべてのリクエストで発生するわけではありませんが、リクエストの約50％で発生します。これは最初のリクエスト（OPTIONS-call）で発生します。

セットアップは次のとおりです。node.jsバックエンドに接続するクロスゾーンELB（現在はeu-west-1の2つのAZにあります）。すべてのインスタンスは正常であり、リクエストが完了すると、正常に処理されます。現在、システムに負荷はありません。 Cloudwatch for ELBは、バックエンド接続エラーを報告せず、SurgeQueue（値0）も波及効果も報告しません。 ELBメトリックは、低遅延（<100ミリ秒）を示します。 ELBにルーティングするようにRoute53を設定しました（DNSの問題は発生していません。添付のスクリーンショットを参照してください）。

さまざまなREST-APIがあり、すべてこの設定があります。これはすべてのELBで発生します（それぞれが独立したnode.jsバックエンドに接続しています）。これらのELBはすべて、cloudformationテンプレートを介して同じ方法で設定されます。

ELBはSSL終了も行います。

何がそのような行動につながる可能性がありますか？ ELBが正しく構成されていない可能性はありますか？そして、なぜそれはグーグルクロームにしか現れないのでしょうか？

request timing

google-chromeamazon-web-servicesamazon-elb
17
ahrzg

ELBの設定ミスの可能性があると思います。プライベートサブネットをELBに配置したときにも同じ問題が発生しました。プライベートサブネットをパブリックに変更することで修正しました。 https://docs.aws.Amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-manage-subnets.html を参照してください

18
Nikita Ogurtsov

@NikitaOgurtsovの優れた回答をフォローアップするだけです。たまたまプライベートで残りがパブリックだったのはサブネットの1つであったことを除いて、同じ問題が発生しました。

サブネットがパブリックであると思われる場合でも、ルートテーブルを再確認して、サブネットにゲートウェイがあることを確認することをお勧めしますall 。

これが理にかなっている場合は、すべてのLBサブネットにゲートウェイを持つ単一のルートテーブルを使用できます。

VPC/Subnets/(select subnet)/Route Table/Edit

3
Alan Barker

これは、Amazonのエルブで問題になる可能性があります。 elbは、リクエストの数に応じてインスタンスの数をスケーリングします。そのとき、いくつかのリクエストが表示されるはずです。 Amazonは、負荷に合わせるためにいくつかのインスタンスを追加します。インスタンスは起動プロセス中に到達可能であるため、クライアントはそれらのタイムアウトを取得します。それは完全にランダムなので、次のようにする必要があります。

  • すべてのIPを使用するためにelbにpingを実行します

  • 見つかったすべてのIPで mtr を使用します

  • CloudWatchに注目してください

  • いくつかの手がかりを見つける

1
Djory Krache

私にとっての問題は、Classic LoadBalancerに未使用の「アベイラビリティーゾーン」があることでした。不健全で未使用のアベイラビリティーゾーンを削除すると、「初期接続」の一貫した20秒または21秒の遅延が50ミリ秒未満に低下しました。

注：更新する時間を与える必要がある場合があります。 DNS TTLを60秒に設定したので、未使用のアベイラビリティーゾーンを削除してから1分以内に修正が表示されます。

1
Elijah Lofgren

解決策DNSがELBに直接ヒットするように構成されている場合->アソシエーション（IP、DNS）のTTL）を減らす必要があります。IPはELBでいつでも変更できるため、トラフィックに深刻なダメージを与える可能性があります。

クライアントはELBからのIPの一部をキャッシュに保持するため、問題が発生する可能性があります。

Elastic LoadBalancerのスケーリングElasticLoad Balancerを作成したら、着信トラフィックを受け入れ、リクエストをEC2インスタンスにルーティングするように構成する必要があります。これらの構成パラメーターはコントローラーによって保存され、コントローラーはすべてのロードバランサーが正しい構成で動作していることを確認します。また、コントローラーはロードバランサーを監視し、クライアント要求の処理に使用される容量を管理します。より大きなリソース（より高いパフォーマンス特性を持つリソース）またはより多くの個別のリソースを利用することにより、容量が増加します。 Elastic Load Balancingサービスは、新しいリソースがそれぞれのIPアドレスをDNSに登録するようにスケーリングするときに、ロードバランサーのドメインネームシステム（DNS）レコードを更新します。作成されるDNSレコードには、60秒の存続可能時間（TTL）設定が含まれ、クライアントは少なくとも60秒ごとにDNSを再検索することが期待されます。デフォルトでは、クライアントがDNS解決を実行すると、Elastic Load Balancingは複数のIPアドレスを返し、レコードは各DNS解決要求でランダムに順序付けられます。トラフィックプロファイルが変更されると、コントローラーサービスはロードバランサーをスケーリングしてより多くのリクエストを処理し、すべてのアベイラビリティーゾーンで均等にスケーリングします。

AWSでのベストプラクティスELB

1
Djory Krache

私にとっての問題は、ALBがDNSリゾルバーの構成が誤っているNginxインスタンスを指していることでした。これは、Nginxがリゾルバーを使用しようとしてタイムアウトし、実際には少し遅れて動作を開始したことを意味します。

ロードバランサー自体とはあまり関係がありませんが、誰かが自分のセットアップで問題を理解するのに役立つかもしれません。

0
Janis Peisenieks

セキュリティグループも確認してください。それが私の場合の問題でした。

0
Dmitry Grinko