こんにちは！Mackerelチーム CRE（Customer Reliability Engineer）の井上（
id:a-know）です！
昨日・2月5日（月）に、2018年一発目となる Mackerel 公式イベント、Mackerel Meetup #11 を開催しました！今日は、その開催レポートをお届けしたいと思います。
DMM.com様 の素敵な会場！
会場準備のために、今回のイベントの会場となるDMM.com様のセミナースペースに少し早めに会場入りした私たちの目の前に広がっていたのは、そう、ジャングルでした。
この植物たち、つくりものではなくて全部、生きてるんです！すごい！！
窓を覗くと、外には東京タワーが。素敵すぎます。
こんな素敵な会場に、これから始まるイベントへの期待感が否が応にも高まります！
The 2018 Mackerel Product Roadmap
今回のミートアップはこれまでと少し趣向を変えて、開会と同時に乾杯をし、お酒を楽しんでいただきながら発表を聞くスタイルに。
発表のトップバッターは、Mackerelのプロデューサーである杉山（
id:sugiyama88）。「The 2018 Mackerel Product Roadmap」と題して、これからのMackerelの進化・進歩の方向性についてお話をさせていただきました。
今日が Mackerel Meetup に参加するのは初めて、という方に向けた Mackerel の概要、定番機能の説明からはじまり、直近での目玉アップデートのご紹介、2017年リリース機能のふりかえり、と話は進みます。
そして待ちに待った2018年のプロダクトロードマップ（≒ 最新の開発方針）ですが、以下のような項目を発表しました。
- アラートグループ
- コンテナの正式サポート
- カスタムダッシュボード V2
- 異常検知機能
- OSS Monitoring Affinity の拡充
特に5点目の「OSS Monitoring Affinity の拡充」について。これは、既存の様々な仕組みに対しての親和性を高める・確保するための仕組みで、これまでには Nagios や Sensu といったツールに対しての Affinity をサポートしていました。今回それに加えて、次世代モニタリングシステムとしても確固たる地位を築きつつある Prometheus に対する Affinity を新たに発表しました。
Prometheus の優れたアーキテクチャ、そしてそれをとりまくエコシステムはそのままに、Prometheus が苦手とする長期データ保存・ビジュアライズを Mackerel でおこなっていただきやすいような姿を想定しています。
その他、盛りだくさんの発表資料は以下となります。参加された方もそうでない方も、ぜひ確認してみてください！
AWSで実現した Mackerel 時系列データ1分粒度長期保存の裏側
この時点で既に10分押しというタイムスケジュールの中、2番手として登壇したのが Mackerel チームに所属するWebアプリケーションエンジニア、脇坂（
id:astj）です。
「AWSで実現した Mackerel 時系列データ1分粒度長期保存の裏側」と題し、Mackerel の根幹である時系列データベースについてわかりやすく説明をしたのちに、先日発表の大きなアップデートであった「1分粒度時系列データ保持期間の長期化（25時間 → 460日）」をいかにAWSの各種マネージドサービスで実現したか、実現するにあたり工夫した点や気をつけるべきポイントはどういったところにあったか、ということなどについて、具体的な例も交えつつご紹介をしました。
技術的難易度の高い機能をどのように実現したか、といったことのみならず、様々なリミットが課せられているクラウドサービス・マネージドサービスを安全に使うためにモニタリングが欠かせないこともお伝えできたかと思っています。
当日の発表資料は以下となります。ぜひご覧ください！
seesaa meets Mackerel
ここからは Mackerel をお使いいただいているユーザーさんからの発表です。まず発表してくださったのが、シーサー株式会社の瀬戸さん。
「seesaa meets Mackerel」というタイトルで、「Mackerelを導入する前」「導入した後」「その後のブラッシュアップ・応用」というストーリー構成で、サーバー監視・インフラ管理業務をいかに効率化してきたか、ということについて、ユーザー目線で・ときに赤裸々に、語っていただきました。
Mackerel導入以前、シーサーさんでは savacan（さばかん）という自社ツールでモニタリングを実現していた、とのこと。Mackerel も、その出自ははてな社内で作られたサーバー管理ツールであることから、私も非常に親近感を持ってお話を聞くことができました。
Mackerelを導入したあとも、昨年開催された大イベント・Mackerel DAY での収穫をもとに監視を全て見直した、というお話は、私たちとしても大変うれしいお話でした。今後も、Mackerelユーザーのみなさんの知見を集め、共有できるような場作りをしていきたいと思います。
クラウド（AWS）とオンプレミス環境の両方を運用している、というユーザーの方も多いと思います。既存の監視ツールでは動的な変動の大きいクラウド環境に適用することが難しかったり、またクラウド環境が提供するモニタリングツールでは異なる環境のモニタリングが難しかったり、できなかったりすることもあると思います。今回の瀬戸さんからの発表は、そんな方に向けたエールでもあり、「問題は技術で解決しよう」というメッセージでもあると思っています。発表に使用されていた資料は下記となります、ぜひご一読ください！
Mackerel で ECS をどこまでモニタリングできるのか
2018年初のミートアップのトリを飾っていただいたのが、株式会社マクアケの吉田さん。
吉田さんは近年、とても精力的に技術活動をされているので、なんらかの形でその成果物をご覧になった方も多いのではないかと思います。
そんな吉田さんも Mackerel ユーザー。今回は、AWS が提供するコンテナオーケストレーションサービスである Amazon ECS を Mackerel でどこまで監視することができるのか、という点にフォーカスした発表をしていただきました。
直前に発表されたロードマップでの「コンテナ正式サポート」とぶつかる内容が多かったようで、ご本人も少し気にされていたようでしたが、それを受けてすでに発表資料がアレンジされていた点はさすがの一言。図や写真を効果的に用いたスライドも、思わず目で追ってしまいました！
ECS や kubernetes などのコンテナオーケストレーションツール、そしてコンテナ環境へのモニタリング対応は、私たちもまだまだ拡充の余地があると認識してはいるのですが、そんな点を鋭くも的確に、指摘してくださいました。具体的には、以下のようなフィードバック・要望を発信していただきました。
- 動的ポートマッピングだと、mackerel-agent コンテナから ECS タスク内部のメトリックを取得できない
- コンテナインスタンスに mackerel-agent をインストール（cloud-init）しカスタムメトリックを取得する場合、そのためのスクリプト（吉田さんはシェルスクリプトにて実現）も合わせて配置する必要がある
- ロールグラフだとポート番号部分をワイルドカード指定・グラフ表示することができない
- いずれ東京リージョンにも来る AWS Fargate はどのようにモニタリングしていくのか？
- 本来ならばタスクごとに mackerel-agent コンテナを link するだけで良いはず！コンテナ特化の課金体系が欲しい！
その他にも、「mkr のプラグインインストーラーにおいて、RubyGems の Gemfile のような定義ができると便利かも」といった、Mackerel のヘビーユーザーならでは、といったご意見も。
Mackerel がこの先も発展しつづけるためには、こうしたユーザーの方からのフィードバックは欠かすことができないものだと考えています。そうしたご意見をお持ちの方は、ぜひお気軽にフィードバックをお寄せください！（Mackerelにログイン後、右上にある「サポートチームへ連絡」より送ることができます！）
会の最後は懇親会！
吉田さんの驚異的な時間調整力で、奇跡的に時間通りにはじめることができた懇親会。私もとてもたくさんのユーザーのみなさんと交流することができました。
昨年末に、Mackerel の開発ディレクターである粕谷（
id:daiksy）も以下のようなブログ記事を書いていますが、
この記事にあるとおり、Mackerel は「開発者に会いに行けるサービス」だと思っています。さらにいうと、私たちからも会いに行くこともでき、その声を直接聞くこともできるサービスです。今回は Mackerel Meetup という形でしたが、今後も様々な機会を設けていきますので、そういった場を利用して意見のやりとりをさせていただき、一緒になって Mackerel というサービスをより良いものにしていけたら、と心から思っています。
今回ご参加いただいた皆様、そしてとても素晴らしい会場を提供してくださった DMM.com 様、本当にありがとうございました！ 今後とも Mackerel どうぞよろしくお願いします！
