目的
このチュートリアルを終了すると、次のことができるようになります。
- 外部サービス UI の使用方法を理解する
- API 呼び出しなどの遅い外部サービスを特定する
- トランザクションレベルのパフォーマンスのレビュー

外部サービスに注目する理由
外部サービス機能を使用すると、サービスのアップストリームおよびダウンストリーム アクティビティを観察できます。これらのアップストリームまたはダウンストリームの外部サービスは、インストルメント化した独自のサービス、またはサードパーティのサービスと API 呼び出しである可能性があります。これらの外部サービスの応答時間が遅いと、アプリが滞り、速度が低下します。
遅い外部サービスを特定する
遅い外部サービスを特定する方法を見てみましょう。
外部サービス UI に移動します: one.newrelic.com > (select an app) > Monitor > External servicesに移動します。まだ有効になっていない場合は、左上のShow new viewを切り替えて、右上のMapをクリックします。
アプリケーションの依存関係 (アップストリームの依存関係とも呼ばれます) は、左側に一覧表示されます。右側には、ダウンストリーム サービスと呼ばれるアプリケーションに依存するサービスがあります。どのサービスが正常であるか、および各サービスのスループットと時間消費を確認できます。サービスを選択すると、そのサービスに関する詳細情報を表示できます。
すべての上流依存関係にマウスを移動し、応答タイムまたはトレース数が高いものを特定してください。 最近の履歴で大幅な上昇が見られるものには特に注意してください。疑わしいサービスを見つけた場合は、そのサービスにマウスを移動してView tracesボタンを選択し、さらに詳しく調べてください。この新しいペインには、その境界トレースに関する情報が表示され、その境界の利用可能な関数呼び出し、データベース呼び出し、および外部呼び出しが記録されます。
このページの情報を活用する方法はいろいろありますので、ぜひ参考にしてみてください。ワークフローの例を次に示します。
マップ上で最も太くて暗い線を探し、それを上流または下流のサービスまでたどります。
上流または下流の頂点をクリックします。
2 つのサービス間の取引の内訳を表示します。

この例では、太いエッジ (線) の 1 つが Order-Composer サービスから Order Status サービスの倉庫エンドポイントまで伸びています。
特定のトランザクションに最も時間がかかっていると判断した場合は、そのトランザクションをクリックして、その依存関係に特に焦点を当てます。

このドリルダウン ビューでは、Order-Composer サービスと Order-Status サービスの倉庫エンドポイント間のトランザクションを確認できます。
このフローのどの時点からでも、時間の経過に伴う変化を示すサポートパフォーマンスチャートを参照してください。
ドリルダウンでディストリビューティッド(分散)トレーシングを表示したい箇所に到達したら、右上のListをクリックし、表内のTracesをクリックします。

ヒント
上で使用したようなサービス マップは、システム内の複雑な関係を理解するのに役立ちます。インスツルメントしたサービスが多いほど、ロックを解除するシステムへのオブザーバビリティが向上します。サービス マップの詳細については、こちらをご覧ください。
前の手順のマップ ビューは、システムを視覚的に表示するのに最適ですが、問題のある外部サービスを特定するのに苦労している場合は、グラフや表でデータを提供するリスト ビューの方が役立つ場合があります。
まず、右上のListを選択してリスト ビューに移動します。このページには、低速な外部サービスを識別するために使用できるさまざまな表とグラフが表示されます。このページを使用して、サービスをトリアージします。
Response timeグラフをご覧ください。最も遅い 5 つの外部サービスが表示されます。これらは最も遅いサービスですが、他のサービスと比較すると遅いだけであることに注意してください。アプリの動作に支障をきたすほど遅くない可能性があります。
Traced error countをご覧ください。エラーは多量にありますか?もしそうなら、どのサービスから来ているのでしょうか?
下の表で、サービスを% changeで並べ替えます。ここには、サービスの継続時間または呼び出されたトレースが最近どの程度変化したかによってランク付けされたサービスが表示されます。最近急激に増加しているサービスはありますか?
下部の表でサービス名の横にあるView traces選択すると、上記で特定したサービスについてさらに詳しく調べることができます。この情報を使用して、これらのサービスを置き換えたり、 APIコールを最適化したり、サービス間で負荷を分散したりします。
作品をチェック
問題の範囲を絞り込んだので、次は解決策を特定します。修正は問題に固有のものになりますが、いくつかの例を次に示します。
- 誤って API を 2 回呼び出していることに気付きました。重複した通話を削除すると、合計応答時間が半分になります。
- 特定の API 呼び出しが毎日正午頃にスロットルを開始し、毎日その時間に API の無料制限に達していることに気付きます。別の API を探すか、アクセスをアップグレードしてください。
- 負荷が高いと、別の内部サービスが制限を超えてヒットし、応答時間が遅くなります。この負荷をより多くのサービスに分散するか、負荷を軽減または最適化する方法を見つけてください。
修正を開発にプッシュしてから、一般的な負荷テストを実行して、アプリが本番環境でどのように実行されるかを把握します。
外部サービスを監視するときは、チャートをよく見てください。
- 外部サービスの応答時間は許容範囲内ですか?これで完了です。
- 彼らは改善しましたか?学んだことを使用して、なぜ彼らが通常よりも改善したのかを理解してください.
- まだ応答時間が遅いですか?データベースに問題があるか、トランザクションの実行が遅い可能性があります。