SRE はサービス品質に影響しない程度の異常をどう扱うべきか？

今回の記事は、最近考えていたことのメモです。

ここ最近いろいろ考えていたのですが行き詰まってきたので、とりあえず課題意識を説明する文章だけ書いてみました。結論はまだありません。

障害と異常の定義

話の前に、障害（failure）および異常（anomaly）という単語を定義しておきます。人によって定義は違うと思いますが、自分が文章を書くときは以下のように区別しています。

• 障害：サービスの停止や、サービス品質の深刻な劣化を引き起こすようなインシデント
• 異常：サービスに対する深刻な問題は引き起こさないが、通常は起こらないはずのインシデント

この定義をもう少し詳しく説明するために、例として、ロードバランサと、その背後に5台のアプリケーションサーバがあるシステムを考えます。

これらのサーバが5台ともダウンしたり、半数を超える3台がダウンして応答時間が極端に長くなった（例えば10秒以上になった）場合は障害です。

一方、サーバが1台だけダウンしたものの、ロードバランサのヘルスチェック機能によって、ダウンしたサーバは自動的に切り離されたとします。その結果、ユーザにはほとんどサーバダウンが気づかれなかったとしたら、それは異常です。

障害は計測しやすく、対応しやすい

障害は、その定義からして、明確なユーザ影響が出るため、測定しやすいです。

SRE は、障害の発生度合いを表すサービスレベル指標（SLI）を定義します。例えば、サービスのダウンタイムであったり、リクエストの成功率、応答時間の95パーセンタイルなど。

また、SLI を定義したら、最低限満たすべき SLI の目標値も設定します。例えば、サービスのダウンタイムは1ヶ月あたり3.6時間、など。その目標値はサービスレベル目標（SLO）と呼ばれます。

SLO に限らず、目標値というものは「ここまで頑張らないといけない」高い目標を示すものですが、逆に言うと「ここまでは手を抜いてもいい」下限と考えることもできます。

SLO を「開発・リリースの速度を上げるために、ここまでは手を抜いていいという下限」と捉えたものが、SRE 本で紹介されて有名になった「エラーバジェット」という考え方です。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

障害は、もちろん良くないものですが、それだけに計測しやすいものです。また、エラーバジェットという考え方を導入することで、チームとしての対応を議論することができます。

異常は計測しにくい、対応しにくい

その一方で、異常はその種類が無数にあり、サービスへの影響度合いも分かりづらく、測定しにくいものです。

上で挙げたアプリケーションサーバの例でいうと、例えばこういうものが異常です。

• OSやミドルウェアのメトリクスの異常な動き
  • 例：サーバの CPU 利用率が、よくわからないタイミングで 100% まで急上昇する。ロードバランサからすぐ切り離されるから、エラーになるリクエスト数は少ない。
• 普段は出ないエラーログ、あるいは普段とは違うログ件数
  • 例：通常時は出ないログが、時々頻繁に出る。特定のユーザが入力を間違えたときに出るログのはずだが、なにかそれを引き起こす原因があるのかもしれない。
• 普段とは違うサービスの利用状況
  • 例：アクセス数が普段よりも急激に増えている。ユーザの繁忙期で一時的に増えているだけかもしれないが、今後もこのまま増え続けることを想定したシステム増強が必要かもしれない。

もちろんこれらを SLO に含めることもできます。

とはいえ、SLO の数を増やしすぎると SRE にとってチェックしきれるものではなくなります。サービス影響に直結しないので、チームの方針を決めるためのエラーバジェットとしても説得力は得にくいでしょう。

異常の数が増えていくと、いずれ深刻な障害につながる（かも）

異常の原因調査に割く時間がないので、とりあえずサーバリソースを増やして時間稼ぎをする、という経験は自分にも何度かあります。

あるいは、エラーバジェットを導入している現場なら「障害にまで発展してから、エラーバジェットの範囲内で対応したら？」と考える人もいるかもしれません。

しかし、それぞれの異常がバラバラのタイミングで起きているときは良くても、それらの異常がいくつか同時に発生したタイミングで大きな障害につながる、という可能性を自分はどうしても心配してしまいます。例えば、サーバ1台が突然ダウンする問題があるなら、サーバ3台が同時にダウンすることもあり得るだろう、という心配です。

そういう、サービス品質に影響しない程度の異常については、どう扱うべきなのでしょうか？

あるいは、それが実態の伴わない不安だとして、なにか「エラーバジェット」のような仕組みでうまく解消できるものなのでしょうか？

もやもやと考えていること

最初に書いた通り、この疑問に対する結論はまだありません。ただ、現時点でなんとなく考えていることだけメモしておきます。

メトリクスやログを見て回って、人手で異常を探すのは難しい……というか費用対効果が悪すぎて時間を割けません。なので、原因調査をすべき異常があったときだけ、何らかのアラートが欲しい。

アラートを設定するにしても、

• 何を監視すべきなのか
• 閾値をどう設定すべきなのか

という問題があります。これは異常検出（anomaly detection）や傾向分析（performance prediction）と呼ばれる技術の領域です。機械学習で、完全に設定ゼロで導入できたりしたら素晴らしいですが、そこまで実現できている現場ってあるんでしょうか……？

ちなみに、「未知のログが一定数以上発生した場合だけ、日次でレポートを送信する」といった単純な異常検出であれば、ツールを自作すればできるのでいまの現場にも導入しています。実際に使ってみると、その程度でも意外と役に立つものです。ただ、やはり障害のアラートほど重要ではないので、忙しいときは無視されがちではあります。

あるいは、異常が多いと感じるなら、それは異常の数よりも、ソフトウェアメトリクスやテストの量など、コードの品質の方を見たらいいんでしょうか。そういう、遠回りに感じるものの、障害・異常とは別の観点で見るべき話なんでしょうか？

なにかもうちょっとまとまった話が書けそうになったら、そのうちまた書きます。