はじめに

こんにちは、まいんだーです。

私は2015年前半頃まで担当サービスでMackerelを使っていました。
また、管理はもうpapixさんにお任せしましたがWebService::MackerelというCPANモジュールをリリースしたりしておりました。
https://metacpan.org/pod/WebService::Mackerel

使っていた当時のことは
https://mackerel.io/ja/customers/mtburn/
https://github.com/myfinder/mackerel-meetup-3/blob/master/slide.md
この辺に詳しく書いてありますので、昔話的なものが好きな方はどうぞご覧ください。

最近は仮想マシンの管理運用仕事から離れていてMackerelを使っていなかったのですが、そーだいさんから

@myfinder 思い出話とか久々にしませんか！？ https://t.co/mLOqE2l80Y
— そーだい@初代ALF (@soudai1025) 2017年11月22日

こんなメンションをもらったので、改めてMackerelを使っていた頃のことを思い出して当時の課題とその解決アプローチなど振り返ろうと思います。

Mackerelを使いだした時の話

Mackerel前夜

Mackerel前夜、私は下記のような構成のシステムを構築運用する仕事をしていました。(出典：https://github.com/myfinder/mackerel-meetup-3/blob/master/slide.md)

オンプレ
L3スイッチ -> 集約スイッチ -> ラックスイッチの3層ネットワーク
データセンター提供のマネージドDNS(外側)
OSSのDNS(内部)
箱物ロードバランサ / 大手メーカー製サーバ / 一部自作機
CentOS 6系 / cobbler / puppet / RackTables
Hadoop 担当が構築 / 運用
MySQL/Redis/Memcached 担当が構築 / 運用
Nagios / CloudForecast / GrowthForecast
足元のディスクに吐いたログをでっかいディスク積んだサーバにscpで収集して集計

正直、2018年代を迎えようとしている今からするともはや古めかしいとも言える構成ですが、意外とまだこんな構成でやってらっしゃる方もいるのではないでしょうか。
正直、この技術スタックで安定してサーバの増減もないサービスなら無理にこれを変える必要もないし、Mackerelを使う必要はないと思います。

Mackerelを使いたくなった事案

先に挙げたようなシステム構成で、安定して緩やかな処理要求の増加ペースならもうそのままマッタリと運用を続ければよかったわけですが、新規でトラフィックの増減が読み切れないサービスを置くとなると話は変わってきます。
サーバ足すのに "見積書を取って稟議を通して発注して設置して受け入れ検証してセットアップしてサービスに追加して監視して" みたいな儀式をやっている間にひと月とかかかってしまう状況は、エンドユーザや顧客からして見れば単に動きの遅いサービス提供者です。

そこを解決するべくパブリッククラウドの仮想マシンを使い始めたわけですが、その仮想マシンはオンプレのサーバと単純比較しても高額なわけです。
なによりも、運用の枠組みが既存のままなので、"見積書を取って稟議を通して発注して設置して検収してセットアップしてサービスに追加して監視して" のうちなくせるのはせいぜい "見積書を取って稟議を通して発注して設置して受け入れ検証して" であり、無くせたのは前半の "非技術的な仕事" の待ち時間であり後半の "技術的な仕事" を減らせたわけではありませんでした。

これ以上効率化していこうと思うとAuto Scaling対応していく必要があり、そういったチャレンジに伴って、NagiosやMuninのようなスタティックファイルにサーバ一覧を書くようなやり方がなじまなくなった時に、API経由で操作でき、ロール単位で監視やメトリックのグラフ化ができるMackerelが役立ちました。

そのあたりのアプローチや経緯はAWS Casual 3とかAWS Advanced Users Meetup 2で話した資料に書いてあるので関心のある方はどうぞご覧ください。

Mackerelを使った結果

オンプレ事情を引きずっていたこれまでの環境が

サービス監視/インスタンス管理をMackerelで
インスタンスのセットアップやAMI作成をPackerで
セットアップ状況の保証をServerspecで
トラフィックが上下する部分はAutoScalingで

といったような感じの環境に生まれ変わり、前項で述べた "技術的な仕事" を大きく減らすことができたわけです。

というわけで、ここまでの話はめでたしめでたしな話なのですが、それはあくまでIaaSで仮想マシンベース構成にしたときのことであり、近年ではむしろそれがMackerelを使う際の考慮事項になることもあるよなと感じているので、それを次節に書きます。

2018年代に向けてMackerelを使う際の考慮事項

Mackerelの課金体系

Mackerelはホスト数での課金であることは広く知られている通りです。
なので、前節までで取り上げたような事案にはとても合っていました。が、時代は流れ、いまや大サーバレス時代であり、ホスト単位での課金がマッチしないケースが出てきています。

特に "え～そりゃどうなのよ" と思っている象徴的なところがAWSインテグレーションのLambdaで、"AWSインテグレーションで連携をおこなった場合、課金対象として 1function = 1ホストと換算します。" という点です。
どちらかというとサービスメトリックでまとめたい気持ちがあるわけですがこの辺り皆さんはいかがでしょうか。

こういう観点で考えていくと、今時Auto Scalingするのも当たり前になってきている昨今ではむしろホスト単位での課金(Auto Scalingしている場合は一定時間あたりの平均)という構成自体が実はマッチしないんじゃないのかと感じます。

ほかの監視サービスの課金体系はどうなのか

例えばGCP StackdriverとAzure Log Analyticsだと、どちらもエージェントベースであるところは似ているものの、Mackerelとの大きな違いは "ログデータサイズ上限" と "保存期間" での課金になっている点です。

オンプレのサーバだったり、パブリッククラウドのVMだったり、ナントカ as a Serviceだったりのメトリックをまとめて監視しようとすると、こちらのやり方のほうがより明瞭というか、利用リソースに対する課金としてはわかりやすいのではないかと感じます。

Mackerel開発者の皆様、この辺りいかがお考えでしょうか。

おわりに

明日は syou6162 さんの "小ネタを書きます!" です。おたのしみに！

Mackerel思い出話