はじめに

カミナシの認証認可チームのmanaty（@manaty226）です。今年もラスベガスにて12月1日から12月5日まで開催されているre:Inventに参加しています。この記事では、3日目に参加した以下のワークショップセッションについて記載します。

Build full-stack observability from applications to databases [REPEAT] (COP404-R1)

オブザーバビリティの難しさ

このワークショップでは、アプリケーション及びデータベースまでをカバーしたオブザーバビリティのことをフルスタックオブザーバビリティと呼び、実際にAWSのサービスを使ってフルスタックオブザーバビリティを構築していきます。

まず、ワークショップの冒頭にオブザーバビリティの難しさをアプリケーションとデータベースの視点でそれぞれ説明されました。

アプリケーション視点では、分散したシステムや標準化されたアプリケーションメトリクスの欠如、ビジネスゴールにアラインさせて優先度を上げることの難しさや、取得したログ、メトリクス、トレースを横断して監視することの難しさが語られました。

一方データベース視点では、データベースインスタンスが分散していたり、アプリケーションの挙動との相関がないこと、データベースの専門知識が必要なことなどが挙げられています。私自身、アプリケーションよりもデータベースのオブザーバビリティのほうが不十分と感じています。

このような課題に対して、AWSのサービスを利用してどのように解決していけるのでしょうか。ワークショップを進めていきました。

AWSによるフルスタックオブザーバビリティの構築

CloudWatch APMによる統合監視

今回構築する模擬アプリケーションおよびオブザーバビリティスタックの全体像は下図のとおりです。模擬アプリケーションとしてEKSでコンテナを動かして、AuroraをDBとして利用しています。また、OpenTelemetryの自動計装サイドカーを使ってCloudWatchに各種テレメトリを流します。

アプリケーションから自動計装エージェントがテレメトリを収集してCloudWatch APMに流すデータの流れは下図のようになっています。

さっそく構築してCloudWatch APMで確認してみます。CloudWatch APMのアプリケーションマップという機能を利用すると、以下のようにサービスの健全性だけでなく、サービス間の接続における障害発生、レイテンシー、エラー率などをパスごとに可視化することができます。普段Managed Grafanaで一生懸命ダッシュボードを作り込んでいる自分からすると、これだけでもかなり感動があります。

また、レイテンシーの高いパスをクリックすると、リクエスト数やp99レイテンシ、エラーだけでなく、各メトリクスに関連したトレースも見ることができます。ほしかったやつ！

さらになんと、これらの情報を利用してサービスレベル目標（SLO）も作れちゃいます！今までちゃんと追ってこなかったけど、CloudWatch APMすごすぎる！自分たちでSLIから計算しようとすると結構作り込まないといけないのですが、こうやって設定すれば計測できるのは大変ありがたいですね。

さて、CloudWatch APMによってテレメトリの相関や、ビジネスゴールにアラインさせるためのSLOの設定ができるようになりました。それでは、データベースはどうでしょうか。

データベースのメトリクスについては、データベースインサイトという機能をAurora and RDSのコンソールから有効化すると、下図のようにアプリケーションのトレースとの関連を出してくれるようになります。これで、アプリケーションとデータベースのコンテクストが繋がりました。

データベースインサイトでは、データベースの健全性（負荷使用率）やスロークエリなどが可視化されています。また、呼び出し元アプリケーションごとのレスポンス時間やエラーなども見られるようです。

AIによる障害対応：AIオペレーション機能

AWSでは、オブザーバビリティの成熟度について4段階に定義しています。ステージ1では、オブザーバビリティ基盤が整備されており、ステージ2になるとテレメトリ間を横断して監視したりアラートを出してより効果的にインサイトが得られるようになっています。ステージ3では、SLOを満たすように日々の運用が最適化されているだけでなく、生成AIなどを利用して障害発生時の対応を行っています。最後にステージ4になると、プロアクティブに問題を把握し自動復旧するような仕組みも整備されています。

今回のワークショップの最後には、CloudWatchのAIオペレーションを利用してSLOを違反している状態に対するAIエージェントによる原因の特定や解決策の提示を行いました。本番アプリケーションの障害において障害の主要因特定にどれほど利用できるかは未知数ですが、関連するテレメトリを自動で収集して手がかりを得るという意味ではすごくよさそうだなと感じました。

おわりに

CloudWatch APMというサービスの名前は知っていましたが、これまで触ったことがなかったのでワークショップを通して想定以上に色々な機能が充実していることを学びました。また、APMの機能を触る中で、オブザーバビリティの成熟度をイメージしながら自分たちの運用に何が足りていないかを振り返る機会にもなりました。

カミナシではストレージを整理してデッキ構築に必要なカードの探索容易性を上げることが上手なソフトウェアエンジニアも募集しています。ご興味がある方はカジュアル面談からお願いします。