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

前回は、モニタリングの必要性や妥当な値とは何かについて、見ていきました。
妥当な値が設定されたモニタリングによって出されるアラートは、ユーザーに混乱を与えず、必要なことを伝え、かつノイズの少ないものになると学びました。
今回は、質の高いアラートを出すための観点から見ていきます。

症状と原因

モニタリングシステムは、２つの疑問に答えなければなりません。それは、何が壊れたのか、なぜそれが壊れたのか？という疑問です。¹

基本的なことかもしれないですが、まずこの観点が重要だと思います。
明確にユーザーに何が原因になっているのかを伝えることが大切です。逆に自分が受けての際は、これに問題があるのだと訴えてきているとしっかり受け取ることが大事だと思いました。
また、認識が間違っていたなと思うことは、エラーが出た際にエラーが原因で動かないというのは、間違っていると思いました。エラーとは、ただの症状です。エラーを見た際に、なぜそのエラーが出ているのかを読みよることが重要だと思いました。

症状と原因の例

また、上の例でレスポンス速度が低下したことの原因をCPUに負荷がかかっているとしましたが、これも直接的な原因ではないです。本当の原因は、アクセスが増えたからであり、アクセスが増えたのは、人気のコンテンツが掲載されたからであり、人気のコンテンツになったのは、メディアで取り上げられたからであり、。。。

ブラックボックスとホワイトボックス

モニタリングの方法には、ブラックボックスモニタリングとホワイトボックスモニタリングの2種類が存在します。
ホワイトボックスは、ログやHTTPエンドポイントといったシステム内部の機能を調査することができます。
ブラックボックスは、システム内部の構造が見えず、システムの振る舞いや実際に起きている問題について、表現します。
この二つは、それぞれ利点があり、ホワイトボックスの利点は、システム内部を直接みることができるので、内部に隠されてしまっている問題や近々生じることになりそうな問題を検出できます。
ブラックボックスの利点は、それがユーザー目線のモニタリングになるということです。ユーザーに直接影響を与える問題に密接しているため、良いアラートトリガーになります。

４大シグナル

次の４つがモニタリングの際に特に重要なシグナルとなります。
ユーザーが直接利用できるシステムで、メトリクスを４つだけ計測できるなら、この４つに集中すべきです。

レイテンシ

リクエストを処理して、レスポンスを返すまでの時間です。
この時、成功したリクエストと失敗したリクエストを区別する必要があります。
例えば、データベースなどのクリティカルな接続が失われたことによるエラー（500エラー）は、きわめて高速で返されます。ここで全体のレイテンシをこれを含んでしまうと正確にレイテンシを計測することができません。
また、低速なエラーと高速なエラーでは、低速なエラーの方が悪いことが多いです。
ユーザーへの重要度（解決の優先度）の為、エラーだけでなく、エラーのレイテンシまで区別する必要があります。

トラフィック

システムに対するリクエストの量です。
webサービスの場合、通常毎秒のHTTPリクエスト数で計測されますが、静的なリクエスト、動的なリクエストなど、リクエストの性格によって、区別されます。
それぞれのシステムにあった方法で計測する必要があります。

エラー

処理に失敗したリクエストのレートです。
失敗には、さまざまなものがあり、サーバー内でエラーが起きたことによる明示的なエラー（500エラー）や200の成功レスポンスが返されているが、内容に誤りがある場合、またポリシーとして、1秒以上のレスポンスはエラーとした場合、エラーになります。
レスポンスコードがすべての状態を表せるわけではないので、障害の状態を追跡するためには、2次的なプロトコルが必要になる場合があります。

サチュレーション

サービスの飽和、サービスがどれだけ「手一杯」になっているかを表します。
最も制約になるリソース（メモリが少ない、CPUの性能が低いなど）に重点を置いて、利用率を計測します。たいていの場合、利用率が100%になる前にパフォーマンスが低下します。なので、負荷試験を行い、レイテンシを計測することで、早い段階でサチュレーションをとらえることができます。

まとめ

• モニタリングでは、ユーザーへ症状と原因を伝える必要がある。
• 4大シグナル（レイテンシ、トラフィック、エラー、サチュレーション）

参考文献

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