※この記事は、Luup Advent Calendar の11日目の記事です。
最初に
こんにちは、Luup SREチームの峯岸です。
今回はLuupのSREチームにて行っている「SLI/SLOの導入」への取り組みについて記載したいと思います。
LuupのSREチーム紹介で記載しているように、SREチームはインフラ品質や信頼性を高めることを目的に動いております。
その中のミッションの1つに「組織全体へのSLI/SLOの導入」があり、その導入に向けてSREチームは日々奮闘しております。
そこでLuupとしてSLI/SLOの導入に向けて、Datadogの利用を検討しました。
この記事ではDatadogの利用にあたる背景や目的、検証内容について記載したいと思います。
※SREおよびSLI/SLOについてはLuupのSREチーム紹介に記載しておりますので、「SREとは何か」「SLI/SLOとは何か」などの説明はなるべく割愛いたします。
※IoTの仕組み、細かい用語の説明に関しても割愛いたします。
Datadog導入検討の背景・目的
LuupとしてDatadog導入を検討した背景・目的は以下になります。
- 今後組織全体にSLI/SLOを導入し、SLOに対するアラートを設定したい
- インフラ環境としては主にAWSとGCPを使っており、監視自体はそれぞれのクラウドが提供する監視ツール（Cloudwatch/CloudMonitoring）を使っている
- 単純な監視項目としてCloudwatch/CloudMonitoringのメトリクスは有効であるが、SLOに適したアラートの設定や運用は難しい
- Datadogの機能としてSLOのモニタリング設定を行うことが可能であるため、SLOのモニタリング設定の使用感を確かめたい
- Datadogは利用状況に応じて課金が発生するため、上記を実装した場合のDatadogのコスト感も確かめたい
検証の目標
Luupは一部の車両においてAWS IoTを用いております。
LUUP のシステム構成図(21年12月時点)
Datadogはインフラからアプリケーションまでさまざまな監視ができますが、トライアルの短い期間でインフラからアプリケーションまですべてを網羅した検証はできません。
今回はトライアル期間にて「Datadogの継続利用の有無」を判断をするため、
以下の範囲に絞ってSLOモニタリング設定の使用感・コスト感の確認の検証しました。
- Cloudwatchに蓄積されているAWS IoTのCloudwatchメトリクスをDatadogに転送できること
- Datadogに転送したCloudwatchメトリクスを元にSLOモニタリングを設定できること
- 上記の実装に係るコストを計算したこと
導入手順
1. Datadogアカウントを発行し、AWSアカウントをインテグレーションする
公式ページの「無料で試す」からアカウントを作成できます。
Datadog公式ページ
AWSアカウントのインテグレーションは以下の手順から実行できます。
AWSアカウントのインテグレーション
2. CloudwatchメトリクスをDatadogに送信する
CloudwatchメトリクスをDatadogに送信する方法は2つあります。
メトリクスのポーリング: AWS インテグレーションで利用できる API ポーリングです。CloudWatch API をメトリクス別にクロールしてデータを取得し、Datadog に送信します。新しいメトリクスの取得は平均 10 分毎に行われます。
Kinesis Firehose でのメトリクスストリーム: Amazon CloudWatch Metric Streams と Amazon Kinesis Data Firehose を使用してメトリクスを確認します。注: このメソッドには 2 - 3 分のレイテンシーがあり、別途設定が必要となります。
簡単な比較表が以下になります。
| 方法 | データ取得の流れ | 転送間隔 | 課金 |
|---|---|---|---|
| メトリクスのポーリング | Datadog→AWS(Cloudwatch) | 10分 | リクエストされた 1,000 件のメトリクスごと 0.01USD |
| Kinesis Firehose でのメトリクスストリーム | AWS(Cloudwatch→Kinesis)→Datadog | 2~3分 | 更新された 1,000 件のメトリクスごと 0.003 USD（※） |
※KinesisDataFirehoseの利用料金（取り込みデータ量1GBあたり0.036USDより）も合わせて必要になります。
「メトリクスのポーリング」はDatadog側でのメトリクスの取得に大幅な遅延が発生するものでしたが、その後「Kinesis Firehoseでのメトリクスストリーム」の実装により、素早くメトリクスを取得できるようになりました。
課金についてはメトリクスの更新間隔およびデータ容量にもよるため一概に比較はできませんが、今回はKinesisを経由することで転送間隔が短くSLOアラートの遅延が少なくできるため、Kinesis Firehose でのメトリクスストリームの検証をしました。
Kinesisを用いた構成図概要は以下になります。
【メトリクス転送フロー】
① 電動キックボードやCloud FunctionsがAWS IoT Coreにアクセスする。
② AWS IoT Coreに蓄積された各種データがCloudwatchのAWS/IoTメトリクス名前空間へ送信される。
③ Cloudwatch Metrics Streamを用いてAWS/IoTメトリクスをKinesis Data Firehoseに転送する。
④ Kinesis Data Firehoseに溜まったデータがDatadogへ配信される。
AWSアカウントのインテグレーションおよびKinesis Firehoseでのメトリクスストリームの設定手順は公式ページをご確認ください。
Cloudformationを用いることで、IAMロールを含めて配信設定を簡単に実装できます、Cloudformationでの設定をオススメします。
取得したメトリクスをもとに以下のようなダッシュボードを作成しました。
なお「メトリクスのポーリング」はAWSアカウントをインテグレーションした時点で実装されるものになりますが、「Kinesis Firehoseでのメトリクスストリーム」への切り替えをした場合は、自動で取得方法が変更されるようになっております。
API ポーリングメソッドを通じて特定の CloudWatch ネームスペースのメトリクスを既に受け取っている場合、Datadog は自動的にこれを検出し、ストリーミングを開始するとそのネームスペースのメトリクスポーリングを停止します。Datadog は引き続き API ポーリングを使用して、ストリームされたメトリクスに対してカスタムタグや他のメタデータを収集するため、AWS インテグレーションページの構成設定は変更しないままにしておきます。
引用:API ポーリングからメトリクスストリームへの切り替え
これでCloudwatchメトリクスをDatadogに転送できました。
3. 転送したCloudwatchメトリクスを元にSLOアラートを設定する
SLOアラートを設定する場合、以下の前提があります。
- SLI/SLOの具体的な数値が定まっていること
- SLI（対象のメトリクスやイベントデータ）がDatadogに収集されていること
LuupではAWS IoT CoreのSLIを以下のように定義しました。
- AWS IoT CoreのSLI計算式
| メトリクス名 | 説明 | SLI計算式 | フィルター |
|---|---|---|---|
| MQTT(※1) PublishIn Success Rate | broker(※2)によって正常に処理されたpublish request | count(PublishIn.Success) / (count(PublishIn.Success) + count(PublishIn.AuthError) + count(PublishIn.ClientError) + count(PublishIn.ServerError)) | protocol=MQTT |
| MQTT PublishOut Success Rate | brokerによって正常に発行されたpublish request | count(PublishOut.Success) / (count(PublishOut.Success) + count(PublishOut.AuthError) + count(PublishOut.ClientError)) | protocol=MQTT |
| MQTT Connect.Success Rate | brokerとのクライアント間の正常に行われた接続 | count(Connect.Success) / (count(Connect.Success) + count(Connect.AuthError) + count(Connect.ClientError) + count(Connect.ServerError)) | protocol=MQTT |
| MQTT Subscribe.Success Rate | brokerによって正常に処理されたサブスクリプションのリクエスト | count(Subscribe.Success) / (count(Subscribe.Success) + count(Subscribe.AuthError) + count(Subscribe.ClientError) + count(Subscribe.ServerError)) | protocol=MQTT |
| MQTT Unsubscribe.Success Rate | brokerによって正常に処理されたサブスクリプション解除のリクエスト | count(Unsubscribe.Success) / (count(Unsubscribe.Success) + count(Unsubscribe.AuthError) + count(Unsubscribe.ClientError)) | protocol=MQTT |
| Http xxx(車両の識別子をマスクしております) Success Rate | CloudFunctionsの呼び出しイベント | count(Success) / (count(Success) + count(Failure)) | rule_name=xxx, action_type=Http |
上記計算式でSLIの値を出し、SLO（SLIに対して達成すべき割合と期間の目標値）を決めます。
そのSLOに対し、バーンレート（※3）を指定します。
- バーンレートの指定
| severity | バーンレート | 長いウィンドウ | 短いウィンドウ | 消費される理論上のエラーバジェット | このバーンレートが継続した場合バジェットが枯渇するまでの時間 |
|---|---|---|---|---|---|
| Critical | 14.4 | 1 時間 | 5 分 | 2% | 約2日 |
| Critical | 6 | 6 時間 | 30 分 | 5% | 5日 |
| Warn | 3 | 24 時間 | 120 分 | 10% | 10日 |
※1 メッセージ指向ミドルウェアのアプリケーション層で使用される、TCP/IPによるPub/Sub型データ配信モデルの軽量なデータ配信プロトコル。
引用：Wikipedia
※2 MQTTをサポートするサーバ。
※3 障害が発生してから、ユーザーがエラーの影響を受け、エラーバジェットがすべて消費されるまでの速度。
引用：SLOバーンレート
DatadogでのSLOのアラート設定（エラーバジェット、バーンレート等の用語を含め）に関しては以下の記事が非常に分かりやすいです。
メルカリのエンジニア情報ポータルサイト:お客さま影響に基づく実践的なアラート方法
結果として以下のようなダッシュボードを作成し、SLOアラートを設定しました。
最初からSLI/SLOを明確に設定することは困難なため、ある程度は決めうちで設定をし定期的な見直しな行うことが必要です。
SLI/SLOの定義により対処すべき項目が浮き彫りになったため、今後の品質改善に役立てていきたいと思います。
総評
今回はじめてDatadogの検証をした上で、以下のメリットを感じました。
- Cloudformationの定義ファイルがあらかじめ用意されていているため、AWSアカウントのインテグレーションからメトリクス収集まで容易に設定できる
- Datadogダッシュボード、アラート設定のカスタマイズ性が高い
- AWS以外の他クラウドサービスとの親和性も高く、あらゆる監視を一元管理できそう
反対にコスト観点での以下のデメリットを感じました。
- 実際に発生した金額がいくらかになる月の途中で把握できないため、発生したコストが把握しにくい
Datadogは発生した請求金額を通貨ベースで確認できないため、「一ヶ月内で〇万円超えたらアラートを出す」などのコストアラートは設定できません。
実際にクレジットカード等に請求された金額をもとに料金表から計算することが必要になります。
もしくは一定使用量（推定使用量メトリクス）を超えた場合にアラートを出すという運用は可能なようです。
https://docs.datadoghq.com/ja/account_management/billing/usage_metrics/
https://docs.datadoghq.com/ja/logs/guide/logs-monitors-on-volumes/
総評としては、サービス規模に応じて発生するコストを許容できるのであれば、SLI/SLOのモニタリング機能としてDatadogを使うことは非常に有効なツールと感じました。
最後に
SLI/SLO導入のためのDatadog検証について、簡単な説明ではございましたがいかがでしたでしょうか。
DatadogはAWSやGCPだけではなく数多くの3rdParty製品との親和性が高いため、今後さまざまな監視の検証に取り組んでいきたいと思います。
弊社では現在SREの採用やカジュアル面談を積極的に行っていますので、ご興味がございましたらお気軽にお問い合わせください。
明日は12日目、@t-kurimuraさんの記事になります。
Discussion