Webサービスのアクセス急増対策｜負荷試験・ボトルネック特定・切り戻しの手順
株式会社 SunSunTech
キャンペーンやテレビ紹介、プッシュ通知の直後にアクセスが集中し、「画面が開かない」「決済だけ失敗する」といった事態を防ぎたい開発者・運用担当者向けの記事です。アクセス急増への備えは、サーバー台数を増やすだけでは不十分です。本記事では、ボトルネックの見つけ方、負荷試験の設計、キャッシュやスケーリングの使い分け、本番当日の監視と切り戻しまでを実務の順序で解説します。
目次
アクセス急増で起きる障害を分解する
アクセス急増時の遅延は、Webサーバーだけが原因とは限りません。ブラウザからCDN、ロードバランサー、アプリケーション、データベース、外部APIまで、リクエストが通る経路のどこかで処理能力を超えると全体が遅くなります。最初に重要なのは「何台必要か」ではなく、「どこが、どの条件で限界になるか」を把握することです。
代表的な兆候には、CPU使用率の上昇、メモリ不足、DB接続プールの枯渇、ロック待ち、外部APIのレート制限、キュー滞留などがあります。平均応答時間だけを見ると、一部ユーザーの深刻な遅延を見落とします。p95やp99の応答時間、エラー率、スループットを同じ時間軸で確認しましょう。
また、閲覧ページは正常でもログインや購入だけ失敗する場合があります。読み取り処理と書き込み処理では、キャッシュの効き方やDB負荷が異なるためです。トップページ、検索、ログイン、カート、決済など、利用者の行動単位で重要経路を分けることが出発点になります。
負荷試験の前に目標とシナリオを決める
負荷試験は、大量のリクエストを送ればよいものではありません。まず通常時とピーク時の想定同時接続数、1秒当たりのリクエスト数、許容する応答時間とエラー率を決めます。予測が難しい場合は、過去イベントのログや事業部の集客計画を根拠に、通常、想定ピーク、想定超過の3段階を置くと判断しやすくなります。
次に、本番に近い利用比率でシナリオを作ります。たとえば閲覧80％、検索10％、ログイン5％、購入5％のように、軽い処理だけへ偏らせないことが重要です。ログイン済みセッション、データの偏り、キャッシュが温まる前後も再現します。負荷の上げ方は、段階的に増やすランプ試験、一定負荷を長くかける持久試験、限界を調べるストレス試験を目的に応じて使い分けます。
試験環境が本番より小さい場合は、結果を単純に台数倍してはいけません。DB性能、ネットワーク帯域、外部サービスの制限など、比例しない要素があるためです。環境差分を一覧にし、結果から言える範囲と言えない範囲を明記します。試験データには実在する個人情報を使わず、外部APIには先方と合意した上限を設定します。
ボトルネックを特定する実践手順
- 基準値を取る：低負荷時の応答時間、CPU、メモリ、DB接続数、クエリ時間を記録します。
- 負荷を段階的に上げる：一気に最大負荷をかけず、各段階でスループットとエラー率がどう変わるかを確認します。
- 相関を見る：遅延が始まった時刻と、CPU飽和、GC、スロークエリ、キュー滞留などの変化を照合します。
- 仮説を一つずつ検証する：インデックス追加や接続数変更などを同時に行わず、変更前後を比較します。
- 再試験する：改善後は同じ条件で測り、別の箇所が新たな限界になっていないか確認します。
計測では、インフラ指標、アプリケーションのトレース、ログ、DB統計をリクエストIDなどでつなげると原因を追いやすくなります。エラーそのものだけでなく、タイムアウト直前の遅い処理も対象にします。性能問題を再現できないときは、負荷量だけでなくデータ件数、特定URL、時刻、キャッシュ状態、外部APIの応答を見直してください。
対策はキャッシュ・非同期化・スケーリングを使い分ける
静的ファイルや更新頻度の低いページはCDNやHTTPキャッシュで配信し、アプリケーションまで届くリクエストを減らします。ただし、ログイン後の個別情報や在庫数などを誤って共有キャッシュすると、情報漏えいや表示不整合につながります。キャッシュキー、TTL、無効化条件を先に設計しましょう。
メール送信、画像変換、集計など即時完了が不要な処理は、キューを使って非同期化できます。利用者には受付完了を返し、処理状況を後から確認できる形にします。一方、決済や在庫引当のような重要処理では、再実行しても二重処理にならない冪等性と、失敗したメッセージを隔離する仕組みが必要です。
水平スケーリングを行うなら、セッションを各サーバーのメモリだけに置かない、起動に必要な時間を計測する、ヘルスチェックを実処理に近づける、といった準備が欠かせません。DBが限界なら、アプリサーバーを増やすほど接続数が増えて悪化する場合もあります。読み取り負荷の分散、クエリ改善、適切なインデックス、接続プール調整を優先順位付きで検討します。
最後の防波堤として、レート制限、待機室、機能の一時停止も用意します。全機能を遅くするより、優先度の低い検索やレコメンドを止め、ログインや購入を守る方が事業影響を抑えられます。
本番当日の監視と切り戻しチェックリスト
- 重要画面ごとの応答時間、エラー率、処理件数をダッシュボード化したか
- アラートの閾値、担当者、連絡経路、判断責任者が決まっているか
- オートスケールの最小・最大台数と起動時間を検証したか
- 外部API、DB、キュー、CDNの上限と利用率を確認したか
- 機能フラグで停止できる非必須機能を決めたか
- リリース中止、設定復元、旧バージョンへの切り戻し手順を演習したか
- イベント後にログと判断記録を保存する担当を決めたか
当日は、単一の数値だけで緊急変更を決めないことも重要です。利用者影響、指標の継続時間、変更による副作用を短時間で確認し、事前に決めた基準に沿って判断します。イベント終了後は、最大負荷、最初に逼迫した箇所、実施した対応、未解決リスクを振り返り、次回の予測と試験条件を更新します。
よくある質問
Q1. 負荷試験は本番環境で行うべきですか？
原則は本番相当の隔離環境で行います。本番でしか確認できない項目は、影響範囲、時間帯、停止条件を合意し、少量から段階的に実施します。実利用者のデータや外部サービスへ予期せぬ負荷を与えない設計が必要です。
Q2. オートスケーリングがあればアクセス急増に耐えられますか？
十分とは限りません。新しいインスタンスの起動より速く負荷が増える場合や、DB、外部API、共有ストレージが先に限界になる場合があります。事前スケール、キャッシュ、レート制限を組み合わせ、依存先を含む全体で検証します。
Q3. 最初に改善すべき箇所はどう決めますか？
重要な利用経路への影響、発生頻度、改善効果、変更リスクの4軸で優先順位を付けます。推測で大規模改修を始めず、計測で確認できたボトルネックから、小さく安全に改善するのが基本です。
まとめ
アクセス急増対策は、負荷の予測、重要経路のシナリオ化、ボトルネック計測、対策、再試験、本番監視を一つの流れとして進めます。まず過去ログと集客計画から3段階の負荷目標を置き、重要画面のp95応答時間、エラー率、スループットを測ってください。その結果をもとに、キャッシュ、非同期化、クエリ改善、スケーリング、レート制限を組み合わせ、切り戻し判断まで演習しておけば、アクセス急増時にも事業上重要な機能を守りやすくなります。
投稿者プロフィール
-
はじめまして。
株式会社SunSunTech代表取締役の鈴木と申します。
SunSunTechは、エンジニアが納得できるキャリアと報酬を得られるSES企業を目指して設立しました。
私は元々、エンジニアとして複数のSES現場で経験を積んできました。
その中で、「スキルに見合った評価が得られない」「給与の仕組みが不透明」といった業界特有の課題に何度も直面してきました。
こうした状況を変えるために、SunSunTechでは、透明性のある評価制度の導入、エンジニアファーストな案件選定など、"エンジニアが報われる仕組み"を徹底しています。
SES企業様とのパートナー連携においても、スピード・誠実・精度を大切にし、長期的に信頼される関係構築を目指しております。
エンジニアの未来を、本気で変えていく。
その想いに共感してくださる方、ぜひ一度お気軽にお声がけください。
