先日のInfoQポッドキャストで、Chronosphere共同創業者兼CTOのRob Skillington氏が、最新の分散システムにおける可観測性に関する自身の経験と意見を公開した。取り上げられた話題は、大規模なメトリクスコレクションとその具体例としてのUberのM3およびM3DBメトリクスツーリングの設計と運用に関する洞察、多次元(multi-dimensional)メトリクスと高カージナリティ(high-cardinality)、可観測性ツーリングにおける開発経験の重要性、可観測性ツーリングを実装するプラットフォームエンジニアにとってOpenMetricsなどのオープン標準を導入することのメリット、といったものだった。
10年以上にわたり、管理や警告に関する要件と、その実装に使用されるアプローチは、絶えず変化を続けてきた。エンジニアはより多くの仕組みを実装することで、自分たちや組織の他の部分にとって有用な、より多くの洞察を生成したいと願っている。加えて、現在の計算処理は一時的(ephemeral)かつ動的になっており、サービスの数も増え続けている。
メトリクスデータにおける大きな課題は、収集した値のコンテキストを知るための情報に制限のあることだ。多次元メトリクスを使えば、この問題を解決できる可能性がある。メトリクスの次元(dimension)とは、メトリクスを説明する付加データを運搬する名前-値ペアのことだ。高次元は高カージナリティへとつなげることができる。
もうひとつの重要な問題は、目的に適合したスケーラブルな監視ソリューションの実装である。Skillington氏は、自身がUberで開発に従事した日々について語った。メトリクス収集を担当するそのチームでは、当初はNagiosやGraphiteといったツーリングを運用していた。
私がUberにいた頃、最初はNagiosを運用していました [....] 当初は非常に効率的に動作していました。特に物理ホストを運用していた時期には、世界中にNagiosにすべてが極めてネイティブにマップされていたのです。しかし、企業の規模が大きくなってMesosなどの計算フレームワークを使用するようになり、その他の部分ではおもにKubernetesが使用されるようになると、そういったコンセプトをマップすることができなくなりました。
UberのM3メトリクス収集システムが開発されたのは、このような理由からだ。このシステムは、当初はCassandraやElasticSearchといったオープンソースコンポーネントをストレージやインデクスに使用していたが、M3の利用スケールが大きくなるにつれて、M3DBやその他のカスタムコンポーネントに順次リプレースされていった。
Uberが2回めのハロウィンを迎えた頃には、Graphiteクエリの量は当社のPython Stackの能力を完全に圧倒するようになりました。ストレージサーバに比べて運用するPythonサーバの数が非常に多くなったため、Graphiteクエリ言語をGoで書き直したのです。
M3ツーリングの進化に伴って、Skillington氏とその同僚でChronosphereの共同創業者であるMartion Mao氏は、この可観測性ツーリングを開発するエンジニアにとって、効果的なユーザエクスペリエンスを作り上げることの価値についても学ぶようになった。
社内のGrafanaには毎日、数千のユニークベンダが訪れていましたが、それを支えたのがM3でした。エンジニアリングチームの過半数が、このツールを毎日使用していたのです。そのためには高速で、スケーラブルで、使いやすいものでなければなりませんでしたが、エンジニアが使用しているユーザインターフェースには、実際にはそれほど力を入れていませんでした。
運用ツールにとって、効果的なユーザエクスペリエンスを構築することは非常に重要です。エンジニアたちは警告だけでなく、運用障害の発生時に起きていることを特定し、理解する手段としても、これらのツールを頼ることになります。Chronosphereチームが商用サポート付きサービスの価値を模索し、追加している理由がここにあるのです。
Skillington氏は最後に、相互運用性だけでなく、コラボレーションとイノベーションを適切に推進するためにも、オープン標準が極めて重要である、という主張をポッドキャストの結論とした。OpenMetricsプロジェクトは、大規模なメトリクス転送を行うためのオープン標準を開発する活動で、テキスト表現とプロトコルバッファの両方をサポートする。
ポッドキャストのオーディオと文章は記事"Rob Skillington on Metrics Collection, Uber's M3, and OpenMetrics"にある。