Mackerel Day #mackerelday に参加してきました
昨日（もう一昨日になっちゃった）開催されたMackerel Dayに参加してきました。
とても有意義で楽しいイベントだったので、手元のメモをここに残します。 スピーカーの方の本名を書いて良いものなのかどうかわからなかったので、Connpassページにお名前が記載されている方のみお名前も書いています。
Mackerelリリース3周年の振り返りとこれからの成長について
Mackerel プロデューサー 杉山 id:sugiyama88 さん
- 現在166週連続リリース中
- 直近の主要なリリース
Mackerelは構成管理系の機能が拡充してきていて、もはや監視ツールというよりは動的に変化するシステムにリアルタイムに追従できる「現状把握」の「プラットフォーム」になってきているな、と感じました。
アプリケーションエンジニアがMackerelで楽しく監視構成している事例
- DMM.com ラボ
- id:koudenpa さん
- id:heleeen さん
www.slideshare.net
- 導入背景
- 最初はCloudWatch ＋ Lambda → Slack通知 でやっていた
- 導入にあたり、自分たちが運用するにあたっての利便性 を観点にいくつかのツールを比較検討した
- 監視構成
- 監視設定の管理
- Jenkinsから
mkr monitor push - 設定のJSONはGit管理
- チャンネル設定は手作業
- Jenkinsから
- 得られた価値
- 楽 である
- 想定通りに平易に監視を構成できた
- つまづくところがほぼなし
- 楽しく 監視構成
- 何をすればどうなるかがわかりやすい
- やってみて反映されるまでが早い
- 通知時のグラフでぱっとヤバさがわかる
- アプリケーションエンジニアでも異常がわかる
- 楽 である
- まとめ
- 導入が楽で運用が楽しい
- 監視結果を受けての改善サイクルができつつある
アプリケーション開発者の視点から見た監視や監視ツールについてのお話でした。会場アンケートではインフラエンジニアとアプリエンジニアの比率が6:4から7:3くらいだったかと思いますが、ずっとインフラをやってた身からすると「今はこんなにアプリケーション開発者がインフラ監視もしてるのか！」とちょっと驚きでした。
Mackerel インフラ基盤 AWS 移行の舞台裏
- 8/7,21 にMackerelの基盤はAWSに移行した
- なぜAWSに移行したか
- 時系列データベース
- ハードウェア的スケールの限界、調達が大変だった
- データの堅牢性、冗長性の向上を図りたかった
- データセンター運用コストの削減
- ハードウェア、リソース管理の人的コストを下げたかった
- 時系列データベース
時系列データベースの移行
- データセンターで動いているものとAWSで動いているものは別
- AWSで動いているものは自分たちで作り直した
- AWS Summit2017で id:y_uuki さんが発表している blog.yuuk.io
時系列データベースの運用
- 権威DNSはデータセンターのものを使っている
- 社内システムを利用する必要があるため
- ホストのローカルキャッシュサーバに Unboundを使っている
- MackerelホストのunboundはGoogle Public DNSを見ている
- AWSのネットワークモニタリング
- Q & A
単純な「オンプレミスからAWSへの移行」事例としてもすごい話だと思うんですが、その上AWSの各マネージドサービスの特性をフルに活かした構成に再構築されているのが凄まじいです。
コストについてはオンプレミスとクラウドで単純比較は難しいですね。AWSでいうMulti-AZはオンプレミスでいえば2か所以上のデータセンタをつないで運用していることになるので、それと比較すれば安いと思われるのですが。
大丈夫！ Mackerel には CRE がいます
- CREとは
- Customer Reliability Engineer
- 顧客信頼性エンジニア
- CREがMackerelチームに在籍していることの意味
- Mackerelによってユーザに提供されているものはなにか
- 例えば
- サーバ監視が効率化される
- 動的なインフラ管理を実現することでDevOpsが加速される
- こうした価値はMackerelが利用されることで初めて生まれるもの
- ユーザが居るからこそMackerelの価値はうまれる
- 例えば
- Mackerelの価値を支えるもの
- プロダクトそのもの
- はてなのエンジニアの高い技術力によって支えられている
- Mackerelに対するエンジニアの皆様からの信頼
- 投げかけた質問に的確かつ真摯な回答が得られること
- わかりやすく正確なドキュメントがあること
- Mackerelについてまだ知らない方がそれを使うことの便利さや重要性などを短期間で把握できること
- プロダクトそのもの
- これらの側面でMackerelに対する信頼性を支えるエンジニアロールがCRE
- 開発エンジニアとのやりとりも積極的に円滑に行うことで、迅速なレスポンスの維持に努める
- 同営業日中 90%
- 翌営業日までに 99%
- やりとりの往復 2往復以内
- を達成 （前期実績）
- 公式ヘルプページなどドキュメントもGitHubレポジトリで管理（Privateレポジトリ）
- 「CREがいること」も含めてMackerelというサービス
サポートのレスポンスの速さと正確さは本当に驚異的で、これは当然CREのお二方のサポートが卓越しているからだと思うのですが、それだけでなくユーザ側もリテラシーや説明能力が高い人が多いというのもあるのでは、とイベントに参加して周りの方を見ていて感じました。
サービス提供側も利用側もハイレベルですごい世界だなと思います。
freeeでMackerelを使って一年間サービスを運用してみた事例紹介
- freee 浅羽さん
- Mackerel導入前はZabbixを使っていた
- VPC毎にZabbixサーバを運用
- いくつかのプロダクトを評価
- 監視の構成
- 通常時
- ダッシュボードかサービス一覧のグラフを眺める
- 定期的にパフォーマンス振り返り会を実施
- 手でポチポチ作るのは面倒なのでmkrコマンドで作る
- さらに深掘りしたいときはNewrelicで確認する
- ダッシュボードかサービス一覧のグラフを眺める
- 何かあった時やグラフをシェアしたい時
- チャンネルにグラフを投稿 が超絶便利
- いつデプロイしたかわかるように記録しておく
- グラフアノテーションを自動化
- EC2起動時の初期状態はStandby
- 初期ビルドがおわったら mkr を叩いてworkingに戻す
- 構築がコケた場合も mkr を叩いてworkingに戻す → コケたことを検知できる
- Mackerelに欲しい機能
- AWSインテグレーションも自動退役機能欲しい
EC2起動時の初期状態をStandbyにしておく、というのが目からウロコでした。AutoScalingでEC2が起動するたびチェック監視に引っかかってたので、早速うちの環境でも取り入れました。
グラフの共有機能でいうと自分はMarkdown形式で共有できるのが気に入っていて、Github/GitLab や Crowi などのMarkdownをレンダリングしてくれるWebサービスに張り付けて自作ダッシュボードを作って眺めてます。これだとFreeプランでもダッシュボード作り放題だし複数オーガニゼーションのグラフを並べられて便利！
Mackerelを導入して変わったN個のこと
- GMO ペパボ 高石 諒 さん
- 初めて触った監視ツールがMackerel
- 2015年4月に正式導入
- 2017年10月5日時点でホスト数1000台
- サービス 20
- ユーザ 100
- ロール 300
- ホスト 1000
- サービスメトリック 300
- 外形監視 70
- Mackerel導入前の課題
- Mackerel実践活用 ＠ペパボ
- いろんな言語で手軽に独自プラグインがかけるのは楽しい！
- Q & A
- 運用ツールとしてMackerelのグラフを活用しているということだが、面白い使い方しているものはあるか
- 各種クラウドサービスの料金とか、金の相場とか ravelll.hatenadiary.jp
- 運用ツールとしてMackerelのグラフを活用しているということだが、面白い使い方しているものはあるか
リリースにかかった時間を計測している、というのが面白いなと思いました。デプロイプロセスを改善する際に定量的な評価ができるので素敵ですね。
懇親会でオーガニゼーションの構成についてお話を伺ったところ、あれだけジャンルの違う様々なサービスを展開されているのにMackerelのオーガニゼーションは1つだけで、全社員が全サービスの状況を自由に確認できるようになっているとのことでした。すごいなぁ！
Driving Mercari with 50+ custom Plugins
- 株式会社メルカリ 長野 id:kazeburo さん
- Mackerelの導入理由
- 異なるインフラの監視項目・内容を共通化する
- 以前はリージョン毎にZabbixを利用。バージョンがズレたり監視内容の差が発生
- Service/Roleを利用することで管理
- 異なるインフラの監視項目・内容を共通化する
- Mackrel以外の監視
- Kurado
- グラフを一気に見られる
- 基本的なメトリクスはこちらで見る
- New Relic
- PHP内部のトレース
- Kurado
- Service/Role設計＆Deploy
- サービスを行うリージョン毎にServiceを分ける
- mercari, mercari-us, mercari-gb
- 外形監視は別Service
- mercari0jp-extenalなど
- 通知チャンネルを分けるため
- Role名のprefixに意味を持たせる
- サービスを行うリージョン毎にServiceを分ける
- Deploy
- Mackerelによる監視とPlugin
- 紹介されていたカスタムプラグインのうち特に気になったもの
- diff-detector
- コマンドの結果に変化があるとアラート
cat /etc/passwd,uname -aとか
- mackerel-plugin-ntpq
- check-ntp ではなくメトリックで見ているのは、時刻のズレ方を見たいから
- periodic-checker
- 特定の時間のみ監視を行う
- diff-detector
- 監視されてないサーバの自動検知
- 1日2回Slackに通知
ものすごい情報量の発表で圧倒されました。
特定の時間だけ監視を行う、もしくは監視を止める 機能はmackerel-agent標準に欲しいと思いました。夜間休日停止させている開発・管理系のEC2の監視設定をもう少しスマートにやりたい。
AWS Ecosystem with Mackerel
- AWS 酒徳 さん
- DevOps系サービス
- 色々あるけど、CodeStarで割りと統合されてる
- が、東京リージョンにはまだ来てない
- CloudFormation がマルチアカウント・マルチリージョンに対応した
- 色々あるけど、CodeStarで割りと統合されてる
- This is my Architecture
- https://aws.amazon.com/jp/this-is-my-architecture/
- いろんなサービスがAWS上にどう構築されているかを語る動画が数十本掲載されている
AWSの繁栄はエコシステムあってのこと、というお話でした。AWSから見てもMackerelは単なる監視ツールではなくDevOpsを加速させるためのプラットフォームという認識なんですね。
参加しての感想
いろいろな環境での事例を聞けて、早速うちの環境でも適用できそうな知見も多く、さらに懇親会では直接はてなのエンジニアみなさんとお話しでき、要望をお伝えしたり今後の展望を伺えたりしてとても楽しかったです。 企画・運営してくださったはてなの皆様、ありがとうございました。
イベント自体がとても楽しかった上、お酒も入ってテンション上がってしまって「インフラの運用ってなんだかんだ楽しいですよねー？」って懇親会で色んな人に絡んでしまってちょっと反省している。
— MIYA (@kmiya_bbm) 2017年10月5日
でも楽しいよね？
