GoogleのPerfettoとOpenTelemetryの比較レポート

GoogleのPerfettoとOpenTelemetryの比較レポート

本稿は、Googleの Perfetto と CNCF 主導の OpenTelemetry を「どちらが上か」ではなく、「何を観測したいときにどちらが効くか」という観点で比較するレポートです。結論を先に言えば、両者はかなり競合しているようでいて、実際には主戦場がずれています。Perfetto は単一マシンや端末上の詳細な実行トレース解析に強く、OpenTelemetry は分散システム全体のリクエスト流れや運用監視の標準化に強い、というのが基本線です。

結論の要約

  • Perfetto は、CPUスケジューリング、スレッド実行、アプリ内部イベント、システム挙動を高精細に追うためのトレース基盤です。
  • OpenTelemetry は、アプリケーションやサービスからトレース、メトリクス、ログを共通仕様で収集し、各種バックエンドへ送るための観測標準です。
  • したがって、両者は完全な代替関係ではありません。
  • 端末性能解析、Android/Chrome 系の低レベル可視化、時系列の因果追跡には Perfetto が向きます。
  • マイクロサービス、SaaS、クラウド運用、ベンダーニュートラルな計装には OpenTelemetry が向きます。

1. それぞれ何者か

Perfetto

Perfetto は、もともと Android や Chrome 系の性能解析文脈で発展してきたトレース基盤です。公式ドキュメントでも、Perfetto の tracing は「単一マシン上のソフトウェア挙動を理解するための tracing」であり、サーバー分散環境で言う distributed tracing とは文脈が違うと明記されています。ここがまず重要です。

Perfetto の強みは、OS・ランタイム・アプリのイベントを時系列で細かく記録し、あとから SQL で解析できる点です。単なる「遅い」ではなく、「どのスレッドが、どの瞬間に、何に待たされ、CPU・I/O・ロック・GC・描画のどこで詰まったか」を掘り下げる用途に向いています。

OpenTelemetry

OpenTelemetry は、トレース、メトリクス、ログを扱うオブザーバビリティ標準です。SDK、API、Collector、セマンティック規約を通じて、アプリケーションから観測データを一貫した形式で出し、Jaeger、Prometheus、Grafana、Datadog など多様な観測基盤へ送れる点が中核です。

OpenTelemetry の発想は「どの監視ベンダーを選ぶか」より前に、「まず計装を標準化する」ことにあります。特に分散トレーシングでは、複数サービスをまたぐリクエストの因果関係を trace と span で表現する考え方が中心になります。

2. 何が一番違うのか

最も大きい違いは、観測対象の粒度とスコープ です。

観点 Perfetto OpenTelemetry
主戦場 単一端末・単一マシンの性能解析 分散システム・サービス観測
得意な対象 CPU、スレッド、カーネルイベント、アプリ内詳細イベント リクエスト経路、サービス間依存、SLI/SLO監視
中心データ 高精細なタイムライン型トレース Span、Metric、Log
利用場面 Android、Chrome、ネイティブアプリ、性能ボトルネック調査 クラウド、マイクロサービス、API運用、可観測性基盤
典型的な問い 「この端末でなぜ 1 フレーム落ちたか」 「このAPI遅延はどのサービスで発生したか」

つまり Perfetto は「機械の中を開ける」道具であり、OpenTelemetry は「システム全体の流れを揃えて見る」道具です。両方とも tracing を扱いますが、同じ tracing という言葉でも見ている世界が違います。

3. Perfetto が強い場面

Perfetto が特に強いのは、現象の解像度を上げたいときです。

  • UI のカクつきやフレーム落ちの原因を追いたい
  • Android アプリの起動遅延を分解したい
  • Chrome 系ワークロードでスケジューリングやレンダリングを分析したい
  • CPU 使用率の高さを「どのスレッドのどの区間か」まで掘りたい
  • 収集後に SQL で自在に集計・相関分析したい

Perfetto は「重たいサービス監視のための共通計装」より、「原因究明のための精密な証拠保全」に寄っています。運用ダッシュボードの常時監視より、パフォーマンス調査や再現ケースの深掘りで真価を出しやすいです。

4. OpenTelemetry が強い場面

OpenTelemetry が強いのは、チームやシステムが大きくなる場面です。

  • 複数マイクロサービスをまたぐ遅延を追いたい
  • ベンダー依存を減らして計装を共通化したい
  • traces / metrics / logs を横断して運用したい
  • Collector を介して送信先や加工ルールを統一したい
  • ライブラリやフレームワークの自動計装を活用したい

OpenTelemetry は、個々のプロセス内部の極小イベントを全部見るよりも、「運用に必要な観測を組織横断で揃える」ことに向きます。したがって、SRE、Platform Engineering、クラウド基盤運用との相性が非常によいです。

5. 両者は競合するか

表面的にはどちらも trace を扱うため競合に見えますが、実務上は 部分競合・大半補完 という理解が近いです。

たとえば、OpenTelemetry で「checkout API が遅い」という事実を見つけ、その後で特定サービスや端末側の詳細調査に Perfetto を使う、という流れは自然です。逆に、Perfetto だけで分散サービス全体の依存関係や SLO 運用を担うのは無理がありますし、OpenTelemetry だけで端末ローカルのスケジューリング問題を Perfetto 並みの粒度で掘るのも難しいです。

この意味で、両者は「観測の階層」が違います。

  • Perfetto は低レイヤ寄り
  • OpenTelemetry はサービス運用寄り

6. 選び方の実務基準

次の基準で考えると迷いにくいです。

Perfetto を選ぶべきケース

  • 問題が単一端末・単一プロセス・単一マシン内に閉じている
  • 性能問題の原因をミリ秒未満の粒度で追いたい
  • Android / Chrome / ネイティブ実行環境の解析が中心
  • 監視よりも forensic な調査が目的

OpenTelemetry を選ぶべきケース

  • サービス間通信の遅延や失敗を見たい
  • 将来のバックエンド変更に備えて計装を標準化したい
  • traces / metrics / logs を同じ文脈で扱いたい
  • 組織全体の observability 基盤を整備したい

両方使うべきケース

  • クラウドサービスとクライアント性能の両方が問題になる
  • 「遅い場所」は OpenTelemetry で発見し、「遅い理由」は Perfetto で深掘る
  • モバイル/エッジ/ブラウザとサーバーが一体で体験品質を決める

7. 乱暴に一言でまとめると

Perfetto は 高倍率の顕微鏡、OpenTelemetry は 広域の管制レーダー です。

顕微鏡だけでは全体の交通は見えません。レーダーだけでは局所の故障原因は見えません。したがって、どちらが優れているかという問いより、「いま解きたい問題は局所原因の解剖か、全体運用の可視化か」を先に決めるほうが正確です。

参考リンク

補記

Perfetto は Google 発で強力なトレース解析基盤ですが、OpenTelemetry の代替標準ではありません。同様に、OpenTelemetry は観測標準として強い一方で、Perfetto が得意とする低レベル性能解析をそのまま置き換えるものでもありません。両者を比較するときは、製品比較というより「観測レイヤの違い」を見抜けるかどうかが重要です。

作成日: 2026-03-27
著者AIモデル: GPT-5 Codex