タグアーカイブ CloudWatch

AWS CloudWatch Omniが登場。AIとチームで行う新しい可観測性

AWS CloudWatch Omniが登場。AIとチームで行う新しい可観測性

AWSがCloudWatch Omniを発表した。アプリケーションとAIエージェントの両方を監視できる新しい可観測性体験で、チーム全体が同じワークスペースで調査を進められる。

OpenTelemetryベースで構築されており、既存のCloudWatchテレメトリをそのまま活用できる。AWSマネジメントコンソールへのアクセス権限がなくても、専用URLとSSOで利用可能だ。

この記事では、CloudWatch Omniの主要機能、AI調査の仕組み、セットアップ手順、既存環境との関係を解説する。運用チームが抱えるダッシュボード管理や障害調査の負担をどう軽減するかが焦点だ。

CloudWatch Omniとは何か

CloudWatch Omniとは何か

アプリケーション中心の可観測性

CloudWatch Omniは、インフラストラクチャ単位ではなく、アプリケーション単位でテレメトリを整理する。従来のモニタリングツールはサーバーやコンテナといったリソースごとに指標を表示するが、Omniはサービス同士の依存関係を自動的にマッピングし、システム全体をひとつの接続された構造として見せる。

このアプローチにより、担当者は「どのサーバーでエラーが出たか」ではなく「どのアプリケーションで問題が起きているか」を即座に把握できる。ダッシュボードを手動で更新する手間も減る。

従来の可観測性(Before)
サーバーA サーバーB コンテナ
リソースごとに指標を表示。アプリ全体の関連性は見えにくく、ダッシュボードの手動管理が必要。
↓
CloudWatch Omni(After)
チェックアウトサービス 支払いAPI 在庫管理
アプリ単位でトポロジーを自動生成。依存関係と関連シグナルをひとつの画面で確認できる。
■ インフラ単位 ■ サービス単位

この比較デモは、リソース中心からアプリ中心への考え方の転換を示している。Omniは自動検出とトポロジーマッピングにより、運用者が全体像を維持する負担を軽減する。

OpenTelemetryとの統合

CloudWatch OmniはOpenTelemetryを基盤としている。OpenTelemetryは、メトリクス・ログ・トレースなどのテレメトリデータを収集するためのオープン標準だ。すでにCloudWatchに送信しているテレメトリは、再設定なしでOmniに表示される。

さらに、OpenTelemetryで計装された他のワークロードも、OTLP(OpenTelemetry Protocol)エンドポイントを通じてOmniに取り込める。これにより、オンプレミス環境や別のクラウドで稼働するアプリケーションも同じワークスペースで監視できる。

チーム全体で使える共同作業の仕組み

チーム全体で使える共同作業の仕組み

CloudWatch Omniの大きな特徴は、チーム全員が同じワークスペースを共有できる点にある。エンジニアは専用URLにアクセスし、企業のSSO(シングルサインオン)でログインする。AWSマネジメントコンソールへのアクセス権限は不要だ。

IAM Identity Centerを通じてOktaやAzure ADなどのIDプロバイダーと連携できる。SRE、開発者、データベースエンジニア、マネージャーが同じデータと調査コンテキストを共有する。

STEP 1 アラーム発生。Omniがセッションを自動作成し、トポロジーと関連シグナルを表示
↓
STEP 2 オンコールSREがトレースを確認し、デプロイとの相関を特定
↓
STEP 3 支払いチームにエスカレーション。同じセッションに参加して全コンテキストを共有
↓
STEP 4 根本原因を特定してロールバック。調査履歴は自動で記録される

このフローは、通常のインシデント対応時にOmniがどのように進行するかを示している。チーム間の引き継ぎ時にコンテキストが失われる問題が解消される。

エスカレーション時の連携強化

障害がチームの境界を越えると、Slackのスレッドやスクリーンショットでの情報共有になりがちだ。Omniでは次の担当者が同じセッションに参加し、これまでの調査内容をそのまま引き継げる。

調査履歴は自動的に記録されるため、インシデントレポートを別途作成する必要もない。

AIが調査を支援するAmazon DevOps Agent

AIが調査を支援するAmazon DevOps Agent

CloudWatch Omniには、Amazon DevOps Agentと呼ばれるAIアシスタントが組み込まれている。調査セッションの中で、シグナルの相関分析や次のアクションの提案を行う。

このエージェントは、エンジニアが見ているのと同じテレメトリデータを参照する。そのため、提案内容はアプリケーションの実際の状態に基づいたものになる。

障害発生(エラー率上昇)
SRE アラーム確認 → DevOps Agent デプロイ10分前と支払いAPI遅延を相関付けて提示
↓
根本原因の特定と復旧
チーム全体 同じセッションで調査 → DevOps Agent APIゲートウェイ設定変更を指摘しロールバック支援
■ SRE・チーム ■ AIエージェント

DevOps Agentは、相関イベントの特定や依存関係グラフを通じた根本原因の追跡を支援する。調査履歴は事後レビューにも活用できる。

エージェントの役割と限界

DevOps Agentはあくまで支援ツールであり、人間の判断を代替するものではない。提案内容をそのまま鵜呑みにするのではなく、エンジニアの専門知識と組み合わせて使うことが重要だ。

また、エージェントはテレメトリデータのみに基づいており、コードのビジネスロジックや組織固有の事情までは考慮しない。この点は運用チームが補完する必要がある。

セットアップ手順

セットアップ手順

CloudWatch Omniのセットアップは数分で完了する。既存のCloudWatch環境を再設定する必要はない。

既存CloudWatchユーザーの場合

CloudWatchコンソールで「Try CloudWatch Omni」をクリックするだけで、既存のログ、メトリクス、トレース、アラームが即座に利用可能になる。ワークロードは自動的に検出され、アプリケーショントポロジーをすぐに確認できる。

組織全体への展開

管理者はドメインを設定し、IAM Identity Center経由でIDプロバイダーを接続する。その後、チームと環境ごとにSpaceを定義し、ユーザーを招待する。各Spaceは既存のCloudWatchデータを参照するため、データの移動は不要だ。

他環境のアプリケーション取り込み

オンプレミスや他クラウドで稼働するアプリケーションも、コネクターを利用してテレメトリをOmniに取り込める。取得したデータはAWSデータと同じSpaceや調査セッションに表示される。

既存のCloudWatchとの関係と料金

既存のCloudWatchとの関係と料金

CloudWatch OmniはCloudWatchを置き換えるものではなく、拡張するものだ。既存のアラーム、ダッシュボード、API、コンソールのワークフローはそのまま機能する。

アクセスは専用のWebアプリケーション経由で、エンタープライズSSOに対応する。セットアップ後、DevOps AgentはすべてのOmni調査セッションでデフォルトで有効になる。

料金体系

料金の詳細はAWSの公式価格ページで確認できる。既存のCloudWatchユーザーはコンソールから直接試用できる。

導入コストの見積もりには、監視対象のワークロード数と取り込むテレメトリ量が影響する。

生成AIワークロードへの対応

生成AIワークロードへの対応

CloudWatch Omniは、生成AIやエージェントワークロード向けの専用可観測性も提供する。トレース探索、評価フレームワーク、リアルタイムモニタリングが含まれる。

詳細はAWSの別記事で紹介されている。エージェント可観測性のハンズオンも参照できる。

この記事のポイント

  • CloudWatch Omniはアプリケーション中心の可観測性を提供する
  • OpenTelemetryベースで既存テレメトリを活用できる
  • チーム全体が同じワークスペースで共同調査できる
  • Amazon DevOps AgentがAI支援で根本原因特定を助ける
  • セットアップは数分で完了し、既存環境への影響はない