AWS ELB Apache2 503サービスを利用できません：バックエンドサーバーが最大容量に達しています
アマゾンのAWSインフラストラクチャから2年間、いくつかのウェブサイトを実行していますが、約2日前に、ウェブサーバーが1日に1回または2回ダウンし始め、唯一のエラーが見つかりました。
HTTP/1.1 503 Service Unavailable: Back-end server is at capacity
CloudWatchによってトリガーされているアラーム（CPU /ディスクIO/DB接続）はありません。 ELBをスキップしてエラスティックIP経由でサイトにアクセスしてみたところ、次のようになりました。
HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers. Retrying.
Apacheログに異常なものは見られず、適切にローテーションされていることを確認しました。 SSHを介して「ダウン」しているときにマシンにアクセスしても問題はありません。プロセスリストを見ると、正常に見える151個のApache2プロセスが表示されています。 Apacheを再起動すると、一時的に問題が解決します。このマシンは、ELBの背後にある単なるWebサーバーとして動作します。任意の提案をいただければ幸いです。
CPU使用率平均：7.45％、最小：0.00％、最大：25.82％
メモリ使用率平均：11.04％、最小：8.76％、最大：13.84％
スワップ使用率平均：N/A、最小：N/A、最大：N/A
/にマウントされた/ dev/xvda1のディスク領域使用率：平均：62.18％、最小：53.39％、最大：65.49％
ELBではなく個々のEC2インスタンスに問題があると思います。エラスティックIPに到達できなかったとしても、それを除外したくありませんでした。 ELBが実際のEC2インスタンスにヒットした結果を返すだけだと思います。
更新：2014-08-26私はこれをもっと早く更新するべきでしたが、「修正」は「悪い」インスタンスのスナップショットを取り、結果のAMIを開始することでした。それ以来、それは下がっていません。まだ問題が発生しているときにヘルスチェックを確認しましたが、ヘルスチェックページ（curl http://localhost/page.html）ロードバランサーから容量の問題が発生した場合でも。私はそれがヘルスチェックの問題だったとは確信していませんが、Amazonを含む誰もより良い答えを提供できないので、私はそれを答えとしてマークしています。ありがとうございました。
更新：2015-05-06私はここに戻ってきて、ヘルスチェックの設定が問題であると私が確信している問題の一部だと言いました。 AMIの問題であることを排除したくありません。交換用AMIの起動後に間違いなく改善されたためですが、ロードバランサーごとにヘルスチェックが異なり、最も問題が発生しているヘルスチェックが見つかりました。非常に積極的な異常なしきい値と応答タイムアウトがありました。私たちのトラフィックは予想外に急上昇する傾向があり、積極的なヘルスチェック設定とトラフィックの急上昇の間で、それは完璧な嵐であったと思います。問題の診断では、現時点でヘルスチェックのエンドポイントに到達できるという事実に焦点を当てましたが、レイテンシのためにヘルスチェックが失敗した可能性があり、その特定のELBに対して高いヘルスしきい値があったため、インスタンスが再び正常であることを確認するにはしばらく時間がかかります。
ELBロードバランサーがヘルスチェックを実行し、（通常はNameVirtualホストでの）構成の誤りが原因で「ページが見つかりません」（またはその他の単純なエラー）を受信すると、「バックエンドサーバーは容量に達しています」を取得します。
「ELB-HealthChecker」ユーザーエージェントを使用して、ログファイルフォルダーをgreppingしてみてください。例えば.
grep ELB-HealthChecker /var/log/httpd/*
これにより、通常、4xまたは5xエラーが発生し、簡単に修正できます。例えばフラッディング、MaxClientsなどが問題の原因になりすぎています。
FYI Amazon：リクエストから返された応答を表示しないのはなぜですか？ステータスコードも役立ちます。
私はこの問題に自分で遭遇しました。正常なインスタンスがない場合、Amazon ELBはこのエラーを返します。私たちのサイトは正しく構成されていなかったため、ELBヘルスチェックが失敗し、ELBが2つのサーバーをローテーションから外しました。正常なサイトがゼロの場合、ELBは503 Service Unavailable：Back-end server is capacityを返しました。
[質問をよく理解してから編集してください] ELBの経験がないので、ApacheがTomcatの前にいて接続にフラッディングが発生した場合にスローされる503エラーのように聞こえます。
その結果、Apacheがバックエンドで処理できるよりも多くの接続要求を配信する場合、接続が受け入れられなくなるまでバックエンド入力キューがいっぱいになります。その場合、Apacheの対応する出力キューがいっぱいになります。キューがいっぱいになると、Apacheは503をスローします。Apacheがバックエンドであり、キューがいっぱいになるような速度でフロントエンドが配信する場合も同じことが起こります。
（仮想）ソリューションは、バックエンドの入力コネクタとフロントエンドの出力コネクタのサイズを決定することです。これは、予想されるフラッディングレベルと、関係するコンピューターの利用可能なRAM）の間のバランスをとる行為に変わります。
そのため、これが発生した場合は、maxclients設定を確認し、Apache（mod_status。）で忙しいワーカーを監視してください。可能な場合は、Tomcatsコネクタバックログ、maxthreadsなどに対応するELBを使用して同じことを行います。要するに、Apacheの入力キューとELBの出力キューに関するすべてを調べます。
私はそれが直接適用可能ではないことを完全に理解していますが、このリンクにはApacheコネクタのサイジングガイドが含まれています。対応するELBキューの技術を調査してから、計算を行う必要があります。 http://www.cubrid.org/blog/dev-platform/maxclients-in-Apache-and-its-effect-on- Tomcat-during-full-gc /
以下の解説でわかるように、Apacheコネクタを圧倒するのはトラフィックのスパイクだけではありません。一部のリクエストが他のリクエストよりも処理が遅い場合、それらの比率が高いと、コネクタキューがいっぱいになる可能性があります。私の場合はそうでした。
また、これが私に起こったとき、503：sが再び提供されないようにするためにApacheサービスを再起動しなければならないことに困惑しました。コネクタのフラッディングを待つだけでは不十分でした。私はそれを理解できませんでしたが、Apacheのキャッシュからサービスを提供していると推測できますか？
ワーカーの数と対応するpre-fork maxclients設定（これはWindows上のマルチスレッド化されたApacheであり、私が正しく覚えていればキューに他のいくつかのディレクティブがある）を増やした後、503問題が消えました。私は実際には計算をしませんでしたが、キューリソースのピーク消費量に広いマージンが見られるまで値を調整しました。私はそれを手放しました。
これが何らかの助けになったといいのですが。
elbヘルスチェッカーの値を上げることができるため、単一の遅い応答でelbからサーバーをプルすることはありません。誰もがサイトをダウンさせるよりも、数人のユーザーがサービスを利用できないようにする方がよいでしょう。
編集：ヘルスチェックのタイムアウトを25秒にアップすることで、キャッシュを事前に暖めることなく回避できます...... 1〜2分後に...サイトは地獄のように反応します
編集::オンデマンドの束を起動するだけで、監視ツールが管理の速さを示したら、RI Amazonを前払いするだけです：P
編集：それは可能です、単一のバックエンドelb登録されたインスタンスは十分ではありません。もう少し起動して、elbに登録するだけで、問題を絞り込むのに役立ちます
それは数年遅れですが、うまくいけばこれは誰かを助けるのに役立ちます。
ELBの背後にあるインスタンスに適切なパブリックIPが割り当てられていなかったときに、このエラーが発生しました。 Elastic IPを手動で作成してインスタンスに関連付ける必要があり、その後ELBはほぼ瞬時にそれを取得しました。