【re:Inent 2025】Implementing observability at scale: A blueprint for success (COP328) 参加レポート

はじめに

エンタープライズクラウド本部の小林です。

AWS re:Invent 2025で開催されたセッション「Implementing observability at scale: A blueprint for success (COP328)」にて、エンタープライズ規模の複雑な環境において、いかにして効果的かつ効率的なオブザーバビリティ（可観測性）を実現するか、この為の道筋・ブループリントの説明がありました。

Amazon 自身が各サービスの監視に CloudWatch を使用しており、実践ガイドとしても非常に参考になりましたので、セッション内容をかいつまんで説明します。

エンタープライズ規模の Observability における現状と課題

規模の現実

従来のモニタリングとは異なり、現代のエンタープライズ環境は極めて大規模かつ複雑化している

インフラの規模: 複数リージョンにまたがる数百～数千のAWSアカウントを管理する必要がある
サービスの複雑性: 数千、時には数十万ものマイクロサービスが存在する
データ量: 日次でペタバイト級のテレメトリデータが発生するケースもある

直面する主な課題

規模の拡大に伴い、多くの組織が以下のような課題を抱えている

ツールの断片化: ログ、トレース、メトリクスが別々のツールに分散しており、管理が困難
コストとアラート: 監視コストの増大に加え、大量のアラートにより重要な問題が見逃されるリスクがある
サイロ化と手動運用: データやチームがサイロ化し、複数のツール間で手動による相関分析（タブの切り替えなど）が強いられる。解決までの時間（MTTR）が増加する

ビジネスへの影響

Observabilityが適切にスケールしない場合、技術的な問題だけでなく甚大なビジネス損失を招く

ダウンタイムコスト: 90%の企業で1時間あたり30万ドル以上、41%の企業では100万～500万ドルの損失が発生する
その他の損失: エンジニアの生産性低下、顧客体験の悪化、社会的信用の失墜、機能リリースの遅延などにつながる

メトリクスに対する考え方の転換

従来のモニタリングの限界

これまでのモニタリングは、インフラ（CPU、ネットワークなど）やアプリケーションのパフォーマンス、そして「ゴールデンシグナル（レイテンシ、トラフィック、エラー、飽和度）」といった技術的な指標を下から積み上げるアプローチが一般的
→　 多くの組織はこの技術的なレイヤーで思考が止まってしまっている

ビジネス成果（Business Outcomes）への転換

新たなアプローチとして、技術指標の上に「ビジネス成果」という最上位のレイヤーを設け、顧客にとって真に重要な指標を計測することを推奨する

顧客視点の重視: 顧客はサーバーのCPU使用率やメモリ使用量には関心がなく、「商品が買えるか」といった自身の体験に関わる事象を気にしている
Amazonの例: Amazon.comにおいて最も重要な指標は、技術的な数値ではなく「Orders Per Minute（1分あたりの注文数）」としている

ビジネス成果を計測する意義

ビジネス成果をモニタリングの指標に含めるべき理由は主に2つある

確実な異常検知: 技術的なメトリクスに異常が見られなくても、ビジネス指標（注文数の急落など）を監視していれば、問題の発生を確実に検知できる
影響の定量化: 技術的な問題が発生した際、それがビジネスに具体的にどれだけの影響を与えているかを、推測ではなく正確に把握することが可能になる

エンタープライズ Observability の Blueprint

大規模環境で Observability を成功させるために提示した全体像（フレームワーク）。

マルチアカウント・マルチリージョンでの運用を前提とし、主に以下の2つの層で構成されている。

Operational Excellence: ログの一元化、メトリクス収集の統一、分散トレーシングの実装を通じて、強固な監視基盤を確立する
Intelligence Layer: 収集したデータに対し、AIによる異常検知、高カーディナリティ分析、自動相関分析などを適用し、高度な洞察を得る

Amazonにおける実践

Amazon社内のCloudWatchチームでは、月間 20 京件以上のメトリクスを処理する超大規模環境において、上記の Blueprint をもとに以下のように実践している

標準化と自動化: マイクロサービスごとの複雑性を管理するため、「Two-Pizza Teams（少人数チーム）」モデルを採用。サービスの作成には標準化されたテンプレートを使用。これにより、ログやトレースが自動的に組み込まれ、開発者は意識することなく統一されたテレメトリを収集できる
高カーディナリティへの対応: 顧客IDやエンドポイントの組み合わせによるメトリクス爆発（コスト増大）を防ぐ目的で、Contributor Insights などを活用。これにより、構造化ログから影響を受けている上位の顧客（トップN）をリアルタイムに特定・分析している
高度なインシデント対応: 大量のアラートによるアラート疲れを防ぐため、単発のアラームではなく複数のアラームを集約する「Composite Alarms」を利用。さらに、チケット起票と同時にAIによる自動調査（CloudWatch Investigation）をトリガーし、運用者が調査を開始する前に根本原因の示唆を得られるワークフローを構築
アカウント管理: サービスはリージョンやアカウントごとに分離してデプロイされるが、運用監視は中央のモニタリングアカウントにデータを集約して行っている

Blueprint の実装

大規模実装のための基盤と可視化

大規模環境におけるデータ管理の効率化と、手作業を最小限に抑えた可視化の実現について

ログとアラームの一元管理: 直近でリリースされたCloudWatchによるログ一元管理機能を用いて、ログ、メトリクス、トレースを単一のアカウント・リージョンに集約。データのサイロ化を解消する。また、「Metrics Insights」を用いてSQLライクなクエリを実行することで、数万のリソースに対しても単一のアラーム設定で監視を可能にし、アラーム管理の煩雑さを解決する
トレース分析: 「Transaction Search」により、すべてのトレース（100%）をリアルタイムに検索・分析可能にし、重要な事象の見逃しを防ぐ
自動計装による可視化: 「Application Signals」や各種Insights（Container, Database, Lambda）を活用し、エージェントベースでの自動計装を実現。これにより、コード変更の手間なく、アプリケーションからインフラ層までの詳細なパフォーマンスデータを標準化して収集・可視化する

インテリジェンスと AI の活用

基盤が整った環境に対し、AI/MLを適用することで、人間では困難な規模の分析を自動化し、障害対応の迅速化を図る

3本柱の異常検知: 「AI-Powered Anomaly Detection」により、メトリクス（季節性を考慮）、ログ（パターンの変化）、トレース（レイテンシやエラー）のすべてにおいて、AIが自動的に異常を検知
自動調査と根本原因分析: 「CloudWatch Investigations」により、アラーム発火時にメトリクス、ログ、トレース、変更イベントをもとに自動で相関分析を実施。AIが自然言語で根本原因を提示し、推奨される対応手順（Runbook）まで案内。調査時間を大幅に短縮する
対話型の運用: 「MCP Servers（Model Context Protocol対応サーバー）」を活用することで、運用者は自然言語でシステムの状況を問い合わせ可能とした。AIがコードベースやリソース状況を横断的に調査し、障害の影響範囲や原因を即座に回答する

導入戦略

高度なAI機能を利用する前に、まずは基礎を固める段階的なアプローチが推奨される。

1. 基盤の確立

AI活用や高度な分析の前提として、まずはモニタリングアカウントの構成、ログの一元化（Centralized Logging）、保持ポリシーの策定を実施し、データを集約・標準化する

併せて、アラートフレームワークの整備やリソースへのタグ付け、ログフォーマット（JSON化など）の統一を行う

2. インサイトの可視化 (Insights)

次に、「Container Insights」や「Database Insights」など、有効化するだけで詳細な可視性が得られる機能を展開する

EC2へのエージェント導入や「Application Signals」による自動計装を行い、インフラからアプリ層までの可視性を確保する

3. インテリジェンスの適用 (Intelligence)

集約されたデータを基に、「Contributor Insights」や「Anomaly Detection」を活用し、高度な洞察を得る

さらに、「CloudWatch Investigations」による調査や、SSM Runbookによる自動修復、チャットツール連携など、運用の自動化とワークフロー統合を進める

4. コストとパフォーマンスの最適化 (Optimization)

最終段階として、システム全体のコスト効率とパフォーマンスを調整する

アラームの集約（Composite Alarms）、ログ保持期間の見直し、トレースサンプリング設定の最適化などを実施する

まとめ

セッションを通して単にツールを導入するだけでなく、「ビジネスへの影響を可視化」し、「データを一元化・相関付け」し、「AIで運用負荷を下げる」ことで、Amazonのような大規模環境でも耐えうる監視基盤を構築する、非常に良い実践ガイドであったと感じました。

「Contributor Insights」は私自身、本番環境で試したことがなく、また現地の参加者でも利用率が低いものでしたが、「Application Signals」等とともに、ただメトリクスを集めて終わりではなく、その先のビジネス成果を踏まえた監視をぜひ実践していきたいです。