オブザーバビリティについての読書会を開催しました

皆さんこんにちは。SREチームの土居です。

最近はSREチームの対応可能範囲を広げていくために、未経験分野の開拓に特に力を入れています。その中で、特に「オブザーバビリティ」については、最近よく耳にしますし、AWS Well-Architectedのチェック項目にも出てくる... いったい、導入するにはどのようなことを準備しなければならないのか？一つ上のレベルのモニタリングみたいなことなのだろうか？要するにダッシュボードで一元的にメトリクスを見るべきってこと？といった様な感じで、知らないことだらけであることに気づきました。そこで、まずは「オブザーバビリティ・エンジニアリング」の読書会を通じて学んだ上で、実際のワークロードに導入してみることになりました。今回はそこで学んだことや、導入初期の所感についてご報告します。

一言でオブザーバビリティとは

「オブザーバビリティは、デバッグが必要なコードがシステムのどこにあるかを見つけ出すためのものです」

システムがどの様な状態になっているか、それがこれまで一度も経験したことの無い状態であっても把握できること。また、システムに精通した熟練のエンジニアの経験値に頼ることなく問題の原因を調査できること。

オブザーバビリティは、システムの実装やチームの理解、APM・ダッシュボードなどのツールの準備といった観点から、システムをどの程度理解・監視できているかの能力を指します。

そのためには、システムについて知りうる可能な限りのデータ（フロントエンド側での操作、バックエンドのトレース、データベースへのクエリ...etc。）を保持し、また素早く検索できる状態を構築しておく必要があります。

カーディナリティとディメンション

オブザーバビリティの向上において、データを検索・調査しやすい仕組みが構築できていれば基本的にデータの数は多いほど良いです。
データの多さの指標としてはカーディナリティ・ディメンション※といったものがあり、それらが大きいほど、様々な切り口でシステムの状態を捉えることができます。

※カーディナリティ: あるデータの値の幅広さ（例: 真偽値は2種類しかないため、カーディナリティは低、文字列は様々なパターンが考えられるためカーディナリティは 高）
※ディメンション: データの項目の種類。（例: ユーザー名、リクエスト日時、HTTPステータスコードなど）

オブザーバビリティとモニタリングの関係

２つは全く異なるものです。
簡単に違いを表にしてみました。

オブザーバビリティの方がモニタリングよりも優れているということもなく、向いているかどうかはワークロードの性質によります。また両方とも同時に導入する価値もあります。

モニタリングは予定した閾値によるアラートという性質上、既知の問題を早期に認識することに適しています。
オブザーバビリティは、頻繁にコードがデプロイされ、変化が激しいワークロードで潜在的な問題の発見、初めて発生した問題の調査により適しています。

※第一原理による分析
哲学の概念を科学的分析に応用したもので、「何が解決したい問題か？」（例: Webサイトのパフォーマンスを改善したい）といった様な根本的な問いからスタートし、可能な限り経験的な情報（例: 対象システムを長く扱ってきたエンジニアの経験や直感）を用いずに与えられたメトリクスのみを元に分析する方法。ただし徹底的にこの方法をとる場合、すべてのディメンションとカーディナリティのパターンを総当たりで調べることになり、人間では不可能なためAIや機械学習を活用する必要がある。

導入してわかったこと

まずは実際にパフォーマンスについての課題を抱えているバックエンドAPIのワークロードにDatadog APMを導入してみました。

導入から2週間ほどデータを収集したところで、チームでダッシュボードを色々と操作してみました。早速以下の様な特徴に気づくことができました。

• 特別に遅延しているエンドポイントがほぼ３つに絞られること。
• １つのエンドポイントは、ある早朝の時間帯のリクエストのみ遅延していること。日中の時間帯では遅延は発生していないが、早朝のものとクエリパラメータに有意な違いがあること。
• エンドポイントごとにプログラムのアルゴリズム or データベースのクエリのいずれかまたは両方についてどれくらいの割合で処理に時間がかかっているか。
• 利用されていないと思っていたエンドポイントにリクエストが来ている

チームへの適用・今後

まずは1時間ほどチームでダッシュボードに触れてみて、早速認識していなかった特徴にいくつか気付くことができました。というのは一つの成果ではあるのですが、これを今後もチームで定期的に継続していき、さらに改善アクションに繋げる必要があります。

定期的にダッシュボードを確認する時間を設けるか、全てを各自の積極性に任せるか、どちらも一長一短があり難しいところです。実は一度導入したものの、結局あまり分析に時間を割くことがなく料金もそれなりにかかるため一旦削除したということもありました。今回は明確にパフォーマンス改善というわかりやすい目標があるため、まずは継続して分析していくための習慣付けをした上で改善に向けて取り組んでいけたらと思います。うまくいけば、また皆様にご報告したいと思います。

どいけん