「サイトが重い」と連絡を受けたデスクで、どこから調べようかと画面のグラフをじっと見て考えている一人運用の保守担当者
障害対応・運用監視約10分

「サイトが重い」の切り分け手順｜どこが遅いかを順番に絞る

「なんかサイトが重いんだけど」。 このひと言、障害の連絡の中でもいちばん困りませんか。落ちていれば原因の場所も絞りやすいのに、「重い」は範囲が広すぎて、どこから手をつければいいのか迷ってしまいます。

一人で保守運用をしていると、「とりあえずサーバーに入って top を叩く」「アプリのログを眺める」と、思いついた場所から手当たり次第に見てしまいがちです。 でも、重さの原因はネットワークかもしれないし、DBかもしれないし、そもそも相手の回線の問題かもしれません。順番を決めずに探すと、いちばん疲れて、いちばん時間がかかります。

この記事では、「重い」を利用者に近い側から、システムの奥へと一方向に絞っていく手順を一緒に整理します。考えなくても順番に手が動く状態を作っておきましょう。

結論：「サイトが重い」は、①本当に・どこが重いかを確認（外形）→ ②ネットワーク・DNS → ③Webサーバー・アプリ → ④データベース・外部連携 → ⑤サーバーのリソースの順に、上流から一方向で絞ります。あちこち同時に見ないのがコツ。まずは「自分の環境でも再現するか」「全ページ重いか、特定の画面だけか」の2つだけ確認すれば、見るべき場所がぐっと狭まります。

切り分けの順番や見る場所は、構成（クラウドかオンプレか、CDNの有無、DBの種類）で変わります。 この記事の順番は出発点として、自分の現場に合わせて並べ替えてください。

なぜ「順番」が大事なのか

「重い」の切り分けがしんどいのは、知識が足りないからではありません。 原因になりうる場所が多すぎて、どこから見ても「それっぽい何か」が見つかってしまうからです。

CPUがちょっと高い。スロークエリが1本ある。ネットワークのグラフが少し跳ねている。 どれも怪しく見えますが、それが今回の「重い」の本当の原因とは限りません。手当たり次第に見ると、関係ない発見に振り回されて、時間だけが過ぎていきます。

そこで、利用者に近い側から奥へ、一方向に進むと決めておきます。 すると「上流が問題なければ、その下は今回は見なくていい」と判断でき、調べる範囲をどんどん狭められます。迷子にならないための地図、それが切り分けの順番です。

まず2つだけ確認する（範囲をしぼる）

本格的に潜る前に、最初の1〜2分でこの2つを確認します。ここで原因の場所が半分くらい絞れます。

あわせて「いつから重いか」「直前に何か変えたか（リリース・設定変更・アクセス増）」も思い出しておきます。 直近の変更は、原因のいちばんの近道です。

切り分けの順番（上流から奥へ）

「サイトが重い」の切り分けを、利用者に近い外形から、ネットワーク・アプリ・データベース・リソースへと上から順に下りていく階層の図
利用者に近い「外形」から、奥の「リソース」へ。上から順に下りて、問題のない層はそこで切り上げる

範囲がしぼれたら、次の順番で上流から見ていきます。 各層で「ここは白（問題なし）」と分かったら、その下へ進みます。

① 外形（利用者の目線で測る）

まずは利用者と同じ立場で、実際の遅さを測ります。 ブラウザの開発者ツール（ネットワークタブ）で、どのリクエストに時間がかかっているかを見ます。

利用者が社外・遠隔で、自分の端末では再現しないこともあります。そのときは机上で止めず、利用者にスクショ・起きた時刻・URL・回線種別（社内/自宅/モバイルなど）を聞くだけでも、見る場所がぐっと絞れます。

ここで「サーバーが応答を返すまで」が遅いと分かれば、③④へ進む価値があります。

② ネットワーク・DNS・配信

サーバーにたどり着くまでの経路を確認します。

ここは知識が浅いと手が止まりやすい層です。分からない項目は無理に粘らず、上の免除条件で軽く流して先へ進めば十分です。経路が問題なくサーバーまで速く届いているなら、原因は中（③以降）にあります。

③ Webサーバー・アプリ

サーバーが応答を返すまでが遅いなら、アプリの処理を見ます。

「特定の画面だけ重い」の多くは、この層か次のDB層に原因があります。

④ データベース・外部連携

アプリが「何かを待って」遅いなら、その待ち先を見ます。

DBや外部の応答時間は、アプリのログやDBの管理機能から確認できます。

⑤ サーバーのリソース

ここまでで原因が見えないとき、土台のリソースを確認します。

リソースが原因なら、一時的な増設や不要プロセスの停止で楽になることもありますが、本番で何かを止める判断は一人だと怖いものです。何のプロセスか分からないものは触らない、増設は課金が増える点を一拍考える——この2つを踏みとどまる基準にして、操作の前に「戻せるか」もあわせて確認してからにします。迷うなら、止めずに記録だけ取って先送りするのも立派な判断です。

ひとつ注意です。重さの調査は、つい本番でいろいろ試したくなりますが、再起動やキャッシュ削除、設定変更は、戻し方とセットで。本番をいじるなら、できる範囲で先に状態（設定・プロセス・メトリクス）を記録してからにすると、後で振り返れます。

具体例：3つの「重い」のたどり方

順番に当てはめると、こんなふうにたどれます。

大事なのは、最初の「2つの確認」で入口を決めてから潜ることです。入口が決まれば、どこを見ればいいかは自然と狭まります。

影響：順番を決めておくと、何が変わるか

切り分けの順番を1枚持っておくと、対応そのものが速くなるだけでなく、気持ちが落ち着きます。

逆に、順番がないまま毎回ゼロから勘で探すと、同じ「重い」でも対応する人や日によって時間が大きく変わってしまいます。

明日やること：自分の構成で順番を1枚にする

いきなり全部は要りません。明日できる、いちばん小さな一歩はこれです。

  1. 今いちばん止まると困るシステムを1つ選ぶ。
  2. 紙でもドキュメントでもいいので、「外形・ネットワーク・アプリ・DB・リソース」の5見出しを書く。
  3. 各見出しに、自分の環境での「見る場所」（開発者ツール／このログのパス／このコマンド／この管理画面URL）を、思い出せる範囲で書く。
  4. 最初に確認する「2つの質問」（再現するか／全部か一部か）を、いちばん上に書いておく。
  5. 残りは、次に「重い」が来たときに1行ずつ追記して育てる。

完成版を目指さなくて大丈夫です。5見出しと「最初の2つの質問」だけでも、立派な切り分けメモの第一稿です。

「サイトが重い」切り分けチェックリスト

本番で迷わないかを確かめる項目です。コピーして、自分のメモに当ててみてください。 まずは上2つ（再現するか／全部か一部か）だけ書いてあればOK。そこが最低ラインで、残りは追々で大丈夫です。

全部に○が付かなくても大丈夫です。半分でも、何もないときよりずっと落ち着いて潜れます。

よければ、こちらも

「重い」の切り分けは、障害対応全体の一部です。鳴った瞬間の段取りや、連絡の型もあわせて1枚にしておくと、当日とても楽になります。

重さの原因を順番に絞って突き止め、応答時間が落ち着いたグラフを見てほっと一息つく保守運用の担当者

「重い」は原因の場所が広い分、順番という地図がいちばん効きます。 今日は5つの見出しと「最初の2つの質問」を書いておくだけで十分です。次に「なんか重いんだけど」と言われたとき、そのメモが、あなたを迷子にさせず奥へ案内してくれます。

ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。

関連用語