だいぶ遅くなっちゃった。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 を運用
- 機能が豊富、作り込めばなんでもできる
- が、作り込みや運用に時間を取れない状況
- 移行を検討、いくつかのプロダクトを評価した
- 移行のしやすさ
- プロダクトの進化スピード
- 使いやすさ（GUI / API / CLI）
- コスト
- AutoScalingとの親和性
- 現状のfreeeでの監視構成
- リソース監視、外形監視、アラート通知：Mackerel
- APM：NewRelic
- AutoScalingのトリガー：CloudWatch
- アプリケーションのエラーログ集約：BugSnag
- セキュリティ監視：Deep Security as a Service for AWS
- サービス／ロール／ホストの考え方
- AWS側で付与しているタグの情報をそのまま Mackerel で利用
- サービス
- サービス名_ステージ名称
- ロール
- サービス内のサーバの役割（web, batch, worker 等）
- 開発エンジニアとのコミュニケーション
- 定期的にパフォーマンスふりかえり会を実施している
- そのためのダッシュボードは mkr コマンドで作成する
- さらに深掘りしたいときは NewRelic で
- グラフをもとにディスカッションしたいときは、各グラフのカメラボタン「グラフをチャンネルに投稿」が便利
- グラフアノテーションを利用してデプロイタイミングをグラフに記録
- サービスメトリックの使いどころ
- サービスに紐づくメトリックを投稿
- レスポンスタイム
- 非同期ワーカーの未処理のキュー
- サーバー台数
- 投稿方法はサービスメトリック投稿APIをLambdaでリクエスト
- サービスに紐づくメトリックを投稿
- アラートの通知
- 基本的には slack で
- 夜中のアラートは twilio 経由で電話を掛けさせている
- 利用している Mackerel のプラグイン
- mackerel-plugin-linux
- mackerel-plugin-mailq
- mackerel-plugin-multicore
- mackerel-plugin-mysql
- mackerel-plugin-nginx
- 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
- 当時の導入理由
- Nagios の管理が大変
- サーバーの追加・削除時に設定ファイルの更新が必要
- 監視サーバーも複数あり、どこを見ればいいのかがわかりにくい状態だった
- 「クラウドらしい」仕組みへ移行したかった
- サーバーの管理を手動でおこなっていた
- ボコボコ生まれ変わる時代には厳しい
- 監視設定の定期的な見直しにも繋がる
- サーバーの管理を手動でおこなっていた
- 情報の一元管理も
- パッケージ情報も
- OpenSSL の脆弱性対応の効率化
- 「監視サーバーが複数ある」ことも同じく課題
- Nagios の管理が大変
- 導入してどうなったか
- Nagios の管理が不要になり、本業に集中できるようになった
- 「クラウドらしい」仕組みへの移行ができ、サーバーの管理が楽に
- 「Mackerel を見れば、サーバーに関する情報がすべてある」状態になり、情報の一元管理もできるように
- サービスディスカバリとして使う
- デプロイ対象の取得を「あるロールのサーバの一覧の取得」のように、Mackerel でおこなうように
- 退役漏れ・ロールの設定漏れのチェック
- ロール毎のサーバー数を数える
- bash + consul + mkr
- サービスメトリックとして投稿
- Consul 未所属サーバの検知
- openstack コマンドで取得したサーバー台数と consul コマンドで取得したノード数を Mackerel に投稿、その差を監視
- リリースタイムの計測
- デプロイ時、リリース進捗を監視するスクリプトを Ruby で実装
- 完了時に、デプロイに掛かった時間を Mackerel に投稿する
- ステータス毎のリクエスト数
- nginx におけるステータス毎のリクエスト数を ngx_mruby でカウント
- それを、Goで書いたプラグインで取得、Mackerel に投稿
- sidekiq のジョブ数の監視
- ジョブが詰まって障害になることを防ぎたい
- mruby でプラグインを実装
- TreasureData のジョブ数の監視
- Go でプラグインを実装
- GHEのディスク使用量の監視
- Ruby でサービスごとのディスク使用量を投稿
- お問い合わせ数を監視
- お問い合わせが急増していることを把握することも、サービスの異常の予兆の把握に繋がる
- DBに記録されているお問い合わせ数を Ruby の実装により取得、Mackerel に投稿
- いろいろな言語で手軽に書けるプラグインの実装は楽しい！
- ペパボさんでの言語割合
- Python: 1, bash: 2, Ruby: 3, Go: 2, mruby: 2
- ペパボさんでの言語割合
- インフラ周りだけでなく「いろいろなものを」「気軽に」モニタリングできるのが Mackerel。
Driving Mercari with 50+ custom Plugins・メルカリさん
ポイント
- かなりの Mackerel の使い込みを感じさせる、サービス・ロール設計。リアルタイムで発表を聴いていて、おもわず唸ってしまった。。
- 「異なるプラットフォームの情報をひとつにまとめる」という Mackerel のメリットを存分に活かしていただいていることも伝わってくる内容。
- プラグインに関しては別エントリとしてまとめきる予定なので、今しばらくお待ちを :pray:
- とにもかくにも、「コードを書いて問題解決を図る」ことの楽しさと、その力強さを終始感じる素晴らしい内容。
サマリー
- 日本版メルカリは「さくらインターネット・石狩DC」、US版メルカリは「AWS + GCP」、UK版メルカリは「GCP」と、ロケーションごとに環境を使い分けている
- そのうち、「さくらインターネット・石狩DC」、「US版メルカリのAWS」「UK版メルカリのGCP」それぞれのモニタリングソリューションとして Mackerel を活用している
- Mackerel を導入した理由
- 異なるインフラストラクチャの監視項目・内容を共通化する
- 以前はリージョンごとに Zabbix を利用していた。
- バージョンがずれたり、監視内容に差が発生してしまっていたりしていた
- サービスメトリックの柔軟な使い勝手を評価
- Nagios と互換のあるプラグインも評価
- Mackerel 以外にも、Kurado, NewRelic なども使い分けている
- 異なるインフラストラクチャの監視項目・内容を共通化する
- 「サービス」設計
- リージョンごとにサービスを分ける
- 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- 監視用のフラグ。
role-mysqlはレプリケーション監視をおこなうが、x-mysql-masterを追加するとその監視対象からは除外する、など- この prefix を持つロールの適用は手作業でおこなうことがおおい
- diskの監視閾値の切り替えなどにも活用している
- ロールの自動設定方法
/etc/mackerel-agent/conf.d/に、サーバによって異なる conf を配布、本体の mackerel-agent.conf ではそれを include しているrole-mysql.confz-common-jp.confなど。- role 名とほぼ一致しているが、完全に一致もしていない
- 配布は Ansible で実施
/etc/sysconfig/mackerel-agentにスクリプトを配置- conf.d 以下のファイルを
role-def:で grep - conf.d 以下のファイルに
#role-def:ロール名のコメント行を追加しておくことで、上記のスクリプトでこれが読み取られ、エージェントの起動オプションとして利用されるようにしている
- conf.d 以下のファイルを
- Mackerel による監視とプラグイン
- このパートは、別エントリとして紹介した・していきたい。
- Mackerel "kazeburo" plugin を通じてサーバーモニタリングのキモを探る 〜スクリプトプラグイン編〜 - えいのうにっき
- （近日中に書きたい）Mackerel "kazeburo" plugin を通じてサーバーモニタリングのキモを探る 〜Go言語製プラグイン編〜
- 問い合わせ数の監視はメルカリでも実施
- 障害の検知だけでなく、影響範囲の把握にも
- SREだけでなく、全チームが関わることで対応の迅速化
- 監視されていないサーバの自動検出
- IPアドレスの一覧と Mackerel のホスト一覧での取得結果を比較すれば把握可能
- その結果は slack に投稿
- Mackerel はコードを書いて問題を解決する使いがいのあるツール！
以上！
諸事情あり、会の開催から数週間経ってのこのまとめになってしまったけど、改めて、利用してくれている各社ならではの使い方が色濃くでていて、本当に素晴らしいイベントでした。
シンプルに・正しく設計されているツールやサービスこそ、さまざまな使われ方・柔軟な応用がされるところはあると思っていて、まさにそのことを様々な形で教えていただいたなぁ、というかんじ。簡単に・素早く利用を開始できることも去ることながら、こうした使い込み方をしてくれるユーザーのみなさんを引き続き満足させ続けられるようなサービスで有り続けなければならないよな、ということも強く思った一日でした......！
