こえむの編集後記

コンピュータ スキー そして旅の話を綴ります

ITインフラ 催し

Mackerel Meetup #3 へ行ってきました

昨夜は、はてなさん主催の「Mackerel Meetup #3」へ足を運んできました。

Mackerelとの自分の関わりとしては、会社や個人で検証を進めたり、プラグインを書いたりしているところです。今回の　Meetup では、自社サービスでの採用状況を知ることができました。Mackerel を中心に IaaS や PaaS を利用してITインフラ運用の自動化を進めることで、大規模でさえ無ければ専任の運用担当者が不要になるレベルにまで運用コストが下げられることを身をもって知ることとなりました。

あと、要望は積極的にWebフォームから送っていいのだなってのを、この日知りました。

僕は、MSP というお客様からITインフラを預かって構築・運用・提案を行う業態の会社にいるため、恐らく自社サービスでの活用とはまた違った側面で Mackrerl を使えるのではと考えているところです。それに、今出つつある事例を実践する会社が増えると、これまでのような監視して一次対応する MSP の存在価値って下がるんじゃないかなと危機感もあります。

懇親会ではアジフライをいただきました。会場を提供いただいたフリークアウトさん、食事も提供いただいたはてなさん、大変お世話になりました！

それでは、いつものようにノートをアップしておきます。

概要

開催概要

  • 開催日：2015年1月22日（木） 19:00受付開始、19:30スタート
  • 場所：株式会社フリークアウト ヒルズガレージ（六本木）
  • 定員：80名程度
  • 参加費：無料

プログラム(予定)

  • 19:30–20:00 Mackerel updateと2015年の展望 @stanaka
  • 20:00–20:30 Mackerelを中心に考える2015年代のサービス運用環境 フリークアウトでの事例 @myfinder
  • 20:30? 懇親会
  • ピザ、ビール、サバ料理などを提供予定です。抽選で Mackerel パーカーが当たるイベントも企画中です

Mackerel updateと2015年の展望 @stanaka

  • 利用者 会場で3割くらい
    • 僕も個人用と会社の検証用で使っている

  • 概要紹介

  • 数字で見るMackerel
    • Active Agent数 6,000〜
    • 全Org 2,400〜
  • 事例

  • IDCF連携

  • Update
    • Agentの安定化: 0.14
      • 再送時の調整: サーバが止まったりしたときに、バッファリングする仕組みのチューニングを施している。
      • 一部環境でメトリックが収集できなかった点を修正。
    • Agentプラグインの充実: 0.6.2
    • サービスメトリック
      • アプリの応答時間、エラーレート等を蓄積する。
      • ログの集計、AWS CloudWatchのログ等を送る。
    • 監視
      • 通知テスト可能に
      • 通知先を多種多様なチャットツールに投げられるようにした
      • ブラックリスト(除外) – 一部のマシンをルールから除くことができる
        • 本日リリース！！！
      • ファイルシステム％基準監視 (欲しかった！！！)
    • 表示
      • 埋め込みグラフを引っ張る
        • これでカスタマイズしたダッシュボードを自分で作ることができる。
      • SPDY対応
        • 読み込みが早くなって良くなった。
  • 今後
    • 埋め込みグラフのゲスト表示対応
      • 現在はログインして参照権限があるユーザのみ
    • Windows対応
    • URL外部監視
      • やった！外形監視だ！
      • パフォーマンスも測ることができるようになる模様。
    • Alert対応API
    • 監視・通知ルールの設定を柔軟に行えるようにする
      • サービス毎に別チャネル
      • 重要なものだけ緊急ルートで
  • 使ったこと無い人へ: オススメ！
    • とりあえずAgentを入れてみよう
    • ミドルウェアプラグインを使ってみよう
    • 普段目にする所に埋め込みグラフを貼ってみよう
  • OSSの他のツールと比べてどの辺りがメリットか
    • インストールが容易・監視サーバ自体の運用が不要
    • UIが平易・学習コストが低い
    • ミドルウェアプラグイン・外部サービス連携を標準でサポート
  • フィードバックは積極的にした方がよさそう。
    • 海外のサービスと違って結構回答くれるみたい。
  • 感想
    • 着実かつ運用で必要だなと感じていた機能が実装されつつある。
    • そして、自分自身が欲しいと思っていた外形監視が入りそうなので嬉しい！！！

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

  • 背景
    • 子会社(MT Burn)で開発しているサービスが対象。
    • 「どオンプレ」で作ったサービスをAWSに移し替えた
    • そのときに運用環境も刷新。
    • Mackerelの採用に至る。→とってもはかどる！！！
  • 移行前の環境
    • オンプレ＋S3/CF
    • まあよくある感じ、ですかね。
    • 消耗 しがちな環境！！！
  • 懸案
    • 調達
    • 実装速度
  • 課題
    • 性能が箱で規定されている…複雑なプロビジョニングが求められる
    • オンプレはリードタイムが大きい
    • などなど
    • クラウドに移れば 半分 は解決できる
    • 残りの半分→考え方・仕組みの変更→オートスケール等等
  • 変えた点
    • Mackerelを管理の中心に
    • マネージド(PaaS)に積極的に切り替え
  • Mackerel
    • サーバリストの細かいメントが不要(APIで取れる)
    • ロールベースでの管理が楽
    • サービスメトリックが充実してきてサービス全体の稼働状況管理がはかどる
    • 開発者が身近にいたから直接聞けた
  • グラフの連続性
    • サービスメトリック
      • オートスケールしている様子が分かる
      • AWS CloudWatchの情報がわかる
    • Norikraを絡める
      • ビジネス指標も取れる(1分の分解能)
  • その他
    • オートスケール前提なので、サーバに 名前はついていない 。
    • BigQuery: 自前でがんばるより断然早いので、使わない理由はない。
  • ツール・オペレーションの改善
    • 運用担当は自分1人
      • でも運用自体の作業はほとんどない
      • 規模が上がってきたら変わるかもしれない
    • ログ解析: 足元のストレージで集計→Fluentdへ
    • Capistrano + Mackerel連携を活用
    • プロビジョニング: Puppet→Packer + Shell
      • サーバ停止時に自動的に退役、initスクリプトの停止で止まるようにしている。
    • デプロイ: S3経由のPull型
      • 種サーバでビルドしたものをS3に同期
      • 各サーバはS3から取得
      • オートスケール時はcloud-initでpull処理を走らせている
  • 質疑応答
    • 質問: 退役したホストのメトリック参照ってどうしてるの？管理できるの？
    • 回答: チャットに退役したサーバの記録を残している。問題があればチャットログからサーバを探し出している。 (※注: 退役ホストはMackrerelに残ります)
    • 感想: MSPとかで同じことをやろうとしたら、サーバの起動終了ログを何らかの形で管理しないと行けなさそう。チャットログで管理できるってのは、自社のサービスならではだなと思った。
  • 感想
    • 「消耗しない」「オーバーワークしない」というバランスを考慮した結果の着地点とのことだった。適度な負荷がかかる自社サービス運用の良いモデルになりそう。
    • Shellの原点回帰、思い切っている。とはいえ、大まかな所はShell、細かい所はPackerやItamaeとかでこなせたらそれで充分だろうし、引き継ぎもしやすそう。
    • こういうことができる状況になると、MSPはどのような役割でいるのが良いのか再考しないとね。

関連投稿

ITインフラ

趣味の #AWS – koemu.com の内側

催し 日記 音楽

初・ピアノの発表会で息子と連弾をしてきたよ #ピティナ

プログラミング 催し

#builderscon 2019 に足を運びました