キャンペーン前に見るべきWebサービス負荷対策
「来月テレビで紹介される予定なんですが、サーバー大丈夫でしょうか」「大型セールの日程が決まったんですが、今のシステムでアクセス集中に耐えられますか」——こうした相談は、キャンペーンの実施日が決まった後に駆け込みで来ることがほとんどです。普段は月間数万PVで問題なく動いているサービスが、露出のあった当日だけ急激なアクセス集中に晒され、レスポンスが遅延し、最悪の場合は落ちる。せっかく獲得したチャンスをシステム側の理由で取りこぼすのは、事業として最も避けたい失敗です。この記事では、キャンペーン前にやるべき負荷対策を、時間が限られている中での優先順位とあわせて整理します。
なぜ「普段動いているから大丈夫」は通用しないのか
日常のアクセス数で問題なく稼働しているサービスでも、キャンペーンやTV露出では普段の10倍・100倍のアクセスが短時間に集中することがあります。この状況で問題が起きやすいのは、次のような理由からです。
- 普段のアクセス量では顕在化しないボトルネック（N+1クエリ、インデックス不足、キャッシュされていない重い処理）が、負荷がかかった瞬間に一気に表面化する
- サーバーの台数やDBの接続数上限が、平常時のトラフィックを基準に設定されたままになっている
- 「落ちたらどうするか」の運用手順が整備されておらず、当日に担当者が手探りで対応することになる
普段のパフォーマンスと、瞬間的なアクセス集中に対する耐性はまったく別の指標です。「今まで落ちたことがないから大丈夫」という判断は、まだ強い負荷を経験していないだけ、というケースがほとんどです。
事前にやるべきこと（1）負荷試験でボトルネックを可視化する
最初にやるべきは、想定されるアクセス量を模擬した負荷試験です。これをやらずに対策を進めると、闇雲にサーバーを増強して終わり、という結果になりがちです。
- 想定ピークアクセス数を決める（過去のキャンペーン実績、TV露出の視聴率換算、広告出稿量などから概算する）
- 負荷試験ツール（k6、Locust等）で、想定ピークの1.5〜2倍程度の負荷をかけて挙動を確認する
- どこで応答が遅くなるか、どこでエラーが出始めるかを計測する
このステップを踏むと「どこがボトルネックか」が数字で見えるようになります。逆にここを飛ばして感覚で対策すると、実際には問題のない箇所を強化して、本当のボトルネックを見落とすことになります。
事前にやるべきこと（2）ボトルネックの特定と潰し込み
負荷試験で見つかったボトルネックは、多くの場合、次のいずれかに分類されます。
- DB周り: インデックスが効いていないクエリ、N+1クエリ、コネクションプールの上限不足
- アプリケーションサーバー: ワーカー数・スレッド数が過小、重い処理が同期的にリクエストをブロックしている
- 外部API依存: 決済・メール送信・SNS連携など、外部サービスへの同期呼び出しがボトルネックになり、外部側が詰まると自サービスまで巻き込まれて詰まる
- 静的アセット配信: 画像・CSS・JSがアプリケーションサーバーから直接配信され、CDNを経由していない
原因ごとに対応の重さは大きく異なります。インデックス追加やクエリの見直しは数時間〜数日で終わることが多い一方、アーキテクチャレベルの見直しが必要な場合は数週間かかることもあります。時間が限られているキャンペーン前は、効果の大きいものから優先的に潰すという判断が重要です。
事前にやるべきこと（3）スケール設計とキャッシュ
ボトルネックを潰したうえで、アクセス集中そのものを受け止める仕組みを整えます。
- 水平スケール: アプリケーションサーバーを1台から複数台に増やし、オートスケール（アクセス量に応じて自動で台数を増減）を設定する。AWSであればECS/EC2のAuto Scaling、負荷に応じたスケールアウトの仕組みを整備する
- キャッシュ: 頻繁にアクセスされるが更新頻度の低いページ・データ（トップページ、商品一覧、ランキング等）をキャッシュし、DBへのアクセス自体を減らす。CDN（CloudFront等）での静的コンテンツ配信もあわせて整える
- DB側の対策: 読み取りが多いサービスであればリードレプリカを追加し、書き込みと読み取りの負荷を分散する
- キュー化: メール送信・通知・集計処理など、リアルタイム性が不要な処理は非同期のジョブキューに逃がし、リクエストの応答時間から切り離す
すべてを一度に整備する必要はありません。「当日のピークにどこまで耐える必要があるか」から逆算して、投資する範囲を決めるのが現実的です。
事前にやるべきこと（4）監視・アラートの強化
キャンペーン当日は、普段以上に異常への即応が求められます。普段の監視体制のままだと、問題が起きてから気づくまでのタイムラグが致命傷になりかねません。
- レスポンスタイム・エラー率・CPU/メモリ使用率をリアルタイムで可視化するダッシュボードを用意する
- 閾値を超えたら即座にSlack等へ通知が飛ぶアラートを設定する
- 当日は担当者を張り付け、ダッシュボードを常時監視できる体制を組む
普段から監視が手薄なプロダクトでは、この機会にあわせて整備しておくと、キャンペーン後も資産として残ります。監視が入っていない状態のリスクについては本番システムに監視が入っていないとどうなるかでも詳しく解説しています。
当日の備えと「落ちたときの縮退運転」
どれだけ事前対策をしても、想定を超えるアクセスが来る可能性はゼロにはできません。完全に落とさないことと同じくらい重要なのが、落ちかけたときにどう被害を最小化するかという縮退運転の設計です。
- 機能の優先順位を決めておく: すべての機能を平等に守ろうとせず、「購入・申込導線だけは死守し、レコメンドやランキングなど重要度の低い機能は一時的に止める・簡易表示に切り替える」といった判断をあらかじめ決めておく
- 流量制限（レートリミット）: アクセスが閾値を超えたら、一部のリクエストを待機画面に誘導し、システム全体の共倒れを防ぐ
- 手動でのスケールアウト手順を用意する: オートスケールが間に合わない・想定外の挙動をした場合に、担当者が手動で台数を増やせる手順を明文化しておく
- ロールバック手順の確認: 当日に緊急でコードを直す事態に備え、デプロイとロールバックの手順を事前に確認しておく
「落ちない」を目指すのではなく、「落ちても、一番大事な機能だけは守り切る」という設計にしておくことで、被害を最小限に抑えられます。
時間がない中での優先順位
相談が来るタイミングの多くは、キャンペーンの実施まで数週間しかない状態です。時間が限られている場合は、次の順番で着手するのが現実的です。
- 負荷試験でボトルネックを特定する（これをやらないと以降の投資判断ができない）
- 致命的なボトルネック（決済・申込導線に関わるもの）から潰す
- キャッシュ・CDNなど、比較的低コストで効果の大きい対策を入れる
- 監視・アラートを強化し、当日の体制を組む
- 縮退運転の方針を決め、関係者間で合意しておく
すべてを完璧にする時間がなくても、この順番で着手すれば「一番割に合う対策」から着実に投資できます。逆に、時間がないからと闇雲にサーバースペックだけ上げても、ボトルネックがDBのクエリにある場合は効果が出ません。
外注で進める場合の進め方
社内にインフラ・パフォーマンスチューニングの知見が薄い場合、外部チームに一時的に入ってもらうのも有効な選択肢です。進め方としては、まず現状のアーキテクチャとアクセスログを共有してもらい、負荷試験と原因特定を短期で実施、その結果をもとに「キャンペーンまでにやること」と「キャンペーン後に本格対応すること」を切り分けて提案する、という流れが一般的です。時間的な制約がある案件ほど、最初の現状把握を素早く行い、優先順位を早期に確定させることが成否を分けます。既存プロダクトの改善に外部チームが入る際に最初に見る観点は既存プロダクトの改善、外部チームが最初に見る観点で詳しく解説しているので、あわせてご覧ください。
torcheees では Rails を中心とした既存プロダクトの改善支援に加え、AWSを中心としたインフラの設計・スケール対応も手がけています。負荷試験の実施からボトルネック特定、スケール設計、当日の監視体制構築まで、期限が決まっているキャンペーン対応を数多く支援してきました。
まとめ
- キャンペーン前は「普段動いているから大丈夫」ではなく、負荷試験で想定アクセス量に対するボトルネックを数字で可視化することが出発点
- ボトルネックの潰し込み・スケール設計・キャッシュ・監視強化を、時間が限られている中では効果の大きいものから優先して着手する
- 完全に落とさないことを目指すより、「落ちかけたときに何を守るか」という縮退運転の方針を事前に決めておくことが被害を最小化する
キャンペーンやTV露出の日程が決まっている場合、torcheees では「既存プロダクト改善 診断」として、現状のインフラ・コードを確認し、負荷対策の優先順位と概算費用をご提示します。期限が迫っている場合はその旨をお伝えいただければ、スケジュールを優先して調整します。まずはお問い合わせフォームからご相談ください。