ObservabilityとDatadogで実現したいこと

はじめに

この記事はDatadog Advent Calendar 2019の12/12分です。

DatadogのAdvent Calendarにお誘いいただいたので、誕生日にAdvent Calendar&Qiitaデビューしてみました。

今年はNoOps Meetupとか、AWS SummitとかTech-onとか、いろんなところで、入門 監視の話を聞いたので、この世界観を実現するには、PrometheusやStackdriverやDatadog何だろうなと漠然と思っていて、たまたま周りでDatadogを使っていて、ロゴの犬のTシャツが可愛いので、使い始めてみました。

と言っても、ぼく自身は世界観を語るだけで、構築そのものは他のメンバーにお任せなので、このQiitaでもDatadogで実現したいことについて書きたいと思います。

雰囲気で監視をやっていた

オンプレでの監視はサーバ、ネットワーク、OS、アプリケーションと各コンポーネントそのものの状態が正常かどうかを判断するだけで、サービスが正常なのかどうかを判断するのが難しかった。外部からのサービス監視や、アプリケーションのログ監視で何かが起きていることを把握することはできても、原因の特定や相関を見つける時なんて、個々のデータをExcelに貼り付けて時系列に並べるなんてことをやっていた。

そもそも、メトリクス、ログ、トレースもある程度システムにおけるボトルネックにあたりをつけて仕掛けないと必要な情報もとれていない。障害対応も、その後の報告のための資料作成、対策の検討も時間がかかる。

パブリッククラウドを使い始めてからも、監視対象は物理から仮想ホストに変わるだけで、ツールも同じZabbix。Datadogも使い始めたけれど、どうしても開発優先になってしまい使いこなせていない。CloudWatchやCloudWatch Logsにデータは集約されていても、アラームが上がって、どこで何が起こっているかは、メトリクスを順番に見ていかなければいけない。あの障害（素晴らしい振り返り）のときもそうだった。

そう、ぼくたちは「雰囲気で監視をやっていた」。

Observability

オブザーバビリティとは、システムが運用する上で必要な内部状態の情報を取得できる状態にあること。

「YAMAGUCHI::weblog「オブザーバビリティ（可観測性）がなぜ必要だと考えるのか」

運用する上で必要な内部の状態とは。
パブリッククラウドにおいて、インフラのメトリクスと睨めっこする必要性は減っているはずで、サーバレスで構築されることも増えてきていて、サービスが正常に稼働しているかどうか、サービスにどんな影響が生じているかどうかを知りたい。そこで何を取得するか。

SRE(Site Reliability Engineering)の説明のなかで、「意思決定にデータを用いる＝人の主観で判断しない（雰囲気で判断しない）」というのがあって、そのSREで用いる「データ」というのが、SLI、SLO、SLA、そしてエラーバジェット。

SLI (Service Level Indicator)

システムの安定稼働、ビジネスの成功に必要な指標

SLO (Service Level Objective)

SLIの許容限界値

SLA (Service Level Agreement)

SLOを達成・未達の場合の規約（SLO＋規約）

エラーバジェット

許容可能なエラー率（時間・範囲・レベル）

ビジネスの成功に必要な指標という定義があって、これまでのSLAだけを基準に障害か障害でないかを判断していたのとは大きく違っていたし、SLAがあっても少しのサービス影響も許さない、過敏な運用設計もまた過剰であった。
ビジネスが成功していることが見えて、システムが安定稼働していることもわかる、そんなメトリクスを取得・収集すること。それがオブザーバビリティ（可観測性）。

Datadogでできること

Datadogでの監視設計については、村主さんの12/2のAdvent Calendarでも紹介されていたMonitoring Modern Infractructureにほとんど書いてあるので、詳しくはそちらでということで、オブザーバビリティ観点で、Datadogで実現したいことを書いてみます。

1. Sevice毎にタグを付ける
   サービス毎の相関が見られるようにメトリクスにタグを付けておく。

2. Synthetics
   API Tests（外形監視）やBrowser Testで、APIのエンドポイント毎、エンドユーザー観点でサービスの安定稼働を確認。稼働状況をダッシュボードで表示。

3. モニタリング対象
   ワークメトリクス、リソースメトリクス、イベント、APM、ログに分けて取得対象を整理する。
   APMやログは、DevOpsにおける開発メンバーへの迅速なフィードバックにも有効。

4. SLOウィジェットでSLOに対するエラーバジェットの状況を可視化
   Syntheticsやモニタリング対象からサービスレベルを可視化。ビジネスが健全に提供できているかがわかる。

5. ビジネスのKPIもSLIとして設定する
   DAUやMAU、連携先サービスへの送客数などをダッシュボードに表示し、ビジネスの状況も可視化する。

まとめ

今回は雰囲気で監視していたところから、モダンな監視に移行する際の考え方の違いと、オブザーバビリティとDatadogで実現したいことについて書いてみました。

アラートの緊急度の話なんかも、狼少年にならないようにするために、すぐに対応が必要なものとそうでないものを明確にすることも大事だし、ダッシュボードの設計についても、かなり奥が深いので、この辺りについても、考察を深めてみたいと思ってます。

モダンな監視も運用も開発も、サービスを、ビジネスを意識するとより同じ目線で語れるので、それがDatadogというツールを通じてよりチームが一体になれたらいいなと思ってます。