先日、縁あってオブザーバビリティ(可観測性)勉強会の講師を務める機会があった。普通に考えれば教壇に立つからにはその分野に大変詳しいことが期待されると思うが、恐るべきことに僕は講師を引き受けるまでオブザーバビリティについて何も知らなかった。 それで慌ててO'Reillyの『オブザーバビリティ・エンジニアリング』やCNCFのwhitepaperなどを熟読し、なんとか「完全に理解」して本番を好評で終えることができたので、記憶が揮発しないうちに肝と思われるポイントをメモしておく。マクロの思想的な側面にフォーカスして、OpenTelemetryなど個々の技術やツールのhowto的な話には触れない。
オブザーバビリティが注目される背景
現代のシステムは全ての構成要素を論理的/物理的に集約する設計（いわゆるモノリシック）から、分散されたコンポーネントの集合体で構成する設計（いわゆるマイクロサービス）へ移りつつある。マイクロサービス指向な設計の背景には、モノリシックな設計は要素間の依存が強いため高速なイテレーションでアップデートするのが難しい点や、要素ごとに異なる性能特性を持つのに対して個々の要求に応じたスケールが難しい点、特定の要素で発生した障害が(相対的に)全体に波及しやすい点などが挙げられる。また、クラウドネイティブなシステムをデザインしようとすると、クラウドプロバイダが提供するマネージドなコンポーネントも含めて必然的に分散的な設計になる側面もあるはずだ。とはいえモノリスかマイクロサービスかは程度の問題であって、完全にモノリシックなシステムも完全に分散されたシステムも現実には存在しないとは思うが、あくまで相対的に分散的な設計がトレンドであるということだ。しかし、要素を分散すれば全てが薔薇色かと言えば全くそんなことはなく、システムを構成する要素間を結ぶ複雑性が増すことで開発, 運用の両面に様々な困難が生じる問題が出てくる。運用面においては、障害時に調査するべき要素が分散している上、依存が複雑であり、しかも個々の要素が頻繁にアップデートされるため、障害の原因を特定する難易度が上がる。特に数十、数百のコンポーネントで構成され、かつそれらが個々に頻繁に更新されるサービスにおいては問題の特定に時間を要したり、結局原因がわからないまま気づけば解消し、「timing issue」などといった非論理的な整理で見なかったことにする、などといった運用が発生しがちである。
オブザーバビリティとは何か
バズワード的な側面があり全ての人間が納得する厳密な定義を見いだすことは難しいものの、僕は以下２つの定義が気に入っている。
"In control theory, observability is a measure of how well internal states of a system can be inferred from knowledge of its external outputs" [9]. Being less theoretical, it is a function of a system with which humans and machines can observe, understand and act on the state of said system. CNCF Observability Whitepaper
私たちが考えるソフトウェアシステムの「オブザーバビリティ」とは、システムがどのような状態になったとしても、それがどんなに斬新で奇妙なものであっても、どれだけ理解し説明できるかを示す尺度です。また、そのような斬新で奇妙な状態に対しても、事前にデバッグの必要性を定義したり予測したりすることなく、、システムの状態データのあらゆるディメンションやそれらの組み合わせについてアドホックに調査し、よりデバッグが可能であるようにする必要があります。もし、新しいコードをデプロイする必要がなく、どんな斬新で奇妙な状態でも理解できるなら、オブザーバビリティがあると言えます。 O'Reilly『オブザーバビリティ・エンジニアリング』1章「オブザーバビリティとは？」
つまり、システムやチームが、システムの内側で何が起きているのかを、普段から得られている情報だけで如何に説明できるかを示す尺度であるということだ。「尺度である」点は地味に重要なポイントだと思っていて、オブザーバビリティはゼロサムではなく、「オブザーバビリティが完全にない」状態もないし、「オブザーバビリティが完全である」状態もないということだ。
内部で何が起きているのかを説明するには？
CNCFのwhitepaperによれば、「Primary Signals」としてメトリクス、ログ、トレースが挙げられている。
個々の定義はwhitepaperなりを読んでもらうとして、メトリクスとログについては既に収集しているシステムが多いだろうから、多くのチームでは実質的に分散トレースの導入が「オブザーバビリティ案件」として取り組まれがちで、分散トレースの収集や可視化を行う製品やOSSが「オブザーバビリティ/APMツール」的な位置付けで理解されがちな気がする。実際トレースは重要である一方で、トレースに偏重しすぎると本質を見誤るリスクがあると思うし、そもそもオブザーバビリティは何か特定のソフトを導入すれば片付くような単純なテーマではないのだ。 まず、オブザーバビリティを得るためのSignalはメトリクス、ログ、トレースの３つだけではない。「メトリクス、ログ、トレースがオブザーバビリティの3本柱」といった表現をよく見るが、CNCFはこの言い方を改めるべきだと主張している。
There is a really good chance that you have heard about the "Three Observability Pillars", which are metrics, logs, and traces. They are an industry standard and probably what you're going to start with. We like to think of them as the "primary signals" instead of "three pillars" for two reasons: (1) pillars carry an implicit meaning that if one of the pillars is missing, the whole structure is faded to crumble, which is not true. One can safely use just two or even just one signal and still fulfil its observability goals; (2) in the last year, more signals are becoming popular in the open-source communities like application profiles and crash dumps, and today's tooling and methodologies still don't fulfil all needs of the Tech Industry. New signals may arise in the near future, and those interested in this topic should keep an eye open for them. CNCF Observability Whitepaper
CNCFがそう主張する理由は引用の通り、メトリクス、ログ、トレースはその全てが完全に収集、利用されていなければプラクティス全体が無意味になるゼロサム的なものではないため誤解を招く点と、オブザーバビリティを向上するために必要なsignalはそれら3つが全てではなくprofileやdumpといった情報も必要になる場合があるし、今後他のsignalも出てくる可能性があるためだ。 個人的にはこれらに加えて、オブザーバビリティ向上に必要となる組織文化や運用プロセスの変革といった要素が軽視されるリスクがある点も、メトリクス、ログ、トレースを強調しすぎることのリスクだと思う。ではなぜテレメトリーを集めるだけではダメなのか？、従来のモニタリングとの違いを踏まえて次項で考える。 (なお、whitepaperでも文化やプロセス面の変革が重要である点は 強調されている)
These cultural and process changes are often challenges or blockers for many organizations. On top of that, there are many methods and tools out in the market that suggest different approaches to reach a reasonable level of observability. CNCF Observability Whitepaper
オブザーバビリティとモニタリングの違い
メトリクス、ログ、トレースを集める話をすると「オブザーバビリティってモニタリングと何が違うの？」という疑問が必ず出てくると思う。僕の理解では、両者の違いの本質は問題に対する取り組み型の観点の違いだと捉えている。モニタリングでは、何らかの具体的な障害シナリオを念頭に監視点を設置する。例えば「hogehogeというエラーログが出たら障害なのでログのパターンを監視してアラートを発報できるようにしておく」とか、「メモリが枯渇したらOOMでヤバいのでメモリ使用量を監視しておく」といった具合だ。これに対してオブザーバビリティは特定の問題を事前に意識せず、いつでもシステムを丸裸にできる環境を整えておくことに集中する。それによって、もしオブザーバビリティが理想の状態にあるならば、如何に斬新で奇妙な未知の問題が発生した場合でも、システムで何が起きているかをすぐに特定できるだろうという発想だ。言い換えるならば、オブザーバビリティの計装は、原因分析の道具を提供することに主眼を置くのだ。これは一見すると個々の問題に対して遠回りに思えるかもしれないが、大規模で複雑かつ、高頻度に変化する分散システムの障害シナリオは極めて多岐に渡り、それら全てを事前に想定して監視するのは不可能に近いため、オブザーバビリティ的なアプローチが有効になってくるのだ。
ところで、『オブザーバビリティ・エンジニアリング』では、オブザーバビリティに取り組んだ成果として、Parse社の面白い事例が紹介されている。
もっとも長く在籍する人が最高のデバッガーであるということはなくなりました。もっとも好奇心が強く、もっとも粘り強く、新しい分析ツールをもっとも使いこなす人が最高のデバッガーになりました O'Reilly『オブザーバビリティ・エンジニアリング』3章「オブザーバビリティを用いないスケーリングからの教訓」
Parse社は、障害対応における一部のベテランエンジニアへの依存度が高く、依存されるエンジニアもまたある種の自己肯定感と使命感によってそれに応えてしまう、いわゆるヒロイズム的な状態に陥っていたという。それに対して、オブザーバビリティ指向な運用を取り入れた結果、在籍年数に関係なく、好奇心と能力の高いエンジニアが活躍できるようになったということだ。つまり、従来のモニタリングは既知の障害シナリオに対する監視の集積であるため、それらの情報に精通している人が効率的に対応できるものであったのに対して、先述の通りオブザーバビリティの計装は原因分析の道具を提供して、システムを丸裸にするので、それが充実していれば、道具をうまく使える人なら誰でも問題を特定できるというわけだ。
このエピソードからはオブザーバビリティの魅力と同時に難しさも読み取れると思う。何故なら、常識的に考えれば、このエピソードで語られているような状態に行き着くにはメトリクス、ログ、トレースを単に集めたり、APMを導入するだけではダメで、チームのプロセスや文化を変えていくことが不可欠だと分かるからだ。例えば、そもそも強い心でベテランに頼らないオペレーションであったり、システムに関するドキュメンテーションの整備だったり、障害が起きた際にポストモーテムを実施して、かつ必要なinstrumentationやダッシュボードを随時追加していく運用であったり、運用者がシステムを外面的に扱うだけではなくコードを読み解く/直す慣習やスキルだったり、そういったものが全て揃い、有機的に繋がって初めて、プロジェクトの在籍年数に関係なく「もっとも好奇心が強く、もっとも粘り強く、新しい分析ツールをもっとも使いこなす人が最高のデバッガー」である状態が生まれるはずだ。こうした変革の重要性はSRE NEXT2022でのLINE社の素晴らしい登壇「小さく始める障害検知・対応・振り返りの改善プラクティス」で語られている脱ヒロイズムの実践にも通じるところがある。
まとめ
オブザーバビリティは、システムの状態を把握する能力の尺度であって、その計装はシステム/エンジニアに原因分析の道具を与えることに主眼を置く。オブザーバビリティのPrimary Signalsとしてはメトリクス、ログ、トレースが挙げられるがそれが全てではなく、他のsignalの収集が有効である場合もあるし、チームの文化面、プロセス面での変革も併せて必要になる。 付言するなら、オブザーバビリティがバズワードであることや、各種APMプロバイダの利害関係などもあって「本物のオブザーバビリティはこれや！」的な論争がしばしば見られるが、CNCFのwhitepaperですらWork in progressなのだから、過度に言葉遊びに拘らず、それぞれのチーム、システムに合った最適解を見つけることが重要だと思う。
