PostgreSQLのチェックポイント：その「設定」で、障害時の復旧時間は守れるか？
「データベースが落ちた！ 早く復旧させなきゃ！」
そんな緊急事態の現場で、真っ青になりながらリカバリの進捗バーを見つめた経験はありますか？ PostgreSQLが起動する際、WAL（Write Ahead Log）を再生して整合性を取りますよね。あの時間がやけに長く感じられたなら、原因は十中八九「チェックポイントの頻度とWALの容量設定」にあります。
今日は、教科書には載っているけれど、意外と現場で「デフォルトのまま」放置されがちなチェックポイントの仕組みと、実務的なチューニングの考え方について話そうと思います。
—
チェックポイントは「整理整頓の儀式」
PostgreSQLのアーキテクチャを理解する上で、チェックポイントは避けて通れません。
ざっくり言うと、メモリ上（共有バッファ）で更新されたデータは、すぐには物理ファイル（データファイル）に書き込まれません。高速化のために「とりあえずWALに書き込んで、データファイルへの反映は後でまとめてやろう」という戦略をとっているからです。
でも、この「後で」を放置すると、障害が起きた時にWALの最初から最後まで全部やり直す羽目になり、復旧に数時間かかる……なんて大惨事になります。
そこで、定期的に「よし、今のメモリ上の変更を全部データファイルに書き出そう！」と号令をかけるのがチェックポイントです。
—
制御の肝：max_wal_size と checkpoint_timeout
このチェックポイントをいつ発生させるかを決めるのが、主に以下の2つの設定値です。
1. checkpoint_timeout: 「時間が経ったからやる」という時間ベースのトリガー。
2. max_wal_size: 「WALが溜まりすぎたからやる」という容量ベースのトリガー。
現場で一番悩ましいのが、「この2つのバランスをどう取るか」です。
1. checkpoint_timeout を短くしすぎると？
「5分でチェックポイントを走らせれば安心だよね！」と思いがちですが、これは罠です。チェックポイントはディスクへの大量書き込みを伴うため、頻発するとIO負荷が上がり、データベース全体のパフォーマンスを食いつぶします。
2. max_wal_size を大きくしすぎると？
逆に、これを大きくしすぎると、チェックポイントがなかなか発生しません。一見パフォーマンスは良いのですが、いざ障害が起きた時のWAL再生量が増え、リカバリ時間（RTO）が長大化します。
—
実務での設定指針：まずは「ログ」を見よう
「結局、設定値は何がいいの？」と聞かれたら、僕はいつもこう答えます。「まずはログを見て、今どうなっているかを知ることから始めよう」と。
PostgreSQLの設定ファイルで `log_checkpoints = on` にして、ログを確認してみてください。
ログ出力例
checkpoint starting: time
checkpoint complete: wrote 1234 buffers (9.4%); 0 WAL file(s) added, 0 removed, 12 recycled; …
もし、`checkpoint starting` が頻繁に出ているなら、IOが常にビジー状態である可能性が高い。逆に、`checkpoint starting: wal` という理由が頻発しているなら、`max_wal_size` が負荷に対して小さすぎます。
推奨するチューニングのステップ
1. RTO（目標復旧時間）を決める: 「障害発生から10分以内にサービス復旧」という要件があるなら、WALの再生時間がそれに収まるように計算します。
2. 負荷のピークを測る: 普段のトラフィックで、どれくらいのWALが生成されているかを確認します。
3. 設定値の調整: 僕は多くのWebアプリケーション環境では、`checkpoint_timeout` は15〜30分程度、`max_wal_size` は「WALが生成される速度 × 30〜60分」程度から始めることが多いです。
— 現在の設定確認
SHOW checkpoint_timeout;
SHOW max_wal_size;
— 設定変更の例（postgresql.conf）
checkpoint_timeout = 15min
max_wal_size = 4GB
—
後輩エンジニアへ伝えたいこと
最後にひとつだけ。「完璧な設定値」というのは存在しません。
DBの負荷はアプリケーションの成長とともに変わります。今日最適だった設定も、半年後にはボトルネックになるかもしれません。だからこそ、監視が重要です。`pg_stat_bgwriter` ビューを使って、チェックポイントが何回発生しているか、どれくらいの頻度で起きているかを定期的にモニタリングしてください。
— チェックポイントの統計情報を見る
SELECT checkpoints_timed, checkpoints_req, buffers_checkpoint
FROM pg_stat_bgwriter;
`checkpoints_req`（強制発生）が多すぎる場合は、`max_wal_size` を見直すサインです。
データベースのチューニングは「正解を当てる」ことではなく、「システムの性格に合わせて寄り添うこと」です。まずはログを確認する癖をつけて、自分の守っているデータベースの「呼吸の速さ」を感じ取れるようになると、ぐっとエンジニアとして強くなれますよ。
さて、今日はこの辺で。また何か詰まったら聞きに来てくださいね！
コメント