クラウド環境でのアラートを考えてみよう
サービスを運用しているといろんな事象が発生しますが、それに対応するために、適宜モニタリングとアラートを設定すると思います。この記事では、クラウド上でサービスを運用する際のアラートの設計について、大まかな指針を紹介します。Google SRE 本 (*)と Workbook 本 (**) の内容をふまえたものとなっておりますので、興味のあるかたはぜひこちらもお読みください。
(*) https://sre.google/sre-book/table-of-contents/
(**) https://sre.google/workbook/table-of-contents/
特定のサービス (たとえば GCE とか GAE とか)について、何か具体的なメトリックを紹介する内容ではないので、あらかじめご了承ください。
そもそもモニタリングとアラートって？
サービスを運用していて、システムの振る舞いを把握するのはとても大事です。ユーザリクエストがどのように増えているか知りたいですし、A/Bテストを行った際の比較もしたいですよね。つまりは、後で比較検討ができるよう、システムの振る舞いを時間軸で記録・把握するのがモニタリングといえます。
そして、モニタリングしていく中で、人の対応が必要となるような状況が発生したとします。そうなった時に人に連絡するのがアラートということになります。
どういう時にアラートする?
「人の対応が必要となる」というのを掘り下げてみます。そのような状況を考えるにあたって、次の二つの視点で考えてみましょう。
- ユーザに具体的で重大な影響が発生しているか
その状況は本当に今すぐに対応しなくてはいけないほど、ユーザへの影響が発生しているでしょうか？ ごく稀なエラーで、クライアント側プログラムのリトライでユーザが気づくことなく利用を続けられる状況だったりしないでしょうか？
ごく軽微な影響までアラートして、通知の頻度をむやみに増やすのは考えものです。通知が多すぎると人間は「また来たな」と思って反応が鈍りがちです。
人間が1日の間で集中してタスクをこなせるのはほんの二、三回です。通知の頻度がそれを超えるようであれば、都度アラートの対応に時間をかけるよりも、システムの冗長性、対故障性を高める方に労力を使うべきです。
2. 人手による調査や作業が必要か？
アラートの対象は、人間が知恵を絞って対応する必要があるものに限りましょう。定型作業のためにアラートを使うのは良くないです。つまり、アラートが来た時は、今までに見たこともないような未知の事象が発生しているというわけです。
定型作業で対応できる内容であれば、自動的に実行できるプロセスを組み込み、人が対応する工程を減らしていきましょう。ユーザへの影響が大きければ大きいほど、システムが自動的に、より素早く復旧できるようにしたいですよね。
「原因」じゃなくて「症状」に対するアラート
ここまでのことを踏まえると、適切なアラートを設定するには、「今まで見たこともないような原因でのユーザへの影響」を検知できる必要があるとわかります。
ところが、未知の原因をあらかじめ知ることはできませんから、原因をもとにしたアラートを設定するのはうまくいきません。一方、ユーザから見える「症状」であれば監視できるので、そこにアラートを設定するのがより効果的です。
たとえば、あるサービスプロセスがメモリを使い切って頻繁に再起動され、その間数秒間、ユーザからのリクエストに対するエラーが繰り返し発生した、としましょう。この場合、いくつかのアラートの設定ポイントが考えられます。
A. メモリ使用量でアラート
B. プロセスが再起動されたらアラート
C. レスポンスのエラー率、エラー数でアラート
この中で A がより「原因」に近く、C がより「症状」に近いアラートとなります。つまり、A -> B -> C の順でより未知の原因にも対応できるアラートとなります。
A はメモリ・フォールトなどが原因でのプロセス再起動はアラートできません。
B は、サーバアプリケーションのアップデートなど、管理の作業としての再起動までアラートされてしまう場合があり、誤検知を避けるなど作業が複雑になることが考えられます。
それらに比べると C は、再起動だけではなく、アプリケーション・プログラムの不具合によるエラーもカバーでき、より広範囲に未知の事象でもアラートできることになります。
もちろん、原因を調査するにあたっては、A と B が監視されて記録されている必要はあります。A, B, C 全てをモニタリングの対象としつつも、アラートは C に対して行うのが良いということです。
✅ 原因より症状のアラート
参考: “it’s better to spend much more effort on catching symptoms than causes”
アラートの度合い
症状の監視にはエラー率が良さそうだということはわかりました。それでは、一つでもエラーが発生したらアラートするべきでしょうか？ 100% の成功率を求めるべきでしょうか？ アラートの度合いをどうやって決めれば良いのでしょう。
Google では 100% を目指すことは現実的ではないと判断しました。100% の達成コストは、99.999% のそれよりも非常に高くつくわりに、実際のお客様の満足度はさほど変わらないとわかったからです。
✅ 100%のヒーローなんて…
参考: “Our experience has shown that 100% reliability is the wrong target”
Google のインフラは error budget と SLO をもとに設計・運用されている
そのかわり、ある目標、例えば 95% から始めて実際に運用をしてみて、それを次第に 99%, 99.9% というように高めていく手法を採用しています。そして、ある時点で、目標を維持するコストと、それに対するリターンのバランスが良いところに落ち着かせるわけです。
このバランス点がアラートの妥協点となります。エラー率などアラートの設定にあたっては、この妥協点をあらかじめ社内のグループ間で合意しておく必要があります。その合意にもとづいて許容できる症状の範囲を定めておき、その範囲を超えたらアラートするのです。
✅ 社内で話し合って症状の許容範囲を決めよう
SLI / SLO とアラート
それでは、その合意をどのように表現すればいいでしょうか？
ここで、SLI と SLO がでてきます。
- SLI: Service Level Indicator / サービスレベルを測る指標
- SLO: Service Level Objective / サービスレベルの目標値
合意を表現するためには、サービスレベルを測るための指標 (SLI) と、その目標値 (SLO) をあきらかにします。例えば、ユーザリクエストの成功率を指標として測ることにして、その目標値を 95% 以上、と表現するわけです。
こうして目標値が SLO としてあきらかになれば、あとはおのずから、SLO が満たせないような状況になったり、あるいはそういう状況に近づいた時にアラートだすようにできます。
✅ 許容範囲 -> SLI/SLOで表現 -> アラート度合いの決定
100% じゃなくても目指せるもの
そうはいっても、一つのエラーも出さないことを目指したい人もいるかもしれません。でも無理です。だって、サービスの基礎となるハードウェアがそもそも 100% じゃないですから。
それでも、一定のエラーは不可避だと織り込んだ上で、実質的なユーザへの影響をできるかぎり減らすことは可能です。エラーを検知したら自動でリトライする、冗長構成にしておいて別のサーバーに自動接続する、などなど、障害に強いシステムのノウハウは充実しています。ゼロエラーを目指すのではなく、よりエラーに強いシステム作りを目指して SLO を 95, 99, 99.9% と高めていけば、ユーザもエラーを感じることはないはずです。
そもそも、パブリッククラウドサービスをインターネットから使う今時の環境では、エラーを起こす可能性がある箇所はどんどん増えるばかりです。オンプレであったような、信頼性の高いハードウェアに依存した作りでパブリッククラウドにそのまま移行しても、まったく同じ運用ではすまないでしょう。どのように変化させていくかの指針としても SLO は役に立ってくれます。
パブリッククラウドはその性質上、冗長化を支援する機能がたくさん提供されています。ロードバランサや複数インスタンスなどをうまく活用して、そこそこのエラーは起きる前提で、総じてユーザには影響がないシステムを目指しましょう。
まとめ
クラウドを使うにあたって、うまくアラートを設定するには SLI/SLO をきちんと定義し、それに応じたアラートの度合いを決めるのがよいです。また、SLO の対象となる指標としては、原因じゃなくて症状、つまりユーザへの具体的な影響を測れるものが良いです。そして、ある程度のエラーを許容しつつユーザへの影響がでないようなシステムの作りを目指しましょう。
余談 SLI vs SLO vs SLA: 🚂 🚂 🚂
ここまで、SLI、SLO などの用語がでてきましたが、それに SLA を含めて三つの SLx がありますね。これらはそれぞれ違うものですが、一緒くたになっているケースも見受けられます。ちょっと詳しく見てみましょう。
- SLI は「何を計るか (Indicator) 」です:
例: 今のエラーレートは 0.2% - SLO は「目標 (Objective)」です:
例: エラーレートを 0.5% 未満に常に保つ - SLA は目標値 (SLO) に対する「ビジネス的な取り決め (Agreement)」です:
例: SLO を守るよう頑張るけど、もし守れなかったら返金する
「SLO違反」とは、SLI が目標値を逸脱したということです。つまり、上記の SLO (常に0.5%未満) であれば、1% のエラーレートは SLOに違反していることになります。
一方「SLA 違反」はビジネス的な取り決めを破った、ということになります。たとえば、エラーレートが 1% になったのに返金しなかったら SLA に違反したことになります。
あくまで SLA はビジネス的な取り決めを守るかどうかなので、SLOに違反したとしてもちゃんと返金すれば 、SLA には違反していませんね。返金するという取り決めを守っていますから。
細かい違いですが、障害があったとしても、それがすぐにSLAに違反するということにはならないのでご注意ください。だいたいの場合は、SLOを逸脱したので何らかの補償があるという SLA を遵守した対応となっているはずです。
