Amazon CloudWatch RUM、Evidently、ServiceLens によるオブザーバビリティ ジャーニー

このブログは An Observability Journey with Amazon CloudWatch RUM, Evidently, and ServiceLens (ブログ公開日 : 2022 年 1 月 24日) を翻訳したものです。

オブザーバビリティとは、単なる監視ではありません。AWS では、オブザーバビリティは健全で安全な運用に欠かせない要素であると考えています。アプリケーションの健全性と運用に関するオブザーバビリティを強化する Amazon CloudWatch の最新機能の 2 つは、Amazon CloudWatch RUM と Amazon CloudWatch Evidently です。このブログでは、これらのツールを使用してアプリケーションをエンドツーエンドでデバッグする方法と、これらが他の CloudWatch サービスとどのように統合されているかを説明し、ユーザーエクスペリエンスとアプリケーションのパフォーマンスの全体像を把握できるようにします。

始める前に、「エンドツーエンド」が実際に何を意味するのかを明確にしておきましょう。真のオブザーバビリティ ストーリーには、エンドユーザーまたはお客様によるアプリケーションの利用が含まれます。このブログでは、エンドユーザーが Eコマースサイトで購入しようとしたときに、技術的な障害が発生する例を挙げて説明します。フロントエンドのウェブアプリケーションから、別のディベロッパーが実行していた A/B テスト、ウェブアプリケーションとのインタラクションを定量化するために使用するツール、そして最後にマイクロサービスのバックエンドに至るまで、ユーザージャーニーの全過程を見ていきます。このブログの Eコマースサイトは架空のものですが、ここで説明する技術や経験はどれも架空のものではありません。このブログでは、AWSが経験した実際のシナリオについて説明しています。

これらの新しいサービスにはどのようなものがありますか?

ディベロッパーやオペレーターは、ログ、トレース、メトリクスをオブザーバビリティの構成要素として説明するのが一般的です。サービスの観点から見ると、Amazon CloudWatch Logs、Amazon CloudWatch メトリックス、および AWS X-Ray を使用してトレースを行っています。CloudWatch には、これら 3 つのデータタイプを照合、取り込み、分析し、洞察を引き出す強力なツールも用意されています。お客様の目的とアプリケーションアーキテクチャに応じて、AWS がサポートすることを約束しているオープンソースベースの代替手段もあります。

ここで、新しい AWS オブザーバビリティツールが登場します。このツールは、問題がアプリケーションやインフラストラクチャのさまざまなコンポーネントにまたがるときに、インサイトをコンテキストに基づいてリンクすることで、データの意味を理解するのに役立ちます。マネージドとガイド付きのエクスペリエンスを通じて、お客様が自分で点と点をつなぐ必要がないように、私たちが難しい作業を代行します。これらのサービスを組み合わせることで、アプリケーションパフォーマンスモニタリングプラットフォームが提供されます。

これらのサービスは、Amazon が提供するすべてのサービスやプラットフォームでオブザーバビリティを高めるために使用しているものです。今日、Webアプリケーションとのインタラクションを可視化するためには、これらのツールを組み合わせて使用する必要があります。エンドユーザーのテレメトリを収集してウェブアプリケーションに関するインサイトを得たり、エンドユーザーのページ読み込み時間を測定したり、実験を行ったり、エラー率が高い場合はトグルを使用してアプリケーションの機能を無効にしたりするために、さまざまな機能が必要になる場合があります。

Amazon CloudWatch RUM と Evidently はまさにそれを実現するもので、手間のかかる作業を自分で行う必要はありません。実際のユーザーのアプリケーション体験のデータを簡単に収集し、ユーザーの感情やフラストレーション、エラー、他12種類以上のイベントタイプから解釈できます。さらに、CloudWatch はこれらのニーズを明確にターゲットにした一連の機能を提供します。

Digital Experience Management (DEM)

Amazon CloudWatch DEM では、パフォーマンス、可用性、使いやすさなど、エンドユーザーがアプリケーションをどのように体験しているかを監視できます。たとえば、ユーザーがウェブページを読み込んだ場合、そのページのオブジェクトが読み込まれ、ブラウザがこのページをレンダリングするのを待ってから操作を続行する必要があります。HTML、CSS、画像、JavaScript コード、ページを描画する時間、Web サービスへの非同期呼び出しなど、Web アプリケーションのあらゆる要素がまとめてユーザージャーニーの要素を構成します。CloudWatch DEM ツールはこうしたカスタマーエクスペリエンスをわかりやすく説明し、オブザーバビリティのコアとなる 3 つの基本原則に基づいて構築されており、ディベロッパーがエンドユーザーのアプリケーションに対する不満や喜びを理解するための強力な手段となります。2021年の re: Invent で、CloudWatchは既存のDEMスイートを拡張する2つの新しいサービスを導入しました。

Amazon CloudWatch RUM は、ウェブアプリケーションのクライアント側の問題を特定・デバッグし、エンドユーザーのデジタル体験を向上させるのに役立つ、リアルユーザーモニタリング機能です。CloudWatch RUM により、アプリケーション開発者と DevOps エンジニアは、クライアント側のパフォーマンス問題を解決するまでの平均時間 (MTTR) を短縮できます。

Evidently はディベロッパーがアプリケーションコードに実験や機能管理を簡単に導入できるようにする新しい Amazon CloudWatch の機能です。CloudWatch Evidently は、機能フラグとも呼ばれるシャドーローンチの実装と A/B テストという、似ているが異なる 2 つのユースケースに使用できます。

実際のサポート体験を通して、実感しましょう

エンドユーザーがお気に入りの Eコマースサイトで「購入を完了する」ボタンをクリックしたところ、ページの読み込みに時間がかかり、エラーメッセージが表示されました。

この状況は良いカスタマーエクスペリエンスではありません！ しかし、Eコマースアプリケーションはすでに CloudWatch RUM にオンボードされているので、このエラーが表示された直後に、RUM ウェブクライアントはエラー、ページID、セッションID、アプリケーショントレースID、その他いくつかの重要な統計を分析のため CloudWatch RUM に報告しています。お客様が辛抱強く購入を再試行している間に、何が問題だったのかを知るためのデータはすでに収集されているのです。

そして残念なことに、今日購入に失敗したのはこのお客様だけではありませんでした！ このトランザクションやその他の誤ったトランザクションから収集されたデータを使用して、問題を効果的にデバッグし、今後のトランザクションに影響を与えないようにすることができます。これが重要なポイントですよね？ ここで問題となるのは、これがどれくらい早くできるかということです。このお客様に起こったことを切り分け、そもそも起こらないようにするにはどうすればよいでしょうか。しかし、先走ることなく、目の前の問題に集中しましょう。

購入ページを管理する開発チームには、購入ページでステータスコード 502 が急増しているというアラームがいくつか届きます。これは問題があることを示す最初の兆候です。同時に、CloudWatch メトリックスで購入が成功した回数が急落していることもわかりました。

ディベロッパーは、購入を試みた後にテキストを書き換えて表示する実験が行われていることを理解しており、最近のデプロイが問題になっているのではないかと疑っています。最初に立ち寄るのは CloudWatch RUM コンソールで、アプリケーション全体のユーザーエクスペリエンスの重要な統計情報を表示できます。結局のところ、すべてはお客様から始まります！

明らかに、問題が発生しています！ページの平均読み込み時間が大きな問題を引き起こしていることがわかったため、ディベロッパー はエラーとセッションのページから詳細情報を確認します。

ディベロッパー は世界中で発生している問題を明確に把握できるため、問題が特定の地域に限定されている可能性を排除できます。また、エラーが複数のデバイスで発生していることも確認できます。つまり、特定種類のデバイスに関連するコードの問題ではないことがわかりました。素晴らしい！ ここで問題を大幅に絞り込み、これはネットワークの問題ではないことを理解しました（あちこちで見かけるので）。これで、アプリケーションのパフォーマンスに集中できます。

サービスマップを通じて、ディベロッパーはエラー状態にあるいくつかのリソースを確認し、またアラーム状態であることも確認しました。

これらのリソースでトレースを調べると、502という同じアプリケーション エラーが見つかり、Lambda 関数のアプリケーションからのログと相関関係もわかります。さらにログを調べてみると、コード内の型変換が誤って処理されたというバグがすぐに見つかります。

ディベロッパーはほんの数分で多くのことを理解しました。

• 特定の地域や特定タイプのデバイスで発生している問題ではありません。
• ネットワークの問題ではないようです。
• コードにバグがあります。
• 購入の 50% が失敗しています。
• そして、サイト上のエンドユーザーの体験が悪いです。

しかし、この問題を解決するために本番環境への緊急デプロイ（他のリスクを招く手順）を行う代わりに、アプリケーションログから興味深い情報を見つけました。組織内の別のチームが購入ページで新しい機能を試すための実験を行っており、この実験を含むようにお客様のコアワークフローを更新していたようです。ディベロッパー が Amazon Eviently コンソールを開くと、実験的なページビューに送られたユーザーの数が表示されます。

皮肉なことに、これはとても良いニュースです！この時点で、新しい購入ページは実験の一部であるため、ディベロッパー はすぐにそれを終了させ、すべてのトラフィックを以前の機能バージョンに戻すことができます。これにより、トラフィックの 100% が購入コードの正常な表示に戻されます。現時点ではデプロイは不要です！

危機は回避されました！そして、そのエラーが二度と表示されないことを願っています。なぜなら、すべての買い物と選択を行った後にチェックアウトできないなんて、お客さんにとってこれ以上悪いことはないでしょう!

このチームは、Evidently を利用して定期的にアプリケーション機能をテストしており、過去の実験も大成功を収めています。この例では、同じツールを使用して実際の生産上の問題をどのように軽減できるかを見ることができます。

自動化でこれをさらに改善しましょう

上記の例は典型的でありふれたものですが、問題を解決するための手作業による介入が強調されています。これは素晴らしいスタートです！ただし、この種のサービス修正を人間に任せることは最も効率的な方法ではないため、エラーから自動的に回復できるシステムを使用することを強くお勧めします。ここでは、このようなお客様への影響を防ぐことができた 2 つの簡単な更新について説明します。

CloudWatch Synthetics の利用

Amazon CloudWatch Synthetics を使用すると、スケジュールに従って実行される設定可能なスクリプトである Canary を作成し、エンドポイントと API をモニタリングできます。Canary はアプリケーション内で同じルートをたどり、お客様と同じアクションを実行します。これにより、アプリケーションにライブトラフィックがない場合でも、カスタマーエクスペリエンスを継続的に検証できます。Canary を使用することで、お客様より先に問題を発見できます。

この場合、エラーがお客様の画面に明るみに出る前に Canary が開発チームに問題を警告できたはずです。しかし、これよりもさらに多くの自動化を実現できます！

CloudWatch Evidently の利用

今回説明したアクションは、エンドユーザーが観察した環境の健全性に基づいて、プログラム的に、そして動的に操作できる Evidently を介して行われます。失敗した実験や機能の公開を自動的に終了させる最も簡単な方法は、AWS が収集するメトリクスを利用して終了させることです。CloudWatch RUM は、実際のユーザーが体験した ウェブページのパフォーマンスを自動的に測定します。アプリケーションに不安定性や劣化が見られる場合は、実験を中止してみてはいかがでしょうか。

これは、CloudWatch アラーム、メトリクス、実験を削除する Lambda 関数を含むシンプルなパイプラインで行うことができます。これにより、アプリケーションのデフォルトの動作が復元されます。

データ収集を自動化するだけでなく、アプリケーションの動作をプロアクティブかつダイナミックに調整するこのアプローチを使用することで、本番環境のエラーを観察し、修正するまでの時間を短縮できます。かつては何時間もかかっていたことが、わずか数分で自動的に達成できるようになりました。また、この実験をすぐに終了しても、開発チームは何が起こったのかについての可視性や洞察を失うことはありません。本番環境へ暫定的な予定外の変更を行うのではなく、事後分析とエラー修正を安全な方法で行うことができるのです。

次のステップ

上記のシナリオは、私たち自身の経験から導き出されたもので、私たちのお客様が日々直面している現実的な問題を表しています。Amazon CloudWatch RUM と Evidently は、オブザーバビリティを迅速に進め、アプリケーションの状態に関するインサイトを得るのに役立つ新しいサービスですが、オブザーバビリティの話はそれだけではありません。ログ、メトリクス、トレースに関する洞察を提供する一連のサービスが揃っていますが、このブログは表面的なものにすぎません。

One Observability Workshop を確認し、合成テスト、ログの相関、カスタムメトリクス、高度なダッシュボード、異常検出モデルなどについて、さらに多くの例や詳細を確認することをお勧めします。

著者について:

翻訳はテクニカルアカウントマネージャーの日平が担当しました。原文はこちらです。