パフォーマンス調査の最初のステップは、経時的なリソース使用量における異常値の特定です。サービス product-recommendation について、以下の過去 1 時間の CPU 使用率のグラフをご覧ください。
これにより、正確な根本原因まではわかりませんが、CPU 使用率の異常ピークを見ることができます。
Show - Avg of ドロップダウン (前の画像でハイライト表示) を選択し、グラフを CPU Cores for Top Endpoints に変更します。このグラフでは、アプリケーションの異なる部分が全体の CPU 使用率にどのように寄与しているかが示されています。
黄色のピークは、GET /store_history エンドポイントにおいて、先ほど特定した異常値に対応するいくつかの断続的な使用が見られることを示しています。ただし、これらのピークは、そのエンドポイントへのトラフィックの違いが原因かもしれません。さらなる洞察を得るために、プロファイルがどれだけの情報を提供できるかを理解するため、メトリクスを CPU - Average Time Per Call for Top Endpoints に変更します。
GET /store_history が呼び出されるたびに CPU 使用率が上昇する原因を特定するため、スパイクが発生している時点での、このエンドポイントのプロファイリングフレームグラフを調べます。GET /store_history で CPU 使用率の上昇が見られる時間範囲を選択し、プロファイリングページのスコープをその時間範囲に設定します。次に、Flame Graph 表示に切り替えて、その時点で CPU を利用しているメソッドを確認します。
GET /store_history エンドポイントで CPU をより多く使用する理由をより良く理解するには、前の画像でハイライトされたテーブルを参照してください。該当のエンドポイントが、上から 2 番目に表示されています。その行を選択し、フレームグラフのフォーカスを GET /store_history エンドポイントによって引き起こされる CPU 使用率に合わせます。
ここで調査しているのはリクエスト 1 件あたりのリソース使用量なので、表の上にあるドロップダウンの値も CPU Time per Endpoint Call に変更します。これにより、1 分あたりの平均リソース使用量ではなく、そのエンドポイントに対する呼び出し 1 回当たりの平均リソース使用量が表示されます。
APM の Trace operation 属性を使えば、選択したエンドポイントのトレースと同じ細かさでフレームグラフの絞り込みとグループ化が可能です。これは、スレッドやメソッドの細かい粒度と、エンドポイント全体の大まかな粒度との間で、適切なバランスとなっています。オペレーションを分離するには、CPU time by ドロップダウンから Trace Operation を選択します。
前の画像では、ModelTraining オペレーションが GET /train エンドポイントでの主要な用途よりも多くの CPU 時間を使用していることが分かりますので、それが他のどこかで使われているはずです。それがどこで使用されているかを特定するため、オペレーション名をクリックしてください。この例では、ModelTraining は POST /update_model によっても使用されています。