アドベントカレンダー13日目:SREを読んでみた「分散システムのモニタリング」編③

  • 2020.12.16
337
NO IMAGE

前回の内容を振り返ると、モニタリングシステムは、ユーザーに対して、何が、なぜ壊れたのかに答える必要がありました。その手法には、ホワイトボックスとブラックボックスあり、4大シグナル(レイテンシ、トラフィック、エラー、サチュレーション)に焦点を当てる必要があるということを学びました。
今回は、モニタリングシステムを構築する際の観点について、学びます。

0から作るモニタリングシステム

モニタリングシステムを0から構築するとしたら、何を考えるべきでしょうか?
前回の内容を踏まえると、4大シグナルをモニタリングする必要がまずありそうです。
レイテンシに注目した時、レイテンシの定義は、リクエストを処理して、レスポンスを返すまでの時間なので、その値を測定して、そのまま返せばとりあえずユーザーがレイテンシを観察することはできます。しかし、モニタリングシステムならば、何かしらの値をトリガーとして、通知しないといけないです。通知の基準はどのように設定すべきでしょうか?
最終的に以下のような機能をもつシステムになるかもしれません。

  • さまざまなメトリクス、レイテンシの閾値、パーセントタイルによるアラート
  • 考えられる原因を検出して知らせるための追加コード
  • 考えられる原因のそれぞれに関連するダッシュボード1

適切な粒度の選択

メトリクスやレイテンシ、パーセントタイルの計測にあたって、適切な粒度を選択する必要があります。
以下に過剰となりうる粒度で設定された例が挙げられます。

  • 1分ごとのCPUの負荷を観察しても、高いテイルレイテンシを生じさせるスパイクは、それが長時間であっても、見つけられないかもしれません。
  • 一方、年間で合計9時間未満の停止時間(年間稼働率99.9%)をターゲットとするWebサーバーの場合、200(成功)のステータスの確認頻度を1分間に1回か2回以上にするのは、やり過ぎでしょう。
  • 同様に、99.9%の可用性をターゲットとするサービスのハードドライブの空き容量のチェックは、1分から2分に1回以上にする必要はありません。1

このように、モニタリングしたい値により、適した粒度は異なります。
CPUの負荷を毎秒計測することは、収集、保存、分析のコストが大きくなります。
それほど細かい粒度でなくてもかまわないのなら、粒度を大きくすることでコストを抑えることができます。

シンプルにする、ただしやり過ぎない

モニタリングシステムに限ったことではないですが、システムの要件を積み上げていくと、とても複雑なシステムが出来上がります。
複雑すぎるシステムは、脆く、変更するには複雑で、メンテナンスコストが高くなっていきます。
そのため、モニタリング対象は以下のガイドラインが参考になります。

  • 本当のインシデントを最も頻繁に捉えるルールは、可能な限りシンプルで、予想しやすく、信頼できるものであるべきです。
  • ほとんど実施されない(例えば、SREチームによっては、四半期に1回未満が目安です)データの収集、集計、アラートの設定は削除すべきです。
  • 収集されてはいても、事前に作成されたダッシュボードのいずれにも表示されず、どのアラートにも使われていないシグナルは、削除の候補です。1

まとめ

  • モニタリングの粒度は適切に選択する
  • モニタイングシステムは、シンプルに保つ

参考文献

  1. Betsy Seyerほか SRE サイトリライアビリティエンジニアリング オライリー 63-66