Pyroscope 2.0が登場：大規模環境でより高速かつ低コストな継続的プロファイリングを実現
継続的プロファイリング（Continuous Profiling）がオブザーバビリティスタックの標準になりつつあるのには、正当な理由があります。コードが単に「遅い」あるいは「リソースを消費している」という事実だけでなく、「なぜ」そうなっているのかを教えてくれる唯一のシグナルだからです。メトリクスはCPU使用率が高いことを教え、ログはリクエストが遅かったことを伝え、トレースはどのサービスがボトルネックかを示します。しかし、どの関数の、どの行がサイクルを浪費しているかを教えてくれるのは、プロファイルだけです。
システムが複雑になるにつれ、このレベルの可視性は不可欠なものとなります。OpenTelemetryがプロファイリングシグナルのアルファ版を発表したことは、プロファイリングが「最優先の監視指標（シグナル）」へと進化するための明確な一歩となりました。
そして今、私たちはオープンソースの継続的プロファイリング用データベースをゼロから再構築したPyroscope 2.0をリリースし、次の一歩を踏み出します。大規模環境でのコスト効率を追求して設計されており、OpenTelemetry Protocol（OTLP）プロファイリングをネイティブにサポートしているため、新しい標準規格を用いたプロファイルの取り込みを今すぐ開始できます。
常時プロファイリングを行うべき理由
Pyroscope 2.0の新機能に触れる前に、なぜ継続的プロファイリングが重要なのか、その価値についてお話しします。その見返りは、多くのチームが想像している以上に大きなものです。
推測ではなくデータに基づきインフラコストを削減
エンジニアリング予算においてクラウド支出は最大の項目の一つであり、その大部分をCPUとメモリが占めています。リソースを実際に「何が、どれだけ」消費しているかを詳しく把握できないため、多くのチームは余裕を持たせすぎた過剰なリソース確保（プロビジョニング）を常態化させています。
継続的プロファイリングはこの状況を変えます。本番環境のあらゆるサービスで、どの関数がCPUやメモリを消費しているかを時系列で正確に把握できれば、ハードウェアを増強して問題を解決するのではなく、的を絞った最適化が可能になります。
根本原因分析（RCA）の迅速化
インシデントが発生した際、最初の問いは常に「なぜ」です。メトリクスとトレースは影響範囲を絞り込み、どのサービス、どのエンドポイント、あるいはどのデプロイがデグレ（退行）を引き起こしたかを特定します。しかし、根本原因分析の「最後の1マイル」で、チームは何時間も浪費してしまいます。
継続的プロファイリングがあれば、その最後の1マイルは数分に短縮されます。デグレ前後のプロファイルを比較（diff）し、どのコードパスが変更されたかを正確に確認できるからです。ステージング環境での再現や、その場限りのログ追加、推測などは必要ありません。
コードレベルでレイテンシを理解する
分散トレーシングが「実時間（Wall clock time）」がどこで費やされたかを示すのに対し、プロファイリングは「CPUがその時間をどこで費やしたか」を教えます。この二つが組み合わさることで、オブザーバビリティのギャップが埋まります。例えば、トレースが認証サービスで200msの遅延が発生していることを示し、プロファイルがそのうち150msがキャッシュ可能な正規表現のコンパイルに費やされていることを示す、といった具合です。
これは、再現や診断が困難なp99（99パーセントタイル）のスパイクといった「テールレイテンシ」の解決に特に威力を発揮します。継続的プロファイリングはこれらの瞬間を発生と同時に捉えるため、デバッガーを当てる運に頼る必要がなくなります。
Pyroscope 2.0：新機能の詳細
初代Pyroscopeのアーキテクチャは、MimirやLokiプロジェクトと同じCortexを基盤としていました。それは機能こそしましたが、大規模な継続的プロファイリングを運用するにはコストが高く、運用負荷も大きいというオーバーヘッドを抱えていました。
その後、これら三つのプロジェクトはいずれもその基盤を脱却しました。Mimirは、書き込みパスのレプリケーションを排除し、読み取りと書き込みを分離し、オブジェクトストレージを唯一の信頼できる情報源（Single source of truth）とするアーキテクチャへと刷新されました。Pyroscope 2.0も同様の設計原則を適用し、プロファイリングデータ特有の性質（大きなペイロード、大量のシンボル情報、バースト的なクエリパターン）に合わせて最適化しました。その結果、劇的に安価で高速、かつ運用がシンプルなシステムが誕生しました。
コストを抑えた大規模プロファイリング
Pyroscope v1のアーキテクチャでは、書き込みパスですべてのプロファイルを3回複製（レプリケーション）していました。一つのプロファイルが数十メガバイトにもなるデータにおいて、この3倍の増幅はコストに直結します。Pyroscope 2.0では書き込みパスのレプリケーションを完全に排除したため、各プロファイルはオブジェクトストレージに一度だけ書き込まれます。
しかし、より大きな成果はデータの「コロケーション（近接配置）」です。同一サービスのプロファイルが近くに保存されるようになったことで、関数名、ソースの場所、スタックトレースといったシンボル情報（プロファイルサイズの60%以上を占めることが多いデータ）がデプロイ単位で重複排除され、最小限のオブジェクトに集約されます。私たちの本番環境では、これによりシンボル情報のストレージ使用量を最大95%削減できました。
ストレージや計算コストを理由に継続的プロファイリングを避けていたチームにとって、これらのアーキテクチャ変更は、大規模なプロファイリング運用を現実的なものにします。
ワークフローに即したクエリパフォーマンス
プロファイリングのクエリは、扱うデータ量の多さから本質的に高負荷です。各ポッドが継続的にスタックトレースのサンプルを送信するため、100個のポッドを12時間にわたってクエリする場合、数億個のサンプルをスキャンしてマージする必要があり、数百CPU秒の処理を要することもあります。
v1では、この処理が伸縮性のないステートフルなコンポーネント内で行われていたため、99%の時間はアイドル状態であっても、ピーク時のクエリ負荷に合わせてキャパシティを確保しておく必要がありました。
Pyroscope 2.0では、データ読み取りのプロセスを完全にステートレス化しました。クエリを実行するコンポーネント（Querier）が特定のデータに縛られないため、負荷に応じて柔軟に台数を増減できます。これにより、常に高いコストを払う必要はなく、実際に調査を行っている時だけ計算リソースを消費する効率的な運用が可能です。
プロファイリングのアクセスパターンはバースト的であるため、これは非常に重要です。ベースとなる負荷はほとんどありません。30秒ごとにダッシュボード上のプロファイルを監視し続ける人はいないからです。しかし、インシデントが発生すると、複数のエンジニアが同時に重いクエリを実行し始めます。また、自動調査の一環としてLLM搭載のエージェントが自律的にプロファイリングデータをクエリすることも増えており、トラフィックを押し上げています。ステートレスなクエリアにより、システムは平常時のアイドルコストを抑えつつ、こうした急激なスパイクをスマートに処理できるようになります。
運用の簡素化
ステートフルなコンポーネントが減ることは、故障リスクの低減と復旧の迅速化を意味します。v1で8〜12時間かかっていたロールアウトは、数分で完了するようになりました。セグメントライター（Segment writer）はディスクレスになり、ストアゲートウェイ（Store-gateway）は廃止されました。運用の対象範囲は大幅に縮小しています。
Pyroscopeを自前で運用するチームにとって、これは「専任の担当者が必要」な状態から「ただ動いている」状態への大きな変化です。
Grafana Cloudでの実証済み
Pyroscopeをエンジンとしたホスト型継続的プロファイリングツールであるGrafana Cloud Profilesでは、2025年4月から本番環境でPyroscope 2.0を稼働させています。9月までに全リージョンへの展開を完了し、これまでに19.5PBのプロファイリングデータを処理してきました。無駄なレプリケーション、読み書きパスの結合、遅いロールアウトといった私たちが解決しようとした課題は、数字として明確に解消されました。
Grafana Cloud Profilesをご利用の場合、移行はすでに完了しています。今回のリリースは、この本番環境で実証されたアーキテクチャをオープンソースコミュニティにお届けするものです。
新機能の基盤として
運用面の改善に加え、Pyroscope 2.0のクリーンなアーキテクチャは、v1では実現不可能だった以下のような機能も可能にします。
- プロファイルからのメトリクス生成：プロファイリングデータを集計し、フリート全体のメトリクスを生成します。個別のプロファイルを一つずつ調査しなくても、サービスやバージョン、デプロイ間でのリソース消費を簡単に比較できます。
- 個別プロファイルの検査：集計された統計データを見るだけでなく、特定のタイミングにおける単一のプロファイルインスタンスを詳細にドリルダウンして調査できます。
- ヒートマップクエリ：プロファイルの分布を時系列で可視化します。これにより、パフォーマンスの傾向や通常とは異なる挙動を示す外れ値を一目で特定できます。
多彩なクエリタイプの拡張：読み取りプロセスがステートレスになりデータモデルも整理されたことで、システム全体を改修することなく、新しい分析機能を柔軟に追加できるようになりました。
始め方
Pyroscope 2.0は現在利用可能です。v1からアップグレードする場合の主な変更点は、分散デプロイにおいてオブジェクトストレージが必須となることです。これは、すべてのプロファイルデータの「唯一の信頼できる情報源」となるためです。
ステップバイステップの移行手順については、Pyroscope 2.0 migration guideを参照してください。また、詳細はrelease notesでもご確認いただけます。
GrafanaCON 2026で発表されたすべてのニュースについては、GrafanaCON announcementsのブログ記事をご覧ください。