【セッションレポート】明日から実践できる AWS でのオブザーバビリティ革新 - Amazon CloudWatch Application Signals と OpenTelemetry で実現する次世代オブザーバビリティ(AWS-10)#AWSSummit

【セッションレポート】明日から実践できる AWS でのオブザーバビリティ革新 - Amazon CloudWatch Application Signals と OpenTelemetry で実現する次世代オブザーバビリティ(AWS-10)#AWSSummit

Clock Icon2025.06.26

はじめに

皆様こんにちは、あかいけです。

AWS Summit Japan 2025 の一日目で行われた、
明日から実践できる AWS でのオブザーバビリティ革新 - Amazon CloudWatch Application Signals と OpenTelemetry で実現する次世代オブザーバビリティ」に参加してきました。
本記事ではそのレポートをお届けします。

セッション概要

タイトル :
明日から実践できる AWS でのオブザーバビリティ革新 - Amazon CloudWatch Application Signals と OpenTelemetry で実現する次世代オブザーバビリティ

概要:
「アプリケーションの性能低下の原因がわからない」「マイクロサービス間の問題箇所の特定に時間がかかる」―こうした運用現場での課題に対して、Amazon CloudWatch Application Signals と OpenTelemetry の組み合わせが新たな解決策を提供します。

本セッションでは、CloudWatch Application Signals を活用した実践的なオブザーバビリティの実現方法について解説します。
具体的には、Application Signals の特長である SLO モニタリングの実装からインシデントの早期発見方法、OpenTelemetry による分散トレースを活用したボトルネックの特定について紹介します。
さらに、ゼロコード計装による開発者の負担軽減といった実務で活用できる具体的な実装手法を説明します。

これからオブザーバビリティを導入したい方はもちろん、既存のモニタリングを改善したいエンジニアの方にも最適です。
AWS 環境での運用効率を向上させる実践的なテクニックと、次世代のオブザーバビリティプラットフォームの活用方法を習得していただけます。

スピーカー :
津郷 光明

セッションレベル :
Level 300: 中級者向け

資料

AWS 公式から資料や動画がアップされたら追記します。

レポート内容

本セッションについて

  • セッションの対象者
    • オブザーバビリティに取り組んでいるが、効果を実感できていない方
    • オブザーバビリティを始めるにあたり、
      どのような課題があり、またどのように解決できるのか知りたい方
  • セッションのゴール
    • OpenTelemetry と Amazon CloudWatch Application Signals の概要、および解決する課題を理解する
    • OpenTelemetry と Amazon CloudWatch Application Signals の関係性を理解する

アジェンダ

  • オブザーバビリティと AWS オブザーバビリティサービスの概要
  • オブザーバビリティの活動が進まない技術的な課題
  • Open Telemetry 概要と解決できること
  • Amazon CloudWatch Application Signals 概要と解決できること
  • 実際の様子 (デモ)
  • まとめ

オブザーバビリティと AWS オブザーバビリティサービスの概要

  • オブザーバビリティとは

    • システムの状態が把握できている状態
    • 複雑なシステムでもどこで何がいつ起きたか後からわかる状態
  • テレメトリデータの収集と分析が活動の中心となる

    • メトリクス
    • ログ
    • トレース
  • オブザーバビリティの活動を始めても、効果が実感できていない感覚があるのでは?

    • どこで起きたかはすぐわかっても、
      障害発生時に、なぜ発生したのか、何が原因なのかを把握するのに時間がかかってしまうことも…

オブザーバビリティの活動が進まない技術的な課題

オブザーバビリティの活動が進まない原因は、
以下の複合的で技術的な課題があるためです。

  • 部分的な分析
    • 取得するデータの広さや深さの不足
    • 不一致なデータフォーマット
    • テレメトリデータの高い実装コスト
  • 分析スキルセットの不足
    • 難易度の高い相関分析
    • 多様な分析観点
    • 分析担当者の属人化
  • 膨大なデータ、複雑さ
    • 膨大なテレメトリデータ
    • 分散処理
    • マイクロサービス

それらの一つの解決策として、以下を活用できます。

  • OpenTelemetry
  • Amazon CloudWatch Application Signals

Open Telemetry 概要と解決できること

  • 解消する課題
    • 部分的な分析

OpenTelemetry とは

  • テレメトリデータの作成と送信の標準仕様と実装を提供

テレメトリ取得の流れ

  • OpenTelemetry SDK を利用したアプリケーションの計装
    • OpenTelemetry SDK で自身で計装可能
  • OTLP を利用したテレメトリデータの送信
    • OpenTelemetryで定義された標準プロトコル
  • バックエンドの可視化と分析
    • AWS であれば X-Ray などを活用

OpenTelemetry SDK を利用したアプリケーションの計装 の課題

  • 手動計装

    • 計装のため実装コストが高い
    • 既存のアプリコードを修正する必要あり
  • 解消方法:ゼロコード計装

    • 主要フレームワーク/ライブラリ向けのエージェントを提供している
      • 実装コストを下げられる
      • 既存アプリコードの修正を軽減
  • 活用できるAWSサービス

    • AWS Distro for OpenTelemetry
    • AWS が提供しているオープンソースディストリビューション

Amazon CloudWatch Application Signals 概要と解決できること

  • 解決する課題
    • 分析スキルセット不足
    • 膨大なデータ、複雑さ

Cloudwatch Application Signals とは

  • アプリ状態を把握、分析のための情報を自動で収集、可視化
  • CloudWatch、X-Ray の機能を集約
  • 特徴
    • テレメトリデータの自動収集
    • サービス検出とトポロジー可視化
    • ダッシュボードの提供、トレース、メトリクスの確認
    • SLO モニタリング
    • CloudWatch Synthetics、CloudWatch RUM との連携

提供されているダッシュボード

  • サービスダッシュボード
    • サービスの自動検知
    • SLO 状態確認
    • 障害率、レイテンシーの確認
    • サービス可用性も自動計算
  • サービスマップ
    • サービスの関係性を可視化
    • 複雑なアーキテクチャでも全体像を把握可能
    • SLO に問題のあるサービスを検知可能

サポート環境

  • アーキテクチャ
    • EC2
    • ECS
    • EKS
    • Lambda
  • 言語
    • Java
    • Python
    • .NET
    • Node.js

解決する課題

  • 分析スキルセット不足
    • ビルドインダッシュボードによる分析
    • 分析経験のないエンジニアでも分析に着手可能
    • テレメトリデータの活用
  • 膨大なデータ、複雑さ
    • サービスマップによる可視化
      • 全体像を失わずに分析
      • 必要な分析だけに集中し、膨大なデータや複雑さを解消

CloudWatch Application Signals の仕組みと一連のデータの流れ

  • 生成
    • AWS Distro for OpenTelemetory
  • 収集
    • Cloudwatch Agent
  • 蓄積
    • CloudWatch
    • AWS X-Ray
  • 可視化と分析
    • CloudWatch Application Signals

実際の様子 (デモ)

大まかな手順

  • AWS Distro for OpenTelemetry サービス有効化
  • CloudWatch Application Signals の有効化
    • Lambda、EC2、EKS などで手順が異なる

事例

  • 状況
    • Cloudwatch は導入済み
    • マイクロサービス増加により、メトリクスやログでの全体把握が不可
  • 対応
    • CloudWatch Application Signals の導入
  • 結果
    • ビジネスメトリクスを含む高度な分析を実現

まとめ

  • オブザーバビリティの活動が進まない技術的な課題
    • 部分的な分析、分析スキルセットの不足、膨大なデータと複雑さ
  • 部分的な分析 の解決法
    • AWS Distro for OpenTelemetry が提供する統一規格、ゼロコード実装で解消
  • 分析スキルセットの不足、膨大なデータと複雑さ の解決法
    • Amazon CloudWatch Application Signals が提供するダッシュボード群で解消

さいごに

オブザーバビリティという概念は知っていましたが、恥ずかしながら私は実務レベルで実践したことはほとんどありません。
しかし本セッションに参加することで、オブザーバビリティとテレメトリへの理解が深まり、実現する際に活用できるAWSサービスを知ることができました。

セッション内でも説明があった通り、オブザーバビリティはシステムが大規模化・複雑化するほど有用性が高まる(というか必須の)仕組みです。
ただし現状では概念や思想だけが先行し、実装面で有効性を実感できていないケースが多いのも事実でしょう。

本セッションでは、そうした課題に対してAWSサービスを活用した具体的な解決策とアプローチが示されたため非常に実践的で有意義な内容であり、特に以下の点が印象的でした。

  • ゼロコード計装による開発者負担の軽減
  • 統一されたテレメトリデータによる分析効率の向上
  • ビルトインダッシュボードによる分析スキルの民主化

なお私自身はAmazon CloudWatch Application SignalsもOpenTelemetryも未経験のため、実際に触れてみて、その効果を検証したいと思います。
実践した際は改めてブログで共有します。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.