ThousandEyes と AppDynamics

AppDynamics との統合に関するビデオチュートリアルの字幕

AppDynamics のソリューションアーキテクト、Konr Ness です。このデモでは AppDynamics と ThousandEyes の統合を取り上げます。新たなネイティブ統合によって、どのようにして可視性をエンドツーエンドに広げ、それを分散型クラウドアプリケーションで実現しているのかをご紹介します。

このダッシュボードは収益源となるビジネスクリティカルなサービス、具体的には保険契約書やお客様からの決済を扱うようなサービスに適しています。

ダッシュボードは豊富な情報源です。決済中のコンテキストやエンドユーザーの体感品質だけでなく、サードパーティの API のパフォーマンスや、シスコのアプリケーションが決済情報を取得するために利用しているサービスの重要な依存関係などの情報を得られます。

ここで、ダッシュボード上に気にかかる情報が表示されています。

黄色の表示は決済完了額が通常の基準を下回っていることを表します。

実際、今日はその時間までに決済がすっかり停止してしまっています。

収益の低下に合わせて、「課金」ビジネストランザクションの応答時間が上昇しているのがわかります。

このアプリケーションの動作状況を確認し、何が起きているのかを診断してみましょう。

こちらは「課金」ビジネストランザクションのフローマップです。

先ほどダッシュボードで見たのと同じもので、応答時間は上昇していますが収益は低下しています。

このビジネストランザクションは、Web 階層やコアサービス、決済サービスなどの複数のマイクロサービスによってサポートされています。

バックエンドのマイクロサービスによってトランザクションが正常に行われている背後には、決済処理を担う外部の API も関わっています。この灰色のクラウドの部分がその API です。

さて、応答時間が突然跳ね上がっているのがわかるかと思います。

これはお客様が利用サービスで決済を確定したときの動きです。

もし決済ができなければ、たくさんのお客様を不快にしてしまい、コールセンターへの入電が急増することになります。

スナップショットの動きの鈍いところを詳しく見てみると、そこで何が起きているのかがはっきりとわかります。

この外部 Web サービスの呼び出しに通常よりも時間がかかっていて、リモート呼び出しのタイムアウトが発生して決済サービスが異常終了しています。その結果、上流のコアサービスはまったく機能していません。

[ドリルダウン（Drill Down）] をクリックすると、正常に応答しなかった HTTP リクエストの詳細を確認できます。詳細にはリクエストを実行したコードの呼び出しグラフも含まれます。

決済処理システムに対するこの外部 Web サービスの呼び出しがタイムアウトし、処理されないまま決済が終了する事象が起きています。

このような事態が起きたときに理解しておくべき最も大事な点は、問題が生じている領域を切り分けることです。

問題があるのは自社のアプリケーションなのか、ネットワークなのか、パブリックインターネットなのか。それとも外部のサービスプロバイダー、このケースでは自社の決済ゲートウェイの問題なのか。

このスナップショットの情報から、自社のアプリケーションやコードが遅延の原因でないことはすでにわかっています。

自社アプリケーションではない外部のどこかに原因があるのです。

この時点でアプリケーション担当チームへの疑いは晴れ、ネットワーク担当チームが責められるという光景をよく見かけますが、こうして問題解決までに一進一退を繰り返すことで無益な責任のなすりつけ合いが起き、貴重な時間を無駄にするばかりでなく、エンドユーザー体験にも影響をもたらします。

ですが、ここで決済ゲートウェイへの接続に影響を与えている外部環境を特定できるとしたらどうでしょうか。ダッシュボードに戻れば、AppDynamics と ThousandEyes による可視性のおかげで何が根本原因なのかという問いに即座に答えることができます。

ご存じない方のために説明すると、ThousandEyes はインターネットとクラウドインテリジェンスのためのプラットフォームで、インターネットや外部の環境がアプリケーションのパフォーマンスに与える影響を可視化できます。

当社のアプリケーション環境で稼働している ThousandEyes Enterprise Agent のおかげで、可視性をアプリ環境の外にまで広げ、外部の Web サービスリクエストがパブリックインターネットを行き交う様子を把握することができます。

実際にこのアプリケーションの視点から見たグラフでは、バックエンドの応答時間と、データセンターからトランザクションが送信されるときのネットワークの遅延との間に相関関係があることが視覚的に表されています。

予想通り、収益の急降下と決済処理の不具合が起こり始めるのと同時に、ネットワークの遅延が増加していることが ThousandEyes で確認できます。

ここで、問題がネットワークにあり、サードパーティのサービスで遅延が起きているわけではないことが確かめられました。

AppDynamics と ThousandEyes の統合によって一元的な可視化と業務上の言語の共通化がなされ、トラブルシューティングの場面でも AppOps チームから NetOps チームへの引き継ぎがスムーズになります。

決済ゲートウェイでネットワークの遅延が増加していることはわかりました。ですが実際の原因は何でしょうか。

それではダッシュボードから ThousandEyes のテスト画面に移動し、診断を続けましょう。

ThousandEyes で HTTP サーバーのテストを行い、バックエンドの決済サービスやアプリケーションが利用しているのと同じ URL にリクエストを送信します。

5 つの監視ポイントから決済 API をテストします。そのうちの 4 つは世界各地にある、ThousandEyes がホストしている Cloud Agents です。

残りの 1 つはシスコのアプリケーション環境で稼働している Enterprise Agent です。これで、私たちの環境から外部のサービスエンドポイントに向けたトランザクションが、パブリックインターネットでどのように伝送されるかを把握できます。

このネットワーク概要のタブを見ると、重要な発見があります。

ネットワークの遅延の増加は、実はいくつかの場所で発生していて、そのほとんどは米国で起きている事象なのです。しかしその影響はアプリケーション環境に最も顕著に現れています。

こうした情報は、この問題を、データセンターネットワークや上流の ISP で起きている事象から、決済プロバイダーのインターネットのパス上で起きている事象に絞り込むための判断材料となります。

決済プロバイダーとの接続はインターネット上でどのような経路を取っているのでしょうか。

それを理解するためにパスの可視化を見てみましょう。

まずは確認する期間を問題発生前に変更し、そこで何が起きたのかを把握します。

私たちのアプリケーションは太平洋北西リージョンのデータセンターで稼働しています。パスの可視化によって、パブリックインターネット上で接続がどのような経路を取るのかがわかります。左側は Enterprise Agent で、

右側は接続先である決済処理者の API のフロントドアです。それらの中間にあるそれぞれの線および円は、トラフィックが接続先に到達するために通過するインターネット上のパスを可視化したものです。

問題が発生する前、リクエストは米国のアッシュバーンでホストされている決済処理者の拠点（Amazon 米国東部リージョン）を通過しています。

他の Cloud Agents、たとえば日本や英国のエージェントは、シンガポールにある決済処理者の拠点にルーティングされています。

これは典型的な GeoDNS の実装に見られる挙動です。

DNS はリクエスト相手の物理的な位置に応じて、サービスの IP アドレスを最も遅延の少ないものに変更したうえで返します。

ここまでは問題ありませんが、遅延が急激に増加した場合に何が起きるかを見てみましょう。

少しお待ちください。

私たちのアプリケーションから送信された API リクエストが、はるばるシンガポールまでルーティングされているようです。

目的の GeoDNS との間で輻輳が起きます。

シンガポールにあるサービスエンドポイントが米国から送られてきたリクエストに応えるのはなぜでしょうか。

明らかに何かがおかしいと思えますが、ネットワークの遅延が急増し、アプリケーションがタイムアウトしてしまう根本原因は、こうした動きによって説明できます。

ThousandEyes の独自のビューには、アプリケーションとネットワークそれぞれのチームが問題を把握するために必要なすべての情報が集められています。

このように一元的に可視化されたビューがあれば、総力で調査に臨むようなリソースの集中を防ぐことができます。

ここではそうせずに ShareLink を作成します。これは ThousandEyes のデータを常時利用できる双方向のビューです。

この ShareLink を、問題を説明するすべての周辺情報と一緒に、決済ベンダーと協力して問題の解決にあたる決済チームに送ります。

AppDynamics のダッシュボードでどのようにしてアプリケーションとネットワークの周辺情報を 1 つのビューにまとめて設定するのかをお見せします。

この独自のビューは、今日ご紹介する AppDynamics と ThousandEyes との新たな統合によって実現したものです。

ThousandEyes の資格情報を AppDynamics に追加するだけで、ThousandEyes の指標をこのダッシュボード上に表示できます。

資格情報の追加が終わると、ウィジェットに表示するデータを選択する際に AppDynamics のデータ（アプリケーションやエンドユーザーモニタリング、データベース、サーバーなど）にアクセスできるだけでなく、ThousandEyes のデータソースも使用できるようになります。

気になる指標や情報を取得するテストを選択すると、複雑なデータ統合の設定をすることなく、ただちにそのデータがプロットされます。

そのため利用しているアプリケーションに ThousandEyes のネットワークやインターネットの周辺情報を追加して、アプリケーションのエンドツーエンドの可視性を拡張することも簡単にできます。

AppDynamics と ThousandEyes を利用するメリットをまとめると、アプリケーションとネットワークの両方をリアルタイムに、相関関係まで把握できる包括的な可視性を実現でき、その情報を活用して顧客体験に影響を及ぼすインシデントに早急に対処し、解決を図れるということです。

ご視聴いただきありがとうございました。