メタデータ管理の 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 を提供します。

#[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. 移行ロードマップ

共通基盤の構築: chainfire-client::metadata を実装。Chainfire ブリッジとテスト用の InMemory バックエンドを提供。
k8shost のリファクタリング: storage.rs を MetadataClient 経由に書き換え、flaredb-client 依存を削除。
他コンポーネントの追随: lightningstor 等の独自ストレージ選択ロジックを chainfire-client::metadata に置換。

4. 結論

本提案により、現状の FlareDB マルチテナント実装の複雑さから解放され、開発効率とシステムの一貫性が劇的に向上します。将来的なスケーラビリティ要求に対しても、抽象化レイヤーの導入により十分対応可能です。

3.3 KiB Raw Blame History Unescape Escape