2022/09/06 追記 Next.js v12.2以降では本記事の対処が不要になりました。詳細はコメントをご覧ください。 https://zenn.dev/link/comments/83306d9bb57eb9 Client -> AWS ALB -> Node.js 構成をとった場合、稀にALBが502を返す場合があります。 これは、Node.jsのkeepAliveTimeoutのデフォルト値が5秒[1]であり、ALBのConnection idle timeoutのデフォルト値が60秒[2]であることによって引き起こされます。 この問題の詳細はこちらの記事が詳しいです。 問題点 Next.jsでも上記の問題が発生するのですが、厄介なのはkeepAliveTimeout値を変更する方法が提供されていないことです。 例外的に、Custom Serverを利用すればkeepAlive
こんにちは、テクニカルサポートの Shimizu です。 弊社ヘルプデスクへ「Application Load Balancer(ALB)の 502 エラーの原因調査が難しい」というお問い合わせをよくいただきます。 実際サポート側においても「原因箇所が ALB 側か、またはバックエンド EC2 サーバー側か」の切り分けは確認するべき点が多く、毎回時間がかかります。 そこで「もっと簡単に原因を切り分ける方法がないか」と考えた結果、Yes/No 形式のトラブルシューティングを作ろうと思いつきました。 それでは始めてみましょう! 質問 [質問1] 該当時刻の ALB のメトリクスを確認しましょう。「HTTP 5XXs」は出ていますか? YES(出ている) バックエンドサーバーの内部から 500 系のエラーレスポンスが返されており、バックエンド側の問題を明確に示しています。 → [結果A] へ N
渡辺です。 最近、ビックコミックスの「アオアシ」ってサッカー漫画がお気に入りです。 同じサッカー漫画のジャイアントキリングと共に、チームビルディングやコーチングのヒントなども学べます。 さて、今回はELBをフロントエンドに配置したApacheの推奨設定です。 過去エントリーあるかなと思いましたが、なかったので書いておきましょう。 What are the optimal settings for using Apache as a back-end server for ELB?で説明されています。 KeepAliveTimeoutをELBアイドルタイムアウトの値以上にする 結論としては、 KeepAliveTimeoutを60秒以上 に設定します。 60秒というのはELBのアイドルタイムアウトのデフォルト値です。 AWSのドキュメントでは120秒を推奨値としています。 その他の推奨値を反
TL;DR ELBはクライアントからのリクエスト時に、クライアントとバックエンドとのコネクション2つを維持する 両方の接続について、アイドルタイムアウト値はデフォルトで60秒となっている バランシング先のNginxなどのKeepAlive Timeout値は、ELBのアイドルタイムアウト値より大きくなければならない もしELBのアイドルタイムアウト値より小さい場合、504 Gateway Timeoutエラーが返ってくる この504エラーはALBのログには書き込まれないので、きちんとALBのステータスコードを監視するべき ELBのコネクション 図にするまでもないが、ELBにおけるTCPコネクションは以下のようになっている。 KeepAliveとは まずはKeepAliveについて振り返っておく。KeepAliveとはクライアントとサーバー間での接続が有効であるかを確認するために一定周期で行
連載目次 TCP/IPの仕組みについて、“目で見て触って”学ぶ本連載。第5回では、「認証」の仕組みを見ていきます。プロトコルビュワー(※)での実行結果とブラウザの動作を見比べながら、HTTPへの理解をさらに深めましょう。 ※「プロトコルビュワー」について 本連載では、筆者が作成した「プロトコルビュワー」というツールを使い、実際のリクエスト/レスポンスの内容を見ながら学習を進めていきます。プロトコルビュワーのインストール方法や使い方については、前回を参考にしてください(記事冒頭やや下「『プロトコルビュワー』差し替えのお願い」を参照) 認証とは?――実際のアクセスの流れ 認証とは、「Webへのアクセスに際してユーザー名とパスワードを求め、それらがあらかじめ登録してあるものと合致したときだけ、リクエストされた内容を送り返す仕組み」のことです。認証を利用することで、ユーザー名とパスワードを知ってい
Keep-Aliveの動作 HTTPの基本的な動作では、「リクエストのたびに接続を確立し、1つのレスポンスを返したら接続を切る」ということを繰り返します。 実際のWebページを見ると、そこには文字以外に複数の要素(写真、画像、音楽など)が含まれており、1つの画面を表示するにはこれら全てをサーバから取得する必要があります。そのため、Webページを見るときには通常、HTTPのリクエストを何度か繰り返して、必要な全ての情報をサーバから取得します。 しかしながら、HTTPのリクエストとレスポンスを1つやりとりするたびに、いちいち接続を準備して切断することを繰り返すのは、明らかな無駄です。 そこで、現在最も多く使われているバージョンのHTTP(HTTP 1.1)では、この無駄を省く仕組みが用意されています。具体的には、特に指定がない限り、レスポンスを返した後に接続を維持し、次のリクエストを送るときは
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く