「チェックポイントの波」に溺れないために。PostgreSQLの影の功労者、バックグラウンドライターの話をしよう
やあ。データベースの運用、順調かな？
先日、若手のエンジニアが「DBの書き込み負荷が急に跳ね上がって、アプリケーションのレスポンスがカクつくんです」と相談に来たんだ。ログを見ると、案の定「チェックポイント（checkpoint）」によるI/Oスパイクが原因だった。
PostgreSQLを触っていると、どうしてもクエリのチューニングやインデックスの話に目が行きがちだよね。でも、大規模なトラフィックを捌くとき、本当に重要なのは「いかにしてディスクI/Oを平滑化するか」という視点なんだ。
今日は、その平滑化の主役である「バックグラウンドライター（bgwriter）」について、現場目線で深掘りしてみようと思う。
—
バックグラウンドライターって、結局何者？
簡単に言うと、「共有バッファ（Shared Buffers）上のダーティページを、チェックポイントを待たずに少しずつディスクへ書き出す掃除屋」だ。
PostgreSQLはメモリ（共有バッファ）上でデータをいじるけど、書き込みはすぐにはディスクに行かない。ダーティページ（更新されたけどディスクに反映されていないページ）が溜まると、どこかのタイミングで一気にディスクへフラッシュする必要がある。それが「チェックポイント」だ。
もしバックグラウンドライターがいなかったらどうなるか？
チェックポイントの瞬間に、溜まりに溜まったダーティページを全部ディスクに書き込もうとして、I/Oがボトルネックになり、システム全体が一時停止したような状態（I/O待ち）になってしまう。
バックグラウンドライターは、この「まとめてドン！」という負荷を、普段からコツコツと前倒しで処理することで、チェックポイント時の衝撃を和らげてくれているんだ。まさに縁の下の力持ちだね。
—
バックグラウンドライターを理解するための設定値
チューニングの話をするとき、まずは以下の3つのパラメータを `postgresql.conf` で確認してほしい。
- `bgwriter_delay`: 何ミリ秒ごとにループして処理を行うか（デフォルト: 200ms）
- `bgwriter_lru_maxpages`: 1回のループで何ページまで書き出せるか（デフォルト: 100）
- `bgwriter_lru_multiplier`: どれくらい積極的にキャッシュを解放するか
現場でよくある失敗は、闇雲にこの数値をいじってしまうこと。特に `bgwriter_lru_maxpages` を大きくしすぎると、バックグラウンドライター自体がI/Oを食いすぎて、本番のクエリの邪魔をしてしまう。「バランス」こそが全てだよ。
—
実際に「働いているか」を確認する術
「自分のDBのバックグラウンドライターはちゃんと仕事してるのか？」と不安になったら、次のSQLで統計情報を見てみよう。
SELECT
buffers_clean, — バックグラウンドライターが書き出した数
buffers_backend, — バックグラウンドライターが間に合わなくて、バックエンドプロセスが自分で書き出した数
buffers_checkpoint — チェックポイントで書き出された数
FROM pg_stat_bgwriter;
ここを見る際のポイントは `buffers_backend` だ。
もしこの数値が異常に増えているなら、バックグラウンドライターがサボっているか、あるいはI/Oのキャパシティに対して更新負荷が高すぎる証拠だ。クエリを投げたバックエンドプロセスが「あー、もう！自分で書くよ！」とディスクI/Oを肩代わりしている状態で、これが一番パフォーマンスを低下させる。
—
実践的なアドバイス：チェックポイントとの付き合い方
バックグラウンドライターを完璧に設定しても、チェックポイントの設定がガバガバだと意味がない。
よく「チェックポイントを減らすために `max_wal_size` を巨大にする」という手法をとる人がいるけれど、それだけだと今度はリカバリ（クラッシュ復旧）に時間がかかるというリスクを負うことになる。
僕が推奨する手順はこうだ：
1. `pg_stat_bgwriter` を監視する: `buffers_backend` が増えていないかチェックする。
2. `checkpoint_completion_target` を調整する: デフォルトの0.5から0.9程度に引き上げて、チェックポイントの書き込み時間を長くし、負荷をより平滑化させる。
3. I/Oのボトルネックを特定する: もしI/Oが追い付かないなら、バックグラウンドライターのせいにする前に、ディスクの性能（IOPS）やOS側の設定を見直す必要がある。
—
最後に：完璧な設定なんて存在しない
データベースのアーキテクチャを語るとき、僕はいつも「魔法の銀の弾丸はない」と言うことにしている。
バックグラウンドライターの設定も、ワークロードが「書き込み中心」なのか「読み取り中心」なのかによって、最適解は全く変わってくるんだ。だからこそ、自分の環境で負荷試験をして、統計情報をじっくり眺めて、少しずつ数字を動かす。この泥臭いプロセスを楽しめるかどうかが、優れたエンジニアになれるかの分かれ道だよ。
もし、この記事を読んで自分のDBの `pg_stat_bgwriter` を叩いてみて、何か不思議な挙動を見つけたら、またいつでも相談してくれ。一緒にログを読み解こう。
それでは、良いデータライフを！
コメント