Redisのデータ整合性を極限まで制御する：WAITコマンドの深淵
多くのエンジニアがRedisを「高速なキャッシュ」と定義し、その先にある「信頼性」の担保をアプリケーション側のロジックに丸投げしている。しかし、分散システムにおけるデータの一貫性は、アプリケーション層の努力だけで解決できるほど甘くはない。
Redisのアーキテクチャにおいて、`WAIT`コマンドは単なる「同期待ち」のツールではない。これは、非同期レプリケーションという「結果整合性の暴走」に対し、開発者が物理的な制約を課すための唯一のブレーキである。
今日は、Redisの内部メカニズムに踏み込み、`WAIT`がどのようにして「緩やかな同期」を「確実なコミット」へ変貌させるのか、その極限の動作を紐解く。
—
1. WAITの本質：非同期レプリケーションの「静かなる断絶」
Redisのレプリケーションは、デフォルトで非同期（asynchronous）である。マスターが書き込みを受け付けた瞬間、クライアントには`OK`が返るが、その裏でレプリカへの伝搬は「ベストエフォート」で行われる。
この「ベストエフォート」は、フェイルオーバー時に深刻なデータロスト（RPO > 0）を招く。ここで`WAIT`の出番だ。
num_replicas: 完了を待つレプリカ数
timeout: ミリ秒単位の待ち時間
WAIT
`WAIT`を実行すると、Redisサーバーはその瞬間に「現在までの全ての書き込みが、指定された数のレプリカに複製されるまで」、現在のクライアント接続をブロックする。
2. 内部メカニズム：`repl_ack_off` との対話
内部的に何が起きているのか。Redisのマスターインスタンスは、接続している各レプリカに対して `replication offset` を管理している。
1. 書き込み発生: マスターは自身のオフセットをインクリメントする。
2. WAIT発行: Redisは現在のマスターの `master_repl_offset` を記録する。
3. ブロック状態: クライアントの接続は、特定のレプリカがそのオフセットに到達したという `ACK` を返してくるまで、イベントループ内でブロック（`aeWait` または `epoll_wait` の応用）される。
4. 解除: 到達したレプリカの数が指定数に達したか、タイムアウトが発生した時点で、コマンドは完了したレプリカ数を返す。
ここで重要なのは、`WAIT`はストレージエンジンへの書き込みを待つのではなく、ネットワークを通じたレプリケーションの伝搬を待つという点だ。つまり、レプリカのメモリ上でデータが展開された保証を得るための、低レイヤの同期ハンドシェイクに他ならない。
3. なぜ「同期レプリケーション」ではないのか
ここを誤解しているエンジニアが多い。`WAIT`を使っても、Redisは完全な同期レプリケーション（Synchronous Replication）にはならない。
- 耐障害性の限界: `WAIT`が成功した直後にマスターがダウンすれば、データは一貫性を保つが、`WAIT`がタイムアウトした場合はどうなるか？ クライアントは「書き込みが成功したのか、失敗したのか」を知る術を失う。
- レイテンシの非線形性: `WAIT`はネットワークRTT（Round Trip Time）に完全に依存する。マルチAZ構成で`WAIT`を多用すれば、書き込みパフォーマンスはネットワークの遅延そのものに収束する。
4. アーキテクトのための運用最適化：限界への挑戦
実務でこのコマンドを扱う際、以下の「禁忌」と「最適化」を頭に叩き込んでおく必要がある。
① タイムアウト値の設計
`timeout`に`0`を指定するのは論外だ。ネットワークの分断（Network Partition）が発生した場合、永久にコネクションが解放されず、Redisのワーカースレッドを食いつぶすことになる。必ず、許容可能なビジネス上のレイテンシ限界をミリ秒単位で設定せよ。
② クリティカルパスの分離
全ての`SET`コマンドの後に`WAIT`を置くのは、Redisのアーキテクチャを否定しているに等しい。「どうしてもデータロストが許されない決済トランザクション」など、一貫性が極めて重要なキーに対してのみ適用する。
③ 監視とメトリクス
`WAIT`が頻発する環境では、以下のメトリクスを監視せよ。
- `instantaneous_ops_per_sec`: `WAIT`によるブロックが、Redisの全体的なスループットをどれだけ削いでいるか。
- `connected_slaves`: 期待するレプリカ数に対して、実際に `ACK` を返せるレプリカが常にオンラインであるか（レプリカの増減が`WAIT`の完了時間に直結する）。
結びに代えて：トレードオフの美学
Redisの`WAIT`は、CAP定理における「C（一貫性）」と「A（可用性）」を、開発者が動的に調整するためのスイッチだ。
エンジニアとして成熟するとは、Redisの高速性を享受するだけでなく、「どこまでならデータロストを許容できるか」というビジネスの要求を、レプリケーションのオフセット管理という低レイヤの論理に翻訳する能力を持つことである。
`WAIT`は特効薬ではない。それは、複雑な分散システムの深淵を覗き込み、自身のシステムの耐障害性を精密に設計するための、最も鋭利なメスである。使いこなせ。ただし、その重みを理解した上で。
コメント