こんにちは、MSP の田所です。

AWS re:Invent 2024 が盛り上がっていますね！
現場からイベント模様をお届けします。

セッション情報

Best practices for end-to-end digital experience monitoring

CloudWatch でデジタル体験をまるっと見守りましょう！

Gain full-stack visibility into application performance, from the internet down to your services. In this session, learn how AWS digital experience monitoring combines network and internet monitoring with user experience tracking to provide an outside-in view across all touchpoints. Understand how monitoring real user interactions, synthetic traffic, internet service provider data, and backend infrastructure metrics reveals a complete picture of frontend performance, user behavior, API efficiency, and potential failure points. See how correlating these insights allows you to turn end-to-end digital experience into actionable KPIs like release velocity, adoption rates, conversions, and availability for enhancing customer experiences.

ネットワーク、ユーザー体験からインフラまで、まるっと監視して、より良いサービスにする手助けをします！

Session types: Breakout session

1時間の Breakout セッション

今回のまとめ

  • デジタル体験はブラウザからデータベースまでいくつもの階層がある
  • CloudWatch にはそれぞれの階層を監視できる機能がある
  • 生成 AI の稼動環境では特に押さえておきたいシグナルがある

セッションの詳細

1. デジタルエクスペリエンスを見守るということ

近年 IT 技術の利用はもはや企業の前提となっており、Web サイトのダウンタイムが売上や信頼の低下に直結するようになっています。
通販サイトでは何かトラブルがあった際の離脱のスピードが速まっており、安定稼動がますます重要になってきています。

デジタルエクスペリエンスとは、Webサイトやアプリなど、顧客がデジタル資産にアクセスしている際の体験のことです。

典型的なユーザーリクエストは以下の流れを辿ります。

  • ブラウザ
  • インターネット
  • ロードバランサー
  • ウェブサーバー
  • API
  • データベース

そしてシステムの形は進化しているため、デジタルエクスペリエンスの情報を追う難易度も上がっています。

オブザーバビリティはシステムの状態を把握する能力のことですが、実装や運用するにあたり、簡単で低コストで効果が高い方が良いのは言うまでもありません。

今回、CloudWatch でユーザーリクエストの端から端までデータを取ることができるという話です。

2. CloudWatch で実現するオブザーバビリティ

端から端までデータを取れる CloudWatch の機能を簡単にご紹介します。

① RUM（ユーザー体験）

ユーザーがサービスを利用した時のパフォーマンスデータを収集します。
どの処理にどのくらい時間がかかったかを可視化することができます。
X-Ray トレースを有効化してデータを統合することが推奨されています。

 

② Synthetics（ブラウザ）

ブラウザでの操作を再現して動作確認を行います。
URL のレスポンスコードを確認するだけのヘルスチェックにも使えますが、ウェブページ内の表記をチェックする、ボタンを押す、文字を入力する、などステップを組み合わせて、ユーザーの動作に近いスクリプトにすることが推奨されています。

 

③ Internet Monitor（インターネット）

パブリックなインターネットの遅延状況を確かめたり、サービスに対するトラフィックの分析を行います。
コンソールではインターネット天気図と呼ばれる、世界各国のインターネットの遅延状況を示した地図や、サービスへのトラフィック数やその遅延情報を国やリージョンごとに集計したランキングなどを確認できます。

 

④ Network Monitoring（ネットワーク）

AWS 内のネットワークや、AWS とオンプレミスのワークロード間のネットワークパフォーマンスを評価します。
昨年発表された比較的新しい機能です。
エージェントのインストールなしで利用可能です。

 

⑤ Application Signals（アプリケーション）

サービス同士の関係性の可視化や、SLO の管理を行えます。
図にあるように、メトリクス、ログ、トレースから、SLO、RUM、Synthetics まで多岐に渡るデータを統合したサービスダッシュボードを利用できます。

 

⑥ Database Insights（データベース）

Amazon Aurora のダッシュボードを提供します。
データベースの負荷、パフォーマンス、スロークエリ、リソース使用状況などを確認できます。

 

⑦ 番外編：生成AI 環境

生成AI を稼動させている環境に向けた機能がある訳ではありませんが、特に監視すべきシグナルについて触れられていましたので紹介します。

  • モデル呼び出しのレイテンシやエラー（パフォーマンス評価）
  • Amazon Bedrock ガードレースのメトリクス（コンプライアンス）
  • Amazon Bedrock ナレッジベースのログ（RAG の正常稼動）
  • CloudTrail の API コール（セキュリティ）

CloudWatch でデジタル体験の端から端まで可視化できることが分かりましたね。

最後に、「オブザーバビリティは目的地ではなく旅路である」と締め括られました。
設定、運用しているから安心という訳ではなくて、終わりなき改善のサイクルということなのでしょう。

MSPとして

1. システムの何を測るのか

ネットワーク、ユーザー体験からインフラまで、非常に多くの視点でデータを取れることが分かりました。
それと同時に、データが増えるほど、何に活かすかを明確に設定すること必要があると感じました。
とりあえずたくさん取る、ではなく、重視する KPI や SLO を達成する要素となるような設計があってこそのデータかと思います。

通販サイトであれば、Web サイトのダウンタイムの少なさや、リクエストに対する応答の速さかもしれません。
また MSP であれば、迅速に障害を検知し、迅速に復旧を完了することが価値となります。
その目標時間に基づいて監視の範囲や間隔が決まってきます。

達成したいことが何かは常に意識しておきたいものですね。

2. お客様は何を求めているか

デジタル体験を多面的に監視できることを学びました。
これらを使いこなせばオブザーバビリティを兼ね備えていると言えそうです。
とはいえお客様が求めるものとしてコストの比重も大きく、バランス感が大切になると感じました。

万全な監視体制とコストのどこを落とし所にするのか、お客様と密にコミュニケーションを取りつつ、最高ではなく最善の価値提供をしていきたいと思いました。
技術だけでなくコミュニケーションも含めてエンジニアの腕の見せ所、というちょっと本筋から逸れた感想でした。

おわりに

CloudWatch があらゆる切り口でシステムを監視できることを見てきました。
そしてあらゆる監視ができるからこそ、何を優先事項とするのか目的意識をはっきりさせないと重要なメッセージが膨大なデータに埋もれてしまうと思いました。

それにしても re:Invent を通して CloudWatch に詳しくなってきました。
好きなサービスは CloudWatch と公言する日も近いかもしれません。

おしまい