【実務・中級編】永続化設定 – Redis

Redis永続化の真実：アーキテクチャの妥協点と「死なない」設計

Redisを単なる「爆速なキャッシュ」と呼ぶのは、エンジニアとしてあまりに短絡的だ。Redisは、メモリという極めて高速だが揮発性の高い領域を、いかにして「堅牢なデータストア」へと昇華させるかという、アーキテクチャ上の壮大な綱渡りを体現している。

多くの開発者が、デフォルト設定のまま本番環境に投入し、ある日突然の障害でデータを消失させて青ざめる。そうならないための、Redis永続化の深淵を解説しよう。

—

永続化には二つの道がある。RDB（スナップショット）とAOF（ログ追記）だ。

RDBは、特定の時点におけるデータセット全体のコピーをバイナリファイル（`dump.rdb`）として書き出す。

AOFは、Redisが受け取った全ての書き込み命令をログファイルに追記し続ける。

—

RDBの設定において、多くのエンジニアが犯すミスは「過剰な頻度の保存」だ。`save`設定を頻繁に行うと、`fork()`によるメモリコピー（Copy-on-Write）が頻発し、OSがメモリ不足に陥るリスクがある。

賢いRDB設定の例
N秒以内にM回以上の変更があったら保存せよ
save 3600 1 # 1時間で1回変更があれば保存
save 300 100 # 5分で100回変更があれば保存
save 60 10000 # 1分で10000回変更があれば保存

リードの助言:
「高負荷なシステムで `save 60 1` のような設定を置くのは自殺行為だ。スナップショットはあくまで『災害復旧用』と割り切り、バックアップの頻度とパフォーマンスのバランスをプロファイリングで決定しろ。」

—

AOFの肝は `appendfsync` 設定だ。ここには明確なトレードオフがある。

appendfsync always: 一命令ごとにfsync。最強だが遅い。
appendfsync everysec: 1秒ごとにfsync。バランスが良い。推奨。
appendfsync no: OS任せ。速いがデータ消失リスクあり。
appendfsync everysec

実務の現場では、`everysec` 一択と考えていい。`always`はディスクI/OのボトルネックでRedisの真価である「レイテンシ」を殺す。`no`は論外だ。`everysec`であれば、万が一の障害時でも「最大1秒前」までのデータ損失という、運用上許容可能な範囲に収められる。

—

高可用性（HA）を担保するアーキテクトであれば、以下の構成を推奨する。

Redis 4.0から導入された機能だ。RDBとAOFを組み合わせ、スナップショットの高速復旧とAOFのデータ保護を両立させる。

ログ書き換え時にRDBを先頭に含める
aof-use-rdb-preamble yes

マスターノードで永続化をゴリゴリ回すのは避けろ。「レプリカノードに永続化を任せる」のが鉄則だ。マスターは書き込み処理に専念させ、レプリカ側でAOFを有効にしてバックアップを作成する。これにより、マスターのパフォーマンス低下を防ぎつつ、データ保全を実現できる。

`fsync`のタイミングをどれだけ調整しても、OSレベルのバッファキャッシュやディスクの物理障害は防げない。真に重要なデータであれば、Redisだけに依存せず、必ず永続化ストレージ（RDBMSなど）を併用する「キャッシュ・アサイド・パターン」を徹底すべきだ。

—

Redisの永続化を語る上で最も重要なことは、「Redisは100%のデータ保護を保証するデータベースではない」という事実を受け入れることだ。

永続化設定は「どれだけパフォーマンスを犠牲にして、どれだけのデータ損失を許容するか」という、ビジネス要件との交渉術に他ならない。

これらを理解し、システムの性格に応じて適切にチューニングすること。それが、Redisという猛獣を飼い慣らす唯一の道だ。

さあ、次は君のアーキテクチャで、この設定をどう最適化するか教えてほしい。コードレビューはいつでも歓迎する。