45 lines
No EOL
3.3 KiB
Markdown
45 lines
No EOL
3.3 KiB
Markdown
# メタデータ管理の Chainfire 一本化に関する調査報告と構成案
|
||
|
||
## 1. 調査結果サマリー
|
||
プロジェクト内の各コンポーネントにおけるメタデータ（設定、リソース定義、状態）の管理状況を調査した結果、現状は `Chainfire` (etcd-like) と `FlareDB` (TiKV-like) が混在しており、メンテナンスコストとシステム複雑性を増大させていることが判明しました。
|
||
|
||
### コンポーネント別の現状
|
||
- **移行が必要**: `k8shost` (現在 FlareDB に強く密結合)
|
||
- **設定・実装の統一が必要**: `lightningstor`, `flashdns`, `prismnet`, `fiberlb` (既に Chainfire 対応コードを持つが、独自に抽象化を実装)
|
||
- **対応済み**: `iam`, `creditservice` (既に Chainfire を主に使用)
|
||
|
||
## 2. 技術的判断
|
||
メタデータ実装を **Chainfire に一本化することは妥当かつ推奨される** と判断します。
|
||
|
||
### 妥当性の理由
|
||
- **運用性の向上**: 運用・監視・バックアップの対象を Raft ベースの `Chainfire` 1つに集約できる。
|
||
- **一貫した連携基盤**: `Chainfire` の `Watch` 機能を共通のイベント基盤として、コンポーネント間（例：Podの変更をネットワーク層が検知）のリアクティブな連携が容易になる。
|
||
- **コードの健全化**: 依存ライブラリを整理し、各コンポーネントで重複しているストレージ抽象化ロジックを排除できる。
|
||
|
||
### リスクへの対策
|
||
`Chainfire` は全ノード複製型のため、大規模環境での書き込み性能がボトルネックになる懸念があります。これに対し、本案では**共通抽象化インターフェース (Trait)** を導入することで、将来的に特定リソースのみ高性能バックエンドへ再分離できる柔軟性を確保します。
|
||
|
||
## 3. 構成案
|
||
|
||
### A. 共通モジュール `chainfire-client::metadata` の新設
|
||
各サービスからストレージ固有の実装を分離し、共通の `MetadataClient` Trait を提供します。
|
||
|
||
```rust
|
||
#[async_trait]
|
||
pub trait MetadataClient: Send + Sync {
|
||
async fn get(&self, key: &str) -> Result<Option<Vec<u8>>>;
|
||
async fn put(&self, key: &str, value: Vec<u8>) -> Result<()>;
|
||
async fn delete(&self, key: &str) -> Result<bool>;
|
||
async fn list_prefix(&self, prefix: &str) -> Result<Vec<(String, Vec<u8>)>>;
|
||
async fn watch(&self, prefix: &str) -> BoxStream<WatchEvent>;
|
||
async fn compare_and_swap(&self, key: &str, expected_rev: u64, value: Vec<u8>) -> Result<CasOutcome>;
|
||
}
|
||
```
|
||
|
||
### B. 移行ロードマップ
|
||
1. **共通基盤の構築**: `chainfire-client::metadata` を実装。`Chainfire` ブリッジとテスト用の `InMemory` バックエンドを提供。
|
||
2. **k8shost のリファクタリング**: `storage.rs` を `MetadataClient` 経由に書き換え、`flaredb-client` 依存を削除。
|
||
3. **他コンポーネントの追随**: `lightningstor` 等の独自ストレージ選択ロジックを `chainfire-client::metadata` に置換。
|
||
|
||
## 4. 結論
|
||
本提案により、現状の `FlareDB` マルチテナント実装の複雑さから解放され、開発効率とシステムの一貫性が劇的に向上します。将来的なスケーラビリティ要求に対しても、抽象化レイヤーの導入により十分対応可能です。 |