Apacheをリバースプロキシとして使用し、かつバックエンドにALBを配置する構成の落とし穴について、ご紹介します。具体的には、下記構成となります。インターネットからのリクエストをNLBで受け、後続のリバースプロキシがバックエンドのWebサーバーにパススルーします。Webサーバーは、ALBとEC2で構成します。503のエラーが返ること。outのエラーが記録されていることが分かりました。このエラーは何らかの理由でALBに接続できなかったことを表します。実際にクライアントからcurlを投げてみると、反応なし。することで復旧し、その後使用可能となります。数日すると同様の現象が発生する(!?)。継続して調査すると原因が見えてきました。503のエラーをトラブルシューティングする方法は、下記記事を参照ください。503のエラーが返ることがあります。503が返されたときのトラブルシューティングをまとめます。xx.xx.xx.xx」のIPアドレスはバックエンドに配置したALBのIPアドレスとなりますが、ALBのIPアドレスは可変のため、このIPアドレスは既に解放されており使用できないIPアドレスであることが分かりました。IPアドレスが変わったタイミングからエラーが起きている可能性があると考えました。IPアドレスが変わった日時と現象の発生日時が一致することを確認しています。IPアドレスにアクセスしていることが理由と判断しました。調査はできておりません。ALBのIPアドレスを調べる方法は、下記記事を参照ください。IPアドレスが変わります。IPアドレスを把...Oji-Cloudリバースプロキシの回避策ALBのIPアドレスを変えて再現試験ALBのIPアドレスが変わる条件が不明であったため、疑似的な環境を準備しました。53で設定した別名を指定します。次にバックエンドを2種類準備します。ターゲットなし(503を返す)のターゲットグループです。リダイレクトし続けることが確認できました。IPアドレスが引けていることを確認する。DNS名)へアクセスが行われました。intactniikawa@niikawa1:~$Apacheのproxy設定に回避策を追加するproxyのリダイレクト先に回避策として、”disablereuse=On”と”retry=0′′オプションを追加します。disablereuseはバックエンドとの接続を再利用するか切断するかの設定です。(デフォルトがOff)retryはリトライのタイムアウトを秒で指定します。(デフォルトは60)proxy設定のオプションは、こちらのドキュメントを参照。DNS名)へアクセスが行われました。ALB2はターゲットが1つもないターゲットグループを割り当てているため、期待通り503のエラーを返しています。リバースプロキシサーバ17日目はリバースプロキシサーバについて書きます。初期のリバースプロキシサーバの主な利用目的は社内イントラネット内に構築したWebサーバを社外からアクセスする事でした。S3をはじめとするAWSの各種プロダクトを利用する際の、導入・設計から運用保守を含んだフルマネージドのサービスを提供し、バックアップや24時間365日の監視/障害対応、技術的な問い合わせに対するサポートなどを行っております。AWS上のインフラ構築およびAWSを活用したシステム開発など、案件のご相談はcloudpack.jpよりご連絡ください。cloudpack.。