ELBに関するHTTPコードについて

HTTPCode_Backend_2XX：

(3)及び(4)のレスポンスで200系のHTTPレスポンスを行い、(1)〜(4)までのステップを全て正常に完了した場合、HTTPCode_Backend_2XXとしてカウントされます。

一般的に最も健全な動作と言えるでしょう。

HTTPCode_Backend_4XX：

(1)〜(4)までのステップを全て正常に完了したのだが、3のレスポンスが400系レスポンスであり、その結果(4)のレスポンスが400系として完了した場合、これはHTTPCode_Backend_4XXとしてカウントされます。存在しないリソースにアクセスして404がとなった場合や、Web APIに於いて必須のパラメータが足りなかった場合の400レスポンス等、クライアント側の「リクエストの仕方」に問題がある場合、400系のレスポンスを返すのが一般的ですね。

HTTPCode_Backend_5XX：

(1)〜(4)までのステップを全て正常に完了したのだが、(3)のレスポンスが500系レスポンスであり、その結果(4)のレスポンスが500系として完了した場合、これはHTTPCode_Backend_5XXとしてカウントされます。アプリケーション層でのエラーにより正常なレスポンスが返せなかった場合の500、メンテナンス中の503等、

エラーの原因がサーバ側にある場合、500系のレスポンスを返すのが一般的です。

ELBが独自の判断によりステータスコードを返す場合（HTTPCode_ELB_*）

以上の通り、普通は「バックエンドから受け取ったレスポンス(3)をそのままクライアントに返す(4)」のが

ELBの動きです。

しかし、特定の状況下ではELBは独自の判断で(4)のレスポンスを行います。

HTTPCode_ELB_4XX：

①HTTP 400: BAD_REQUEST

そもそも(1)のリクエストが日本語でおｋHTTPリクエストとして解釈不能な場合、ELBは(2)のリクエスト転送を行わず（行えず？）、400を返します。

②HTTP 405: METHOD_NOT_ALLOWED

(1)のリクエストにおけるHTTPメソッド名（GETやPOST等）が127文字を超えていた場合、ELBは(2)のリクエスト転送を行わず、405を返します。

HTTPメソッドは、よく知られたGET, POST, OPTIONS等の他に、独自の拡張が可能です。（RFC 2616 Section 5.1.1参照）

このような拡張を利用していた時、無駄に長いHTTPメソッド名が使われる可能性もゼロではありません。

HTTPの仕様上、この長さには制限は無いようですが、ELBとしては127文字を上限としているようです。

③HTTP 408: Request Timeout

(1)のリクエストでタイムアウトが発生した場合、ELBは(2)のリクエスト転送を行わず（行えず？）、408を返します。

例えば、ネットワーク切断が発生した場合や、Content-Lengthの値よりも実際のサイズが小さくてELBが続きを待ってしまう場合など、ELBが(1)の完了を認識できずにタイムアウトした場合があてはまります。

HTTPCode_ELB_5XX：

①HTTP 502: Bad Gateway

(3)のレスポンスが日本語でHTTPレスポンスとして解釈不能な場合、ELBは502を返します。

②HTTP 503: Service Unavailable(ELBの高負荷系)

Case 1:

突発的なアクセスによりELB自体がキャパシティを超えてしまった場合です。

ELBは、負荷に応じて自動スケールします。

 ->ELBを突発的な負荷が襲った場合、スケーリングが間に合わないことがあります。

また、負荷により「スケールアップ」が行われた場合、ELBのDNS名から正引きされるIPアドレスが変わります。

つまり、古い（小さな）インスタンスと、新しい（大きな）インスタンスにバトンタッチが起こります。

しかし、クライアントがDNSキャッシュを持っていた場合、スケールアップ前の古いインスタンスに対してリクエストを送り続けてしまうことがあります。

こういった場合にも、キャパ超えのレスポンスとして503が返されるでしょう。

このようなケースに対しては、ベンチマークツール等を利用して本番想定の負荷をあらかじめ掛けておき

ELBの自動的なスケーリングによる調整を期待した上で、本番運用を開始するといった対応が必要です。

このような対応が行えない場合、AWSサポートのビジネスまたはエンタープライズに加入しているのであれば

暖気申請を行うことも可能です。

AWSサポートに対して、いつ頃どの程度のリクエストが来るのか、事前に通知を行うことにより、リクエストを充分受け付けられる規模にあらかじめスケールをしてもらえます。

Case 2: 

(3)を行った後(4)が返ってくるのに時間が掛かり、(3)のリクエストがタイムアウトした場合です。

このタイムアウト時間は通常60秒です。

このケースに対応する場合、アプリケーションが60秒以内にレスポンスを返すように何らかの対応を行うのが

第一選択ですが、サポートに依頼することによりタイムアウト時間を最大17分まで延長することができるようです。