はじめに

あるアプリケーションをAWSのELBを使ってアクセスを分散していたのだが、ある定期的にアクセス制限されるといった自体が起きていた。

原因としては初歩的なことだったのだが、少々はまっていたので備忘録として残しておきます。

要約

ELBは作成時に指定のregionの全availabity-zone分のロードバランサを作成する
対象のavailabity-zoneのインスタンス数が0の場合、別のavailabity-zoneのインスタンスへとアクセスが割り振られる
当たり前だけど問題発生時はエラーログをすぐにちゃんと確認する

原因解明とその経緯

nginx.confの設定ミス？

その時のnginxの設定は以下の通りである。

/etc/nginx/nginx.conf

  set_real_ip_from   172.31.16.0/16;
  real_ip_header     X-Forwarded-For;

インスタンスのavailabity-zoneに対応したCIDRがきちんと設定されていた。
そのため設定をみる限りはなにも間違いがなかった。
そこで設定されても反映されてないのかな？と思い、nginxを再起動するも変わらず、
CIDRの入力ミスでは？となんど見直しても間違っておらず、
依然、繋がったり繋がらなかったりと謎は深まるばかり。

エラーログを見てみると？

なんでだ、なんでだー。
と思いログの存在を思い出したので確認してみると、以下のようなメッセージが。

2016/02/10 05:20:32 [error] 1948#0: *3458 access forbidden by rule, client: 172.31.0.x, server: localhost, request: "GET /hoge HTTP/1.1", host: "example.com"

ん？172.31.0.xってなんだ？172.31.16.xじゃないの？？

インスタンスは0なのに？なぜ？

ELBのIPを確認してみると、アクセス元がインスタンスが配備されているap-northeast-1cではなく、ap-northeast-1aであることが判明。

でもなぜ、ap-northeast-1aから？
と思って、コンソールを見てみると、インスタンスが0のap-northeast-1aがロードバランサに設定されていました。
0なら問題ないのでは？と思いつつも、ap-northeast-1aの設定を削除してみると無事アクセス制限に引っかからなくなりました。

どうやらインスタンス数が0の場合は、別のap-northeast-1aへアクセスを割り振っている模様。

本来、各availability-zoneごとにインスタンスを配備してあるのが普通だと思うのだが、
開発用の小規模なサーバだったために、このへんケチってインスタンス１個でやってたため、このような自体に。

それに作成時の流れでは特に設定する画面もなかったので、
生成時に指定regionで利用可能な全availability-zoneのロードバランサが設定されるという自体にも気付かずハマってしまいました。

最後に

原因わかってみれば大したことじゃなかった気もしますが、わかるまではさっぱり何が起きてるのかもわからず結構はまってました。
というのも現象がわからず、ただただなんでだろうといろいろ試していたためでした。
この時エラーログをちゃんと確認する癖をつけてれば原因発見も早かったのになと、当たり前なんですが改めて身をもって知ることとなりました。