この記事は Mackerel Advent Calendar 2021 の17日目の記事です。
Mackerel SREチームの
id:masayoshi です。
今回はAWS ECSとALBで構築したWebアプリケーションを例に、Mackerelを利用したSLI/SLOの設定、運用改善に利用できる機能やツールを紹介したいと思います。
今回紹介する機能やツールの概要図です。
まずは、ECSで動いているWebアプリケーションのSLI/SLOを考えていきましょう。
最初から複雑なSLI/SLOを設定、実装するのは難しいため、簡単に取得できるメトリックや監視設定から運用を始めていき、徐々に監視を改善していくことをおすすめします。
ここでは、以下のようなSLI/SLOを設定したと仮定して、メトリックの取得する方法など見ていきましょう。
- レイテンシー
- HTTPレスポンスの90%が100ms以内
- 可用性
- HTTPステータスコードが5xx以外の割合が99.9%
Mackerelでメトリックを収集する
SLI/SLOを設定したら、次はMackerelのメトリックとして取得できるように設定していきましょう。
最初はMackerelとAWSの設定だけで達成できる外形監視とAWSインテグレーションを利用するのが良いでしょう。
①外形監視
外形監視はMackerelから実際にHTTPリクエストを送り、応答時間やエラーを計測する機能です。
今回の例ならALBへHTTPリクエストを送り、その応答時間をMackerel側で計測します。
外形監視の設定方法は以下を参照してください。
外形監視のメリットは以下の3点です。
- Mackerelの設定だけで簡単に始められる
- DNSによる名前解決など、実際のユーザーリクエストに近い監視が利用できる
- 障害がすぐにわかる
自分たちのサービスのインフラ環境とは別の環境から定期的にリクエストを送り監視する仕組みを作ることは手間がかかりますが、Mackerelなら設定だけ追加すれば実現できます。
また、実際のHTTPリクエストを元にレスポンスタイムや5xx系エラーなどが出ないかを計測できるので、簡単に実際のユーザーリクエストに近い監視が利用できるため、設定可能な環境であれば積極的に利用していきましょう。
1分に1回リクエストしているので、サービスの全体的な障害が発生した場合は、他の手法にくらべると比較的早く障害を検知しやすいです。
一方で以下のようなデメリットがあります。
- インターネットからアクセスできる場合にしか使えない
- 1回のリクエストの計測値を利用するため、リクエスト全体の統計値を取ることはできない
- 実際のサービスで提供する全てのエンドポイントに外形監視を設定するのは難しい
デメリットをまとめると、外形監視は設定に付き、1つのリクエストを元に算出する(サンプル数が1)ので全体の把握には不向きです。
そのため、外形監視のリクエストが100ms以内だとしても、90%のリクエストが100ms以内かどうかは判断できません。
また、外形監視以外のエンドポイントのステータスコードの割合なども把握ができません。
外形監視はTopページなど重要なページをピンポイントに監視し、この後に紹介するSLIなどと一緒に利用し全体を把握できるようにするようにしましょう。
②AWSインテグレーション
AWSインテグレーションは、AWSの各サービスをMackerelのホストとして自動的に登録し、メトリックを取得する機能です。
AWSインテグレーションを利用することで、ALBのメトリックを取得することができます。
設定方法は以下のページを参照してください。
- Webコンソール画面からの設定
- Terraformによる設定
AWSインテグレーションのALBメトリック一覧は以下を参照してください
AWSインテグレーションのメリットは以下の2点です。
- MackerelとAWSの設定だけでホストの登録とメトリックが取得できる
- ALBのメトリックでレスポンスタイムの90,95,99%ileとHTTPステータスコードカウントがある
すべてのHTTPリクエストが通るALBのカウンターをメトリックにできるので、外形監視では難しかったリクエスト全体の統計値が取得できます。
特にレスポンスタイムは90,95,99%ileの値がメトリックとして利用できるので、「HTTPレスポンスの90%が100ms以内」かどうかを判断できます。
ステータスコードは、後述する式グラフ、式監視を利用することで、全体リクエスト数と5xxリクエスト数からエラー率や可用性を計算することができます。
一方で以下のようなデメリットがあります。
- エンドポイント毎などレスポンスタイムの統計など細かい集計はできない
ALBが出力するメトリックをMackerelで取得しているため、ALBが出力していないメトリックが必要になった場合はAWSインテグレーション機能のみではカバーができません。
MackerelでSLOを確認しアラートを出す
SLIが取得できたので、SLOをもとに監視設定をしたり、カスタムダッシュボードを利用してチームで定期的に確認できるようにしましょう。
③式グラフ、式監視
式グラフ、式監視を利用するとMackerelにあるメトリックから更に割合や平均などを計算した値をグラフや監視設定の閾値にすることができます。
今回の例だと式グラフ、式監視でAWSインテグレーションで取得したALBのステータスコードカウントを計算することで、「HTTPステータスコードが5xx以外の割合が99.9%」かどうか判断できるようになります。
実際に式グラフでALBのステータスコードの割合を算出する式グラフの例は以下を参照してください。
④カスタムダッシュボード
カスタムダッシュボードでグラフをまとめることができます。
今回の例では、「HTTPレスポンスの90%が100ms以内」と「HTTPステータスコードが5xx以外の割合が99.9%」かどうかを判断したり推移が確認できるグラフをまとめておくと便利でしょう。
アラートが出ていなくても推移を開発チームと運用チームで定期的に確認したり、場合によってはSLOを見直すことも重要です。
例えば、Mackerelチームでの運用ではプロダクトオーナー、開発チームのアプリケーションエンジニア、SREが集まって2週間に1回これらのダッシュボードを見直すPWGという会を実施しています。
PWGは今年のアドベントカレンダーでも話題に出たので参考にしてみてください。
さらに改善していこう
ここまでの機能で、「HTTPレスポンスの90%が100ms以内」と「HTTPステータスコードが5xx以外の割合が99.9%」の2つのSLIを取得し監視設定をすることができるようになりました。
簡単なSLI/SLOの実装、運用なら、MackerelやAWSの設定のみで実現できることが結構あるので、まずはこれらの機能で実現できる範囲から始めると良いと思います。
一方で、HTTPのエラーコードだけではなくて、アプリケーションのエラーをログに出力して、その数を集計した値をアプリケーションエラー数としてSLIにしたい場合や、
APIによって応答速度が違ったり、プロダクトにとっての重要性が違ったりするので、パスごとに応答速度を集計したい場合などもあると思います。
またSLOを運用する場合、実際には30日で99.9%の可用性など、ある程度の期間内で達成しているかを確認する必要があります。
この場合、実際99.9%の可用性を達成できていなかった時間がどれぐらい存在したか(=エラーバジェットをどれだけ消費したか)を計測する必要があります。
これらのより詳細なSLIを取得するためのツールやエラーバジェットを計測しSLO運用を手助けするツールを紹介します。
⑤cloudwatch-logs-aggregator
cloudwatch-logs-aggregatorはCloudWatch Logs Insightsのクエリを実行し、結果をMackerelのメトリックに変換し投稿してくれます。
主な利用方法は、アプリケーションログにエラーやリクエスト数、ジョブ実行数など出力し、それらをSLIにしたいときに利用します。
外形監視やAWSインテグレーションに比べて、以下の点でメリットがあります。
- 外形監視やALBのメトリックなどではなく、アプリケーションのエラー数など自分たちで実装しカスタマイズしたメトリックを使うことができる
ECS Fargateではコンテナのログを簡単にCloudWatch Logsに出すことができるため、外形監視やALBのメトリック以外をアプリケーションログに出力した上で、cloudwatch-logs-aggregatorを利用することでMakcerelにメトリックを投稿できます。 ログ出力の仕方次第でより詳細なSLIを実装できるため、柔軟なSLI/SLO設計が実現できます。
一方で以下のようなデメリットがあります。
- cloudwatch-logs-aggregator をLambdaやECSで別途動かす必要がある
- アプリケーションでSLIとして利用できるように集計しやすい形でログ出力をしなければいけない
- ログを正確に集計できるようになるまで少しラグがある
外形監視やAWSインテグレーションと違い、自分たちでcloudwatch-logs-aggregatorを動かす必要があったり、SLIを意識したアプリケーションを書く必要があるため、難易度は自然と高くなります。
また、CloudWatch Logs Insightsの仕様ですべてのログを集計できるようになるには1~5分程度のラグがあり即時性は外形監視に劣ります。
外形監視やAWSインテグレーションを設定した上で、更に詳細なSLIが必要な場合はぜひ検討してみてください。
より詳細な設定例などは今年のアドベントカレンダーを参照してください。
⑥SQL => Mackerel
前述したように、AWSインテグレーションで取得できるALBのメトリックではパスごとの集計などはできず、ALBに来るトラフィック全体のSLIしか設定できませんでした。
パスごとの集計をしたい場合は、ALBのログを集計してSLIにする必要があります。
これを実現するには、Athenaを利用してS3のログをSQLで集計し、その結果をMackerelに投稿するツールが必要となります。
今年の公開は間に合わなかったのですが、Mackerel SREチームで利用している「sqlの結果をmackerelのメトリックとして投稿するツール」(社内ではsql-metric-collectorと呼んでいます)を、今後OSSとして公開したいと思っています。
今回の例のようにAthenaの結果や、MySQL、PostgreSQL、BigQueryなどの結果をMackerelに投稿できるツールの予定ですので公開をお待ちいただければと思います。
メリット、デメリットはcloudwatch-logs-aggregatorとほぼ同様にカスタマイズができる利点があり、構築難易度や即時性が外形監視、AWSインテグレーションに劣ります。
現在Mackerelではログを投稿できる機能はないですが、AWSのログストレージをそのまま使いながら集計したメトリックをMackerelで扱うためのツールを提供したいと思っています。
⑦shimesaba
最後に今年のアドベントカレンダーでも紹介されたshimesabaです。
shimesabaは特定の期間内で、SLO違反をしていた時間を算出(=エラーバジェットをどれだけ消費したか)を計測し、メトリックとしてMackerelに投稿してくれるツールです。
今回の例では簡単にするため、期間を設定していませんでしたが、実際のSLOの運用では30日などある程度の期間で計測をします。
例えば障害があって、5分程度サイトが落ちていたとしても、前後30日の間で障害が発生していなければ可用性99.9%を達成することができます。
現在のMackerelの監視では、(ある程度、式監視でカスタマイズできますが)基本的にその時点のメトリックを元に判定をするため、前後30日の可用性を監視するのが少し難しいですが、shimesabaを使えばエラーバジェットがメトリックとして投稿されるので、そのメトリックを元に監視設定することもできるようになります。
これからSLI/SLO運用を始める人がいきなり使う必要はないかもしれませんが、SLO運用を改善していく中でそのうち考慮する必要がでてくると思いますので、その際はshimesabaを検討してみてください。
詳細は作者様のエントリを参照してください。
まとめ
今回はAWS ECSの環境を例にSLI/SLO設計と運用を始めるにあたって、Mackerelで利用する機能や改善するためのツールを紹介しました。
最初は設定が簡単な機能を使って計測を開始し、プロダクトの開発状況やチームの運用力に応じて徐々に利用する機能やツールを増やしてSLI/SLOを改善していきましょう！
また、Mackerelチームから今後も継続的に運用改善のためのツールを提供したり、ユーザーコミュニティから誕生したツールなどを紹介してければと思っております。
