【実務・中級編】 rdb-save-incremental-fsync設定 – Redis

Redis RDB永続化の真髄：`rdb-save-incremental-fsync`が解き放つI/Oの呪縛

諸君、Redisのパフォーマンスチューニング、特に永続化機構に関してどれほどの深淵を覗き込んでいるだろうか？多くのエンジニアは、`BGSAVE`がバックグラウンドで動き、親プロセスをブロックしないという表面的な理解に留まりがちだ。しかし、この「バックグラウンド」という言葉の裏には、我々が直面しうる最も苛烈なボトルネック、すなわちディスクI/Oのスパイクが潜んでいる。

今日は、そのI/Oの呪縛を解き放つための、Redis 7.0以降で導入された極めて強力な設定、`rdb-save-incremental-fsync`について、その本質から実践的な活用まで、私の知見のすべてを共有しよう。これは単なる設定項目ではない。システム全体の安定性とパフォーマンスを根本から見直すための、設計思想そのものだ。

—

第1章：RDB永続化の光と影 ― なぜI/Oスパイクは問題なのか

まず、RedisのRDB永続化がどのように動作するかを簡潔に復習しよう。

1. `BGSAVE`コマンドの実行: Redisサーバーは`fork()`システムコールを発行し、子プロセスを生成する。
2. コピーオンライト (CoW): 子プロセスは親プロセスのメモリイメージを継承するが、実際の物理メモリは共有される。親プロセスがメモリを変更しようとすると、変更箇所のみがコピーされ、子プロセスは変更前のデータを参照し続ける。
3. RDBファイルの書き込み: 子プロセスは継承したメモリイメージからRDBファイルを生成し、ディスクに書き込む。

このメカニズムは素晴らしい。親プロセスはクライアントリクエストを処理し続け、サービスの可用性を損なわない。しかし、ここで一つの大きな「影」が生まれる。

RDBファイル生成時のディスクI/Oの集中だ。

RDBファイルは、Redisのデータセット全体のスナップショットであるため、そのサイズはGB単位になることも珍しくない。この巨大なデータを一度にディスクに書き込む際、OSのページキャッシュを経由するとはいえ、最終的には大量のI/O操作がディスクに集中する。

何が問題か？:
レイテンシースパイク: ディスクへの書き込みが集中すると、ディスクキューが飽和し、他のI/O要求（AOFのfsync、OSのメタデータ操作、場合によってはRedis以外のプロセスI/O）のレイテンシーが劇的に悪化する。
サービス品質の低下: Redis自体のコマンド処理レイテンシーが悪化するだけでなく、同一ホスト上の他のサービスや、共有ストレージ（NFS、SAN、クラウドの汎用ブロックストレージなど）を利用している他のインスタンスにも影響が波及する。
メモリ解放の遅延: RDB書き込み中にOSのページキャッシュが大量のダーティページで占められ、メモリ不足を誘発したり、ページの解放が遅れたりする可能性もある。

従来の対策としては、RDB保存間隔の調整、より高速なディスク（SSD/NVMe）、I/Oスケジューラの調整（cfqからnoop/deadlineなど）、またはI/O分離（専用ディスク/LVM）などが考えられてきた。しかし、これらは根本的な解決策にはならず、特に共有ストレージ環境下では限界があった。

—

第2章：`rdb-save-incremental-fsync`の核心 ― I/Oスパイクの平滑化

この長年の課題に対するRedis 7.0からの回答が、`rdb-save-incremental-fsync`だ。

この設定は、RDBファイル書き込み中に指定されたバイト数ごとに`fsync()`システムコールを呼び出すことで、ディスクI/Oの集中を「平滑化」することを目的としている。

2.1. `fsync()`の役割

ここで`fsync()`の役割を再認識しよう。

`fsync()`は、指定されたファイルディスクリプタに関連付けられたメモリ上のすべての変更（ダーティページ）を、OSのページキャッシュから物理ディスクに強制的に書き込むシステムコールだ。これにより、OSやアプリケーションのクラッシュ時にもデータが失われないことが保証される。

通常、RDBファイルは書き込み完了後に一度だけ`fsync()`される。しかし、`rdb-save-incremental-fsync`を有効にすると、RDBファイル書き込みの子プロセスは、例えば1MBごとに`fsync()`を呼び出すようになる。

2.2. なぜ平滑化されるのか？

小刻みな書き込み: 巨大なRDBファイル全体を一気に書き込むのではなく、小さなチャンク（例えば1MB）ごとにディスクへの同期書き込みを行う。
I/Oの分散: これにより、一度の`fsync()`が処理するデータ量が減り、ディスクへのI/O負荷が時間的に分散される。ディスクキューが飽和する時間を短縮し、I/Oレイテンシーのスパイクを抑制する効果が期待できる。
他のI/Oへの影響緩和: RedisのRDB書き込みがディスクを独占する時間を減らし、OSや他のアプリケーションのI/O要求がスムーズに処理される可能性を高める。

これは、大規模データセットを持つRedisインスタンスや、I/O性能がボトルネックになりがちな共有ストレージ環境において、システム全体の安定性を劇的に向上させる可能性を秘めた機能だ。

—

第3章：実践的な設定と最適化

では、この強力な設定をどのように活用すべきか。

3.1. 設定方法

`redis.conf`に以下の行を追加する。

rdb-save-incremental-fsync
RDBファイル書き込み中に、指定されたバイト数ごとにfsyncを実行します。
これにより、RDB書き込み時のディスクI/Oスパイクを平滑化し、
システム全体のI/Oレイテンシーへの影響を抑制します。
デフォルトは無効 (0)。有効にする場合は、例えば 1MB (1048576 バイト) を指定します。
適切な値は、ディスクの種類、I/O負荷パターン、RDBファイルサイズによって異なります。
rdb-save-incremental-fsync 1048576 # 例: 1MBごとにfsync

3.2. 設定値の選び方と考慮事項

`rdb-save-incremental-fsync`の値は、まさにトレードオフの芸術だ。

値が小さすぎる場合:
`fsync()`システムコール自体のオーバーヘッドが相対的に大きくなる。
`fsync()`は同期的な操作であり、その呼び出し頻度が高くなると、RDB書き込みプロセス全体の完了時間が長くなる可能性がある。
値が大きすぎる場合:
`fsync()`の目的であるI/Oスパイクの平滑化効果が薄れる。
依然として大きなチャンクが一度に書き込まれるため、一時的なI/O飽和を招く可能性がある。

推奨されるアプローチ:

1. 初期値の選定: 1MB (1048576バイト) または4MB (4194304バイト) 程度から始めるのが妥当だろう。これは、一般的なOSのページサイズやファイルシステムのブロックサイズを考慮した数値だ。
2. 徹底したモニタリング:

ディスクI/O利用率 (util): `iostat`や`sar -d`などで確認。RDB保存中のピーク値が以前と比べて下がっているか。
I/O待ち時間 (await/svctm): ディスクへのI/Oリクエストの平均待ち時間。これが安定しているか。
Redisコマンドレイテンシー: `redis-cli –latency` や Prometheus/Grafana などのメトリクスで、RDB保存中のP99/P99.9レイテンシーの変化を注視する。
RDB保存完了時間: 設定変更によってRDB保存自体にかかる時間が極端に増えていないか。

3. A/Bテストとベンチマーク: 本番環境に導入する前に、開発/ステージング環境で実際のワークロードに近い条件でテストを行う。設定値を段階的に変更し、最適なバランス点を見つけ出す。
4. 環境依存性:

ディスクの種類: NVMe SSDのような超高速ストレージでは、`fsync`のレイテンシーが低いため、この設定の恩恵はHDDほど劇的ではないかもしれないが、それでもキューイングによるスパイクは回避できる。
クラウド環境: AWS EBSやGCP Persistent Diskなどの共有ブロックストレージでは、プロビジョニングされたIOPS制限やバーストクレジットと密接に関連する。この設定は、バーストクレジットの枯渇を防ぎ、安定したI/O性能を維持するのに役立つ可能性がある。

—

第4章：堅牢な設計パターンと運用上の『極限の知見』

`rdb-save-incremental-fsync`は強力なツールだが、それはシステム全体の堅牢性を高めるための「ピース」の一つに過ぎない。伝説のアーキテクトとして、さらに踏み込んだ知見を共有しよう。

4.1. モニタリングの深化 ― I/Oだけを見るな

単にディスクI/Oのグラフが平坦になったからといって安心するなかれ。

CPU利用率: RDB子プロセスが`fsync`でブロックされている間、CPUはアイドル状態になる。これが全体的なCPU利用パターンにどう影響するか。I/O待機がCPU利用率を不必要に押し下げる場合、より大きなチャンクサイズを検討する余地がある。
メモリとページキャッシュ: RDB書き込み中のダーティページ数、キャッシュヒット率、スワッピングの発生。これらが異常な挙動を示していないか。
システムコールトレース: `strace`などを用いてRDB子プロセスの`fsync`呼び出し頻度や時間を詳細に分析することで、設定値の妥当性をより深く検証できる。

4.2. AOFとの関係性 ― 永続化の二面性

`rdb-save-incremental-fsync`はRDBの課題に特化したものだが、Redisの永続化にはAOFもある。

AOFの`appendfsync`: AOFは通常、`everysec`や`always`などの設定で、常に`fsync`を小刻みに実行している。これはトランザクションログとしての性質上、データの耐久性を高めるためだ。
相互作用: AOFとRDBが同時に永続化を実行する場合、両者からのディスクI/O要求が競合する可能性がある。`rdb-save-incremental-fsync`は、この競合によるRDB側のI/Oスパイクを緩和する効果が期待できる。
設計原則: どちらの永続化メカニズムを主軸にするか、あるいは両方を使うかによって、I/O設計は大きく変わる。AOFを主軸とするならば、RDBは定期的なバックアップや高速なリストア手段として位置づけられ、RDBのI/Oスパイク緩和はさらなる安定性向上に寄与する。

4.3. Master-Slaveアーキテクチャでの考慮

スレーブインスタンスは、マスターからRDBファイルを同期する際にも、ディスクへの書き込みを行う。

スレーブ側のI/O: マスターで`rdb-save-incremental-fsync`が有効でも、スレーブがマスターから受け取ったRDBファイルを書き込む際には、スレーブ自身のI/O特性が重要になる。スレーブ側でも同様にI/Oスパイクが発生しうるため、スレーブのディスク性能や`rdb-save-incremental-fsync`設定も考慮に入れるべきだ。
フェイルオーバーの安定性: スレーブが健全な状態でRDBを保持していることは、フェイルオーバー時のデータ整合性と復旧速度に直結する。スレーブ側の安定したRDB書き込みは、システム全体の堅牢性を高める。

4.4. 抽象化されたI/Oと物理的な現実

クラウド環境では、ディスクはEBSやPersistent Diskといった抽象化されたサービスとして提供される。これにより、物理的なディスクの特性が見えにくくなる。

IOPSとスループット: プロビジョニングされたIOPSやスループットの制限を常に意識する。`rdb-save-incremental-fsync`は、瞬間的なIOPSバーストを抑え、プロビジョニングされた制限内で安定した性能を維持するのに役立つ。
共有ストレージのノイズ: クラウド環境では、隣接するVMインスタンスのI/Oが自社のインスタンスに影響を与える「ノイジーネイバー」問題が存在する。この設定は、少なくとも自社のRedisインスタンスがI/Oノイズの発生源になることを緩和し、他のサービスへの影響を最小限に抑えることができる。

—

第5章：結論 ― 見えないI/Oを制御する

`rdb-save-incremental-fsync`は、Redisが長年にわたり抱えてきたディスクI/Oスパイクという課題に対し、極めてスマートかつ実践的な解決策を提供する。これは、単にRDBファイルの書き込みを速くする設定ではない。むしろ、書き込みプロセスをより賢く、より周囲と協調的にするための設定だ。

この設定を導入する際には、安易なコピペではなく、自社の環境におけるディスク特性、I/Oパターン、そしてRedisのワークロードを深く理解した上で、慎重にテストとモニタリングを行う必要がある。最適な値は環境によって異なり、まさに「チューニング」の腕の見せ所だ。

我々エンジニアの使命は、システムの裏側で蠢く見えないボトルネックを特定し、それを制御下に置くことだ。`rdb-save-incremental-fsync`は、そのための強力な武器となる。この知見を胸に、諸君が担当するRedisインスタンスを、より堅牢に、より高性能に進化させることを期待する。

常に深く考え、表面的な現象に惑わされず、本質を見抜く目を養うこと。それが、伝説への道だ。