DevOpsチームが直面する大きな課題の1つとしてとして、自らの業務の成果とリーダーの優先事項を関連付けることが挙げられます。私たちがこれまでに聞き取りを行った開発者やSREの多くは、自分たちが時間を有効に使って問題に適切に対処していること、そしてそれがビジネス成果の向上につながっていることを、ビジネスリーダーやエンジニアリングリーダーにどのように示せばよいか悩んでいました。ビジネスリーダーやエンジニアリングリーダーもまた、別の角度から同じ問題を抱えています。リーダーは常にビジネスKPIをリアルタイムで把握し、各マイクロサービスがそれらのKPIに与える影響を知りたいと思っているのです。
従来型のアプリケーションパフォーマンス監視(APM)ソリューションは、重要なビジネスKPIをアプリケーションの主要トランザクションと関連付け、それらのトランザクションの遅延やエラー率を監視することで、この問題に対応しています。しかしこのアプローチは、一昔前の環境を前提としており、ビジネストランザクションはシステムへのエントリーポイントに基づいて定義されます。モノリシックなレガシーアプリケーションであればこのアプローチは有効ですが、技術が進化し、マイクロサービスやクラウドを活用した新しいアプリケーションが登場した今日では、1つのアプリケーションが数十、ときには数百のマイクロサービスで構成されます。また、複数のトランザクションが同じエントリーポイントを共有しながら、それぞれ異なるダウンストリームサービスに枝分かれし、まったく異なるビジネスKPIに関連付けられることもあります。この新しいエキサイティングな世界では、エントリーポイントに基づくアプローチはもはや時代遅れです。
今日の環境に必要なのはオブザーバビリティです。オブザーバビリティのアプローチが問題解決の鍵を握ります。マイクロサービスを運用するには、システムをより深いレベルで理解する必要があります。Splunk APMは、マイクロサービスをベースとする環境でも重要なビジネスKPIを追跡できる唯一のAPMソリューションです。Splunk APMのBusiness Workflows機能では、重要なビジネストランザクションやビジネスKPIに基づいて、さまざまなマイクロサービスをグループ化できます。この機能の詳細を説明する前に、1つの例をご紹介します。
下の図に示すアプリケーションについて考えてみましょう。このアプリケーションでは、カタログ(catalog)とチェックアウト(checkout)の2つのメイン機能が実行されます。ただし、システムへのエントリーポイントは1つのAPIサービスに統合されています。このAPIの遅延やエラー率を測定すればある程度の情報は得られますが、チェックアウト関連またはトランザクション関連のトランザクションの実行状況についてビジネスリーダーやエンジニアリングリーダーが必要とするインサイトは得られません。また、開発者の観点から、カタログとチェックアウトの両方のトランザクションで使用される認可(authorization)サービスとアイデンティティプロバイダー(Idp)サービスのオーナーはそれぞれ、担当するサービスが2つのメイン機能のKPIにどう影響しているかを把握する必要があります。
図1：複数のマイクロサービスで構成されるアプリケーション
Business Workflowsによる重要なKPIの測定
Business Workflowsでは、内蔵の使いやすい設定ウィザードを使って、マイクロサービス、タグ、または起点となる操作に基づいて、関連するすべてのトレース/トランザクションをグループ化できます。ワークフローを重要なビジネスKPIと直接相関付けて定義することで、ビジネス/エンジニアリングリーダーとDevOpsチームの両方にとって有用なメトリクスが提供されるようになります。ビジネスワークフローを定義した後は、事前構築済みのダッシュボードで、RED(比率、エラー、期間)メトリクスの値が高いワークフローを確認したり、個々のワークフローのREDメトリクスを追跡したりできます。さらにこれらのグラフから、コンテキストを維持したままサービスマップにシームレスに移動することや、ワークフローに基づくアラートを作成することも可能です。
この例の場合は、チェックアウトとカタログに基づく2つのビジネスワークフロー、CheckoutとCatalogを作成できます。さらに、チェックアウトサービスと出荷(shipping)サービスの両方をたどるすべてのトレースを追跡するための3つ目のビジネスワークフロー、Shippingを作成して、詳細度を高めることもできます。
図2：Checkout、Shipping、Catalogワークフロー
3つのワークフローはいずれもトレースがAPIサービスから始まりますが、その後、カタログサービスに遷移するか、チェックアウトサービスに遷移するか、またはチェックアウトサービスを介して出荷サービスに遷移するかによってグループ分けされます。実際、Splunkのお客様の中にも、チェックアウトの成功率を重要なKPIとして追跡している企業があります。
前述したように、ワークフローで問題が起きたときにアラートを生成することも簡単にできます。個々のサービスに関するアラートと同様に、Business Workflowsでは、エラー率や処理時間が指定のしきい値に達したときや、予想外の変化があったとき、または過去の異常に基づいてAIの判断でアラートを生成するように設定できます。Splunk APMは、サンプリングをせずにすべてのトレースを調査、分析、保存し、問題を漏れなく検出できる点で、他に類を見ないソリューションです。
図3：Checkoutビジネスワークフローの事前構築済みのダッシュボード
図4：ビジネスワークフローに基づくアラートの定義
開発者の観点
開発者の観点から、自身が担当するサービスがビジネスKPI全体に与える影響を追跡することもできます。ビジネスワークフローを定義すれば、サービスマップをクリックすることで、担当するサービスのエラーや遅延が、そのサービスを使用する各種のワークフローにどう影響しているかを簡単に確認できます。
図5：Idpサービスをクリックした画面。エラーはすべてCheckoutワークフローに関連していて、CatalogとShippingワークフローには影響していないことがわかります。
Business Workflowsを活用してトラブルシューティングを加速
Business Workflowsのメリットは、ビジネスリーダーとDevOpsチームに共通の言語を提供することだけにとどまりません。Splunk APMでBusiness Workflowsを活用することにより、SREと開発者は、検出された問題のトラブルシューティングを迅速化できます。図1の例でAPIサービスに表示されている赤い丸は、問題が発生していることを示します。図2を見ると、ShippingワークフローとCatalogワークフローに赤い丸は表示されておらず、問題のあるトレースはないこと、そしてすべての問題はCheckoutワークフローに起因していることがわかります。この簡単な例でも、図1だけでは、エラーの大半がCheckoutビジネスワークフローに関係していることは推測できたかもしれませんが、Shippingワークフローにエラーがまったくないことは確信できなかったでしょう。サービスマップに数百のサービスが含まれ、もっと複雑であったら、状況の把握はなおさら困難です。そこで、ワークフローに基づいてサービスマップをフィルタリングする機能が役立ちます。これによりDevOpsチームは、トランザクションごとに関連するサービスをすべて確認し、アプリケーションの問題を特定して、すばやくトラブルシューティングできます。さらにワークフローを選択すれば、そのワークフローのエラーや遅延に関連付けられた主なタグが自動的に抽出されるため、トラブルシューティングが一層簡単になります。
図6：Checkoutビジネスワークフローに関連付けられた主なエラータグ。右下のグラフによるとKubernetesノード6が原因のようです。
また、サービスオーナーであれば、Tag Spotlightを使って、担当するサービスが影響を与えているビジネスKPIとその影響の度合いを確認できます。次の図は、エラーの根本原因であることを示す濃い赤い丸が表示されたIdpサービスのTag Spotlight画面です。
図7：Tag Spotlight。下段の一番右のグラフによると、Idpサービスのエラーはチェックアウトサービスにのみ影響を与えていることがわかります。また、上段の右から2番目のグラフによると、これらのエラーはすべて無効な資格情報が原因であることがわかります。
これだけではありません。Splunk APMは無限のカーディナリティに対応しているため、図8に示すように、ビジネスワークフローなどの任意のタグの組み合わせに基づいてトレースデータを詳細に分析できます。また、サンプリングをせずにすべてのトレースが保存されるため、それらのタグの組み合わせの標本トレースをいつでも取得できます。図9では、Checkoutビジネスワークフローに2つのタグを追加しています。
図8：ビジネスワークフローによってフィルタリングした決済サービスのタグ
図9：決済サービスを通るCheckoutワークフローの標本トレース。プラチナ層に属し、HTTPステータスコード401を返したという条件でフィルタリングしています。
これらの機能を活用すれば、ビジネスワークフローに問題が発生したときに、SREはTag Spotlightを使って、問題の要因となっているサービスと影響を受けるユーザーをすばやく特定できます。これにより、関係チームだけを対策会議に招き、無関係のチームが無駄に時間を費やすのを避けることができます。その後、問題のあるサービスを担当している開発者もTag Spotlightを使って、問題の根本原因をすばやく特定し、トラブルシューティングに取り掛かることができます。
続く改善
Business Workflowsは、ビジネスパフォーマンスに対するアプリケーションの影響という、ビジネスリーダーやエンジニアリングリーダーが必要とする情報を可視化する、唯一無二の強力なツールです。マイクロサービスをベースとする環境を前提に設計され、エンドツーエンドのトレースに基づいて正確なメトリクスを生成し、ビジネスKPIに関するグラフやアラートを生成します。開発者やSREは、Business Workflowsを使用することで、アプリケーションアーキテクチャがどれだけ複雑であっても、各種サービスの影響範囲を把握し、問題をすばやくトラブルシューティングできます。
Business WorkflowsはSplunk APM Enterpriseエディションに含まれ、APM Enterpriseをご使用中のお客様はすでに利用可能です。
SplunkはBusiness Workflowsの改善を続けており、数カ月後にはさらに強力な機能が追加されるでしょう。ぜひご期待ください。
Splunk APMは、Splunk Observability Cloudに含まれる非常に優れたソリューションです。ガートナー社は、マジック・クアドラントのアプリケーションパフォーマンス監視(APM)部門でSplunkをビジョナリーに位置付けています。
Splunk Observability Cloudについて詳しくは、こちらのビデオまたはデモをご覧ください。エンドツーエンドの可視化を体験してみたい方は、Splunk Observability Cloudの14日間無料トライアルもご利用いただけます。
このブログはこちらの英語ブログの翻訳、池山 邦彦によるレビューです。
