目次
はじめに
こんにちは!クラウド事業部の野村です(*゚ー゚)
ただいま運用監視、オブザーバビリティの勉強をしているのですが、言葉の定義が難しく3歩歩いたら忘れてしまいそうなのでこの場でアウトプットさせていただきます! 勝手な動機ですみませんが、お付き合いいただけますと幸いです。
今回は「オブザーバビリティ」の概念についてまとめていきたいと思います。
参考にした書籍
今回は、オライリーの「オブザーバビリティ・エンジニアリング」より第1部、第2部を参考にまとめています。 この書籍以外のサイトなどを参考にしたところは、個別に参考リンクをつけました。
オブザーバビリティとはなにか?
オブザーバビリティとはなにか?について書籍「オブザーバビリティ・エンジニアリング」ではつぎのように述べています。
システムがどのような状態になったとしても、それがどんなに斬新で奇妙なものであっても、どれだけ理解し説明できるかを示す尺度
「斬新」とか「奇妙」のあたりが少し理解しにくいですよね。
もう少しかみ砕いている説明を別のサイトで見つけてきたので、以下に引用します。
オブザーバビリティ(Observability)は、オブザーブ(Observe):「観測する」と、アビリティ(Ability):「能力」を組み合わせた複合語で、日本語では「可観測性」あるいは「観測する能力」などと訳されます。
システム上で何らかの異常が起こった際に、それを通知するだけでなく、どこで何が起こったのか、なぜ起こったのかを把握する能力を表す指標、あるいは仕組みを指します。
システムで起こっていることを、「どこで」「なぜ」のレベルまで深く洞察できるような指標、仕組みといった感じでしょうか。
ちなみに書籍では、オブザーバビリティを、「メトリクス」「ログ」「トレース」の3本柱で説明することには否定的です。ただし、現在のところ多くの監視ツールはこの3本柱を取り入れていますし、対象のシステムを適切に理解する目的をそれなければ、オブザーバビリティを高める方法について、3本柱で整理していくのも悪くないのではないかと私は感じています。
では、話を戻して、オブザーバビリティについて話を続けます。
なぜオブザーバビリティが必要なのか?
従来、システム監視はメトリクスを用いて行われてきました。そのなかで、なぜ最近はオブザーバビリティの必要性が叫ばれるようになってきたのでしょうか。
メトリクスを用いたモニタリングの限界
長く使われてきたメトリクスによるモニタリングには、つぎのような限界が指摘されています。
- メトリクスや閾値は過去に経験済みの問題を前提に作られており、予測できない問題には対応できない
- データと原因の関連性が薄いため、トラブルシューティングには、過去の事例や一番長くチームにいる人の直感が頼り
- データを個別のリクエストレベルにまで細分化して調査することが出来ない
分散システムではオブザーバビリティを導入しないと大変
システムの構成がシンプルであったころは、それでも運用できたかもしれません。
ですが近年は、クラウドネイティブのインフラサービスの導入が急速に進み、マイクロサービス、サーバーレス、コンテナといった分散システムが普及しつつあります。この分散システムでイベントをその発生源まで追跡するには、クラウド、オンプレミス、またはその両方の環境で実行されている何千ものプロセスを調査する必要があります。
いままでの監視手法とツールでは、こういった分散アーキテクチャの通信経路や相互依存関係を追跡するのはかなり難しいことです。
このような問題に対処するために、オブザーバビリティの必要性が高まってきたのです。
オブザーバビリティはどのように実現するのか?
オブザーバビリティの実現については、以下のような技術的要件があります。
- イベントに、ユニークIDや実行時間などのコンテキストを含めて、構造化イベントとしてデータを取得する
- 分散トレースを計装(instrumentation)し、あらゆるイベントをトレースとしてつなぐ
- 経験に頼らないイベント解析とその自動化
中身まで書いてしまうと壮大になってしまうので、箇条書きくらいにしておきます。。
最後に、オブザーバビリティにおいて重要な考え方である、カーディナリティとディメンションについて説明して終わりにしたいと思います。
さきに述べた通り、書籍「オブザーバビリティ・エンジニアリング」は、「メトリクス」「ログ」「トレース」の3本柱を否定していますが、「もしオブザーバビリティの3本柱を持たなければいけないとしたら、それは『高いカーディナリティ』、『高いディメンション』、『探索可能性をサポートするツール』であるべき」としているので、とても重要ということですね。
カーディナリティの役割
カーディナリティとは、集合に含まれるデータの値の一意性を表します。理想的なのは、カーディナリティが高いことです。
例えば、1億件のユーザレコードの中では、一つ一つのレコードに一意の識別子(UUID)をつけておけばそれは可能な限り高いカーディナリティといえます。逆に、性別や、人間であることなどは高いカーディナリティとはいえないですよね。
高いカーディナリティは、システムのデバッグや理解のためにデータを特定する場面で力を発揮します。また、高いカーディナリティは低いカーディナリティにダウングレードすることも可能です(例えば、姓の頭文字でまとめるなど)が、その逆はできません。
高いカーディナリティでデータをクエリ出来るようにすることで、未知の事象の探索がより行いやすくなるのです。
ディメンションの役割
ディメンションは、データ内のキーの数を意味します。ディメンションに関しても高いほど良いです。つまり、あるイベントは、それによって切り刻める何百、何千ものキーバリューのペアを持っていることが理想とされます(この状態を、「イベントが任意に幅広い」と表現する)。
例えば、あるイベントスキーマがtime、app、host、user、endpoint、statusの6つのディメンションを持っているとします。そうすると、「userがfooで、過去30分間に発生した、すべての502エラー」だったり、「appがbazで、endpointが/paymentsのリクエストを、どのホストから送信されたかを含めて」のようなものを取得できます。
もっと高いディメンションを持つことで、アプリケーション動作の隠れたパターンやリクエストの高度な相関関係を見つけられる可能性が高くなります。
所感
オブザーバビリティについて、最初は聞いたこともない言葉でした。そのため、単語の意味がスッと入ってこず苦労しました。
ネット上には情報があふれていますが、書籍を読んで、カーディナリティやディメンションの概念に触れられたのは収穫でした。ただ、実運用に当てはめてのイメージはまだあまり出来ていません。
現在Datadogを用いて、ハンズオンなども実施しているので、またその記事なども書けたらと思います。