Mackerel Meetup #12 Tokyo #mackerelio
第12回目となる Makerel ミートアップに参加してきました。
今回はブログ枠で参加しました。😃
会場は ドリコム さんでした。おしゃれカフェスペース的なのがあったぞ！
内容は以下でした。
- 200週連続新機能リリースとこれから
- 機械学習を用いたMackerelの異常検知機能について
- トレタのインフラ運用を支えるMackerel
- フルマネージドホスティングの運用監視にMackerelを導入した話
感想など書いていきます。スライドは随時足していきます。
200週連続新機能リリースとこれから
200週は本当にすごいですね…。
今後の継続リリースは、毎週必ず新機能ではなく、大きめの新機能を計画的・継続的に届ける方にシフトするとのこと。
歴史の振り返りの話から。
Mackerel はそう言えば2014年5月8日公開。もう4年経ったんですね。
追加されてきた機能のざっくりした振り返りがありました。個人的にはエイプリルフールネタで出来たハッカーモードが正式に機能として取り込まれ、後に色覚サポートモードへつながった話が面白かったです。ハッカーモードがジョークネタから始まったのは知っていましたが、思わぬところから新しいアイデアが生まれる話は楽しいですね。
「ユーザーと一緒に作る」という想いのもと、社外の一般ユーザーからの Mackerel 関連 OSS への Pull Request やプラグイン開発、機能要望などを受け入れてきましたという話からの、「今年のコントリビューション抜粋」発表がありました。
- mkr でプラグイン更新できるやつ
- configtest
- goroutine リークの指摘
- Windows での自動退役対応
などが抜粋されていました。割と大きい変更もあってすごい。
「2018年ロードマップ状況」では年始のミートアップで発表した新機能追加の進捗について。
アラートグループは既に公開済みですね。機能の紹介がありました。
関連して「サービス・ロールの勝利」の話がありました。サービスやロールというグルーピングフレームワークが良くて、グラフが見やすくなるなどの恩恵を受けられたと言う話。
コンテナ正式サポートは現在開発中！11月ごろに mackerel-container-agent がリリース予定とのこと！！
開発中の画面が紹介されました。画面上に pod や task が表示されていました。 ECS や k8s 環境を対象としているとのこと。オーケストレーションツール API との連携を想定した作りになるそう。などなど。これは楽しみ！
カスタムダッシュボード v2 も絶賛開発中。早ければ9月にリリース。
各種ウィジェットを自由に配置できるとのことで、これも面白そうですね。 Redash 等もそうですが、ダッシュボード作るの楽しいですよねw
異常検知も早ければ10月リリース！異常検知についての詳細は後の @syou6162 さんの発表にて。
「mackerelのこれから」では改めて今後の Mackerel の方向性等について語られていました。。
来年以降は、インテグレーション拡充や SAML 認証、新機械学習活用機能など、エンプラ系向けの機能拡充が進むようです。
引き続き、新機能など楽しみですね。
機械学習を用いたMackerelの異常検知機能について
Mackerel の異常検知機能がどのように実装されているか、何を解決したいか、また実際の画面の紹介が行われました。
解決したい課題の話の中で共感したのは、「複数条件を考慮した異常の検知」が難しいと言う点でした。例として、メモリと CPU の監視があり、 CPU はあまり使っていないのにメモリだけガンガン減っていくみたいなものが挙げられました。
これは人間が見れば「メモリリークしているのかな」と想像したりしますが、これを検知するルールをうまく作るのが難しい、これらの問題を機械学習の監視のサポートによって解決したい、という話でした。
ここからデモというか実際の管理画面や実例の紹介がありました。
管理画面は見やすく、設定もロールを選択するだけ！簡単！
実働例としては、 CPU やメモリの監視ルールを設定していないにも関わらず、 Full GC による一時的な負荷の上昇を検知したり、 swap が多発し始めて LA が上がったタイミングでアラートを出したり、既に実用的やんけといった感じでした。
ある条件で異常検知が行われ、こういう条件の時はこのようなメトリクスになる、とわかり、改めて監視ルールとして追加する、その際にルールについて説明をメモしておく、といった運用が紹介され、綺麗な使い方だなあという感想。
この異常検知は外れ値の検知によって行われており、具体的にはガウス分布という確率分布によって行われているとのこと。障害のパターンを集めるのは難しいので(たくさん障害を起こさないといけないw)、教師なし学習が用いられている。
ただし、単純にガウス分布を用いただけでは負荷に波がある場合(平日昼間は高いが夜は低いとか)に誤検知してしまうので、低い負荷、高い負荷それぞれにガウス分布を適用した混合ガウス分布を用いる。
ロール毎にガウス分布を適用している。これはロール( DB とか Web とか)単位で似たような負荷が記録されると期待されるからで、例えばいろんな役割のサーバを1ロールにまとめてしまうと負荷もバラバラになるのでうまく適用されない。ロールの管理はちゃんとしよう！
みたいな話で面白かった。説明がわかりやすかった…。
トレタのインフラ運用を支えるMackerel
インフラ構成。全体的に自動化されていてカッコ良い…。
- Packer や Ansible, Terraform などコードでインフラを管理
- Blue-Green Deployment 運用
- イミュータブルなインフラストラクチャ
Packer, CircleCI, Serverspec, Terraform でうまく回っていて、この辺のノウハウの話も面白そうw
Packer build の時は Mackerel の status を standby にしていて、アプリのデプロイ後外部との通信ができることをテストされてから working にする運用。
監視状態を監視していて、色々実験のために Mackerel のステータスを変えたりするので、変えたの忘れて帰っちゃうことがあり、それを防ぐために監視状態を監視w
好きな Mackerel の機能の話。
ダッシュボード
- エンジニア以外のメンバーにアクセス数などのグラフを見てもらえるようになった
- 超人気店のウェブ予約が始まると、スパイクする。それをセールスメンバーが気づいてお店と話して来週もあるから、対応しようとかいう話ができるように！
グラフアノテーション
- ETL のボトルネックの検出
- デプロイの可視化
- Terraform apply 時にアノテーション追加
Mackerel への要望として、 Vuls 対応。今は Vuls 用のサーバを立てて、 Redis に結果を保存して重複通知しないようにとか、頑張っている。ここを Mackerel 連携でいい感じにできたら嬉しい。
フルマネージドホスティングの運用監視にMackerelを導入した話
法人向けフルマネージドホスティングを提供している中で抱えていた問題を Mackerel で解決。
- ユーザへの障害通知のタイムラグ
- 監視システム混在
- zabbix, cacti, grouthforestなどなど
- それぞれにメリットデメリットがある…
- 度々起きる監視設定周りが大変
- Mackerel を使えば総合的に解決できそうと判断
- 運用コストとかサーバの保守が不要
- プライベートネットワーク環境に導入しやすい
- 数十オーガニゼーション！
- オーガニゼーションをまたいだ監視やホストの検索を自前で用意した
- Mackerel api を使って検索できるようにした
- オーガニゼーションをまたいだダッシュボードの作成
- python + flask_flaskadmin で作成
- Mackerel はエージェント入れれば監視が始まるのでミスもなくなり、楽
- などの利点があった
なかなか激しい話もあり盛り上がっていたw
色々工夫して Mackerel を使われていて衝撃を受けた。
懇親会
じゃんけん全く勝てなかったんだが？？
いただき物
ポーチ(ブログ枠の賞品？)とセンスの良い扇子をいただきました！！✨
感想
相変わらず新機能が追加されたり進化が続いていてすごい。🐟
また何か Mackerel のプラグイン作ってみよう。