【入門編】 ALBのスケーリング挙動（リクエスト急増時のウォームアップ） – クラウド＆コンテナネットワーク実践ガイド

こんにちは！第一線でクラウドインフラを構築・運用しているSREの「なかのひと」です。

突然ですが、みなさんは「大人気アーティストのライブチケット販売開始」や「年に一度の超特大セール」の瞬間に、Webサイトが重くて繋がらなくなったり、エラー画面が表示されたりした経験はありませんか？

裏側で動いているシステムでは、急激に押し寄せる膨大なアクセス（これを「トラフィックのスパイク」と呼びます）をさばくために、インフラエンジニアたちが冷や汗を流しながら戦っています。

Webサイトへのアクセスを交通整理してくれる超重要コンポーネントが、AWSのALB（Application Load Balancer）です。しかし、このALB、実は「どんな急増アクセスでも、ノータイムで無限に耐えられる魔法の箱」ではないのです。

今回は、ネットワークやインフラに初めて触れるみなさんに向けて、ALBが裏側でどのようにスケール（自動でパワーアップ）しているのか、その仕組みを「郵便局の窓口」に例えながら、優しく、そして現場の泥臭い知見を交えて一歩ずつ紐解いていきます！

—

1. そもそもALBってどんな仕組み？（郵便局の窓口で例えてみよう）

まずは、ALB（ロードバランサー）の役割をイメージしやすい身近な例に置き換えてみましょう。

みなさんが「郵便局」に荷物を出しにいくところを想像してみてください。

【お客さん（アクセス）】 ──> 【受付の案内係（ALB）】 ──> 【処理する窓口（Webサーバー）】
                                      │
                                      ├──> 窓口 A さん
                                      ├──> 窓口 B さん
                                      └──> 窓口 C さん

インターネットの世界でも全く同じことが行われています。

お客さん ＝スマホやパソコンからWebサイトを見にくるユーザー
受付の案内係（ALB） ＝アクセスを交通整理して、空いている窓口へ均等に振り分ける存在
処理する窓口（Webサーバー） ＝実際にWebサイトのデータを返すサーバー（EC2やECSなど）

ここで大事なのが、「案内係であるALB自身も、実は人間（リソース）である」という点です。

多くの人が「ロードバランサーはAWSが提供している無敵のネットワーク設備だから、どれだけアクセスが来ても絶対に壊れない」と思いがちです。しかし、ALBの裏側では、AWSが管理する「小さな案内係のパソコン（内部的な処理ノード）」が実際に動いています。

アクセスが増えてくると、案内係（ALB）自身のキャパシティも限界を迎えるため、「案内係の人数自体を増やす（ALBの自動スケーリング）」という処理が裏側で行われているのです。

—

2. ALBが自動で強くなる「自動スケーリング」の仕組み

アクセスが徐々に増えていくとき、ALBはとてもお利口です。

「おや、なんだかお客さんが増えてきたな。案内係を1人から3人に増やそう！」と、自動的に判断して処理能力をアップしてくれます。

これを専門用語で「自動スケーリング（Auto Scaling）」と呼びます。

具体的には、以下のような流れでALBが自動でパワーアップします。

1. アクセスの増加を検知する
ALBの中を流れるデータ量や接続数が増えてくると、AWSのシステムがそれを検知します。
2. 裏側で新しい「案内係（処理ノード）」を起動する
AWSの裏側で、ALBの役割を持った新しい仮想マシンが静かに立ち上がります。
3. 看板（DNS）を書き換える
インターネット上の案内看板である「DNS（Domain Name System）」の情報が更新され、新しい案内係の場所（新しいIPアドレス）が追加されます。

このプロセスにより、数分から十数分かけて、ALBは大きなアクセスに耐えられるように自動で進化していくのです。

—

3. 「急激なスパイク」が来ると、なぜ耐えられないのか？

「自動で強くなるなら、何も心配いらないじゃないですか！」と思いますよね。しかし、ここに大きな落とし穴があります。それが「急激なスパイク（一瞬でのアクセス急増）」です。

先ほどの郵便局の例で考えてみましょう。

普段は1分間に10人くらいしか来ないのんびりした郵便局に、テレビで紹介された直後、「1秒後に突然、1万人のお客さんが押し寄せた」としたらどうなるでしょうか？

【普段ののんびりした状態】
お客さん（10人） ──> 案内係（1人） ──> 窓口へスムーズに案内

【テレビ紹介直後のスパイク！】
お客さん（1万人！） ──> 案内係（1人） ──> 「ギャー！パンクです！」（503 Service Unavailable エラー）
                              ：
                     （案内係を増やすのに数分かかる…）

案内係を1人から100人に増やすには、デスクを準備したり、スタッフを呼び出したりする「準備時間（ウォームアップ時間）」がどうしても数分間かかってしまいます。

その準備をしている「魔の数分間」の間に押し寄せた数千、数万のお客さんは、案内係にたどり着くことすらできず、入り口でシャットアウトされてしまいます。これが、Webサイトでよく見る 503 Service Unavailable や 504 Gateway Timeout といったエラーの正体です。

—

4. 救世主！「事前ウォーミング（Pre-warming）」とは？

この「起動が間に合わない問題」を解決するために、AWSには「事前ウォーミング（Pre-warming）」という素晴らしい仕組み（制度）が用意されています。

これは一言でいうと、「AWSのサポート窓口に『◯月◯日の◯時に一瞬で大アクセスが来るから、あらかじめ案内係を100人に増やしておいて！』と事前にお願いしておくこと」です。

事前に申請をしておくことで、指定された日時の直前に、AWS側が裏側でALBの処理能力を最大化（事前ウォーミング）しておいてくれます。これにより、イベント開始の「1秒目」に数万アクセスがドカンと来ても、余裕の表情でパケットをさばくことができるのです。

事前ウォーミングが必要になる目安

以下のようなイベントが控えている場合は、迷わず事前ウォーミングを検討しましょう。

テレビ番組（地上波のゴールデンタイムなど）で自社サービスが紹介されるとき
大規模な事前登録キャンペーンの開始時刻
人気商品のフラッシュセール（先着順販売）の開始時刻
全社的な大規模プロモーションメール・プッシュ通知の一斉配信

一般的には、「5分以内に、現在の数倍〜数十倍以上のトラフィック（目安として毎秒数千〜数万リクエスト以上）に急増することが予想される場合」に申請を行います。

—

5. AWSサポートへ事前ウォーミングを申請する方法

事前ウォーミングは、AWSのコントロールパネルからボタンを1つ押せばできるものではありません。AWSサポート（ビジネスプラン以上）へ問い合わせチケットを作成して依頼する必要があります。

申請時には、以下のような技術的なパラメータを伝える必要があります。「一歩ずつ」項目を確認していきましょう！

> 💡 注意点！
> 事前ウォーミングの申請は、イベント開始の「3営業日前」までに行う必要があります。直前だとAWS側も準備が間に合わないため、イベントの日程が決まったら真っ先に申請を出すのが現場の鉄則です。

—

6. 実践！ALBと監視アラームを準備するTerraformコード例

ここからは、実際にインフラを構築するエンジニアのみなさんのために、ALBの基本構成と、ALBが限界を迎えていないかを監視するためのCloudWatchアラームのテンプレートをご紹介します。

モダンなインフラ定義ツールである Terraform を使って書いてみましょう。初心者の方でも理解しやすいように、各設定値に丁寧な日本語コメントを入れています。

# ------------------------------------------------------------------
# 1. 交通整理の主役：Application Load Balancer (ALB) の作成
# ------------------------------------------------------------------
resource "aws_lb" "web_alb" {
  name               = "my-secure-web-alb"
  internal           = false # インターネットからアクセスできるように「外部向け」に設定
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb_sg.id]
  subnets            = [aws_subnet.public_a.id, aws_subnet.public_c.id]

  # 削除保護（本番環境では誤削除を防ぐために true にすることをおすすめします）
  enable_deletion_protection = false

  tags = {
    Environment = "Production"
    Project     = "WarmUpDemo"
  }
}

# ------------------------------------------------------------------
# 2. 監視の目：ALBの「5xxエラー（システムエラー）」を検知するアラーム
# ------------------------------------------------------------------
# もしALB自体がパンクしたり、後ろのサーバーが死んでエラーが多発したら、
# すぐにSlackやメールで通知を受け取れるようにアラームを設定します。
resource "aws_cloudwatch_metric_alarm" "alb_high_5xx_errors" {
  alarm_name          = "alb-high-5xx-error-rates"
  comparison_operator = "GreaterThanOrEqualToThreshold" # 閾値（しきいち）以上になったら発報
  evaluation_periods  = 1                               # 1回でも異常値を検出したらアウト
  metric_name         = "HTTPCode_Target_5XX_Count"     # ターゲットサーバーが返した5xxエラーの数
  namespace           = "AWS/ApplicationELB"
  period              = 60                              # 60秒（1分）単位でチェック
  statistic           = "Sum"
  threshold           = 50                              # 1分間に50回以上5xxエラーが出たらアラーム
  alarm_description   = "後ろのWebサーバーが悲鳴を上げています！至急確認してください！"

  dimensions = {
    LoadBalancer = aws_lb.web_alb.arn_suffix
  }

  # ここに通知先（SNSトピックなど）を紐解きます
  # alarm_actions = [aws_sns_topic.alert_topic.arn]
}

# ------------------------------------------------------------------
# 3. 監視の目その２：レスポンスにかかっている「処理時間」を監視するアラーム
# ------------------------------------------------------------------
# お客さんが「重い！」と感じていないか、平均の処理時間を監視します。
resource "aws_cloudwatch_metric_alarm" "alb_slow_response" {
  alarm_name          = "alb-slow-response-time"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 2                           # 2回連続で遅かったらアラーム
  metric_name         = "TargetResponseTime"        # サーバーが応答を返すまでの時間（秒）
  namespace           = "AWS/ApplicationELB"
  period              = 60
  statistic           = "Average"                   # 平均値で判断
  threshold           = 2.0                         # 2.0秒以上かかっていたら警告
  alarm_description   = "レスポンス速度が低下しています。負荷が急増している可能性があります。"

  dimensions = {
    LoadBalancer = aws_lb.web_alb.arn_suffix
  }
}

この設定を入れておくことで、万が一急激なアクセス増によってシステムが限界を迎えそうになったときも、エラー（HTTPCode_Target_5XX_Count）や応答速度の悪化（TargetResponseTime）として即座に検知し、トラブルシューティングに動くことができます。

—

7. まとめ＆次のステップへ！

今回は、ALBのスケーリングの仕組みと、急激なスパイクに立ち向かうための「事前ウォーミング」について解説しました。

最後に、今回学んだ大切なポイントを3つにおさらいしましょう！

1. ALBは魔法の箱ではない： 裏側ではAWSが管理する処理ノード（サーバー）が動いており、それらが増減することでスケールしている。
2. 急激なスパイクには弱い： 自動スケーリングには数分〜十分程度の時間がかかるため、一瞬の急増には追いつけずエラーになることがある。
3. イベント前には事前ウォーミング： 大量アクセスが事前に分かっている場合は、3営業日前までにAWSサポートへ申請して、あらかじめパワーアップさせておく。

クラウドはボタン一つで何でもできる便利な世界ですが、その物理的な裏側（パケットの通り道やリソースの準備時間）を意識できるようになると、一気に「一人前のインフラエンジニア」へと近づきます。

まずは身近なWebサイトのイベント情報を眺めながら、「このサイトの裏側では今、事前ウォーミングの申請がされているんだろうな…」と思いを馳せてみてくださいね。

一歩ずつ、楽しみながらクラウドネットワークの深い世界を学んでいきましょう！