【入門編】 AWS Application Load Balancer (ALB) の基本アーキテクチャとレイヤー7ルーティング – クラウド＆コンテナネットワーク実践ガイド

皆さん、こんにちは！第一線でSRE（サイト信頼性エンジニア）をしているクラウドアーキテクトです。

日々、 AWSやKubernetesの海に飛び込み、数え切れないほどのパケットの波を乗りこなしている私ですが、インフラの世界に足を踏み入れたばかりの頃は、専門用語の壁に何度も頭を打ちました。「ロードバランサーって何をする箱なの？」「レイヤー7ってどういうこと？」と、途方に暮れた苦い思い出があります。

この記事に辿り着いたあなたも、もしかしたら今、そんな言葉のシャワーを浴びて「うっ…」となっているところかもしれませんね。でも、安心してください！今回は、AWSの代表的な交通整理役である Application Load Balancer（ALB） の基本アーキテクチャと、L7（レイヤー7）ルーティングの仕組みを、身近な例えを交えて一緒に優しく解きほぐしていきます。

一歩ずつ、確実に理解していきましょう！

—

1. ロードバランサーってそもそも何？（街の郵便局に例えてみよう）

私たちが普段使っているWebサイトには、世界中から一瞬にして膨大なアクセスが集まります。もし、たった1台のサーバーだけでそのすべてを受け止めようとしたらどうなるでしょうか？そう、サーバーはあっという間にパンクしてしまい、サイトがダウンしてしまいますよね。

そこで登場するのが、ロードバランサー（負荷分散装置）です。

これを現実世界で例えるなら、「超優秀な総合案内所」や「街の大きな郵便局」のようなものだと思ってください。

あなたが送った手紙（Webサイトへのリクエスト）は、まず郵便局の窓口に届きます。
窓口のスタッフ（ロードバランサー）は、手紙の宛先を見て、「あ、この手紙は裏の倉庫番のA君に渡そう」「こっちは別のチームのB君のところだね」と仕分けをし、忙しさが偏らないようにバランスよく仕事を割り振ります。

AWSの世界では、この「超優秀な窓口」が自動で何台にも増え、どんなにアクセスの嵐が来てもビクともしない仕組みになっています。その中でも、特にWebアプリの交通整理に特化したのが ALB なのです。

—

2. ALBの心臓部：「レイヤー7（アプリケーション層）」ってなに？

ネットワークの世界にはOSI参照モデルという、通信の仕組みを7つの階層（レイヤー）に分けた考え方があります。

「うわ、出たよ専門用語…」と思わないでください！ここも身近な例えでサクッとクリアしちゃいましょう。

レイヤー4（L4 / トランスポート層）： 封筒の「宛先住所」と「差出人」だけを見て、届ける層。中身のの手紙が「ラブレター」なのか「請求書」なのかは気にしません。これが AWS の NLB（Network Load Balancer） です。
レイヤー7（L7 / アプリケーション層）： 封筒をペリッと開封して、中の「手紙の本文（HTTPのルール）」までしっかり読んで判断する層。これが今回の主役、ALB です。

ALBはレイヤー7で動作するため、ただの「住所（IPアドレス）」だけでなく、次のような「手紙の細かいリクエスト内容」まで読み取ることができます。

1. URLのパス（道順）： https://example.com/images/... なら画像専用のサーバーへ、/api/... ならAPI用のサーバーへ送る。
2. HTTPヘッダー情報： 「おや、このアクセスはスマホのブラウザから来ているな」「このクッキー（Cookie）を持っている人はVIP専用のサーバーへ案内しよう」といった判断。

つまり、ALBはただの交通整理のお巡りさんではなく、「お客様の要望を細かくヒアリングして、最適な専門スタッフへご案内する一流コンシェルジュ」なのです。

—

3. ALBの基本アーキテクチャ：トラフィックが流れるリアルな軌跡

では、実際にユーザーのブラウザから送られたパケットが、どのようにALBを通り、バックエンドのサーバー（EC2やECSなど）に届くのか、その旅路を見てみましょう。

[ ユーザー (ブラウザ) ]
       │
       ▼ (HTTPSリクエスト: https://example.com/shop)
 [ AWS ALB (リスナーで受け取る) ]
       │
       ├─ (パスが "/shop" なら) ──► [ EC2サーバー群 A (ショッピング担当) ]
       └─ (パスがそれ以外なら) ──► [ EC2サーバー群 B (通常サイト担当) ]

① リスナー（Listener）が待ち構える

ALBには、入り口となる「リスナー」という設定があります。「ポート443（HTTPS）で待ち受けてくださいね」という指示をここで受け、ユーザーからのリクエストを最初にキャッチします。

② ターゲットグループ（Target Group）へパスポートを渡す

ALBの後ろには、実際にアプリを動かしているサーバーたちの集まりである「ターゲットグループ」が控えています。
ALBは、受信したリクエストをどのターゲットグループに流すべきかを、あらかじめ設定されたルーティングルールに従って瞬時に決定します。

—

4. 実務で役立つ！L7ルーティングの設定イメージ

言葉だけではイメージしづらいと思いますので、AWSのインフラを構築するときに私たちがよく書く、代表的なL7ルーティングのイメージを見てみましょう。

例えば、AWSのCLIやCloudFormation、Terraformなどでは、次のようなルールを定義します。

{
  "ListenerArn": "arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:listener/app/my-alb/...",
  "Rules": [
    {
      "Priority": "10",
      "Conditions": [
        {
          "Field": "path-pattern",
          "Values": ["/images/*"]
        }
      ],
      "Actions": [
        {
          "Type": "forward",
          "TargetGroupArn": "arn:aws:elasticloadbalancing:...:targetgroup/image-servers/..."
        }
      ]
    },
    {
      "Priority": "20",
      "Conditions": [
        {
          "Field": "host-header",
          "Values": ["api.example.com"]
        }
      ],
      "Actions": [
        {
          "Type": "forward",
          "TargetGroupArn": "arn:aws:elasticloadbalancing:...:targetgroup/api-servers/..."
        }
      ]
    }
  ]
}

設定のポイント解説

パスベースルーティング (/images/*): URLの後半に /images/ が含まれるリクエストだけをキャッチして、画像専用の高速なサーバー群 (image-servers) へシュートします。
ホストヘッダーベースルーティング (api.example.com): アクセスされたドメイン名自体を見て、API専用のバックエンド (api-servers) へ綺麗に交通整理を行います。

このように、1台のALBの背後に全く異なる役割を持つ複数のサーバー群を配置できるため、マイクロサービスのようなモダンなシステム構成にはなくてはならない存在なのです。

—

5. まとめと現場からのエール

今回は、AWS Application Load Balancer（ALB）の基本アーキテクチャと、レイヤー7ルーティングの仕組みについて、身近な例えを交えて解説しました。

ALBはL7（アプリケーション層）で動く優秀なコンシェルジュ。
URLのパスやドメイン名、ヘッダーの中身まで覗き見して、適切なサーバーへ案内してくれる。
1つの入り口（ALB）で、複数のシステムやサービスへ綺麗にトラフィックを振り分けられる。

インフラやネットワークの世界は、最初は見えないパケットばかりで難しく感じるかもしれません。でも、一つひとつの機能を「現実世界のどんな役割と同じかな？」と置き換えて考えてみると、驚くほどすんなりと頭に入ってきます。

焦らず、一歩ずつ、あなたのペースで知識を積み上げていってくださいね。現場のSRE仲間として、あなたのクラウドエンジニアライフを心から応援しています！