「チェックポイント」を飼い慣らす：PostgreSQLのリカバリ時間とI/Oの狭間で
PostgreSQLを運用していると、必ず一度は頭を抱えるのが「チェックポイント」のチューニングです。`max_wal_size` をどれくらいに設定するか。この数字一つで、システムのリカバリ時間（RTO）と書き込みパフォーマンスのバランスが劇的に変わる。まさに、DBエンジニアとしての腕の見せ所と言えるでしょう。
今日は、教科書的な説明は一旦置いておいて、PostgreSQLの内部で何が起きているのか、そしてなぜこの設定がこれほどまでに「厄介」なのか、現場の視点から掘り下げてみたいと思います。
—
チェックポイントの正体：矛盾する二つの要求
ご存知の通り、PostgreSQLはWAL（Write Ahead Log）を書き込むことでデータの整合性を担保しています。しかし、全てをWALに書き出し続けるわけにはいきません。もしクラッシュリカバリのたびに、数テラバイトあるWALを先頭からリプレイしていたら、サービスはいつまで経っても復旧しませんよね。
そこで登場するのが「チェックポイント」です。
チェックポイントは、メモリ上のダーティページ（更新されたデータ）を物理ディスク上のデータファイルへ「強制的に掃き出す」イベントです。このプロセスには、実は二つの矛盾する要求が同居しています。
1. RTOの短縮： チェックポイントを頻繁に行えば、リカバリ時にリプレイするWALは少なくて済む。
2. I/Oの平滑化： チェックポイントを控えめにすれば、ディスクの書き込み負荷を分散できる。
この「頻繁さ」を規定するのが、`max_wal_size` と `checkpoint_timeout` です。
「max_wal_size」が引き起こすI/Oの嵐
多くのエンジニアが陥る罠が、`max_wal_size` を過剰に小さく設定することです。
「リカバリを速くしたいから」という理由でこの値を絞ると、WALの生成速度が早まった瞬間に、システムは「あ、もう制限に達した。今すぐチェックポイントだ！」と頻繁にトリガーを引くようになります。
ここで発生するのが、I/Oのスパイクです。
チェックポイントが走ると、バックグラウンドライタやチェックポインタが、メモリ上のダーティページをまとめてディスクへフラッシュします。この瞬間、ディスクI/Oは飽和し、メインのトランザクション処理が「待ち」の状態になる。つまり、設定を詰めすぎた結果、かえって普段のパフォーマンスを殺してしまうわけです。
パフォーマンストラブルシューティングの勘所
もし、あなたが「なぜか時々クエリが重くなる」「特定のタイミングでレイテンシが跳ねる」という事象に悩んでいるなら、まずは `log_checkpoints = on` に設定して、ログを覗いてみてください。
ログには、チェックポイントにかかった時間や、書き出されたバッファの数が記録されます。ここで注目すべきは、「チェックポイントの頻度」と「I/O負荷の相関」です。
- チェックポイントが短時間で頻発している場合：
`max_wal_size` を引き上げる検討が必要です。近年の高速なNVMeストレージであれば、ある程度（例えば16GB〜64GB以上など）まで許容値を広げても、リカバリ時間が許容範囲内であればパフォーマンス向上の恩恵の方が大きくなります。
- チェックポイントの書き込みが重すぎてレイテンシが出る場合：
`checkpoint_completion_target` を調整しましょう。デフォルトは0.9ですが、これを調整することで、チェックポイントの書き込みをより緩やかに分散させることができます。
最後に：絶対的な正解はない
結局のところ、PostgreSQLのチューニングに「魔法の数値」はありません。
- ワークロードがバッチ処理中心なのか、OLTPなのか。
- ストレージの物理的なスペックはどれくらいか。
- ビジネスが許容するRTOはどれくらいか。
これらをすべて加味した上で、最後に残るのが「運用しながら微調整する」という泥臭い作業です。`pg_stat_bgwriter` を見て、`checkpoints_timed` と `checkpoints_req` の比率を眺める。もし `checkpoints_req` が多すぎるなら、それはシステムが「チェックポイントが足りないよ！」と悲鳴を上げている証拠です。
データベースは、いわば生き物です。アーキテクチャを深く理解し、システムの呼吸（I/Oの波）を感じ取れるようになれば、チェックポイントの設定は怖くありません。ぜひ、あなたの環境でも一度ログを覗いてみてください。そこには、まだ見ぬ最適化のヒントが眠っているはずです。
コメント