re:Invent 2024: エンドツーエンドのデジタルエクスペリエンス監視ベストプラクティス
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Best practices for end-to-end digital experience monitoring (COP320)
この動画では、エンドツーエンドのデジタルエクスペリエンスモニタリングのベストプラクティスについて解説しています。CloudWatch RUMやSyntheticsを活用したフロントエンド体験の監視から、Amazon BedrockのGenerative AIワークロードのモニタリング、そしてCloudWatch Database Insightsによるデータベースの監視まで、包括的な内容をカバーしています。特に、SLOの設定とBurn Rateに基づくアラート、Application Signalsを活用したサービス診断、OpenTelemetryとX-Rayを組み合わせた分散トレーシングなど、具体的な実装方法とベストプラクティスを詳しく説明しています。システム障害による10万ドル以上のコスト発生や信頼関係の喪失を防ぐための、実践的なObservabilityの実現方法を学ぶことができます。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
エンドツーエンドのデジタルエクスペリエンスモニタリングの重要性
皆様、おはようございます。本セッションへようこそ。エンドツーエンドのデジタルエクスペリエンスモニタリングのベストプラクティスについてお話しさせていただきます。私はImaya Kumar Jagannathanと申します。Observabilityを含むクラウドオペレーションを専門とするSpecialist Solution Architectsのチームを率いています。私はBobby Hallahanと申します。 AWSのSolution Architectを務めています。本日のアジェンダは、ベストプラクティスに焦点を当てた300レベルのセッションです。まず、モニタリングが重要である理由について簡単に説明し、共通の理解を得るためにデジタルエクスペリエンスモニタリングの定義を行います。その後、多岐にわたる内容になりますが、様々なベストプラクティスについて詳しく見ていきます。
今回は珍しく二人で登壇させていただきますので、うまくいくことを願っています。皆様にお聞きしたいのですが、このような状況を経験したことがある方は手を挙げていただけますでしょうか。ここにいらっしゃる方々の中には、Developer、DevOps Engineer、Architect、インフラのスペシャリストの方々がいらっしゃると思います。何か問題が発生してお客様と対面しなければならない時というのは、本当に大変ですよね。私が開発者だった頃を鮮明に覚えているのですが、社内のお客様が私のデスクの横に立って、私の作業を見ながら「いつ変更をプッシュするの？」と尋ねてきたことがありました。その時のことを思い出すだけでも身震いが出ます。お客様の立場からしても、壊れたWebサイトを見るのは好きではありません。何かを使う時は、ただ単純に動いてほしいだけなんです。
Bobby、あなたは以前TAMをされていましたよね。はい、AWSでのキャリアの初期にTechnical Account Managerを務めていました。ビジネスクリティカルな重要度の高いケースが発生してページングを受けた時、TAMとして直接コントロールできないことがあり、ビジネスクリティカルなシステムがダウンまたは機能が低下している状況で、お客様がとても不満を感じることがあります。それは誰もが避けたい、フラストレーションの溜まる経験です。だからこそ私はObservabilityの分野に特化することを決めました。お客様を支援する上で、プロアクティブに対応できる分野だと知っていたからです。
もちろん、私たち全員がモニタリングの重要性を理解しています。だからこそ、今日はこのテーマについて話し合うために集まっているわけです。当然のことながら、システム障害は組織に大きな損失をもたらします。短期的な金銭的影響もありますが、私の意見では、長期的な影響としてお客様との信頼関係や信用の喪失が最も深刻です。Webサイトが遅くてもたついている時、お客様はそのサイトを信用しなくなり、他のサイトを探しに行ってしまいます。 最近の調査によると、システム障害の3分の2以上が1件あたり10万ドルのコストを発生させており、このコストは増加傾向にあります。これは、銀行取引や航空券予約などの重要なユースケースでデジタルサービスへの依存度が高まっているためです。その結果、SLAの要求水準は上昇し、重要なサービスがダウンした際には規制機関が介入するようになり、障害時の組織的コストが更に増加することになります。
では、デジタルエクスペリエンスについて、私たちの考える定義を明確にしておきましょう。 デジタルエクスペリエンスとは、Webサイトやモバイルアプリケーション、API、チャット、ソーシャルメディアチャネル、その他のプラットフォームといったデジタルプロパティ上でのユーザーインタラクションを指します。 では、エンドツーエンドのデジタルエクスペリエンスモニタリングとは具体的に何を意味するのでしょうか？一般的に、RUMやSynthetics、そしてサーバーモニタリングだけでは必ずしも把握できないフロントエンドの体験を考えます。しかし、私たちはそのエンドツーエンドの部分も考慮に入れたいと考えています。これは、デジタルサービスやアプリケーションにおけるユーザーエクスペリエンスを追跡、分析、最適化するための包括的なアプローチなのです。
複雑化するデジタルエクスペリエンスの課題と顧客中心のアプローチ
典型的なユーザーリクエストのフローを見てみましょう。特別なものではありません - Webサイトがあり、ユーザーが使用しているブラウザがあり、リクエストはネットワークやインターネットを経由します。その後、ロードバランサーのある自社のネットワークに到達し、リクエストを処理するWebサーバー、そしてマイクロサービスなので複数のAPIがあります。複数の場所を経由してデータベースにたどり着くため、より複雑になっています。 これらの異なるレイヤーが重なると、さらに複雑さが増します。私たちが話している複雑さは、これらの複数のレイヤーが多言語環境を含んでいることから生じ、それが多くの障害ポイントを生み出します。多くの関係者が存在するため、単一の責任者による管理が難しく、可視性と全体的なコントロールが低下します。これは、時には第三者のソリューションを利用したり、自分たちが管理していないAPIのレスポンスタイムに完全に依存したりしているためです。
また、パフォーマンスへの期待値も様々で、それがさらに複雑さを増しています。 これが重要だということは分かっていますが、もし重要なら、なぜすべての人がこれを実施していないのでしょうか？なぜ誰にとっても完璧な状態になっていないのでしょうか？それは明らかに、いくつかの課題があるからです。
4、5年前にサポートしていたアプリケーションやシステムについて考えてみると、それらはもう少しシンプルだったかもしれません。今日でも、多くの場合、このようなモノリシックなアプリケーションを目にします。サービス指向アーキテクチャやマイクロサービスアーキテクチャに移行すると、 比較的急速に変化する可能性のある多くの下流の依存関係を持つことになります。デプロイの頻度は格段に上がり、異なるチームが様々な責任を持つことになります。アプリケーションを根本からマイクロサービス分散アプリケーションとして再設計する場合、Observabilityの実現方法も根本から見直す必要があります。
まず第一に、顧客はどのビジネスにおいても中心的な存在です。このセッションの準備をしているとき、数年前のJeff Bezosのインタビューを思い出しました。彼は非常に異なる視点を持っており、長期間にわたって変化しないものについて語っています。私たちはいつも、何が変化しているのか、次は何かということを考えがちですが、彼の視点は長期間変化しないものに焦点を当てています。 誰もJeff Bezosのところに行って、Amazonが他社より少し高く売ってほしいとは言わないでしょうし、配送をもっと遅くしてほしいとも言わないでしょう。
Observabilityのユースケースにおいて、長期間変化しないものは何かを考えてみました。 私は毎年何百もの顧客と会い、私のチーム全体では毎年何千もの顧客と1対1で会っています。しかし、CloudWatchやその他のサービスをもっと使いたい、もっと多くの時間を費やしたい、あるいはデバッグやRoot Causeの特定にもっと時間を費やしたいと言った顧客には、まだ一度も出会ったことがありません。誰もが、より低コストでMean Time To Resolutionを短縮できる、使いやすく設定が簡単で、さらに変化するニーズに合わせてスケールし適応できるサービスを求めているのです。
多くのAWSサービスにおいて、私たちは共有責任モデルをよく知っています。Lambda、RDS、EC2など、サービスによってAWSが担う管理レベルとお客様に提供する部分が変わってきます。Observabilityについても同様の考え方ができます。Observabilityの観点から見ると、私たちはAPI、SDK、使いやすいインターフェースを提供していますが、基本的にはログ、メトリクス、トレースデータといったデータストアレイヤーと、そのデータのクエリや取得機能を提供しています。一方、お客様側の責任としては、シグナルの選択、自動化、シグナルの強化、アラートの設定、計装があります。私たちは積極的なガイダンスや規範的なガイダンス、キュレーションされた体験を提供したいと考えていますが、最終的にはお客様が自身のアプリケーションを最もよく理解しているのです。
SLO設定とBurn Rateによるモニタリングの最適化
また、常に左シフトを心がけ、入力自体の最適化に焦点を当てる必要があります。監視対象と監視方法の選択に意図的に取り組んでいるお客様は、非常に成功を収めています。ノイズが少なくシグナルが多いため、運用コストが低く、問題をすばやく発見できるのです。ベストプラクティスのガイダンスとして、ワークフローを見てみましょう。私たちは、ビジネスから始めることをお勧めします。構築するものに関して、ビジネス側がSLAの観点で何を求めているのかを理解することから始めます。これから始めることで、アプリケーションやマイクロサービスを構築する理由を理解することができます。
具体例を見てみましょう。あるAPIがあり、そのSLAを明確にしたいとします。このAPIでは、リクエストの99%が200ミリ秒以内のレスポンスタイムであることが求められています。これは非常に明確で具体的な要件です。では、 これをどのように活用すればよいでしょうか？次のステップとして、 現実的な技術的能力に基づいたSLO（Service Level Objectives）を設定します。
開発を始めた時点で、現実的な技術的能力をどのように把握すればよいのでしょうか？最初は難しいかもしれませんが、業界標準から始めることをお勧めします。このプロセスを進めていくうちに、より正確で予測可能な数値が分かってくるはずです。このAPIの例で見てみましょう。 データベースの依存関係があることが分かりました。データベースについては、リクエストの97%が100ミリ秒以内であり、APIレスポンスの99.5%が200ミリ秒以内であることを期待しています。SLAよりも厳しい基準を設定していることがお分かりいただけると思います。これは、失敗の余地を持たせるためです。常に失敗しないものを作ることはできませんから、私たちは余裕を持って高い期待値を設定したいのです。
次に、SLOを追跡するための適切なSLIを特定する必要があります。これが実際のシグナル選択について話したい部分です。 実践的な例として、200ミリ秒以内に完了したAPIリクエストの割合を考えてみましょう。非常に過小評価されているMetric Mathを使用すれば、パーセンタイルランクのような指標を得ることができます。まだMetric Mathを試していない方は、ぜひ確認してみてください。データソースとしては、アプリケーションのAPMツールから取得でき、測定頻度は1時間ごとに継続的に行います。データベースの観点からは、100ミリ秒以内に完了したデータベースクエリの割合を考える必要があり、これは任意のデータベース監視ツールから取得できます。
今、SLIを手に入れました。2つのシグナルに対して、あるいは1つのアプリケーションに対してこれを行うのは簡単かもしれません。私たちは常にお客様と協力していますが、それが必ずしも課題というわけではありません。課題となるのは、Platform Engineeringチームにいて、1回ではなく何百回も、異なる環境、異なるアカウント、異なるワークロード、異なるデータベースエンジンで運用している多くのチームに対してこれを行わなければならない場合です。ここで紹介したい重要なベストプラクティスが4番目と5番目で、一貫した計装基準を設定し、収集エージェントの設定を標準化することです。
一貫した計装基準について話すとき、私たちは使用可能な計装基準を持つことを意味しています。これには、シグナルの強化、収集方法、そして他のアプリケーションチームがより効果的にアプリケーションを収集・計装できるようにすることが含まれます。中央のObservabilityグループとして、何を収集するかを指示できるようになり、人々に指示するのではなく、実行できるように支援することになります。このアプローチで成功を収めているお客様を何度も見てきました。
予算について考えるとき、エラー率やBurn Rateを考える必要があります。エラー予算とは、違反が発生するまでに失敗できるリクエスト数のことです。これは私たちが強調したいもう一つの重要なベストプラクティスです。SLOだけでなく、Burn Rateを見る必要があります。これはSLOに違反するまでの速度を示すもので、これを使用してBurn Rateにアラームを設定し、SLO違反が発生する前に問題を事前に検知しようとすることができます。
必ずしも非準拠状態やアラーム状態になるまで待つ必要はありません。 このリクエスト率とエラー率がこのまま続くと、今後20分程度でSLOに到達するだろうという前兆を見ることができます。つまり、これがSLOのしきい値で、それを設定して追跡し、その状況に基づいてアラートを受け取ることができます。例を見てみましょう。 このAPIの例では、月間500万件のAPIリクエストがあるとします。0.5%の余裕がある場合、基本的に合意されたSLAに到達できるリクエストは25,000件あることになります。
この期間を追跡するために、SLOしきい値アラームとBurn Rateアラームを設定します。これらは、現在の予算使用状況と月内の残り運用時間を追跡する上で重要です。これらのしきい値を継続的に超えたり失敗したりする場合、CoEセッションや各インシデント後に実施されるエラー修正会議で議論すべき問題があることを示しています。これらの議論にはすべての入力データを含めることを強く推奨します。
ブラウザからサーバーまでのエンドツーエンドモニタリング
ステップ2で説明した技術的能力に基づく現実的なSLOの設定について、しきい値の違反が頻繁に発生していることに気づいた場合は、何らかの変更が必要です。ビジネスチームと交渉してSLAを緩和するか、合意されたSLAを満たすために技術アーキテクチャの改善に取り組むことができます。これは、時間をかけて改良を重ねていく学習と反復のプロセスです。ステップ2により、運用がより予測可能で正確になり、より一貫した方法で運用できるようになります。
典型的なリクエストフローを、ブラウザから始めて見ていきましょう。ブラウザやモバイルアプリを通じた一般的なデジタルエクスペリエンスを考えるとき、まずブラウザから始めて、何が問題になり得るかを考えます。ブラウザを使用してデジタルアプリケーションを操作した経験がある人なら、誰もがパフォーマンスの問題に遭遇したことがあるでしょう。これを説明するために、フラワーショップの簡単なデモを用意しました。サイトにログインしてみて、何が起こるか観察してみましょう。ログインした後、画像の読み込みに時間がかかり、一部のボタンが読み込まれず、画像が表示されないといった状況が確認できます。
これらの問題は、サーバーサイドの計測だけでは必ずしも検出できず、一般的に2つのカテゴリーに分類されます。まず、パフォーマンスへの影響があります：ネットワークの問題やコンテンツが大きすぎることによる遅いページ読み込み。CSSアセットが読み込めないなどの静的コンテンツの問題でサイトの見た目が悪くなることもあります。JavaScriptのエラーは機能の問題を引き起こす可能性があります。しかし、デジタルエクスペリエンスは速度だけの問題ではありません。インターフェースデザイン、デバイスの互換性、アクセシビリティなど、ユーザーエクスペリエンスの課題も考慮する必要があります。多くの人がスクリーンリーダーなどの支援ツールを使ってデジタルプラットフォームを利用しているため、アクセシビリティは非常に重要です。コンテンツのアクセシビリティを確保することは絶対に不可欠です。
メトリクスについて、重要な測定項目をいくつか見ていきましょう。Web Core Vitalsについては、Largest Contentful Paintが2.5秒、Interaction to Next Paintが200ミリ秒、Cumulative Layout Shiftが0.1というベンチマークがあります。フロントエンドのデジタルエクスペリエンスを検証する際には、これらのWeb Core Vitalsを追跡できるツールが必要です。その他の重要なメトリクスには、ナビゲーションのフラストレーション、満足、許容できるトランザクション、HTTPステータスコードの数、JavaScriptエラーの数などがあります。これらのメトリクスは、サイト全体のパフォーマンスを評価するのに役立ちます。
CloudWatchサービスには、CloudWatch RUM（Real User Monitoring）やCloudWatch Syntheticsなどのツールが用意されています。ImayaがCloudWatch RUMについて説明し、いくつかのベストプラクティスを共有してくれる予定です。
CloudWatch RUMとSyntheticsによるフロントエンド監視
CloudWatch RUMはとてもシンプルです。 RUMアプリケーションと呼ばれるものを作成すると、Webサイトに組み込めるJavaScriptが提供されます。このJavaScriptを組み込むと、 RUMは様々な種類の情報の収集を開始します。まず、ナビゲーションイベントを追跡します。これにより、ユーザーがどのページを訪問し、どのような経路で決済ページにたどり着くかなど、Webサイト上でのユーザーの行動を把握できます。本来ならもっと長く滞在してほしいページからユーザーが離脱してしまう場合など、こうした情報は、プロダクトマネージャーやUXデザイナーがより良いカスタマーエクスペリエンスを設計する上で、非常に有益な洞察を提供します。
次に、JavaScriptとHTTPエラーについてです。先ほどのデモでは、画像の1つが読み込めませんでしたが、この機能を有効にしていれば、そのHTTPエラーやJavaScriptエラーを検出できたはずです。また、クライアントサイドのパフォーマンス指標も取得できます。同じデモで、いくつかのボタンの読み込みに時間がかかっていましたが、これはページがユーザーの操作に対応できる状態になっていなかったことを意味します。つまり、HTML DOMがブラウザでのユーザー操作を許可できる状態になっていなかったのです。Webサイトは素早く読み込まれ、ユーザーがすぐに操作できる状態であるべきなので、これは問題です。
有効にすると、CloudWatchはこれらの情報をすべて収集し、CloudWatchに送信します。そこには、ユーザーのナビゲーションを確認し、ユーザーがWebサイトをどのように使用しているかを理解するための使いやすいインターフェースがあります。 CloudWatch内で、RUM関連のすべての操作を1つのインターフェースで行うことができます。このデータはCloudWatch MetricsとCloudWatch Logsでも利用可能で、アラートを設定することもできます。SLIを設定してアラートを作成したり、CloudWatch Logsをクエリしたりできます。CloudWatch Metricsで異常検知を設定して、問題を引き起こす異常な状況がないかを確認することもできます。また、標準で提供されていない指標が必要な場合は、CloudWatch Logsのメトリクスフィルター機能を使用して、任意のディメンションで新しい指標を抽出することができるので、この機能の活用を強くお勧めします。
CloudWatch RUMを使用する際のベストプラクティスについてお話ししましょう。 まず、現実的なサンプリング設定から始めます。デフォルトでは、CloudWatch RUMはコストを抑え、過剰な情報を避けるためにユーザーリクエストをサンプリングします。必要に応じてサンプリング率を上げることもできますが、それによってコストが増加し、処理すべき情報も増える可能性があることを覚えておいてください。各ページイベントやユーザーインタラクションにX-Rayトレースを含めると、X-RayトレースIDが関連付けられます。これにより、ユーザーのリクエストとパスだけでなく、どの特定のリクエストがページに到達し、他のどのサービスが影響を受けたかを確認できます。Webフロントエンド部分と、Webサイトが他のシステムとやり取りするすべてのサービス間の相互作用の両方を見ることができ、これはトラブルシューティングに非常に役立ちます。
Cookieを有効にすると、セッションとユーザーの2種類のCookieがあります。有効にすると、セッションIDとユーザーIDを取得して、何人のユーザーが訪問しているか、頻繁に再訪問しているかを追跡できます。最後に、これは全か無かの選択ではありません。必要なテレメトリーを選んで使用できます。例えば、WebサイトがSPAアプリケーションの場合、ページナビゲーションは最も重要な指標ではなく、ユーザーインタラクションのためのDOMの準備状態の方が重要かもしれません。その場合、ページナビゲーションイベントを無視して、JavaScriptエラーとクライアントサイドのパフォーマンス指標だけを選択することができます。これらの機能の活用を、お客様に強くお勧めしています。
ネットワークモニタリングとApplication Signalsの活用
Imayaさん、ありがとうございます。 CloudWatch Syntheticsについてお話ししましょう。実際のユーザーが多く、トラフィックが高い場合、RUMは素晴らしく機能し、ユーザーの行動を理解するのに役立ちます。しかし、特定のAPIやワークフローが正常に動作するかを確認したい場合や、特定のデバイスやデバイスタイプが適切に機能することを確認したい場合があります。そういった場合にSyntheticsが非常に有用です。これは合成テストを行うもので、基本的にPuppeteerやSeleniumレイヤーを備えたLambdaを使用します。SyntheticsはPuppeteerやSeleniumを使用してそれらのLambda関数の実行をオーケストレーションします。
具体的には、CloudWatch Syntheticsは、PuppeteerまたはSeleniumを使用してLambda関数の実行をオーケストレーションし、ヘッドレスのChromeブラウザをセットアップし、リクエストを行い、CloudWatchメトリクスを通じてデータを送信します。セッションのスクリーンショットを撮影し、HTTPアーカイブファイルを取得します。データはCloudWatchのログとメトリクスに送信され、それに基づいてアラームを設定できます。これらのメトリクスは、合成Canaryの全体的な実行だけでなく、各ステップごとに基づいて設定できます。
Syntheticsのベストプラクティスについて考えると、最も重要なのは、これをヘルスチェックとして使用しないことです。 HTTP 200が返ってくるかどうか、またはTLSハンドシェイクが機能するかどうかを確認するだけのヘルスチェックを行いたい場合は、Route 53ヘルスチェックを使用してください。これは8つの異なる場所から毎分複数回チェックを実行し、より安価です。Route 53ヘルスチェックができないのは、ユーザーとしてログインして特定のワークフローを実行するような作業です。すべての静的アセットを読み込んで保存できるヘッダー情報を提供することもできません。Syntheticsは単なるヘルスチェック以上の強力なツールだと考えてください。
グループとSyntheticのセットアップを活用して、グループ内に合成Canaryを作成し、異なるアプリケーションセット間や複数のステップフェーズ内でタスクを整理して実行できるようにします。複数のステップで使用することが重要です。ウェブサイトにアクセスするだけでなく、ウェブサイトにアクセスしてログインし、商品をカートに追加して、チェックアウトするまでの一連のワークフローとして使用します。顧客の中には、Canaryに何百ものステップを追加している例も見てきました。Syntheticsは Canaryの実行ごとに料金が発生するため、複数のステップを活用することでコスト効率を高める創造的な方法があります。LambdaはすべてのAWS APIにアクセスできるため、Secrets Managerを使用してください。これにより、サンプルユーザーの認証情報をLambda関数に直接記述するのではなく、安全に保存できます。PuppeteerとSeleniumに慣れていない場合は、ブループリントを使用することをお勧めします。私たちには、始めるのに役立つ多くのブループリントがあります。
では、次のレイヤーを見てみましょう。ブラウザを確認しましたが、ここではインターネットとして分類されているものについて考えてみましょう。ブラウザと最初のエンドポイントの間で何が起こるのか、そしてネットワーク内のどこでパフォーマンスの問題が発生する可能性があるのかを考える必要があります。全体的なインターネットアプリケーションの接続性やVPC内の事項について検討しています。インターネットの健全性の問題を示し、それらの問題が特定の方法でユーザーに影響を与えているかどうかを示すマップがあれば素晴らしいと思いませんか？ これは、CloudWatch Internet Monitorで実現可能です。
CloudWatch Internet Monitorは、現在進行中のインターネットの問題や状況を示すマップを提供します。Internet MonitorはCloudFrontログやVPC Flow Logsと連携して使用できるため、アプリケーションやエンドユーザーが特定のイベントの影響を受けているかどうかを把握することができます。ヘルスイベントのタイムラインを提供し、特定のリージョンでのレイテンシーの低下を検知することができます。トラフィックの大部分がどこから発生しているかを確認し、より最適なリージョンやCloudFrontやGlobal Acceleratorなどのソリューションを提案することができます。可用性とパフォーマンススコアを含むトラフィックの概要や、重要なポイントとして、ユーザーリクエストがどの都市から来ているかを正確に示す都市別・目的地別のトラフィック情報を提供します。
インターネットのモニタリングの先には、アプリケーション内で何が起きているかを考える必要があります。つい数日前、私たちはCloudWatch Network MonitoringまたはNetwork Flow Monitorをローンチしました。これはAWSワークロードのネットワークパフォーマンスに関する詳細な洞察を提供します。ワークロードにインストールできるeBPFエージェントを使用し、サービスからの追加のテレメトリと組み合わせることで、AWS Supportにヘルスイベントを送信してトラブルシューティングを加速し、ネットワークヘルスのモニタリングにより積極的なアプローチを可能にします。ネットワークワークロードをモニタリングし、ネットワーク上のレイテンシーと損失を理解するためにネットワーク起因の影響を評価できる一方で、皆さんの共感を得られそうな機能の1つは、AWSからの影響を特定できることです。何か問題が起きているとき、それがAWSによるものなのか、それとも他の要因なのかと悩んだ経験はありませんか？
お客様はこのような状況を頻繁に経験されており、このソリューションはそのネットワークの影響がどこにあり、パフォーマンス低下の原因が何であるかを理解するのに役立つように作られています。これは、ネットワークとコンピュートのワークロードメトリクスを収集する管理されたエージェントを通じて機能します。eBPFを使用したパッシブモニタリングで、さらにTCP検査を実行します。AWSネットワークインフラストラクチャからは追加のメトリクスを収集し、それらを相関的に構築して、CloudWatchメトリクスを通じて確認することができます。
ここで特に興味深いのは、これまでテレメトリ収集のためのeBPFエージェントを持っていなかったことで、これ自体が注目に値します。この新機能の先には、VPC内で確認すべき重要な事項を提供する他のVPCテレメトリソースについても考慮する必要があります。Traffic Mirroring、Reachability Analyzer、その他のCloudWatchメトリクス、VPC Flow Logsがあります。ベストプラクティスに入る前に、どのようなシグナルが利用可能かを検討する必要があります。これはネットワークだけでなく、あらゆるタイプのアプリケーションやモニタリングの状況に当てはまります - 利用可能なシグナルが何であり、それらがSLOを定義するためのニーズを満たしているかどうかを考慮する必要があります。
それではベストプラクティスについて話しましょう。Internet Monitorを使用していない場合は、有効にして確認することをお勧めします。また、VPC Flow Logsを可視化することも重要です - 方法は問いませんが、とにかく可視化してください。CloudWatch LogsとのOpenSearch機能統合で、VPC Flow Logs用の新しい規定のダッシュボードを構築しました。Contributor Insightsを使用したり、VPC Flow LogsをS3に送信してAthenaやQuickSightで作業したりすることもできます。また、多くのObservabilityパートナーがいるので、サードパーティプロバイダーに送信することもできます。そしてもちろん、Network Flow Monitorエージェントを使用してください - これらのパッシブリスナーは不可欠です。
Generative AIワークロードのモニタリング戦略
そこから、単なるネットワーキングを超えて次のレベルに進みたいと思います。それは、ELBとWebサーバーのアプリケーションとインフラストラクチャーです。ここで、私たちがいつも問いかける基本的な質問に立ち返ってみましょう：ワークロードの健全性をどのように理解すればよいのでしょうか？これは、AWS Well-Architected Frameworkの中でも、私が特に好きなCost Optimizationと並んで重要なOperational Excellenceの柱における質問8から来ています。ワークロードの健全性を理解する際、私がお客様に最初に尋ねるのは、SLOを設定しているかどうかということです。
Amazon CloudWatch Application Signalsでは、ベストプラクティスに基づいたサービスオペレーターのダッシュボードを提供するようになりました。これにより、ゴールデンアプリケーションメトリクスとService Level Objectivesが得られます。以前のCloudWatchでは、毎分評価される単純なメトリクスとアラームしかなく、SLOの実装が困難でした。Application Signalsを使えば、SLOやSLIの作成が可能になり、達成度やその他の関連機能も利用できます。
仕組みを説明しましょう。Application Signalsの外にSLOを配置している理由は、CloudWatch内のどのメトリクスに対してもSLOを作成できるからです。つまり、Application Signalsから得られるデータである必要はありません。カスタムメトリクスでもAWSネームスペースのメトリクスでも、追加の計装なしで今お使いのどのメトリクスでもSLOに使用できます。これらのSLOデータ、トレース、メトリクス、ログ、RUMデータ、そしてSyntheticsのデータを取り込んで、SLOダッシュボード、サービスダッシュボード、サービス診断、そしてサービスマップを構築します。
シグナル収集に関して、Application SignalsはOpenTelemetryと互換性があります。AWS Distro for OpenTelemetryはこれを実装する良い方法で、CloudWatchエージェントやOTELコレクターも使用できます。これは、もう一つの新機能であるOTLPエンドポイントのサポートと組み合わせると特に価値があります。X-Rayが新たにOpenTelemetryエンドポイントを備え、OpenTelemetryを直接送信できるようになりました。
OpenTelemetry ProtocolからX-Ray形式への変換を行わなくても、X-Rayに直接送信できるようになりました。さらに、CloudWatchログに埋め込みメトリクス形式で送信することもでき、そこからApplication Signalsにデータを送ることができます。これにより、すべてのX-Rayトレースをアプリケーションシグナルに変換できます。つまり、ボタンを押すだけで、すべてのトレーススパンなどがCloudWatchログとApplication Signalsに送られるため、このサービスの導入障壁が大幅に下がったということです。さらに重要な利点として、より低いレートで課金されるため、このやり方の方がコスト効率が良いのです。
Application Signalsで対応しているものをご紹介します。Amazon EC2、AWS Lambda、Amazon Bedrock などがあります。今日、アプリケーションでBedrockを使って生成AIを活用している方はいらっしゃいますか？何人かいらっしゃいますね。素晴らしいです。Bedrockのネイティブ統合、Amazon EKSでのネイティブなKubernetesサポート、そしてAmazon ECSもサポートしています。対応言語については、Java、Python、.NET 、そして現在プレビュー段階のNode.jsがあります。覚えておいていただきたいのは、OpenTelemetryと互換性のあるものは全て対応しているということです。つまり、OpenTelemetryに対応しているものは基本的に使えると考えてよいでしょう。
では、Application Signalsで何ができるのでしょうか？先ほど触れたように、RUMとSyntheticsのデータを確認したり、問題が発生した際に、その特定の問題や時系列に関連するトレーススパンを相関的に確認したりすることができます。SLOやSLIを定義することもできます。先ほど重要な機能として触れたバーンレートメトリクスの設定も可能です。依存関係の確認やサービスマップの表示もできます。これは実質的な運用者向けダッシュボードであり、サービスの健全性を理解するための手段です。ワークロードやサービスの健全性について質問された時、Application Signalsを使っていれば、簡単に答えることができます。
ベストプラクティスとしては、X-Rayのエンドポイントを介したOpenTelemetryのサポートを確認し、トレーススパン分析を試してみることをお勧めします。数日前にデモアカウントで試してみましたが、その機能に驚かされました。メトリクスではなくSLOでアラームを設定し、バーンレートに基づいてアラームを設定しましょう。これにより、プロアクティブな対応が可能になります。自動計装を活用しましょう。これは味方になってくれて、作業を大幅に簡単にしてくれます。自動計装で多くの価値が得られます。そして、どんなことでも同じですが、繰り返し改善することが大切です。SLOについては現実的なアプローチが必要で、それを繰り返し改善していくことが一般的なベストプラクティスです。
最後に、もう一つよく見かける課題に対応したいと思います：10、20、30、40、50、あるいは100のアプリケーションがある場合、どのように管理すればよいのでしょうか？テレメトリーにギャップがないかどうかをどうやって知ることができるでしょうか？今回、私たちが追加したのがテレメトリー設定で、これによってどのシグナルがあり、どれが実際にデータを提供しているか、そしてどこにギャップがあるかの概要を把握できます。例えば、詳細モニタリングが有効になっているか、どこで有効になっていないか、ロギングはどうなっているかなど、より高いレベルでギャップを確認することができます。
ここから私が引き継ぎます。実はこれはとても素晴らしい機能です。お客様からよく聞かれる質問の一つが、「EC2インスタンスが実際にメトリクスを送信しているかどうかをどうやって確認できるのか」「本当にEC2インスタンスからメトリクスを収集できているのか」というものです。このテレメトリー設定は、カバレッジを確認する優れた方法です。デモを続けましょう。同じウェブサイトには、生成AIを活用したボットがユーザーをサポートするために配置されています。今日どのように支援できるかを尋ねると、ボットは確認と評価を行い、突然エラーを返してきました。おそらくネットワークの問題か、Bedrockエージェントが通信しているAPIが機能していないか、あるいはAPIに問題があるのかもしれません。もしかしたらBedrockの前にある別のファサードレイヤーが機能していない可能性もあります。ユーザーがボットに開示してはいけない情報を明かすよう仕向けようとしていることを察知し - これはプロンプトインジェクション攻撃と呼ばれ、生成モデルやチャットボットが開示すべきでない情報を引き出そうとする攻撃です - ボットはすぐに質問に答えられないと返答しました。ここでは2つのことが起きました：ボットが質問に応答しなかったことによるエラーと、ボットが潜在的な攻撃から自身を守ることに成功したということです。これがモニタリングにつながっていきます。
データベースパフォーマンスの包括的な監視とDatabase Insightsの活用
Amazon Bedrock を利用した Generative AI の例を見ていきましょう。このようなワークロードを監視する方法にはどのようなものがあるでしょうか？
Generative AI 環境には一般的に3つのレイヤーがあります：基盤となるインフラストラクチャ、サービス自体、そしてアプリケーションです。多くのユースケースでは、Amazon Bedrock が提供する Large Language Model をそのまま使用することに魅力を感じるかもしれません。しかし、企業によっては既存のモデルを使用したくない場合もあります。Large Language Model が大きすぎたり、運用コストが高すぎたりする場合に、独自のモデルを構築したい、モデルのトレーニングや Fine-tuning を行いたいというケースです。データの機密性の観点から、他のデータで学習されたものを信頼せず、自社のデータで学習させることを望むかもしれません。
そのため、独自のモデルを構築し、オンラインの推論のためにランタイムでホストします。これは、モデルのトレーニング、構築、Fine-tuning、オンライン推論に使用しているインフラストラクチャのパフォーマンスを監視する必要があることを意味します。これは通常、NVIDIA GPU ベースのインスタンスなどの GPU インスタンスで行われます。Amazon EKS 上でこれを行う場合、CloudWatch Container Insights を使用して GDGCM メトリクスを使用した GPU ベースのインスタンスのモニタリングが可能です。また、Neuron コンテナを使用したトレーニングおよび推論インスタンスでメトリクスをエクスポートすることもできます。 モデルトレーニングが複雑で、大規模に異なるノードに分散している場合、ネットワークや EFA（Elastic Fabric Adapter）メトリクスを含む複数のノードが関与しますが、これらはすべて Container Insights で自動的に収集され、利用可能になります。
次のレベルは Generative AI サービスです。Amazon Bedrock について言えば、多くのメトリクスとログを自動的に CloudWatch に送信します。これを積極的に活用することを強くお勧めします。アプリケーションワークロードについては、Bobby が説明したように、Application Signals を有効にするだけで、環境からメトリクス、ログ、トレースを収集できます。あとは、これらのデータをすべて組み合わせて意味のあるものにしていくだけです。
Generative AI モニタリングの主要な SLO をいくつか見てみましょう。モデルの呼び出しレイテンシー（実行にかかる時間）、特にトークン使用量とコストに関するモデルのパフォーマンスを見ています。多くの Generative AI ツールは通常トークン使用量に基づいて課金されるため、これを追跡することは重要です。インフラストラクチャのキャパシティ監視は言うまでもありません。データのセキュリティと整合性を確保し、コンテンツの品質と関連性、つまりプロンプトに対して質の高い関連性のある回答を提供していることを確認する必要があります。最後はモデルのパフォーマンス比較です。Amazon Bedrock では、さまざまなモデルを選択し、それらのモデルに異なるパラメータを設定できるため、必要なものを選択的に取得できます。適切な用途に適切なモデルを選択することで、大きなコスト削減につながる可能性があります。
この環境からのシグナルに注意を払う必要があります。Amazon Bedrockのモデル呼び出しシグナルについては、モデルのランタイムメトリクスやモデル呼び出しメトリクスがあり、モデルの呼び出しから応答までにかかる時間を示してくれます。これは標準で利用可能な重要なモデルパフォーマンスメトリクスです。また、Amazon Bedrockのガードレールメトリクスもあります。先ほどのデモでは、ボットがPrompt injectionアタックから自身を守ることに成功しましたが、これはエージェントに設定されたガードレールによるもので、リクエストを素早く拒否することができました。
Amazon Bedrockのナレッジベースログも非常に重要です。お客様がこのようなシステムを構築する際、モデルが企業データから情報を取得できるようにしたいと考え、RAGなどのアプローチを使用することがあります。これは、誤った情報を提供しないように、ナレッジベースを定期的に更新する必要があることを意味します。通常、ナレッジベースを定期的に更新するためのパイプラインを設定し、これも標準で利用可能なモニタリング対象となります。
ナレッジベースのモニタリングに加えて、セキュリティ目的でAmazon BedrockエージェントのAPIコールと、誰がそれを呼び出しているかを追跡する必要があります。 Amazon Bedrockのガードレールのモニタリングに関して、データセキュリティはどの組織でも重要ですが、特にGenerative AIワークロードではより重要です。Prompt injectionアタックやモデルセキュリティ違反などを事前に検出できるようにして、監査やレポートの要件に準拠しながら対策を講じることができます。これにより、ナレッジベースの強制更新やガードレールメカニズムへの条件追加など、自動修復アクションを実装することが可能になります。
ガードレールのパフォーマンスをモニタリングする際には、いくつかの重要なメトリクスに注目する必要があります。これには、InvocationLatency、InvocationThrottles、InvocationServerErrors、InvocationClientErrors、InvocationsIntervenedが含まれます。最後のメトリクスは特に重要で、不審なアクティビティや不適切なクエリによってガードレールが呼び出しに介入した場合を示します。
仕組みについて説明しましょう。先ほど述べたように、Amazon Bedrockはモデルパフォーマンス、ナレッジベースメトリクス、ログ、ガードレールシグナルに関する多くのメトリクスを提供します。これがGenerative AIレイヤーを形成し、その上にアプリケーションやインフラストラクチャ環境があります。Amazon ECSを使用している場合、アプリケーションシグナルやCloudWatch Container Insightsを有効にして、インフラストラクチャとアプリケーションレベルの情報を取得できます。これらの情報はすべてAmazon CloudWatchに流れ込み、コンテキスト、クエリ、可視化、アラートのための一元化された場所を提供します。
デモでは、ユーザーがアプリケーションの使用を続け、特定の注文や商品を選択しようとしましたが、エラーが発生してしまいました。 ユーザーはフラストレーションを感じ、商品の検索を試みることにしました。 検索したい商品名を入力してSearch buttonをクリックすると、エラーが表示されました。これは先ほど説明したように、APIの問題やネットワークの問題、あるいはWebサイトの人気が高すぎてデータベースに負荷がかかり、適切なインデックスが設定されていないために処理できない、といったさまざまな理由が考えられます。
データベースの問題を特定する際には、いくつかの課題があります。高速に動作する必要があるクエリのパフォーマンス、複数のユーザーが同じ行に書き込もうとする際のユーザー競合、キャパシティの制限、データベースチューニングに関する設定の問題などです。特に重要な点は、アプリケーションの問題とデータベースの問題の相関関係を把握することです。多くの場合、チームが分かれていて効果的なコミュニケーションが取れないため、データベースの問題が下流のアプリケーションにどのような影響を与えるのか、またその逆の関係を理解することが難しくなっています。
データベースのService Level Objectives（SLOs）を考える際には、レイテンシー、エラー率、可用性、スループットといった主要なメトリクスに注目します。さらに、データの永続性と一貫性も考慮する必要があります。これには、Eventually Consistentモデルを使用しているか、クロスリージョンの書き込みを実装しているか、あるいはAmazon S3のようなRead-after-Write Consistencyモデルを使用しているかを理解することも含まれます。スケーラビリティも監視すべき重要なSLOの一つです。
データベースの監視には、2種類のシグナルを考慮する必要があります。1つ目は、基盤となるオペレーティングシステムとインフラストラクチャからのシグナル、2つ目は、データベースエンジン自体からのシグナルで、データベース内で何が起きているかを示すものです。 Enhanced Monitoringを有効にすることを強くお勧めします。これにより、基盤となる環境から多くのシグナルを取得できます。
Aurora RDSの場合、これらのシグナルにはCPU使用率、ファイルシステム、メモリ、ネットワーク、その他の一般的な監視データが含まれます。この情報は自動的にCloudWatch Logsに公開され、3ヶ月間保持されます（必要に応じて延長可能です）。追加のメトリクスを抽出したい場合は、Metric FiltersやCloudWatch Contributor Insightsの使用を強くお勧めします。これらを使用することで、ログ情報に基づいてTop-Nレポートを作成し、常に最新の状態に保つことができます。
データベースのシグナルについては、Performance Insightsを有効にすることをお勧めします。Performance Insightsを使用すると、クエリ情報、トランザクション、デッドロックなどのデータベースに関する情報を取得できます。これにより、データベースエンジンのパフォーマンス自体について詳細な洞察が得られ、RDSコンソールから確認することができます。これらの情報をすべて確認でき、さらにCloudWatchに追加することで、より簡単な分析のためにすべてのデータを1つのビューにまとめることができます。
現在、新機能としてCloudWatch Database Insightsがあります。これはワンクリックで利用できる完全マネージド型のソリューションで、手間やメンテナンスの問題がありません。ログ、メトリクス、トレースデータを1か所で統合表示し、データベース固有のルートコースエラーや、アプリケーションとデータベース間の依存関係マッピングを提供することを目的としています。多くのお客様が苦労している問題を解決しました。1つのデータベースだけでなく、数十、数百、数千のデータベースを扱う場合にも対応できるように設計されています。
この機能は2日前にリリースされたばかりですが、有効にすると、Aurora、PostgreSQL、MySQLデータベースの全フリートの完全なビューが得られます。具体的に何が見えるのか見てみましょう。ハニカムビューで可視化され、右側にはDBロードと使用率に基づくトップ10のインスタンスが表示され、データベースがどこでどの程度使用されているかが分かります。データベースから発生するイベントや、CPUの使用率などの異なるパラメータに基づくトップ10のレポートも確認できます。
最も興味深いのは、もはやデータベースだけの話ではないということです。Database Insightsを有効にし、これらのデータベースを使用しているアプリケーションでApplication Signalsが有効になっている場合、Database Insightsコンソール内で、どの特定のサービスがデータベースにコールを行っているかが実際に表示されます。クリックすると、すべて完全にディープリンクされています。Application Signalsを使用すると、データベースの観点から、情報、Synthetics、依存サービスを含む特定のサービスのパフォーマンスを確認できます。
アプリケーション層に問題がなく、インフラストラクチャの問題かもしれません。この場合、このアプリケーションが特定のサービス上のEKSクラスターでホストされていることが分かります。そのサービスもここにリストアップされ、ディープリンクされています。クリックするだけで、Container Insightsコンソールに移動し、すべてのPodのパフォーマンス、サービスのパフォーマンス、その他の詳細を確認できます。データベースから始まり、アプリケーション、インフラストラクチャへと移動でき、逆方向も同様に可能です。
このナビゲーションでは、クエリを書いたり、長いグループ名やメトリクスを覚えたりする必要はありません。複雑な結合クエリを考える必要もありません。すべての機能が標準で提供されており、CloudWatchは問題の可能性がある箇所を把握できるよう、コンテキストを意識した表示を増やしています。仕組みはシンプルです。先ほど説明したように、これらの環境からDatabase Insightsを有効にすると、メトリクスとログがCloudWatchに収集されます。Application SignalsやECSを有効にすると、すべてのデータが1つのインターフェースに集約されます。Logs Insightsを使用してクエリを実行することも、約1週間前にリリースされた新機能であるSQLやOpenSearchベースのクエリを使用することもできます。
これらのクエリ言語により、お好みのPLクエリ言語を使用することができます。
ベストプラクティスとしては、環境から詳細な情報を得るために連携して機能するPerformance InsightsとDatabase Insightsの有効化をお勧めします。オペレーティングシステムレベルの監視にはEnhanced Monitoringを有効にしてください。繰り返し強調していますが、バーンレートとSLOのしきい値にアラームを設定してください。まず、パフォーマンスメトリクスを追跡するためのSLOを確立します。さらに、多くの方が十分に認識していない重要な機能として、RDSのDB InsightsでPerformance Insightsを有効にすると、Performance Insightsのメトリクスにアラームを設定できます。CloudWatchには、Contributor Insightsのような他の機能でも同様の機能があり、CloudWatchにまだ公開されていないメトリクスに対してもアラームを設定できます。
エンドツーエンドモニタリングのベストプラクティスと今後の展望
今日は、ブラウザからデータストアレイヤーまで、かなり広範な内容をカバーしてきました。ここで重要なポイントをまとめましょう。これまで強調してきたように、SLOを定義し、あらゆるものを計測することが大切です。計測可能なすべてのレイヤーで、何らかの形で計測を行う必要があります。計測がなければ、システムの健全性を理解するためのシグナルが得られません。
次のポイントは非常に重要です。なぜなら、たとえすべての場所で計測を行っても、相関関係がなければ、それは単なる関連性のないシグナルの集まりに過ぎないからです。多くのお客様がこの問題で苦労していますが、私たちは分散トレーシングを活用してこれに対処しています。そのため、RUMのベストプラクティスとしてX-Rayの有効化を強調しているのです。これにより、アプリケーション全体にわたるエンドツーエンドの分散トレースが提供され、コンテキストを保持することができます。SLI、SLO、自動化されたアクション、バーンレートにアラームを設定し、継続的に改善を重ねていきましょう。
Well-Architected Frameworkを通じて、この考え方が随所に出てきます。Observabilityは目的地ではなく、旅のようなものなのです。ビジネスオーナーやアプリケーションチームと協力して、収集しているシグナルがワークロードに関連し、それを適切に表現しているものであることを確認することが重要です。このような議論は、実際にはあまり頻繁には行われていません。
実践的な経験を積みたい方は、AWSアカウントチームを通じてOne Observability Workshopをご確認ください。担当者が分からない場合は、お問い合わせいただければ、このワークショップの設定をお手伝いさせていただきます。これまで参照してきたベストプラクティスのサイトには、私やImayaを含む多くのテクニカルフィールドの貢献者からの情報が掲載されており、今日お話しできた内容をはるかに超える情報が含まれています。トレーニングリソースとしては、Observability AcceleratorやSkill Builderをご活用ください。
本日は皆様、お時間をいただき、ありがとうございました。素晴らしいカンファレンスになりますように。セッションのアンケートにもぜひご協力ください。質疑応答のため、私たちは前方で待機しています。部屋から退出するよう指示があった後も、廊下で引き続きディスカッションができます。最後に一点、Venetianのブースにもぜひお立ち寄りください。本日遅めの時間に伺って、質問にお答えできればと思っています。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion