この記事は、Mackerel Advent Calendar 2023 の9日目の記事です。
qiita.com
Mackerelのアドベントカレンダーですが、Mackerelの文字がないタイトルなので違和感を感じられた方もいらっしゃるかもしれません。
このブログではUSE Method / RED Methodと呼ばれる監視・パフォーマンス分析の方法論についてまとめようと思います。
そもそも、なぜ監視・パフォーマンス分析の方法論について知っておく必要があるのでしょうか?
システムを運用している私達は当たり前のようにメトリクスを取得し監視ルールを作成している訳ですが、監視自体が目的ではなく監視によって何かの目的を達成したいわけです。
- (1) システムを監視することで、障害影響の軽減ひいては障害の回避によるサービスの可用性向上に繋げたい
- (2) システムにおけるボトルネックになっている箇所を特定・解消することで、パフォーマンスを改善しユーザー体験の改善を図りたい
- (3) システムの挙動を正確に理解することで、トラブルシューティングの効率を向上させたい
- etc...
監視の目的は様々ありますが、目的によって何をどのように監視するかは変わってきます。
例えば、(1)の例は内部状態をあまり意識することなく、外部から見てシステムが正常稼働しているかを確認するブラックボックステスト的な監視を行うことになりますが、(2)や(3)の例はシステムの内部状態を詳細に把握するためのメトリックやホワイトボックステスト的な監視を実現するための監視ルールが必要になると思います。
今回ご紹介するUSE Method / RED Methodでは、監視の目的とそれを踏まえた対象が整理されています。これらの方法論を利用することで、自分達の監視目的に合致した監視を設計・実装しやすくなるという意味で方法論を知ることは重要であると筆者は考えています。
私はMackerelの開発チームに所属していますが、Mackerelのユーザーの皆様にMackerelを利用してより良い監視を設計・実装するための一助となればとの思いから、今回このようなブログを執筆しています。
USE Methodとは
USE Methodは、Brendan Gregg氏により提唱されたシステムのパフォーマンス分析の方法論です。下記の3つの指標で構成されています。
- 使用率 (Utilization)：リソースが処理中でbusyだった時間の平均
- e.g.) CPU, Disk utilization
- 飽和状態 (Saturation)：リソースが実行しなければならない作業量
- エラー (Error) : エラーイベントの数
- e.g.) Network interfaceにおけるlate collisionの発生数
USE Methodの定義は、Brendan Gregg氏のウェブサイトにもまとめられていますのでこちらもどうぞ。
USE Methodの特徴
USE Methodの特徴としては、内部的な状態に焦点を当てた監視、つまりホワイトボックステスト的な監視の方法論であることが挙げられます。これはUSE Methodがシステムのパフォーマンス分析における利用を想定しているからも想像がつくかと思います。
The USE Method can be summarized as:
For every resource, check utilization, saturation, and errors.
It's intended to be used early in a performance investigation, to identify systemic bottlenecks.
また、先述の引用箇所に記載があった通り、リソース単位での監視が念頭にあります。RED Methodにおけるリソースは「物理サーバーにおけるコンポーネント(CPU、Disk etc.)」を指します。
Terminology definitions:
resource: all physical server functional components (CPUs, disks, busses, ...) [1]
[1] It can be useful to consider some software resources as well, or software imposed limits (resource controls), and see which metrics are possible.
USE Methodはツールベースのアプローチと比較されており、USE Methodは特定のツールに依存することなくcomplete view (不足のない監視項目・観点) を提供するとまとめられています。
While this can be fairly effective, one problem is that it relies exclusively on available (or known) tools, which can provide an incomplete view of the system.
The user is also unaware that they have an incomplete view - and so the problem will remain.
The USE Method, instead, iterates over the system resources to create a complete list of questions to ask, then searches for tools to answer them.
A more complete view is constructed, and unknown areas are documented and their existence known ("known unknowns").
RED Methodとは
RED Methodは、Google AnalyticsのSREであったTom Wilkie氏が提唱した監視についての方法論です。下記の3つの指標で構成されています。
- レート(Rate) : 秒間あたりのリクエスト数
- エラー(Errors) : リクエストの失敗数
- 時間(Duration) : リクエストの処理にかかった時間
RED Methodの特徴
RED Methodの特徴としては、外部から見た時の振る舞いに焦点を当てた監視、つまりブラックボックステスト的な監視の方法論であることが挙げられます。
また、もう一つの重要な特徴としては、サービス単位の監視であることが挙げられます。RED Methodでのサービスという単語の定義としては、マイクロサービスを念頭に置いたシステムにおける独立して機能するサービスと同義です。
これらは、2018年に行われたGrafanaCon EUでのTom Wilkie氏の登壇に関するレポート記事の中でも述べられています。
https://grafana.com/blog/2018/08/02/the-red-Method-how-to-instrument-your-services
“The USE Method doesn’t really apply to services; it applies to hardware, network disks, things like this,” Tom said. “We really wanted a microservices-oriented monitoring philosophy, so we came up with the RED Method.”
“You model this for every single service in your architecture, and this gives you a nice, consistent view of how your architecture is behaving.
USE Method / RED Methodの比較
先述の説明を踏まえると、USE MethodとRED Methodでは下記のような比較ができることがわかりました。
このように並べると、どちらの方法論が優れているというような議論になるかもしれません。しかし、USE Method / RED Methodに関しては、どちらか片方ではなく監視目的に応じて両者を併用する、使い分けることがポイントになります。
先述のTom Wilkie氏の登壇に関するレポート記事でも、本人のコメントとして下記のような発言があります。
https://grafana.com/blog/2018/08/02/the-red-Method-how-to-instrument-your-services
Tom recommended using the USE and RED Methods together. “It’s like the RED Method is about caring about your users and how happy they are,” Tom said, “and the USE Method is about caring about your machines and how happy they are. It’s really just two different views on the same system. They’re complimentary.”
MackerelでのUSE Method / RED Methodの実践例
さて、このブログはMackerelのアドベントカレンダーの一記事なので、Mackerelについても触れておこうと思います。
USE Method / RED MethodをMackerelで実現するには、どのような機能・ツールが利用できるでしょうか?
例として、ALB + EC2 + RDSで構成されたシステムを想定して考えてみようと思います。記事の主題の都合上、このパートでは機能・ツールの紹介に留めさせていただきます。
USE Method
USE Methodにおいて取り上げられている監視指標について、Mackerel-agentによって取得されるシステムメトリックやAWS integrationや各種プラグインによって取得できるメトリックが利用可能かと思います。
システムメトリックについては、mackerel-agent をインストールすると自動的に投稿されます。
mackerel.io
ALB + EC2 + RDSの構成で利用されているサービスはいずれもAWS Integrationでのメトリック取得の対象となっています。
mackerel.io
また、RDSに関しては、DBMSに応じたメトリックプラグインを利用することも可能となっています。
mackerel.io
RED method
USE Methodにおいて取り上げられている監視指標について、ALBを利用している場合はAWS integrationの機能でRequest CountやHTTP Code Countをメトリックとして取得することが可能です。
mackerel.io
RED Methodで取り上げられているような指標がアプリケーションログで表現されている場合は、cloudwatch-logs-aggregator, sql-metric-collectorの利用も検討されると良いかと思います。
各ツールの詳細な説明は、下記記事をご参照いただければと思います。
mackerel.io
mackerel.io
最後に
いかがだったでしょうか? 本記事では、USE Method / RED Methodと呼ばれる監視・パフォーマンス分析の方法論についてご紹介させていただきました。本記事が皆様の監視設計・実装の参考になれば幸いです。
明日は id:wtatsuru さんです。
id:taxintt
id:lufiabb
id:onk
