オブザーバビリティを実現するメトリクスとは何か？
DevOpsやクラウド適用が進む中で、開発者の中でも注目を集めているキーワードの一つにオブザーバビリティがある。日本語では可観測性と訳されるように、いかに起きた問題を適切に捉えて、正確な対処につなげるための能力である。
セキュリティやIT運用のためのログ管理ツールを提供してきたSplunkも、いち早くオブザーバビリティに参入し、クラウドネイティブ・マイクロサービス時代のオブザーバビリティプラットフォーム「Splunk Observability」を提供している。
Splunk Observabilityの特徴は、「3つある」と大谷氏。一つはリアルタイム性。「メトリクスのリアルタイム性は非常に重要で、Splunkではストリーム技術を用いてリアルタイム性を実現しており、この点が非常に優れている」と語る。第二はNoSampleトレースによる分析力。サンプリングせずに、環境に関するすべてのデータを忠実に計測および収集できること。第三はOpenTelemetryに完全準拠していることである。
「Splunkのスポンサーセッションだが、製品の紹介はこれでほぼ終わり」と語り、大谷氏はオブザーバビリティを実現する3本柱の一つ、メトリクスの説明へと進んだ。
メトリクスとは時間の経過とともに変化する測定可能な数値。「例えば10秒間の平均のレスポンスタイム、1分間のCPU使用率など、特定の時間間隔の統計値。これが、日頃皆さんがメトリクスと呼んでいるものの中身」と大谷氏は説明する。
メトリクスは「ゲージ」「カウンター」「累積カウンター」という3つのデータ型がある。ゲージとは特定の瞬間の値。「例えるなら車のスピードメーターみたいなもの」と大谷氏。次のカウンターは何かが起こるたびに増加する値。「リクエストカウントなどが代表例」（大谷氏）。3つ目の累積カウンターとは累積されるカウンター。1分間のカウンターだと、次の1分の計測が来るまでにリセットをする必要がある。だが、そのリセットするタイミングが非常に難しい。そこで累積カウンターを使い、その中で1分間を切り取る方法でデータを集計する方法が使われる場合がある。
「他にもサマリーみたいな形でデータ型を定義することもあるが、基本的なデータ型はこの3つ」（大谷氏）
メトリクスのデータモデルは、ディメンション（メトリックのメタデータを指定するキーと値のペア）、データポイント（ある時点でのメトリックデータ）、メトリック時系列（MTS：まったく同じデータ型、メトリック名、ディメンションの組み合わせを持つデータポイントのセット）で構成される。
ではダッシュボードに表示したり、アラートを出したりするために、どのようにクエリするか。その方法はいろいろある。例えばメトリック名でクエリをかけたり、ディメンションによってフィルターをかけたりすることはもちろん、集計や計算もできる。「合計、平均やパーセンタイル値、データポイント間の差分などを描画することもできる。そのほかにも、ディメンションによるGroup-by、割合など値同士を使った計算ができます」（大谷氏）
時間範囲と時間的解像度も描画することができる
これらのことができるために、メトリクス処理基盤の性能に求められる重要なポイントは3つ。まずはカーディナリティ、つまりどのくらい細かい情報のデータを管理できるかである。次に重要なのが、保持期間と時間的解像度。時間的にどのくらい細かいデータをどのくらいの期間管理できるかがポイントになる。第三はリアルタイム性。「リアルタイム性についてはわかりやすいので、カーディナリティと保持期間について解説していきたい」と大谷氏。
カーディナリティとは、メトリックスの個々の値の数。言葉にすると難しいが、例を見るとわかりやすい。そこで大谷氏は、Webサーバのリクエストカウントを例に取り次のように説明した。「レスポンスのステータスコードごとに集計している状況で、レスポンスのステータスコードが200と300の2種類あるとする。そのステータスコードごとにリクエストカウントを1分に1回集計するとする。その場合のカーディナリティは2となる」（大谷氏）
ある時点で500エラーが発生したとする。そうなるとリクエストカウントのスレー＋コードの種類は3つに増える。カーディナリティは3になる。このようにユニークな値、組み合わせがどれだけあるのかがカーディナリティである。
「面白いポイントは、ディメンションの数が増えたからといって、カーディナリティが増えるとは限らないところ」と大谷氏。例えば東京とパリにサーバホストが10台ずつ動いていて、ホストネームは完全にユニークモノが割り当てられているとする。ではこのカーディナリティはいくつになるか。答えは20である。「カーディナリティは高ければ高いほど、さまざまな分析ができるようになる」（大谷氏）
次は保持期間と時間的解像度。「これはソリューションによってパワーに差が出るところ」と大谷氏は話す。到達したデータポイントは、特定の時間的改造で丸められ、時間経過とともに細かい解像度のデータは破棄するケースも多いからだ。
オブザーバビリティを実現するために――メトリクスの実用例を紹介
このように便利で使いやすいツールであるメトリクスだが、限界もある。第一は非常に高いカーディナリティのデータには向かないこと。requeset.countをユーザーごとに見るのはその一例だ。「どういうユーザーがどのぐらいのリクエストを出しているか見るために、ディメンションを安易に追加してしまうと、カーディナリティが爆増してしまい、クエリも時間がかかるようになる」（大谷氏）
メトリクスの実用例として、StatsDの活用が挙げられる。StatsDは2011年ぐらいからブログなどでも紹介されている、UDP/TCPで送信されるカウンターやタイマーなどのメトリクスを受け付け、Graphiteなどのバックエンドの時系列データベースなどに送信するサービスである。
インターフェースはシンプルなので、「いろいろな言語のクライアントに実装やインテグレーションされている。かなり歴史あるツールだが、現在もさまざまな現場で活躍しているのではないか」と大谷氏は言う。
StatsDはGraphiteやOpenTelemetry Collector、Prometheusとも容易に連携できる。例えばOpenTelemetry Collectorであれば、2行ほど追加するだけで、メトリクスがレポートできるようになる。「詳しく知りたい方は、『入門OpenTelemetry Collector』で検索すると私の過去コンテンツが読めると思う」と大谷氏。
また、SaaSによっては「利用料金が跳ね上がることもあるので、注意が必要」と大谷氏は警鐘を鳴らす。第二に、状況の把握には限界があること。例えばCPU使用率が上がったことは分かるが、その理由についてはメトリクスだけで把握することは難しい。だが、ログやトレースなど、他のテレメトリデータを合わせて利用することで、その限界を低減できる。
OpenTelemetry Collectorではなく、Prometheusを使っている人も増えている。そんな人にオススメなのが、Prometheus＋OpenMetricsという組み合わせ。Prometheusはメトリクスを扱う、オープンソースのシステム監視・アラームツールキットである。「特徴はpull型アーキテクチャであること」と大谷氏。
HTTPでリクエストを受け付けるexporterを監視対象に備えることで、エンドポイントにリクエストを出してその内容をよい加減で集計して、アラートを出したりダッシュボードに表示したりする。
「Kubernetesとの親和性がかなり高く、各種ツールとの連携も豊富。Prometheusの環境を整備すれば、ほぼメトリクスに関してはカバーできる。そんなエコシステムになっている」（大谷氏）
前述したように、Prometheusはexporterで監視対象からメトリクスを集約する。そのPrometheusのエクスポートの仕組みを切り出して、整理するためのプロジェクトがOpenMetricsである。「エンドポイントの仕様の整理をはじめ、メトリクス名やデータモデルの整理もしてくれる」（大谷氏）
Prometheusを使って何ができるのか。その例として大谷氏が示したのが、Spring Bootのサンプルアプリケーション「Spring PetClinic Sample Application」。これをそのまま動かすと、各サービスはMicrometerでメトリクスを計測され、micrometer-registry-prometheusでエクスポーズ、Prometheusがスクレイプし、Garafanaで可視化できる。「Prometheusの中身はシンプルだが、パワフルで拡張性が高い形で動かすことができる」（大谷氏）
さらにOpenTelemetryとPrometheus環境と組み合わせて使うことも簡単にできることもデモを通じて紹介。「opentelemetry-demo-webstore」を使えば、OpenTelemetry Collectorを通じて、PrometheusやJaegerで管理できる環境が比較的すぐに立ち上げられる。また、OpenTelemetry Collectorを少し変更するだけで、Splunk Observabilityをはじめ、任意のバックエンドにメトリクスをエクスポートできるようになる。「少しの変更で、Prometheusを使っている環境からバックエンドを切り替えることができる。それがOpenTelemetryを活用する面白さ」と大谷氏は語る。
最後に大谷氏は「メトリクスは古典的なツールだが、改めてそれがどんなツールなのか、それを理解した上で別のツールとどのように使い分けていけばいいのか、それらの点を意識して便利に使ってほしい」と語り、セッションを締めた。
