メインコンテンツまでスキップ

第01章：まず“遅い”を数値化しよう ⏱️

この章でやるのはシンプルです👇 「どこが遅いのか？」を、勘じゃなくて“数字”で言える状態にすること！📏✨ （ここができると、次章以降の改善がぜんぶ速くなります🚀）

1) まずは“遅い”を4つに分解しよう 🧩​

体感で「Docker遅い…😇」ってなりやすいけど、遅さはだいたいこの4つに分かれます👇

  1. ビルドが遅い 🏗️（docker build / compose build）
  2. 起動が遅い ▶️（docker run / compose up）
  3. 依存解決が遅い 📦（npm/pnpm の install）
  4. ファイルI/Oが遅い 📁🐢（マウントしたソース読み書き）

この章では、全部を“計測できる形”にするのがゴールです✅

2) 今日作る「ベースライン」📒✨（改善前の成績表）​

次の3つだけは最低限そろえます👇

  • ビルド時間（初回 / 2回目の差も見る）
  • イメージサイズ（どれくらい重いか）
  • 遅い工程トップ3（BuildKitログから拾う）

BuildKitの --progress=plain で、各ステップの DONE 0.4s みたいな時間が見えるので、犯人探しが一気にラクになります👀⚡️ (Docker ドキュメント)

3) 計測のコツ（ズレないためのルール）🧠​

  • 1回で判断しない：できれば 3回測って中央値 🥉
  • 同じ条件で測る：バックグラウンド更新・大量DL中だとブレます📶
  • 記録は“コピペできる形”で残す：あとで比較できないと泣きます😭

4) ミニ演習：ベースラインを作る 🧪📒​

4-1. ベースライン用のメモを用意する 📝​

プロジェクト直下に perf-baseline.md を作って、まずテンプレを貼ります👇

## Docker Perf Baseline (before)

## A. Build
- Build command:
- Build time (1st): 
- Build time (2nd): 
- Slow steps (top3):
  1)
  2)
  3)

## B. Image
- Image name:
- Image size:
- Layer suspects (top3):

## C. Run / Start
- Start command:
- Start time:

## D. Disk usage (optional)
- docker system df (summary):

4-2. ビルド時間を測る（PowerShellの最短ルート）⏱️​

PowerShell なら Measure-Command が超便利です✨（公式コマンドレット）(Microsoft Learn)

Measure-Command { docker build --progress=plain -t app:baseline . }
  • --progress=plain を付けると、BuildKitのログがテキストで出ます🧾 （各ステップの時間が見えるのが超大事！）(Docker ドキュメント)

ポイント🎯 同じコマンドをもう1回実行して、2回目の時間も測ってください👇

  • 1回目：キャッシュが育ってない（重い）😵
  • 2回目：キャッシュが効いてる（軽い）😎 この差が“改善の伸びしろ”です📈✨

4-3. 「遅い工程トップ3」を抜く 🕵️‍♂️​

--progress=plain のログには、だいたいこんな感じで出ます👇（例）

#7 [deps 3/4] RUN npm ci
#7 DONE 42.1s

この DONE xx.xs が大きい順に トップ3 をメモします✍️

  • たとえば npm ci が 40秒なら、次章以降の主役は「依存キャッシュ」です📦🔥

4-4. イメージサイズを測る 📦⚖️​

まずは一覧でサイズ確認👇 docker image ls の SIZE は「そのイメージ＋親イメージも含めた累積サイズ」って位置づけです📦(Docker Documentation)

docker image ls app:baseline

さらに「どの命令（レイヤ）が重い？」を見るなら docker image history 👀 公式リファレンスもあります📚(Docker Documentation)

docker image history app:baseline

ここで “巨大COPY” とか “依存を入れたRUN” がデカいのが見えると、改善方針がすぐ立ちます🔧✨

4-5. 起動時間を測る ▶️⏱️​

まずは「コンテナが立ってコマンドが返るまで」を測るのが簡単です👍

Measure-Command { docker run --rm app:baseline node -e "console.log('ok')" }

これで「起動そのもの」が重いのか、アプリ初期化が重いのか、切り分けの入口になります🚪

4-6. （任意）Dockerが食ってるディスク量を見る 🧹🗑️​

ビルドが遅い原因が「キャッシュやイメージが膨れてる」こともあります💥 まず現状を見える化👇（公式CLI）(Docker Documentation)

docker system df

5) “ファイルI/Oが遅い”の気配をつかむ（超かんたん版）📁🐢​

「ビルドはそんなに遅くないのに、開発がモッサリ…😇」は、**ファイル共有（マウント）**が原因のことが多いです。

Docker Desktop + WSL周りは、コードの置き場所で体感が変わる話が公式にまとまっています📌(Docker Documentation)

まずは“疑い”を持つためのミニテスト👇（ホスト側で実行）

node -e "const fs=require('fs'); const t=Date.now(); for(let i=0;i<2000;i++){fs.writeFileSync('tmp.txt','x'.repeat(1024)); fs.readFileSync('tmp.txt');} console.log(Date.now()-t,'ms')"
  • これを「プロジェクトを置いてる場所」を変えたときに測ると、差が出ることがあります📉📈 （※深掘りは第21章〜第22章でガッツリやります🪓✨）

6) よくある落とし穴（最初に踏みがち）🕳️😵‍💫​

  • --progress=plain を付けてないせいで どこが遅いか分からない 😭 (Docker ドキュメント)
  • compose でログが静かすぎるとき、オプションの付け方が変わってるケースあり（例：サブコマンドの前に付ける等）🧩 (GitHub)
  • サイズだけ見て「軽い！」と思ったら、実は レイヤが太い（historyで犯人が出ます）👀 (Docker Documentation)

7) 🤖AI活用：この章で使う“診断プロンプト”テンプレ​

7-1. BuildKitログから犯人を特定してもらう 🕵️‍♂️​

（--progress=plain のログを貼る）

  • 「このログから、時間が長いステップ上位5つを抜き出して、原因候補を3つずつ挙げて。Dockerfile変更は最小で。次章（キャッシュ改善）につながる順で！」

7-2. Dockerfileを“キャッシュ効く順”に直す案を出してもらう 🧱​

  • 「このDockerfileでキャッシュが壊れやすい行を指摘して。依存インストールが再実行されない形に並べ替え案を2パターン出して（npm/pnpm両対応の発想で）。」

7-3. イメージ肥大の犯人を当ててもらう 📦💥​

（docker image history の結果を貼る）

  • 「サイズが増えているレイヤ上位3つについて、“なぜ太るか”と“削る方法”を具体策で。やりすぎ最適化（可読性低下）も注意して。」

8) この章の提出物（次章に持っていくもの）🎒✨​

✅ perf-baseline.md が埋まっていればOK！ 最低限これ👇

  • Build time（1回目 / 2回目）⏱️
  • Slow steps top3 🕵️‍♂️
  • Image size 📦
  • Layer suspects top3 👀

次の第2章は、今日取ったベースラインを使って **「なぜキャッシュが効く/壊れるのか」**を“レイヤ”で理解していきます🧱⚡️