Rohit が Classic Load Balancer の
503 エラーのトラブルシューティング方法
について説明する

503-error-classic-rohit

Classic Load Balancer のアクセスログ内、CloudWatch のメトリックス内、あるいは、ブラウザー内で、またはクライアントから、ロードバランサーの DNS 名がヒットした場合、HTTP 503 エラーが表示されます。この問題を解決する方法を教えてください。

Classic Load Balancer の応答先として構成されている各アベイラビリティゾーンにおいて、バックエンドインスタンスが登録済みか、登録済みのバックエンドインスタンスがヘルスチェックに失敗したことはないか、しかもそれらはアプリケーションで必要とされる負荷を処理するために適切なサイズになっているかどうかを確認してください。

ロードバランサーを支える正常なバックエンドインスタンスの数を調べるには、CloudWatch 内の HealthyHostCount および UnHealthyHostCount メトリックスを参照します。CloudWatch メトリックスで正常なホストが存在しないことが示されている場合、あるいは 1 つ以上の正常ではないホストが存在することが示されている場合、以下のチェックを行うことで、問題をトラブルシューティングすることができます。

バックエンドインスタンスがヘルスチェックに応答していることを確認する

バックエンドインスタンスは動作中で正常のように見えるけれども、UnhealthyHostCount メトリックスでは 1 つ以上の正常ではないインスタンスが存在することが示されている場合、ロードバランサーはヘルスチェックリクエストに応答できるかどうかをチェックします。HTTP/HTTPS ヘルスチェックの場合、ロードバランサーがバックエンドからの応答コード 200 を受信できるかどうかをチェックします。レイヤー 4 ヘルスチェックの場合、インスタンスが TCP ハンドシェイクに成功したとき、ロードバランサーはインスタンスを正常とマークするかどうかをチェックします。詳細については、「Classic Load Balancer のトラブルシューティング: ヘルスチェック」を参照してください。

ロードバランサーとバックエンドインスタンスが負荷を処理することができるかどうかをチェックする

ロードバランサーとバックエンドインスタンスをチェックして、それらが アプリケーションが必要としている CPU、メモリ、ディスクの使用率、および接続数を管理することができていることを確認します

たとえば、SpilloverCount および SurgeQueueLength CloudWatch メトリックスをチェックします。SurgeQueueLength がキューに入れられるリクエストの最大数 1,024 に達している、もしくは近付いている場合、バックエンドのサービスが入ってくるリクエストに追いつけていないことを示し、SpilloverCount がゼロではない値になっている場合、バックエンドはリクエストにサービスをまったく提供できていないことを示します。

また、バックエンドインスタンスの CPUUtilization CloudWatch もチェックしてください。そして、CPU 使用率が 100% に急上昇している場合、あるいは長い時間定常的に高くなっている場合、バックエンドインスタンスの追加、または 現在のインスタンスのサイズを増やすことを検討してみてください。メモリやディスクの使用率など、他の値のチェックについての詳細は、インスタンスベンダーのドキュメントを参照してください。

 


このページは役に立ちましたか? はい | いいえ

AWS サポートナレッジセンターに戻る

サポートが必要ですか?AWS サポートセンターをご覧ください。

公開日: 2016 年 9 月 15 日

更新: 2018 年 2 月 27 日