Upgrade to Pro — share decks privately, control downloads, hide ads and more …

クラメソの監視サービスがその基盤に Mackerel を採用した話

Seigo Watanabe
November 06, 2020
3.1k

クラメソの監視サービスがその基盤に Mackerel を採用した話

クラスメソッドが提供するAWS監視サービス(監視オプション)。2018年にリニューアルした際に、その基盤としてはてな社のMackerelを新たに採用しました。なぜこれまで使っていたOSS実装から離れてSaaSに乗り換えたのか? なぜMackerelだったのか? 当時を知る担当者が赤裸々にお話します。

https://classmethod.jp/m/devio_2020_showcase/
https://dev.classmethod.jp/cloud/202011-report-aws-monitoring-mackerel/

Seigo Watanabe

November 06, 2020
Tweet

More Decks by Seigo Watanabe

Transcript

  1. 自己紹介 3 渡辺聖剛 ( Seigo Watanabe ) • クラスメソッド株式会社 AWS

    事業本部 パートナーアライアンス部 • 監視オプションサービスの (一応)プロダクトオーナー(のはず) • Mackerelアンバサダー(2019〜) • 好きな AWS サービス ◦ ACM, Route 53 ◦ AWS Systems Manager ◦ Amazon CloudWatch https://dev.classmethod.jp/author/watanabe-seigo/
  2. 4 監視オプション #とは クラスメソッドが 提供する監視サービスの名称 • 2018/11〜 • エンジン部に Mackerelを採用

    ※Mackerelは、  株式会社はてなの商標です AWS向けマネージドサービス「メンバーズ」の監視オプションを刷新|プレスリリース https://classmethod.jp/news/members-monitoring-hatena-mackerel/
  3. 5 監視オプション #とは (cont.) 現在(‘20/11)は ネクストモード社との 共同提供サービスが主軸 ◦ 運用代行とセット ◦

    こちらもMackerel使用 (‘19/06〜) ※クラメソの監視オプションも併売  その他SaaSリセールも AWS運用保守:運用代行オプション|AWS総合支援|クラスメソッドのサービス https://classmethod.jp/services/members/aws-operating/ クラウドの運用にMackerelを使ってみた|コラム|クラウドソリューション|サービス|法人のお客さま|NTT東日本 https://business.ntt-east.co.jp/content/cloudsolution/column-try-05.html
  4. • HOOT24(2013/02〜) ◦ 外部にアウトソーシング、運用支援コミ • フートモニタリング(2015/10〜) ◦ 旧称:HOOTLite, くらもん ◦

    Zabbix + 内製の拡張機能(Java,Ruby,Go ...) • その他:運用支援の時期と対象にあわせて ◦ Zabbix、Datadog ... 6 監視オプションより前の監視サービス リニューアルで何故 Mackerel を採用したのか? についてお話しします
  5. 7 過去に発表した内容のアップデートになります Mackerel Drink Up #9 Tokyo(’19/10/23) Mackerel Drink Up

    #9 Tokyo の LT で「弊社監視サービスの基盤に Mackerel を採用してみた」という話 をしてきた #mackerelio | Developers.IO https://dev.classmethod.jp/articles/201910-report-mackerel-drink-up-9-lt/
  6. 12 監視とは:何をするのか? • システムを常時観測・計測し • 異常が検知できたら • それに対して対処する 対処 Respond

    / Resolve 検知 Detect 計測 Measurement ・死活(Availability) ・性能(Speed) ・適正さ(Functionally) ・通知 ・自動復旧 ・閾値 ・ふるまい ・予測
  7. 13 監視とは:どこからどうするのか? • Blackbox (closed box) ... システムを外から監視 • Whitebox

    (open box) ... 内側から監視 得たい情報によって手法も異なる インフラ監視 (CPU,I/O ...) 疎通確認 (Ping, TCP Port) 外形監視 (L7監視) ネットワーク監視 (Traffic)  : OS監視 (メモリ,ディスク, LA ...) 性能監視・APM 合成(Synthetic)監視 ログ監視 ビジネスKPI  : Awesome Service System
  8. 15 そもそも:なぜ監視しなくてはならないのか? • 監視とは「そのシステムの稼働状況に責任を持つ」こと ◦ SLA, SLI, SLO ◦ 正しく動作し、設計通りの「サービス」を提供していること

    ◦ 意図しない動作・挙動はしていないか? • Q: とまっていいものは監視しなくても良い? → NO ◦ 止まっているべきものは正しく止まっていること ◦ コスト、セキュリティ ▪ だれか「お客さん」が居座ったりしていないよね?
  9. 18 クラスメソッドの運用支援・監視サービスの歴史 メンバーズ サポート HOOT24 (顧客別対応) フートモニタリング • 2013/02〜 •

    疎通監視・外形監視、 CloudWatchメトリクス • Equinix社 (siteROCK) • 24x7の有人監視・対応 • 運用支援もセット • 運用支援サービスの一環 • Zabbix、Datadog ... • 顧客にあわせて適宜選択 導入、運用サポート • 2015/10〜 • 旧称:HOOTLite • Zabbix + 内製拡張機能 ◦ Java, Ruby, Go ... • 通知は直接顧客へ (いわゆる無人監視) 顧客の要望に応じて新サービス順次投入 • フートオペレーション • パートナー社と提携した運用支援サービスの提供 ◦ JIG-SAW(運用代行オプション - 2018/09〜) ◦ ネクストモード(2020/07〜) → NTT東日本(クラウド導入・運用サービス) • メンバーズ会員向け • テクニカルサポート・ カスタマーサポート • 24x7 (一部平日のみ) ◦ 海外2拠点+日本 • AWS内で発生したイン シデントや Abuse の 通知など ※画像は2013年・2018年の資料より
  10. 20 フートモニタリング(Zabbix版) ➢ ベースにZabbix (開始当時 3.0.0) • on EC2 +

    RDS • Zabbix Proxyを複数台設置・運用 • 定期バックアップ・メンテナンス • zabbix-agentは使用せず OS内部メトリックはシェルスクリプトでCloudWatchへ • その他さまざまな機能拡張を内製の仕組みで実現 ➢ 独自コントロールパネルの提供 • Flask(Python)+ bootstrap + PyZabbixで内製 • ホストごとの監視閾値の確認・変更 • 時限式で監視を一時停止する機能の提供・コントロール ➢ AWSとの連携 リソースディスカバリ • 定期的に顧客AWS環境をチェック • 監視対象タグがついているリソースを収集し登録 ➢ 電話通知機能 • クリティカルな異常検知時には自動で架電 • ダイアル操作でのエスカレーション・EC2再起動指示 • Java + SQS/SNS + Rubyスクリプトで内製 • 架電部分にはTwilioを採用
  11. 21 構成図 ElasticBeanstalk Twilio API Java Let’s Encrypt CloudFormation Zabbix

    API Ruby Go Ruby Shell Script Flask Python Zabbix API Ruby 内部DSL
  12. 23 閉塞感? 課題点 • 最善を尽くしたが故の「内製の多さ・複雑さ」 ◦ 社内スキルとの乖離、メンテナ不足 ◦ 新機能追加どころか現状維持すら大変 •

    そもそも、弊社提供が「OSSのリフト&シフト」? ◦ 当時はそうあるべきだった。いまは? 高まるリニューアルの機運 でも、どのように?
  13. 24 クラメソが提供したい「監視サービス」とは??? • もっと最新のサービスも対応したい・監視して欲しい ◦ RDS Aurora, NLB, Lambda ...

    • 監視することを負担に思って欲しくない ◦ 手軽に導入 ◦ 見やすいダッシュボード • もっとクラウドネイティブでサーバーレスのメリットを 享受できる、いま風でかっちょいい(重要)サービスを ◦ そもそもAWSならびにクラスメソッドが主張していること などなど
  14. 25 必須要件 • SaaSであること(インフラ管理コストを下げられること) • AWSサービスとの親和性が高いこと • 既存メニューとの連続性を持たせられること • 日本国内での展開の容易さ

    • 運用面:設定自動化のための機能やAPIを持つこと クラメソ内で利用実績のあるものを 中心に、複数のSaaSで機能比較・検討
  15. 27 というわけで、Mackerelを採用しました • AWS連携・機能拡張あり ◦ mackerel-agent plugin、Webhook、Mackerel API • 外形監視も標準で備える

    ◦ 選考対象だった別SaaS  では不可だった(’18/04当時) • 純国内企業製・信頼と実績の「株式会社はてな」 ◦ 国内市場を熟知・優先しているハズ ◦ 開発も活発・毎週のように機能拡張 • UI:ダッシュボード、グラフ表示の見栄えの良さ ◦ クラメソ社内でも評判がよかった • その他契約やコストまわりなど諸々も問題なし
  16. 対処 Respond / Resolve 検知 Detect 計測 Measurement 30 つまりこんな感じ

    Whitebox 監視 Blackbox 監視 mackerel-agentによる ・メトリック監視 ・疎通・チェック監視 ・必要に応じカスタマイズ Mackerelサーバーによる ・Cloudインテグレーション  (AWS / Azure / GCP) ・URL外形監視 ・サービス・ロール ・監視ルール ・通知チャネル(グループ)  - メール、チャット  - 3rdPT API  - Webhook  - Amazon EventBridge ・ダッシュボード・可視化 ・mackerel-agentによる  チェック監視 action ・アラートダッシュボード
  17. 31 (勝手に考える)Mackerelのメリット • 国内事情によりそう機能セットと拡充方針 ◦ 重厚長大な他監視プラットフォームとは向きが違う ▪ 例:URL外形監視が初期から実装されているなど • out-of-the-box的な手軽さ

    ◦ デフォルトのUIの出来が良い ◦ アラート文面などカスタマイズ性が低いところもあるが… • 「計測」と「検知」がメイン機能 • シンプルな課金体制 • サポート・コミュニティ・ユーザーを向いた運営姿勢 ◦ はてな社 - クラスメソッドのパートナーシップ
  18. 32 監視オプションはMackerelをどう使っているか • 顧客の環境にMackerelを設定(初期構築支援) ◦ デフォルトのサービス・ロール ◦ 監視ルール(ヒアリングにて調整) ◦ AWSインテグレーション設定

    • 電話通知機能の提供 ◦ API Gateway + Step Functions + Lambdaで再実装 ◦ 異常検知 -> Webhookから駆動 ◦ 最大10件まで順次架電・エスカレーション • 導入作業・バックオフィス機能は Mackerel APIを駆使して極力自動化
  19. 対処 Respond / Resolve 検知 Detect 計測 Measurement 33 監視オプション(Mackerel

    + クラメソ) Whitebox 監視 Blackbox 監視 mackerel-agentによる ・メトリック監視 ・疎通・チェック監視 ・カスタマイズも容易 Mackerelサーバーによる ・AWSインテグレーション  (CloudWatchメトリクス) ・URL外形監視 電話通知機能の提供 - 多段エスカレーション - パッド操作での再起動 ・サービス・ロール ・監視ルール ・通知チャネル(グループ)  - メール、チャット  - 3rdPT API  - Webhook  - Amazon EventBridge ・ダッシュボード・可視化 デフォルトの提供 (初期構築支援)
  20. 構成(監視・通知) 34 顧客AWS Cloud RDS / Aurora Redshift ELB (

    ALB / NLB / CLB ) CloudFront Lambda EC2 mackerel-agent CloudWatch Metrics AWS Crawler External URL Monitoring 顧客 Webサイト Web UI TSDB 通知チャネル Webhook API Gateway Step Functions Lambda S3 Route 53 WAF ACM URL外形監視 AWSインテ グレーション API Call 通知 Webhook 通知チャネル メール Chat 架電 不通時はエスカレーション
  21. 37 coming soon - Mackerel 10/22 Mackerel Online Meetup #1

    Mackerel Online Meetup #1 〜Google Cloud インテグレーション〜 - connpass https://mackerelio.connpass.com/event/190810/
  22. 38 coming soon - Mackerel • Arm版mackerel-agent • 外形監視でリダイレクト先のステータスコードをフォロー •

    AWSインテグレーションBilling • GCPインテグレーションの機能追加 中長期ロードマップ • ロール内異常検知Windows対応 • 退役したホストのカスタムメトリックを残す改善 (※予定変更の可能性あり)
  23. 39 coming soon - Mackerel • Arm版mackerel-agent • 外形監視でリダイレクト先のステータスコードをフォロー •

    AWSインテグレーションBilling • GCPインテグレーションの機能追加 中長期ロードマップ • ロール内異常検知Windows対応 • 退役したホストのカスタムメトリックを残す改善 (※予定変更の可能性あり) 11/02 リリース完了 • Arm版mackerel-agent • 外形監視でリダイレクト先のステータスコードをフォロー
  24. 40 監視オプションでやりきれていないこと • Mackerelにあるのに採用できていないところ ◦ AWSインテグレーションの対応サービス追加 ▪ 特に最近はコンテナ周りの需要が高い ◦ 運営側のシステムのブラッシュアップ

    ◦ などなど • 監視オプションとはどういうものでありたいか ◦ (再び改めて)クラメソの提供したい監視とは ◦ AWSの方向性もにらみつつ検討中
  25. 41