🍽️ レストランの厨房チームで例えると超わかりやすい！
ALB（Application Load Balancer）= レストランの案内係
ターゲットグループ = 厨房チーム
お客様（リクエスト）が来たら、案内係（ALB）が
適切な厨房チーム（ターゲットグループ）に注文を振り分けます。
和食チーム、洋食チーム、デザートチーム...
どのチームに注文を振り分けるか
を決めるのがターゲットグループです✨
🏪 レストラン = AWS構成図
💡 ポイント：
案内係（ALB）は「和食が食べたい」というお客様を和食チームへ、
「パスタが食べたい」というお客様を洋食チームへ振り分けます。
各チーム（ターゲットグループ）には複数のシェフ（EC2等）がいて、
手が空いているシェフに順番に注文を回します！
🎪 3種類のターゲットタイプ
毎日出勤する固定メンバー。厨房の設備をフル活用できる。
別の場所にいるシェフに住所（IP）を指定して配達依頼。
注文があった時だけ稼働。設備維持費ゼロの魔法の厨房！
🔄 リクエストの流れを図解
リスナー（ポート80/443）
💓 ヘルスチェック = シェフの体調確認
🍽️ レストランの例え：
店長が定期的に各シェフの体調を確認。
「元気ですか？」→「はい！」なら注文を回す。
体調不良なら休ませて、他のシェフに注文を回す。
これがALBの
ヘルスチェック
です！
ヘルスチェックパス
インターバル
正常しきい値
非正常しきい値
成功コード
タイムアウト
🎲 ルーティングアルゴリズム = 注文の振り分け方
Round Robin（ラウンドロビン）
1番目の注文→シェフA
2番目の注文→シェフB
3番目の注文→シェフC
4番目の注文→シェフA...
特徴： シンプルで均等に分散。デフォルト設定。
Least Outstanding Requests
シェフA: 注文3件処理中
シェフB: 注文1件処理中 ← ここへ！
シェフC: 注文2件処理中
特徴： 処理時間にばらつきがある場合に効果的。
Weighted Random
シェフA（ベテラン）: 50%
シェフB（中堅）: 30%
シェフC（新人）: 20%
特徴： サーバースペックに差がある場合に有効。
🍪 スティッキーセッション = 指名制度
💡 スティッキーセッションとは：
同じお客様は、必ず同じシェフ（サーバー）が担当する仕組み。
「田中さんの好みは佐藤シェフが一番わかってる」→ 毎回同じ担当に！
ショッピングカートやログイン状態の維持に必須の機能です。
例： ログインセッションIDなど、アプリ側で管理するCookieを使用。
向いているケース： 既存のセッション管理がある場合
例： 1時間、1日など期間を指定。
向いているケース： シンプルに実装したい場合
📊 ターゲットタイプ比較表
| 項目 | Instance | IP | Lambda |
|---|---|---|---|
| 対象リソース | EC2インスタンス | 任意のIPアドレス | Lambda関数 |
| 指定方法 | インスタンスID | IPアドレス | Lambda ARN |
| Auto Scaling連携 | ✅ 簡単 | ⚠️ 手動設定 | ✅ 不要 |
| オンプレミス対応 | ❌ 不可 | ✅ 可能 | ❌ 不可 |
| 他VPCへのルーティング | ❌ 不可 | ✅ 可能 | ❌ 不可 |
| コンテナとの相性 | △ 可能 | ✅ 最適 | ❌ 不可 |
| サーバーレス | ❌ 不可 | ❌ 不可 | ✅ 完全対応 |
| 推奨用途 | 一般的なWebアプリ | ハイブリッド/コンテナ | APIバックエンド |
💼 ユースケース別：最適な設定は？
ECサイト
モバイルアプリAPI
マイクロサービス（ECS/EKS）
ハイブリッドクラウド
/healthや/api/healthなど、軽量で高速に応答するエンドポイントを用意。DBアクセスなど重い処理は避ける。
2. 登録解除遅延（Deregistration Delay）を適切に設定：
デフォルト300秒は長すぎることも。処理中のリクエストが完了する時間を考慮して設定（30〜60秒が一般的）。
3. スローアウォーミング期間を活用：
新しいターゲットに徐々にトラフィックを増やす設定。急激な負荷を避けられる。
4. クロスゾーン負荷分散を有効に：
複数AZに均等にトラフィックを分散。一部AZの障害時も他AZで処理継続。
5. CloudWatchでターゲットの状態を監視：
HealthyHostCount、UnHealthyHostCountのアラームを設定。障害を早期発見！
# ターゲットグループの作成 aws elbv2 create-target-group \ --name my-app-targets \ --protocol HTTP \ --port 80 \ --vpc-id vpc-12345678 \ --target-type instance \ --health-check-protocol HTTP \ --health-check-path /health \ --health-check-interval-seconds 30 \ --healthy-threshold-count 2 \ --unhealthy-threshold-count 2 # ターゲットの登録 aws elbv2 register-targets \ --target-group-arn arn:aws:elasticloadbalancing:... \ --targets Id=i-1234567890abcdef0 Id=i-0987654321fedcba0 # スティッキーセッションの有効化 aws elbv2 modify-target-group-attributes \ --target-group-arn arn:aws:elasticloadbalancing:... \ --attributes Key=stickiness.enabled,Value=true \ Key=stickiness.type,Value=lb_cookie \ Key=stickiness.lb_cookie.duration_seconds,Value=3600
🎓 まとめ
🍽️ レストラン = ALB構成
ターゲットグループは
「どのシェフチームに注文を回すか」
を決める仕組み！
適切な設定で、安定したサービス提供を実現しましょう✨
Auto Scalingと相性◎
コンテナ・ハイブリッド向け
コスト最適化
軽量エンドポイント推奨
EC・ログインに必須
🎯
ターゲットグループのポイント：
用途に合ったターゲットタイプを選び、
ヘルスチェックで障害を早期発見、
スティッキーセッションでユーザー体験を向上させよう！🚀