# Raftログ診断 ## 定義 Raft ログ診断（Raft-based Anomaly Diagnosis）とは、分散ストレージシステムにおける Raft コンセンサスアルゴリズムが必然的に生成する**Raft ログ**を入力として、システム異常の種別を自動的に診断する手法の総称である。従来の監視データ（CPU・メモリ・I/O メトリクス）やアプリケーションログを用いた異常診断に対する**オルタナティブ**であり、最大の特徴は Raft ログがシステム動作の必要条件であるため**収集に追加オーバーヘッドをほぼ要しない**点にある。 Raft ログは、ログエントリの種類（操作タイプ・データサイズ）と合意に要したタイムスタンプ情報を含む。これらから抽出できる 3 種の時系列特徴量——raft-latency（コンセンサス到達遅延）・local-latency（ノード間ネットワーク遅延）・value-size（操作データサイズ）——が異常種別ごとに固有のパターンを示すことが実証されている。(Source: [[@2025__IEEE TSC__Towards Close-To-Zero Runtime Collection Overhead - Raft-Based Anomaly Diagnosis on System Faults for Distributed Storage System]]) ## 背景：監視データとアプリログの問題 既存の異常診断手法は以下の 2 データ源を主に使う： | データ源 | 手法例 | 問題 | |---------|--------|------| | **監視データ**（メトリクス） | openGauss, DBSherlock | 収集エージェントが必要。IoTDB での書き込みスループット -23.79% | | **アプリケーションログ** | LogKG, LogCluster, Cloud19 | デバッグログは性能を -50% 以上低下。通常ログでも -55.37% | 「より詳細なデータほど精度が上がるが収集コストも増す」というジレンマに対し、Raft ログはコンセンサス動作の副産物として**無条件に生成される**ため、収集コストをほぼゼロ（IoTDB での書き込み低下 1.3%）に抑えられる。(Source: [[@2025__IEEE TSC__Towards Close-To-Zero Runtime Collection Overhead - Raft-Based Anomaly Diagnosis on System Faults for Distributed Storage System]]) ## Raft ログが異常を反映するしくみ Raft コンセンサスはリーダーとフォロワー間で操作ログを同期し、過半数ノードの合意をもって完了する。この同期プロセスは以下の要因に敏感に反応する： - **CPU 飽和**: マージソート等の CPU ヘビータスクが合意処理を遅延 → raft-latency が単調増加 - **IO 飽和**: ディスク帯域の枯渇がレプリカ書き込みに影響 → raft-latency に大きなスパイク - **ネットワーク分断**: リーダー選出の遅延 → raft-latency が持続的に急増 - **ワークロードスパイク**: 高負荷での並列書き込みが実際にはスループットを高める → raft-latency が低下（逆説的パターン） - **ロック競合**: 均一な遅延増加でスパイクなく全体レイテンシが上昇 すなわち Raft ログは、分散システムが「何かを提案して合意する」たびに書き残す動作記録であり、異常はその速度変化や値のサイズ変化として滲み出る。(Source: [[@2025__IEEE TSC__Towards Close-To-Zero Runtime Collection Overhead - Raft-Based Anomaly Diagnosis on System Faults for Distributed Storage System]]) ## 代表的実装：RBAD [[RBAD]]（Raft-Based Anomaly Diagnoser）は本概念の最初の公開実装である。[[Lingzhe Zhang]]・[[Tong Jia]]・[[Ying Li]] ら([[Peking University]])が提案し、IEEE Transactions on Services Computing に掲載。 ### RBAD のアーキテクチャ 1. **前処理**: Timestamp Injector でタイムスタンプを付加し、Raft-Feature Extractor で 3 特徴量を抽出、カルマンフィルタでノイズ除去。 2. **オフライン特徴分析**: DTW（動的時間伸縮法）で各異常クラスの代表パターン時系列を選定し、距離行列を Min-Max 正規化で構築。 3. **オンライン診断**: 入力 Raft ログの特徴を既知パターンと比較し、全結合層（学習済み重み）で最近傍の異常クラスを出力。 Apache IoTDB（Multi-Raft 対応）に統合済み。スナップショット生成時に診断をトリガーするため、Active なログへの侵入を回避。 ## 横断的知見 - **「Raft ログは収集コストゼロ」という命題は、監視データ・ログの二択を崩す第三の選択肢を開く**: 異常診断の研究は「高精度には詳細データが必要」と「詳細データは収集コストが高い」のジレンマに縛られてきた。RBAD の実験では書き込みスループット低下 1.3% でモニタリング比 +15.38%・ログ比 +53.10% の精度向上を実現し、このジレンマが「収集コストゼロかつ細粒度」なデータを選ぶことで解消できることを示した。Raft ログは合意アルゴリズムの一部であり、システムがそれなしでは動作できないため、収集の追加コストは構造的に小さい。(Source: [[@2025__IEEE TSC__Towards Close-To-Zero Runtime Collection Overhead - Raft-Based Anomaly Diagnosis on System Faults for Distributed Storage System]]) - **Raft ログの診断精度が監視データとログの両方を上回るのは「広範な異常カバレッジ」による**: 論文の分析によれば、監視データは CPU/IO 系異常を得意とし、アプリログはパターンマッチで特定障害種別を捉えるが、それぞれが苦手とする異常種別がある。Raft ログはシステム全体の通信・合意の遅延変化として異質な異常（ネットワーク分断・ロック競合・設定エラー等）を横断的に反映するため、単一データ源として最広のカバレッジを持つ。これは [[異常検知]] における「マイクロサービス異常検知では『データ源の統合』が常に性能改善を意味しない」という観察と表裏一体——適切な単一データ源が複数データ源の統合を上回りうる。(Source: [[@2025__IEEE TSC__Towards Close-To-Zero Runtime Collection Overhead - Raft-Based Anomaly Diagnosis on System Faults for Distributed Storage System]]) - **コンセンサスログというデータ源の発想はクラウドネイティブの普及によって初めて実用的になった**: 2024 年時点で DB-Engine ランキング上位の大半は Raft または Paxos 系コンセンサスを採用している（TiDB・Apache IoTDB・OceanBase・Google Spanner 等）。コンテナ化された分散 DB が標準環境になった現代では、Raft ログはほぼ全ての分散 DB に存在する共通データ源となっており、本概念の適用範囲は広い。逆に Raft を採用しない旧来型 DB（MySQL マスタースレーブ等）には適用できない制約も残る。(Source: [[@2025__IEEE TSC__Towards Close-To-Zero Runtime Collection Overhead - Raft-Based Anomaly Diagnosis on System Faults for Distributed Storage System]]) - **DTW による時系列パターンマッチは「ノイズへの頑健性」と「異なる長さへの対応」で選ばれた**: 異常診断に機械学習ではなく DTW を採用したのは、DTW がノイズに頑健で異なる長さの時系列を比較できるからである。時間計算量 $O(n^2)$ の問題は 10 秒時間窓で $n$ を制御することで解決し、GPU なしで数秒以内の推論を実現した。RBAD は「常時稼働の検知に LLM は重すぎる」([[異常検知]]の横断的知見)という制約に対し、LLM なし・軽量統計手法路線でも高精度が出せることをデモした最初の分散ストレージ専用手法でもある。(Source: [[@2025__IEEE TSC__Towards Close-To-Zero Runtime Collection Overhead - Raft-Based Anomaly Diagnosis on System Faults for Distributed Storage System]]) ## 未解決の問い - Raft 以外のコンセンサスアルゴリズム（Paxos・Zab・Multi-Paxos）を使う分散システムに同様の「コンセンサスログ診断」が適用できるか。各アルゴリズムの内部ログ構造がどの程度異なるか。 - RBAD の DTW 時間計算量 $O(n^2)$ は 10 秒時間窓でコントロールされているが、高負荷時に時間窓内ログが急増したときのレイテンシ保証はどうなるか。ストリーミング対応の DTW 近似アルゴリズム（FastDTW 等）と精度はどう両立するか。 - Raft ログのパターンは 14 種の異常について実証されたが、産業環境では「未知の異常」が高い頻度で現れる。RBAD の最近傍分類は「合理的なカテゴリへの帰属」を示したが、実際の運用での誤分類率はどのくらいか。アクティブラーニングで新規異常クラスを追加できるか。 - 複数の異常が同時に発生している場合（例: ネットワーク分断中にメモリ飽和も起きる）、Raft ログのパターンは複合的になり、単一クラス分類では対処できない。マルチラベル分類や混合状態の分解は可能か。 - Raft ログ診断と既存の監視データ/アプリログ診断を補完的に組み合わせるハイブリッド手法は精度をさらに向上させるか、それともデータ源の増加が誤検知を増やすか。マルチソース統合のトレードオフ([[@2025__IEEE TSC__Towards Close-To-Zero Runtime Collection Overhead - Raft-Based Anomaly Diagnosis on System Faults for Distributed Storage System]] §VI で Hades との比較あり)。 - 本概念を Kubernetes 上の分散ストレージ（etcd・TiKV・Rook）に適用する場合、Multi-Raft のリージョン単位の診断をどう集約してクラスタ全体の健全性を判断するか。 ## 関連 - ソース: [[@2025__IEEE TSC__Towards Close-To-Zero Runtime Collection Overhead - Raft-Based Anomaly Diagnosis on System Faults for Distributed Storage System]] - エンティティ: [[RBAD]] / [[Lingzhe Zhang]] / [[Tong Jia]] / [[Ying Li]] / [[Peking University]] - 関連概念: [[分散ストレージ]] / [[異常検知]] / [[AIOps]] - 関連 MOC: [[AIOps - Failure Detection - MOC]] ## 出典 - [[@2025__IEEE TSC__Towards Close-To-Zero Runtime Collection Overhead - Raft-Based Anomaly Diagnosis on System Faults for Distributed Storage System]]