2017/09/07一般的なロードバランサではできるのにELBでできないURLでの振り分けAWSで提供されるELBはスケーラブルでスケールアップやスケールアウトが自動的にできたり、複数のデータセンター(AZ)をまたぐことができたり、Webサーバのオートスケールと連動したりとても魅力的な機能がある。WebサイトをAWSに引っ越す場合に困ることの1つにELBの機能面で問題になるのはレイヤ7スイッチの機能がないことがあげられる。L7ロードバランサの機能ではパスやcookieやHTTPヘッダで振り分けられる一般的なロードバランサ機器は、単に特定のIPアドレスとポートにきた通信をL4スイッチの機能だけではなく、httpのプロトコルの中身をみて振り分けを行うL7スイッチを利用することができるのが一般的だ。使うのがURLのディレクトリパスでWebサーバを振り分けすることが多い。これは機能毎にWebサーバが異なっているが同じドメインでアクセスするような場合がある。具体的にはhttp://milo.jp/blog/とhttp://milo.jp/game/があって、前者はブログを行うWordPressのWebサーバ群で後者はゲームのアプリケーションサーバ群があるといったもの。通常のロードバランサならパスと振り分け先を設定するだけである。ELBではパスなどでの振り分け設定ができないELB設定のメインの部分はリスナーの設定で受付プロトコルとポート、EC2インスタンス側のプロトコルとポートしかない。EC2インスタンス設定も単純に選ぶだけになっているだkで条件などの設定はないオープンソースのロードバランサLVSを使う方法もあるがEC2にLVS+keepalivedやheartbeat3でロードバランサを構築してしまう方法もありますが運用がかなり厄介。AZまたぎとか冗長化とか。VIPの付け替え処理とかかなり面倒。参考「クックパッドのLVSについて」CloudFrontをL7スイッチとして使いその配下でELBを配置ClowdFrontはAWSのCDNのキャッシュサーバサービスであるが、キャッシュの管理がURLのパスなどの条件でオリジンサーバを振り分けられるようにできている。CloudFrontの設定では「オリジン(振り分け先)」の設定と、「Behavior(振り分け設定)」になる。オリジンにはEC2のインスタンスかELBかS3などが指定できる。今回のネタはロードバランサなのでパスの振り分け毎にELBを設定しCloudFrontの「オリジン(振り分け先)」に登録する。振り分け設定ではワイルドカードを使ったパスの設定をする。(ここに図を入れる予定です)CloudFrontではさらにキャッシュする時間の設定(httpヘッダでも指定可能)などあるので必要なら使っても良い。DELETE)や、httpヘッダやCookieの設定、クエリパラメータの中継もあるので必要な設定を行う。いっても今回はLB目的なので、キャッシュは0指定で、その他はすべて転送する設定にすればよい。下記が設定例で、/blog/*のパス配下はどのオリジン(ELB)に転送するか指定している。オリジンを選択肢に追加するためにはこの設定の前にClowdFrontのオリジン追加で追加しておく。下記の場合はS3も登録してあったので選択枝にS3のエントリが見えている。httpヘッダ転送設定で、ALL設定をするとワーニングでキャッシュできない旨がでるがロードバランサとしては問題ない(キャッシュしたい場合はほしいヘッダを設定すればよい)この方法はCloudFrontの通信料金はそれなりにかかってしまうが、運用の容易さはこちらのほうが断然上である。ロードバランサ336336Tweet関連記事[Jmeter]負荷があまりかからない場合の対策Webアプリケーションサーバの負荷上限を調べることになった。