今日のユーザーや顧客は、オンラインのリクエストに対する応答時間に敏感です。リクエストが正常に完了するだけでは満足せず、「十分に速い」と感じられる時間内に完了することを求めています。一方、サービスを提供する側では、パブリッククラウドでよく使用されるKubernetesのようなコンテナオーケストレーションシステムの普及により、マイクロサービスアーキテクチャを取り入れたクラウドネイティブアプリケーションが増えています。こうしたアプリケーションでは、システムの動作を1つの側面だけでなくあらゆる側面から統合的に把握する必要があります。
監視の目的は結局のところ、ユーザーを満足させることです。そこで、システムの処理に応じて変化する「満足度」をリアルタイムで測定する方法が必要です。そのためには、アプリケーション内でカスタマージャーニーを追跡するだけでは不十分です。カスタマージャーニーを継続的に追跡して、変化の影響を把握することが必要です。
哲学的に、成功や満足感に対する顧客の視点は一面的です。顧客の関心は、リクエスト、その成否、完了までの時間のみです。現時点でのリクエストだけで良し悪しを判断します。今日の社会では、満足感にも即効性が求められます。Microsoft社の調査では、人の集中力の持続時間は8秒だという結果が出ています(反論も多い結果ですが)。モバイルサイトの表示時間と直帰率の関係に関するGoogle社の調査では、1ページの読み込み時間が5秒以内での直帰率は90%に達します。人は退屈するのを好まず、特に今日のデジタル時代においては、待つことは退屈とみなされます。退屈させたままでは競争を勝ち抜くことはできないのです。
しかし、一般的なDevOpsエンジニアの視点は1つのワークロードにとどまりません。エンジニアの関心は、すべてのリクエストと、それらの遅延、比率、同時実行数にまで及びます。そのため、リクエストに対する処理を支えるシステムリソースやその関連コンポーネントの動作も対象になります。その監視アプローチとして主流になっているのが集計であり、よく使われるのがRED (Rate: 比率、Errors: エラー、Duration: 期間)です。
両者の視点は関連していますが、同じではありません。そのため、メトリクスをトレースレベルまで分解できることが重要です。顧客が気にするのは自身のエクスペリエンスであり、DevOpsエンジニアが気にするのは全体のパフォーマンスです。そこでオブザーバビリティの考え方を取り入れれば、その両方を把握して、適切なデータを適切に維持することができます。
オブザーバビリティはデータの監視に重要な概念であり、システムの動作を追跡して状態を推測するために必要な情報を提供するのはシステムの属性です。オブザーバビリティのデータやシグナルは、一般的に、メトリクス、トレース、ログの3つの柱で構成されます。これらのデータを使用して、インフラコンポーネントとアプリケーションコンポーネントの両方の状態を把握できます。データが完全である(完全な忠実度のデータを収集できる)システムでは、リクエストに対する個々のすべての処理を確認できます。
REDの例がこちらです。これによると、過去10秒間で1秒あたり平均5.8件のリクエストがあったことがわかります。また、すべてのリクエストが正しく処理されたことも示されています。つまり、システムがすべてのリクエストを処理し、正しく完了させたことがわかります。運用の観点から、システムは非常に良い状態にあると言えます。
ただし、過去10秒間で処理の完了までに平均5秒以上かかっています。正規分布曲線で考えると、少なくとも1人の顧客はかなり待たされていると推測されます。このように、オブザーバビリティデータから、今のシステムの状態では顧客の不満がある程度生まれている可能性があることがわかります。
ここで分散トレーシングデータがあれば、特定のトレースを確認することができます。この例では、時間のかかっているトレースの1つを詳しく調査することで、タイムアウトの問題が発生していたことがわかりました。
さらに、カーディナリティが高いデータから、考えられる原因を特定することもできます。タグの欄で「userId」の項目を探してみてください。その値を見るとスペース(“ “)になっています。つまり、何らかの理由で、システムは空のフィールドを受け入れていたのです。
この情報をもとに、該当するサービスのログファイルを調査して、何が起きているのかを突き止めることができます。原因は無効なuserIdの処理ミスかもしれませんし、ルックアップの不具合かもしれません。ログを見れば答えがわかるでしょう。このように、メトリクスとトレースは、問題の有無や問題の発生箇所を調べるのに役立ちます。
注目すべき点は、すべてのデータ、つまり完全な忠実度のトレース(とメトリクス)データを利用できるときにこそ、このアプローチが最大の効果を発揮することです。データをサンプリングしたり特定のデータ(エラーや外れ値など)のみを収集するシステムでは、影響を見過ごしたり、もっと悪い場合にはイベントを特定できなかったりする可能性すらあります。
ユーザーの満足度はリクエストの成否と処理時間によって決まることをよく覚えておいてください。そして、REDなどのダッシュボードでメトリクスを監視して、オブザーバビリティデータをユーザーの満足度を測る代替手段として活用しましょう。分散トレーシングを利用すれば、単体のトランザクションの観点と経時的な観点の両方でユーザーエクスペリエンス全体を把握できます。さらに、ログを利用すれば、根本的な問題を解決するための最善策を見つけて、ユーザーの満足度を維持し続けることができるはずです。
関連情報
このブログはこちらの英語ブログの翻訳です。
