テレビ放送・チケット発売・ニュース掲載の直後は、普段の平均アクセスが参考にならないほど人が集まります。上位プランへ変更するだけでは、データベースや外部APIが先に詰まるかもしれません。公開前には、どの処理へ何人が同時に来るかを具体的にします。

ここで扱うのはキャンペーンの企画運用ではなく、負荷からサイトを守る技術準備です。告知開始から終了までの公開管理は別に考え、この記事では公開時刻の前後に必要な容量と縮退に焦点を当てます。

平均ではなく山の形を見積もる

「一日十万ページビュー」だけでは必要容量を決められません。十万件が一日に分散するのか、開始一分へ集中するのかで負荷は変わります。告知媒体の到達人数、公開時刻、想定クリック率から一秒当たりの要求数と同時接続を仮置きします。

閲覧だけのページと、検索・ログイン・申込・決済を分けることも重要です。静的ページは多く配信できても、一件ごとにデータベースへ書き込む受付は同じ速度で増やせません。外部の決済やメール配信にも上限があるため、一本の経路として確認します。

キャッシュで元サーバーへ届く量を減らす

画像・CSS・告知本文をCDNやキャッシュから返せれば、元サーバーが処理する要求を減らせます。ただしログイン後の画面や在庫表示を誤って共有すると、別の利用者の情報を返す危険があります。何を共通化し、何を毎回処理するかをURL単位で決めます。

キャッシュは速度を上げる機能であると同時に、容量を守る仕組みです。公開直前に全削除すると、アクセスの山と再生成が重なります。主要ページを事前に読み込み、更新時にどの範囲を消すかを決めておきます。

告知時刻や在庫のように変わる部分だけを短く保ち、共通画像まで同時に再生成しない設計が有効です。実際のレスポンスヘッダーでキャッシュ経由かを確認します。

負荷試験で壊れ方まで確認する

負荷試験は、本番に近い構成へ少量から段階的に要求を増やします。許可なく共用サーバーへ大量通信を送れば、契約違反や他の利用者への影響につながります。実施条件と上限をサーバー会社へ確認し、必要なら隔離した検証環境を使います。

見るのは応答時間だけではありません。成功率・CPU・メモリ・同時処理数・データベース接続・待ち行列を同じ時刻で記録します。限界を超えた後に処理能力が急落しないか、負荷を下げれば戻るかまで確かめます。

試験データは本番の申込と区別し、通知や決済を誤って動かさないようにします。キャッシュが温まった状態と空の状態を分けると、公開直後の弱点が見えます。

すべてを守れないときの順番を決める

過負荷時に全機能を動かそうとすると、重要な受付まで止まることがあります。動画やおすすめ表示を外し、軽い案内へ切り替えるなど、計算量の高い機能から止める順番を決めます。受付上限に達したら待機ページを出す方法もあります。

GoogleのSRE資料では、過負荷時に一部の要求を早く拒否し、サービス全体の崩壊を防ぐ考え方が示されています。再試行が集中を増幅することもあるため、利用者へ連打を促さず、受付状態と次の行動を明確に伝えます。縮退中も監視や管理画面まで止めないことが重要です。切り替え機能は平常時に試し、解除した後に受付データの欠落がないか確認します。

公開当日の判断を一枚にする

公開前には設定変更を止め、担当者・連絡先・監視画面をそろえます。正常時・遅延時・受付停止時の基準を数値で決めます。「重い気がする」という会話では、切り替え判断が遅れます。変更できる人と告知する人を分けると混乱を抑えられます。

PageSpeed Insightsは利用者側の表示課題を調べるために使えますが、同時アクセスの限界を測る負荷試験ではありません。公開当日は応答時間だけでなく、エラー率と資源の飽和を監視します。外部サービスの状態も同じ時系列へ残します。

山を越えた後に元へ戻す

一時的に増やした容量や監視を放置すると、費用と通知だけが残ります。アクセスが落ち着いた基準を決め、増設分を戻す時刻を記録します。実績のピーク・失敗した要求・手動操作を保存すれば、次回の見積もりに使えます。

想定との差は担当者の反省ではなく、次回の容量計算へ戻します。外部サービスの制限が先に来た場合は、サーバー増設とは別の改善項目にします。

アクセス集中への備えは、巨大なサーバーを一台用意することではありません。負荷の山を描き、元サーバーへ届く量を減らし、限界を超えたときの縮退を試します。当日の判断まで決めておけば、想定を超える反響にも重要な機能を残せます。