目的
このチュートリアルを終了すると、次のことができるようになります。
- 外部サービス UI の使用方法を理解する
- API 呼び出しなどの遅い外部サービスを特定する
- トランザクションレベルのパフォーマンスのレビュー
外部サービスに注目する理由
外部サービス機能を使用すると、サービスのアップストリームおよびダウンストリーム アクティビティを観察できます。これらのアップストリームまたはダウンストリームの外部サービスは、インストルメント化した独自のサービス、またはサードパーティのサービスと API 呼び出しである可能性があります。これらの外部サービスの応答時間が遅いと、アプリが滞り、速度が低下します。
遅い外部サービスを特定する
遅い外部サービスを特定する方法を見てみましょう。
外部サービス UI に移動します 。one.newrelic.com > (アプリを選択) > Monitor > External services に移動します。左上の Show new view[新しいビューを表示] をまだ有効にしていない場合は切り替えてから、右上の Map[地図] をクリックします。
アプリケーションの依存関係 (アップストリームの依存関係とも呼ばれます) は、左側に一覧表示されます。右側には、ダウンストリーム サービスと呼ばれるアプリケーションに依存するサービスがあります。どのサービスが正常であるか、および各サービスのスループットと時間消費を確認できます。サービスを選択すると、そのサービスに関する詳細情報を表示できます。
アップストリームのすべての依存関係にカーソルを合わせ、応答時間またはトレース カウントが高いものを特定します。最近の履歴に大きなスパイクがあるものには特に注意してください。疑わしいサービスを見つけた場合は、そのサービスにカーソルを合わせ、 View traces[トレースの表示] ボタンを選択して、さらに掘り下げます。この新しいペインには、そのトランザクション トレースに関する情報が表示されます。この情報には、そのトランザクションの使用可能な関数呼び出し、データベース呼び出し、および外部呼び出しが記録されます。
このページの情報を活用する方法はいろいろありますので、ぜひ参考にしてみてください。ワークフローの例を次に示します。
マップ上で最も太くて暗い線を探し、それを上流または下流のサービスまでたどります。
上流または下流の頂点をクリックします。
2 つのサービス間のトランザクションの内訳を表示します。
この例では、太いエッジ（線）の1つが、Order-ComposerサービスからOrderStatusサービスのウェアハウスエンドポイントに移動します。
特定のトランザクションに最も時間がかかっていると判断した場合は、そのトランザクションをクリックして、特にその依存関係に注目します。
このドリルダウンビューでは、Order-ComposerサービスとOrder-Statusサービスのウェアハウスエンドポイント間のトランザクションを確認できます。
このフローのどの時点からでも、時間の経過に伴う変化を示すサポートパフォーマンスチャートを参照してください。
ドリルダウンで分散トレースを表示したい箇所に到達したら、右上のList [リスト]をクリックし、表内のTraces [トレース]をクリックします。
ヒント
上で使用したようなサービス マップは、システム内の複雑な関係を理解するのに役立ちます。インスツルメントしたサービスが多いほど、ロックを解除するシステムへのオブザーバビリティが向上します。サービス マップの詳細については、こちらをご覧ください。
前の手順のマップ ビューは、システムを視覚的に表示するのに最適ですが、問題のある外部サービスを特定するのに苦労している場合は、グラフや表でデータを提供するリスト ビューの方が役立つ場合があります。
最初に、右上の List[リスト] を選択してリスト ビューに移動します。このページには、低速な外部サービスを識別するために使用できるさまざまな表とグラフが表示されます。このページを使用して、サービスのトリアージを行います。
Response time[応答時間] グラフを見てください。これは、最も遅い 5 つの外部サービスを示しています。これらは最も遅いものですが、他のサービスと比べて遅いだけであることに注意してください.アプリを中断させるほど遅くない可能性があります。
Traced error countを見てください。大量のエラーがありますか?もしそうなら、彼らはどのサービスから来ていますか?
下部の表で、サービスを % changeで並べ替えます。これにより、最近呼び出された期間またはトレースがどれだけ変化したかによってランク付けされたサービスが表示されます。最近急激に伸びているサービスはありますか？
下部のテーブルでそのサービス名の横にある View traces[トレースを表示] を選択して、上記で特定されたサービスをさらに深く掘り下げます。この情報を使用して、これらのサービスを置き換えたり、API 呼び出しを最適化したり、サービス間で負荷を分散したりします
作品をチェック
問題の範囲を絞り込んだので、次は解決策を特定します。修正は問題に固有のものになりますが、いくつかの例を次に示します。
- 誤って API を 2 回呼び出していることに気付きました。重複した通話を削除して、合計応答時間を半分にします。
- 特定の API 呼び出しが毎日正午頃にスロットルを開始し、毎日その時間に API の無料制限に達していることに気付きます。別の API を探すか、アクセスをアップグレードしてください。
- 負荷が高いと、別の内部サービスが制限を超えてヒットし、応答時間が遅くなります。この負荷をより多くのサービスに分散するか、負荷を軽減または最適化する方法を見つけてください。
修正を開発にプッシュしてから、一般的な負荷テストを実行して、アプリが本番環境でどのように実行されるかを把握します。
外部サービスを監視するときは、チャートをよく見てください。
- 外部サービスの応答時間は許容範囲内ですか?これで完了です。
- 彼らは改善しましたか？学んだことを使用して、なぜ彼らが通常よりも改善したのかを理解してください.
- まだ応答時間が遅いですか？データベースに問題があるか、トランザクションの実行が遅い可能性があります。