ビデオリサーチのニシです。
本日はALBの502 Bad Gatewayの回避策についてお話します。
突然ですが、皆様はシステムを設計する際、タイムアウト設計をどのように行いますか？
バックエンドで発生したエラーをフロントエンドでキャッチし、処理できるようにするために、フロントエンドからバックエンドへのタイムアウト時間を短く設定する設計が一般的かと思います。
私もこのような方針でタイムアウト設計を行うことが多いのですが、ALBが存在する環境では、これが502 Bad Gatewayの発生要因となることがあります。
ALBの502 Bad Gatewayの回避策については、AWSが公開している記事が参考になります。 repost.aws
ロードバランサーがターゲットへの未処理のリクエストを持っている間に、ターゲットは TCP RST または TCP FIN との接続を閉じました。
ロードバランサーはリクエストを受け取り、それをターゲットに転送します。ターゲットはリクエストを受け取って処理を開始しますが、ロードバランサーへの接続を早期に終了します。これは通常、ターゲットのキープアライブタイムアウトの期間がロードバランサーのアイドルタイムアウト値よりも短い場合に発生します。キープアライブタイムアウトの期間がアイドルタイムアウト値より長いことを確認してください。
発生している事象によりますが、私がよく行う回避策は上記の通り、ターゲットのキープアライブタイムアウトの期間をロードバランサーのアイドルタイムアウトよりも長く設定することです。
本日はここまでです。
私自身、たまに忘れてしまい、検索するとすぐに思い出すALBの502 Bad Gatewayについての記事を書いてみました。
この記事が誰かの役に立てば嬉しいです。
ビデオリサーチでは、現在一緒にサービス開発を推進してくれる仲間を大募集しています！
もしビデオリサーチに興味を持っていただいた方は、以下よりお気軽にご応募ください💁♂️
