このブログ記事はDeena ShanghaviとBob Niの共同執筆です。
組織のモダナイズに伴い、ほとんどのアプリケーションが1つのカテゴリーに分類できなくなっています。つまり、ほとんどが従来の3層アーキテクチャとクラウドネイティブマイクロサービスの両方を併せ持っています。このようなハイブリッド環境を効果的に監視するには、この2つの領域をシームレスに連携できるAPMツールが欠かせません。
そこでSplunkは、.conf25においてSplunk Observability Cloudの新機能をご紹介します。これはクラウドネイティブアプリケーション向けのAPMを強化し、ハイブリッド環境に対するサポートを拡張するものです。これらの機能は、従来の3層型アプリケーションの監視で優れた実績を持つAppDynamicsの技術を基盤としています。このアップデートにより、ビジネストランザクションからコードレベルの実行に至るまで、監視の可視性と精度が向上します。
主な機能には以下のものがあります。
これらの機能を組み合わせることで、ハイブリッドアプリケーションやマイクロサービス中心のアプリケーションを実行する組織で、統合的なAPMソリューションを実現できます。
各サービスを個別に監視するだけでは、アプリケーションのパフォーマンスがビジネスに与える影響を把握したり、何に注力すべきか優先順位を付けたりすることは困難です。顧客に直接影響を与える、複数のサービスが関わるビジネストランザクションをエンドツーエンドで可視化する必要があります。
Splunk Observability Cloudのビジネストランザクションは、特定のトランザクションやユーザーフローを追跡する一連の関連トレースをまとめたものです。Splunkは、Splunk APMの従来のビジネスワークフロー機能をビジネストランザクションへと進化させました。専用のビューが導入され、ビジネストランザクションの定義と監視における柔軟性も向上しました。これにより、決済処理などの主要な操作の監視やトラブルシューティングが容易になります。
例:eコマースアプリケーションのサイトリライアビリティエンジニア(SRE)が、サービスごとにアラートを設定して多くのノイズが発生するのを避けるため、注文確認など重要なビジネストランザクション向けのアラート検出ルールを設定しました。ある日、注文確認トランザクションで高い遅延が発生していることを示す重大なアラートがSREに届きます。SREがアラートメール内のリンクをクリックすると、そのビジネストランザクションの概要ページがすぐに表示されました。
この概要ページで、SREは以下の内容を確認できます。
SREはトランザクション内の各サービスの遅延をすばやく比較し、最も上流のサービスであるecommerce-green-svcで最も大きな遅延が発生していることに気づきました。これで、問題をそのサービスに絞り込み、さらに詳細なトラブルシューティングを行うことができます。
ビジネストランザクションの概要ページでは、サービスの遅延の比較など、トランザクションレベルのREDメトリクスを追跡できます。
APMにおいて、トレースは分散サービス全体で遅延やエラーの発生場所を確認するのには役立ちますが、必ずしもコード内で何が起きているのかを明らかにするわけではありません。そこで役立つのがコールグラフです。コールグラフは、コードレベルで、トレースの個々のスパンの実行パスを詳細に分析することを可能にします。
Splunk APMにコールグラフが導入されたことで、遅延しているトレースを確認するだけでなく、遅延を引き起こしているサービス内の関数やメソッドを正確に特定できるようになりました。
例(上記の続き):問題の発生源がecommerce-green-svcサービスであることはすでにわかっています。そこでSREは、ecommerce-green-svcのService-Centricビューでさらに詳しく調査します。サービスが正常な状態ではなく、遅延が増えていることを確認してから、関連するトレースを分析します。トレースビューでは、問題のあるトレースが自動的に表示されるため、最も時間がかかっているトレースをクリックして状況を把握できます。
トレースビューでは、選択したサービスで問題のあるトレースが自動的に表示されます。
このトレースのウォーターフォールビューで、ほとんどの時間がルートスパンに費やされていることがわかりました。また、このルートスパンには、(青いノートブックアイコンが付いた)コールグラフが含まれています。コールグラフを確認すると、sun.nio.ch.Net.connect0(Net.java:0)というメソッドが遅延の大部分を引き起こしていることが判明しました。このインサイトに基づいて、SREは該当するコードの担当チームと直接やり取りして、問題を解決することができます。
コールグラフでは実行パスが詳細に可視化されます。
大規模な分散環境では、数百ものサービスが構造化されていないリストとして表示されることがよくあります。そのため、関係性の把握や責任範囲の特定、それに技術的な問題とビジネス領域の関連付けをすばやく行うことが困難です。論理的なグループ化を行わないと、トラブルシューティングが遅れ、ダッシュボードが雑然と管理されずに放置され、チームはノイズをふるい分ける作業に時間を取られてしまいます。
Splunkはこうした問題に対処するため、service.namespaceなどのインデックス化されたスパンタグを使ってサービスマップ上の関連サービスをグループ化できる機能を導入しました。これにより、オブザーバビリティデータに構造とコンテキストが追加され、サービスの羅列ではなく、システムの全体像がビジネスに沿ってわかりやすく表示されるようになりました。
サービスマップのグループ化によって、各チームの担当業務に合わせて、さまざまな視点を得ることができます。たとえば、決済処理関連のサービスをまとめると、その単位でパフォーマンスを監視し、各グループが相互に及ぼす影響を把握できるようになります。また、しばしばチームや事業部門によって異なる名前空間を持つため、グループ化によってサービスの所有者を明確にしたり、無関係なサービスによるノイズを削減したりできます。
サービスをグループ化すると、その健全性を一目で監視できます。各グループの周りの色付きリングが健全性のレベルを示し、赤(重大)、オレンジ(警告)、グレー(正常)の状態にあるサービスの割合がわかります。サービスグループを選択すると、そのグループのリクエストの集計値とエラーメトリクス、そしてそのグループに含まれるサービスのリストが表示されます。
サービスマップのグループ化により、各チームの担当業務に合わせて、関連サービスをインデックス化されたスパンタグでグループ化できます。
今日の分散環境では、アプリケーションは単一のサーバー上で動作するのではなく、複数のコンテナやエフェメラル(一時的な)インフラ上で、数百から数千ものサービスインスタンスにまたがって動作しています。そのため、サービスレベルのメトリクスの集計値しか見ていないと、一部のインスタンス(Kubernetes内の単一のPodやクラスター内の特定のVMなど)だけに影響している重大な問題を見逃してしまう可能性があります。
この問題を解決するため、SplunkはAPMに新しい[Instances]タブを導入しました。これにより、サービスインスタンスとインフラメトリクスを1つの画面で確認し、問題をすばやく特定できるようになりました。
[Instances]タブでは、すべてのサービスインスタンスが検索可能なテーブル形式で表示され、REDメトリクス(リクエスト数、エラー数、所要時間)に加え、CPU、メモリー、ホストIDなどのインフラデータを確認できます。インフラ監視データとの直接的な相関付けにより、アプリケーションの問題がインフラに起因するかどうかをすばやく確認したり切り分けたりできるようになります。
ここで紹介したイノベーションにより、Splunk APMはクラウドネイティブアプリケーションと従来の3層型アプリケーションの両方で業界最高レベルの機能を提供していきます。あらゆる環境のあらゆるアプリケーションを単一の統合プラットフォームで監視できるようになったのです。
今すぐ無料トライアル版をお試しになるか、デモをお申し込みください。
#splunkconf25のハッシュタグが付いたツイートをぜひご確認ください。
Splunkプラットフォームは、データを行動へとつなげる際に立ちはだかる障壁を取り除いて、オブザーバビリティチーム、IT運用チーム、セキュリティチームの能力を引き出し、組織のセキュリティ、レジリエンス(回復力)、イノベーションを強化します。
Splunkは、2003年に設立され、世界の21の地域で事業を展開し、7,500人以上の従業員が働くグローバル企業です。取得した特許数は1,020を超え、あらゆる環境間でデータを共有できるオープンで拡張性の高いプラットフォームを提供しています。Splunkプラットフォームを使用すれば、組織内のすべてのサービス間通信やビジネスプロセスをエンドツーエンドで可視化し、コンテキストに基づいて状況を把握できます。Splunkなら、強力なデータ基盤の構築が可能です。