centra
8f94aee1fa
- Remove gitlinks (160000 mode) for chainfire, flaredb, iam - Add workspace contents as regular tracked files - Update flake.nix to use simple paths instead of builtins.fetchGit This resolves the nix build failure where submodule directories appeared empty in the nix store. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
87 lines
6 KiB
Markdown
87 lines
6 KiB
Markdown
RaftとGossipプロトコルを用いた、クラスター管理のための数万台までスケールするKey-Value Storeを書いてほしいです。
|
||
|
||
- プログラミング言語：rust
|
||
- テストをちゃんと書きながら書くことを推奨する。
|
||
- クラスターへの参加/削除/障害検知を行う。
|
||
|
||
では、**「Raft（合意形成）」と「Gossip（情報の拡散）」を組み合わせた場合、具体的にどうデータが流れ、どうやってノードが動き出すのか**、その具体的なフローを解説します。
|
||
|
||
-----
|
||
|
||
### 前提：このシステムの役割分担
|
||
|
||
* **Control Plane (CP):** Raftで構成された3〜7台（Raftアルゴリズムでうまく合意が取れる範囲）のサーバー。情報の「正規の持ち主」。いなくなったら自動でWorker Nodesから昇格する。
|
||
* **Worker Nodes (VM/DB Hosts):** 数百〜数千台の実働部隊。CPのクライアント。
|
||
|
||
### 1\. データはどのように書き込まれるか？ (Write)
|
||
|
||
書き込みは **「必ず Control Plane の Raft Leader に対して」** 行います。Gossip経由での書き込みは（順序保証がないため）行いません。
|
||
|
||
例：「VM-A を Node-10 で起動したい」
|
||
|
||
1. **API Call:** 管理者（またはCLI）が、CPのAPIサーバーにリクエストを送ります。
|
||
2. **Raft Log:** CPのリーダーは、この変更を `Put(Key="/nodes/node-10/tasks/vm-a", Value="START")` としてRaftログに追加します。
|
||
3. **Commit:** 過半数のCPノードがログを保存したら「書き込み完了」と見なします。
|
||
|
||
ここまでは普通のDBと同じです。
|
||
|
||
### 2\. 各ノードはどのようにデータを取得し、通知を受けるか？ (Read & Notify)
|
||
|
||
ここが最大のポイントです。数千台のノードが「自分宛ての命令はないか？」と毎秒ポーリング（問い合わせ）すると、CPがDDoS攻撃を受けたようにパンクします。
|
||
|
||
ここで **「Watch（ロングポーリング）」** という仕組みを使います。
|
||
|
||
#### A. Watchによる通知と取得（これがメイン）
|
||
|
||
Kubernetesやetcdが採用している方式です。
|
||
|
||
1. **接続維持:** Node-10 は起動時に CP に対して `Watch("/nodes/node-10/")` というリクエストを送ります。
|
||
2. **待機:** CP は「Node-10 以下のキーに変更があるまで、レスポンスを返さずに接続を維持（ブロック）」します。
|
||
3. **イベント発火:** 先ほどの書き込み（VM起動命令）が発生した瞬間、CP は待機していた Node-10 への接続を通じて「更新イベント（Event: PUT, Key: ...vm-a, Value: START）」を即座にプッシュします。
|
||
4. **アクション:** Node-10 は通知を受け取り次第、VMを起動します。
|
||
|
||
**結論:** 「書き込み後の通知」は絶対に必要です。それを効率よくやるのが **Watch API** です。
|
||
|
||
-----
|
||
|
||
### 3\. じゃあ Gossip はどこで使うのか？
|
||
|
||
「Raft + Watch」で完結しそうに見えますが、10台以上のスケール、特にVM基盤のような動的な環境では **Gossip が以下の「3つの穴」を埋めるために不可欠** になります。
|
||
|
||
#### ① Nodeの死活監視・インベントリ管理（下り方向）
|
||
|
||
CPが「Node-10にVMを立てたい」と思ったとき、「そもそもNode-10は生きているのか？ IPは？ 空きメモリは？」という情報を知る必要があります。
|
||
|
||
* **Gossipの役割:** 各Worker Nodeは、Gossip（SWIMプロトコル）でお互いに、そしてCPに対して「自分は生きてるよ、IPはこれだよ」と喋り続けます。
|
||
* CPはこのGossip情報を聞いて、最新の「ノード一覧リスト（Memberlist）」をメモリ上に保持します。
|
||
|
||
#### ② サービスのディスカバリ（横方向）
|
||
|
||
DB基盤の場合、「DBノードA」が「DBノードB」と通信したいことがあります。いちいちCPに聞きに行くと遅いです。
|
||
|
||
* **Gossipの役割:** ノード同士で「私はここにいるよ」とGossipし合うことで、CPを介さずに直接通信相手を見つけられます。
|
||
|
||
#### ③ "Actual State"（現状）の報告（上り方向）
|
||
|
||
VMが起動した後、「起動しました」というステータスをどうCPに伝えるか。
|
||
|
||
* **Raftに書く:** 確実ですが、頻繁に変わるステータス（CPU使用率など）を全部Raftに書くとCPがパンクします。
|
||
* **Gossipで流す:** 「VM-Aは起動中、負荷50%」といった情報はGossipに乗せて、**「結果的にCPに伝わればいい」** という扱いにします。
|
||
|
||
-----
|
||
|
||
### 設計のまとめ：RaftとGossipの使い分け
|
||
|
||
これから作る「汎用管理DB（外部依存型）」は、以下のようなインターフェースを持つことになるでしょう。
|
||
|
||
| アクション | 通信方式 | 具体的なデータ例 |
|
||
| :--- | :--- | :--- |
|
||
| **命令 (Desired State)**<br>「こうなってほしい」 | **Raft + Watch**<br>(強整合性) | ・VMの起動/停止命令<br>・DBのデータ配置情報の変更<br>・パスワードや設定変更 |
|
||
| **現状 (Actual State)**<br>「今こうなってます」 | **Gossip**<br>(結果整合性) | ・ノードの生存確認 (Heartbeat)<br>・リソース使用率 (CPU/Mem)<br>・「VM起動完了」などのステータス |
|
||
| **通知 (Notification)** | **Watch (HTTP/gRPC Stream)** | ・「新しい命令が来たぞ！」というトリガー |
|
||
|
||
#### 実装のアドバイス
|
||
|
||
もし「etcdのようなもの」を自作されるなら、**「Serf (Gossip)」と「Raft」をライブラリとして組み込み、その上に「gRPCによるWatch付きのKVS API」を被せる** という構成になります。
|
||
|
||
これができれば、VM基盤は「Watchして、VMを起動して、Gossipでステータスを返すエージェント」を作るだけで済みますし、DB基盤も同様に作れます。非常にスケーラブルで美しい設計です。
|