AWSでオブザーバビリティを実現するためのビルディングブロック
ここからはAWSにおけるアプローチを見ていこう。AWSではオブザーバビリティ成熟度モデルを提唱している。成熟度に応じてレベル1から4まで分かれている。
ステージ1はログとメトリクスの収集。これはまだ（オブザーバビリティ以前の）モニタリングと呼ばれていた時代に求められていたことで、まずはモニタリング基礎が最初のステップとなる。ステージ2は計装、テレメトリーの分析と洞察。モニタリングが中級レベルに上がり、アプリケーションレベルでテレメトリーをとれるようにする。
ステージ3は相関、アノマリーの検知、SLOとなり、トレースとログを紐付けることができるようになる。さらにステージ4は原因究明の自動化と予防ができるようになる。
今回はステージ1〜2を目指すこととする。必要になるものは下図の通り、計装、収集、送信、保存、可視化だ。これがオブザーバビリティの基盤となる。
テレメトリーを得るために、まずはコンポーネントに計装（インスツルメンテーション）する。出てきたテレメトリーを収集し、送信し、どこかに保存し、そこからクエリなどを通じてダッシュボードで可視化する。オブザーバビリティでは最低限ここまでが必要になる。
どんなコンポーネントが対象になるかと考えると、責任共有モデルを思い出すといいだろう。一般的にはIT統制やセキュリティの文脈で語られるものだが、似たような発想がオブザーバビリティにも当てはまる。
例えばAmazon S3なら、このサービスを動かすためのハードウェアやOSはAWSが担保するが、暗号化やアセットの分類、IAM権限は利用者（お客さま）が責任を持って取り組む必要がある。オブザーバビリティでも同様に、サービスが動いているか確認するためのテレメトリーはAWSが用意するが、AWSのサービスを用いてシステムを構成するならシステムのテレメトリーは利用者が整備する必要がある。
AWSでは、先述したオブザーバビリティに必要な5段階を満たすために、必要なものが提供されている。各サービスからはログやメトリクスなどのテレメトリーが提供されていて、CloudWatchに入る。これで計装、収集、送信、保存までが満たされることになる。可視化はCloudWatchから各種Insightsにかかわる製品を出しており、CloudWatchのダッシュボードから確認することもできる。
アプリケーション向けにはApplication Signals、合成監視、RUMなど広い範囲でテレメトリーを収集、送信、保存できるようになっている。またシステムやネットワーク向けには「〜〜Insights」や「〜〜Monitor」など、すでに送信・取得済みのテレメトリーがあり可視化できるようになっている。
保存と可視化ではオープンソースソリューションもある、例えばPrometheusのマネージドサービス「Amazon Managed Service for Prometheus」や、同様にGrafanaの「Amazon Managed Grafana」がある。他にもOpenSearch、Open Telemetryなどもある。オープンソースに関しては選択肢も多く、AWSはコントリビュートもしている。さらに、AWS Distro for OpenTelemetryを通じたパートナー連携もあるので、サードパーティーのサービスと連携することも可能だ。
