はじめに
株式会社スタディストSREチームの@katsuhisa__です。前回記事「SREをはじめるには、まずどうすればいいですか？ SREに必要なスキルと取り組み方」では、SREのはじめかたについて、スキルと取り組み方の両面から皆さんにお伝えしました。主に概念や文化的な部分を重点的に解説いたしました。
本記事では、より実践的なSREへの取り組み方をご紹介します。具体的には、前回記事後半で触れた「サービス信頼性階層」をもとに、以下のポイントを紹介していきます。
- モニタリングのデザイン
- SLO（サービスレベル目標）の決定
最後までお楽しみください。
モニタリングのデザイン
前回記事の最後に、「サービス信頼性階層」について触れました。サービス信頼性階層は、サービスを信頼できるものにするための要素を階層化したものです。本記事では、サービス信頼性階層の第一層であるモニタリングについての考え方をご紹介します。
モニタリングを実装する際に最も大切なこと
モニタリングを行うのは、サービスが信頼できる状態であることを確認するためです。では、サービスが信頼できる状態であることを確認するには、何をモニタリングすればよいでしょうか？ この問いに答えるために、うってつけの書籍の日本語版が2019年1月に出版されました。
本書では、デザインパターンの一つとして「ユーザ視点での監視」が推奨されています。
Apacheのノードが何台動いているか、ジョブに対していくつのワーカが使用可能かといったアプリケーションの実装の詳細をユーザは気にしません。ユーザが気にするのは、アプリケーションが動いているかどうかです。
- 引用：『入門 監視』２章 監視のデザインパターン
つまり、まず実装するべきは、対象システムのユーザに影響のある状態を把握するためのモニタリングです。CPU使用率や、メモリ使用率をモニタリングするのは、何が問題かを分析する手がかりにはなりますが、ユーザに何かが起きているかどうかを確実に検知することはできません。例えCPU使用率が高くても、ユーザのリクエストを正常にさばけていれば、それで問題はないのです。
モニタリングのメトリクスを考える
ユーザ視点での監視が大事であることは分かりましたが、では、具体的に何をモニタリング対象として実装すればよいのでしょうか。書籍『Site Reliability Engineering』にそのヒントとして「The Four Golden Signals」という考え方が記されています。
The four golden signals of monitoring are latency, traffic, errors, and saturation. If you can only measure four metrics of your user-facing system, focus on these four.
筆者訳
モニタリングの4つの黄金のシグナルは、レイテンシ、トラフィック、エラー、サチュレーション（飽和）です。ユーザー向けシステムの4つのメトリクスしか測定できない場合は、これら4つに注目してください。
- 引用：The Four Golden Signals（Site Reliability Engineering）
ここで紹介されているThe four golden signalsについて、順に見ていきましょう。
レイテンシ
リクエストを処理するのにかかる時間のこと。ちなみに、SRE本では、成功したリクエストのレイテンシと失敗したリクエストのレイテンシを区別することが重要であると書かれているので、ご興味ある方は読んでみるとよいでしょう。
トラフィック
システムにどれだけのリクエストが集まっているかを示すメトリクスです。
エラー
エラーリクエストの割合のこと。エラーリクエストは、具体的にはHTTPステータスコードが5XX番のリクエスト、または、ポリシーとして失敗とみなすリクエスト（例えば、1秒以上のレイテンシを要するリクエストはエラーと見なす、など）です。
サチュレーション
最も制約のあるリソースに着目し、そのリソースの飽和状態を測定します。多くのシステムでは、成約のあるリソースの使用率が100％に近づくとパフォーマンスが低下するため、使用率の目標を設定するとよいでしょう。
これからモニタリングを実装する多くの方にとって、The Four Golden Signalsは有用な観点となるでしょう。サービスの信頼性をモニタリングする取っ掛かりとして、どれも最適なメトリクスだと思います。
ただし、サチュレーションに関しては、具体的なモニタリング対象として、何を見ればよいのかピンとこない方も多いのではないでしょうか。システムにおける最も成約のあるリソースをはじめから判断することは、容易ではありません。しかし、ご安心ください。これら4つのメトリクスのうち、サチュレーションを除いた3つのメトリクスからはじめれば問題ありません。Google AnalyticsのSREであったTom Wilkie氏（ソフトウェア監視ツールKausalのFounder）も、彼が提唱するモニタリングメソッドREDメソッド[1]を紹介するブログで以下のようにコメントしています。
Google include an extra metric, Saturation, over and above the RED method. I don’t include Saturation because, in my opinion, it is a more advanced use case. I think the first three metrics are really the most important, and people remember things in threes… But it you’ve mastered the first three, by all means include Saturation.
筆者訳
Google（The Four Golden Signals）には、REDメソッドに加えてサチュレーションという追加のメトリックがあります。私の考えでは、それはより高度なユースケースです。私は最初の3つのメトリクスが本当に最も重要であると思います。しかし、最初の3つを習得したのであれば、サチュレーションを含めるようにしてください。
[1] REDメソッドとは
アーキテクチャ内のすべてのマイクロサービスについて測定する必要がある3つの主要な指標（Rate、Errors、Duration）の頭文字を取った用語。
- Rate：1秒あたりのリクエスト数
- Errors：1秒あたりのエラー数
- Duration：各リクエストにかかる時間量の分布
それぞれ、The Four Golden Signalsのレイテンシ、エラー、トラフィックに対応する。
SaaSをうまく使おう
ここまで読んで、モニタリングのメトリクスとして何を見ればよいかをご理解いただいたと思います。しかし、どうやって実装するんだろう……と途方に暮れてしまった方もいるでしょう。
安心してください。モニタリングシステムは、すべてをゼロから自分たちで構築する必要はありません。モニタリングシステムを買えばよいのです。なぜなら、我々の多くは、モニタリングシステムを構築するプロではありませんし、自前で構築すると多少なりとも運用コストも発生します。であれば、はじめからその道のプロがつくったモニタリングシステムを買うことで、私たちはサービスの信頼性向上により集中することができます。要は、餅は餅屋にというわけです。
前述した書籍『入門 監視』には、「実践 監視 SaaS」と題した付録が収録されています。この付録は、サーバ管理・監視サービスとして有名なMackerelのプロダクトマネージャー、及びチーフエンジニアである松木雅幸氏（@songmu）が執筆しており、これから監視SaaSの購入を検討する多くの人にとって役立つ内容がまとめられています。
