【NIC x Ops（にこぷす）通信】（Instana編）障害発生！「遅延」の原因はどこ？Instanaでスマートに特定してみた

皆さま、こんにちは！
このテックブログでは、IT運用に関する内容を連載、「にこぷす通信」をお届けしています。

1．はじめに：今回のテーマ

みなさま、改めましてこんにちは！IBM Instana担当の高巣です。

第1回では、Linux未経験の私がAWS環境にInstanaエージェントを導入し、サーバーの状態をInstana上で確認するまでをお届けしました。
第2回では、Instanaの画面を見ながら、以下の3つの特長をご紹介しました。
　・サービス品質とユーザー体験をリアルタイムに把握できること
　・システムの依存関係やアプリケーション内部の処理を可視化できること
　・運用・開発・事業部門の情報共有をスムーズにできること

そして第3回となる今回は、いよいよ実践編です！
第1回で構築したAWS環境に、Web・App・DBの3層構成のデモECサイトを用意しました。実際にアプリケーションを動かすと、Instanaはどこまで自動で見つけてくれるのでしょうか？
さらに今回は、ECサイトの注文処理に意図的な遅延を発生させてみました。
ユーザーから見れば、単に「注文処理が遅い」という現象です。しかし、その原因が外部の決済サービスなのか、データベースなのかによって、対応すべき担当者や調査方法は大きく変わります。

そこで今回は、以下のポイントを検証しました！
　・アプリケーションを導入すると、依存関係マップは自動生成されるのか
　・ECサイトの操作をInstanaでどのように確認できるのか
　・「注文処理が遅い」原因を、Instanaの分散トレースで特定できるのか
　・Smart Alertsで遅延を自動検知・通知できるのか

2．今回検証したECサイトの構成

今回用意したデモ環境は、AWS上に構築したWeb／App／DBの3層構成のECサイトです。

サーバー	主な役割	主なコンポーネント
Webサーバー	ユーザーからのアクセスを最初に受け付ける窓口	Apache HTTPd、Instana Agent
Appサーバー	商品表示、ログイン、カート、注文処理などのビジネスロジックを実行	Javaアプリケーション、Tomcat、Redis、Instana Agent
DBサーバー	商品情報、ユーザー情報、注文情報などを保存	PostgreSQL、Instana Agent

ユーザーがECサイトを操作すると、リクエストはまずWebサーバーで受け付けられ、その後Appサーバーへ転送されます。Appサーバーではログイン時のセッション管理にRedis／Valkeyを利用し、DBサーバーでは商品情報や注文情報の参照・更新にPostgreSQLを利用します。

今回用意したデモ環境の概要は、以下のとおりです。

図：今回の検証環境。AWS上のWeb／App／DBの3台のEC2にそれぞれInstana Agentを導入し、収集した監視データをInstana Backend（SaaS）へ送信します。

従来の監視では、Webサーバー・Appサーバー・DBサーバーごとに収集・管理している情報が分断されているため、障害発生時には担当者がそれぞれの監視ツールやログを個別に確認し、情報を繋ぎ合わせる必要がありました。

しかしInstanaでは、各サーバーにInstana Agentを導入するだけで、OSやプロセスはもちろん、Apache HTTPd、Javaアプリケーション、Redis/Valkey、PostgreSQLといったミドルウェアやアプリケーションの存在まで一元的に自動検出します。

3．Instana Agentを入れるだけで依存関係マップは本当にできる？

第2回でご紹介したInstanaの特長のひとつに、「依存関係の自動マッピング」がありました。
今回は、実際にデモECサイトを動かしてみて、Instanaがどのようにアプリケーションやデータベースのつながりを可視化してくれるのかを確認しました。
Instanaの［アプリケーション］画面で対象アプリケーションを開き、［依存関係］タブを選択すると、以下のようなマップが表示されます。

図：Instanaが自動生成したECサイトの依存関係マップ。

今回のデモECサイトでは、order、cart、product、review、user といったサービスと、PostgreSQL@5432 が表示されました。各サービスとPostgreSQLが線で結ばれ、互いに連携して動作している関係性（通信の繋がり）が自動的に可視化されています。

なお、マップ上に表示されている各サービスの役割は以下の通りです。

• order：注文処理を担当するサービス
• cart：カート情報を扱うサービス
• product：商品情報を扱うサービス
• review：レビュー情報を扱うサービス
• user：ユーザー情報やログイン処理を扱うサービス
• PostgreSQL@5432：各サービスが利用するデータベース

このように、Instanaではアプリケーションコードの中身を一つひとつ手作業で調べたり、構成図を管理し続けたりしなくても、サービス同士やデータベースとの依存関係を自動で可視化できます。

手作業でアプリケーション構成図を作成し、サービス間の接続関係を管理し続ける必要がない点は、構成変更が多いシステムやマイクロサービス型のシステムでは特に大きなメリットだと感じました。

ホスト内で動作するコンポーネントも自動検出

依存関係マップでは、サービスとデータベースのつながりを確認できます。

さらに、Instanaの［インフラストラクチャー］画面では、Web／App／DBの各ホスト内で動作しているコンポーネントも自動的に検出されていました。

図：Instanaのインフラストラクチャー画面。各ホスト上で稼働しているコンポーネントも自動検出されます。

今回の環境で検出された主なコンポーネントは、以下のとおりです。

特別な構成図を手作業で作成したわけではありません。各ホストにInstana Agentを導入し、アプリケーションを動かすことで、Instanaが稼働中のソフトウェアやサービス間の通信関係を自動的に見つけてくれました。

このようにInstanaでは、依存関係マップで「アプリケーションやDBがどうつながっているか」を確認できるだけでなく、インフラストラクチャー画面で「各サーバーの中で何が動いているか」も確認できます。

サービスのつながりと、サーバー内部の構成を同じInstana上で確認できることが、障害発生時の調査をスムーズに進めるうえで大きな強みだと感じました。

特に、実際の業務システムでは、サーバーやアプリケーションが増えるほど構成管理は大変になります。そんなときに、Instanaが最新の構成を自動的に可視化してくれることは、障害対応時だけでなく、日々の運用においても大きな助けになりそうです。

4.　「注文処理が遅い」原因を分散トレースで追跡してみた

続いて、実際にデモECサイトを操作してみました。

ECサイトの画面から、以下の操作を行います。

商品一覧を表示する
ログインする
商品をカートへ追加する
クレジットカード決済を行う

操作後、Instanaの［アプリケーション］画面から対象アプリケーションを開くと、呼び出し数、エラー率、待ち時間などを確認できます。

さらに、［呼び出し分析］を開くと、実行されたリクエストを1件ずつ確認できます。呼び出し名をクリックすると、そのリクエストがWebサーバー、Appサーバー、DBサーバーをどのように通過したのか、また各サーバー内でどの処理に時間がかかったのかが、タイムライン形式で表示されます。

例えば、Appサーバー上のJavaアプリケーションやRedis／Valkey、DBサーバー上のPostgreSQLに対する処理時間まで確認できます。

これがInstanaの「分散トレース」です。

分散トレースを一言でいうと、1回のユーザー操作が、裏側のどこで、どれくらい時間を使ったのかを追跡できる機能です。

今回のデモECサイトでは、実際のクレジットカード会社との決済連携の代わりに、環境内で動作するダミーの決済サービスを利用しています。

今回は、商品購入時の注文処理が約30秒かかる疑似障害を2パターン発生させました。

利用者から見える現象は、どちらのケースも同じです。

「注文ボタンを押した後、処理がなかなか完了しない」

しかし、同じ「注文処理が遅い」という現象でも、原因が外部サービスにあるのか、データベースにあるのかによって、調査対象や対応すべき担当チームは変わります。

そこで今回は、Instanaのトレースを使って、実際にどこが遅延原因となっているのかを確認しました。

障害パターン①：注文処理の遅延原因を調べると、ダミー決済サービスにたどり着いた

最初の検証では、商品購入時に注文処理が約30秒かかる疑似障害を発生させました。

まず、Instanaのトレース一覧画面を確認すると、通常よりも大幅に時間がかかっている/orders/checkoutの呼び出しを見つけることができました。

次に、該当する呼び出しをクリックしてトレース詳細を確認します。

ウォーターフォール表示を見ると、注文処理全体が約30秒かかっている中で、ダミー決済サービスのPOST /payments/charge呼び出しに、待ち時間の大部分が集中していることが分かりました。

この結果から、注文処理全体の待ち時間の大部分は、Webサーバー上で動作しているダミー決済サービスに対するPOST /payments/charge呼び出しで発生していることが分かりました。

Instanaのトレースにより、Webサーバー上のダミー決済サービスの応答遅延が、注文処理全体を遅くしている原因だと特定できました。

利用者からは単に「注文処理が遅い」としか見えません。しかしInstanaを使うことで、注文処理のどの部分に時間がかかっているかを確認し、調査対象をダミー決済サービスまで絞り込めました。

障害パターン②：同じ注文処理の遅延でも、原因はPostgreSQLだった

次の検証でも、同じく商品購入時の注文処理が約30秒かかる状態を発生させました。

今回もまず、Instanaのトレース一覧画面から、約30秒かかっている/orders/checkoutの呼び出しを確認しました。

次にトレース詳細を確認すると、先ほどのダミー決済サービス遅延とは異なる結果が表示されました。

今回、待ち時間の大部分を占めていたのは、AppサーバーからDBサーバー上のPostgreSQLへ接続するJDBC呼び出しでした。

さらに詳細を見ると、PostgreSQLで実行されたSQLも確認できます。今回は、SELECT pg_sleep(…)が実行されており、Appサーバー上のアプリケーションが、DBサーバー上のPostgreSQLからの応答を約30秒待っていたことが分かりました。

この結果から、今回の注文処理遅延は、決済サービスではなく、DBサーバー上のPostgreSQLの応答遅延が原因だと特定できました。

同じ「注文処理が遅い」でも、原因は異なる

今回の2つの検証では、利用者から見える事象はいずれも「商品購入時の注文処理が約30秒かかる」という同じものでした。

しかし、Instanaで遅延しているリクエストのトレースを確認すると、待ち時間が発生している場所はそれぞれ異なっていました。

1つ目は外部決済サービス、2つ目はPostgreSQLの処理に時間がかかっていることを確認できました。

	利用者から見た事象	Instanaで確認した遅延箇所	特定できた原因
障害パターン①	注文処理が約30秒かかる	ダミー決済サービスのPOST /payments/charge に約30秒かかっている	ダミー決済サービスの応答遅延
障害パターン②	注文処理が約30秒かかる	AppサーバーからDBサーバー上のPostgreSQLへのJDBC呼び出し、SQL処理（SELECT pg_sleep）に約30秒かかっている	DBサーバー上のPostgreSQLの応答遅延

このようにInstanaでは、「注文処理が遅い」という利用者視点の事象から、どのサービス・どの処理に時間がかかっているのかを追跡できます。

単に「遅い」という事実を把握するだけでなく、「決済サービスに原因があるのか」「データベースに原因があるのか」まで根拠を持って切り分けられることが、Observabilityの大きな価値だと実感しました。

5.　Smart Alertsで遅延を自動検知してみた

ここまでの検証では、Instanaの画面を開いてトレースを確認することで、遅延の原因を特定できました。
しかし実際の運用では、担当者が常に監視画面を見続けることはできません。
そこで活用できるのが、InstanaのSmart Alerts（スマート・アラート）です。

Smart Alertsとは、アプリケーションのエラー率や待ち時間、HTTPステータスコード、インフラのリソース使用率などを条件として、異常を検知・通知する機能です。

今回のような注文処理の遅延に対しては、例えば以下のような条件を設定できます。

• 対象：注文処理 /orders/checkout
• 監視項目：待ち時間（レイテンシー）
• 条件：待ち時間が5秒を超えた場合
• 評価期間：1分
• 通知先：運用に応じてメールやチャットツールなどを設定

従来の監視では「レスポンスが3秒を超えたら通知する」といった固定のしきい値を、人が一つひとつ設定することが一般的でした。

InstanaのSmart Alertsでは、「遅延コール（Slow Calls）」「エラーコール（Erroneous Calls）」などのブループリントを利用して、監視条件を作成できます。また、通常時の動きを基準に異常を検知するアダプティブしきい値を利用することも可能です。

そのため、ゼロから複雑な監視条件を考えなくても、目的に応じた監視を始めやすい点が便利だと感じました。

Instanaでは、遅延コール、エラーコール、HTTPステータスコードなど、用途に応じたブループリントが用意されています。ゼロから複雑な監視条件を考えなくても、必要なアラートを比較的簡単に作成できる点も便利だと感じました。実運用の要件に合わせて柔軟に設定できるのも素晴らしいポイントですね。

【検証の裏話】なぜ最初はアラートが鳴らなかったのか？

実は検証中、わざと30秒の遅延を起こしたのにアラートが鳴らない！と焦る一幕がありました。
原因は、待ち時間の評価基準が「90th（P90：90パーセンタイル）」になっていたためです。

90thとは、全リクエストのうち「90％がこの時間以内に完了した」という基準を見る指標です。通常の高速な通信が多く、私がテストで1回だけ決済遅延を起こした場合、その遅延は全体の傾向に大きく影響せず、アラートの条件を満たさないことがあります。
これは、本番環境で一時的な遅延や単発の通信不良によるアラートが多発しないようにするために有効な考え方です。

すぐにアラートを鳴らしてテストしたい場合は、この集計方法を「Max（最大値）」に変更し、評価期間を「1分」に設定します。すると、1回でも大きな遅延が発生した場合にアラートを検知しやすくなりました。
デモや検証では、Maxと短い評価期間を利用すると、遅延発生からアラート通知までの流れを確認しやすくなります。ただし、本番環境では単発のネットワーク遅延などで通知が多発してしまう可能性もあります。そのため、実運用では90th、95th、99thといったパーセンタイルや、アダプティブしきい値を利用し、サービスの特性に合わせて調整することが重要です。

6.　まとめ：Instanaで「遅い理由」まで見える運用へ

今回は、AWS上に構築したWeb／App／DBの3層構成のデモECサイトを使い、Instanaの可視化・原因特定・アラート機能を検証しました。

今回分かったことを振り返ります。

📍アプリケーションの依存関係とホスト内部の構成を自動で可視化できる

Webサーバー、Appサーバー、DBサーバーにInstana Agentを導入することで、Apache HTTPd、Javaアプリケーション、Tomcat、Redis／Valkey、PostgreSQLなどのコンポーネントが自動的に検出されました。
また、依存関係マップでは、ECサイトを構成するサービスとPostgreSQLの接続関係も確認できました。

手作業で構成図を作成しなくても、各サーバーに何があり、どのように連携しているのかを確認できることは、複雑なシステムを運用するうえで大きなメリットです。

🔍「遅い」という現象から、原因箇所まで追跡できる

今回、注文処理の遅延を2パターン再現しました。
・決済サービスの応答遅延
・PostgreSQLの応答遅延
利用者からはどちらも「注文処理が遅い」と見える現象です。しかしInstanaの分散トレースを確認することで、決済サービスが遅いのか、PostgreSQLが遅いのかを具体的に切り分けることができました。

これにより、「まずどこを調査すべきか」「誰に連携すべきか」を迅速に判断できます。

🔔 Smart Alertsで異常の自動検知・通知ができる

Instanaでは、待ち時間やエラー率などを条件にSmart Alertsを設定できます。担当者が画面をずっと監視していなくても、注文処理の遅延などを自動で検知し、通知につなげることが可能です。
ただし、90thやMaxなどの集計方法によって検知結果が変わるため、検証環境と本番環境では目的に応じて設定を使い分けることが重要だと学びました。

今回の検証を通じて、「画面が遅い」「注文処理に時間がかかっている」といった事象を見つけるだけでは、障害対応として十分ではないことを改めて実感しました。

Instanaでは、インフラの状態、アプリケーションの処理、DBアクセス、外部サービス呼び出しまでを一気通貫で確認できます。

「何かが遅い」から「どこで、なぜ遅いのか」へ。

これまで多くのログや監視画面を横断していた原因調査を、より速く、より分かりやすく進められることが、Instanaの大きな強みだと感じました。

次回予告

「InstanaとIBM Bobを連携してみた！」（予定）

ここまでの検証では、Instanaの画面から、システムの構成やアプリケーションの遅延原因、エラーの発生状況を確認してきました。
ただ、実際の運用では「今月、エラーが多かったサービスはどれ？」「先月と比べて応答時間が悪化している処理は？」「直近で発生したインシデントをまとめてほしい」といった情報を、都度画面を開いて探すのは少し大変ですよね。

そこで次回は、AIを活用した開発・運用支援ツールであるIBM BobとInstanaを連携し、自然な言葉でInstanaの情報を確認できるのかを検証してみます。

Instanaで取得した「事実」と、IBM Bobによる「対話形式での情報整理」を組み合わせることで、監視画面を一つひとつ確認する時間を減らし、障害調査や日常的なレポート作成をもっとスムーズにできるのではないかと期待しています。

「監視ツールの画面を見て分析する」だけではなく、AIに質問しながらシステムの状態を把握する運用は実現できるのでしょうか？

次回も、実際の画面を交えながら検証していきます。ぜひチェックしてください！

「にこぷす通信」について

「NIC × Ops（にこぷす）通信」は、隔週で皆さまに情報をお届けします。
このシリーズでは、Instana（可観測性）をはじめ、Turbonomic（リソース最適化）やTerraform（インフラ自動化）など、IT運用を劇的に変える製品をピックアップしていきます。
これからも最新の技術検証をチームで継続し、皆さまの現場ですぐに役立つ「有益な知見」を全力で共有していきます。 次回の連載もお楽しみに！