AWS re:Invent 2024 で AWS Observability はどう変わったか

## はじめに
こんにちは、Datadog Japan で Sales Engineer をしている [**AoTo**](https://qiita.com/AoTo0330) です。

本投稿は **<font color=#FF9900>AWS Community Builders Advent Calendar 2024</font> 14日目** の記事です

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

**re:Invent 2024** での発表内容は、**AWS 公式ブログ**の『[AWS re:Invent 2024 の注目の発表](https://aws.amazon.com/jp/blogs/news/top-announcements-of-aws-reinvent-2024/)』や [re:Invent カテゴリページ](https://aws.amazon.com/jp/blogs/news/category/events/reinvent/)で確認できます。

https://aws.amazon.com/jp/blogs/news/top-announcements-of-aws-reinvent-2024/

Datadog に所属する [**<font color=#FF9900>Cloud Operations Builder</font>**](https://aws.amazon.com/developer/community/community-builders/community-builders-directory/?cb-cards.q=Kento%2BKimura)として、今回はその中でもクラウド運用(Cloud Operations)における主要な発表をまとめた『[re:Invent 2024 での AWS のクラウド運用における主要な発表](https://aws.amazon.com/jp/blogs/news/top-announcements-for-aws-cloud-operations-at-reinvent-2024/)』から、特に AWS の可観測性(Observability) の「変革」を解説しました。

https://aws.amazon.com/jp/blogs/news/top-announcements-for-aws-cloud-operations-at-reinvent-2024/

最新の変革へ迫る前に、CloudWatch の歴史を CloudWatch Agent を中心に見ていきましょう。過去の発表を遡る際は [AWS News Blog](https://aws.amazon.com/blogs/aws/category/management-tools/amazon-cloudwatch/) をはじめ、[Document Histry(CloudWatch)](https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/DocumentHistory.html) と [CloudWatch Agent Release Note](https://github.com/aws/amazon-cloudwatch-agent/blob/main/RELEASE_NOTES) が見やすくまとまっています。

## 従来の AWS 監視の世界
CloudWatch はそのエコシステムをメトリクスとログを中心に拡大していきました。

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


### 2017年~2020年頃
![AWS_CW-XR.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/2b586e73-7b43-e01d-f1eb-eac31deac06d.png)


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

https://aws.amazon.com/about-aws/whats-new/2017/12/amazon-cloudwatch-introduces-a-new-cloudwatch-agent-with-aws-systems-manager-integration-for-unified-metrics-and-logs-collection/

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

https://aws.amazon.com/about-aws/whats-new/2016/12/announcing-aws-x-ray/

### 2020年~2023年頃
![AWS_CW-XR-ADOT.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/693a7db4-3de0-fb23-7c4d-135b435588b5.png)

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

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

https://aws.amazon.com/jp/about-aws/whats-new/2020/10/announcing-aws-distro-for-opentelemetry-in-preview/

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

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

https://aws.amazon.com/jp/about-aws/whats-new/2019/11/announcing-amazon-cloudwatch-servicelens/

### 2023年以後
![AWS_CW_XR-ADOT.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/50e8e9ed-3646-8694-461c-3ecc2eaaa3eb.png)

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

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

https://aws.amazon.com/jp/about-aws/whats-new/2023/08/amazon-cloudwatch-agent-opentelemetry-traces-x-ray/

https://aws.amazon.com/jp/about-aws/whats-new/2023/11/amazon-cloudwatch-applications-signals-observe-preview/

これにより、従来の Service Lens はその役割を終え、CloudWatch コンソール内に統合された X-Ray コンソールに結合されました。以下は、2024年12月時点の『[X-Ray トレースマップの使用](https://docs.aws.amazon.com/ja_jp/xray/latest/devguide/xray-console-servicemap.html)』ページからの引用です。

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

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

https://aws.amazon.com/jp/about-aws/whats-new/2024/06/amazon-cloudwatch-application-signals-application-monitoring/

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

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

説明の都合上省略してしまいましたが、 CloudWatch は [**RUM(Real User Monitoring)**](https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html), [**Synthetic Monitoring**](https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) など、**デジタルエクスペリエンスモニタリング(Digital Experience Monitoring, DEM)** の機能も追加していました。

こうした中で、オブザーバビリティの重要な要素である[監視データの相関](https://github.com/cncf/tag-observability/blob/main/whitepaper.md#correlating-observability-signals)の強化が今回の大きな変革です。「コンテキストの追加」とは、異なる種類で同じ対象の複数の監視データを、監視対象の ID などを監視データのコンテキストに追加することで異なる監視データからもう一方の監視データを簡単に参照できる、ということです。

https://aws.amazon.com/jp/about-aws/whats-new/2024/11/amazon-cloudwatch-observability-data-consoles-analysis/

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/a4f812a0-e19e-7614-e429-2e8241edc72d.png)
Amazon Web Services ブログ『[re:Invent 2024 での AWS のクラウド運用における主要な発表](https://aws.amazon.com/jp/blogs/news/top-announcements-for-aws-cloud-operations-at-reinvent-2024/)』より引用

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

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

https://aws.amazon.com/jp/about-aws/whats-new/2024/11/amazon-cloudwatch-observability-solutions-aws-services-workloads/

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2363567/efa43bdc-350c-bdc9-b415-7e77a7a38869.png)

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

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

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

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

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

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