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

ALBはただのロードバランサーにあらず：L7で制御する「賢いトラフィック制御」の深淵

こんにちは。現場で夜通しパケットキャプチャを眺めながら、ネットワークの深淵と戦っているエンジニアです。

今日は、AWSのインフラ設計における「必須科目」でありながら、意外とブラックボックスになりがちな Application Load Balancer (ALB) について掘り下げていきます。単に「リクエストを振り分ける箱」として使っていませんか？ ALBの本質は、OSI参照モデルのレイヤー7（アプリケーション層）でHTTP/HTTPSを解釈し、インテリジェントに交通整理を行う「プロキシ」であるという点にあります。

この仕組みを理解しているか否かで、障害発生時の切り分けスピードが天と地ほど変わります。

—

1. ALBの「脳内」：L7インスペクションの仕組み

ALBは、クライアントからのTCPコネクションを一度終端（Termination）します。つまり、ALBはクライアントと「握手」をした後、内部的にバックエンドのターゲット（EC2やFargateなど）と別のTCPコネクションを張り直す構造です。

この「終端」こそが、ALBがただのL4（NLBなど）と一線を画すポイントです。一度HTTPリクエストをバッファリングし、中身を解釈できるからこそ、以下の処理が可能になります。

Hostベースルーティング: api.example.com と web.example.com を同じALBで受け分ける。
Pathベースルーティング: /api/v1/ はマイクロサービスAへ、/images/ はS3経由で配信するなど。
HTTPヘッダー操作: X-Forwarded-For の付与や、X-Amzn-Trace-Id によるトレース。

—

2. 実務で直面するHTTP通信フロー

私たちが何気なく叩く curl コマンドの裏側では、ALBが高度な判断を下しています。

# 現場でよく使う、ALB経由のトレース確認コマンド
curl -v -H "Host: api.example.com" https://my-alb-12345.ap-northeast-1.elb.amazonaws.com/api/v1/users

このコマンドを打った瞬間、ALBの内部では以下のシーケンスが走っています。

1. クライアント → ALB: TLSハンドシェイクが完了。HTTP GETリクエストがALBに届く。
2. ALBのリスナールール評価: 設定された「優先順位」に基づき、リクエストを解析。Host ヘッダーが api.example.com かつパスが /api/v1/ であることを確認。
3. ターゲットグループへの転送: 紐付いたターゲットグループ（TG）の健全なインスタンスをアルゴリズム（Round Robin等）で選出。
4. ALB → ターゲット: X-Forwarded-For 等のヘッダーを付与してリクエストを転送。

—

3. 設定の肝：リスナールールの優先順位と「デフォルトルール」

ALBの運用で最も多いミスが「ルールの優先順位設定」です。ALBのルールは上から順に評価され、マッチした瞬間に処理を確定します。

よくある構成例（Terraform/AWS CLI想定）

もし /api/v1/ へのルーティング設定を、デフォルトルール（全てのパスを拾うルール）よりも下に書いてしまうと、永遠に意図したターゲットに届きません。

# ルール優先順位の考え方
resource "aws_lb_listener_rule" "api_rule" {
  listener_arn = aws_lb_listener.front_end.arn
  priority     = 10 # 数字が小さいほど優先される

  action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.api_tg.arn
  }

  condition {
    path_pattern {
      values = ["/api/*"]
    }
  }
}

—

4. 現場の教訓：ALBトラブルシューティングの極意

「ALBが503を返しているが、バックエンドは生きているように見える」といった相談をよく受けます。そんな時は、迷わず以下の点を確認してください。

ターゲットグループのヘルスチェック: HTTP 200 OK 以外のコードを返していないか？
Tips: ヘルスチェックのパスは、単なる / ではなく、DB接続チェックを含まない「軽量な疎通確認エンドポイント」を専用に用意するのが鉄則です。
セキュリティグループ（SG）の穴: ALBからターゲットへの通信（ポート80/8080等）がSGで許可されているか？意外と忘れがちですが、ALBのIDを参照するSGルールにするのがベストプラクティスです。
クライアントのタイムアウト: ALBはデフォルトで60秒のアイドルタイムアウトを設定しています。Web APIで重いバッチ処理を叩く場合、504 Gateway Timeout が出ることがあります。その際はターゲット側ではなく、ALBの設定変更が必要です。

Pythonによるレスポンスヘッダー確認（デバッグ用）

ALBが正しくリクエストを処理しているか、HTTPレスポンスを確認する小さなスクリプトです。

import requests

# ALBのURL
url = "https://my-alb-12345.ap-northeast-1.elb.amazonaws.com/api/health"

try:
    response = requests.get(url, timeout=5)
    # X-Amzn-Trace-Id を確認することで、ALBのどのノードを通ったか追跡可能
    print(f"Status: {response.status_code}")
    print(f"Trace ID: {response.headers.get('X-Amzn-Trace-Id')}")
except requests.exceptions.RequestException as e:
    print(f"通信エラー: {e}")

—

最後に：ALBを「ただの通過点」にしないために

ALBは単なるL7スイッチではありません。WAF（Web Application Firewall）を統合すればセキュリティの要になりますし、リクエストの正規化を行うことで、バックエンドのアプリケーションコードをクリーンに保つ役割も担います。

「なぜこのリクエストがここに飛ぶのか？」をパケット単位で想像できるようになれば、あなたはもう一人前のインフラエンジニアです。現場で困ったときは、まずはALBの Access Log を眺めてみてください。そこに、全ての真実が記録されています。

次回は、より高トラフィックを捌くための「NLBとALBの使い分け（ハイブリッド構成）」について深掘りしましょう。それでは、良いクラウドライフを！