Classic Load Balancer の使用中に返される 504 エラーをトラブルシューティングするにはどうすればよいですか?

解決策

HTTP 504 エラーは、ゲートウェイまたはプロキシがタイムアウトしたことを示す HTTP ステータスコードです。トラブルシューティングを行う際は、次の点を調べてください。

ロードバランサーのアイドルタイムアウトを確認し、必要に応じて変更する

HTTP 504 エラーが発生する最も一般的な理由は、対応するインスタンスが設定されたアイドルタイムアウト内にリクエストに応答しなかったことです。Classic Load Balancer のデフォルトのアイドルタイムアウトは 60 秒です。

CloudWatch メトリクスがオンになっている場合は、ロードバランサーの CloudWatch メトリクスを確認してください。設定されたロードバランサーのタイムアウト値とレイテンシーデータポイントが同じで、HTTPCode_ELB_5XX にデータポイントがある場合は、少なくとも 1 つのリクエストがタイムアウトしています。

これを解決するには、次の 2 つの方法のいずれかを実行します。

• HTTP リクエストがアイドルタイムアウト期間内に完了するように、ロードバランサーのアイドルタイムアウトを変更する。
• より迅速に応答するようにアプリケーションを調整する。

バックエンドインスタンスが接続を開いたままにする

バックエンドインスタンスがアイドルタイムアウト値に達する前にロードバランサーへの TCP 接続を閉じると、HTTP 504 エラーが表示されることがあります。

これを解決するには、バックエンドインスタンスでキープアライブ設定を有効にし、キープアライブタイムアウトをロードバランサーのアイドルタイムアウトよりも大きい値に設定します。

(Apache のみ) TCP_DEFER_ACCEPT を無効にする

Apache バックエンドインスタンスで TCP_DEFER_ACCEPT が有効になると、ロードバランサーがバックエンドインスタンスに SYN を送信して接続を開始します。その後、バックエンドインスタンスが SYN-ACK で応答し、ロードバランサーが空の ACK をバックエンドインスタンスに送信します。

最後の ACK は空なので、バックエンドは ACK を受け入れず、代わりに SYN-ACK をロードバランサーに再送信します。これにより、後続の SYN リトライがタイムアウトする可能性があります。バックエンドインスタンスが接続を閉じる前に FIN または RST が送信されない場合、ロードバランサーは接続が確立されたと見なしますが、実際は確立されていません。ロードバランサーがこの TCP 接続を介してリクエストを送信すると、バックエンドが RST で応答して 504 エラーを生成します。

これを解決するには、AcceptFilter http と AcceptFilter https の両方を none に設定します。

(Apache のみ) イベント MPM をオフにして、prefork MPM と worker MPM を最適に設定する

ロードバランサーに登録されているバックエンドインスタンスでは、イベント MPM を無効にするのがベストプラクティスです。Apache バックエンドは接続を動的に閉じるため、これらの接続を閉じると HTTP 504 エラーが発生する可能性があります。詳細については、Apache のウェブサイトの「Apache MPM event 」を参照してください。

prefork MPM と worker MPM を使用し、ロードバランサーが 60 秒のアイドルタイムアウトに設定されていると仮定して最適なパフォーマンスを得るには、次の値を使用してください。

詳細については、Apache ウェブサイトの「Apache MPM worker」 と「Apache MPM prefork」を参照してください。

関連情報

Monitor your Classic Load Balancer

Troubleshoot a Classic Load Balancer: HTTP errors

ELB のバックエンドサーバーとして Apache または NGINX を使用するための最適な設定を教えてください。