こんにちは！日々のコーディング、本当にお疲れ様です。
Go言語を使っていると、「なんか最近このAPIのレスポンスが重いな…」「メモリ使用量がじわじわ増えて、最終的にOOM Killer（Out of Memory）でコンテナが強制終了しちゃうんだけど、原因がどこにも見当たらないぞ…」なんて壁にぶぶつかったことはありませんか？
大規模なトラフィックをさばくWebサーバーや、常時稼働するマイクロサービスを開発していると、こうした「目に見えないボトルネック」や「ゴースト（幽霊）のようなメモリリーク」に頭を悩まされることが必ずと言っていいほどやってきます。
勘や経験則だけで「ここが遅いはずだ！」とアタリをつけてコードを書き直すのは、暗闇の中で手探りでボルトを締めるようなものです。運良く直ればいいですが、大抵は的外れに終わり、疲弊してしまいますよね。
そんなとき、あなたを救い出す最強の武器が、Go言語の標準ライブラリにひっそりと、しかし強力に備わっている `pprof` です。
今回は、この `pprof` を使って、CPUの消費箇所、メモリの割り当て、そして悪名高い「Goroutineリーク」をまるでレントゲン写真のように丸裸にし、スマートに解決する手法を一緒に見ていきましょう。これをマスターすれば、あなたのパフォーマンスチューニングの腕前は一気にプロの領域へ到達します。毎日のコーディングが、もっと自信に満ちた楽しいものになりますよ！
—
1. なぜ Goの `pprof` は「神ツール」と呼ばれるのか？
多くのプログラミング言語では、プロファイリングを行うためにサードパーティ製の重いエージェントを組み込んだり、商用の高価なモニタリングツールを導入したりする必要があります。しかし、Goの思想は違います。「言語のランタイム自体が、自己診断の能力を持つべきだ」という設計思想のもと、初期状態からプロファイリング機能がランタイムに組み込まれています。
ランタイム内部で何が起きているのか？
Goのランタイム（runtime）は、OSスレッドと軽量なGoroutineのスケジューリング、そしてガベージコレクション（GC）を自前で管理しています。
`pprof` を有効にすると、ランタイムは一定間隔（デフォルトのCPUプロファイルであれば1秒間に100回）でサンプリングを行い、「今、どの関数がどれだけのCPU時間を消費しているか」「ヒープメモリのどの部分でアロケーション（割当）が頻発しているか」「現在どんな状態のGoroutineがいくつ生きているか」といったデータを、極めて低いオーバーヘッド（通常数パーセント以内）で収集し続けます。
つまり、追加のプラグインなしで、本番環境の健康状態をミリ秒単位で正確に観測できるのです。この圧倒的な手軽さと精度が、`pprof` が世界中のシニアエンジニアに愛され続ける理由です。
—
2. 実践：わずか数行のコードでプロファイリングを有効化する
それでは、実際に手を動かして `pprof` の世界を体験しましょう。
ここでは、あえて「ちょっと怪しい動きをする（わざとメモリとGoroutineをリークさせる）HTTPサーバー」を題材にします。
サンプルコードの準備
以下のコードを `main.go` という名前で保存してください。
package main
import (
“fmt”
“log”
“net/http”
// 1. pprofのハンドラを自動登録するためにインポートします
// アンダースコア(_)をつけることで、パッケージのinit()関数のみを実行させます
_ “net/http/pprof”
“time”
)
// わざとメモリとGoroutineをリークさせる不穏な関数
func leakyHandler(w http.ResponseWriter, r http.Request) {
// 無限に増え続けるスライス（メモリリークの模擬）
// 呼び出されるたびに巨大な配列がヒープに蓄積されます
leakSlice := make([][]byte, 0, 10000)
for i := 0; i < 10000; i++ {
leakSlice = append(leakSlice, make([]byte, 1024)) // 1KB 10000 = 約10MBの消費
}
// 終了しないGoroutine（Goroutineリークの模擬）
// チャネルからの受信を永遠に待ち続けるため、親の処理が終わってもメモリに残り続けます
ch := make(chan struct{})
go func() {
// ここでずっとブロックされる
<-ch
}()
fmt.Fprintf(w, "Leaky operation executed! Check pprof.")
}
func main() {
// 通常のエンドポイントを登録
http.HandleFunc("/leak", leakyHandler)
// 2. net/http/pprofをインポートすると、
// 自動的にDefaultServeMuxに "/debug/pprof/" というパスの診断用エンドポイント群が生えます。
// ポート6060でデバッグ専用のHTTPサーバーを起動します。
fmt.Println("Starting debug server on http://localhost:6060")
go func() {
log.Println(http.ListenAndServe("localhost:6060", nil))
}()
// アプリケーション本体のサーバーをポート8080で起動
fmt.Println("Starting main server on http://localhost:8080")
log.Fatal(http.ListenAndServe(":8080", nil))
}
なぜ `net/http/pprof` をインポートするだけで動くのか？
Goの標準ライブラリである `net/http/pprof` は、パッケージの `init()` 関数内で、デフォルトのHTTPルーター（`http.DefaultServeMux`）に対して以下のようなエンドポイントを自動的に登録します。
- `/debug/pprof/` : プロファイルの概要とリンクの一覧
- `/debug/pprof/profile` : CPUプロファイル（デフォルトで30秒間サンプリング）
- `/debug/pprof/heap` : ヒープメモリの割り当て状況
- `/debug/pprof/goroutine` : すべてのGoroutineのスタックトレース
- `/debug/pprof/block` : 同期プリミティブ（Mutex等）のブロック競合状況
これによって、専用の管理画面を自分で一から作る必要がなくなるのです。
—
3. サーバーを起動して、あえて負荷をかけてみる
それでは、このアプリケーションを起動し、裏で何が起きているのかを覗き見してみましょう。
1. アプリケーションの起動
ターミナルを開き、以下のコマンドを実行します。
プログラムの実行
go run main.go
別のターミナルタブを開き、先ほどの「怪しいエンドポイント（`/leak`）」に負荷をかけて、あえてリーク状態を作り出します。ここでは `curl` コマンドを数回叩いてみましょう。
/leak エンドポイントを5回叩いて、メモリとGoroutineを意図的にリークさせます
for i in {1..5}; do
curl http://localhost:8080/leak
echo ” Request $i sent”
done
—
4. `go tool pprof` でボトルネックを徹底的に暴く
いよいよ本番です。Goのツールチェーンには、収集したプロファイルデータをリッチに分析するための `go tool pprof` というCLIツールが標準付属しています。
① Goroutineリークを特定する
まずは、アプリケーション内で「どのくらいのGoroutineが生き残っていて、どこでブロックされているのか」を確認します。
以下のコマンドを実行してください。ローカルサーバーの `/debug/pprof/goroutine` エンドポイントから直接データを取得し、対話モードに入ります。
実行中のGoroutineプロファイルを直接取得して対話モードへ入る
go tool pprof http://localhost:6060/debug/pprof/goroutine
コマンドを実行すると、次のようなプロンプトが表示されます。
Fetching profile over HTTP from http://localhost:6060/debug/pprof/goroutine
Saved profile in /Users/username/pprof/pprof.samples.goroutine.001.gz
Type: goroutine
Time: Oct 24, 2023 at 10:00am (JST)
Entering interactive mode (type “help”,-type “h” for help)
(pprof)
この対話モードの中で `top` と入力してみてください。
(pprof) top
Showing nodes accounting for 5, 100% of 5 total
————————————————-+—————–+
flat flat% sum% cum cum% functioin
5 100% 100% 5 100% main.leakyHandler.func1
0 0% 100% 5 100% net/http.(conn).serve
————————————————-+—————–+
おっ、出ました！
`main.leakyHandler.func1` が5件のGoroutineを保持してブロックしていることが一目瞭然です。先ほど `curl` で5回リクエストを送った回数と完全に一致していますね。
さらに、ここで `list leakyHandler` と入力してみましょう。コードのどの行でGoroutineが足止めされているのかが、ソースコードの行番号付きでピンポイント表示されます。
(pprof) list leakyHandler
Total: 5
ROUTINE ================= main.leakyHandler in /path/to/main.go
…
. . 28: ch := make(chan struct{})
. . 29: go func() {
. . 30: // ここでずっとブロックされる
. . 31: <-ch
. . 32: }()
...
「31行目のチャネル受信待ちでGoroutineが死なずに残っている！」ということが、ここまで鮮やかに特定できました。原因がわかれば、あとは「チャネルを適切にクローズする」「タイムアウトを設ける」「contextを使う」といった正しい修正を行うだけです。
② ヒープメモリの割り当てを可視化する（Web UIの活用）
次は、メモリの消費状況をビジュアルで確認してみましょう。CLIの対話も強力ですが、グラフ表示させるとさらに直感的に理解できます。
そのためには、お使いのPCに Graphviz（グラフ描画ツール）がインストールされている必要があります（Macなら `brew install graphviz`、Ubuntuなら `sudo apt-get install graphviz` でサクッと入ります）。
以下のコマンドを実行してください。`-http=:8081` オプションをつけることで、ブラウザ上で動くリッチなWeb UI（インタラクティブなフレームグラフやグラフネットワーク）を起動できます。
ヒープメモリのプロファイルをWeb UIで起動（ポート8081を使用）
go tool pprof -http=:8081 http://localhost:6060/debug/pprof/heap
コマンドを実行すると自動的にブラウザが立ち上がる（あるいは表示されたURLにアクセスする）はずです。
画面上部のメニューから 「View」 -> 「Graph」 または 「Flame Graph」 を選択してみてください。
- Flame Graph（フレイムグラフ）の読み方:
横軸がメモリの割り当て量（またはCPU使用率）、縦軸が関数の呼び出しスタック（コールスタック）を表しています。横幅が広い関数ほど、リソースを多く食っている（悪さをしている）ことになります。
フレイムグラフを見れば、どの親関数からどのサブルーチンへ降りていったときにメモリが爆発しているのかが一目でわかります。
—
5. 現場で役立つ！プロファイリング運用の黄金律
最後に、シニアエンジニアとして実務現場で `pprof` を運用する際の「知恵」をいくつかシェアします。
1. 本番環境への適用時はエンドポイントの保護を忘れずに
`net/http/pprof` をそのまま公開すると、誰でも内部のメモリ構造やGoroutineのスタックトレースを覗き見できてしまい、セキュリティ上の脆弱性（情報漏洩）につながります。本番環境では、独自のエンドポイント（例: `/internal/debug/pprof/`）に手動でルーティングし、Basic認証や社内IP制限、あるいはAdmin用VPN経由でのみアクセスできるように必ずガードをかけましょう。
2. CPUプロファイルは「期間」を指定して取得する
`/debug/pprof/profile` にブラウザでアクセスすると、デフォルトで 30秒間 サーバーがブロッキングされ、その間のCPU使用状況をサンプリングします。そのため、高負荷な本番環境で安易にリロードすると、一時的にレスポンスが遅延することがあります。本番で取得する際は、コマンドラインから秒数を指定してスマートに取得するのがプロの技です。
# 10秒間だけCPUプロファイルを採取してローカルに保存
go tool pprof -seconds=10 http://localhost:6060/debug/pprof/profile
3. 定期的なContinuous Profiling（継続的プロファイル）の視野を持つ
開発環境でのスポット的なプロファイリングだけでなく、昨今では Datadog、Pyroscope、Google Cloud Profilerなどのツールを使って、本番環境のプロファイルデータを定常的に収集・蓄積する「継続的プロファイリング」が主流になりつつあります。「昨日のリリース以来、じわじわとメモリ消費のベースラインが上がっている」といった長期的な変化も、これらを導入すれば一発で検知できるようになります。
—
まとめ
いかがでしたでしょうか？
Go言語の `pprof` は、一見すると難しそうに見えますが、本質を理解してしまえばこれほど心強い相棒はいません。
- 「勘」でコードを直すのではなく、「データ」に基づいてボトルネックを特定する。
- CLIの `top` や `list`、そしてWeb UIのグラフを活用して、リソースの偏りを視覚化する。
- Goroutineやヒープのリークを早期に発見し、堅牢なバックエンドシステムを作り上げる。
このステップを踏むだけで、あなたの書くGoコードの品質とパフォーマンスは劇的に向上します。「あ、最近システムの挙動が怪しいな」と思ったその瞬間に、サクッと `go tool pprof` を叩けるエンジニアになって、周囲をアッと言わせてやりましょう！
あなたの開発ライフが、より快適で知的でエキサイティングなものになりますように。
それではまた、次の技術でお会いしましょう！