分散システムの問題をサクッと解決する

# TL;DR
オブザーバビリティプラットフォームであるNew Relicは分散システムを効率的に管理・監視するための分散トレーシングをサポートしています。複雑な分散システムの下流で発生しているパフォーマンス遅延やエラーも自動的に収集して効率的に問題箇所を特定する方法をご紹介します。

:::note info
この機能に関する詳細はこちら
[New Relic アップデート(2023年7月)](https://newrelic.com/jp/blog/nerdlog/new-relic-update-202307 "New Relic アップデート(2023年7月)")
[New Relic アップデート一覧](https://newrelic.com/jp/blog/nerdlog/new-relic-update)
:::

:::note info
無料のアカウントで試してみよう！
[New Relic フリープランで始めるオブザーバビリティ！
](https://qiita.com/ktst79/items/5ee74b34e6adb8a7a6fa)
:::

# はじめに
「複数のシステムが連携する環境のトラブルシュートがもっと簡単にできないか」そんなことを考えたことないでしょうか？

レガシーなSORと連携して新たな付加価値を提供するように構築されたSOEや、マイクロサービスアーキテクチャを採用したモダンなシステムなど、システム間の連携パターンはシステムの数だけ存在しますが、いずれの場合でも複雑に絡み合うシステムで問題が発生した場合は、根本原因の追求や影響範囲の把握は骨が折れます。特に、複数チームが関係していたり、監視ツールがバラバラな場合はなおさらです。

分散システムにおけるシステム間の処理を追跡する方法としては分散トレーシングという方法があり、今やW3Cで標準的な規格にもなっています。加えて、オブザーバビリティプラットフォームであるNew Relicでは、New RelicのエージェントやOpenTelemetryで収集した分散トレースの情報を使って分散システムを一気通貫で効率的に分析することが可能です（以下イメージ図）。
![1. 分散トレース.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/535230/3faf8e03-87f3-2ada-94fd-16b5f6e41f26.png)


分散トレーシングは分散システムを分析するには非常に有効な手段ですが、連携するシステムが多い場合や、芋蔓式に多数のシステムが呼び出されている場合は、依然として根本原因の特定には難しさが残ります。トレース一つ一つに対して、どこのシステムでレスポンスが劣化しているか、もしくはエラーが発生しているかを関係性を辿って特定していく必要があるためです。

# 数ホップ先の問題を即座に特定

上記の問題に対し、New Relicは収集しているトレースデータを自動的に分析し、分散システムのどこで問題が発生しているかを提示してくれます。例えば、2ホップ先の下流のアプリケーションでエラーが発生していることや、3ホップ先の外部サービスでレスポンスが劣化していることなどを提示してくれます。これにより、いちいちトレースを一つ一つ辿って問題箇所を探す必要なく、システム全体のサービスレベル低下の原因となっている箇所をピンポイントで特定することが可能になります。


では、実際どのように見えるのかを確認してみましょう。

まず前提となる環境ですが、以下のように複数のシステム（6角形一つ一つがシステム）が関係しており、「Order-Processing」というシステムが「Order-Composer」というシステムを呼び出しており、さらに「Order-Composer」が「Delivery」を呼び出しています。そしてさらにその先で別のシステムが呼び出されています。
この場合、例えばDeliveryのシステムにレスポンス遅延が生じるとその影響でOrder-Processingに同じくレスポンス遅延が発生し、その先のユーザーに影響が出ます。
![2. Service Map.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/535230/a2dd3a68-3e38-1fd0-2af9-6c1f619631c0.png)


New Relic　APM（Application Performance Monitoring）エージェントを導入すると、システムのパフォーマンスデータをリアルタイムに収集して可視化します。例えばOrder-Composorのレスポンスタイムやエラー率などを確認することができます。仮にレスポンスタイムが劣化していたり、エラー率が上昇している場合はボトルネック箇所を特定することも可能です。
![3. APM.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/535230/8a5b2c36-c87a-e2b0-ce8b-a12f2494630d.png)


この時、関連するシステムが多い場合、レスポンスタイムの劣化やエラーレートの増加の原因がどこにあるのか把握する必要がありますが、New Relicでは下流のシステムにレスポンスタイムの劣化やエラー率の増加などの問題が発生していないか、自動的に検出してレポートしてくれます。添付画像では、レスポンス劣化が下流の3システムで発生しており、8システムでエラーが増加していることがわかります。
![4. DT insight.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/535230/dab8a6d3-2907-a227-092a-3371644c1bfb.png)



一番左のレスポンス劣化の部分についてクリックしてみると、すぐに詳細が確認できます。例えば、以下の画面では平均3.1ホップ先の下流のシステムの呼び出しのレスポンスタイムが3倍以上劣化しているということがわかります。
![5. Exclusive duration.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/535230/ca37f1f5-3472-e5da-528c-4bd3aafb1a55.png)


そして、そのまま詳細な分散トレースを開いてそのまま問題箇所をピンポイントで確認することが可能です。
![6. Trace.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/535230/81966984-3369-6215-ddd4-337f204f3d0c.png)


いかがでしょうか？いちいちトレースを辿らなくても関連する下流のシステムの問題箇所に即座に辿り着けることが理解いただけたかと思います。

# まとめ
今回は、複数のシステムが関連する複雑な分散システムでもNew Relicを活用して簡単に問題箇所が特定できることを解説しました。マイクロサービスアーキテクチャの台頭や、ビジネスニーズに応えるためのシステムの増加などでシステムはますます複雑化する中でより効率的な分散システムの管理方法を利用してみてはいかがでしょうか。


:::note info
最新のアップデートの詳細はこちら
[New Relic アップデート(2023年7月)](https://newrelic.com/jp/blog/nerdlog/new-relic-update-202307 "New Relic アップデート(2023年7月)")
[New Relic アップデート一覧](https://newrelic.com/jp/blog/nerdlog/new-relic-update)
:::

:::note info
無料のアカウントで試してみよう！
[New Relic フリープランで始めるオブザーバビリティ！
](https://qiita.com/ktst79/items/5ee74b34e6adb8a7a6fa)
:::

:::note info
[New Relic株式会社のQiita Organization](https://qiita.com/organizations/newrelic)では、
新機能を含む活用方法を公開していますので、ぜひフォローをお願いします。
:::