# @2017__SOSP__Canopy - An End-to-End Performance Tracing And Analysis System ## 論文情報 | 項目 | 内容 | |---|---| | 題名 | Canopy: An End-to-End Performance Tracing And Analysis System | | 著者 | Jonathan Kaldor, [[Jonathan Mace]], Michał Bejda, Edison Gao ほか (Facebook / Brown University) | | 会議 | SOSP 2017（第26回 ACM シンポジウム on オペレーティングシステムの原理）| | 掲載年月 | 2017年10月 | | DOI | 10.1145/3132747.3132749 | ## 概要（アブストラクト和訳） 本論文は Canopy を紹介する。[[Facebook]] のエンドツーエンド性能トレース基盤であり、ブラウザ・モバイルアプリ・バックエンドサービスを含むリクエストのエンドツーエンド実行パス全体にわたって、因果的に関連付けられた性能データを記録する。Canopy はトレースをほぼリアルタイムで処理し、ユーザー指定の特徴量を導出して、何十億件ものリクエストを集約する性能データセットに出力する。Canopy を利用することで、Facebook のエンジニアは性能データをリアルタイムでクエリ・解析できる。Canopy は性能解析をスケールさせる上で直面した三つの課題に取り組む。(1) Facebook スタックの各コンポーネントが使用する多様な実行・性能モデルへの対応、(2) 性能データのインタラクティブな臨機応変解析への対応、(3) サンプリングポリシーから特徴量抽出・可視化まで深い利用者カスタマイズの実現。Canopy は現在、1 日 10 億件以上のトレースを記録・処理している。論文では Canopy が広範なシナリオに適用されてきた経緯を論じ、様々な性能課題解決へのケーススタディを示す。 ## 問題設定 ### 背景と動機 Facebook では、Canopy 以前から複数のトレースシステムが個別に開発されていた。バックエンドサービス向けの RPC 呼び出しツリー計装、ブラウザのページロードトレース、モバイルアプリ向けの OS 提供トレースなどが独立して存在していた。しかしこれらはサイロ化しており、システム横断の洞察を得ることが困難であった。 ### 三つの主要課題 1. **トレースデータのモデリング**: エンドツーエンドの性能データは不均一で、複数の実行モデル（スレッド・イベントループ・継続・キュー・RPC）と計装品質の多様な変動が存在する。生のイベントデータを直接扱うことはエンジニアにとって困難であり、一方で高レベルモデルを計装に固定することもレガシーや将来の変更への対応で問題が生じる 2. **集約とスケール**: 1 日 13 億件のトレース（各トレースに数千のイベント）に対して、エンジニアが必要とするインタラクティブなクエリを直接実行するのは計算量的に不可能 3. **多様なユースケースへの対応**: 多くのエンジニアが同じトレース基盤を共有しており、各自の調査に関連するデータだけを柔軟に取り出す手段が必要 ## 提案手法 ### 設計の核心: 計装・モデル・特徴量抽出の三層分離 Canopy は三層を明示的に分離することで各層が独立に進化できる設計とする。 ![[wiki/sources/_attachments/kaldor2017canopy/fig-overview-pipeline.png]] *図: Canopy のパイプライン全体像（図2: 開発者が計装 API を使いイベントを生成し、テイラーがモデル構築・特徴量抽出・データセット出力を行う）* #### トレースモデル（Modeled Traces） Canopy のトレースモデルは **実行ユニット(execution unit)**・**ブロック(block)**・**ポイント(point)**・**エッジ(edge)** の四要素で構成される。 - **実行ユニット**: スレッドに相当する高レベルの計算タスク - **ブロック**: 実行ユニット内の計算セグメント（Dapper のスパンに対応） - **ポイント**: ブロック内の瞬間的なイベント - **エッジ**: ブロックや実行ユニット間の非自明な因果関係（ネットワーク通信・キューイング・ストリーミング等） 重要な設計判断として、計装 API はイベント（DAG ノード）として実装し、モデルのセマンティクス（ブロックの開始/終了・エッジの送受信）は後処理で付与する。これにより計装ライブラリとモデルの間の結合が緩くなり、それぞれを独立に進化させられる。 #### イベント表現 全ての計装 API は共通のイベント表現に写像される。イベントは `traceID`・`type`・`id1/id2`・`sequenceNumber`・`timestamp`・`annotations` から構成される（Thrift 定義）。22 種類のイベントタイプを定義しており、新しい計装ライブラリは既存タイプを再利用するか新規定義できる。 #### 特徴量抽出パイプライン ![[wiki/sources/_attachments/kaldor2017canopy/fig-feature-extraction-dsl.png]] *図: DSL による特徴量抽出の例（Display Done レイテンシ・クリティカルパス上のリソース読み込み時間等）* Canopy はドメイン固有言語（DSL）を提供し、特徴量をパイプライン関数として記述できる。例えば「ブラウザ表示完了レイテンシ」は `ExecUnits | Filter(name="Client") | Points | First` でクライアント開始点を求め、`DisplayDone | Timestamp | Subtract(Begin | Timestamp) | RecordAs("display_done")` で計算する。特徴量抽出関数はトレースごとに独立して評価されるステートレス関数である。 #### データセットと Scuba 統合 特徴量抽出結果はデータセットに出力される。多くのデータセットは [[Scuba]]（Facebook のインメモリ分析データベース）に出力され、エンジニアはリアルタイムでスライス・集計・可視化を行える。2017 年 4 月時点で 129 のデータセットが稼働している。 ### サンプリングポリシー Canopy は二層のサンプリング機構を持つ。 1. **分散トークンバケット**: テナントごとにデフォルト 5 トレース/秒でグローバルにレートリミットする 2. **サンプリングポリシー**: ユーザーが所有者・サンプリング戦略（確率またはレート）・制約（エンドポイント・データセンター・地域等）・有効期間・詳細レベルを設定できる高レベル抽象。特定の低 QPS API や特定の実行パスを狙い打ちにできる **日和見的トレーシング(Opportunistic Tracing)**: サーバー側でサンプリング決定が行われるケースで、クライアントはメモリにイベントをキャッシュし、サーバーからサンプリング決定を受け取って初めてフラッシュまたは破棄する。 ### テイラー（バックエンドパイプライン） ![[wiki/sources/_attachments/kaldor2017canopy/fig-tailer-architecture.png]] *図: テイラーのアーキテクチャ（図7: フェッチャー・トリガー・スケジューラ・ビルダー・エクストラクタ・遅延エクストラクタで構成）* テイラーは TraceID でシャードされた処理パイプラインであり、フェッチャー・HBase 永続化・インメモリキャッシュ・トリガー・ビルダー・孤立キュー(isolation queue)・エクストラクタ・遅延エクストラクタで構成される。負荷分散は**欠乏ラウンドロビン(deficit round-robin)**でエクストラクタのCPU時間をキュー間で公平配分し、過負荷テナントを遅延エクストラクタにオフロードする。 ## 新規性 1. **計装とトレースモデルの分離**: 先行システム（Dapper・Zipkin）はトレースモデルを計装 API に固定していた。Canopy はイベント DAG を汎用表現として採用し、モデルをバックエンドで後付けで適用することで、計装とモデルの独立進化を実現した 2. **フィーチャー抽出ステップ**: 集約分析の中間ステップとして特徴量抽出を独立した一等概念として設計した。先行研究（G2・Pivot Tracing）は生トレースや動的計装に限定されており、事前計算による大規模集約が困難だった 3. **パフォーマンスデータセット**: トレースを下流のデータセットに変換する多様な視点を同一のトレースモデルから生成できる設計 ## 実験設定と評価 ### 本番環境規模 - Facebook 本番環境で 2 年間稼働（2015〜2017年） - 1 日 13 億件のトレースを生成・処理（ブラウザ・モバイル・バックエンドサービスにまたがる） - 129 の性能データセット、2,852 列を 45 データセット以上で提供 - バックエンドリソース使用量はデータセンターの 0.1% 未満 ### 計装オーバーヘッド（表1） | 対象 | 中央値ウォールクロック増加 | |---|---| | Facebook.com (WWW) | +2.14% | | Android コールドスタート | +10.78% | | ServiceA（短時間・詳細計装） | +8.15% | | ServiceB（長時間・最小計装） | <1% | ### 負荷分散実験（§5.2） モバイルテナントに模擬負荷スパイクを注入した実験で、孤立キューが満杯になると Mobile トレースが遅延エクストラクタにオフロードされ、非モバイルテナントの処理スループットは本番テイラーと一致することを確認した（図10）。 ### ケーススタディ（§5.4） 1. **因果順序の問題**: 低優先度ページパーツ「Suggestions」がサーバー側クリティカルパスに予期せず出現。非同期継続の処理系バグと特定、10.4M リクエストへの影響を定量化した 2. **サブ集団の回帰**: 2016〜2017年インド洋サイクロン・海底ケーブル切断による 50ms のグローバル回帰を国別分解で即座に特定した 3. **改善点の特定**: CSS ページロードの早期フラッシュ最適化。DB クエリ最適化（インデックス欠落）で DB 時間 99% 削減・ページロード 50% 高速化 ## 考察と経験（§6） - **共通データセットが入口**: カジュアルユーザーにはドメイン共通データセットが入口となり、トレース構造を意識させない。モバイルはクリティカルパスの正確な計装が困難なため、リソースカウンタ中心のデータセットとなる - **DSL の表現力の限界**: 全ての分析が DSL で表現できるかどうかは未解決の問いである。複雑な特徴量は一般目的言語（Python ノートブック）への統合で補完している - **計装エラーパターン**: TraceID 伝搬と実際のトレースを混同すること（全リクエストをトレースしたいと思い込む）と、TraceID の不正伝搬（終わらないトレースの生成）が最も多い計装ミスである ## 強みと弱点 ### 強み - **完全なパイプライン**: 計装 → イベント収集 → トレースモデル構築 → 特徴量抽出 → インタラクティブ解析まで一貫した設計 - **スケーラビリティ**: TraceID シャーディングにより通信不要で水平拡張でき、Mystery Machine の「130万トレースで2時間」に対して 13 億トレース/日を処理 - **独立進化**: モデルを 5 回改訂（ブロックモデル → 実行ユニット追加 → CQ イベント追加 → エッジ分解へ）した一方、既存計装は後方互換を維持した ### 弱点 - **サンプリング対象外リクエストの調査不可**: サンプリングされなかった特定ユーザーの異常報告には対応困難 - **日和見的トレーシングの制限**: 小規模かつ既知のコンポーネント数に限定される。大規模ファンアウトや多段ホップには対応できない - **計装なし層の盲点**: 計装されていないコンポーネントや旧バージョンのサービスはトレースから欠落する ## 他システムとの比較 | システム | アプローチ | Canopy との差異 | |---|---|---| | **Dapper (Google 2010)** | スパンツリー + ヘッドサンプリング | Canopy はイベント → モデル分離で汎用化 | | **X-Trace (NSDI 2007)** | ネットワークトレーシングフレームワーク | Canopy は特徴量抽出ステップを追加 | | **Zipkin** | スパンベース、OSS | キュー等の実行モデルに対する表現力の限界 | | **Pivot Tracing** | 動的計装・クエリの組み合わせ | 過去トレースの歴史分析ができない | | **Mystery Machine** | ブラックボックス因果推定 | 130万トレースで2時間 vs. Canopy は 13億/日 | ## 関連 - エンティティ: [[Canopy]] / [[Jonathan Kaldor]] / [[Jonathan Mace]] / [[Facebook]] / [[Scuba]] - 概念: [[分散トレーシング]] / [[トレースサンプリング]] / [[マイクロサービスアーキテクチャ]] / [[テレメトリ]] / [[オブザーバビリティ]] - 関連 MOC: [[SRE - MOC]] / [[AI Infra Telemetry - MOC]] ## 出典 - 本論文 §1(Introduction)、§2(Motivation・背景と3課題)、§3(Design: Overview・計装 API・イベント・モデル・データセット)、§4(Implementation: クライアント・パイプライン・スケーラビリティ・DSL・可視化)、§5(Evaluation: オーバーヘッド・負荷分散・モデル進化・ケーススタディ)、§6(経験)、§7(関連研究)、§8(結論)