やあ。今日もPostgreSQLと格闘してるかな？
今回は、データベースの「心臓部」とも言える、WALライター（WAL Writer）というプロセスについて話そうと思う。
正直、普段のクエリ発行で意識することはまずない機能だ。でもね、大規模なトランザクションをさばいたり、データベースが急にクラッシュした時の復旧速度を最適化しようとすると、こいつの挙動を知っているかどうかで、エンジニアとしての「格」が変わってくるんだよ。
—
WALライターって結局何者？
簡単に言うと、「メモリ上の変更記録を、安全なディスクへせっせと運び出す運び屋さん」だ。
PostgreSQLは、データを更新するとき、いきなりデータファイル（テーブルの実体）を書き換えるような無謀なことはしない。まずは変更内容を「WALバッファ」という共有メモリに書き込んで、トランザクションを完了させるんだ。
でも、メモリは揮発性だよね。もしここでOSが落ちたらデータは消える。だから、この変更ログを物理ファイル（WALセグメント）に書き出す必要がある。それを担っているのがWALライタープロセスだ。
なぜ「WALライター」がいるのか？
「えっ、じゃあWALバッファが溜まったら、ユーザーのトランザクションが自分でディスクに書き込めばいいんじゃないの？」
鋭いね。実はその通りなんだ。通常は、トランザクションがコミットするタイミングで、ユーザーのバックエンドプロセスが直接ディスクへの書き込み（fsync）を要求する。
じゃあ、なんでわざわざ「WALライター」なんていう独立したプロセスがいるのか。
答えは「書き込みの効率化（グループコミット）」のためだ。
高負荷な環境だと、何百ものプロセスが同時に「俺のログも書き込め！」「俺のもだ！」と押し寄せてくる。これを個別に処理してたらI/Oがボトルネックになってパンクするよね。そこでWALライターの出番だ。WALライターは定期的に（あるいはバッファが溢れそうになったら）メモリからログを回収し、まとめてディスクへ掃き出す。
これによって、個々のトランザクションの書き込みコストを劇的に下げているんだよ。
実務で意識すべき「wal_writer_delay」
さて、ここからは現場のエンジニアとしての実践的な話だ。
PostgreSQLの設定ファイル（`postgresql.conf`）に、`wal_writer_delay` というパラメータがある。これはWALライターがどれくらいの頻度でループして書き込みチェックを行うかを決めるものだ。
デフォルトは200ミリ秒
wal_writer_delay = 200ms
先輩からのアドバイス：この値をいじるべき時とは？
基本的にはデフォルトのままでいい。でも、もし君が「異常に高いトランザクション量」を扱うシステムを設計しているなら、少しチューニングの余地がある。
- 遅延を短くすると： WALがより頻繁にディスクに書き込まれるようになる。チェックポイントの負荷分散には寄与するけれど、CPU使用率が少し上がる。
- 遅延を長くすると： 一回の書き込み量が増える。I/Oのスループットは良くなるが、システムがクラッシュした際、メモリに残ったまま未書き込みになるログの量（＝データ消失リスク）が増える。
ただ、今のSSDは優秀だからね。闇雲にいじる前に、まずは `pg_stat_bgwriter` ビューを見て、WAL関連の統計情報を確認すること。
SELECT wal_writes, wal_write_time, wal_sync, wal_sync_time
FROM pg_stat_bgwriter;
ここで `wal_write_time` が異常に高かったり、ディスクI/Oが飽和しているなら、ディスク構成を見直すのが先決だ。WALを別ドライブにする、あるいはディスクのI/O性能を上げる。パラメータをいじるのは、物理的な限界が見えてからで十分だよ。
最後に：結局どう理解しておけばいい？
WALライターは、PostgreSQLという巨大な組織を裏で支える「事務職」のような存在だ。派手なクエリやインデックスのチューニングほど注目されないけれど、こいつがサボればデータベース全体がもたつくし、こいつが優秀ならシステムは軽快に動く。
もし誰かに「PostgreSQLの信頼性と高速性の両立ってどうやってるの？」と聞かれたら、こう答えてやってくれ。
「メモリでの高速処理と、WALライターによる効率的なグループコミットが、ACID特性と性能のバランスを絶妙に保っているんだよ」とね。
さて、今日はこれくらいにしておこう。次は「チェックポイント」の仕組みについて話せればと思う。あそこを理解すると、DBチューニングが一段と面白くなるぞ。
それじゃ、また現場で！
コメント