はじめに
この現象の謎は解明されたので最後に追記してあります。
やりたかったこと
- ELB から EC2 インスタンスに HTTP リクエストを流す
- EC2 インスタンスは Private Subnet1 に置く
- インターネットに出ていくときは Public Subnet にある NAT インスタンスを経由する
発生した問題
ELB に対して HTTP リクエストを投げたときに、レスポンスがものすごく遅いときがある。
ちゃんと返ってくるときは1秒以内に返ってくるのだが、返ってこないときは1分以上待たされる。
ブラウザの開発者ツールで内訳を見てみると、
このように Initial connection に一分以上かかってしまっている。
そもそも ELB から Web サーバ (EC2 インスタンス) まで接続するのにものすごく時間がかかっている。
解決した方法
Private Subnet と同じ AZ に空の Public Subnet を作成し、ELB の設定で Public Subnet の方を指定したところ問題が再現しなくなった。
「EC2 インスタンスを置いてない方のサブネットを設定したらターゲットとして指定できないんじゃないの」と思うかもしれないが、そんなことはなく、普通に指定できる。
ELB の挙動についての考察
そもそも ELB の設定では、Subnet ではなく AZ を選択する。
ここで選択した AZ に含まれる EC2 インスタンスをターゲットとして指定することができる。
そして、選択した AZ ひとつにつき Subnet をひとつ選択する必要がある。
おそらく、各 AZ にロードバランサを配置する際に「この AZ 内のどの Subnet に配置するか」を選択する必要があるのだろう。
そしてロードバランサを配置した Subnet が Private Subnet である場合、ロードバランサから EC2 インスタンスに接続するまでに (なぜか) 一分以上かかってしまうことがある。
なぜ Private Subnet だとダメなのかは、調べた限りではよくわからなかった。
追記
ELB 作成時に Private Subnet を選ぶと Warning が出るっぽい。
You are creating an internet-facing Load Balancer, but there is no Internet Gateway attached to these subnets you have selected
見逃していた・・・。
まとめ
- ELB の配置先を Private Subnet にすると、(理由は不明だが) 接続に時間が掛かる問題が発生する
- 同じ AZ に Public Subnet を作成してそこに ELB を配置すれば解決する
2020.03 追記
AWS 詳しい同僚に解説してもらって3年越しで謎が解けたのでまとめておく。
- ELB インスタンスは AZ ごとに作成される
- 今回のケースの場合、片方の AZ では Public Subnet に、もう片方の AZ では Private Subnet に ELB インスタンスが配置されるように設定した
- この状態で ELB エンドポイントの A レコードを引くと、IP アドレスが2つ返ってくる
- Public な ELB の IP (Global IP) と Private な ELB の IP (VPC の Private IP)
- 接続先の IP アドレスが複数ある場合にどのように接続されるかは Web ブラウザによって挙動が異なる
- Google Chrome の場合、ランダムに1つを選択して接続を試みるが、Private IP の方が選択された場合は接続できないので1分でタイムアウトして他の IP アドレスで再試行する
- 結果的として、「接続できるときとできないときがある」「1分以上待つと接続できる」「Web ブラウザによって挙動が異なる」という現象が発生する
-
Subnet ごとに「これは Private Subnet です」というパラメータがあるわけではなく、Subnet のルートテーブルに設定されているデフォルトゲートウェイ (
0.0.0.0/0) がインターネットゲートウェイに向いていない (NAT インスタンス等を向いている) 場合、その Subnet を Private Subnet と呼ぶ (はず...) ↩