· OpenWorks · tech-tips

基幹システムのリリース後に『想定外の負荷パターン』が見えてくる理由と事前検証の限界

本番環境で初めて見える、予測不可能な使い方

基幹システムをリリースして数週間から数ヶ月が経つと、必ずと言っていいほど「想定していなかった使い方」による負荷が顕在化します。それは決してシステムが壊れているわけではなく、ユーザーの実務が想定モデルを超えている、ということです。

たとえば、予約や販売管理の基幹システムでは、営業部門が「月末締切の駆け込み処理」をどう実行するか、あるいは「過去データの一括修正」をどのタイミングで、どのような粒度で実行するかは、設計フェーズではなかなか見えません。検証環境では正規のシナリオに従ったテストデータを使いますが、本番では「昨年同期のデータを全件再計算してから新規月度を開始する」といった、業務慣行に根ざした動作が突然始まるのです。

こうした「想定外」は、単なる設計の甘さではなく、事前検証の根本的な限界に起因しています。その限界を理解し、設計段階で対策を講じることが、リリース後の安定性を大きく左右します。

検証環境が再現できない3つの要素

データボリュームとその分布

テスト環境では通常、データ量を「本番相当」と想定して用意します。しかし実際の本番データは、時間とともに歪みます。

  • 偏ったアクセスパターン: 特定の営業所や期間のデータに集中的にアクセスが偏る
  • レコードサイズの不均一性: 設計時の「平均的なレコード」と異なり、実際には非常に大きなレコードや複雑な関連データが存在する
  • インデックスの効きやすさの変動: 初期段階では効いていたインデックスが、データの成長や更新パターンの偏りによって徐々に効きにくくなる

現場では、「テスト時は問題なかったのに、月末になると急に遅くなる」という報告が入ります。これは月末に特定の営業所が大量の修正を一括処理するから、という背景がテスト環境には再現されていなかったのです。

並行処理と競合状態

複数の部門が同時にシステムを使う本番環境では、テスト環境の「シナリオ順序」が通用しません。

検証では、「ユーザーAが操作してから、ユーザーBが操作する」という流れをテストします。しかし本番では、同じレコードに対して複数ユーザーが同時にアクセスし、ロック競合やデッドロックが発生します。特に基幹システムでは、月末や期末に「全員が同時に締め処理を実行する」という現象が起きやすいのです。

データベースのロック戦略やトランザクション設計は、単一シナリオでは問題が見えず、本番の並行負荷で初めて露呈します。

ユーザーの「想定外」な操作

最も厄介なのが、ユーザーが設計者の想定を超えた操作をすることです。

  • 「この機能は月1回の使用想定」だったが、実際には営業部門が「試しに何度も実行する」
  • 「この画面は個別レコード表示用」だったが、管理者が「全件データをExcelに落とすため、フィルタなしで全件検索を何度も実行」
  • 「この一括処理は数百件を想定」だったが、営業所の統合に伴い、数万件の一括処理が必要になった

こうした操作は、ユーザー教育や運用ルールである程度は抑制できますが、完全には防げません。なぜなら、ユーザーは「このシステムでどこまで可能か」を試行錯誤して学ぶからです。

設計段階で講じるべき防御策

1. 負荷の「天井値」を明示的に設定する

テスト環境で「本番相当」と言っても曖昧です。代わりに、実装時に明確な制約を設定しておきます。

// 例：一括処理の件数上限を明示的に設定
const BATCH_PROCESS_MAX_RECORDS = 10000;
const SEARCH_RESULT_MAX_ROWS = 5000;
const CONCURRENT_UPDATE_TIMEOUT_SEC = 30;

これらの値は、検証環境でのボトルネック測定に基づいて決めます。そして設定値としてコード内に埋め込まず、管理画面やコンフィグから変更可能にしておくことが重要です。本番運用が始まると、業務要件の変化に応じてこれらの値を調整する必要が生じるからです。

2. ロック戦略を明確に文書化する

基幹システムでは、複数ユーザーが同じレコードにアクセスする場面が避けられません。その際のロック動作を、設計段階で明文化しておきます。

  • 「レコード更新時は行ロック（FOR UPDATE）を取得し、トランザクション終了まで保持」
  • 「検索結果の表示後、ユーザーが編集画面を開いた時点で再度ロック取得を試みる。タイムアウト時は『別ユーザーが編集中』と表示」
  • 「一括処理中は、対象レコード群に対して意図的に待機時間を入れ、他の処理を阻害しないようにする」

こうした方針を実装段階で反映しておくと、本番で「なぜこんなに遅いのか」という問い合わせが入った時に、設計意図を説明でき、対応策を検討しやすくなります。

3. 段階的なリリースと監視体制の構築

本番環境に全ユーザーを一度に投入するのではなく、段階的に展開することで、想定外の負荷パターンを早期に検出できます。

  • 第1段階: 管理者と担当者のみ（数名）
  • 第2段階: 特定の営業所や部門（数十名）
  • 第3段階: 全体展開（数百名以上）

各段階で1〜2週間の観察期間を設け、その間に以下を監視します。

  • データベースのスロークエリログ
  • アプリケーションのレスポンスタイム分布
  • ロック待機時間
  • エラーログ（特にタイムアウトやデッドロック）

これらのメトリクスから、「テスト環境では見えなかった負荷パターン」を検出し、フェーズを進める前に対応することができます。

運用開始後の現実的な対応

ボトルネックの特定と優先度付け

本番運用が始まると、複数の「遅い」という報告が上がります。その中で、すべてに対応することは難しいため、優先度を付ける必要があります。

優先度の判断基準は：

  1. 業務への影響度: 月末締め処理など、期限が決まっている業務か、それとも日常的な参照か
  2. 発生頻度: 毎日起きるのか、特定の時期だけか
  3. 対応難度: 設定値の調整で済むのか、実装の見直しが必要か

現場では「管理者が毎月1回実行する一括処理が遅い」という報告よりも、「営業担当者が毎日使う検索機能が遅い」という報告を優先するべきです。

キャッシュとバッチ処理の活用

本番で見えた負荷パターンに対して、キャッシュやバッチ処理を後付けすることも有効です。

たとえば、「月末に全営業所の売上集計を表示する画面が遅い」という報告が入った場合、その集計結果を前夜の夜間バッチで事前計算し、キャッシュしておくという対応が考えられます。

// 例：夜間バッチで集計結果をキャッシュ
schedule.every().day.at("23:00").do(() => {
  const summaryByOffice = calculateSalesSum();
  cache.set('monthly_summary', summaryByOffice, { ttl: 86400 });
});

ただし、この方法は「集計値が常に最新ではない」というトレードオフを伴います。業務要件に応じて、その遅延が許容できるかを判断する必要があります。

見落とされやすい落とし穴

「テストデータが正規分布」という幻想

検証環境では、テストデータが意図的に「平均的」に作られます。しかし本番データは、業務の歴史と偏りを反映しています。

  • 古いデータが大量に残存している
  • 特定の期間に異常に大量のデータが登録されている
  • データ品質にばらつきがある（空文字、NULLの混在など）

こうしたデータの「汚さ」は、インデックスの効きやクエリプランの最適化に影響します。本番環境でのデータダンプを、定期的に開発環境にコピーして検証することが、こうした問題の早期発見に役立ちます。

「運用ルールで対応できる」という過信

リリース前に、ユーザーに対して「この機能は月1回の使用を想定しているため、頻繁な実行は控えてください」といった運用ルールを説明します。しかし、運用ルールに頼り過ぎると、本番で問題が起きた時に「ユーザーが指示を守らなかった」という責任転嫁になりやすいのです。

むしろ、「ユーザーはシステムの機能を試す」という前提に立ち、設計段階で対応可能な負荷範囲を広くしておくべきです。

まとめ

基幹システムのリリース後に想定外の負荷が見えるのは、設計の失敗というより、事前検証の根本的な限界です。その限界を認識した上で、以下の3点に注力することが現実的です。

  1. 設計段階で負荷の「天井値」と制約を明示する
  2. **段階的なリリースで本番パターンを早