Application Load Balancerの細かい挙動をチェックしてみた

AWS運用自動化サービス「Cloud Automator」
この記事は1年以上前に書かれたものです。
内容が古い可能性がありますのでご注意ください。

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

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

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

ALBの挙動観察

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

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

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

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

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

elb-header

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

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

alb-header

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

ただし、一点注意が必要です。公式のアナウンスにある通り、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-routing

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

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

alb-duplicate-rules

この場合

  • プライオリティ1のルールの振り分け条件となるパスが “/img/*”
  • プライオリティ2のルールの振り分け条件となるパスが “/img/img/*”

となり、1の条件が2の条件を包含してしまいます。この場合、2で指定したターゲットグループにリクエストがルーティングされることはありません。この辺り、ルールを設計する際には気にしておきたいところです。

また、このパスベースの振り分けを行う際に気に留めておかなければならない点は、

  • クライアントからALBに対するリクエストURI(のドメイン部から右)
  • ALBからターゲットに対するリクエストURI(のドメイン部から右)

の両者は全く同じとなるということです。つまり

  • クライアントがALBに対して http://www.example.com/img/image.png をリクエストする

という場合、

  • ALBはターゲットに対して http://[ターゲットのIPアドレス]/img/image.png をそっくりそのままリクエストする

ため、URLのリライト等は一切行わないという点です。こういった動きを必要とする場合、従来と同じくURLのリライト処理を行うための仕組が必要となります。

最後に

余談ですが、AWS CLIもこのリリースに合わせて aws-cli/1.10.56 がリリースされています。ふと先ほどのルールの設定に関するCLIのリファレンスを眺めていたのですが、現状パスベースしか選択肢のないマッチング条件については、今後の拡張を睨んだ作りになっていることが伺えます。

これからのALBのエンハンスに期待したいところです。

 

AWS運用自動化サービス「Cloud Automator」