皆さんこんにちは。技術二課＠大阪オフィスの久保です。

会社では細々とスイーツを食べては写真をSlackにアップするという業務に勤しんでいる私ですが、最近ヤマザキナビスコの定番「リッツ」がナビスコ社とのライセンス契約解消に伴い今月一杯で販売を終えるというニュースを耳にするに及び、落胆を隠せません。あまりに気落ちしたので、ついAmazonで売っているリッツの缶（Lサイズ）を2つも買ってしまいましたが後悔はしていません。

さて、既に御存知の通り、Elastic Load Balancerの新バージョンとして”Application Load Balancer（以下、ALB）”がこのほど正式にリリースされました。当社も技術一課の寺田が既に速報を公開しておりますが、使ってみると色々と気になる点がありますので、実構成へのインプリ視点で気にしておいた方が良いポイントを解説させて頂きます。

ALBの挙動観察

以下の視点でALBの挙動を観察してみました。

バックエンドに渡すHTTPリクエストヘッダに変化があったかどうか
リクエストURLベースでの振り分けはどのような制御が可能なのか

バックエンドに渡すHTTPリクエストヘッダ

結論から言うと、従来のELB(Classic Load Balancer、以下ELB)とALBとで変化はありませんでした。実際に一つのインスタンスをALB・ELB両方の配下に設置して、両者を経由してやってくるリクエストを覗いてみた結果は以下の通りです。

まずはELB経由でのリクエストヘッダです。

ELBが付与するものとして、X-Forwarded-for(ELBにリクエストを発行したホストのIPアドレス)、X-Forwarded-Proto(接続元からのリクエストを受け付けたELBのプロトコル)、X-Forwarded-Port(同ポート)、あとはHostヘッダ（これはリクエスト元からキャリーオーバーされているもの）あたりです。

次はALB経由でのリクエストを見てみましょう。

なぜかヘッダの並び順が変わっていますが、記載されるヘッダに大きな違いは無いようです。

ただし、一点注意が必要です。公式のアナウンスにある通り、ALBはリスナープロトコルとしてはHTTPもしくはHTTPSのみが利用可能となっているため、従来のようにTCPでのListenは出来ません。

ALBの前段にWAFを挟むような多段プロキシ構成でALBを使うと、前段のプロキシによって付与されたこれらのヘッダが、意図せずALBによって上書きされることも考えられますので、バックエンド側のアプリケーションの仕組み上HTTPヘッダを活用するような場合、ヘッダの上書きには注意すべきです（ELBではTCPリスナーで回避する事が可能でした）。

パスベースの振り分け

パスベースの振り分けはALBの目玉機能の一つです。これによって、バックエンドに複数台のバックエンドサーバーがいる時に、

http://www.example.com/ へのリクエストは1号機に振り分け
http://www.example.com/img/* へのリクエストは2号機に振り分け

といったようなリクエストURIに基づいたルーティングが可能となります。では実際にパスベースの振り分けを設定してみましょう。この設定は”Listeners”タブの中に隠れています。

リスナーのプロトコルを選択すると、どのようにターゲットグループに振り分けるか（ALBでは"ルール"と呼ぶそうです）が設定できます。

ルールにはプライオリティがあり、数字の小さなものから順番に評価され、マッチした時点で振り分け処理が行われます。つまり、プライオリティ1のルールと2のルールが存在する場合、1のマッチング条件が2のものを包含してしまう場合、２は評価されることが無いため2のルールが適用されることは無いということになります。試しに以下の様なルールを書いてみました。