めも帖

「めも帖」代わりにダラダラと書いていったり、めもしたりしているだけです。

Mackerel Meetup #3 Tokyo #mackerelio に参加してきた

1月22日に「Mackerel Meetup #3 Tokyo #mackerelio」に参加しました。特定のサービスに関するイベントは初めてです。着いたら、id:kiyohero (@)さんが見えたりして、「はてなのイベント」っぽかったです。

f:id:d4-1977:20150125233416j:plain

よいまとめ

すごーーく丁寧にまとめていらっしゃる方がいました。

Mackerel updateと2015年の展望 @stanaka

アーキテクチャ

スクリーンキャプチャー

  • 各サーバーの状況についてグラフを重ね合わせられる
  • キャパシティープランニングに使用できる
  • オートスケールに対応
    • サーバーが増減しても履歴が残る

数字

  • 6,000エージェントを超える
  • 2,400オーガニゼーション
  • ユーザー事例
  • IDCフロンティア連携

2014.9からのupdate

エージェント安定化

  • 最新 0.14
    • メトリック再送時の調整

エージェントプラグインの充実

サービスメトリックグラフ

  • サーバーには直接紐付かない情報
  • 応答時間や、エラーレート、アクティブユーザー数の取得をしてグラフ化
    • nginx のログを fulentdに入れてログを可視化している
  • サービスメトリックの監視

通知

  • 通知先の拡充
  • 通知テストが可能に

監視条件の強化

  • 監視条件でブラックリストを指定
    • サービスA全体ただしバッチサーバーを除く
  • ファイルシステム%監視
  • 埋め込みグラフ
    • ダッシュボード on Qiita::Team
    • 外部のサービスでダッシュボードを作ることができる

SPDY対応

  • 表示速度の向上
  • spdycheck.org

Commin soon

埋め込みグラフのゲスト閲覧

  • サービスレスポンスタイムを共有

Windows 対応

URLの外部監視

  • URLに対する監視
    • レスポンスタイム
    • スタータテスコード

Alert関連API

監視と通知を柔軟に

  • 監視ルールごとに通知先を指定
    • サービスごとに
    • 重要なのは別ルート

オススメ

Mackerelを中心に考える2015年代のサービス運用環境 フリークアウトでの事例

移行前の環境

調達と実装の課題

  • 急速にサービスが立ち上がっている
  • オンプレ環境なのでキャパシティーの見極めが難しい
  • 調達リードタイムがかかる
  • クラウドに移れば半分ぐらい解決
  • クラウドを使うには考え方と仕組みを変える必要がある

変えた

  • 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連携

結果・まとめ

  • 労働集約的な仕事が減った
  • 特定のクラウドに合わせて作りこむのが減った

資料

質疑応答

  • デプロイにかかる時間は

    • 1回数十秒〜で差分の同期(rsync
  • 退役サーバーのメトリックは?

    • slackに流しているので、あとで追う時はそこで
  • インスタンスはどこから?

    • AMIから
    • インスタンスのコピーではない
    • サーバーの設定を変更するときは、新しいグループを作って切り替え
  • まかれるにあってcloudforcastにない

    • 細かいネットワークの状態の監視まわり
  • 運用は?

    • 一人で
    • 差分はpull requestで
    • 専属でやってはいない
    • インスタンスがすごい数になったら専属で人が必要なるかも
  • 手元での開発は?

    • plackで手元で開発
    • テスト環境をつくって
    • AWSで…というときは、独自で
  • ハマったことは?

    • Packer化するときは
    • 試行錯誤に時間をかけた
    • プロビジョニングツールを捨てるタイミングが難しかった
  • まかれるにたいする費用効果は?

    • 個別に田中さんと相談
    • 開発とのフィードバックが早いのと、距離感が近くてよい
  • シェルスクリプトだとスケールしたときにどうする?テストは?

    • 1ファイルが大きくなるときに問題
    • テストはserverspecでしようかと
  • Perlスクリプトを作ってPerlでのテストとかしてもいいのでは?

  • AutoScalingのときに性能の入れ替えをしている?

    • 変えてない
    • コア単価が安いのを選んでスケールしている