【実務・中級編】 appendfilename設定 – Redis

「たかがファイル名」に潜む罠。Redisの命綱を支配する `appendfilename` 設計極論

システムがスケールし、秒間数万クエリをさばくプロダクション環境において、データ永続化の設計はシステムの「生殺与奪の権」を握っています。

Redisの永続化メカニズムであるAOF（Append Only File）。そのファイル名を指定するだけの単純なパラメータに見える `appendfilename` ですが、これをデフォルトの `appendonly.aof` のまま放置しているプロジェクトは、我々チーフアーキテクトの目から見れば「運用の考慮漏れ」と言わざるを得ません。

特に Redis 7.0以降における仕様の激変（Multi-Part AOF） を理解せずに、古い知識のままこのパラメータを扱っていると、監視の崩壊やバックアップの失敗、最悪の場合はデータロストを引き起こします。

今回は、実務で堅牢なシステムを構築するための `appendfilename` 設計の極意を、アーキテクチャの深部から解説します。

—

1. Redis 7.0がもたらしたパラダイムシフト：Multi-Part AOF

まず、前提となる前提知識をアップデートしてください。
Redis 6.2までは、`appendfilename` で指定した名前の「単一の巨大なファイル」が生成されるだけでした。しかし、Redis 7.0以降、この挙動は根底から覆りました。

Redis 7.0からは Multi-Part AOF というアーキテクチャが採用されています。AOFは単一のファイルではなく、役割の異なる複数のファイルに分割して管理されるようになりました。

これに伴い、`appendfilename` の意味合いは「ファイル名そのもの」から「生成されるファイル群のプレフィックス（ベース名）」へと変化しています。

実際のディレクトリ構造（Redis 7.0以降）

`redis.conf` で以下のように設定した場合の、実際のディスク上の状態を見てみましょう。

redis.conf
appendonly yes
appenddirname “appendonlydir”
appendfilename “production-cluster-cache.aof”

この設定により、指定されたディレクトリ（`appenddirname`）配下に、以下のようなファイル群が自動生成されます。

$ ls -l /var/lib/redis/appendonlydir/

1. 全体の構成を管理するマニフェストファイル（これが起点となる）
-rw-r–r– 1 redis redis 140 Oct 24 12:00 production-cluster-cache.aof.manifest

2. AOF書き換え（Rewrite）時に固められたベースデータ（RDB形式またはAOF形式）
-rw-r–r– 1 redis redis 1048 Oct 24 12:00 production-cluster-cache.aof.1.base.rdb

3. ベース作成以降の最新の変更差分を記録するインクリメンタルファイル
-rw-r–r– 1 redis redis 256 Oct 24 12:05 production-cluster-cache.aof.1.incr.aof

ここで犯しがちな致命的ミス

古い監視シェルスクリプトやバックアップスクリプトで、`/var/lib/redis/appendonly.aof` という単一ファイルの存在チェックやファイルサイズ監視を行っている場合、Redis 7.0への移行期にそれらはすべて音もなく機能不全に陥ります。

現代のRedisにおいて、`appendfilename` を設計することは、これら複数ファイルの「アイデンティティ（識別子）」を定義することと同義なのです。

—

2. なぜデフォルト設定（appendonly.aof）を避けるべきなのか？

プロダクション環境において、デフォルト値 `appendonly.aof` をそのまま使うべきではない理由は、主に「識別性」と「運用の安全性」にあります。

理由①：同一ホスト/同一ボリュームでの複数インスタンス運用の衝突回避

実務では、1台の強力なサーバ（または同一の永続ボリューム）に、ポート番号を分けて複数のRedisインスタンス（例：マスターとレプリカ、あるいは用途別のシャード）を同居させることがあります。

もしすべてのインスタンスがデフォルトの `appendfilename “appendonly.aof”` のままで、データディレクトリ（`dir` 設定）の設定ミスや相対パスの解釈ズレが発生した場合、異なるインスタンス同士が互いのAOFファイルを上書き・破損させるという大惨事が発生します。

理由②：Kubernetes（StatefulSet）環境でのボリューム運用の明確化

コンテナ環境において、PV（Persistent Volume）をマウントして運用する場合、どのPodがどのAOFファイルを出力しているかをマニフェストファイル名から即座に識別できる必要があります。ポッド名や役割に紐づいたユニークな命名規則にしておくことで、障害時の切り分けスピードが劇的に向上します。

—

3. チーフアーキテクトが推奨する「命名規則」と設定例

実務の設計レビューで私が承認する、堅牢な命名規則のパターンを提示します。

推奨命名規則

[環境名]-[システム/コンポーネント名]-[ポート/シャード識別子].aof

具体的な `redis.conf` 設定例

PERSISTENCE ###############################

AOFの有効化（必須）
appendonly yes

AOFファイル群を格納するディレクトリ名
Redis 7.0以降では、ベース名とは別にディレクトリを明示的に分けるのがベストプラクティス
appenddirname “appendonlydir-api-cache”

AOFファイルのプレフィックス名
環境、システム、ポート番号を明記し、衝突を物理的に防ぐ
appendfilename “prod-apiserver-redis-6379.aof”

書き込み同期ポリシー（パフォーマンスと安全性のトレードオフ。通常はeverysecを推奨）
appendfsync everysec

AOF書き換え（Rewrite）時のディスクI/O負荷を軽減する設定
no-appendfsync-on-rewrite no

—

4. 運用ライフサイクルにおける `appendfilename` の制約

設計者として絶対に頭に叩き込んでおくべき制約があります。それは、「`appendfilename` は起動中に動的変更（`CONFIG SET`）ができない」という事実です。

実際にRedis CLIから変更を試みると、以下のように拒否されます。

127.0.0.1:6379> CONFIG SET appendfilename “new-name.aof”
(error) ERR dbfilename can’t be set when AOF is enabled (or similar dynamic config restriction)
もしくは
(error) ERR Unsupported CONFIG parameter: appendfilename

この制約が意味すること

後から「やっぱりファイル名を変えたい」と思っても、Redisインスタンスの停止（あるいはフェイルオーバーを伴うローリングアップデート）が必要になります。

したがって、プロジェクトの初期段階（クラスタ設計書、TerraformやAnsibleなどの構成管理コードの作成段階）で、この命名規則を厳格に定めておく必要があります。設計のサボりは、運用の手戻りとして必ずツケが回ってきます。

—

5. BGREWRITEAOF（書き換え）時のストレージ容量設計

`appendfilename` の設定値そのものが直接パフォーマンスを劣化させることはありません。しかし、AOFファイル名が指し示すディスク領域は、`BGREWRITEAOF`（AOF書き換えプロセス）が実行される瞬間に、強烈なリソース消費の舞台となります。

書き換え時のディスク容量「2倍の罠」

`BGREWRITEAOF` が実行されると、Redisは一時ファイル（`temp-rewritebgaof-.aof` のような一時的なファイル名）を作成し、現在のメモリ内のデータを一気に書き出します。

物理ディスク容量の閾値：

アクティブなAOFファイル群の合計サイズの最低2倍以上の空き容量がディスクにない場合、書き換え処理中にディスクフル（Enospc）となり、Redisは書き込みを受け付けなくなります。

I/Oの競合：

`appendfilename` が存在する物理ストレージ（SSD/HDD）のI/O帯域がボトルネックになると、AOF書き込み（`appendfsync`）がブロックされ、メインスレッドの処理速度（レイテンシ）が急激に悪化します。

アーキテクトとしての処方箋：
AOFを格納するディレクトリ（`dir` および `appenddirname`）は、OSのシステム領域や他の高I/Oアプリケーションが使用する領域とは物理的に異なるマウントポイント（専用のNVMe SSD等）に配置するよう、インフラ設計を徹底してください。

—

6. まとめ：たかが名前、されど名前

実務における優れた設計とは、「不確実性を排除し、運用の予見可能性を高めること」に他なりません。

`appendfilename` は単一のファイル名ではなく、Multi-Part AOF全体のプレフィックスである。
デフォルトの `appendonly.aof` は卒業し、環境名、役割、ポートを含めたユニークな命名を徹底する。
動的な変更が不可能なパラメータであるため、初期設計（構成管理）の段階で標準化しておく。
書き換え時のディスク容量・I/O負荷を見越し、物理ストレージの分離を設計に組み込む。

これらを徹底することで、あなたの構築するRedisシステムは、障害に強く、監視しやすく、そして何より「運用のプロに愛される」極めて洗練されたアーキテクチャへと昇華します。次のコードレビューや設計レビューで、ぜひこの知見をチームに注入してください。