氷河期を生き抜くRedisアーキテクチャ：`dir` ディレクティブの底にあるOSカーネルとI/Oの深淵
データベースのアーキテクチャにおいて、ストレージへの永続化は常にパフォーマンスとのトレードオフである。インメモリデータベースであるRedisにおいても例外ではない。数千万QPSを捌くインメモリの要塞であっても、最終的には揮発性の壁を越え、物理的な不揮発性ストレージへデータを刻み込まなければならない。
その永続化の起点、すべての起点となるのが `dir` 設定である。
たった1行、`dir /var/lib/redis` と書き記すだけのシンプルなディレクティブ。しかし、この設定が指し示すディレクトリの選定とOSカーネルレベルの挙動を誤れば、深夜のPagerDuty鳴り響く地獄へと直結する。
本稿では、単なる「RDBやAOFを置く場所」という初歩的な解説を超え、LinuxカーネルのVFS（仮想ファイルシステム）、ページキャッシュ、ディスクI/Oのメカニズムに至るまで、Redisの `dir` を巡る極限の知見を解き明かす。
—
1. `dir` 設定の正体：プロセス空間とファイルシステムの接点
Redisプロセスが起動し、設定ファイルをパースした瞬間、メインスレッドは指定されたパスに対して何を行っているか。
`dir` ディレクティブは、単に文字列としてパスを保持しているだけではない。Redisは内部で `chdir()` システムコールを呼び出し、自身のカレントワーキングディレクトリ（CWD）を明示的に変更する。
/ server.c の初期化シーケンスにおける概念的コード /
if (server.config_file) {
// dir設定で指定されたパスへカレントディレクトリを変更
if (chdir(server.config_dir) == -1) {
serverLog(LL_WARNING, “Fatal error: Can’t chdir to ‘%s’: %s”,
server.config_dir, strerror(errno));
exit(1);
}
}
なぜわざわざ `chdir()` を行うのか？
それは、Redisが動的に生成するバックグラウンドファイル（RDBの `dump.rdb` や AOFの `appendonly.aof`、さらにはreplicationのテンポラリファイル）を生成する際、相対パス指定で堅牢かつ簡潔にファイルディスクリプタを開くためである。
しかし、この「カレントディレクトリをプロセス全体で共有する」というUNIXの基本設計こそが、コンテナ環境やマルチプロセス運用において最初の罠となる。
—
2. カーネル視点で見る `dir`：VFS、マウント名前空間、そしてI/Oバリア
熟練のアーキテクトであれば、`dir` に指定するパスが「単なるローカルディスクのパス」ではないことを知っているはずだ。現代のインフラストラクチャにおいて、そのディレクトリの背後には以下のレイヤーが潜んでいる。
1. ファイルシステムの種類（Ext4 vs XFS）
2. ストレージデバイスの特性（NVMe vs EBS / Persistent Disk）
3. OSのページキャッシュとダーティページフラッシュ制御
RDBスナップショット（`BGSAVE`）時の一撃
Redisが `BGSAVE` を実行するとき、伝説的な `fork()` システムコールが呼び出され、Copy-On-Write (COW) 空間が生成される。子プロセスは、`dir` で指定されたディレクトリ内に一時ファイル（例: `temp-12345.rdb`）を生成し、そこにメモリ上の全キースペースをシリアライズして流し込む。
この時、もし `dir` がネットワークストレージ（NFSやEFSなど）を向いていた場合どうなるか？
想像してほしい。数10GBのメモリを持つインスタンスが `BGSAVE` を走らせた瞬間、ネットワーク帯域が飽和し、カーネルのTCPバッファが溢れ、最終的にRedisの子プロセスがI/Oウェイトでフリーズする。親プロセス（メインスレッド）は直接I/Oを行わないためクライアントの応答は継続するが、OSの仮想メモリ管理機構（VM）におけるCOWのページ複製が遅延し、親プロセスのメモリ消費量が雪だるま式に膨れ上がる。結果として、Linux OOM Killerの餌食となる。
> アーキテクトの戒め:
> `dir` に指定するパスは、絶対に低レイテンシかつ高スループットなローカルNVMe上のファイルシステム（推奨は XFS）でなければならない。共有ストレージを `dir` に指定することは、自らシステムに爆弾を抱えると同義である。
—
3. 権限とセキュリティ：権限剥奪（Privilege Drop）の罠
「十分な書き込み権限が必要です」というリファレンスの記述は、単に `chmod 755` をしておけという意味ではない。
Redisはセキュリティ上の理由から、特権ユーザー（root）で起動された後、安全のために非特権ユーザー（例: `redis:redis`）へと権限を降格（Privilege Drop）させる機能を持っている。
ここで発生しがちな致命的なインシデントのシーケンスを見てみよう。
1. `redis.conf` で `dir /var/lib/redis` と指定。
2. ディレクトリの所有者が `root:root` かつ パーミッションが `700` になっている。
3. Redisが `root` で起動を試み、`dir` を読み込んだ後、内部で `setuid()` を実行して `redis` ユーザーに降格。
4. その後、何らかのトリガーで `BGSAVE` が走り、子プロセスが `temp-.rdb` を作ろうとした瞬間 —— Permission Denied。
[12345] 01 Jan 00:00:00.000 # 致命的エラー: RDB保存用のテンポラリファイルを開けません: Permission denied
このエラーが発生した際、Redisはクラッシュこそしない（ロギングして継続する）が、永続化データが一切更新されない状態に陥る。監視が甘ければ、ハードウェア障害や再起動時にデータが数日前（あるいは起動時）の状態に巻き戻るという悪夢を見る。
究極のディレクトリパーミッション設定
実務レベルの本番環境では、以下のスクリプト的アプローチで `dir` の要塞化を行うべきである。
ディレクトリの作成と厳格なオーナーシップの付与
sudo mkdir -p /var/lib/redis
sudo chown redis:redis /var/lib/redis
sudo chmod 750 /var/lib/redis
SELinux / AppArmor環境下でのコンテキスト確認 (RHEL/CentOS系の場合)
sudo semanage fcontext -a -t redis_var_lib_t “/var/lib/redis(/.)?”
sudo restorecon -Rv /var/lib/redis
—
4. ディスク容量枯渇時のカーネル挙動とRedisの防衛策
「十分なディスク容量が必要です」という要件も、単に「RDBのサイズより空き容量が多くあればいい」というものではない。
1. COWによる一時的な容量爆発
RDB生成時、前述の通り一時ファイルが作られる。つまり、既存の `dump.rdb`（仮に20GB）が存在する状態で `BGSAVE` が走ると、一時的に 既存20GB + 新規一時ファイル（最大20GB超） = 40GB以上 の空き容量が同一ファイルシステム上に必要となる。
2. AOF重力圏（AOF Rewrite / BGREWRITEAOF）
AOF（Append Only File）を有効にしている場合、`dir` 内には `appendonly.aof` が鎮座する。このファイルは追記型であるため無限に肥大化する。これを圧縮する `BGREWRITEAOF` が走るとき、Redisは新しいAOFファイルを別名（例: `appendonly.aof.1.incr.aof` など）で作成し、最後にアトミックなファイル名置換（`rename()`）を行う。
ここでもしディスク容量が限界に達するとどうなるか？
Linuxカーネルは `ENOSPC`（No space left on device）を返す。このシグナルを受け取ったRedisは、ログに悲鳴を刻み、バックグラウンドプロセスを異常終了させる。
カーネルパニックを防ぐためのプロアクティブ・モニタリング
シニアエンジニアであれば、容量が枯渇してから慌てるのではなく、カーネルのブロックレイヤーとファイルシステムの挙動を監視に組み込む。
現在のdir設定が向いているマウントポイントの空き容量とinodesを監視する例
df -T /var/lib/redis
inode使用率も含めて確認すること。大量の小さなキーや一時ファイルの生成で、
ディスク容量は余っていてもInode枯渇（ENOSPC）でRedisが沈没する事例は後を絶たない。
—
5. チーフアーキテクトが推す `dir` 周りの極限ベストプラクティス
最後に、数千台規模のRedisクラスターを統括してきた筆者が到達した、実戦投入における絶対的鉄則を授ける。
1. 専用パーティションの切り出し
`dir` で指定するディレクトリは、OSのルート（`/`）や `/var` とは完全に切り離された、専用の物理/論理ボリューム（LVM / NVMe）の直下に配置せよ。ログやOSのコアダンプがディスクを埋め尽くした際、Redisの永続化まで巻き添えにして死ぬのを防ぐためだ。
2. シンボリックリンクの活用と無停止レイアウト
デプロイメントの自動化やバージョンアップにおいて、パス構造を固定化するために `dir` の実体をシンボリックリンク経由で参照させる手法は有効である。ただし、`chdir()` の挙動とリンクの解決順序に依存するため、リンク先の切り替え時はRedisの再起動、あるいは `CONFIG SET dir` の動的変更を慎重に行うこと。
# 例: 物理パスは世代管理し、シンボリックリンクで抽象化
/var/lib/redis/current -> /var/lib/redis/v1.4.2
3. `CONFIG SET dir` の動的変更の危険性
Redisは実行中に `CONFIG SET dir /new/path` を叩くことで、再起動なしに保存先を変更できる。しかし、このコマンドを実行する前に、新旧ディレクトリ間の所有権、パーミッション、および既存のRDB/AOFファイルのコピー（移行）を完璧に行っておかなければならない。怠ると、次の保存サイクルでデータが消失する。
—
結び
たかが `dir`。されど `dir`。
インメモリデータベースのスピードの裏側には、それを支える厳格なストレージI/OとOSカーネルとの静かな対話が存在する。
設定ファイルの一行に宿るシステム全体の挙動を完全に見通すことこそが、真のエンジニアリングである。
あなたのRedisが、今日も高速かつ安全にデータを作り続けられることを祈る。
コメント