ALBの「急激なトラフィック増」に潜む罠：自動スケーリングの限界とウォーミングの真実
SREの現場で、夜中に鳴り響くアラートほど心臓に悪いものはありません。特に、マーケティング担当が打ち出した「突発的なキャンペーン」や「SNSでの予期せぬバズ」によるトラフィック急増（スパイク）は、準備不足のインフラをいとも簡単に沈黙させます。
AWSの Application Load Balancer（ALB）は、マネージドサービスとして非常に優秀ですが、「魔法のように無限に拡張する」という幻想を抱いていると、本番環境で痛い目を見ます。 今日は、ALBのスケーリング挙動の「裏側」と、現場で生き残るための生存戦略について、泥臭い知見を共有しましょう。
—
1. ALBのスケーリングの「裏側」：なぜ即座に対応できないのか
ALBは、トラフィックの変動に応じて自動的にキャパシティを拡張・縮小します。しかし、これは「瞬時に」起こるものではありません。
ALBは内部的に、リクエスト数や接続数、新着接続レートを監視し、必要に応じてノード（AZごとのインスタンス）を増強します。重要なのは、「ALBのキャパシティはステップ単位で増える」という点です。
突発的なスパイクで何が起きるか
急激なリクエスト増が発生すると、ALBは「あ、これじゃ足りないな」と判断してスケールアウトを開始します。しかし、新しいキャパシティが準備されるまでの数分間、ALBはリクエストを処理しきれず、503 Service Unavailable を返却し始めます。
これは、ALBの制御プレーンが動的にリソースを割り当てる際の物理的な物理的遅延です。いわゆる「ウォームアップ」が終わるまでは、ALB自体がボトルネックになるのです。
—
2. 実践：大規模トラフィックが見えているなら「事前ウォーミング」を
もし、あなたがセール開始時刻やイベントの告知を把握しているなら、AWSサポートに連絡して「事前ウォーミング（Pre-warming）」を依頼するのが、シニアエンジニアの嗜みです。
AWS側で該当のALBに対して、あらかじめ十分なキャパシティを確保しておくことで、スパイク発生時の 503 エラーを防ぎます。
依頼時に伝えるべき必須項目
AWSサポートへのチケットには、以下の情報を正確に記載してください。これがないと、担当者も何をすべきか判断できません。
- ALBのARN: 対象のロードバランサーを一意に特定するため。
- 開始・終了日時: UTCで正確に指定する（日本時間ではないことに注意）。
- 予想されるピークリクエスト数（RPS）:
10,000 RPSなのか100,000 RPSなのか。 - トラフィックのパターン: 緩やかな増加か、それとも瞬間的なスパイクか。
—
3. デバッグと検証：今のALBが耐えられるかを知るには
「今の設定でどれくらい耐えられるのか？」を確認するための、現場でよく使う検証コードを紹介します。負荷試験ツール（Locustやk6）を使うのが定石ですが、まずは手元で確認する際のロジックを把握しましょう。
Pythonによるレスポンス監視コード
単純な curl よりも、接続エラーや 503 を検知して記録するスクリプトを走らせるのが安全です。
import requests
import time
# 負荷テスト対象のALBエンドポイント
TARGET_URL = "https://api.example.com/health"
def check_alb_status():
try:
response = requests.get(TARGET_URL, timeout=2)
# 503エラーはALBがキャパシティ不足の際に出す典型的なコード
if response.status_code == 503:
print(f"[{time.ctime()}] ALERT: 503 Service Unavailable detected!")
else:
print(f"[{time.ctime()}] Status: {response.status_code}")
except requests.exceptions.RequestException as e:
print(f"[{time.ctime()}] Error: {e}")
# 1秒ごとにリクエストを投げて挙動を監視
while True:
check_alb_status()
time.sleep(1)—
4. インフラ屋としての備え：設計段階でのTips
事前のウォーミングだけでなく、アプリケーションとインフラの設計でも守りを固めておきましょう。
- コネクションの再利用:
HTTP/1.1の Keep-Alive を活用し、ALBとターゲット間の接続を維持してください。接続のたびにTCP/TLSハンドシェイクが発生すると、ALBの負荷は跳ね上がります。
- 固定IPの活用:
もしクライアント側でIP制限を行っているなら、NLB（Network Load Balancer）をALBの前に置く「ALB + NLB」構成を検討してください。NLBは極めて高いスループットを瞬時に処理でき、ALBの負荷を分散させるクッションとして機能します。
- CloudWatchアラートの精緻化:
RequestCount だけを見ていると手遅れです。TargetConnectionErrorCount や HTTPCode_Target_5XX_Count を組み合わせて、ALBが悲鳴を上げる兆候を早期に検知できるようにしましょう。
設定例：CloudWatchアラームの設計方針
# CloudWatch Alarm定義の概念
Target5XXAlarm:
Type: AWS::CloudWatch::Alarm
Properties:
AlarmDescription: "ALBのターゲット側での5XXエラーが閾値を超えたら発報"
MetricName: HTTPCode_Target_5XX_Count
Namespace: AWS/ApplicationELB
Statistic: Sum
Period: 60
Threshold: 50 # 1分間に50回以上の5XXが出たら即座にアラート
EvaluationPeriods: 1—
最後に：完璧なシステムは存在しない
どれだけ完璧に設計しても、想定外のトラフィックは必ず発生します。だからこそ、「ALBがスケールするまでの数分間をどう凌ぐか」という視点が重要です。
CDN（CloudFront等）でのキャッシュ戦略を最大化し、ALBまでリクエストを到達させないこと。それが、最も安価で、かつ確実な「スケーリング対策」であることを忘れないでください。
現場からは以上です。今日もパケットを安全に送り届けましょう。
コメント