はじめに
この記事はアドベントカレンダー20日目の記事です。
はじめまして 株式会社うるるOurPhoto事業部でバックエンドエンジニアをしているkmyです。
今回は、担当しているサービスがテレビ放映された際に行った事前準備、負荷対策の意思決定、そして当日の対応についてまとめていきます。
インフラ専任ではないエンジニアが、どのように予測を立てて判断したかの記録としてご覧ください。
本記事で紹介すること
- テレビ放映時のアクセス予測の算出方法（フェルミ推定）
- 予測に基づいたAWS構成変更の判断（ECS/RDS）
- 開発環境を用いた負荷検証（abコマンド）
- 当日のオペレーション体制
1.アクセス予測の出し方
テレビ放映の影響力は未知数ですが、何らかの基準がないとサーバーのスペックを決められません。
そこで、以下の3ステップで予測を立てました。
- フェルミ推定による理論上の予測
- 実績値（平常時のピーク）の確認
- 最終的な予測値の決定
ステップ1：理論上の予測（フェルミ推定）
まずは総アクセス数を予測します。
計算式はこちらの記事を参考に以下の要素を掛け合わせました。
総アクセス数 = (A)リーチ人数 × (B)視聴率 × (C)Web検索転換率 × (D)平均閲覧ページ数
各パラメーターは以下のように設定しました。
- (A) テレビ局のリーチ人数：4,400万人
- 関東広域圏の世帯数 × 世帯平均人数（約2.2人）で算出
- (B) 視聴率：2.0%
- 過去の同番組の数値を参考
- (C) Web検索する人の割合：1.0%
- 一般的なCTRなどを参考に仮置き
- (D) 一人あたりの平均閲覧ページ数：1ページ
- GA4の直帰率等を考慮し、サーバーへのインパクトとして最低ラインを設定
総アクセス数
4400万(テレビ局のリーチ人数) × 2%(視聴率) × 1%(Web検索する人の割合) × 1(一人あたりの平均閲覧ページ数) = 8800
次に秒間アクセス数（RPS）を出します。
1秒あたりのアクセス数
8800 ÷ 60 = 約146
予測としては1秒間に約146という結果になりました。
ステップ2：実績値の確認
※実際の数値を詳細に書けないので仮置きしています。
次に、CloudWatchのメトリクス（ALBのRequestCount）から、直近2週間の最大リクエスト数を確認しました。
期間中のピーク時のリクエスト数（1分間の合計）を約1,000件と仮定します。
1秒あたりの最大アクセス数
1000 / 60 = 16.6666667
結果としては1秒あたり約16アクセス。
ステップ3：最終的なアクセス予測
予測値と実績値を合算し、さらに突発的なスパイクに備えて 1.5倍のバッファ を持たせました。
1秒あたりのアクセス数予測
(アクセス予測 + 直近2週間の1秒あたりの最大リクエスト数) × 1.5
1秒あたりのアクセス数予測
(146 + 16) × 1.5 = 243
キリよく、秒間250リクエスト に耐えられる構成を目指すことに決定しました。
2.サーバーの変更方針
アクセス予測（250 req/sec）に対し、AWS構成をどう変更するかを検討しました。
基本方針
「アーキテクチャの大幅な変更は行わず、スケールアウトで対応する」
テレビ放映は一時的なイベントであるため、設計変更のリスクを負うよりも、既存構成（ALB / ECS / RDS / ElastiCache）の台数調整で吸収する方が安全かつ低コストであると判断しました。
各リソースの対応
| リソース | 対応方針 | 詳細 |
|---|---|---|
| ECS | タスク増強 | 1vCPUあたり50 req/sec処理可能と仮定。 目標250 req/secに対し、50×6台=300 req/sec処理できる計算で、最大6台構成へスケールアウト。 |
| RDS | リードレプリカ増強 | 検索・閲覧負荷の増加を想定。 ALBのAZ分散も考慮し、最低6台〜最大10台へ増強（CPU負荷分散のため）。 |
| ElastiCache | 変更なし | 現状のCPU・メモリに十分な余裕があったため変更なし。 ※念のため開発環境でサイズ変更手順のみ確認。 |
コスト面の確認
ざっくりAWSを用いて試算したところ、放映時間帯（数時間）のスケールアウトによる追加コストは数百円程度でした。イベント対応の保険料としては十分に許容範囲です。
3. 開発環境での検証
計算上のスペックが正しいか確認するため、開発環境で負荷試験を行いました。
検証環境とツール
開発環境は本番よりスペックを落としているため、その差分を考慮して検証しました。
- ツール: ab (Apache Bench)
- 検証対象: ECS (1vCPU/2GB), RDS (db.r5.large) ※サイズは本番合わせ
- ECS台数: 検証時は最低台数を6台に固定
実行コマンド
1秒間に250リクエストが来る状況を擬似的に再現するため、同時接続数（Concurrency）を高めに設定して負荷をかけました。
※URLは変更しています
ab -n 15000 -c 250 https://hogehoge/
※ ab コマンドでは正確な「秒間リクエスト数」の指定はできませんが、
250 req/sec × 60秒 = 15,000 という総量と、同時接続数 250 を指定することで、瞬間的な高負荷状態をシミュレーションしました。
開発環境のスペック（本番より低い）でこの負荷に耐えられれば、本番でも耐えられるという「安全側に倒した」検証です。
検証結果
結果：台数変更のみで問題なさそう
サイト全体のレスポンスは多少重くなるものの、サーバーダウンはしないと判断。
※サイトが重くなる点については、ユーザー影響を考慮し、後述の準備を行いました。
ECSの負荷状況
負荷はかかっていますが、耐えられています。
RDSの負荷状況
リードレプリカに負荷が分散されていることを確認（Writerへの影響も軽微）。
4. 当日までの準備
準備したことは、
- ECS、RDSの設定変更手順
- サーバーダウン時の対応方法
- ユーザー対応フローの確立
- タイムスケジュール
- 監視体制の構築
です。
ECS、RDSの設定変更手順
ECS,RDSの設定変更手順をスクショ付きで作成しました。
サーバーダウン時の対応方法
ユーザー対応フローの確立
ユーザー情報を取得するクエリ作成しておいて、当日に実行するだけの状態にしました。
連絡方法はチーム内で共有、確認済です。
タイムスケジュール
放映何分前にスケールアウトするか、何分後に戻すかを分単位で決定
監視体制の構築
GA4（リアルタイムユーザー数）とCloudWatch（CPU, RequestCount）を並べて監視できるようダッシュボードを整備しました。
5.当日の対応と結果
事前に用意したタイムスケジュールに沿って対応しました。
当日の流れ
- 放映前: ECS、RDSを予定台数までスケールアウト
-
放映中: リアルタイムアクセス数とサーバー負荷を1分単位で記録
※仮の数値を置いています
- 放映後: アクセスが落ち着いたことを確認し、元の構成へスケールイン。
結果
事前の予測と準備が功を奏し、サービスダウンすることなく無事に放映を乗り切ることができました。
また、詳細なログを残したことで、次回のイベント時に向けた貴重なナレッジ（アクセス係数や負荷の傾向）を蓄積することができました。
まとめ
今回はテレビ放映時の対応について調査~当日の対応までを書きました。
インフラ専門ではない立場での対応で、調査段階で迷うことも多くありました。
しかし、準備をしっかりとしていたおかげで安心して当日を迎えることができました。
今回の経験は、単なる負荷対策だけでなく、システム全体のボトルネックを理解する良い機会となりました。
本記事がどなたかの参考になれば幸いです。