SRE NEXT 2020 参加した

SRE NEXT というイベントに参加してきた。

公開されている資料は下記にまとめてくださっている方がいるのでありがたくリンクさせていただく。

まとめ

動機

Brendan Gregg あたりから触発されて考えるようになった 「システムの状態を統計的視点で観察する」というアプローチについて引き出しが少なすぎるので、

Observability に関する事例、手法を知る

あたりの知識領域を少しカバーしたい。

(正直、調べればいくらでもこの辺の情報は出る訳で、本音の動機は「聴講を通じたモチベーションのドーピング」なのかもしれない)

なので Observability に絞って感じ入った点を記載する。

※ 追記

書いてみて力尽きたので UZABASE さんの『実践Observability』はまた後日...

分散アプリケーションの信頼性観測技術に関する研究

講演の概要

資料

分散アプリケーションの依存関係を記述するために、OS が保持する socket 情報を収集してデータベースに蓄積するという話。

BPF やカーネルモジュールなどでカーネルから性能情報を収集するのかな、と予想していたけど違った。 procfs 配下に出力される socket 情報を収集するので完全にユーザ空間のみで解決している。

一方で /proc 配下の定期的な pull 型収集で通信端点を検知する仕組み上、短命な通信は検知できなさそうだった。カーネル側からの push 型のメトリクス収集であれば中継のバッファが溢れない限りは取り漏らしなく検知できそう。まあ、これだと「遅延オーバヘッド」を解決できなさそうなのでトレードオフなのだろう。

さらに通信端点の情報を記録するデータベースを一箇所に集約するとそこがボトルネックになる。 これがを解決するために、データベースを各ノードの収集エージェントと同居させる。

この方式では端点情報の問い合わせを受けると、自身のデータベースをスキャンするだけでなく足りない情報を他のノードに問い合わせることで補完する。問い合わせ先の決定には自身が収集した端点情報からわかる依存関係を活用する。したがってエージェントが端点の依存関係を解決しながら、依存先のノードへと再帰的に問い合わせを行う。

再帰的な問い合わせグラフが静的に設定されているのではなく、実際の通信ベースで動的に構成される、というのはモダンな分散システムと相性が良さそう。 (グラフに閉路があるとどうなるんだろう)

このアプローチが面白いのは、既存のアプリケーションへの変更が一切必要ないところ。 通常アプリケーション同心の依存関係をトレースするためにはアプリケーション間で共有する識別子を (よく知らないけど) Jaeger や Zipkin などで収集し可視化する。 しかしこの socket 情報の収集では Linux カーネルなどが基本的に備えている機能のみを利用しており、既存のアプリケーションに手を加える必要がない。

Jeager などでは特定リクエストの流通経路をトレースできる機能があるのに対して、 socket ベースの収集ではある瞬間のリクエストがどの socket を通ったのか判断できないため、 Jeager のような解像度での分析はできない。が、分散システムの現状を俯瞰することをゴールとするなら、確かに socket 情報だけで依存関係を記述できるだけでも充分事足りそう。

ということで、エージェント入れるだけでアプリケーションの変更なく依存関係を収集できるところが魅力なのかなと感じた。

まとめ

分散システム上で活用できるアプリケーションは CNCF project 見ても分かるように本当にたくさんある。 しかし実は Linux カーネルにも活用できるリソースがあったりするので、下手にオーバーキルなアプリケーションを入れるよりも良いこともあったりするのではなかろうか。

とか思う insight をもらった良い講演でした。

Linux のカーネル機能を活用した observability は Brendan Gregg が たくさん情報 出しているので引き続き見たいなと思いつつ。。。。