Mackerel Meetup #3 Tokyo #mackerelio に参加してきた
1月22日に「Mackerel Meetup #3 Tokyo #mackerelio」に参加しました。特定のサービスに関するイベントは初めてです。着いたら、id:kiyohero (@kiyohero)さんが見えたりして、「はてなのイベント」っぽかったです。
よいまとめ
すごーーく丁寧にまとめていらっしゃる方がいました。
Mackerel updateと2015年の展望 @stanaka
アーキテクチャ
スクリーンキャプチャー
- 各サーバーの状況についてグラフを重ね合わせられる
- キャパシティープランニングに使用できる
- オートスケールに対応
- サーバーが増減しても履歴が残る
数字
- 6,000エージェントを超える
- 2,400オーガニゼーション
- ユーザー事例
- IDCフロンティア連携
2014.9からのupdate
エージェント安定化
- 最新 0.14
- メトリック再送時の調整
エージェントプラグインの充実
- 0.62
- github上にある
サービスメトリックグラフ
- サーバーには直接紐付かない情報
- 応答時間や、エラーレート、アクティブユーザー数の取得をしてグラフ化
- nginx のログを fulentdに入れてログを可視化している
- サービスメトリックの監視
- 応答時間を監視するとか
通知
- 通知先の拡充
- 通知テストが可能に
監視条件の強化
- 監視条件でブラックリストを指定
- サービスA全体ただしバッチサーバーを除く
- ファイルシステム%監視
- 埋め込みグラフ
- ダッシュボード on Qiita::Team
- 外部のサービスでダッシュボードを作ることができる
SPDY対応
- 表示速度の向上
- spdycheck.org
Commin soon
埋め込みグラフのゲスト閲覧
- サービスレスポンスタイムを共有
Windows 対応
URLの外部監視
- URLに対する監視
- レスポンスタイム
- スタータテスコード
Alert関連API
監視と通知を柔軟に
- 監視ルールごとに通知先を指定
- サービスごとに
- 重要なのは別ルート
オススメ
Mackerelを中心に考える2015年代のサービス運用環境 フリークアウトでの事例
- @myfinder
- エムティーバーン
- http://mtburn.jp/aboutus.html
移行前の環境
- S3+CDN
- 箱物のロードバランサー
- オンプレ環境
調達と実装の課題
変えた
- Mackerelをサーバー管理の中心にした
- マネージドサービスの活用
- ツールオペレーションの改善
- アプリ以外は全部変えた
Mackerelをサーバー管理の中心
- サーバーリストの細かいメンテナンスが不要
- ロールで管理
- オートスケールでの履歴が残る
CloutWatchの対応
- 公式手順でカジュアル
Norikra の活用
- 分速で売り上げ、支払いをみれる
Mackerel + slack
- ケータイがアラートメールで一杯はなくなった
- 監視あるある
BigQuery
- 内部DNSもRoute53で扱えるようになったので移行
- ELB/AutoScaling
- BigQuery
- Hiveと比較して楽
- 車内に置いておく必要がない
ツール/オペレーションの改善
- ログ収集の変更
- fluentdでS3/BigQuery
Pupet廃止、Packer採用
- Packer + Shell で十分
- AutoScaling の時は、Mackerelをリタイアさせることを忘れない
- /etc/init.d 配下のスクリプトを用意している
- sleep を入れて、fluentのフラッシュに対応させている
デプロイの方法の変更
- S3を経由している
- pull型deploy
- S3から各サーバーが取得する
- CapistranoのMackerel連携
- AutoScaling で起動する際はcloud-initで取得処理
- supervisor を止めるとELBに入らない
CapistranoのMackerel連携
- 公式にある
- http://help-ja.mackerel.io/entry/advanced/capistrano-2.x
- デプロイのスケール
結果・まとめ
- 労働集約的な仕事が減った
- 特定のクラウドに合わせて作りこむのが減った
資料
質疑応答
デプロイにかかる時間は
- 1回数十秒〜で差分の同期(rsync)
退役サーバーのメトリックは?
- slackに流しているので、あとで追う時はそこで
インスタンスはどこから?
- AMIから
- インスタンスのコピーではない
- サーバーの設定を変更するときは、新しいグループを作って切り替え
まかれるにあってcloudforcastにない
- 細かいネットワークの状態の監視まわり
運用は?
- 一人で
- 差分はpull requestで
- 専属でやってはいない
- インスタンスがすごい数になったら専属で人が必要なるかも
手元での開発は?
ハマったことは?
- Packer化するときは
- 試行錯誤に時間をかけた
- プロビジョニングツールを捨てるタイミングが難しかった
まかれるにたいする費用効果は?
- 個別に田中さんと相談
- 開発とのフィードバックが早いのと、距離感が近くてよい
シェルスクリプトだとスケールしたときにどうする?テストは?
- 1ファイルが大きくなるときに問題
- テストはserverspecでしようかと
Perlでスクリプトを作ってPerlでのテストとかしてもいいのでは?
- シェルスクリプトといっても、コマンド実行が大半なので今は問題なし
AutoScalingのときに性能の入れ替えをしている?
- 変えてない
- コア単価が安いのを選んでスケールしている