ELBからHTTP 503が返された時の調査

AWS,ELB,システム設計

概要

はじめに

  • クライアントからのリクエストに対して、ELBからHTTP 503のエラーが返ることがあります。今回は、ELB（主にALB）からHTTP 503が返されたときのトラブルシューティングをまとめます。
 

HTTP 503とは

  • HTTP 503とは”Service Unavailable”であり、一時的にサーバーにアクセスできないことを示します。一般的な原因として、サーバーに多数のアクセスが集中してサーバーが処理不能となった、サーバーの最大データ転送量を超過したなどがあるようです。
  • また、AWSのドキュメントには、下記の記述があり、ALBに対応したターゲットグループに有効なターゲットがいない場合が原因となるようです。しかし、全ての原因が下記とは限りませんので、もう少し深堀します。
ロードバランサーのターゲットグループに登録済みターゲットがありません。
   

構築時のトラブルシューティング

  • システムは構築中であり、まだ疎通が確認できていない場合、以下に記載の設定が正しいかを確認します。
  • ALBのリスナーPortは正しいか？、再確認します。
 
  • ターゲットグループのPortは正しいか？、再確認します。
  • ターゲットグループのフロントにあるALB がSSL/TLS接続の終端であれば、ターゲットグループは80で受けます。一方、ターゲットグループのフロントがNLB であれば、ターゲットグループは443 となりますね。
  • セキュリティグループのルールは正しいか？、再確認します。
  • ヘルスチェックはHealthyですか？、再確認します。必要に応じて、EC2 or ECS のWebサーバーや設定を確認します。
   

運用時のトラブルシューティング

503はALB or バックエンドどっちから来た？

  • HTTP エラーの発生元は、下記いずれかとなります。503 が返された = ALB に原因があるとは言えません。
    • ロードバランサーが HTTP エラーを返した
    • ターゲットが HTTP エラーを返した
  • 先ず、エラーはALB or バックエンドのどちらから返されたかを見極めます。CloudWatch には、ALBあるいはターゲットのどちらで検出されたエラーかを調査するためのメトリクスがあります。
    • HTTPCode_ELB_4XX_Count または HTTPCode_ELB_5XX_Count 
    • HTTPCode_Target_4XX_Count または HTTPCode_Target_5XX_Count
  • 以下、HTTPCode_ELB_5XX_Count メトリクスのサンプルです。
   
  • 以下、HTTPCode_Target_5XX_Count メトリクスのサンプルです。
   

バックエンドから503が返って来た？

  • バックエンドが503のエラーを返していると思われる場合、ALBのアクセスログを確認して詳細を確かめます。
  • 503の発生元が分かれば、次のステップはWebサーバー（Apache,Nginx,IISなど）やアプリ側の状態、ログファイルを確認しましょう。
  • ALBのアクセスログ取得方法については、下記記事を参照ください。
   

ALBから503が返ってきた？

  • ALBが503を返していると思われる場合、前述したターゲットグループに有効なターゲットがないことが理由かもしれません。
  • 先ず、ターゲットグループのヘルスチェックで、現在のステータスがHealthyかを確認しましょう。
  • 次に、CloudWatchの下記メトリクスを確認します。一時的にターゲットのヘルスチェックがUnHealthy になっていた時間帯があったかもしれません。
    • HealthyHostCount
    • UnHealthyHostCount
   

ApacheにConnection timed outのエラーあり

  • ALBの前段にEC2が配置されリバプロとして機能している場合、EC2 のhttpd ログに転送のエラーが記録されているかもしれません。下記Connection timed outのエラーがあれば、何らかの理由でALBに接続できなかったことが分かります。
  • このケースでは、先ず下記どちらのケースに合致しないかを見極めます。合致する場合のそれぞれの内容を参照ください。次に、どちらのケースにも合致しないが、HTTP 503のエラーが発生し、Connection timed outのエラーが記録されている場合があります（ALBに接続できない）。この場合は、前述の構築時のトラブルシューティングに立ち戻り、再度通信経路で何らかの不適切な設定がないかを調査しましょう。
  • リバプロがALBに接続できないケースで、下記Connection timed outのエラーが発生しており、かつ上記状況に合致しない場合は、下記事例の観点でも調査してみて下さい。 

[Thu Nov 21 10:12:17.170431 2019] [proxy:error] [pid 10000:tid 1234567890] (110)Connection timed out: AH00957: HTTP: attempt to connect to xx.xx.xx.xx:80 (xxxxxxxxxx-111111111.ap-northeast-1.elb.amazonaws.com) failed
[Thu Nov 21 10:12:17.170464 2019] [proxy_http:error] [pid 10000:tid 1234567890] [client xx.xx.xx.xx:xxxxx] AH01114: HTTP: failed to make connection to backend: xxxxxxxxxx-111111111.ap-northeast-1.elb.amazonaws.com
   

不正な攻撃は受けていないか？

  • DDos攻撃や不正アクセスなど、セキュリティホールを利用してリソースに過剰な負荷が掛かっていないかを確認しましょう。セキュリティグループのInboundは不必要にオープンされていませんか？
  • CloudWatch メトリクスでALBのRequestCount を確認します。
  • ALBにアクセスログを設定している場合は、異常なアクセスが発生しているかを確認します。
 

ALBのアクセスは急増していないか？

  • 念のため、ALBへのアクセスが急増していないかを確認しましょう。ALBは負荷に合わせて自動的にスケールアウトします。但し、EC2 Auto Scalingと同様にスケールアウトには数分の時間が掛かります。ALBに対して、アクセスの急増があった場合、ALBは処理しきれず、503を返す場合があります。
  • ALBへのアクセス増が予測できる場合は、ELBの暖気申請（Pre-warming）をして、あらかじめスケールアウトさせることが可能です。但し、ELBの暖気申請は、Bussinessプラン以上の契約が必要となります。
 

参考

  • ALBから返されるステータスコードについて、下記記事でまとめています。参照ください。
  • Apacheをリバースプロキシとして使用し、かつバックエンドにALBを配置する構成の落とし穴について、事例紹介しています。
 

AWS,ELB,システム設計

Posted by takaaki