sgykfjsm.github.com

モニタリングについて思うこと

色々思うところがあって、こんな文章を書いたけど、途中で考えが整理できなくなった。でもまぁ、脳内の考えを一旦吐き出しておいて、いつか気が向いたら、改めて書き直そうと思う。

最近、SRE(Site Reliablity Engineering)だとかなんとかでモニタリングが流行っている気がする。流行っているというか、今までもモニタリングをやっていたんだけど”SRE”という言葉が流行って行く中で、モニタリングの責任が明らかになって、より一般的になったというべきか。また、ポジションとしてのSRE(Site Reliablity Engineer)が確立し、職責として「だれがモニタリングを行なうべきか」ということも明確になったし、DataDogやMackerelなどのようにモニタリングがビジネスとして成立するようになってきたという背景もモニタリングの重要性を高めているのだと思う。あとはGrafanaなんかが提供するダッシュボードがカッコイイというのもあるかな。

で、じゃあどういう風にモニタリングしているのかというと、DataDogやMackerelのようなモニタリング・プラットフォームを利用している場合はちょっと違うかもしれないけど、自分たちで収集するメトリクスを決めて、メトリクスを収集するスクリプトを書き、アラートを設定して、というのが一般的だろう。Prometheusのような場合はコミュニティが提供するExporterを使うこともあるだろう。

モニタリングのアーキテクチャ(Pull or Pushなど)に関してもいくつか思うところはあるのだけれども、個人的にすごくモヤモヤしているのが、「とりあえず集めておく」という姿勢だ。もちろん、メトリクスを集めること自体は悪くない。データが多ければ、その分だけ検証できる内容や深みを増すことができる。しかし、一方でそれに比例してアラートも増える。ある程度の規模の会社やチームだと、こういったメトリクスやアラートは共通化されていき、次第にそれが社内のモニタリング基盤となる。

こういったシナリオは一見すると良さそうに見える。しかし、本当にそうだろうか。集めたメトリクスはサービスを超えて本当に共有できるだろうか。例えばCPUが90%を超えたとして、次に見るべきものは何か。ディスク使用量が85%を超えているという事実は大きなディスクを持つストレージサービスと比較的ディスクが少ないAPIサービスとで同じ意味を持つだろうか。また、同種のサービスであっても、稼働環境がテスト環境かプロダクション環境かによってメトリクスが示唆するものは異なるはずだ。こういったメトリクスの意味や重要性の違いは、サービスやアプリケーション、稼働環境によって異なるはずだ。そしてモニタリングの利用者は膨大なアラートの中から必要なものだけを選択していく。アラートなどによって省みられることがないメトリクスは存在しないことと同じだ。そのため、次第に多くのメトリクスはゴミデータとしてただストレージに蓄積されていく。メトリクスを収集するスクリプトやエージェントは貴重なリソースを消費しているにもかかわらず。

自分は現在、いわゆる”SRE”チームと分類される組織に所属している(“SRE”を生業にしていると明言できないのは、SREが出来ていないからだという自覚があるからだ)。だから、ここで述べる視点はサービス開発者ではなく、モニタリングを提供する側の視点となる。また、ここで問題視したいのは「とりあえず集めた」メトリクスに何の価値があるのか、ということだ。私自身の考えとしては以下の通りだ。

  • メトリクスはアクションを起こすものでなければならない
  • メトリクスは示唆をあたえるものでなければならない
  • 上記を1つも満たさないメトリクスは価値がなく、貴重なサーバーリソースを浪費するコストとなる

ここで問題としたいこと

モニタリングによって集められているデータは次の通り大きく2つに分けることができるだろう。1つは数値データだ。場合によっては数字で表現されたアプリケーションのバージョン情報ということあるだろうが、異常値あるいは閾値を設定しなければ評価できないことを考えると、数字で表現されたバージョン情報は数値データとみなすことが出来る。もう1つは”INFO”, “WARN”, “FATAL”といったような意味をもつ情報だ。この場合、情報自体が意味をもっているため、価値云々を議論する余地は無いものと考える。もちろん、付与された情報のレベルが妥当かどうかという議論は発生するが、それはここでは問題としない。なぜならば、情報のレベルはサービス開発側で予め決められているおり、すでに情報としての価値が決定されているからだ。よって、今回の議論の対象にはしない。ここで議論したいのは数値データであるメトリクスであり、それの運用についてだ。

メトリクスを運用するとは

先にも少し触れたが、メトリクスは必ずしもアラートのためだけではない。アプリケーションやサーバーの稼働状況を数値で表現し、期待通りの動作をしているかというパフォーマンスの検証に用いることもできる。この場合、どのメトリクスを見ることで期待通りの動作をしていると言えるかは一概にいえるものではないと思う。例えばWebサーバーならば処理したリクエストの数だったり、リクエストを受け取ってからレスポンスを返すまでのレイテンシかもしれない。ストレージサービスであれば、如何にディスクIOが少ないかということになるかもしれない。このように、適切な指標の決定はサービス開発者あるいはサービス開発のチームに所属にしていなければ決められないはずだ。これらを踏まえると、「メトリクスを運用する」とは「どのようにメトリクスを評価するか」ということになる。

メトリクスを評価するとは

では、メトリクスを評価するとは具体的にどのようなことだろうか。これもまた繰り返しになるが、結局のところ、サービスやアプリケーション、そして環境によって異なる。しかしながら、それでも共通する点を見出すとするならば、メトリクスの値のどこからどこまでが異常で、どこが異常と正常の閾値になるのかを決定しなければならないということだ。「評価」とはこのような決定を意味している。メトリクスの種類や収集した環境やサービスの違いにかかわらず、メトリクスの閾値は必ず設定されなければならない。

ただし、共通しているのはここまでで、ここから先、つまり決定的な閾値はやはりメトリクスだけで決まるものではない。仮に過去1ヶ月間のCPUが10%から20%で推移していたからといって、これから1ヶ月のうちにCPU使用率が30%になったら、それは異常事態だと言えるだろうか。単純な統計に基づくなら異常と言えるかもしれない。しかし現実にはそう判断できないはずだ。なぜならば、ユーザーの増加、アプリケーションに実装したアルゴリズムの変化など、「正常(起きてしかるべき)な変化」とみなす要因が常に存在しうるからだ。もちろん正常な変化だからといって、そのままにしておいて良いというわけではない。

モニタリングの提供者ができることは?

こうなってくると、メトリクスの評価はサービス開発者の専有事項となりそうだ。確かに多くの場合はそうかもしれない。サービスに携わることなくサービスを評価することは出来ないし、ましてや、そのサービスのアプリケーションが使用するリソースの多寡の良し悪しを判断することなど出来るはずもない。このような前提を基にすると、SREはどのようにモニタリングに関わることができるのだろうか?単にサービス開発者のモニタリング設定作業を代行するだけ?オンコールを受けてトラブルシューティング?そうではないはずだ。SREが文字通りにWebサイトやサービスの安定化に資するエンジニアであるならば、モニタリングにおいては主導的にならなければならないし、それは作業代行者であってはならないはず。

モニタリングを提供する側はサービス開発者に対してメトリクスを評価するための示唆を与えることができるはずだ。例えば…(ここから先は考えがまとまらなかった)

以下はメモランダム。あとで推敲して書き直す

  • メトリクスはむやみに収集するのではなく、目的をもって収集すべき。
  • メトリクスの目的はかならず共有されていなければならない。
  • メトリクスはアクションを導き出すべき
  • メトリクスが導出するアクションを具体的な手順に落とし込んだ文書があるべき
  • モニタリングの提供者はメトリクスの評価者に対して示唆を与える表現(例えばダッシュボードだったり、関連情報の添付、わかりやすいアラートメールのぶん面など)を提供するべき
  • モニタリングにはコストが発生していることを自覚するべき

これもメモランダム。なんとなくだけど、SREっていうムーブメントは、かつては「フルスタックエンジニア」と称する何かをもてはやしたり、「ビッグデータ活用」みたいな「とりあえずウチは大規模に何かやってます!」みたいな中身のない何かになってやしないかなという思いがある。もちろんSRE本がテキストとして存在しているので、これらほど適当なものではないけど、カンバンを変えただけでやってることは今まで通りだったり、逆にモニタリングをそれっぽいアプリケーションでやってるからSREと言ったり…あるいはタチの悪いところだと、リクルーティングのためだけにSREと自称しているところもありそうな気がする。

SREは特定の職能や役割を表現するものではなくて、求められる技術や経験、知識はとても幅広い。だから、個人がSREとなるというよりかは、組織がSREとなるほうが実態としては自然なのかもしれない。それはかつてDevOpsという言葉で表現していたような、ただOpsだけをやるエンジニアだけじゃなくてコードで問題を解決するというDevを取り込むようなチームづくりと基本的な考え方は同じかもしれない。縦割りの組織じゃなくて、横方向に人材を広げて組織として役割の柔軟性や弾力性を持たせる。そうすることでサービス開発者の足元を確かにし、成功への道筋を確かにしていくような役割。SREはスーパーエンジニアの代名詞などではなくて、そういった弾力性に富んだ組織のことを意味するのではないかなぁと思うけど、それって別にSREって表現しなくても今までにも必要とされたし、成功している組織には当たり前にいるんだろうな。

とりとめがないので、このへんで。もう少し考えを整理する必要がある。