こんにちは！SREとして日夜クラウドの海を泳いでいるライターの私です。
AWSのインフラを触り始めると、必ずと言っていいほどお世話になるのが「ロードバランサー（ALB: Application Load Balancer）」ですよね。一つのWebサイトやシステムを作るとき、「画像系のリクエストは専用のサーバー群へ」「APIへのリクエストは別のシステムへ」と、交通整理をしたくなるシーンは本当によくあります。
今回は、そんなALBの花形機能である「ホストヘッダーベースルーティング」と「パスベースルーティング」について、難しい専門用語の裏側にある「リアルな仕組み」を、身近な例えを交えながら一歩ずつ紐解いていきたいと思います。
インフラの世界へ一歩を踏み出したばかりの方も、どうぞ肩の力を抜いてリラックスして読み進めてくださいね！
—
郵便配達で例える「ロードバランサー」の役割
まず、ALBがやっている仕事を私たちの身近な世界に置き換えてみましょう。イメージしやすいのは「巨大な郵便局の仕分けセンター」です。
世界中（インターネット）から、毎日膨大な数の「手紙（HTTPリクエスト）」が届きます。もし仕分けセンターが一つしかなかったら、センターは大パニックになってしまいますよね。そこで登場するのがロードバランサーです。
ロードバランサーは、届いた手紙の「宛先」や「封筒の表書き」をチラッと確認して、次のように適切な部署（ターゲットグループ）へ仕分けて配達してくれます。
- 「この手紙は、あのビル宛てだな。じゃあAチームに渡そう」
- 「こっちは、あそこの倉庫宛ての荷物だな。Bチームのトラックに積んでくれ」
この「宛先を見て仕分ける」賢い仕組みの代表格が、今回解説する2つのルーティング手法なのです。
—
1. ホストヘッダーベースルーティングとは？（宛先の「ビル名」を見る）
ホスト名ってなに？
インターネットでWebサイトを見るとき、ブラウザのURL欄に https://example.com や https://api.example.com のように入力しますよね。この example.com や api.example.com の部分を、ネットワークの世界では「ホスト名」と呼びます。
HTTPリクエストという手紙には、必ず Host というヘッダー（封筒の宛名ラベルのようなもの）に、このホスト名が記されています。
どんなときに使うの？
例えば、ひとつの企業で次のようなサービスを運営しているとします。
1. メインのコーポレートサイト： www.example.com
2. スマホアプリ用のバックエンドAPI： api.example.com
これらふたつのサービスを、まったく異なる裏側のサーバー群（ターゲットグループ）で動かしたいとき、「ホストヘッダーベースルーティング」が力を発揮します。
ALBは届いた手紙の Host ヘッダーを見て、
www.example.comならば ⇒ Webサーバー用ターゲットグループへ！api.example.comならば ⇒ APIサーバー用ターゲットグループへ！
このように、手紙の「宛先（ビル名）」ごとに綺麗に道を分けてくれるのです。
—
2. パスベースルーティングとは？（宛先の「部屋番号やフロア」を見る）
パス（URIパス）ってなに？
ホスト名が「ビル名」だとすれば、URLの後半にある /images/logo.png や /api/v1/users といった部分は、いわば「ビルの何階のどの部屋か」を示すフロアや部屋番号にあたります。これをネットワーク用語で「パス（URIパス）」と呼びます。
どんなときに使うの？
例えば、ひとつのWebサイト（www.example.com）を運営しているとします。このとき、サーバーの負荷やコストを効率化するために、次のような振り分けをしたい場合があります。
/images/*（画像フォルダの中身）へのリクエスト ⇒ 画像専用の高速ストレージや軽量サーバー群へ！/api/*（システムの頭脳部分）へのリクエスト ⇒ ガッツリ処理をするアプリケーションサーバー群へ！- それ以外（通常のHTMLなど） ⇒ 標準のWebサーバー群へ！
このように、同じホスト名（同じビル）の中でも、「どの部屋（パス）へ向かうのか」を見て交通整理をするのが「パスベースルーティング」です。
—
実務でどう設定する？ ALBリスナールールの設計手法
それでは、ここから少しだけ実践的なお話をしましょう。AWSのマネジメントコンソールやTerraform、AWS CLIを使ってALBを設定するとき、私たちは「リスナールール（Listener Rules）」というものを定義します。
郵便配達員に渡す「仕分けのマニュアル」のようなものです。実際のイメージをコードで覗いてみましょう。
設定のイメージ（Terraform風の記述例）
AWSのインフラコードとして広く使われているTerraformでは、リスナールールを次のように記述します。直感的にどんなルールか読み取れるはずですよ。
# ALBのリスナールール（ポート443: HTTPS通信の仕分け）の設定例
resource "aws_lb_listener_rule" "example_routing" {
listener_arn = aws_lb_listener.https.arn
priority = 10 # 優先順位（数字が小さいほど先にチェックされます）
# 条件（Condition）：どんな手紙をキャッチするか？
# 1. ホストヘッダーベースの条件
condition {
host_header {
values = ["api.example.com"] # 「api.example.com」宛てのリクエストなら...
}
}
# 2. パスベースの条件（ホスト名とパスを組み合わせることも可能です！）
condition {
path_pattern {
values = ["/v1/payments/*"] # さらに「/v1/payments/」以下のパスだったら...
}
}
# アクション（Action）：どこへ転送するか？
action {
type = "forward"
target_group_arn = aws_lb_target_group.payment_servers.arn # 決済専用のターゲットグループへGO！
}
}ここで非常に重要なポイントが一つあります。それは「ルールの優先順位（Priority）」です。
郵便の仕分けと同じで、ルールは上から（優先度の数字が若い順に）順番にチェックされます。もし「すべてのリクエストを受け入れるルール」を一番上に書いてしまうと、その下の細かいルール（画像用やAPI用のルール）に手紙が届く前にすべて吸い取られてしまいます。
実務でインフラを構築するときは、「より具体的で細かい条件（例: api.example.com かつ /v1/payments/*）」を高い優先度（若い番号）に設定し、「最後にすべてを受け止めるデフォルトルール（Catch-all）」を一番下に配置するのが鉄則です。この順番を間違えると、「なぜか画像が表示されない！」といったドタバタ劇（トラブル）に繋がるので、本当に気をつけてくださいね。
—
まとめ：一歩ずつ、確実に理解を深めよう
いかがでしたでしょうか？
今回は、ALBのホストヘッダーベースルーティングとパスベースルーティングについて、郵便配達の仕組みに例えながら解説しました。
- ホストヘッダーベースルーティング：
api.example.comやwww.example.comといった「ドメイン名（ビル名）」で宛先を分ける。 - パスベースルーティング：
/images/*や/api/*といった「URLのパス（部屋番号）」で宛先を分ける。
一見すると難しそうなクラウドのネットワーク用語も、私たちが普段暮らしている現実世界の仕組みに置き換えてみると、スッと頭に入ってくるはずです。
「難しそうだな」と身構えてしまう技術も、一歩ずつ分解して眺めていけば、必ず自分の血肉になります。焦らず、楽しみながら、一緒に最高のインフラストラクチャを作っていきましょう！
それでは、また次回の技術解説でお会いしましょう！SREライターの私でした。
コメント