Pyroscope 2.0：オブジェクトストレージ直書きで変わる継続プロファイリングの運用

Pyroscopeが解決するのは「定期的なプロファイリング」の手間

Pyroscopeは、アプリケーションのCPU、メモリ、I/Oを継続的に計測し、パフォーマンスのボトルネックを1行のコードまで特定するためのプラットフォームです。典型的な用途は、リソース消費の削減やレイテンシ対策といった予防的なものと、インシデント発生時にCPUやメモリのボトルネックを迅速にデバッグする反応的なものに分かれます。従来、プロファイリングは開発者が手動でプロファイラを起動し、短時間の計測結果を解析するのが一般的でした。Pyroscopeはこれを常時稼働させ、特定のサービスにドリルダウンできるようにします。対象は、Go、Java、Pythonなど、公式SDKが提供されている言語で書かれたアプリケーションを運用するバックエンド開発者やSREです。

v2アーキテクチャの核心は「インジェスター廃止」と「オブジェクトストレージ直書き」

Pyroscopeのv2アーキテクチャは、プロファイルデータの書き込み経路を根本的に変えました。v1ではインメモリのインジェスターがデータを一時保持し、ローカルディスクに書き出していましたが、v2ではプロファイルがサービスごとにルーティングされ、そのままオブジェクトストレージへ書き込まれます。これにより、インメモリのインジェスターとローカルディスクが不要になり、運用が単純化され、大規模な環境でのリソース消費が抑えられます。読み取り経路では、クエリがオブジェクトストレージに対してファンアウトし、Grafana Profiles Drilldownでフレームグラフを構築します。バックグラウンドではコンパクションワーカーが小さなセグメントを大きなブロックにマージします。つまり、書き込みはシンプルで、後処理は非同期に任せる設計です。

Quick Start：Dockerで手軽に試せるが、本番は構成を考える必要がある

READMEのQuick Startに従えば、ローカルでPyroscopeサーバーをすぐに起動できます。Dockerの場合は「docker run -it -p 4040:4040 grafana/pyroscope」、Homebrewなら「brew install pyroscope-io/brew/pyroscope」と「brew services start pyroscope」です。バイナリをダウンロードして「tar xvf pyroscope_*.tar.gz」で解凍し、「./pyroscope」を実行する方法もあります。デフォルトのポートは4040です。しかし、この手軽さはあくまで試用向けです。本番運用では、オブジェクトストレージの設定、コンパクションワーカーのスケーリング、Grafanaとの連携など、追加の構成が必要になります。KubernetesやHelmを使う場合は、公式のデプロイガイドを参照する必要があります。

データの送り方は3通り：SDK、Alloy、OTLP

プロファイルデータをサーバーへ送る方法は、大きく3つあります。1つ目は、Pyroscopeの言語SDKを使うプッシュ方式です。Go、Java、Pythonなど向けに公式SDKが提供されており、コードに組み込んでプロファイルを送信します。2つ目は、Grafana Alloyを使う方法で、プルまたはプッシュの両方に対応します。Alloyを使えば、アプリケーションを変更せずにプロファイルを収集できます。3つ目は、OpenTelemetry互換のソースからのOTLPです。たとえば、OpenTelemetry eBPFプロファイラがこれに該当します。このように、既存の計装基盤に合わせて選択肢が用意されている点は、導入の敷居を下げるでしょう。ただし、SDKごとに設定方法や対応言語のサポートレベルが異なるため、公式ドキュメントで確認する必要があります。

可視化はGrafana Profiles Drilldownに集約される

プロファイルの可視化は、Grafana Profiles Drilldown（旧Explore Profiles）が中心的な役割を担います。これはクエリを書かずにプロファイルを探索できるUIで、Grafana CloudやGrafana OSSではプリインストールされており、デフォルトの探索方法として使えます。データを送り始めれば、すぐにフレームグラフを確認できるというのは大きな利点です。ただし、Drilldownはあくまで可視化に特化しており、高度な分析やカスタムクエリが必要な場合は、別のGrafanaデータソースやAPIを使うことになるでしょう。この点は、単体のプロファイリングツールではなく、Grafanaエコシステムの一部として使うことを前提に設計されていると言えます。

v1からの移行はフラグで可能だが、データ移行の検証が必須

既存のv1デプロイを運用している場合、v2への移行はフラグを有効にすることで可能です。READMEには「既存のv1デプロイはフラグを介してオプトインし、データを失わずに移行できる」とあります。ただし、この移行には注意点があります。v2ではアーキテクチャが変わるため、移行ガイドを読み、テスト環境で十分に検証する必要があります。特に、オブジェクトストレージの設定や既存データの互換性は、移行前に確認すべき項目です。移行作業は、単純なアップグレードではなく、データの書き込み経路が変わることを理解した上で計画する必要があります。

ライセンスはAGPL-3.0、運用コストはオブジェクトストレージの管理に集中する

PyroscopeはAGPL-3.0でライセンスされています。これは、ネットワーク経由でサービスを提供する場合にソースコードの開示義務が生じる可能性があるコピーレフトライセンスです。自社の製品に組み込んで配布する場合や、SaaSとして提供する場合は、ライセンスの影響を慎重に評価する必要があります。運用コストの観点では、v2ではインメモリのインジェスターが不要になったため、サーバーのメモリ使用量は減るでしょう。一方で、オブジェクトストレージのコストと、コンパクションワーカーのバックグラウンド処理が新たな運用項目になります。オブジェクトストレージの選択肢やコストモデルは、導入時に見積もる必要があります。

代替手段との比較：常時計測か、必要時のみか

Pyroscopeの代替としては、従来のサンプリングプロファイラ（pprof、Java Flight Recorderなど）や、APMツールに組み込まれたプロファイリング機能が考えられます。これらのツールは、開発環境やインシデント発生時に手動でプロファイルを取得する用途に向いています。一方、Pyroscopeは常時計測を前提としており、本番環境で継続的にデータを収集して履歴を蓄積します。この違いは大きく、常時計測によってパフォーマンスの劣化を時間軸で追えるようになりますが、常時プロファイリングによるオーバーヘッドとデータ保存コストが発生します。また、Grafanaのダッシュボードやアラートと統合できる点は、APMツールのプロファイリング機能に近いですが、Pyroscopeはプロファイリングに特化している点で差別化されています。導入を検討する際は、常時計測の必要性とコストを天秤にかけることが重要です。

編集部の結論

Pyroscope 2.0は、プロファイリングデータの保存にインメモリのインジェスターを介さず、オブジェクトストレージへ直接書き込むことで、スケール時のリソース消費と運用の複雑さを抑えたいチームに向いています。一方、まだv1を運用中で、移行に伴うデータ移行やフラグ設定の検証が済んでいない場合は、v2への切り替えを急ぐ必要はありません。導入前に、使用するオブジェクトストレージの互換性、コンパクションワーカーのリソース要件、そしてAGPL-3.0のライセンスが自社の配布形態と整合するかを確認してください。具体的には、v2.0のリリースノートと移行ガイドを読み、既存のv1デプロイでフラグを有効にしてテスト環境で移行を試すことから始めるのが現実的です。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes