はじめに
「ALBの前にEC2が2台あって、トラフィックを分散してくれる」——これが3年間の私のALB理解でした。
使えていました。設定もできていた。でも「ヘルスチェックの仕組みを説明してください」「スティッキーセッションとは何ですか？」と聞かれると答えられなかった。
ある障害対応で「ALBのターゲットが全部unhealthyになっています」という状況になったとき、「unhealthyって何が起きているのか」を正確に説明できなかったことが、理解を深めるきっかけになりました。
この記事は、ALBの構成要素を「なんとなく」から「説明できる」レベルに整理したものです。
この記事を読むと、以下のことができるようになります。
- ALBの構成要素（リスナー・ルール・ターゲットグループ）の役割が理解できる
- ヘルスチェックの仕組みと、unhealthyになる原因の切り分けができる
- スティッキーセッションやパスベースルーティングの使い所が分かる
ALBの全体構造
ALB（Application Load Balancer）は、受け取ったリクエストを複数のバックエンドサーバーに振り分けるサービスです。
ALBは3つの要素で構成されます。
| 要素 | 役割 |
|---|---|
| リスナー | どのポート・プロトコルで待ち受けるかを定義 |
| ルール | リクエストの条件（パス・ヘッダーなど）に応じて転送先を決定 |
| ターゲットグループ | 実際にリクエストを受け取るEC2・Lambdaなどのグループ |
リスナーとルールの仕組み
リスナーは「このポートで受け付けます」という定義です。HTTP（80番）やHTTPS（443番）でリスナーを作ります。
ルールは「このリクエストはここへ転送する」という条件分岐です。
パスベースルーティングの例
条件: パスが /api/* にマッチする → ターゲットグループ: TG-API へ転送
条件: パスが /admin/* にマッチする → ターゲットグループ: TG-Admin へ転送
デフォルト: → ターゲットグループ: TG-Web へ転送
1台のALBで複数のアプリケーションへのルーティングができます。以前は「アプリごとにALBを立てる」という運用を見たことがありますが、パスベースルーティングを使えば1台に集約できます。
ホストベースルーティングの例
条件: ホストヘッダーが api.example.com → TG-API へ転送
条件: ホストヘッダーが www.example.com → TG-Web へ転送
ドメインによって転送先を変えることもできます。
ターゲットグループとヘルスチェック
ターゲットグループは「リクエストを送る先のサーバー一覧＋ヘルスチェック設定」のセットです。
ヘルスチェックとは
ALBはターゲットグループ内のサーバーに対して、定期的にHTTPリクエストを送って「このサーバーは正常に動作しているか」を確認します。これがヘルスチェックです。
ヘルスチェックの設定例：
- プロトコル: HTTP
- パス: /health
- ポート: traffic port（リクエストと同じポート）
- 正常のしきい値: 3回連続成功でhealthy
- 非正常のしきい値: 2回連続失敗でunhealthy
- タイムアウト: 5秒
- 間隔: 30秒
/health というパスにアクセスして、HTTPステータス200が返ってきたらhealthy、返ってこなかったり200以外が返ったらunhealthyと判断します。
unhealthyになる原因
「ALBのターゲットがunhealthyになった」というアラートを受けたとき、確認する順番です。
よくある原因は以下のとおりです。
- アプリのプロセスが落ちている：EC2は起動しているがアプリが落ちている
- セキュリティグループの設定ミス：ALBからのヘルスチェックポートが開いていない
-
ヘルスチェックパスが間違っている：
/healthにアクセスしても404が返る - 起動直後のタイミング：デプロイ直後はアプリが起動中でヘルスチェックが失敗する（猶予期間設定が必要）
スティッキーセッションとは
「スティッキーセッション」を聞いて「何ですか？」となっていた言葉の一つです。
通常のロードバランシングでは、リクエストのたびに異なるターゲットに転送されます。複数台のサーバーにセッション情報が分散するため、セッション管理をサーバー側でしているアプリケーションでは問題が起きることがあります（ログイン状態が次のリクエストで消えるなど）。
スティッキーセッションを有効にすると、同じクライアントからのリクエストを常に同じターゲットに転送し続けます。Cookieを使って「このクライアントはこのサーバーへ」という紐付けを維持します。
ただし、スティッキーセッションは「スケールアウト（サーバーを増やす）の効果が薄れる」「特定のサーバーに負荷が偏る」というデメリットがあります。できればセッション情報をElastiCache（Redis）などに外出しして、どのサーバーが処理しても同じ結果になるアーキテクチャが望ましいです。
HTTPからHTTPSへのリダイレクト設定
ALBでHTTP（80番）へのアクセスをHTTPS（443番）にリダイレクトする設定は、実務でよく使います。
AWSコンソールで設定する場合：
- ロードバランサー → リスナー → HTTP:80 を選択
- ルールの編集 → デフォルトアクション：「リダイレクト先」を選択
- HTTPS / 443 / 301（恒久的リダイレクト）を設定
# CLIでHTTP→HTTPSリダイレクトのルールを確認
aws elbv2 describe-rules \
--listener-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:listener/app/my-alb/xxx/yyy \
--query 'Rules[*].[Priority,Actions[0].Type,Actions[0].RedirectConfig]' \
--output table
まとめ
この記事では以下のことを解説しました。
- ALBは「リスナー（待ち受けポート）」「ルール（転送条件）」「ターゲットグループ（転送先＋ヘルスチェック）」の3要素で構成される
- ヘルスチェックは定期的にHTTPリクエストを送って正常性を確認し、失敗が続くとunhealthyに変わる
- unhealthyの主な原因はアプリプロセスの停止・SGの設定ミス・ヘルスチェックパスの誤り
- パスベース・ホストベースのルーティングで1台のALBから複数のアプリへ振り分けられる
- スティッキーセッションは便利だが、セッション管理の外出しができるなら使わない方がスケーラブル
「ALBの前にEC2が並んでいる」という理解から、「どういうルールでどこに転送しているか」が説明できるようになると、障害対応もトラブルシューティングもずっとスムーズになります。
ハンズオンラボでは、未経験からでも「作って覚える」をモットーにしたITハンズオンイベントを定期開催しています。
面白かったら
「👇いいね」で応援