先日のAWS Summitで「明日から実装できるAWSでのオブザーバビリティ革新」というセッションが勉強になりました。
この記事では、自分用の備忘録もかねて、メモをベースに内容を噛み砕いて整理してみようと思います。
「オブザーバビリティ」って、結局どういう状態？
「どこで何が起きてるかが、ちゃんと見える」
これがシンプルかつ本質的な定義として紹介されていました。
ログだけ、メトリクスだけ、では不十分で、ログ・メトリクス・トレースの3つを組み合わせて分析できる状態が望ましいとのこと。
オブザーバビリティが“うまくいかない”のはなぜ？
この辺り、セッションでかなり丁寧に触れられていました。印象的だったものがこちらです。
- 分析の偏り：たとえばログしか見ていない、メトリクスしか取っていないなど、全体像を捉えきれていない
- 属人化：分析スキルを持った一部の人に頼りがちで、組織としてナレッジが共有されていない
- データが膨大で手がつけられない：特に分散システムだと、トレースもログもとにかく量が多い
個人的には、「見るものが多すぎて、どこを見ればいいかわからなくなる感覚」に共感しました。
じゃあ、どうする？
ここで登場したのが OpenTelemetry（OTel）。
OSSとして多くの言語・環境に対応していて、ログ・メトリクス・トレースを統一的に扱えるのが特徴です。
AWSでは AWS Distro for OpenTelemetry（ADOT） という形で、OpenTelemetryのディストリビューションを提供しており、これを使えばECSやLambdaなどの環境に組み込みやすくなっています。
ちなみに、自分でコードを書いて埋め込む「手動計装」だけでなく、既存アプリを変更せずにテレメトリを取れる「ゼロコード計装」の方法も紹介されていました。
そしてもう一つの手段がCloudWatch Application Signals
OpenTelemetryをベースにしながらも、「分析がうまくできない問題」や「どこを見ればいいかわからない問題」をさらに解消してくれるのがこの新サービスのようです。
要点だけまとめると
- テレメトリデータを自動収集（＝ゼロコード計装）
- サービス構成を自動検出してトポロジー表示
- 主要言語・実行環境（EKS, ECS, EC2, Lambdaなど）に対応
- SLOモニタリングにも対応している
- CloudWatch SyntheticsやRUMとの連携も可能
「SLOとか使いこなせる気がしない…」と思っていたんですが、最初から用意されたダッシュボードがあるのは助かります。まず見ることから始められる構成です。
導入のハードルは意外と低いかもしれない
Application Signalsは、ADOTと組み合わせて使う形になります。
EKSやLambdaなどでは、アノテーションなど最小限の設定で有効化が可能で、「あれこれ書かなくても使える」というのは地味に嬉しいポイントです。
個人的にどう活かせそうか？
セッションを聞いて、まず感じたのは「観察できないものは改善もできない」という基本の大切さでした。
エラー通知が来てからCloudWatchのログに潜って…みたいな運用をしていたりするケースもあるので、「可視化の前提が足りてない」というのはまさに刺さる指摘でした。
まずはADOT＋Application Signalsで、自分たちのサービスの状態を俯瞰してみるところから始められたらと思いました。
おわりに
今回はセッションの内容を中心に、メモを兼ねてまとめてみました。
正直、まだ実際に手を動かしていないところなので、今後、実際にサンプルアプリケーション等に組み込んで検証してみたいと思います。