Mackerel Meetup #12 Tokyo に行ってきた 講演メモ&感想
2018年8月2日に開催された「Mackerel Meetup #12 Tokyo」に行ってきました!!
(講演メモは私の判断で一部を抜粋したものです。また聴きながらとった部分もありますので、乱筆ご容赦ください。)
全体の雑感
(細かい講演の内容に関する感想は後述)
- 7月からの業務で初めて触り、「わからない部分が多いけど便利そう」と思っていたサービスだったので、会社アドレス宛に届いたメルマガでこのミートアップを知り即申し込んだ。
- 今日までずっと「mac"h"erel」だと思っていた。。。今日のイベントでしっかり「mac"k"erel」と覚えた。
- はてなの方は、他の社内エンジニアの方をはてなIDで呼んでいて面白い文化だなぁと感じた。
- (正確に数えたわけではないが)参加者の9割方が男性だった。フロントエンドの勉強会などとは違った印象を受けた。
- 1番目に登壇されていたPMの松木さんが話されていたミッション・ビジョン・バリューに沿ってmackerelが作られていて、またそれに共感するユーザーが使っているということを強く感じた。
講演
200週連続新機能リリースとこれから
Mackerel 株式会社はてな プロダクトマネージャー 松木さん
スライドはこちらから
本日の発表資料です #mackerelio / “200週連続新機能リリースとこれから - Speaker Deck” https://t.co/VOGXwajWJw
— songmu (@songmu) 2018年8月2日
- 自己紹介
- 2014年にはてな入社でMackerel
- 現PM
- 200週連続リリース
- 毎週リリースは継続するけど、毎週新機能はこだわらなくなる
- Mackerelのこれまで
- 2014年 β公開、正式リリース
- 2014/4 エイプリルフールとしてつけたカラーテーマ機能が今では色覚サポート機能に
- 2016年 AWSインテグレーション・LINE Notify
- 2017年 CRE創設、Mackerel サーバ監視[実践]入門」出版、アラートグループ機能
- ユーザーと共に作る
- 今後どうなるのか
- 2018年
- アラートグループ機能
- 「サービス・ロールの勝利」
- コンテナ正式サポート
- カスタムダッシュボードv2を開発中
- 異常検知
- アラートグループ機能
- これから
- ミッション・ビジョン・バリュー(内容はスライド45ページから)にのっとって、進化を続けていきます
- 2018年
- 仲間も絶賛募集中
感想
- リリースの歴史を追っていくうちに今、知っているmackerelが出来上がっていく感じがして面白かった。200週連続リリースは伊達じゃない(現在203週連続リリース中らしい)
- エイプリルフール企画としてつけたカラーテーマ機能が、今では色覚サポート機能へ発展しているという話があった。最初は遊び要素でも、それもサービスに大事な要素になるという好例だった。「まず実装(やってみ)る」大事。
- 知識のなさ故に新機能の説明をあまり理解できなかったが、カスタムダッシュボードは良さそうだと感じた。今でも十分見やすいけど・・・
- mackerelのMMVを初めて知った。MMVと実際のサービスのお互いがしっかりと噛み合っていて、納得感があった。
機械学習を用いたMackerelの異常検知機能について
Mackerel 株式会社はてな アプリケーションエンジニア 吉田さん
- 自己紹介
- サーバー監視の困りごと
- 異常検知によるアラームの実例
- 異常検知とは
- 代表的な問題設定→外れ値検知
- 異常検知のアリゴリズム
- サービス/ロールさえしっかりと設定されていれば使えるようになる。
感想
- 「機械学習?監視ツールと関係あるの?」と思っていたがめっちゃ関係あった。吉田さんの説明は門外漢でもとてもわかりやすかった。
- インフラ周りは一種の職人技のように感じていた。職人技を機械学習によって誰にでも開放すれば、自分のようなインフラ初心者は大助かりになると共に、社会全体でもリソースの有効活用ができそう。
- 「人間と機械学習の組み合わせで監視の質を向上する」という考え方が一貫していたのが印象的だった。人間が得意なことは人間が、人間が苦手なことは機械がやればいい。
- アラートの質が向上するのはすごいと思ったが、実際の障害が起こる前の芽を見つけるのは「未来かよ」となった。(異常がないのが一番だけど)どんなパターンを異常として見つけてくれるのかちょっと楽しみでもある。
トレタのインフラ運用を支えるMackerel
株式会社トレタ インフラエンジニア 山田さん
- 自己紹介
- トレタの全サービスのインフラエンジニア
- 飲食店向けの顧客管理台帳などがサービス
- 運用環境
- IaCで進めている
- Blue-Green Deployment
- immutable
- アラートモニタリングはMackrelに集約している
- ビルドから監視開始も自動化
- mackerelのnameをわかりやすい名前に変更している。デフォではプライベートIPがわかるだけだが、サーバーの属性やパブリックIPも付与して、障害対応時に少しでも手数を減らしている。
- 監視状態の監視
- 今後は「リソースが過剰だよ」というのをMackerelで検知したい
- 最近使い始めた
- ダッシュボードのグラフがあることで、営業さんともグラフを見て話せるようになる
- 超人気店のスパイクなどを見てお店とコミュニケーションが図れる
- ダッシュボードのグラフがあることで、営業さんともグラフを見て話せるようになる
- 期待
- vuls
- 最後に
- エンジニアを募集しています
感想
- よその会社さんのインフラ構成をちゃんと聞くのは初めてだった。業務で携わって1ヶ月だが少しわかる単語が出てきて嬉しい。
- mackerelの機能に加えて、細かな(でも効果抜群な)工夫が随所に施されていて為になった。mackerelのnameを変えて見やすくするのは、明日からできるかもしれない。
- リソースが過剰であることもmackerelで取ろうとしているとのこと。確かにクラウドに移行し、従量課金されていくことが多いので非常に重要な取り組みだと感じた。
- 人気飲食店の予約時のスパイクやばすぎ
フルマネージドホスティングの運用監視にMackerelを導入した話
スライドはこちらから
この後しゃべる資料です https://t.co/mM9N5uQPa9 #mackerelio
— hogem (@hogem) 2018年8月2日
- 自己紹介
- 抱えている問題
- ユーザーへの障害通知のタイムラグ
- 営業を通じ、手動で連絡していた
- 混在している監視システム
- 登校下校システムのメール送信が滞ったことがあったが大混乱
- 度々起こる監視設定ミス
- 監視設定間違い、アラート送信設定間違い、サーバ構築者が監視依頼を忘れていた
- ユーザーへの障害通知のタイムラグ
Mackerel導入理由・工夫
- それぞれの課題を総合的に解決できる
- 監視サーバーの保守が不要
- セキュリティ要件の厳しい顧客のネットワーク環境でも導入できる
- 障害情報ページへのリアルタイムの反映
- 自作ダッシュボードを作って、抱える大量のオーガニゼーションをまたがった検索
- 顧客への通知メールのカスタマイズ
監視している例
- やってくれると嬉しい
- 外形監視をMackerel本体でやってくれると嬉しい
- まとめ
- 何よりエージェントインストールで自動的に監視が始まる安心感
- APIが豊富にあるので大抵のことはできる
- 運用監視を任せることでサービス提供に集中できる
感想
- 先ほどのトレタ山田さんの事例とは打って変わり、「しんどそう」なお話が多かった。サービスの特性上、監視自体も大変そう
- その中でmackerelがそれらの課題を総合的に解決できたというストーリーは納得感があった。
- 自作のダッシュボードかっこいい!!そして便利そう。これは外に出してもウケルと思った。
- こちらのスパイクもやばすぎ・・・
以上です。 元気があれば懇親会に行きたかった・・・