だいぶ遅くなっちゃった。10月5日開催の Mackerel DAY で登壇していただいたユーザー企業・四社の発表内容のポイントとサマリーを、今更ながらにまとめた。どちらかというと自分用メモ。
アプリケーションエンジニアがMackerelで楽しく監視構成している事例・DMM.com ラボさん
www.slideshare.net
ポイント
- 「アプリケーションエンジニア」が Mackerel というツールをどのように捉えているか、という貴重な事例！
- アプリケーションもインフラも、と、エンジニアの責務は増える・広がる傾向は業界としてあると思う
- 同じような境遇の方の判断材料のひとつになるのでは。
- アプリケーションエンジニアなので「コード」を書いたり管理するのは得意！
- 監視設定のコード化、Ansible の利用についても言及されている
- 自分もルーツはアプリケーションエンジニアなので、頷ける点が多くあった...！
サマリー
- クラウドに移行することになり、エンジニアの責務も変化した
- サーバーリソースの確保もアプリケーションエンジニアの責務に
- それに加え、短期間（半年）かつ少数精鋭（2人（not フルコミット））という状況
- 監視はどうする？
- 移行前は監視ツールを独自にホスティング
- 移行後も同じ方式は厳しかった（特に人的コスト的に）
- 当初は CloudWatch + Lambda を検討
- 縁も有り Mackerel を触ってみた、簡単に監視・通知ができた
- 導入の際の稟議は上長に依頼した
- 通すためにおこなったことは、他の選択肢との比較
- とにかく簡単、かつ柔軟な設定が可能なだったことが決め手。
- mackerel-agent の設定は Ansible で
- 公式の Ansible Galaxy Role を使用
- 狙った構成を簡単に入れられた
- 監視設定をコード管理
mkr monitors- 監視設定の json ファイルは Git でバージョン管理
- json ファイルの push は Jenkins で実施
- 監視ルールをGitHubで管理しよう - Mackerel ヘルプ
- アラート通知は、サービス毎・レベル毎（Warning / Critical）にチャンネル設定
- グラフアノテーションも利用
- デプロイタイミングで
- Mackerel を利用することで得られた価値
- 「楽」な監視構成
- 「楽」しく監視
- 「何をどうすればどうなるか」がわかりやすい
- 余剰リソースの把握もしやすく
- ...など、「得られて当たり前の価値」を得られた
- サービスとの距離の近さ
- 送ったフィードバックへの対応
- 各種イベントへの参加
freeeでMackerelを使って一年間サービスを運用してみた事例紹介・freeeさん
ポイント
- とにかく「実戦的」な事例！
- 良くも悪くも Mackerel は、インフラ・サーバーレイヤのためのツール。
- 餅は餅屋。他のサービスとの組み合わせ方も参考になりそう。
- 開発エンジニアとのコミュニケーションを Mackerel が介在している一面もうかがえる
- AutoScaling 環境下での Mackerel のホストステータスの活用方法は必見！
サマリー
- Mackerel 導入前は Zabbix を利用
- VPCごとに Zabbix Server を運用
- 機能が豊富、作り込めばなんでもできる
- が、作り込みや運用に時間を取れない状況
- 移行を検討、いくつかのプロダクトを評価した
- 現状のfreeeでの監視構成
- サービス／ロール／ホストの考え方
- AWS側で付与しているタグの情報をそのまま Mackerel で利用
- サービス
- サービス名_ステージ名称
- ロール
- サービス内のサーバの役割（web, batch, worker 等）
- 開発エンジニアとのコミュニケーション
- 定期的にパフォーマンスふりかえり会を実施している
- そのためのダッシュボードは mkr コマンドで作成する
- さらに深掘りしたいときは NewRelic で
- グラフをもとにディスカッションしたいときは、各グラフのカメラボタン「グラフをチャンネルに投稿」が便利
- グラフアノテーションを利用してデプロイタイミングをグラフに記録
- サービスメトリックの使いどころ
- アラートの通知
- 基本的には slack で
- 夜中のアラートは twilio 経由で電話を掛けさせている
- 利用している Mackerel のプラグイン
- Mackerel のホストステータスの初期値は「standby」にしている
- AutoScalingによる UserData が走っている間はアラートを出したくない
- UserDataの中で mkr を利用し、自身のステータスを「working」に変更しサービスイン
Mackerelを導入して変わったN個のこと・GMOペパボさん
ポイント
- ペパボさんも、数多くのサービスを開発・運営している企業ならではの実戦的な実例を、惜しみなく公開していただいている
- 1000ホスト規模の実例！
- 導入前に直面していた課題なども、とても実感がこもっているもの。
- サーバーの監視だけでなく、サービスディスカバリ的な用途でも使えることが、「ペットから家畜へ」の考え方が主流となってくるこれからの時代における大きなメリットになるはず。
- その他、「お問い合わせ数」や「デプロイ所要時間」など、単純なサーバーリソースに関する値以外も「気軽に」モニタリングをするための手段として Mackerel は最適
- 僕も「Mackerelネイティブ」です！笑
サマリー
- 「Mackerelネイティブ」
- 「入社したらそこにMackerelがあった」
- 初めて仕事としてちゃんと使うモニタリングツール
- モニタリングは「おもしろい」
- イベント開催時点での利用状況
- 20のサービス
- 300のロール
- 1000のホスト
- Mackerel の活用状況
- サーバーの障害はまず Mackerel で検知
- その後、レベルや種類に応じて各種ツールへ通知
- slack, PagerDuty, ryotarai/waker -> Twilio
- 当時の導入理由
- 導入してどうなったか
- サービスディスカバリとして使う
- デプロイ対象の取得を「あるロールのサーバの一覧の取得」のように、Mackerel でおこなうように
- 退役漏れ・ロールの設定漏れのチェック
- ロール毎のサーバー数を数える
- bash + consul + mkr
- サービスメトリックとして投稿
- Consul 未所属サーバの検知
- openstack コマンドで取得したサーバー台数と consul コマンドで取得したノード数を Mackerel に投稿、その差を監視
- リリースタイムの計測
- ステータス毎のリクエスト数
- sidekiq のジョブ数の監視
- ジョブが詰まって障害になることを防ぎたい
- mruby でプラグインを実装
- TreasureData のジョブ数の監視
- Go でプラグインを実装
- GHEのディスク使用量の監視
- Ruby でサービスごとのディスク使用量を投稿
- お問い合わせ数を監視
- お問い合わせが急増していることを把握することも、サービスの異常の予兆の把握に繋がる
- DBに記録されているお問い合わせ数を Ruby の実装により取得、Mackerel に投稿
- いろいろな言語で手軽に書けるプラグインの実装は楽しい！
- インフラ周りだけでなく「いろいろなものを」「気軽に」モニタリングできるのが Mackerel。
Driving Mercari with 50+ custom Plugins・メルカリさん
ポイント
- かなりの Mackerel の使い込みを感じさせる、サービス・ロール設計。リアルタイムで発表を聴いていて、おもわず唸ってしまった。。
- 「異なるプラットフォームの情報をひとつにまとめる」という Mackerel のメリットを存分に活かしていただいていることも伝わってくる内容。
- プラグインに関しては別エントリとしてまとめきる予定なので、今しばらくお待ちを :pray:
- とにもかくにも、「コードを書いて問題解決を図る」ことの楽しさと、その力強さを終始感じる素晴らしい内容。
サマリー
- 日本版メルカリは「さくらインターネット・石狩DC」、US版メルカリは「AWS + GCP」、UK版メルカリは「GCP」と、ロケーションごとに環境を使い分けている
- そのうち、「さくらインターネット・石狩DC」、「US版メルカリのAWS」「UK版メルカリのGCP」それぞれのモニタリングソリューションとして Mackerel を活用している
- Mackerel を導入した理由
- 「サービス」設計
- リージョンごとにサービスを分ける
- mercari, mercari-us, mercari-gb
- 外形監視は別サービスに分ける
mercari-jp-external,mercari-us-external,mercari-gb-external- 通知チャンネルを分けるため
- あとはQA環境用、マイクロサービスの概念
- リージョンごとにサービスを分ける
- 「ロール」設計
- Mackerel では、ホストに複数のロールを付与できる。それを活かしている
- ロールの名称に、意味をもたせた prefix を付けるようにしている
role-prefix- サーバの基本的な役割。
role-muysqlrole-applicationなど
z-prefix- 共通の役割を示す。
- 多くのサーバは
z-commonに属する - php が入っているサーバは
z-phpを付与したりもする
x-prefix
- ロールの自動設定方法
/etc/mackerel-agent/conf.d/に、サーバによって異なる conf を配布、本体の mackerel-agent.conf ではそれを include しているrole-mysql.confz-common-jp.confなど。- role 名とほぼ一致しているが、完全に一致もしていない
- 配布は Ansible で実施
/etc/sysconfig/mackerel-agentにスクリプトを配置
- Mackerel による監視とプラグイン
- このパートは、別エントリとして紹介した・していきたい。
- Mackerel "kazeburo" plugin を通じてサーバーモニタリングのキモを探る 〜スクリプトプラグイン編〜 - えいのうにっき
- （近日中に書きたい）Mackerel "kazeburo" plugin を通じてサーバーモニタリングのキモを探る 〜Go言語製プラグイン編〜
- 問い合わせ数の監視はメルカリでも実施
- 障害の検知だけでなく、影響範囲の把握にも
- SREだけでなく、全チームが関わることで対応の迅速化
- 監視されていないサーバの自動検出
- IPアドレスの一覧と Mackerel のホスト一覧での取得結果を比較すれば把握可能
- その結果は slack に投稿
- Mackerel はコードを書いて問題を解決する使いがいのあるツール！
以上！
諸事情あり、会の開催から数週間経ってのこのまとめになってしまったけど、改めて、利用してくれている各社ならではの使い方が色濃くでていて、本当に素晴らしいイベントでした。
シンプルに・正しく設計されているツールやサービスこそ、さまざまな使われ方・柔軟な応用がされるところはあると思っていて、まさにそのことを様々な形で教えていただいたなぁ、というかんじ。簡単に・素早く利用を開始できることも去ることながら、こうした使い込み方をしてくれるユーザーのみなさんを引き続き満足させ続けられるようなサービスで有り続けなければならないよな、ということも強く思った一日でした......！
