koudenpaのブログ

趣味のブログです。株式会社はてなでWebアプリケーションエンジニアをやっています。職業柄IT関連の記事が多いと思います。

モニタリングのUX

先日、Mackerel User Group主催のモニタリング勉強会に参加してきました。

mackerel-ug.connpass.com

MackerelPrometheusZabbix、という3種のモニタリングサービス・ソフトウェアそれぞれの話が聞けるなかなか面白い企画だったように思います。

そんな中で、懇親会でLINE Fukuoka(敬称略)でのPrometheus活用事例を聞いて「いいなぁ」と思ったのでメモします。

酒も入っていたし、Prometheusのアーキテクチャはさっぱり知らないので嘘八百かもしれないけれど「いいなぁ」と思ったことに変わりはないのでよし。 つまり、眉唾であるということです。

さて、自分がある程度見知っているMackerelでは 時系列データベースという概念をクラウドの技で再構築する - ゆううきブログ と発信されている通り、時系列データを新しいものは高速なストレージに、古いものは順次コストパフォーマンス重視の低速なストレージに配置しています。

同様に、Prometheusでも、直近のデータのみ書き込みできる高速なストレージに、古いデータは順次退役、バックアップして、それをリモートリードするようなことをしているとのことです。

当然ながら、退役先は低速なストレージとなるわけですが、古いデータはそれほど参照されない、という理由からモニタリング上は問題にならない、という判断です。

モニタリングに関してはこの考え方は今後当たり前になっていくような感じを受けています。

さて、聞いた事例で良いな、と思ったのはここからです。

古いデータは参照されないとはいえ、例外的な事情もあり、例えば「年末には去年末のデータがよく参照、比較される」とのことです。

これに対して、該当のデータのリモートリード先をあらかじめ高速なものにすることで、参照の応答速度を上げているとのことでした。

つまり、モニタリングデータを見る側が「去年のデータ見たいなぁ」と思った時に、サクッと出るわけです。

すさまじいUXだと思い、それを提供するエンジニアの気迫を感じました。

具体的にどうしてるのかは知らんですが、Mackerelの時系列DBの構成で言えば、特定の時系列のデータをS3からDynamoに戻すようなことを行っているのでしょう。

とても「いいなぁ」と思いました。

現場から数日後の自宅からは以上です。

この記事が嘘か誠か気になる場合は、登壇ご本人にお伺いください。

github.com