The RED Method: key metrics for microservices architecture

マイクロサービスのキーメトリクス

前回のブログの投稿では、RED Method（レッドメソッド）について軽く触れました。このRED Method（レッドメソッド）はWeaveworkでのモニタリング哲学です。このブログでは、RED Method（レッドメソッド）とは何か、なぜそれを使うのか、そしてどこから来たのかを詳しく説明したいと思っています。

What is The RED Method?

RED Method（レッドメソッド）は自分の構造の中の全てのマイクロサービスのための自分が計測すべき３つの重要なメトリックスを定義するものです。

・(Request) Rate-自分のサービスが行っている一秒ごとのリクエストの数

・(Request) Errors-一秒ごとの失敗したリクエストの数

・(Request) Duration-それぞれのリクエストタスクにかかる時間

それらのメトリックスを計測することはとても簡単です。特にPrometheus (もしくは Weave Cloud’s hosted Prometheus service)のようなツールを使う時は簡単です。以前にもブログで Weave Cloudにどのように自分たちのサービスをインストールするのかについて書いたので、ここでは説明を控えます。

RED methodの他のメリットとしては、ダッシュボードの作り方を考える時に役立つという点です。この３つのメトリックスをそれぞれのサービスの中心におき、エラー率はリクエスト率の割合として表されるべきです。Weaveworksでは、ダッシュボードのためにすごく基本的なフォーマットを設定していました。２つのコラム、１サービスあたりの、左のリクエストとエラー率、右のレイテンシー:

私たちはダッシュボードを作るためにPythonライブラリ(GrafanaLib)も作りました。

Why The RED Method?

全てのサービスのために同じメトリックスを計測すべきなのは、どうしてですか？確かに、それぞれのサービスは特別ですか？モニタリングの観点からして、それぞれのサービスを同じように扱う利点は、自分のオペレーションチームの中でのスケーラビリティです。もしあなたが、Weaveworks、すなわち私の仲間のデベロッパーたちや私自身のようであれば…。

オペレーションチームのスケーラビリティとはどういう意味ですか？私は「どのくらい多くのサービスを一定のチームがサポートできるのか」という観点からこの問題を見ています。理想的な言葉を使うと、「そのチームがサポート可能なサービスの数はそのチームの大きさには関係ない」ということです。しかし、その反面他の要因が関係してきます。「どんな種類のSLAレスポンスが必要なのか」ということに起因します。例えば24/7カバレッジが欲しいなど・・・。だから、そのチームの規模とサービスの数をどういうふうに分離するか、ということです。それには、すべてのサービスを同じように見せて、同じように感じさせる必要があります。こうすることで、チームが必要なサービス特化型のトレーニングの数を減らし、「コグニティブ・ロード」と言われているプレッシャーの高いレスポンス状況のためにすぐに記憶する必要があるサービス特化型の特別なケースを減らします。

これは余談ですが、もしすべてのサービスを同じものとして扱うと、多くの繰り返しのタスクは自動化になります。キャパシティプランニング？それに関しては、QPSの機能、レイテンシーとして、行ってください。プレイブックがエントリーするためのリンクがあるダッシュボードとアラートと、それらのダッシュボードは？自動的にそれらを作ります。

Where does The RED Method come from?

この哲学には、どんなクレジットも当てはまりません。というのもこれはGoogle SREとして自分が学んだことが100％土台になっているからです。Googleはそれを「４つのゴールデンシグナル」と呼んでいます。そのGoogle SREブックは、みんなに広く読まれていて、すごく深い内容になっています。

Googleはその他のメトリック、サーチュレーションなどRED methodを越えたものを含んでいます。私はサーチュレーションを含めていません。というのも私の考えでは、サーチュレーションはもっと進んだ使用例だからです。私は最初の３つのメトリックは一番重要なものであるし、みんなにもきちんと覚えてもらいたいと思っています。でも、最初の３つのメトリックをマスターしてしまったら、ぜひサーチュレーションも加えてください。

「The RED Method」という名前はBrendan Gregg氏の USE Methodから始まりました。これもまた時間がある時に読んでみてください。私たちがWeave Cloud を始めたとき、そしてUSE Methodをどのようにモニターしようかと話し合っているときに、出始めました。自分が提案していたモニタリングのストラテジーのための何かいい名前がないかと思っていました。そこから、The RED Methodが生まれました。USE Methodはリソースをモニタリングする方法としてはすごくいい方法です。私たちは、Weave Cloudの後ろにあるインフラストラクチャーをモニタリングするフレームワークとして使っています。しかし、サービスということになると、オブストラクションは少し無理があると思います。

Limitations

このメソッドがリクエスト主導のサービスのためだけの機能だということを言っても語弊はないと思います。というのも、バッチ指向（一括処理指向）、もしくはストリーミングサービスなどに分類されます。そして、全てを網羅しているわけではありません。他のものをモニタリングする必要なときもあります。USE MethodはホストCPUやメモリー、キャッシュなどのリソースを提供するときの素晴らしい例です。

Orangesys.ioでは、kuberneteの運用、DevOps、監視のお手伝いをさせていただいています。ぜひ私たちにおまかせください。