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

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

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

Transcript

1. クラメソの監視サービスが その基盤に　　　　　　　を採用した話 渡辺聖剛＠クラスメソッド株式会社 2020.11.06
2. 今日話すこと Mackerel はいいぞ（ステマ） 2
3. 自己紹介 3 渡辺聖剛 ( Seigo Watanabe ) • クラスメソッド株式会社 AWS 事業本部 パートナーアライアンス部 • 監視オプションサービスの (一応)プロダクトオーナー(のはず) • Mackerelアンバサダー(2019〜) • 好きな AWS サービス ◦ ACM, Route 53 ◦ AWS Systems Manager ◦ Amazon CloudWatch https://dev.classmethod.jp/author/watanabe-seigo/
4. 4 監視オプション #とは クラスメソッドが 提供する監視サービスの名称 • 2018/11〜 • エンジン部に Mackerelを採用 ※Mackerelは、 　株式会社はてなの商標です AWS向けマネージドサービス「メンバーズ」の監視オプションを刷新｜プレスリリース https://classmethod.jp/news/members-monitoring-hatena-mackerel/
5. 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
6. • HOOT24（2013/02〜） ◦ 外部にアウトソーシング、運用支援コミ • フートモニタリング（2015/10〜） ◦ 旧称：HOOTLite, くらもん ◦ Zabbix + 内製の拡張機能(Java,Ruby,Go ...) • その他：運用支援の時期と対象にあわせて ◦ Zabbix、Datadog ... 6 監視オプションより前の監視サービス リニューアルで何故 Mackerel を採用したのか？ についてお話しします
7. 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/
8. Agenda
9. 9 Agenda • 監視とは（軽くおさらい） • クラメソの監視の歴史 • 監視オプション ◦ なぜMackerelを選んだか ◦ どう使っているか • 今後について
10. 改めて 監視とは（おさらい）
11. 11 監視とは “監視とは、 あるシステムやそのシステムの コンポーネントの振る舞いや出力を 観察しチェックし続ける行為である。” O'Reilly Japan - 入門 監視 https://www.oreilly.co.jp/books/9784873118642/
12. 12 監視とは：何をするのか？ • システムを常時観測・計測し • 異常が検知できたら • それに対して対処する 対処 Respond / Resolve 検知 Detect 計測 Measurement ・死活（Availability） ・性能（Speed） ・適正さ（Functionally） ・通知 ・自動復旧 ・閾値 ・ふるまい ・予測
13. 13 監視とは：どこからどうするのか？ • Blackbox (closed box) ... システムを外から監視 • Whitebox (open box) ... 内側から監視 得たい情報によって手法も異なる インフラ監視 (CPU,I/O ...) 疎通確認 (Ping, TCP Port) 外形監視 (L7監視) ネットワーク監視 (Traffic) 　： OS監視 (メモリ,ディスク, LA ...) 性能監視・APM 合成(Synthetic)監視 ログ監視 ビジネスKPI 　： Awesome Service System
14. 14 監視とは：どのようにするのか？ 今回は省略します。 →詳しくは以下をご参照ください（ステマ） • 監視・ログ分析を最初から始めるイマドキの事情と理由 ◦ https://youtu.be/OspNL5jYpio • みんなのAWS（技術評論社） ◦ https://gihyo.jp/book/2020/978-4-297-11329-2
15. 15 そもそも：なぜ監視しなくてはならないのか？ • 監視とは「そのシステムの稼働状況に責任を持つ」こと ◦ SLA, SLI, SLO ◦ 正しく動作し、設計通りの「サービス」を提供していること ◦ 意図しない動作・挙動はしていないか？ • Q: とまっていいものは監視しなくても良い？ → NO ◦ 止まっているべきものは正しく止まっていること ◦ コスト、セキュリティ ▪ だれか「お客さん」が居座ったりしていないよね？
16. 16 (つまり)「監視」とは • システムの動作・状態が意図通りかどうかを知るために、 • 様々な方法でシステムを継続して計測・可視化し、 • 適切な対処のために異常を検知・検出すること 　　　　　　　そのための「サービス」とは？ 　　　　　　　弊社(クラメソ)は何を提供すべきだろうか？
17. クラスメソッドの 監視サービス Zabbix - Wikipedia https://ja.wikipedia.org/wiki/Zabbix#/media/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:Zabbix_3.0.0_dashboard%EF%BC%BFjp.png
18. 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年の資料より
19. 19 クラスメソッドの監視サービスとは • 運用業務の支援・代行が出発点 • 極論すると、24x7監視の一次請けサービス 「監視に労力を割きたくない」 という顧客の要望を満たすためのもの • デフォルト監視ルールの提供 • 監視基盤（サーバー）のメンテナンス • 「あったらいいな」の提供 • 直接連携した運用支援サービス
20. 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を採用
21. 21 構成図 ElasticBeanstalk Twilio API Java Let’s Encrypt CloudFormation Zabbix API Ruby Go Ruby Shell Script Flask Python Zabbix API Ruby 内部DSL
23. 23 閉塞感？ 課題点 • 最善を尽くしたが故の「内製の多さ・複雑さ」 ◦ 社内スキルとの乖離、メンテナ不足 ◦ 新機能追加どころか現状維持すら大変 • そもそも、弊社提供が「OSSのリフト＆シフト」？ ◦ 当時はそうあるべきだった。いまは？ 高まるリニューアルの機運 でも、どのように？
24. 24 クラメソが提供したい「監視サービス」とは？？？ • もっと最新のサービスも対応したい・監視して欲しい ◦ RDS Aurora, NLB, Lambda ... • 監視することを負担に思って欲しくない ◦ 手軽に導入 ◦ 見やすいダッシュボード • もっとクラウドネイティブでサーバーレスのメリットを 享受できる、いま風でかっちょいい（重要）サービスを ◦ そもそもAWSならびにクラスメソッドが主張していること などなど
25. 25 必須要件 • SaaSであること（インフラ管理コストを下げられること） • AWSサービスとの親和性が高いこと • 既存メニューとの連続性を持たせられること • 日本国内での展開の容易さ • 運用面：設定自動化のための機能やAPIを持つこと クラメソ内で利用実績のあるものを 中心に、複数のSaaSで機能比較・検討
26. それって 　　　では？
27. 27 というわけで、Mackerelを採用しました • AWS連携・機能拡張あり ◦ mackerel-agent plugin、Webhook、Mackerel API • 外形監視も標準で備える ◦ 選考対象だった別SaaS　 では不可だった（’18/04当時） • 純国内企業製・信頼と実績の「株式会社はてな」 ◦ 国内市場を熟知・優先しているハズ ◦ 開発も活発・毎週のように機能拡張 • UI：ダッシュボード、グラフ表示の見栄えの良さ ◦ クラメソ社内でも評判がよかった • その他契約やコストまわりなど諸々も問題なし
28. Mackerelと 監視オプション
29. 29 Mackerel（マカレル）とは 株式会社はてな提供の 監視サービス 特長と機能 - 特長 - Mackerel（マカレル） https://mackerel.io/ja/features/ Hatena with AWS https://aws.amazon.com/jp/featured-partners-jp/hatena/
30. 対処 Respond / Resolve 検知 Detect 計測 Measurement 30 つまりこんな感じ Whitebox 監視 Blackbox 監視 mackerel-agentによる ・メトリック監視 ・疎通・チェック監視 ・必要に応じカスタマイズ Mackerelサーバーによる ・Cloudインテグレーション 　(AWS / Azure / GCP) ・URL外形監視 ・サービス・ロール ・監視ルール ・通知チャネル(グループ) 　- メール、チャット 　- 3rdPT API 　- Webhook 　- Amazon EventBridge ・ダッシュボード・可視化 ・mackerel-agentによる 　チェック監視 action ・アラートダッシュボード
31. 31 （勝手に考える）Mackerelのメリット • 国内事情によりそう機能セットと拡充方針 ◦ 重厚長大な他監視プラットフォームとは向きが違う ▪ 例：URL外形監視が初期から実装されているなど • out-of-the-box的な手軽さ ◦ デフォルトのUIの出来が良い ◦ アラート文面などカスタマイズ性が低いところもあるが… • 「計測」と「検知」がメイン機能 • シンプルな課金体制 • サポート・コミュニティ・ユーザーを向いた運営姿勢 ◦ はてな社 - クラスメソッドのパートナーシップ
32. 32 監視オプションはMackerelをどう使っているか • 顧客の環境にMackerelを設定（初期構築支援） ◦ デフォルトのサービス・ロール ◦ 監視ルール（ヒアリングにて調整） ◦ AWSインテグレーション設定 • 電話通知機能の提供 ◦ API Gateway + Step Functions + Lambdaで再実装 ◦ 異常検知 -> Webhookから駆動 ◦ 最大10件まで順次架電・エスカレーション • 導入作業・バックオフィス機能は Mackerel APIを駆使して極力自動化
33. 対処 Respond / Resolve 検知 Detect 計測 Measurement 33 監視オプション（Mackerel + クラメソ） Whitebox 監視 Blackbox 監視 mackerel-agentによる ・メトリック監視 ・疎通・チェック監視 ・カスタマイズも容易 Mackerelサーバーによる ・AWSインテグレーション 　(CloudWatchメトリクス) ・URL外形監視 電話通知機能の提供 - 多段エスカレーション - パッド操作での再起動 ・サービス・ロール ・監視ルール ・通知チャネル(グループ) 　- メール、チャット 　- 3rdPT API 　- Webhook 　- Amazon EventBridge ・ダッシュボード・可視化 デフォルトの提供 (初期構築支援)
34. 構成（監視・通知） 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 架電 不通時はエスカレーション
35. 35 採用して2年経ちました 良かったところ • サービスイン時に無い機能があとから増えた ◦ ダウンタイム機能、対応AWSサービス、 AWSインテグレーションAPI　等々 ◦ 計画通り（画像は省略） • 安定したサービス運営 • はてな社とは不定期的に直接意見交換
36. 今後
37. 37 coming soon - Mackerel 10/22 Mackerel Online Meetup #1 Mackerel Online Meetup #1 〜Google Cloud インテグレーション〜 - connpass https://mackerelio.connpass.com/event/190810/
38. 38 coming soon - Mackerel • Arm版mackerel-agent • 外形監視でリダイレクト先のステータスコードをフォロー • AWSインテグレーションBilling • GCPインテグレーションの機能追加 中長期ロードマップ • ロール内異常検知Windows対応 • 退役したホストのカスタムメトリックを残す改善 （※予定変更の可能性あり）
39. 39 coming soon - Mackerel • Arm版mackerel-agent • 外形監視でリダイレクト先のステータスコードをフォロー • AWSインテグレーションBilling • GCPインテグレーションの機能追加 中長期ロードマップ • ロール内異常検知Windows対応 • 退役したホストのカスタムメトリックを残す改善 （※予定変更の可能性あり） 11/02 リリース完了 • Arm版mackerel-agent • 外形監視でリダイレクト先のステータスコードをフォロー
40. 40 監視オプションでやりきれていないこと • Mackerelにあるのに採用できていないところ ◦ AWSインテグレーションの対応サービス追加 ▪ 特に最近はコンテナ周りの需要が高い ◦ 運営側のシステムのブラッシュアップ ◦ などなど • 監視オプションとはどういうものでありたいか ◦ (再び改めて)クラメソの提供したい監視とは ◦ AWSの方向性もにらみつつ検討中