Amazon EC2でかなり簡単なセットアップを実行しようとしています-Amazon Elastic Load Balancer（ELB）の背後にあるいくつかのHTTPサーバー。

ドメインはRoute53で管理されており、ELBを指すようにCNAMEレコードが設定されています。

すべてではありませんが、一部の場所が断続的にロードバランサーに接続できないという問題が発生しました。これはELBのドメイン名の解決であると思われます。

Amazonサポートは、ロードバランサーの基盤となるElastic IPが変更されており、問題はISPのDNSサーバーがTTLを尊重していないことであるとアドバイスしました。EC2インスタンスのAmazon独自のDNSサーバーを使用して、オーストラリアのローカルISP上で、GoogleのDNSサーバーを介して問題を再現したため、この説明に満足できません（8.8.8.8）。

Amazonは、一部の場所でダウンタイムに気付いた期間中、ELBを通過するトラフィックが大幅にダウンしたことを確認しました。したがって、問題はエンドポイントにありません。

興味深いことに、ドメインは接続できないサーバー上の正しいIPに解決されるようですが、TCP接続を確立する試みは失敗します。

ELBに接続されているすべてのインスタンスは常に正常です。彼らはすべてです

この問題をより深く診断する方法を誰もが知っていますか？Elastic Load Balancerでこの問題を経験した人はいますか？

おかげで、

GooglingでAmazon Elastic Load Balancer（ELB）を診断する方法についてこの質問を見つけましたが、このような問題を抱えている他の人に多くのガイダンスなしで答えたいと思います。

ELBプロパティ

ELBにはいくつかの興味深い特性があります。例えば：

• ELBは1つ以上のノードで構成されます
• これらのノードは、ELB名のAレコードとして公開されます
• これらのノードは失敗するか、シャットダウンされる可能性があり、接続は正常に閉じられません。
• 多くの場合、誰かがELBの問題を掘り下げるには、Amazonサポート（$$$）との良好な関係が必要です。

注：別の興味深い特性ですが、やや適切ではありませんが、ELBは突然のトラフィックの急増を処理するように設計されていません。通常、スケールアップする前に15分間の大量のトラフィックが必要です。または、サポートチケットを介して要求に応じて事前に暖めることができます

ELBのトラブルシューティング（手動）

更新： AWSはDNSにRoute 53を使用するようにすべてのELBを移行しました。さらに、すべてall.$elb_nameのELBには、ELBのノードの完全なリストを返すレコードがあります。たとえば、ELB名がの場合、elb-123456789.us-east-1.elb.amazonaws.comなどの操作を行うことでノードの完全なリストを取得できますdig all.elb-123456789.us-east-1.elb.amazonaws.com。IPv6ノードの場合all.ipv6.$elb_nameも機能します。さらに、Route 53は、まだUDPを使用している最大4KBのデータを返すことができるため、+tcpフラグを使用する必要はありません。

これを知っているので、自分で少しトラブルシューティングを行うことができます。最初に、ELB名をノードのリストに解決します（Aレコードとして）：

$ dig @ns-942.amazon.com +tcp elb-123456789.us-east-1.elb.amazonaws.com ANY

tcpあなたのELBは、単一のUDPパケットの内部に収まるようにあまりにも多くのレコードを持っている可能性としてフラグが示唆されました。また、個人的には確認していませんが、クエリを実行しない限り、Amazonには最大6ノードしか表示されませんANY。このコマンドを実行すると、次のような出力が得られます（簡潔にするためにトリミングされています）。

;; ANSWER SECTION:
elb-123456789.us-east-1.elb.amazonaws.com. 60 IN SOA ns-942.amazon.com. root.amazon.com. 1376719867 3600 900 7776000 60
elb-123456789.us-east-1.elb.amazonaws.com. 600 IN NS ns-942.amazon.com.
elb-123456789.us-east-1.elb.amazonaws.com. 60 IN A 54.243.63.96
elb-123456789.us-east-1.elb.amazonaws.com. 60 IN A 23.21.73.53

ここで、各Aレコードに対して、たとえばcurlELBへの接続をテストするために使用します。もちろん、バックエンドに接続せずに、テストをELBのみに分離することもできます。最後の1つのプロパティとELBに関するほとんど知られていない事実：

• ELBを介して送信できる要求メソッド（動詞）の最大サイズは127文字です。より大きいとELBは許可されないHTTP 405メソッドで応答します。

これは、この動作を利用して、ELBが応答していることのみをテストできることを意味します。

$ curl -X $(python -c 'print "A" * 128') -i http://ip.of.individual.node
HTTP/1.1 405 METHOD_NOT_ALLOWED
Content-Length: 0
Connection: Close

表示される場合HTTP/1.1 405 METHOD_NOT_ALLOWED、ELBは正常に応答しています。curlのタイムアウトを許容可能な値に調整することもできます。

elbpingを使用したELBのトラブルシューティング

もちろん、これを行うとかなり面倒になる可能性があるため、elbpingと呼ばれる自動化ツールを作成しました。ruby gemとして利用できるので、rubygemsをお持ちの場合は、以下を実行するだけでインストールできます。

$ gem install elbping

これで実行できます：

$ elbping -c 4 http://elb-123456789.us-east-1.elb.amazonaws.com
Response from 54.243.63.96: code=405 time=210 ms
Response from 23.21.73.53: code=405 time=189 ms
Response from 54.243.63.96: code=405 time=191 ms
Response from 23.21.73.53: code=405 time=188 ms
Response from 54.243.63.96: code=405 time=190 ms
Response from 23.21.73.53: code=405 time=192 ms
Response from 54.243.63.96: code=405 time=187 ms
Response from 23.21.73.53: code=405 time=189 ms
--- 54.243.63.96 statistics ---
4 requests, 4 responses, 0% loss
min/avg/max = 187/163/210 ms
--- 23.21.73.53 statistics ---
4 requests, 4 responses, 0% loss
min/avg/max = 188/189/192 ms
--- total statistics ---
8 requests, 8 responses, 0% loss
min/avg/max = 188/189/192 ms

表示される場合code=405、ELBが応答していることを意味します。

次のステップ

どの方法を選択しても、少なくともELBのノードが応答しているかどうかはわかります。この知識を活用して、スタックの他の部分のトラブルシューティングに焦点を合わせるか、何かが間違っているというかなり合理的なケースをAWSに提出することができます。

お役に立てれば！

修正は実際には簡単です。Route53 Aではなくレコードを使用CNAMEします。

AWSマネジメントコンソールで、「Aレコード」を選択し、「エイリアス」というラベルの付いたラジオボタンを「はい」に移動します。次に、ドロップダウンメニューからELBを選択します。

このAWS開発者フォーラムでは、いくつかの解決策を試すことができます。https://forums.aws.amazon.com/message.jspa?messageID=387552。

例えば：

潜在的な修正＃1

ELBに移行したときに同様の問題が発生しました。ELBの名前を1文字に減らすことでこれを解決しました。ELBの2文字の名前でさえ、ネットワークソリューションのDNS解決でランダムな問題を引き起こしました。

ELBのDNS名は-> X. <9chars> .us-east-1.elb.amazonaws.comのようなものでなければなりません

潜在的な修正＃2

私は元のポスターです。すべての回答をありがとう。TTLを非常に高く設定することで、DNSの問題が発生する頻度を減らすことができました（したがって、ネットワークソリューション以外のサーバーによってキャッシュされる）。ただし、Network Solutionsにとどまることができなくなったため、まだ十分な問題が発生していました。サービスに関する優れたレポートに基づいてUltraDNSに移行することを考えましたが、Route 53（内部でUltraDNSを使用しているように見えます）の方が安価であるように見えました。Route 53に切り替えてから、DNSの問題はなくなり、ELB名も長くなります。

その投稿では他にも試してみることがありましたが、それらが最高のリードと思われます。