「サーバーを大きくすれば直る？」システムが遅いときに先に調べること

たとえば、「朝になると検索が遅い。サーバーを大きくすれば直るでしょうか」。利用部門からそう聞かれても、どの画面で、誰が、何をしたときに待つのかが分からなければ、増強すべき場所を決められません。

DBはデータベースのことです。サーバー増強は、自社側の処理能力不足を示す記録が得られた場合の候補であり、原因調査の代わりにはしません。

稼働中のWeb業務システムを例にします。監視では待ち時間だけでなく、処理量・エラー・資源の飽和も見るという原則を踏まえています（出典：Google SRE「Monitoring Distributed Systems」）。

遅い状況を具体的に記録する

最初は、困っている操作を一件だけ書き出します。次は検索が遅い場合の記入例です（想定例）。

操作：受注を条件検索する。端末：A、社内有線。発生時間帯：09:00〜09:30（JST）。待ちの起点：検索ボタンを押す。終点：指定した条件の結果がそろう。秒数は未測定。

調査担当から質問を受けたら、OS・ブラウザーの版、対象データ件数、直前の変更などを補います。共有票には顧客の生データを載せず、必要な識別情報は社内で管理します。

再現した回数と試した回数も分けます。まだ試していないなら「不明」で構いません。担当者の端末では再現しなかったという情報だけで、利用部門の端末でも問題がないとは扱わないようにします。画面、利用できる機能、検索条件、表示件数までそろえて、違いを一つずつ確認してください。

同じ記録票に、一覧表示と保存の操作も加えます。時刻はすべてJSTです。秒数は測定後に埋める欄として空け、次に測る区間を決めておきます。

表1　三つの操作と、次に測る区間

共通条件は端末A・社内有線、基礎データ10万件。平常13:00〜13:30は10人、繁忙09:00〜09:30は40人が操作する仮定です。OS・ブラウザー版、再現回数、秒数、失敗件数は、調査時に追記します。

操作	待ちの起点と終点	次に測る区間と、改善後に残す点検
一覧を開く（D-01）	開く操作から50件の一覧を操作できるまで	受信後の描画が長いか。端末だけ替えて同じ表示を比較する
条件検索（Q-01）	検索押下から、固定条件の正しい50件がそろうまで	DBの検索に時間がかかるか。速くなっても返る結果が同じかを見る
1件保存（W-01）	保存押下から、保存確定と完了表示が出るまで	DB保存、同期で呼ぶ外部APIの応答、完了表示を分ける。受付と完了を混同せず、重複保存がないか調べる

端末B・無線・初回と再表示の差、30万件・別の検索条件・同時更新はまだ試していません。外部APIを含めて試す許可と再試行の仕様も、試験前に聞きます。各操作の秒数は測ってから記入し、分からない区間は0秒にしません。

記録票の項目と改善仮説は、調査依頼のための記入例です。試験の進め方と費用の考え方は、AWS「Implications of load testing」とAWS「AWS 料金体系の仕組み」（PDF）をもとにしています。

記入用の遅い操作の記録票（Excel）には、この見本と空欄版、性能要件・試験計画の記入欄を収録しています。不明な欄は誰がどの記録を確認するかまで決めると、追加調査を依頼しやすくなります。

待ち時間を分ける

画面の待ち時間は、利用者側の操作から業務上必要な結果が見えるまでを測ります。サーバーの応答時間だけを、画面全体の待ち時間と取り違えないことが出発点です。同じ操作をブラウザー側とサーバー側の記録で追うと、どの区間を調べるかが分かります。

図1　画面表示・検索・保存の待ち時間を、処理の順序で分ける（説明例）。矢印は処理の進行順だけを表し、箱の幅は秒数を表しません。

図は、Chrome for Developers「Network features reference」の通信区間と、OpenTelemetry「Traces」の処理区間の考え方をもとにした説明図です。

利用条件をそろえて測る

比較用の条件は、平常と繁忙、少ないデータと多いデータ、初回表示と再表示を分けて用意します。表1では平常10人・繁忙40人を仮定していますが、試験中に操作する利用者数として扱っています。登録ユーザー数とは区別します。同じ40人でも、操作の種類や間隔が違えば、同じ負荷をかけた比較にはなりません。

たとえば端末差を調べる回は端末だけを替え、検索条件と時間帯はそろえます。データ10万件で調べた結果を、30万件へそのまま適用しません。環境の構成、アプリ版、キャッシュの有無、バックグラウンド処理も記録し、そろえられない点は比較の限界として残します。

平均に加えて、長い待ちと失敗を見る

平均が同じでも、一部の操作だけ長く待つ状態は隠れます。p95は、待ち時間を短い順に見たときのおおむね95％の位置を示す値で、最大値とは区別します。操作別の平均・中央値・p95に、集計期間、件数、失敗・タイムアウト件数を添えます（出典：Google SRE「Monitoring Distributed Systems」、Google SRE「Service Level Objectives」）。

成功分だけの時間分布を出す場合も、失敗を除いたことと全試行数を明示します。少数の試行では長い待ちの傾向を判断しにくいため、個々の結果も残します。p95の計算法や集計の粒度は調査側とそろえ、異なる操作や端末の集計値を一つに混ぜないようにします。

性能要件には、秒数と試験条件を書く

検索だけを対象にした、合意前の要件案を作ります（想定例）。端末A・社内有線、検索対象10万件・返却50件、キャッシュ再利用あり、40人が応答後10秒間隔で検索します。5分かけて40人まで増やし、その後の30分を集計対象にします。初回検索、別の検索条件、保存との混在はこの試験の対象外です。

仮の達成条件は「検索ボタンの押下から3秒以内に、正しい結果表示まで完了した回数が全試行の95％以上」とします。タイムアウトは10秒と仮定し、失敗とタイムアウトも分母に含めます。試行数と達成回数は試験後に報告します。これらの秒数・人数・期間は、説明用の仮定です。

実際の目標は、その操作を一日に何回使い、待ちがどの業務を止めるかを利用部門と話し合って決めます。計測の起点・終点、条件、集計期間を明確にする考え方は、Google SRE「Service Level Objectives」を参照しています。

同じ50件を返す検索で、DBの区間だけ測った例

2026年10月26日、架空の受注10万件をメモリー上のSQLiteへ作り、顧客173の最新50件を検索しました。再現用のPythonコードでは、検索条件と返るID・金額を固定し、各条件で準備1回の後に7回測ります。

比較した条件	検索計画	この実行の中央値
顧客別の索引なし	表を走査するSCAN	約0.595ミリ秒
顧客ID・受注IDの索引あり	索引で探すSEARCH	約0.013ミリ秒

Python 3.10.2、SQLite 3.35.5で、SQLの実行開始から50件の読込み完了までを測った結果です。期待するIDの一覧はデータの作成規則から別に計算し、改善前後の全7回で同じ50件と一致しました。速くても検索条件や並び順が変われば、同じ改善とは扱いません。

この小さな測定には、ブラウザー、通信、認証、同時利用、外部APIは含まれません。ミリ秒値や倍率を実システムへ当てはめず、実行環境による違いも見ます。画面の待ち時間が長い場合には、まずDB区間が全体のどれだけを占めるかを調べてから、このような対策を比較します。

調査結果に合う改善策を選ぶ

改善案は、長く待っていた区間に対応させます。受信後の描画が支配的なら端末・表示処理、DB検索が長いなら検索条件や実行計画、外部API待ちなら連携方式が調査候補です。端末・DB・連携の対策は、必要に応じて併用します。

CPUやメモリーの不足と遅延が同時に観測されれば、処理の見直しと増強を比較します。ただし、CPUが低いことも「自社側には原因がない」証拠にはなりません。PostgreSQLでは、実行中の処理がロックやI/Oなどを待っている状態も区別できます（出典：Google SRE「Monitoring Distributed Systems」、PostgreSQL「The Cumulative Statistics System」）。

外部APIの待ちが大部分を占めるなら、アプリ用サーバーの増強を最初の解決策にはしません。必要なのは相手先を含む応答記録です。記録が取れない段階では原因を保留し、提供元の障害情報やサポート、自社の連携ログから追加情報を得ます。逆に自社側の処理待ちが確認されたなら、判断を変えて構成・処理能力を検討します。

比較するのは、対象操作に効く見込み、初期の変更費用と継続費用、安全性、元へ戻す方法、変更後の試験条件です。キャッシュを使う案ならデータの鮮度、非同期化する案なら受付後の完了確認、DB変更なら検索結果と保存内容の正しさも確認対象にします。速さだけを合格条件にしないでください。

変更後は同じ端末・操作・データ量・利用条件で測り直し、長い待ちと失敗が増えていないかを見ます。調査依頼には、記録票、再現手順、対象期間、確認したい業務上の完了を添えれば、増強を先に指定するよりも調査範囲を合意しやすくなります。

調査担当者向け：区間の計測と負荷試験

ブラウザーとサーバーの記録を照合する

Chromeの開発者ツールでは、NetworkのTimingで接続、送信、最初の応答を待つ時間、受信などを確認できます。ただしWaiting（TTFB）には通信の往復とサーバーが応答を準備する時間が含まれます。「Waitingが長いからDBが原因」とは断定できません（出典：Chrome for Developers「Network features reference」）。

サーバー内は、同じ処理を追う識別子でアプリ、DB、外部APIの記録を結びます。OpenTelemetryのトレースは、開始・終了時刻を持つ処理区間と、その親子関係を表せます。親の処理時間に子のDB処理が含まれるなら、両方を足すと二重計上です。並列処理も単純合算せず、開始・終了と重なりを確認します（出典：OpenTelemetry「Traces」）。

画面表示は「開く」から操作可能になるまで、検索は「検索」から指定条件の結果がそろうまでを記録します。保存は、押下、DBでの保存確定、外部連携の応答、完了表示を区別します。図は外部APIを同期呼出しする一例です。非同期処理では「受け付けた」と「業務が完了した」を別の到達点として定義してください。

取得できていない区間は「不明」とし、0秒にはしません。異なる機器のログを突き合わせるときは、時刻のずれと単位も合わせます。記録票の「待ちが始まる場所」は利用者が見た現象であり、ボトルネックが確定した場所ではありません。

負荷試験の対象・許可・費用・停止条件

AWSは、負荷試験による費用、外部サービスの利用枠消費、試験データの蓄積、負荷を発生させる側の帯域不足を注意点に挙げています。対象だけでなく試験装置も確認し、発生させたい負荷を送れなかった結果を「システムの上限」としないでください（出典：AWS「Implications of load testing」）。

本番や外部サービスへ無許可で負荷をかけないことを、試験計画の前提にします。実施者と承認者、対象環境、時間帯、負荷の増やし方、費用上限、停止条件、停止担当、復旧と試験データ削除の手順を決めます。入力データは合成し、顧客への通知や実注文が発生しない経路を確認してください。

外部APIは、必要に応じて模擬応答を返す代替先に置き換えます。ただし、その結果が示すのは代替先を使った自社側の挙動までです。実サービスを含む保存完了時間や、その障害時の性能は証明できません。外部連携込みの確認は、提供元の試験条件と許可を得て別に計画します（出典：AWS「Implications of load testing」）。

費用はサーバーだけでなく、保存・転送・ログ・リクエスト数も試算します。AWSの料金資料は計算資源、保存、データ転送などを料金要因として説明していますが、2020年版の単価や無料枠は見積りへ転記しません。利用するサービスの現行料金と、自社の請求・契約条件で確認します（出典：AWS「AWS 料金体系の仕組み」（PDF））。

調査データの共有にも注意が必要です。ChromeのHARには機密ヘッダーを除く出力方法がありますが、共有前にURLや本文などの顧客情報も点検します。またPostgreSQLのEXPLAIN ANALYZEは実際にSQLを実行します。名前に「分析」とあっても安全な参照専用操作とは限らず、実施環境と実行許可を確認してください（出典：Chrome for Developers「Network features reference」、PostgreSQL「Using EXPLAIN」）。

原因がまだ分からないなら、遅い操作を一つ選び、いつ・どの端末で・どこからどこまで待つかを記録票に書いてください。待つ区間が分かったら、その区間への対策を同じ条件で比べます。

次に読むもの

性能を含む合否基準や再確認の進め方は、システムの受入テスト・検収で確かめることで整理しています。外部APIの応答不明、再送、二重実行への備えは、API連携の要件｜待ち時間・再送・二重実行へ進んでください。

調査後も小さな修正や運用相談が続く場合は、困る操作と確認済みの条件をまとめて、業務システムの月額保守・運用改善の対応範囲を確認してください。

参考出典

• AWS「Implications of load testing」
• AWS「AWS 料金体系の仕組み」（2020年10月30日、日本語PDF）
• Chrome for Developers「Network features reference」（2024年7月16日更新）
• OpenTelemetry「Traces」（2026年1月14日更新）
• Google SRE Book「Monitoring Distributed Systems」（第6章）
• Google SRE Book「Service Level Objectives」（第4章）
• PostgreSQL「Using EXPLAIN」（14.1節）
• PostgreSQL「The Cumulative Statistics System」（27.2節）