Site Reliability Engineering – 10章 時系列データからの実践的なアラート

こんにちは、つるべーです。
先日、福岡のインフラ界隈のエンジニアの方々がやっているSRE本の輪読会に参加し、発表をさせていただいたので、その時の内容をまとめます。
私は、10章の「時系列データからの実践的なアラート」を担当させてもらいました。

はじめに

なぜ「時系列データからの実践的なアラート」が必要かを考えてみた。
Webサービスの大規模化や複雑化に伴い、サーバ台数の増加やシステム構成の複雑化が進んだことで、サーバのメトリクス等の情報を高解像度かつ長期間保持したいという要望が高まっている。また、サーバのメトリクスをより統計的に解析し、アラーティングの精度を向上させたいといったシーンも増え、時系列データベースに溜め込んだデータを用いた柔軟なアラーティングの需要が高まっているのではないだろうか。

概要

• 10章ではBorgmonと呼ばれるGoogleの内部システムについての話が中心だが、「アラートを発するためのデータソースとして時系列データを扱う」という発想は、汎用性が高く、最近ではPrometheus、Riemann、Heka、BosunといったOSSのツールを通じて広く受け入れられている。
• 大規模なシステムにおいて如何にメンテナンスコストを抑えながら、適切なモニタリングを行うかが重要である。
• 大量の時系列データを継続的に収集することで、アラーティングの精度・柔軟性を高めることができる。

まとめノート

大規模システムのモニタリングが難しい理由

• 単にモニタリング対象となるコンポーネントの数が多すぎる。
• システムに対する責任を負うエンジニアのメンテナンスの負荷を低く保つ必要がある。

大規模システムの場合、1台のマシンが不具合を起こしているくらいでアラートを発するのはノイジー過ぎる。（きちんと冗長化されている場合の話だが）
大規模システムでは、個々のコンポーネントの管理を求めるのではなく、データを適切な粒度で集約して、異常値のみを拾い上げるべきである。
また、必要に応じて個々のコンポーネントの調査もできる粒度に情報を保っておいてくれるようなモニタリングシステムが求められる。

10.1 Borgmonの誕生

• 大量の収集を行うためにメトリックスのフォーマットは標準化されている必要がある。
• 単一のターゲットに対する全てのメトリクスの収集を1回のHTTPのフェッチで行えるように定められている。 /varzエンドポイントを叩くとメトリクスが取得できる。

$ curl http://webserver:80/varz
http_requests 37
errors_total 12

10.2 アプリケーションのインスツルメンテーション

• 全てのエクスポートされた変数をkey/value式のプレーンテキストで返す
• スキーマレスなテキストベースのインタフェースは、新しいメトリクスを追加するのが簡単である
• ひとつの変数に対して複数のラベルをつけて出力できるようになった。 例えば、HTTP200のレスポンスが25件、500のレスポンスが12件の場合、下のように出力される。

http_responses map:code 200:25 404:0 500:12

10.3 エクスポートされたデータの収集

• Borgmonでは、サービスディスカバリを利用してモニタリング対象のリストを動的に生成するため、リストのメンテナンスコストが下がり、モニタリングのスケーラビリティを高めることができている。
  サービスディスカバリを有する点はPrometheusも同じ。PrometheusにはAWS、Azure、GCP、OpenStack、Kubernetesなど多種多様なプラットフォームのメタデータを元にサービスディスカバリすることができるし、Consulとの連携もできる。
• Borgmonは一定間隔ごとにターゲットのエンドポイント（/varz）を叩いて、結果をメモリに貯める。（Pull型の監視）
• データの収集をHTTP経由で行っているのは、HTTPのオーバーヘッドが問題になるケースはほとんどないことや、そもそもメトリクスが取れないことそのものを シグナルとして利用することができるからである。

10.4 時系列のアリーナにおけるストレージ

• データポイントは(timestamp, value)という形式を持ち、 時系列データ と呼ばれる時間順のリストとして保存される。
• それぞれの時系列データはname=valueという形式で、ユニークなラベルが付与される。 時系列データの概念は、時間と共に進んでいく数値からなる1次元の行列（列ベクトル）であり、変数に対して複数のラベルの組み合わせを追加すると、多次元の行列になる。
• Borgmonは全てのデータをインメモリデータベースに保存し、定期的にチェックポイントを実行して、時系列データベース（Time-Series Database: TSDB）にアーカイブされる。 Borgmonでは、TSDBに対してもクエリを実行できる。TSDBはインメモリデータベースより低速だが、低コストで大容量である。

時系列データとは（補足）

時系列データとは、時間の推移ととともに観測されるデータのこと。世の中の実務の現場に貯まっていく多くのデータは時系列のデータである。
ITインフラの現場においても、サーバのメトリクス、ネットワークトラフィックなどといった時系列データが時々刻々と蓄積されている。
データ分析において、隣り合う時刻の観測値同士には明らかに相関関係がある（時間依存性を持つ）時系列データの取り扱いは、他のデータ（クロスセクションデータなどと言われる）に比べて、理論的にも実銭的にも難しいとされている。

時系列データベースとは（補足）

時系列データの保存・処理に特化したデータベースである。
Webサービスの大規模化に伴うサーバ台数の増加や、複雑化により、高い解像度の様々なメトリクスを長期間保持したいという要望や、サーバのメトリクスをより統計的に解析し、アラーティングの精度を向上させたいという要望などがあり、時系列データベースの需要が高まっている背景がある。

もちろん、時系列データを格納するためにバックエンドとして、MySQLのようなRDBMSを使用することもできるし、RRD（ラウンドロビンデータベース）のような時系列データに特化したデータベースもある。しかし、最近の時系列データベースでは共通して、時系列データの符号化方式や、メモリもしくはストレージの使用法などのアーキテクチャに工夫がなされており、 ストレージ容量の節約や、解析時に使用するメモリ量の削減などの効果を上げることができる。 また、ほとんどの時系列データベースにおいて、SQL等をベースにしたデータ解析の方法が用意されているという特色もある。

【参考】

• 時系列データベースに関する基礎知識と時系列データの符号化方式について
• 今後の負荷を RRDTool を使って予測してみよう

階層型のデータストアアーキテクチャについて（補足）

データの保持期間に応じた階層型のデータストアアーキテクチャは、時系列データの保存においてはいくつか事例も見受けられる。

【参考】

• Gorilla: A Fast, Scalable, In-Memory Time Series Database
• 時系列データベースという概念をクラウドの技で再構築する

10.4.1 ラベルとベクタ

• 時系列データの名前はラベルセットである。ひとつの時系列データをユニークに探すためには、最低でも次のラベルが必須である。

var    ：変数名
job    ：モニタリング対象のサーバー の種類
service：サービスを提供するジョブの集合
zone   ：データを収集したBorgmonのデータセンタ

これらをまとめて、以下のように変数式として表現できる。

{var=http_requests,job=webserver,instance=host0:80,service=web,zone=us-west}

• 時系列データに対するクエリでは、これらのラベルセットに対して検索を行うと、マッチする全ての時系列データが返される。

10.5 ルールの評価

• Borgmonルールと呼ばれるBorgmonのプログラムコードは時系列データから別の時系列データを算出する。
• ルールの書き方自体は特に重要でない。 ポイントは、「10分間におけるHTTPエラーの比率」といったように、適度な幅で集計をしている点である。（さらにその幅は自由に調整できる）これは時系列にデータを溜め込んでいるからできる。

10.6 アラート

• 「10分間のエラー率が1%以上で、1秒に1回以上のエラーが 2分以上出るときにアラートをあげる」といったことができるのも時系列データを溜めているからできる。

10.7 モニタリングのトポロジーのシャーディング

• Borgmonは他のBorgmonから時系列データをインポートできる。そのため、データセンターごとにBorgmonで監視対象の時系列データを取得して、グローバルなBorgmonが各データセンターのBorgmonから時系列データを取得するといったシステム構成が組める。

10.8 ブラックボックスモニタリング

• Borgmonはホワイトボックスモニタリングであり、調べるのはターゲットのサービス内部の状態のみである。したがって、ブラックボックスモニタリングも組み合わせないと、ユーザーにインパクトのある障害に気づけなくなる場合がある。

10.9 設定のメンテナンス

• Borgmonではルールの定義をモニタリングの対象となるターゲットから分離しているため、同じルールセットを多くのターゲットに対して一斉に適用できる。これによりモニタリングのメンテナンスコストが大幅に削減できる。

10.10 10年が経過して

• Borgmonは「アラートの診断のための大量の変数の収集と時系列データに対する集中化されたルールの評価」というモデルである。
• メンテナンスコストがサービスのサイズに比例しないようにすることがモニタリングをメンテナンス可能にするための鍵である。

最後に…インフラ監視 × データサイエンス

• Prometheusなどの時系列データベースや次世代監視ツールの発展と人工知能などデータサイエンス分野の発展が相まって、
  サーバの異常状態を予測して自動で制御するような時代が来るかもしれないなどと考えている。
  そのためにも、まずデータを高解像度・長期間溜め込むことは重要だ。さらに、溜め込んだデータを単なる閾値ベースの判定だけでなく、統計学や機械学習を駆使したより高度なデータ分析を適用することで、アラーティングの柔軟性を高め、必要なアラートだけを発するようにする。自動制御はその先の世界…

参考

• 輪読会：Site Reliability Engineering – 8, 9, 10章
• Prometheus入門から運用まで徹底解説
• 時系列データベースに関する基礎知識と時系列データの符号化方式について
• 今後の負荷を RRDTool を使って予測してみよう
• Gorilla: A Fast, Scalable, In-Memory Time Series Database
• 時系列データベースという概念をクラウドの技で再構築する

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