今回はalbを利用したwebサーバがあるときになぜかアクセスがうまくいかない事があったので共有します。
Table of Contents
構成
今回はwebサーバ1台に対してalbをつけるというものになっています。
また、証明書はalbが持っているものとします。↓こんな感じ
問題
ここで問題が起きたわけです。
クライアントからwebサーバにアクセスをしようとすると、2回に1回はアクセスしてほしいEC2にアクセスしてくれないんです。
解決策
スティッキーセッション
一旦よくわからなかったので、スティッキーセッションで一度うまくアクセスできたら継続的にアクセスができる環境だけ先に整えました。
この場合の問題点はアクセスに失敗すると、アクセスが成功するまでcookieの削除を行わないといけないという、謎縛りが発生する点です。
まさに選ばれたものだけが入れるwebサイトになってしまったわけです。
ただ、このままじゃ確実に問題でしたので解決していきます。こちらは仮の応急処置です。
ターゲットグループを指定する。
アクセス来た時にalbのターゲットグループを指定することにしました。
仮説として、毎度インスタンスがあるサブネットと、無いサブネットに負荷分散としてalbが交互にアクセスさせているのだと考えたからです。
ターゲットグループをしていして、インスタンスのあるグループのみにアクセスをさせようという方法です。
結果….
うまくいかない。
これで解決かと思いきや、2回に一度、400bad requestが出てくるのです。
謎が深まるばかり。
通信を再確認
ここで通信を再確認することにしました。
まずはクライアントからALBに対してのアクセス。443と80でできるようになっています。
確認した場所はALBのセキュリティグループこちらではしっかりポートは開いていました。
そしてALBのリスナーも確認。
こちらも443と80の設定ができているので問題ありません。
もちろんALBには証明書を持たせているので問題なく、通信ができるわけですね。
次にALBからEC2に対してのアクセスを確認。
まずはEC2のセキュリティグループ。ここには80と443が開いていて、ソースにはALBのセキュリティグループを入れているので問題ありません。
が、よく考えてみるとセキュリティグループのポートは空いています。しかし、EC2自体は証明書も持っていないし、設定もできていないわけです。
ということはALB→EC2の通信がおかしい！！
ALBのターゲットグループのtargetを確認。
すると、targetには80と443二つありました。
ふむ、443が問題でエラーが出ていると思ったので443のtargetを削除しました。
…
…
アクセスができる！
ということで結局は443のtargetが問題になっていたわけですね。
一応、「クライアント＝ALB」間ではssl通信ができている状態なので問題はないかと思います。
まとめ
この問題は別のエンジニアに相談することで一瞬で解決ができました。
何時間も問題に関して悩むのはやめて、一定時間自分で考えて無理だったら質問をするようにするのが大切ですね。
ちなみにgoogleの人工知能の研究部門のルールは15分考えて解決できなかったら質問をする。ということだそうです。
15 min rule: when stuck, you HAVE to try on your own for 15 min; after 15 min, you HAVE to ask for help.- Brain AMA pic.twitter.com/MS7FnjXoGH
— Rachel Thomas (@math_rachel) August 14, 2016
