自動ディスカバリーおよびモニター
自動検出と監視により、効率的で適応性の高いシステム管理が可能となり、大規模アプリケーションにおける物理コンポーネント、論理コンポーネント、およびビジネスコンポーネントを網羅的にカバーできるようになります。 このアプローチは、異常をリアルタイムで検知し、障害による影響を最小限に抑えます。 この高度な監視ソリューションは、システム管理に対して徹底的かつ適応性の高いアプローチを提供します。これは、現代の動的なアプリケーションの信頼性とパフォーマンスを維持するために不可欠なものです。
従来の Application Performance Management （APM）ツールは、本番環境におけるボトルネックやエラーを検出するために、データを手動で調査・照合するのに役立ちます。 しかし、従来のAPMツールには、大規模化に伴う複雑さや現代のシステムの動的な性質によって引き起こされる問題を解決するという課題がある。 問題を特定するには、相互に関連するコンポーネントと指標を照合する必要があります。
機械学習を活用したアプローチは、システム管理の大幅な改善をもたらします。 最適な結果を得るためには、このアプローチの基盤として、堅牢かつ包括的なコアモデルを構築する必要があります。 マイクロサービス・アプリケーションは、絶えず進化し続ける多くの構成要素から成り立っています。 したがって、すべてのブロックとその依存関係を理解する必要がありますが、そのためには高度な調査手法が求められます。
自動検出および監視の構成要素
自動検出および監視の対象には、物理コンポーネント、論理コンポーネント、およびビジネスコンポーネントが含まれます。
物理コンポーネント
次の表は、物理的な構成要素とその説明をまとめたものです：
| コンポーネント | 説明 |
|---|---|
| データセンターまたはアベイラビリティゾーン | ゾーンは、さまざまな大陸や地域に存在します。 これらのゾーンは、障害が発生することも、パフォーマンス特性が異なることもあります。 |
| ホストまたはマシン | 物理的なもの、仮想的なもの、あるいはサービスとして提供されるもの。 各ホストには、CPU、メモリ、I/Oなどのリソースがあり、これらがボトルネックとなる可能性があります。 各ホストは 1 つのゾーンで実行されます。 |
| コンテナー | ホスト上で動作し、コンテナを管理するために Kubernetes などのスケジューラが必要です。 |
| プロセス | コンテナ内またはホスト上で実行されます。 プロセスには、 Java や PHP などの実行環境や、Tomcat、 Oracle、 Elasticsearch などのミドルウェアが含まれる場合があります。 |
| クラスター | 多くのサービスは、グループやクラスタとして動作し、外部からは単一の分散プロセスとして認識されるように設計されています。 クラスター内のインスタンスの数は変化する可能性があり、クラスターのパフォーマンスに影響を与える可能性があります。 |
論理コンポーネント
次の表は、論理コンポーネントとその説明をまとめたものです：
| コンポーネント | 説明 |
|---|---|
| サービス | 前述の物理的な構成要素の上に構築され、複数のインスタンスや異なるバージョンを持つことができる論理的な作業単位。 |
| エンドポイント | システムの他の部分に対して特定のコマンドを公開するための、サービスのパブリック API。 |
| アプリケーションの展望、あるいはアプリケーション | タグを使用して宣言され、共通のコンテキストによって定義される一連のサービスおよびエンドポイントに関する視点。 |
| トレース | サービス間の同期通信および非同期通信の流れ。 サービスは相互に通信し、ユーザー要求の結果を配信します。 データ・フロー内のデータを変換するプロセスには、多くのサービスが含まれる場合があります。 |
| 呼び出し | 2つのサービス間のリクエスト。 トレースは、1 つ以上の呼び出しで構成されます。 |
ビジネスコンポーネント
次の表は、ビジネスコンポーネントとその概要を示しています：
| コンポーネント | 説明 |
|---|---|
| ビジネス・サービス | 独自のビジネス価値とサービスを提供する、サービスおよびアプリケーションの組み合わせ。 |
| ビジネス・プロセス | あるプロセスを構成する技術的な要素の組み合わせ。 例えば、Eコマースにおける「購入」のプロセス、それに続くERPでの注文処理、そして顧客への配送における FedEx's の物流プロセスを表すことができます。 |
複数のゾーンや大陸にまたがる数百台のホスト上で、さまざまなバージョンのサービスインスタンスが数千台も稼働し、ユーザーにアプリケーションを提供していることは珍しくありません。 これにより、アプリケーションのサービス品質が保証され、ビジネス価値が提供されるように、完全に連携する必要があるコンポーネント間の依存関係のネットワークが作成されます。 従来のモニター・ツールでは、1 つのコンポーネントがしきい値を超えた場合にアラートが出されることがあります。 ただし、これらのコンポーネントの 1 つ以上が失敗しても、アプリケーションの品質が確実に影響を受けるわけではありません。 したがって、現代の監視ツールは、サービス品質を効果的に監視、分析、予測するために、コンポーネントのネットワーク全体とその相互依存関係を理解する必要があります。
変更点の特定と記録
現代のアプリケーションでは、サービス数とその依存関係が、サービス指向アーキテクチャ（SOA）に基づくアプリケーションよりも多くなっており、これが監視ツールにとっての課題となっています。 継続的デリバリー手法、自動化ツール、コンテナプラットフォームの普及により、アプリケーションの変更頻度が上昇していることが、この問題をさらに深刻化させている。 このような変化の激しい環境下では、変更を手作業で追跡し、新たに展開されたブロックに対して監視ツールを継続的に設定し続けることは現実的ではありません。
この課題に対処するためには、最新の監視ソリューションは、各ブロックを分析・把握する前に、それらを自動的にかつ瞬時に検出できなければなりません。 この機能により、その後の変更が確実に紐付けられるため、インシデントを調査するために、任意の時点でのモードを再現することが可能になります。
この変更は、以下の図に示すように、どのビルディング・ブロックでもいつでも発生する可能性があります。
Instana の包括的な調査プロセス
Instana Dynamic APMは、センサーを利用する Instana エージェントアーキテクチャに基づいています。 センサーとは、特定の対象を監視するように設計された、コンパクトな自動化プログラムのことです。 これらのセンサーは、ホスト上でスタンドアロンプロセスとして、あるいはコンテナスケジューラを通じてコンテナとして展開される単一のエージェント（ホストごとに1つ）によって管理されます。
エージェントは、 AWS のアベイラビリティゾーン、 Docker ホスト上で実行されるコンテナや Kubernetes、 HAProxy、 Nginx、 JVM、 Spring Boot、 Postgres、 Cassandra、 Elasticsearch などのプロセス、さらには Cassandra クラスタといったこれらのプロセスのクラスタに至るまで、さまざまな物理コンポーネントを自動的に検出して監視します。 検出された各コンポーネントについて、エージェントはその設定データを収集し、変更の監視を開始します。 また、各コンポーネントの重要なメトリクスを1秒ごとに送信します。 エージェントは、 JMX や Dropwizard など、各サービスから提供されるメトリクスを自動的に検出して利用します。
その後、エージェントはサービスコードにトレース関数を挿入します。 例えば、HTTP 呼び出し、データベース呼び出し、および Elasticsearch に対する照会をインターセプトします。 エージェントは、スタックトレースやペイロードなど、各呼び出しのコンテキストをキャプチャします。
収集したデータをトレースとして処理・分析し、依存関係やサービスを特定し、異常や問題を検出する処理は、サーバー上で行われます。 したがって、このエージェントはコンパクトであり、数千台のホストに展開することができます。
Instana 次世代の監視ソリューション向けに、自動的かつ即時的、そして継続的な検出を行うように設計されています。
データの収集
Instana これは、単一のエージェントと複数のセンサーを使用し、数百以上のテクノロジーに対応する監視ソリューションです。 センサーは自動的に検出・監視され、データはエージェントに送信されます。 このエージェントは、 Instana Service Quality Engine とのすべての通信を管理します。 検出後、センサーはコンポーネントの状態に関する詳細なデータを収集します。このデータは、特定の技術に合わせて調整されています。 センサーは、エージェントによって更新、ロード、およびアンロードされます。 オプションのコマンドラインインターフェースを使用すると、エージェントの状態、個々のセンサー、およびエージェントのログにアクセスできます。 詳細については、 「サポートされているテクノロジーの設定と監視」 を参照してください。
センサーは、以下のデータを収集します。
- 構成: 変更を追跡するために現在の設定と状態をカタログします。
- イベント: 初期ディスカバリー、状態変更 (オンラインおよびオフライン)、エンティティーの正常性ルールの失敗に基づいて問題またはインシデントをトリガーする組み込みイベント、および任意のエンティティーの個々のメトリックのしきい値に基づいて問題またはインシデントをトリガーするカスタム・イベント。
- トレース: プログラミング言語プラットフォームに基づいてトレースをキャプチャーします。
- メトリック: パフォーマンスを示すテクノロジーの定性的属性。
Instana のセンサーは再帰的な検出を行います。例えば、「 Java Machine」センサーは、スタックを遡ってTomcatや SpringBoot といったフレームワークを検出します。 検出結果に基づき、センサーはエージェントが適切な追加センサーを読み込むのを支援します。 さらに、 Instana のデータ処理・分析機能により、依存関係やサービスを特定し、サーバー上で発生する異常や問題を検知します。 したがって、このエージェントは軽量であり、数千台のホストに展開することができます。
Instana のバックエンドはストリーミング技術を採用しており、エージェントからストリーミングされる毎秒数百万件のイベントを処理することができます。 このストリーミング・エンジンは効果的にリアルタイムであり、シチュエーションを処理してユーザーに表示するのに 3 秒しかかかりません。