89 lines
No EOL
4.1 KiB
Markdown
89 lines
No EOL
4.1 KiB
Markdown
# Chainfire アーキテクチャ再定義案: 分散システム構築基盤への転換
|
||
|
||
`Chainfire` を単一の KV ストアサービスから、プロジェクト全体の「分散システム構築フレームワーク」へと位置づけ直すための設計案です。
|
||
|
||
## 1. アーキテクチャ概要
|
||
|
||
階層構造を整理し、低レイヤーのプリミティブから高レイヤーのマネージドサービスまでを明確に分離します。
|
||
|
||
```mermaid
|
||
graph TD
|
||
subgraph Application_Layer
|
||
FlareDB[FlareDB / Distributed DB]
|
||
LightningStor[lightningstor / Object Storage]
|
||
IAM[IAM / Control Plane]
|
||
end
|
||
|
||
subgraph L2_Service_Layer_Sidecar
|
||
CFServer[Chainfire Server]
|
||
CFServer -- gRPC Streaming --> IAM
|
||
end
|
||
|
||
subgraph L1_Framework_Layer
|
||
CFCore[chainfire-core]
|
||
CFCore -- Library Embed --> FlareDB
|
||
CFCore -- Library Embed --> LightningStor
|
||
|
||
MultiRaft[Multi-Raft Orchestrator]
|
||
CFCore --> MultiRaft
|
||
end
|
||
|
||
subgraph L0_Primitive_Layer
|
||
Gossip[chainfire-gossip]
|
||
Raft[chainfire-raft]
|
||
Storage[chainfire-storage]
|
||
|
||
CFCore --> Gossip
|
||
CFCore --> Raft
|
||
Raft --> Storage
|
||
end
|
||
|
||
CFServer --> CFCore
|
||
```
|
||
|
||
## 2. 各レイヤーの責務定義
|
||
|
||
### L0 Core (Library): primitives
|
||
- **chainfire-gossip**:
|
||
- SWIM プロトコルに基づくメンバーシップ管理。
|
||
- 特定のサービスに依存せず、任意の `NodeMetadata` を伝搬可能にする。
|
||
- **chainfire-raft**:
|
||
- 単一 Raft グループのコンセンサスロジック。
|
||
- `StateMachine` を Trait 化し、任意のビジネスロジックを注入可能にする。
|
||
- `RaftNetwork` を抽象化し、gRPC 以外（UDS, In-memory）のトランスポートをサポート。
|
||
- **chainfire-storage**:
|
||
- Raft ログおよび StateMachine のための永続化レイヤー。
|
||
|
||
### L1 Framework: chainfire-core
|
||
- **Multi-Raft Orchestrator**:
|
||
- 複数の Raft インスタンス（シャード）を同一プロセス内で効率的に管理。
|
||
- ネットワーク接続やスレッドプール等のリソース共有を最適化。
|
||
- **Cluster Manager**:
|
||
- Gossip のメンバーシップイベントを監視し、Raft グループへのノード追加・削除を自動化。
|
||
- 「ノード発見（Gossip）」から「合意形成参加（Raft）」への橋渡しを行う。
|
||
|
||
### L2 Service: chainfire-server (Standard Implementation)
|
||
- **Shared Infrastructure**:
|
||
- KV ストア、分散ロック、リース管理を gRPC API として提供。
|
||
- 独自に Raft を組む必要のない「軽量サービス」向けの共通基盤。
|
||
- **Sidecar Mode Support**:
|
||
- gRPC Streaming による `ClusterEvents` の提供。
|
||
- リーダー交代やメンバーシップ変更を外部プロセスにリアルタイム通知。
|
||
|
||
## 3. 分散サービスでの再利用シナリオ (例: FlareDB)
|
||
|
||
FlareDB が Chainfire 基盤をどのように利用して Multi-Raft を構成するかの具体例です。
|
||
|
||
1. **ライブラリとして組み込み**: `FlareDB` プロセスが `chainfire-core` をリンク。
|
||
2. **独自の StateMachine 実装**: FlareDB のデータ操作ロジックを `StateMachine` Trait として実装。
|
||
3. **シャード管理**:
|
||
- データのレンジごとに `RaftGroup` インスタンスを作成。
|
||
- 各 `RaftGroup` に FlareDB 独自の `StateMachine` を登録。
|
||
4. **ノード管理の委譲**:
|
||
- Gossip によるノード発見を `chainfire-core` に任せ、FlareDB 側では個別のノードリスト管理を行わない。
|
||
|
||
## 4. メリットの整理
|
||
|
||
- **開発効率の向上**: Gossip や Raft といった複雑な分散プロトコルの再実装が不要になる。
|
||
- **観測性の一貫性**: プロジェクト全体の全ノードが共通の Gossip 基盤に乗ることで、システム全体のトポロジー可視化が容易になる。
|
||
- **柔軟な配置**: 同一のロジックを、ライブラリとして（高パフォーマンス）、あるいはサイドカーとして（疎結合）のどちらでも利用可能。 |