# Chukwa: A System for Reliable Large-Scale Log Collection > [!abstract] 概要(abstract の日本語訳) > Google、Yahoo、Facebook のような大規模インターネットサービス企業は、ログデータの処理に MapReduce プログラミングモデルを使う。MapReduce は Hadoop の HDFS のような分散ファイルシステムに格納されたデータ上で動作するよう設計されている。その結果、データを HDFS にコピーするための多くのログ収集システムが構築されてきた。これらのシステムは、しばしば障害処理への統一的なアプローチを欠いており、エラーは収集・転送・処理パイプラインの各部分でそれぞれ個別に扱われている。 > 我々はこれに代えて、統一的なアプローチを主張する。我々はこのアプローチを体現するシステム、Chukwa を提示する。Chukwa は、信頼性のためにローカルディスク上のログファイルを活用できるエンドツーエンドの配信モデルを使う。このアプローチは、レガシーシステムとの統合も容易にする。このアーキテクチャは配信モデルの選択肢を提供し、収集データの部分集合を必要とするクライアントに即座に利用可能にしつつ、HDFS にコピーを信頼性高く格納する。我々は、200ノードのテストベッド上でシステムが正しく動作し、200 MB/秒を超えるログデータを収集できることを実証する。我々はこれらの測定結果を、複数のサイトにおける実運用経験を記述した一連のケーススタディで補完する。 ## 論文情報 - 著者: Ariel Rabkin ([[University of California, Berkeley]])、Randy Katz ([[University of California, Berkeley]]) - 会議: USENIX LISA '10(24th Large Installation System Administration Conference)、2010年 - URL: https://www.usenix.org/conference/lisa10/chukwa-system-reliable-large-scale-log-collection - PDF直リンク: https://www.usenix.org/events/lisa10/tech/full_papers/Rabkin.pdf - キーワード: logging, scale, research - 先行研究: 同著者らによる初期プロトタイプ論文 Boulon et al., "Chukwa, a large-scale monitoring system"（CCA '08）を本論文が発展させたもの。 ## 概要 [[Chukwa]] は、多数のホストが生成するログファイルを Hadoop の [[HDFS]] に信頼性高く集約し、[[MapReduce]] で処理可能な形にするログ収集システムである。既存の多くのログ収集システム（[[Scribe]] 等）が単一の狭い RPC インターフェースを露出し、障害処理を収集パイプラインの各部品にばらばらに任せているのに対し、Chukwa はエンドツーエンドの配信モデルを採用し、監視対象ホストのローカルディスク上のログファイルを信頼性の拠り所として利用する。これにより、レガシーシステムとの統合が容易になり、かつコレクタ部分の実装を大幅に単純化できる。200ノード規模のテストベッドで正しく動作し、200 MB/秒超のログデータを収集できることを実証し、CBS Interactive・Specific Media・UC Berkeley の SCADS プロジェクトでの実運用経験も報告する。 ## 問題設定 - MapReduce と HDFS は大きなファイル（GB 単位）を前提に最適化されており、POSIX セマンティクスを持たず、複数クライアントによる同時 append にも対応しない。そのため、多数の小さなログファイルを継続的に更新するというログ収集のワークロードと、少数の大きなファイルを想定するファイルシステムの間に「インピーダンスミスマッチ」が生じる。 - 従来の解決策は、アプリケーションがネットワーク越しにログメッセージを「コレクタ」と呼ばれるデーモンへ送り、コレクタがファイルシステムへの書き込みをシリアライズするというものである（Rapleaf・Rackspace・Facebook の Scribe 等）。これらのシステムはログ収集を単なるネットワークサービスとして扱い、データが書き込まれた後は監視システムが関与しない。 - この分離は一見魅力的な設計だが、レガシーシステムのログファイル監視には不向きである。監視システムが成功・失敗を報告できなければ、ディスク上のファイルを安全に削除できない。一過性の障害時にデータをバッファする必要があり、送信直後に成否が確定する同期 RPC モデルでは不十分である。 - 設計目標として次を掲げる: (1) ログファイル以外にもシステムメトリクスや syslog 等の多様なデータソースをサポートする、(2) 監視システムが停止しても被監視システムの動作を妨げない、(3) 10,000ホスト・30 MB/秒規模までスケールする、(4) 監視のオーバーヘッドをクラスタリソースの5%以内に抑える、(5) バーストトラフィック下でも監視システムのリソース消費が資源上限内に留まる。 - 信頼性と「被監視システムをブロックしない」ことは本質的に相反する。Chukwa が採用した妥協点は、「データ発生元のマシンが恒久的に故障しない限り、データは最終的に配信される」という基準である。また、MapReduce ジョブのスケジューリングオーバーヘッドを考えると、1〜2分以内のデータ可視化は目標としない。 ## 提案手法 - **エージェントとコレクタの分離**: Chukwa は監視対象ホストごとに動作する「エージェント」（状態保持・チェックポイントあり）と、HDFS への書き込みを担う「コレクタ」（ステートレス）の2クラスのプロセスに分離する。全ての状態はエージェント側に集約され、定期的にディスクへチェックポイントされるため、障害復旧が容易になる（図1, Figure 1）。 ![[fig01-architecture-flow.png]] - **アダプタ機構**: エージェントは直接データを受信せず、動的にロード可能な「アダプタ」というモジュールがファイルやアプリケーションから直接データを読み取る。ログファイルの tail、Unix コマンドの実行、UDP（syslog 含む）受信のアダプタがあり、アダプタは入れ子にできる（例: バッファリング用アダプタ、write-ahead logging 用アダプタ）。ログローテーションはアダプタの責任として扱われ、`foo.*` にマッチするファイルをファイル更新日時で順序付ける方式をデフォルトとする。 - **エンドツーエンドの信頼性モデル**: コレクタを耐障害化する代わりに、エージェントがコレクタ経由で HDFS 上のファイル長をポーリングし、書き込みの成否を自ら検知する。コレクタは各エージェントに対するデータ書き込み先ファイル名とオフセットを返すだけで、per-agent 状態を持たない。障害時、エージェントは最後のチェックポイントから別のコレクタへフェイルオーバーして再送する（少なくとも1回配信、MapReduce のアーカイブジョブが重複除去を行う、図2, Figure 2）。 ![[fig02-async-ack-flow.png]] - **2つの配信モデル**(表1, Table 1): 「信頼できる経路」は Hadoop sequence file 形式で HDFS に書き込み、クラッシュ後に再送し、順序も保証するが可視化まで数分かかる。「fast path」は TCP ソケット経由でクライアントへ直接ストリーミングし、数秒で可視化できるが、再送・順序保証はなく、ユーザ指定のフィルタリングのみを行う。両者は排他ではなく併用でき、fast path のクライアントは HDFS 上の信頼できるコピーで欠損を後から補完できる。 | | 信頼できる経路(Reliable delivery) | Fast-path delivery | |---|---|---| | 可視化までの時間 | 数分 | 数秒 | | 書き込み先 | HDFS | ソケット | | クラッシュ後の再送 | あり | なし | | 対象データ | 全データ | ユーザ指定のフィルタリング | | 用途 | MapReduce 処理 | ストリーム処理 | | 順序保証 | あり | なし | 表1（Table 1）: Chukwa が提供する2つの配信モデル - **メタデータモデル**(表2, Table 2): 各チャンクに Source（発生ホスト）・Cluster（ユーザ設定の仮想クラスタ名）・Datatype（ユーザ設定のデータ種別）・Sequence ID（ストリーム内オフセット）・Name（ストリーム名）の5フィールドを自動付与する。タイムスタンプは意図的に含めない。理由は、同一ファイルから連続して読んだ複数チャンクが同一タイムスタンプを持ちうること、チャンク単位のタイムスタンプは粒度が粗すぎて分析に不適であること、行単位のタイムスタンプは通常ログ本文に既に含まれ冗長であることの3点である。シーケンス番号のギャップにより、TCP のシーケンス番号と同様の方法でデータ欠損を検知できる。 | フィールド | 意味 | 生成元 | |---|---|---| | Source | チャンクが生成されたホスト | 自動 | | Cluster | ホストが属するクラスタ | ホストごとにユーザ設定 | | Datatype | 出力の形式 | ストリームごとにユーザ設定 | | Sequence ID | ストリーム内でのチャンクのオフセット | 自動 | | Name | データソース名 | 自動 | 表2（Table 2）: Chukwa のメタデータスキーマ - **アーカイビング**: MapReduce ジョブがコレクタの sink ディレクトリのファイルを定期的にクラスタ・日付・データ種別でグループ化し、重複除去とデータ欠損検知を行いながら段階的により大きなファイルへ圧縮する。Chukwa は検索ツールと Pig 連携も提供する。 ## 新規性 - 従来の Scribe 等はコレクタ側で信頼性を確保しようとし、コレクタに障害が起きるとデータ喪失につながる。Chukwa はコレクタを完全にステートレスにし、信頼性のための状態を全てエージェント（データ発生元）に寄せるという逆転した設計を取る。これが本論文の中心的な貢献である。 - ローカルディスク上の既存ログファイルを「タダで手に入る」耐障害化機構として積極的に活用する発想（「fault-tolerance from local disk」）は、レガシーシステムとの統合を前提にした設計判断であり、Scribe のようなクライアントがアプリケーション改修を要するアプローチと対照的である。 - 単一の狭いプロトコルに縛られず、アダプタというプラグイン機構により多様なデータソース（ファイル・UDP・Unix コマンド出力）を統一的に扱える点、および信頼できる経路と fast path という質的に異なる2つの配信保証をユーザが用途ごとに選べる点も、他システムには見られない特徴である。 - タイムスタンプをメタデータから意図的に排除し、代わりにシーケンス番号でギャップ検出するという設計判断は、分散システムにおけるログの順序保証の考え方として明快である。 ## 実験設定 - Amazon EC2 上に構築（Ubuntu Linux, kernel 2.6.21、Hadoop 0.20.0）。 - オーバーヘッド測定: Cloudstone ベンチマーク（Ruby on Rails + MySQL、9ノード EC2 "extra large" インスタンス、Chukwa がコンソールログとシステムメトリクスを1ノードあたり60 KB/分収集）。加えて、20ノードの Hadoop クラスタで標準の random-writer・word-count ジョブ（50 GB のランダムテキストを生成・索引付け、1ノードあたり平均1296アダプタ、約120 KB/分）を実行。 - Fan-in測定: 単一コレクタと200エージェントの組で20分間実行し、5ノード HDFS クラスタへの書き込みレートを計測（fan-in 200:1）。 - スケール測定: Hadoop クラスタサイズを変えながら各 Hadoop ワーカーノードに1つずつコレクタを配置し、コレクタを飽和させるだけのエージェントを起動、ホスト固有の疑似乱数シードを埋め込んだ検証可能な疑似データを送信して集約書き込み帯域を測定。 - 障害耐性測定: (1) 恒久障害 — 10分運転後にコレクタを2台恒久停止し、さらに10分運転（複数クラスタサイズで反復）。(2) 一過性の全コレクタ障害 — 128エージェント・10コレクタで開始し、5分ごとに全コレクタの起動・停止を3サイクル繰り返し、HDFS Namenode 障害のようなシナリオを模した。 ## 実験結果 - Cloudstone: Chukwa 有無での実行は3%以内の差に収まり、統計的に区別できなかった（図3, Figure 3、1回ずつ Cloudstone 実装バグで失敗した run は除外）。 ![[fig03-cloudstone-benchmark.png]] - Hadoop word-count/random-writer: Chukwa 有無でジョブ完了時間は統計的に区別できず、3%を超えるオーバーヘッドの可能性を排除できた（図4, Figure 4）。 ![[fig04-hadoop-job-duration.png]] - Fan-in: 単一コレクタは fan-in 200:1 で最大約30 MB/秒を処理でき、これはこの EC2 構成での HDFS の典型的な最大書き込みレートとほぼ一致した（図5, Figure 5）。損失・重複・破損チャンクは観測されなかった。 ![[fig05-throughput-vs-send-rate.png]] - スケール: DataNode 数に対してほぼ線形に集約書き込み帯域がスケールし、1ノードあたり約10 MB/秒、コレクタは概ね I/O バウンドで CPU 負荷は低かった（図6, Figure 6）。 ![[fig06-aggregate-scaling.png]] - 恒久障害耐性: コレクタを2台恒久停止しても、コレクタからのローカル書き込み比率低下によりスループットはわずかに低下するのみで、データは欠損・破損なく全て受信された（図7, Figure 7）。 ![[fig07-before-after-collector-kill.png]] - 一時的全障害耐性: 全コレクタ停止中はデータ転送が止まるが、再起動のたびに自動的に再開し、3サイクルの停止・再開を通じてデータ損失はゼロだった。データレートは再開後すぐに約100 MB/秒まで回復した（図8, Figure 8）。 ![[fig08-intermittent-collectors.png]] - 5%のクラスタリソース制約という目標のもとで、1000ノードクラスタなら約20台の専用コレクタ・fan-in 50:1で十分に運用できると試算している（実測ではなく推定）。 ## 考察 - **CBS Interactive**（ニュースサイト）と **Specific Media**（広告配信）のケーススタディでは、アプリケーションサーバのローカルログを Chukwa が小さな Hadoop クラスタへコピーし、Pig ジョブで集計して MySQL に格納、内部 Web アプリで参照するというパイプラインが使われている。CBS Interactive では単一コレクタで日次数ギガバイトの負荷に対応できている。 - **SCADS**（UC Berkeley の低レイテンシデータストアプロジェクト）の Director コンポーネントは、fast path 経由で X-Trace（[[@2007__NSDI__X-Trace - A Pervasive Network Tracing Framework]]）形式のレポート（1ノードあたり60〜90 KB/秒）を数秒以内に受け取り、データ配置判断に利用する。SCADS 側は UDP でローカル送信し（TCP のブロッキングを避けるため）、一部のデータ欠損は許容している。信頼できる経路も併用し、後からの分析・デバッグに利用している。 - Xu et al. の機械学習ベース異常検知（コンソールログのメッセージ数を識別子ごとに比較する手法）を Chukwa と統合した事例を挙げ、この種の分析は欠損に弱く、Chukwa が提供する信頼性保証が実運用での適用を可能にすると論じている（統合作業自体は約30行の Java コード）。 - 関連研究として、syslog（信頼性なし）、Splunk（高可用性なし）、Scribe（クライアントがコレクタに責任を委譲するため end-to-end 保証がない）、Microsoft Research の Artemis（ノード上その場での解析、耐久ストレージなし）、Flume（Chukwa 後発、集中管理された flow リストを Zookeeper に冗長格納する hop-by-hop モデル）、Astrolabe・PIER・Ganglia（クエリ機能に特化し大容量の半構造化ログ格納は想定しない）と比較している。 ## 強み / 弱点・課題 - **強み**: エージェント側に状態を集約しコレクタをステートレスにするエンドツーエンド設計により、コレクタ障害からの復旧がシンプルになる。実測でオーバーヘッド3%以内・200 MB/秒までの線形スケール・恒久/一時的コレクタ障害からのデータ無損失復旧を裏付けており、設計目標の達成を定量的に示している点は説得力がある。アダプタ機構と信頼できる経路/fast path の使い分けは、レガシー統合と低レイテンシ用途の両方に応える柔軟性を持つ。 - **弱点・課題**: HDFS Namenode 自体は単一障害点として残り、Chukwa の end-to-end モデルでも Namenode 障害中はデータがエージェント側に滞留するだけである（本論文はこれを一時的全障害実験でシミュレートしているが、Namenode 障害からの復旧そのものは Chukwa の守備範囲外）。fast path は順序保証・重複排除ともになく、データ欠損時の補正をアプリケーション側に委ねる。1000ノード・50:1 fan-in での運用見積もりは実測ではなく外挿である。評価は最大でも20コレクタ・200 MB/秒規模までであり、論文自身が言及する Artemis の277 MB/秒という報告値との比較は理論的な議論に留まる。ケーススタディは3社の質的な運用経験にとどまり、定量的な障害発生率などは示されていない。 ## 関連 - [[Ariel Rabkin]] / [[Randy H. Katz]] / [[University of California, Berkeley]] - [[Chukwa]] - [[Scribe]] / [[HDFS]] / [[MapReduce]] - [[信頼性を持つ大規模ログ収集アーキテクチャ]] - [[階層型メトリック収集アーキテクチャ]]（fan-in を持つ階層的収集アーキテクチャという観点で関連） ## 出典 - Ariel Rabkin, Randy Katz. "Chukwa: A System for Reliable Large-Scale Log Collection." USENIX LISA '10, 2010. https://www.usenix.org/conference/lisa10/chukwa-system-reliable-large-scale-log-collection