はじめに

こんにちは、Datadog Japan で Sales Engineer をしている AoTo です。

本投稿は AWS Community Builders Advent Calendar 2024 14日目 の記事です

みなさん、AWS re:Invent 2024 で発表された新機能はキャッチアップできていますか？

re:Invent 2024 での発表内容は、AWS 公式ブログの『AWS re:Invent 2024 の注目の発表』や re:Invent カテゴリページで確認できます。

Datadog に所属する Cloud Operations Builderとして、今回はその中でもクラウド運用(Cloud Operations)における主要な発表をまとめた『re:Invent 2024 での AWS のクラウド運用における主要な発表』から、特に AWS の可観測性(Observability) の「変革」を解説しました。

最新の変革へ迫る前に、CloudWatch の歴史を CloudWatch Agent を中心に見ていきましょう。過去の発表を遡る際は AWS News Blog をはじめ、Document Histry(CloudWatch) と CloudWatch Agent Release Note が見やすくまとまっています。

従来の AWS 監視の世界

CloudWatch はそのエコシステムをメトリクスとログを中心に拡大していきました。

2017年以前

2017年以前、CloudWatch はクラウドの特性を活かしたマネージドサービスのメトリクスを自動的に収集するプラットフォームとして、AWS サービス用監視ソリューションとしての立ち位置であったことが伺えます。こうした背景から、AWS へ Lift & Shift 移行し EC2 を利用する場合も、旧来のオンプレミスサービスで利用されていたシステム監視ソリューションをそのまま移行することも少なくなかったように思います。

2017年~2020年頃

2017年にメトリクスとログの統合 CloudWatch Agent の発表に合わせて、オンプレミスサーバーのサポートと AWS Systems Manager(SSM) を利用したインストールと管理、1分間隔の高解像度メトリクスによる詳細モニタリング、EC2 インスタンスメタデータの CloudWatch ディメンションなど、基本的に必要とされる要素が数多く追加されました。

この発表により、CloudWatch が AWS マネージドかつハイブリッド環境の監視ソリューションとしての立ち位置を狙うことが示されています。一方でこの時点では AWS re:Invent 2016 で発表された AWS X-ray とは異なるサービス・エコシステムが提供されていました。

2020年~2023年頃

2019年に OpenTelemetry のプロジェクトが発足すると、トレースの仕様が策定された2022年に AWS Distro for OpenTelemetry が発表されました。従来の X-ray による独自の分散トレースから標準化された分散トレースを同時にサポートするように変化しました。

一方で、これらのエコシステムは互いに独立しており、オブザーバビリティの考慮事項である監視データの相関を実現するためには課題がありました。(もちろん X-Ray トレースと関連する Lambda invokations のログを確認するなどの簡易的な相関は可能でした)

このように、従来の AWS の監視は CloudWatch のメトリクス・ログを中心としながらも、トレースは監視から切り離された異なるプラットフォームとして成長を遂げていました。

変革の片鱗

実は異なるプラットフォームでありながらも CloudWatch と X-Ray は CloudWatch ServiceLens が発表され、擬似的に統合されていました。ServiceLens は異なる方法やエージェントで取得された監視データを同一のコンテキストで相関し、直感的なインターフェースで CloudWatch コンソールから ServiceLens を介した X-Ray コンソールへのアクセスができました。

2023年以後

2023年には AWS 上でのトレースの扱いが大きく変化しました。大まかに説明をすると、既存の X-Ray, ADOT のエコシステムを活かしながら、CloudWatch のエコシステムに統合していく流れが起こりました。

具体的には ①CloudWatch Agent が X-Ray と OpenTelemetry, ADOT のトレース情報を収集できるようになったことと、②Application Signals の登場による CloudWatch と X-Ray の統合です。

これにより、従来の Service Lens はその役割を終え、CloudWatch コンソール内に統合された X-Ray コンソールに結合されました。以下は、2024年12月時点の『X-Ray トレースマップの使用』ページからの引用です。

X-Ray サービスマップと CloudWatch ServiceLens マップは、Amazon CloudWatch コンソール内の X-Ray トレースマップに結合されます。CloudWatch コンソールを開き、左側のナビゲーションペインから X-Ray トレースの下にあるトレースマップを選択します。

このように、2023年からは CloudWatch のエコシステムにアプリケーションパフォーマンスモニタリング(APM)と分散トレースが組み込まれ、2024年前半には Application Signals のGA(一般公開) により商用利用が可能な水準に到達しました。

しかし、これらの監視データのオブザーバビリティ(可観測性)はまだ向上する余地がありました。

re:Invent 2024での変革

さて、ここまでのアップデートでメトリクス・ログ・トレースのオブザーバビリティの主要テレメトリーシグナルが CloudWatch に統合された流れを確認してきました。

説明の都合上省略してしまいましたが、 CloudWatch は RUM(Real User Monitoring), Synthetic Monitoring など、デジタルエクスペリエンスモニタリング(Digital Experience Monitoring, DEM) の機能も追加していました。

こうした中で、オブザーバビリティの重要な要素である監視データの相関の強化が今回の大きな変革です。「コンテキストの追加」とは、異なる種類で同じ対象の複数の監視データを、監視対象の ID などを監視データのコンテキストに追加することで異なる監視データからもう一方の監視データを簡単に参照できる、ということです。

Amazon Web Services ブログ『re:Invent 2024 での AWS のクラウド運用における主要な発表』より引用

上記画像を確認すると、従来の CPU 使用率を確認できるビューの右側に Topology Map により関連する EC2 ボリューム(EBS)・アプリケーションサービス・Auto Scaling Group(ASG) が表示され、下部には Metrics, Logs タブにより EC2 上の CloudWatch Agent から取得された他の監視データを参照できます。

さらに、CloudWatch のオブザーバビリティソリューションページは監視可能な対象とその方式をカタログ方式で確認できるページとして新しく登場しました。これにより、AWS 上で利用可能なソリューションを確認し実装までの方式をそのまま確認できるようになります。

ページ自体はそれほど革新的な内容ではありませんが、こうしたコンソール上でのカタログページの表示や実装方式の説明は、サードパーティーのオブザーバビリティツールのデザインと非常に近しくなっているという点で「オブザーバビリティ」という概念への注力を垣間見えます。

こうしたサービスの構造や概念自体の変容の中にも、Network Monitoring, Detabase Insights, Container Insight, Fault Injection Service (FIS) のアップデートは、本番ワークロードに重要な監視情報を収集でき可観測性の向上に大きく寄与しています。

こうした変革を契機に、AWS はオブザーバビリティソリューションにより力を入れ、AWS ネイティブのサービスのみでサードパーティに劣らないソリューションを提供していくために、独自のサービス・機能を拡充していくことが予想されます。

おわりに

今回は2024年の AWS のオブザーバビリティの変革を理解するために、2017年以前からの CloudWatch と周辺の監視ソリューション・エコシステムとの関係を整理しその歴史を追ってきました。

re:Invent 2024 では特に、CloudWatch よりも Observability がキーワードとして発表に多用され、AWS が独自のオブザーバビリティソリューションに今後も力を入れていくことを示唆するような印象を受けました。

今後も CloudWatch と AWS のオブザーバビリティへの取り組みに目が離せません🐶