こんにちは、かたいなかです。
わたしが所属している技術部のインフラグループでは、インフラの構築運用作業以外にも、技術領域をまたいで腰を据えた調査が必要な調査や対応も行うことがあります。
最近も不可解な504エラーが発生しているのを発見し、調査を行いました。今回はその調査の流れを、インフラグループのお仕事紹介も兼ねて共有します。
対象のシステム
対象のシステムはCDNとしてFastlyを採用し、Railsアプリケーションの前段にNginxがいるという構成です。
各コンポーネントの間には、ロードバランスやIPアドレスの固定のために、NLBやALBを挟んでいます。
謎の504エラーが継続的に発生
調査を始めてみると、Fastlyのログでやinternet-facing ALBのELB 504のメトリクスなどから、60秒後に504を返すレスポンスが発生していることが確認できました。
エラーは確率的(0.1%以下)ではあるものの継続的に発生しており、アクセスするパスにはよらず発生しているようでした。
一方、ECSで動かしているRailsアプリケーションに導入しているAPMでは、504や遅いレスポンスは観測できませんでした。
この時点では、nginxやNLB、ALB、pumaのリクエストキューなどが怪しそうに考えていました。
原因の調査を進めた
さらに調査を進めると、nginxからNLBにコネクションを張るところでnginxのproxy_connect_timeout以上に時間がかかってしまい、コネクションがタイムアウトしている事がわかりました。
問題になっている箇所の通信はVPC内部です。そのため、TCPコネクションを張るのにそこまで時間がかかるのは不可解です。そのため、どこかでパケットやコネクション単位で通信がドロップされていたりしそうだと考えていました。
その後もAWSサポートに問い合わせたりVPCフローログを確認したりして調査を進めたのですが、はっきりした原因が特定できませんでした。
keepaliveで緩和するように方針転換したら解決した
原因を調査して、原因を取り除くという方面での対処が手詰まりになってしまったため、緩和を狙って動き直すことにしました。
nginxでは、upstreamのコネクションがkeepaliveされていなかったため、これを修正してkeepaliveさせるようにし、新しくコネクションを張る回数を減らすことで、504や遅いレスポンスが減るかどうかを確認してみることにしました。
すると、エラーの発生がピタリと止まりました。
原因が完全にわかったわけではなく、まだ釈然としないところはあるのですが、504や遅いレスポンスを大幅に減らすことができました。
終わりに
今回はインフラグループでの仕事の紹介を兼ねて最近あった504エラーの調査事例について紹介しました。 はっきりした原因の特定はできなかったものの、問題の解決にはつなげることができました。
インフラグループでは、このようにサーバサイドとインフラの両方の知識を活かした調査や対応も行っています。
興味がありましたら、ぜひインフラグループで一緒に働きましょう！
We are hiring!
技術部インフラグループでは一緒に働く仲間を募集しています！
クラウドインフラ領域に留まらず、アプリケーション側の領域まで踏み込んで、幅広く技術的な課題に取り組んでいきたい方を歓迎します。
興味がある方は、以下の募集要項をご覧の上、ご応募ください。
