ITの世界でオブザーバビリティが重要視されるようになった背景とは
近年注目されている「オブザーバビリティ（可観測性）」とは。もともとは現代制御理論およびシステム理論の創始者となるルドルフ・エミル・カルマン氏が定義した言葉だ。まだロボット制御を模索していた1960年代にカルマン氏が「システムがその出力から内部状態を推測できる状態」になっていることを「オブザーバビリティがある状態」だと定義したのがはじまりだ。
時代が流れ、2013年ごろからIT業界で「システムの運用の判断に必要なデータが取得できる状態」という意味で転用されるようになった。山口氏は「あくまでもオブザーバビリティとはシステムの性質や特性」と指摘する。モニタリングと混同されがちだが、オブザーバビリティはモニタリングで培われた技術スタックを活用しており、モニタリングはオブザーバビリティの一部となる。
ではなぜ、オブザーバビリティが重要視されるようになってきたのか。単一の要因だけで説明できるものではなく、また突然起きた変化でもない。主に3つの時代変化が重なり、次第に重要性を帯びてきたと言える。順に説明していこう。
コンピュータ性能の向上
コンピュータ性能が乏しいころは、OSやミドルウェアを動作させること自体に多くのリソースが割かれていた。その上で動くアプリケーションやコンポーネントの層は「薄い」イメージだ。インフラが健全に動いているかどうかが最重要で、アプリケーションも監視したいもののコストとリソースに制限があり、あまり手が回らなかった。
しかしハードウェア性能の向上、つまりスケールアップしていくと、1台のマシンで複数のアプリケーションやコンポーネントを動かせるようになってきた。
アーキテクチャの複雑化
2000年代初頭からDevOpsが活発化し、開発プロセスの自動化が進んだ。デプロイの高速化を目指すなか、コンポーネントが塊だとリリースしづらいため、疎結合化、マイクロサービス化へと動く。コンポーネントが分かれてくると、コンポーネント自体にどういうテレメトリーをとるかに視点が移っていく。ハードウェアは先述したようにベアメタルから仮想マシン、さらにはLinuxコンテナが採用されるようになることで、こちらも視点が上の層へと移っていく。
デバイスも多岐にわたるようになる。かつてシステムにアクセスするのはパソコン程度だったが、スマートフォンや家電などへとデバイスが広がり、新しい入口に対応するコンポーネントも生まれてくる。いまではひとつのトランザクションの間に、複数のコンポーネントが複雑にやりとりするようになってきている。
仕組みが複雑になるにつれ、複数のコンテナを動かす必要があり、コンテナをオーケストレートする仕組みが発達する。そのオーケストレータの管理も大変なので、マネージドサービスやサーバーレスも普及するようになり、いつの間にか下のレイヤよりアプリケーションレイヤに目が移るようになる。
複雑化したアーキテクチャだと、どこかで問題が起きるリスクを常にはらむ。いかに早急に障害の原因を検知し、対処できるかが重要になってくる。
クラウド化
かつてはオンプレミスで特定のハードウェア上でシステムやアプリケーションが動いていたが、クラウド化、さらにはマネージドサービスへと移行が進んだ。クラウドサービスではハードウェア、OS、ミドルウェアが抽象化され、リクエストに応じて増減するものという感覚になっている。それで意識はインフラよりも、どのプラットフォームで、どのサービスを使ってどうアプリケーションを動かすか、システムを構築するかに向くようになってきている。
あらためて山口氏は「ハードウェアが貴重だった時代はインフラの可用性が重視されていましたが、クラウドネイティブになるとお客さま（エンドユーザー）から見て快適に動いているかが重視されるようになりました。不特定のインフラ、インスタンスからさまざまなテレメトリーが発せられ、トランザクション経路は多様化しています。こうしたクラウドネイティブ時代のオブザーバビリティで、運用の判断に必要な情報が取得できている状態とは、アプリケーションからシステムレベルまであらゆる箇所のさまざまなテレメトリーが必要になります」と説明する。
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を通じたパートナー連携もあるので、サードパーティーのサービスと連携することも可能だ。
AWSでの大規模オブザーバビリティ事例では信頼性強化やコスト最適化も
事例（※）として、決済サービスのStripeを紹介しよう。少しの遅延も許されないため、大規模なオブザーバビリティ基盤をAWSに構築している。テレメトリーの計装、収集、送信、保存、可視化は当然のことながら、オブザーバビリティ基盤の信頼性やコスト最適化も考慮して、送信と保存の間に集約を追加し、また保存先でシャーディングや階層化も行っている。
※参考：YouTube「AWS re:Invent 2023 - Stripe: Architecting for observability at massive scale（FSI319）」
集約というのはAmazon Kinesis Data Streamsを用いて複数のテレメトリーを圧縮することでテレメトリーの数を抑えた。また階層化とは、すぐ使うデータをS3に、残りはGlacierに分け（法令対応など必要な時に出す）、コスト削減を実現した。
山口氏は「AWSは計装、収集、送信、保存、可視化の5段階だけではなく、他に必要なコンポーネントがあれば実現できるようにさまざまなビルディングブロックがあり、常に選択肢が用意されています。AWSオブザーバビリティベストプラクティスやbuilders.flashも参考にしてください」と話す。
なお、AWSではBuilder IDというアカウントがある。AWSの何らかのサービスを利用する時にはAWSアカウントが必要になるが、このBuilder IDは個人に紐付いたアカウントとなる。そのためAmazon Q Developer、Amazon CodeCatalyst、コミュニティへの参加の他にも、AWS Skill Builderの無料コースが600以上利用できる。個人に紐付いているので、転職しても利用可能だ。Builder IDで利用可能なサービスも増えているので、ぜひ登録しておくといいだろう。
