batchiです。
早いものでALB（Application Load Balancer）が登場してから数ヶ月。
先輩のpinoco氏はALBが登場してすぐにブログに書いていたのですが、
ELB(Application Load Balancer）をおさわりする
当時の僕はパスベースとはなんぞや状態で、
いまいち「ALBならでは」の挙動を理解できておりませんでした。
ここにきてようやく理解が追いついてきたので、
数ヶ月前の自分に向けて噛み砕いた説明を記していきます。
まずはCLBとALBの違い
ALB（Application Load Balancer）が登場したことによって、
従来のLoad BalancerはCLB（Classic Load Balancer）と称されることになりました。
以下記事中の呼称はALB、CLBに統一します。
公式ドキュメントで両者の比較表が作られていますので確認しましょう。
http://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/userguide/what-is-load-balancing.html#elb-features
[パスベースのルーティング]という行には、
ALBにのみチェックがついていることがわかります。
あとはまぁ、いろいろ違いますね。
いきなり脱線して日本語訳への不満
[スティッキーセッション (Cookie)]の行をご確認ください。
ALBの列に、「生成されたロードバランサー」と書いてあります。
ちょっと意味が分からないですね。
英語表記に切り替えると、
「load balancer generated」と記載されています。
「generated」によって「load balancer」が修飾されているという訳し方ですね。
正しくは「load balancer generated」が「cookies」を修飾していて、
「ロードバランサーが生成した（クッキー）（によるスティッキーセッション）」のはずです。
CLBであれば、
アプリケーション制御のcookieによるスティッキーセッションも、
ロードバランサー制御のスティッキーセッションも選択できるけど、
ALBでは後者しか使えません。という意味でした。
パスベースのパスとは
話は戻ってパスベースの話です。
パスベースにおけるパスとは何を指しているのかをきちんと理解するために、
URLの構成をおさらいしておきましょう。
https://www.cman.jp/network/term/url/
↑こちらのサイト様がわかりやすくまとまっていました。
簡単に言うとこういった構成になります。
http://<FQDN> <パス>
FQDNとは、「（ホスト名+）ドメイン」のことです。
弊社のHPのURLで見ると…
https://www.simpline.co.jp
| ホスト名 | www |
| ドメイン | simpline.co.jp |
| パス | なし |
技術ブログの場合だと…
http://www.simpline.co.jp/tech/
| ホスト名 | www |
| ドメイン | simpline.co.jp |
| パス | /tech/ |
「パスベースのルーティング」には、
URLにおけるこの「パス」が関係してくるというわけです。
パスベースのルーティングが必要ないケース
ここで、弊社のサーバ構成をごく簡単にご説明します。
簡単すぎますね。
EC2上でwebサーバを動かしており、
そのフロントにはCLBが立っています。
HPや技術ブログの他にも社員ブログ、代表ブログなど様々ありますが、
基本的に同じサーバの同じポート番号で動かしています。
クライアントはwww.simpline.co.jp <何がしかのパス>というURLにアクセスしてくるわけですが、
ここで<パス>が何であっても、
クライアント→hosted zone→CLB→80番ポートに至るまでの経路は全く同じです。
こういった構成においては、パスベースのルーティングは必要ありません。
では一体どういったケースで必要になってくるかというと…
肝心なところは次回に持ち越しです。
以上です。
