📋 要約（TL;DR）#
- 🔑 問題: 分散KVSでRaftを使うと、コンセンサスプロトコルとストレージエンジンの永続化操作が重複し、I/Oオーバーヘッドが発生
- 🔑 解決策: Nezhaはキーバリュー分離アーキテクチャをRaftと統合し、オペレーションレベルの永続化戦略を再設計
- 🔑 結果: put操作で460.2%、get操作で12.5%、scan操作で**72.6%**のスループット向上を実現
- 💡 読みどころ: Raftの「安全な強整合性」を維持したまま、ここまで性能向上できるのが革命的！
🎯 はじめに：分散KVSの「見えない敵」#
みんな、こんにちは！Emmaだよ 🍫
今日は2026年3月にarXivに公開された超面白い論文を紹介するね — Nezha: A Key-Value Separated Distributed Store with Optimized Raft Integration！
分散KVS（Key-Value Store）って、ビッグデータアプリケーションのバックエンドでめっちゃ使われてるよね。etcd、TiKV、CockroachDB… どれもRaftコンセンサスアルゴリズムを使って整合性を保証してる。
でもね、実はここに「見えない敵」が潜んでたんだ — 永続化操作の重複によるI/Oオーバーヘッド。
これ、どういうことか、一緒に見ていこう！
🔍 問題の正体：永続化の二重壁#
Raftの動作フロー#
Raftを使った分散KVSでは、書き込みリクエストが来ると：
- Raftログに書き込み — リーダーがログエントリを永続化
- レプリケーション — フォロワーにエントリを送信
- コミット — 過半数がACKしたらコミット
- ストレージエンジンへの書き込み — 実際のデータを永続化
ここで何が起きてるか分かる？
ステップ1とステップ4で、それぞれ別の永続化操作が走ってる！
これがI/Oの二重壁 — 同じデータを2回ディスクに書いてるようなもの。しかも、Raftログとストレージエンジンが別々に管理されてるから、最適化の余地がない。
なぜこれが問題なのか#
- SSDの書き込み増大: 書き込み増幅が発生
- レイテンシ増加: 2回のfsyncが必要
- スループット低下: I/Oバンド幅の無駄遣い
「Raftは安全だけど遅い」— これ、分散システム界隈ではあるあるだったんだ。
💡 Nezhaの革新的アプローチ#
キーバリュー分離アーキテクチャ#
NezhaはWiscKey（2016年の論文）で提唱された「キーバリュー分離」の考え方をRaftと統合したんだ。
従来のLSM-treeベースのKVS:
Key + Value → SSTableキーバリュー分離:
Key → LSM-tree（小さい、メモリに載りやすい）
Value → Value Log（巨大な値は別管理）これで何が嬉しいか？
- コンパクションの負荷激減（値をコピーしなくていい）
- ランダム読み書きがシーケンシャルに
- LSM-treeのサイズが小さくなってキャッシュ効率アップ
Nezhaの3つのイノベーション#
1. オペレーションレベルの永続化戦略#
NezhaはRaftログとストレージエンジンの永続化を統合した！
従来: Raft Log → Storage Engine（2回の永続化）
Nezha: 統合された永続化（1回）これでI/Oオーバーヘッドが劇的に削減。
2. Leveled Garbage Collection#
キーバリュー分離だと、古い値がValue Logに残り続ける問題がある。Nezhaはレベル別GCを導入して、効率的にガベージコレクションを実行。
3. Raftの安全性を維持#
ここがすごいところ！NezhaはRaftの安全性保証を一切犠牲にしていない：
- リーダー選出の正確性
- ログの一貫性
- 強整合性の保証
「速くて安全」— これこそエンジニアが夢見る理想形！
📊 パフォーマンス：数字で見る革新性#
論文の実験結果を見てみよう：
| 操作 | スループット向上 |
|---|---|
| put | +460.2% |
| get | +12.5% |
| scan | +72.6% |
putが460%って… 5.6倍ってことだよ！ 😱
これ、分散KVSの世界では異次元の改善。普通は10-20%の改善でも論文になるレベルだから、460%は革命的。
なぜputがこれほど向上したのか#
- 永続化の重複解消 — Raftログとストレージの統合でI/O削減
- LSM-treeの書き込み増幅軽減 — キーバリュー分離でコンパクション負荷激減
- シーケンシャル書き込み — Value Logへのシーケンシャルアクセス
getとscanも向上#
- get: LSM-treeが小さくなってキャッシュヒット率向上
- scan: キーだけ走査して必要な値だけ取得できる
🎓 技術的詳細：深掘りポイント#
アーキテクチャ図（概念）#
┌─────────────────────────────────────────┐
│ Client Request │
└────────────────┬────────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ Raft Consensus Layer │
│ ┌────────────────────────────────────┐ │
│ │ Integrated Persistence Strategy │ │
│ └────────────────────────────────────┘ │
└────────────────┬────────────────────────┘
│
┌────────┴────────┐
▼ ▼
┌──────────────┐ ┌──────────────┐
│ LSM-tree │ │ Value Log │
│ (Keys only) │ │ (Values) │
└──────────────┘ └──────────────┘実装のポイント#
- Go言語で実装
- Badger（キーバリュー分離LSM-tree）をベースに構築
- Raft実装はetcd/raftを拡張
🔮 実用化への展望#
Nezhaはプロトタイプだけど、このアプローチは実用化のポテンシャルが高い：
適用シナリオ#
- クラウドネイティブデータベース — TiKVやCockroachDBのような分散DB
- メッセージキュー — Kafkaのような永続化が必要なシステム
- 分散キャッシュ — Redis Clusterのような強整合性が必要なケース
課題#
- 読み取り性能: キーバリュー分離は読み取りが2回必要（キー検索 + 値取得）
- Value LogのGC: 適切なGCタイミングの調整が必要
- 既存システムとの互換性: 移行コスト
🤔 まとめ：Raftの次の進化#
Nezhaの論文、すごくエキサイティングだよね！
「Raftは遅い」っていう常識を覆した — これが一番大きい。分散システムの設計において、「整合性 vs パフォーマンス」は常にトレードオフだと思われてきた。
でもNezhaは「両方手に入る」ことを示した。
エンジニアとしての感想#
この論文を読んで思ったこと：
- 永続化の重複 — 当たり前すぎて見落とされてた問題
- 統合の発想 — Raftとストレージを「別物」として扱わない
- 460%の改善 — 小さな積み重ねじゃなく、アーキテクチャレベルの革新
みんなはどう思う？「強整合性は遅い」っていう常識、これから変わっていくのかな？
コメントで意見聞かせてね！
📚 参照#
- Nezha: A Key-Value Separated Distributed Store with Optimized Raft Integration - arXiv (2026)
- Raft Consensus Algorithm - raft.github.io
- WiscKey: Separating Keys from Values in SSD-conscious Storage - USENIX FAST 2016
- etcd Raft Implementation - GitHub
Emmaでした！次回もお楽しみに〜 🍫