.confで発表した継続的コードプロファイリング機能のプレビュー提供の続報として、先日、Splunk APMのAlwaysOn Profilingの一般提供が開始されたことをお知らせいたします。このJavaアプリケーション向けの新機能はAPMの一部として無料でご利用いただけます。この記事では、新機能の概要と使い方について説明します。
コードプロファイリングを実行すれば、ランタイム環境からCPUのスナップショットやコールスタックを定期的に収集することにより、アプリケーション開発者やサービスオーナーはサービスのボトルネックを特定できます。コールスタックの情報は、トランザクショントレースで処理が遅いスパンを調査するための追加コンテキストとして使用でき、サービスの特定期間のパフォーマンスを示すフレームグラフでボトルネックを可視化するめにも役立ちます。コードプロファイリングのメリットは明らかですが、多くのコードプロファイリングツールはパフォーマンスへの負荷が大きいため、アプリケーションパフォーマンスの維持とデータ収集のどちらを優先するかを判断した上で、エンジニアが手動でオン/オフを切り替える必要があります。
SplunkのAlwaysOn Profilingは、コードレベルのパフォーマンスを、サンプリングなしのトレースデータと関連付け、最小限の負荷で継続的に可視化します。Splunk Synthetic Monitoring、Splunk RUM、Splunk Infrastructure Monitoring、Splunk Log Observer、Splunk On-Callとともに、AlwaysOn Profilingは、本番環境のパフォーマンスの問題に関するコンテキストを提供し、問題の特定とトラブルシューティングを迅速化します。
AlwaysOn Profilingでコードのボトルネックを調査
Splunk APMのAlwaysOn Profilerは、コードのパフォーマンスを継続的に監視して、パフォーマンスのボトルネックが発生している場所即座に把握できるようにします。2つのワークフローを例にAlwaysOnで本番環境の問題を特定する方法をご紹介します。
ワークフロー1：処理が遅いトレースに共通のコードを確認する
本番環境の問題をトラブルシューティングする場合、サンプルトレースを調査して、処理が遅いスパンに共通する属性を探すことがよくあります。AlwaysOnのコールスタックはトレースデータと関連付けられるため、各トレースでコードが実行されたときのコンテキストをすばやく確認できます。
APMでは、本番環境での処理の遅延を簡単に確認できます。
調査したいサービスをクリックすると、サービスマップが表示されます。ここで、サービスとその依存サービスでのボトルネックに関する追加のコンテキストを確認できます。
ここから、サンプルトレースを調査できます。
注：ここでは、処理が特に遅いトレースを抽出するため、最小10,000ミリ秒(10秒)でフィルタリングしています。その結果、「/stats/races/fastest」へのリクエストの多くが応答に40秒前後かかっていることがわかります。
処理の遅いトレースのいずれかをクリックすると、次の画面が表示されます。
ここを見ると、StatsController.fastestRace処理の実行中に21件のコールスタックが収集されています。Javaエージェントはコールスタックを継続的に収集しているので、スパンが長くなるほど、収集されるコールスタックも増えます。このスパンを開くと、左側にメタデータが表示され、右側にエージェントが収集したコールスタックが表示されます。[Previous] (前へ)ボタンと[Next] (次へ)ボタンを使って、前後のコールスタックに移動できます。
複数のコールスタックが連続して同じコード行を指している場合、その行の実行に時間がかかっているか、その行が何度も繰り返し実行されていることを示します。これは通常、パフォーマンスのボトルネックを判断するための重要なヒントになります。
ワークフロー2：サービスの特定期間の集計を確認する
コードの最適化を始める前に、ソースコードのどの部分がパフォーマンスに最も影響するかを把握しておくと役立ちます。収集したコールスタックを集計したフレームグラフを使えば、最大のボトルネックになる部分をすばやく特定できます。
サービスマップを表示すると、右側のサイドパネルにAlwaysOn Profilingが追加されているのがわかります。ここには、指定の時間範囲に収集されたコールスタックの中でトップ5のフレームが自動的に表示されます。ここを見るだけで、コード内のボトルネックを絞り込むことができます。
このパネルをクリックすると、指定の時間範囲に収集されたコールスタックの集計を視覚的に表したフレームグラフが表示されます。特定期間にわたるコールスタックの状態が視覚化されるため、横棒の幅が広いほど、収集されたコールスタック内でそのコード行が頻繁に検出されていることを示します。
フレームグラフでは、幅の大きい縦のラインに注目します。これらは、CPU使用率が高いコード行を示します。フレームグラフで独自のコードクラスを強調表示したい場合は、左上のフィルターを使用します。
フレームグラフの各横棒には、コードのクラス名と行番号が表示されます。フレームグラフで処理の遅延の原因となっているボトルネックを確認したら、ソースコードを開いて問題を修正します。
Splunkのオブザーバビリティソリューションでコードプロファイルを実行
コードプロファイリング専用ツールとは異なり、SplunkのAlwaysOn Profilerでは、収集されたコールスタックが、収集時に実行されていたスパンと関連付けられます。これにより、バックグラウンドのスレッドに関するデータと、受信したリクエストを処理するアクティブなスレッドのデータを切り分けて、プロファイリングデータの分析にかかる時間を大幅に短縮できます。
さらに、データ収集はすべて自動で行われ、負荷は最小限に抑えられます。本番環境のインシデント発生時に手動でオンに切り替える必要もなく、Splunkの専用OpenTelemetryエージェントを導入すればデータの継続的な収集がバックグラウンドで開始されます。
ぜひお試しください
Splunk APMを現在使用していて、JavaサービスでAlwaysOn Profilingを有効にするには、以下の手順に従います。
- Splunk OpenTelemetry Javaインストルメンテーションエージェントのバージョン1.4.0以降を使用していることを確認します。
- OpenTelemetry Collectorのバージョン0.34以降を使用していることを確認します。
- エージェントでプロファイリングを有効にし、プロファイリングデータをCollectorに転送するように設定してから、Collectorでプロファイリングパイプラインを設定します。
詳しい使い方については、AlwaysOn Profilingのマニュアルを参照してください。
Splunk APMをお使いでない場合は、トライアル版をお試しいただけます。
このブログはこちらの英語ブログの翻訳です。
