🍽️ ALBスティッキーセッション

高級レストランのパーソナルサービスで理解する状態保持Webアプリの負荷分散

🏨 高級レストランのパーソナルサービスで理解しよう！

状態保持WebアプリのALBスティッキーセッションを、お客様一人ひとりに専任ウェイターが付く高級レストランのサービスに例えると分かりやすくなります

👤

レストランのお客様

Webユーザー
（ショッピングカート等の状態を持つ）

🧑‍💼

フロントデスク

Application Load Balancer
（お客様を適切なウェイターに案内）

👨‍🍳

専任ウェイター

コンテナインスタンス
（状態を記憶してサービス提供）

🗂️

お客様カルテ

セッション情報
（注文履歴、好み、アレルギー等）

🔗

指名カード

スティッキーセッション
（同じウェイターが継続担当）

🍽️ 高級レストランでのパーソナルサービス体験

👨‍💻
田中様（常連客）

お好みやアレルギー情報をしっかり覚えていてほしい

魚介アレルギー
ワイン好き
前回：フォアグラ
誕生日：来月
🧑‍💼
フロントデスク（ALB）

「田中様、いつものウェイターの佐藤がお待ちしております」

✅ お客様を識別
✅ 適切なウェイターに案内
✅ 継続性を保証
ウェイタースタッフ

各ウェイターが担当客の詳細情報を記憶

👨‍🍳 佐藤
田中様担当
👩‍🍳 鈴木
山田様担当
👨‍🍳 高橋
待機中
👩‍🍳 伊藤
新人研修中
💡 サービスの価値： 田中様は毎回同じウェイターの佐藤に担当してもらうことで、 好みやアレルギーを改めて説明する必要がなく、より質の高い個別サービスを受けられます。

⚠️ スティッキーセッションがない場合の問題

🚨 毎回違うウェイターが担当する場合

お客様の情報が共有されず、毎回一から説明が必要になる問題

1
😔

1回目の訪問

ウェイターA：「アレルギーはありますか？」
お客様：「魚介アレルギーです」

2
😤

2回目の訪問

ウェイターB：「アレルギーはありますか？」
お客様：「また聞くの？魚介アレルギーです」

3
😡

3回目の訪問

ウェイターC：「アレルギーはありますか？」
お客様：「もう来ません！」

4
💸

結果

顧客満足度低下
ショッピングカート放棄
売上機会の損失

⚠️ 技術的な問題： 状態保持アプリで負荷分散すると、リクエストごとに異なるサーバーに振り分けられ、 セッション情報（ログイン状態、ショッピングカート等）が失われてしまいます。

✅ ALBスティッキーセッションによる解決

🎯 専任ウェイター制度の導入

同じお客様は必ず同じウェイターが担当 する仕組みで完璧なサービスを実現

🆔
お客様識別
Cookieで顧客を特定
🔍
担当者確認
ALBが担当ウェイターを検索
➡️
同一サーバー転送
常に同じコンテナに転送
🗂️
状態復元
セッション情報を活用
✨
パーソナルサービス
最適化された体験提供
Session-田中
Container-A 固定
ログイン状態維持
Session-山田
Container-B 固定
カート: 3商品
Session-佐藤
Container-C 固定
決済途中
Session-伊藤
Container-A 固定
商品閲覧履歴
✅ 解決される問題： ユーザーは常に同じコンテナインスタンスに接続されるため、 セッション情報が保持され、ログイン状態やショッピングカートの内容が維持されます。

⚙️ ALBスティッキーセッションの設定方法

🔧 レストランスタッフシステムの設定手順

📋
1. ターゲットグループ設定

レストラン例： ウェイタースタッフのチーム編成

AWS CLI コマンド例
# ターゲットグループ作成
aws elbv2 create-target-group \
--name "restaurant-waiters" \
--protocol "HTTP" \
--port 80 \
--vpc-id "vpc-12345678"
🍪
2. スティッキーセッション有効化

レストラン例： お客様カードによる担当者指定

スティッキーセッション設定
# スティッキーセッション有効化
aws elbv2 modify-target-group-attributes \
--target-group-arn "arn:aws:elasticloadbalancing:..." \
--attributes Key = "stickiness.enabled" , Value = "true" \
Key = "stickiness.lb_cookie.duration_seconds" , Value = "86400"
🎯
3. リスナールール設定

レストラン例： フロントデスクの案内ルール

Terraform設定例
resource "aws_lb_target_group" "restaurant_app" {
name = "restaurant-waiters"
port = 80
protocol = "HTTP"
vpc_id = var .vpc_id
stickiness {
enabled = true
type = "lb_cookie"
cookie_duration = 86400 # 24時間
}
}
📊
4. ヘルスチェック設定

レストラン例： ウェイターの稼働状況確認

ヘルスチェック詳細設定
health_check {
enabled = true
healthy_threshold = 2
unhealthy_threshold = 3
timeout = 5
interval = 30
path = "/health"
matcher = "200"
}

🏗️ システムアーキテクチャ全体図

🎯 スティッキーセッション実装アーキテクチャ

👥

ユーザー

Webブラウザ
（Cookie保持）

AWSALB Cookie
セッション識別子
⚖️

Application Load Balancer

負荷分散 + セッション管理

Cookie確認
ターゲット選択
SSL終端
🐳

ECS/Fargate
コンテナ群

アプリケーション実行環境

セッション状態保持
ビジネスロジック
オートスケーリング

📋 データフロー詳細

1. 初回アクセス
ALBがCookie発行
2. セッション確立
特定コンテナに固定
3. 継続アクセス
同一コンテナに転送
4. 状態維持
セッション情報保持

🔄 スティッキーセッションの代替手法

🛠️ 状態管理の異なるアプローチ比較

🗄️
外部セッションストア

レストラン例： 共有顧客データベース

Redis、DynamoDB等に状態を保存し、どのコンテナからでもアクセス可能

✅ メリット

  • 真の無状態化
  • 高いスケーラビリティ
  • コンテナ障害に強い
❌ デメリット
  • 追加のインフラ
  • ネットワークレイテンシ
  • 実装の複雑性
🍪
クライアントサイド保存

レストラン例： お客様が注文メモを持参

JWT等でクライアント側に状態を保存、サーバーは無状態

✅ メリット
  • サーバー完全無状態
  • インフラ負荷軽減
  • シンプルな構成
❌ デメリット
  • データサイズ制限
  • セキュリティ課題
  • クライアント依存
🔄
ステートレス設計

レストラン例： 毎回新しい注文として処理

アプリケーション自体を無状態に再設計、リクエスト単位で完結

✅ メリット
  • 最高のスケーラビリティ
  • 障害に最も強い
  • クラウドネイティブ
❌ デメリット
  • 大規模な設計変更
  • 開発コスト大
  • 既存資産の破棄
💡 選択指針： スティッキーセッションは短期的な移行戦略として有効ですが、 長期的にはステートレス設計や外部セッションストアへの移行を検討することを推奨します。

🏢 実際の使用ケースと業界別事例

🛒
ECサイト

課題： ショッピングカートの内容が負荷分散で消失

要件： 商品選択からチェックアウトまでの状態維持

解決策： ALBスティッキーセッションで同一コンテナに固定

効果：
• カート放棄率を30%削減
• コンバージョン率15%向上
• ユーザー体験の大幅改善
🏦
オンラインバンキング

課題： 取引途中でセッションが切れるセキュリティリスク

要件： ログイン状態と取引状態の継続保持

解決策： 短時間スティッキーセッション + Redis連携

効果：
• セキュリティ事故ゼロ
• 取引完了率98%達成
• 顧客満足度向上
🎓
オンライン学習プラットフォーム

課題： 学習進捗や回答状況の保持が必要

要件： 長時間の学習セッション中の状態維持

解決策： 24時間スティッキーセッション設定

効果：
• 学習継続率40%向上
• コース完了率25%増加
• システム満足度95%
🎮
オンラインゲーム

課題： ゲーム進行状況やプレイヤー状態の維持

要件： リアルタイム性とセッション継続性

解決策： スティッキーセッション + WebSocket対応

効果：
• 接続切断率70%削減
• プレイ時間20%延長
• 課金率向上

📊 スティッキーセッションのパフォーマンス指標

実際の運用環境での測定データに基づく効果

95%
セッション維持率
30%
カート放棄率削減
15ms
レスポンス時間
99.9%
可用性
10K
同時セッション数
24h
最大セッション時間

⚠️ 注意すべきパフォーマンス要因

コンテナ障害時：
該当ユーザーのセッションが失われる
負荷の偏り：
人気コンテナに負荷集中の可能性
スケーリング制約：
セッション中はコンテナ削除困難
Cookie依存：
Cookieが無効だと機能しない

🎮 インタラクティブデモ：スティッキーセッションの動作確認

ボタンを押して、ALBがどのようにセッションを管理するかを体験してみましょう

ボタンをクリックしてスティッキーセッションの動作を確認してください

Created by SSuzuki1063

AWS SAP Learning Resources