# 信頼性を持つ大規模ログ収集アーキテクチャ ## 定義 多数のホストが生成するログファイルやメトリクスを、単一障害点となりうる中継プロセス（コレクタ）を経由して分散ファイルシステムへ集約する際に、コレクタ自体を耐障害化するのではなく、コレクタをステートレスにしてデータ発生元のエージェントに再送責任と状態を全て寄せることで、コレクタ障害からのデータ損失を防ぐアーキテクチャ様式を指す。[[Chukwa]] はこの様式を体現し、エージェントがコレクタ経由で分散ファイルシステム上のファイル長をポーリングして書き込みの成否を自ら検知し、失敗時は別のコレクタへフェイルオーバーして再送する。少なくとも1回配信＋MapReduce ジョブでの重複除去という組み合わせで「発生元マシンが恒久故障しない限りデータは最終的に配信される」という信頼性基準を達成する（[[@2010__LISA__Chukwa - A System for Reliable Large-Scale Log Collection]])。 この様式は、[[Scribe]] のようにコレクタ（サーバ）側にデータの責任を持たせ、送信元がコピーを保持しない設計（コレクタ障害がそのままデータ損失につながる）と対照的である。 ## 未解決の問い - コレクタをステートレスにするエンドツーエンド設計と、Scribe のようにコレクタに責任を持たせるホップバイホップ設計との間に、スループットやレイテンシで測定可能なトレードオフがあるか。Chukwa 論文はコレクタが概ね I/O バウンドであることしか示しておらず、両アーキテクチャの定量比較は行っていない。 - 分散ファイルシステム自体（HDFS の Namenode 等）が単一障害点として残る場合、エンドツーエンドの信頼性モデルはその停止をどこまで吸収できるか。Chukwa は一時的な全コレクタ停止をエージェント側のバッファで吸収できることを示したが、Namenode 障害からの復旧そのものは対象外である。 - 「信頼できる経路」と「fast path」のような二重配信モデルは、後継システム（Flume・Kafka 等）でどのように継承・淘汰されたか。 ## 未編纂の観察 ## 関連 - ソース: [[@2010__LISA__Chukwa - A System for Reliable Large-Scale Log Collection]] - エンティティ: [[Chukwa]] / [[Scribe]] / [[HDFS]] - 概念: [[階層型メトリック収集アーキテクチャ]]（fan-in を持つ階層的収集という共通点、ただし信頼性モデルは異なる） ## 出典 - [[@2010__LISA__Chukwa - A System for Reliable Large-Scale Log Collection]]