何が重要なのかを推測で判断するのは止めましょう:ゴールデンシグナルを超えて、整備されたBusiness Journeysへ
Observability Wes Cooper主なポイント
- Business Journeysを使用すると、フロントエンド、バックエンド、ビジネスデータを結び付け、注文や融資申請などのプロセスがどこで滞っているのかを正確に把握できます。
- カスタムコーディングや大規模な設定プロジェクトを必要とせずに、既存のOpenTelemetryデータを使用して、4つの簡単なステップでビジネスジャーニーの追跡を設定できます。
- ワンクリックで、処理が滞っているビジネスプロセスから技術的な根本原因に直接アクセスできるため、実際のビジネスへの影響に基づいて修正の優先順位付けが行えます。
企業がビジネス成長を推進すべくAIや最新のクラウドアーキテクチャの規模を拡大していく中、エンジニアリング、ITOps、ビジネスサービスオーナーは、あらゆる角度からの可視化を必要としています。これには、レイテンシー、データベースエラー、サービスの依存関係といった、障害のトラブルシューティングに役立つゴールデンシグナルも含まれます。それらと同じく重要なのが、技術的なパフォーマンスがエンドツーエンドのビジネスプロセスの実行にどのように反映されているかを理解することです。融資申請の審査が順調に進んでいるか、リテール注文が予定どおり出荷・配送されているか、あるいは顧客のオンボーディングがアカウント設定の途中で気付かないうちに滞っていないか、といった点を把握する必要があります。
.conf26において、Splunkはエンドツーエンドのビジネスワークフローをリアルタイムで一元的に可視化する Splunk Observability CloudのBusiness Journeys を発表しました。フロントエンドのユーザーインタラクション(RUM)とバックエンドのマイクロサービス(APM)をビジネスKPIと相関付けることにより、エンジニアリング、SRE、ビジネス運用の各チームはシステム間のボトルネックを正確に特定し、緊急会議での推測に頼った判断をなくし、測定可能なビジネスへの影響に基づいて対応の優先順位付けができるようになります。これらはすべて、既存のOpenTelemetryインストルメンテーションを通じてシームレスに実現されます。
ビジネスドリブンのオブザーバビリティにおける3つの視点:トランザクション、顧客、プロセス
ビジネス成果を達成するためには、オブザーバビリティプラクティスを調整し、次の3種類のジャーニーを測定して監視する必要があります。
(Observability Cloud APMのBusiness Transactionsを活用)
(Observability CloudのDigital Experience Analyticsを活用)
(Observability Cloudの新機能)
単一のサービス/API呼び出し
フロントエンドのユーザーインタラクション
エンドツーエンドのビジネスワークフロー
• エラー率と例外
• サービスの依存関係とDB呼び出し
• ユーザーのつまずくポイントと離脱ポイント
• 完全なセッションリプレイ
• アプリケーション間のボトルネック
• ビジネスSLAの遵守状況と未達状況
これらの機能は、互いにシームレスに積み重なるように設計されています。
- Technical Journeysは、APM (Observability Cloud内)のBusiness Transactionsを活用して、運用サービスの信頼性やインフラの依存関係を監視します。
- User Journeysは、Digital Experience Analytics (Observability Cloud内)を活用して、ユーザーのエンゲージメント、コンバージョン、フロントエンドでのつまずきを追跡します。
- Business JourneysというObservability Cloudの新機能により、分散アーキテクチャ全体にわたり情報の点と点をつなげて、重要なビジネスプロセスが正常に完了しているかどうかを確認できるようになりました。
Splunk Observability Cloudのビジネスインサイトを詳しく見る
このブログでは、主にBusiness Journeysに焦点を当てて説明します。Splunk Observability CloudのTechnical Journeys (Business Transactionsを活用)や、User Journeys (Digital Experience Analyticsを活用)の詳細については、以下の詳しい解説やドキュメントをご覧ください。
- Business Transactionsに関するブログ:クラウドネイティブおよびハイブリッドアプリケーションの監視
- Digital Experience Analyticsに関するブログ:ユーザー行動のオブザーバビリティ
自動検出機能でビジネスジャーニーを簡単に整備
これまで、ビジネスジャーニー(別名:ビジネスプロセス監視)の設定は、手間と時間のかかる作業でした。従来の方法では、チームは数十ものマイクロサービスにわたってテレメトリを手動でタグ付けしたり、壊れやすいカスタムETLデータパイプラインを構築したり、負荷の高い独自のエージェントを導入する必要がありました。しかも、アプリケーションチームがスキーマの更新をプッシュした途端に、マッピングが機能しなくなっていました。その結果、ビジネスジャーニーの監視プロジェクトの導入には数カ月もの専門サービスが必要となり、すぐに断念されてしまうことがよくありました。
Splunk Observability CloudのBusiness Journeysは、Splunk Observability Cloudの APM や RUM ですでに収集しているOpenTelemetryデータをネイティブに活用することで、こうした設定に伴う煩わしさを解消します。チームは大規模なカスタム設定プロジェクトではなく、4つの時系列のステップで構成されるシンプルな手順に沿って作業できます。
- 選択:監視対象とする重要なビジネス成果を1つ選択します(例:融資の組成、リテールの注文処理、請求処理)。
- 検出:現在のアクティブなテレメトリにある既存の相関タグ(orderId、loanAppId、claimIdなど)を1つ選択すると、マイルストーン(ビジネスワークフローの重要な段階をマーキングするイベント)付きのジャーニーを自動的に検出します。
- カスタマイズ:マイルストーンの追加、削除、並べ替えや、分岐ロジックの設定を行います。また、Transition IDを使用して外部のバックグラウンドシステムに接続します。
- 運用:サイクルタイムを監視し、ビジネスへの影響度に基づいてエンジニアリング修正の優先順位付けを行います。
図1:Automatic Journey Discoveryビルダー。既存のOpenTelemetryの相関タグから、エンドツーエンドのビジネスワークフローを即座に構築できます。コードのリファクタリングや独自のエージェントは不要です。
運用:エンドツーエンドのプロセスの健全性をリアルタイムで監視
監視の対象が、数日間にわたる住宅ローンの処理プロセスでも、オムニチャネルリテールの注文処理ワークフローでも、自動化された保険金請求処理でも、Business Journeysは、トランザクションが各マイルストーンをどのように通過するかを自動的にマッピングします。そのため、ビジネスを推進するKPIに照らして、パフォーマンスを簡単に測定できます。
Business Journeysは、重要なビジネスプロセスの各段階にわたる進捗状況、完了率、次の段階に移るまでの遅延、離脱状況の追跡を1つにまとめた統合ビューを提供します。
図2:リアルタイムのBusiness Journeyダッシュボード。ローン承認における多段階のワークフローを追跡し、段階間の遷移時間、コンバージョンの離脱状況、および書類確認のマイルストーンで発生しているアクティブなSLA違反がハイライトされています。
主な機能は以下のとおりです。
- マイルストーンの進捗状況とボトルネックの特定:トランザクションが遅延している具体的な段階を正確に特定します(例:本人確認に4時間のSLAが設定されているが、46.2時間かかっている)。
- 非線形かつ分岐するジャーニーのサポート:実際のビジネスプロセスでは、再試行、条件付きルーティング、例外などが発生します。Business Journeysは、こうした非線形で複雑なマイルストーン構造にもネイティブに対応しています。
- 接続システムのTransition ID:注文受付からサードパーティロジスティクス(3PL)の倉庫での出荷までなど、プロセスの途中で識別子が変わる場合でも、異なるバックエンドシステムの処理を相関付けます。
技術的な根本原因をビジネスへの影響に直接結びつける
インシデント発生時にアラートが発動したとき、経営層が最初に尋ねるのは「どのPodがクラッシュしたのか?」ではありません。「何件の顧客トランザクションが影響を受けているのか、ビジネスへの影響はどの程度なのか?」です。
統合的な相関付けがなければ、エンジニアやAIアシスタントはAPMのトレースIDとCRMレコードや注文ログを手作業で照合するよう強いられます。Business Journeysを使えば、遅延しているビジネスプロセスのマイルストーンからワンクリックで、APMや RUM で収集している基盤となるテレメトリに直接シームレスにアクセスできるため、こうした手作業の負担を解消できます。
図3:遅延しているビジネスプロセスのマイルストーンから、相関付けられたAPM分散トレースやRUMユーザーセッションへシームレスに直接アクセスすることで、サードパーティのKYC APIのタイムアウトが技術的な根本原因だと判明しました。
- テレメトリへの直接アクセス:SRE、開発者、AIエージェントは、処理が滞っているカスタマージャーニーに関連する具体的なスパン、データベースクエリー、下流のマイクロサービスを確認できます。
- フロントエンドのユーザーコンテキスト:バックエンドのマイルストーンやエラーをRUMの実際のユーザーセッションと直接相関付けることで、顧客への影響を把握できます。
- 影響度に基づく優先順位付け:アラート量の多さだけで判断するのではなく、影響を受けたビジネスプロセスの財務的および運用上の重大度に基づいて、エンジニアリング的な修正のトリアージを行います。
Cisco Data Fabric Powered by Splunk上に構築
Business Journeysは、Splunkのフルスタックのオブザーバビリティ戦略を支える重要な柱です。Cisco Data Fabric Powered by Splunk上にネイティブに構築されているため、インフラ、Cisco ThousandEyesによるネットワーク経路、そして Splunk Observability Cloud の統合機能(Splunk APMのアプリケーションサービス、Digital Experience Analyticsのユーザーエクスペリエンス、Business Journeysのビジネス成果を含む)にわたる、包括的な可視化を実現します。