はじめに
この記事では、ALBのルーティングとリスナールールについてまとめています。（AWS：クラウドプラクティショナーレベル）
概要：ALBのルーティングについて
前提として、システムは基本的に担当機能ごとにサーバー群を定義しています。
例えば、googleでいうと「Geminiを担当するサーバー群」「Gmailを担当するサーバー群」などです。
そして、私たちユーザーがシステム宛に「Geminiを使いたいよ」「Gmail使わせて」とリクエストを送ったとき、システムはリクエストの中身を見て各サーバー群に振り分けます。
ALB(Application Load Balancer)はこの振り分け機能を持っています。例えばリクエストデータのURLの中身を見たり送信元IPアドレスの値を見たりしています。
ここで、各サーバー群に振り分けることを「ルーティング」といいます。
ルーティング対象のサーバー群を「ターゲットグループ」といいます。
何を基にルーティングをするかの基準（URL,送信元IPアドレスなど）を「リスナールール」といいます。
具体的には以下のようなリスナールールがあります。
①URLの値を見て決める
(1)ホストベース
(2)パスベース
(3)クエリ文字列ベース
②メタデータを見て決める
(1)HTTPリクエストヘッダベース
(2)送信元IPアドレスベース
以下、各リスナールールの詳細について記載しています。
①URLの値を見て決める
「gemini.google.com」や「google.com/flight」など、私たちがアドレスバーに打ち込むURLの名前を見て判断します。
(1)ホストベースルーティング(2)パスベースルーティング(3)クエリ文字列ベースルーティングがあります。
(1)ホストベースルーティング
前提：ドメインの構成
ホストベースルーティングでは、サブドメインを見て判断します。
そもそもサブドメインとは何かですが、下記画像の一番左側がサブドメインです。
補足的な意味合いになりますが、ドメインの各要素についても説明していきます。
①トップレベルドメイン：
地域・用途を意味します。例えば以下のようなトップレベルドメインがあります。
- com→世界中の人が取れる一般的なもの
- jp→日本に住所を持っている人・会社が取れるもの
- org→非営利団体がよく使うもの
②セカンドレベルドメイン：
各人、各社が自由に命名できるドメインです。アイデンティティみたいなものです。
③サブドメイン
②の中のどの領域かを示したものです。例えば、
- 「gemini.google.com」→「googleのgeminiを担当している領域」
- 「mail.google.com」「googleの中の、gmai.を担当している領域」
というように、②を細分化したうちのどの領域を担当しているの？を示しているところです。
※ちなみに
日本の会社の場合、トップレベルドメインの次に「co」をつけることもあります。(例：rakuten.co.jp)
これは「公式に法人としての存在が認められてますよ〜」の証です。
「co」がついたら、ドメイン内各パーツ定義は以下のようにずれこみます。
トップやらセカンドやらの名前は右から何番目かを表しているんだな〜」ぐらいで理解しておけば問題ないかと思います。
「サブドメインは右部分をもっと細分化した内の一つを表しているんだ」が重要です。
ホストベースルーティングとは
以上を踏まえて、ホストベースルーティングは、サブドメインの値をリスナールールとしてルーティングします。
例えば、「gemini.google.com」だったら、google内のgeminiを担当しているターゲットグループに振り分けますし、「mail.google.com」だったら、google内のgmailを担当しているターゲットグループに振り分けます。
(2)パスベースルーティング
サブドメインでなくパスでドメインを細分化することもあります。
例えば、以下のようなドメインです。
google.com/flight
google.com/maps
この場合はパスを見てルーティングをします。
google.com配下のパス「flight」をみてflightを担当するターゲットグループにつなげたり、
google.com配下のパス「maps」をみてmapsを担当するターゲットグループにつなげたりします。
(3)クエリ文字列ベース
URLのさらに後ろにある、? から始まる検索条件などのパラメータ（クエリ文字列）を見て振り分ける方法です。
例えば、example.com/search?plan=premium のように、URLの末尾に plan=premium（プレミアムプラン）という文字が含まれている場合だけ、「めちゃくちゃ処理が速い高性能なターゲットグループ」へ優先的にアクセスを流す、といった特別扱いができます。
②メタデータを見て決める
HTTPリクエストのヘッダ情報など、URLではわからない値を見て判断します。
(1)HTTPリクエストヘッダベースルーティング、(2)送信元IPアドレスベースルーティングがあります。
(1)HTTPリクエストヘッダベースルーティング
前提
HTTPリクエスト(このwebサイト見せてほしいな〜という要求)は「HTTPリクエストライン」、「HTTPヘッダ」、「HTTPボディ」の3つで構成されています。
①リクエストライン：リクエストの主文。
「端的に言って、どこに対して何をしたいのか」が書かれているところです。
例えば、以下がリクエストラインです。
GET /index.html HTTP/1.1
これは3つの要素で構成されています。
- GET⋯何をしたいのかの「動詞」の部分を示します。GET→参照する(SELECT)、POST→作成する(INSERT)、PUT→更新する(UPDATE)、DELETE削除する(DELETE)といったイメージです。
- /index.html⋯どの資源を触るかを示します。
- HTTP/1.1⋯「このHTTPバージョンで今通信をしていますよ、これからもこのバージョンで通信を希望します。」を示しています。バージョンが合わないと相手が何を言っているかわからない状態になります。言語指定をしているイメージです。
②リクエストヘッダ：詳細情報
リクエストラインに添えて、「ちなみに私はこういう者ですよ」と自分の属性を伝えているところです。
例えば、以下のような項目があります。
Accept: text/html
Accept-Language: ja
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0
(Windows NT 10.0; Win64; x64)…Chrome/147.0.0.0
Host: auctions.yahoo.co.jp
Connection: Keep-Alive
- Accept⋯どの形式のデータファイルが欲しいか。上記だったら「htmlファイルが欲しいっすわ〜」と要求しています。
- Accept-Language⋯希望言語
- Accept-何で圧縮したファイルなら解凍できるか。受信ファイルは基本的に圧縮されているので解凍作業が必要です。(通信量を減らすため)
- User-Agent⋯なんのOS・ブラウザか。上記だったらWindowsOS・Chromeから送信してますよと申告しています。
- Host:接続対象のドメイン名
- Connection⋯接続状態の指定。Keep-Aliveはデータを貰ったからといってすぐに切断せず繋いだままにしてほしいという要求です。
③リクエストボディ
サーバーへ更新・登録する場合の、更新・登録データが格納されているところです。
例えば、サーバーへログインのリクエストをするとき、リクエストボディに「ユーザーID」「パスワード」を格納します。
HTTPリクエストヘッダベースルーティングとは
以上の各項目の値を使ってルーティングするのが、HTTPリクエストヘッダベースルーティングです。
例えば、iphoneやAndroid端末からのリクエストの場合、スマホ専用のサーバー群に繋げる、などのルーティング方法があります。
(2)送信元IPアドレスベースルーティング
アクセスしてきたユーザーのIPアドレスを見て振り分ける方法です。
具体例（社内限定アクセスや海外ブロック）:
「会社のオフィスのIPアドレス（例: 192.0.2.1）からのアクセスだったら、開発中のテストサーバー群へ流す」「それ以外の一般のIPアドレスなら、通常の本番サーバー群へ流す」といった、簡易的なセキュリティ制限のような使い方ができます。