Mackerel Day に行ってきたのでそのメモ書きです。
Mackerel Day は株式会社はてな様が開発しているSaaS型の監視サービスである Mackerel の正式リリースから3周年を記念したイベントでした。 セッションの内容としては、まずはてなのMackerelプロダクトマネージャー杉山様からMackerelの製品コンセプト、主な機能、これまでとこれからといった話から始まり、各ユーザ様(DMM.comラボ,Freee,GMO ペパボ,メルカリ)の導入/利用事例やはてなのMackerel開発チームの方々のMackerel関連のプロジェクトなどの話と続き、最後に、Mackerelが「AWS DevOps Competency」というDevOps領域でのパートナー資格を日本初で取得したことから、Amazon Web Service Japan酒徳様よりAWSのエコシステム/DevOps関連サービスに関するお話で締めくくられました。
当日のツイートは以下にまとめられています。
Mackerelは個人のクラウド上のOSリソース情報を取得しているだけでほとんど初心者に近い状態ですが、お誘いを受けたので参加してみました。
聴講セッション
Mackerelリリース3周年の振り返りとこれからの成長について 株式会社はてな 杉山様
Mackerelについては、元ははてなの中で2007年頃から10年間作り続けられてきたもので、はてなの動的なインフラをいかに効率よく管理するかと言う観点で社内で磨いてきた仕組みを、フルスクラッチで新たに製品化したものであるとのことでした。選ばれる理由として、UIのわかりやすさや、パブリッククラウドとの親和性の高さを挙げられてましたが、それらに加えて、はてなの方々のシステム運用経験をもとに作られてきたことがプロダクトの完成度を高め、同じような悩みを抱えるエンジニアの共感を得て多くのユーザの導入に繋がっているのかと思いました。
オススメ機能5選はアラート通知、URL外形監視、AWS Integration、オーガニゼーションを用いた柔軟な権限管理、グラフアノテーション。 「アラート通知」 はチャットツールへのアラート通知・グラフ投稿、fubotなどと組み合わせによる運用/開発間の連携のサポート(既存仕組みの効率化・ディスカッションへの発展等)のほか、Twilioなどの外部サービス連携があるようです。 「グラフアノテーション(注釈付与)機能」と言うものがあり、これはグラフの特定の箇所に注釈をつけることが可能で、これは例えばこの時間帯でロードアベレージのグラフが跳ねているのは「リリース直後で負荷が高騰したため」等のコメントを付けておき、後から見返したときに何があったかわかりやすくできるとのことで、他の監視ツールにはない機能で確かに使えると後々の振り返りの時などに便利そうでした。
AWS関連のプラグインが充実しておりAWSとの親和性が高く思えますが、Azureサポートも拡張しているとのことです。GCPについては言及されていませんでしたが、Mackerelエージェントを入れればプラットフォームに関わらず基本的なことはできそうです。 直近リリース予定の新機能としては、現在丸られた形で400日保存可能なデータを、丸られることなく400日保存可能にする、と言うものがあるそうです。どんだけのデータ量になりまたそれをどう管理されていくのか・・・。 また今後の展望として機械学習を利用した異常検知やLamdbaやコンテナツール/サービスのサポート拡張、構成を管理するレジストリとしての仕組みの充実等があるようです。
AWS DevOps CompetencyというDevOps領域でのパートナー資格を日本で初めて取得したとのことで、今後世界で勝負していくサービスになっていくような印象を受けました。
アプリケーションエンジニアがMackerelで楽しく監視構成している事例 株式会社DMM.comラボ 太田様 西岡様
DMM.make のサービスを、アプリケーションエンジニアが二人でオンプレからクラウド(AWS)に移行した中で、監視システムもZabbixからMackerelに変えた時の導入〜現在の利用状況のお話でした。
最初に会場にいる参加者はアプリケーションエンジニアかインフラエンジニアかを聞かれて挙手する場面がありましたが、だいたいアプリエンジニア:インフラエンジニアが4:6くらいのように見えました(違ったらすみません)。開発者にも運用者にも注目されているサービスであることが感じ取れました。
DMM全体としてはシステムをオンプレで統合管理されているようですが、今回のサービスをAWS移行はアプリケーションエンジニアの方二人のみで半年でやることになり、責任分解点も変わってAWSの運用管理も含めて全て面倒見ることになったとのことです。クラウド時代のインフラエンジニアの役割について危機感を抱いています。 今まではZabbixで監視していたそうですが、トライアル利用で2時間程度でやりたいと思っていたリソース監視とログ監視を設定出来たとのことで、アプリケーションエンジニアであっても簡単に導入/設定できるMackerelの良さが伝わりました。
導入に当たっての社内稟議の話もあり、比較検討し設定の容易さ、ドキュメントの充実度といった点から構築、運用管理時の人的コストが大幅に削減される点をアピールしたそうです。事務手続き周りは手間でスルーされがちですが、こういった話も聞けたのはよかったです。
まだ色々試行中らしいですが、充実したドキュメントや多数のプラグインでつまずくことなく楽に監視設定できること、モニタリングにより改善サイクルを回しやすくなり楽しい運用ができること、グラフから読み取れる異常など当たり前のことに気づけたとのことで、とにかく扱いが容易であることを強調されている印象でした。 また、Mackerelチームにフィードバックを送ったことがあるそうで、その時のフィードバックの速さ、要望した機能リリースのご連絡など、CREのきめ細かい対応の素晴らしさを感じました。
Mackerel インフラ基盤 AWS 移行の舞台裏 株式会社はてな 大野様
はてなのWebオペレーションエンジニアの大野様より、Mackerelの基盤をAWSへの移行、それに関する技術的な側面のお話でした。 主にはMackerelで使われている時系列DBに関して、その他、社内ツールを参照するためのUnbound、DBやRedis Clusterの冗長構成の仕組み、AWSのネットワークモニタリングについてのお話でした。
もともとオンプレミスで運用されていたMackerelを、AWS側のMackerelとデータセンター側のMackerelで、Mackerel AWS, Mackerel DCといった形で内部的にはサービス名を分けて平行稼働させ、最終的にDNS切り替えによって移行されたとのことです。 DNS切り替え時 mackerel.io ドメインのTTLは60秒にしていたようですが、丸一日は旧環境(DC側Mackerel)にアクセスが来続けていたようです。TTLを無視してアクセスが続くケースは多い気がします。
AWS移行の理由としては、Mackerelで扱っている主に時系列データベースのハードウェア的な限界、具体的には多量な監視メトリック情報を書き込むためにWriteが非常に多い時系列DBのために高スペックなハードウェアを調達し、さらに冗長性やスケール仕組みの構築や運用には手間も人的リソースもかかるため、そういった課題をクラウド移行することで解決するため、とのことです。
元の構成がどんなのかわかりませんが、この時系列DBは、AWS移行に伴いマネージメントサービスとEC2上の Redis Cluster を組み合わせたものに作り直したとのこと。 Redis Clusterでは送られて来たメトリックデータを一番最初に保存し、直近のデータを素早くブラウザから参照できるようにするためのものであるとのことで、構成や運用ノウハウについて話されていました。複数の Redis Cluster をシャードで分割しているそうですが、シャードが偏ることがあり、均一化を行う必要があるが、現状運用でカバーしているそうで、ElastiCacheがうまく解決してくれればそちらに寄せたいとのことでした。 Redis Cluster のメトリックは Redis プラグインで収集できるものもあるが、 Cluster 全体のイベントは収集できず、Redis Cluster プラグインも今はないが、最終的にはMackerelでグラフ化できれば良いとのことで、Mackerel基盤の運用で自分たちがぶつかった課題をMackerelサービスの機能拡張に繋げている印象でした。
また、AWS環境からはてなのサービスは社内ツールを使うために、Unboundを立てて社内の権威サーバを参照している構成となっているとのこと。MackerelのサービスもMackerel.ioにメトリックを投稿していおり、ioドメイン不調時もUnboundのキャッシュのおかげで参照できなくなっていることにすぐに気づけたそうです。
DBやRedis Clusterはアクティブスタンバイの構成となっているそうで、keepalivedとルートテーブル(VPCとサブネットのルーティングを制御する設定)を組み合わせており、keepalived がmasterの異常を検知するとルートテーブルを書き換えて faidover させる仕組みを自社内で開発しているとのことでした。
AWSのネットワークモニタリングに関しては、AWS側に依存するためオンプレほどは十分に関しできないが、TCPパケットの再送や、再送パケットの割合が見れるMackerelプラグインを使ってUPパケットの再送がTCPパケット全体の何割を占めるかなどをモニタリングしているそうです。 またAZ間の通信モニタリングではiptablesのnetfilterでどれだけのパケットがKernel空間を通過したかわかるそうです。
Mackerelで使われいる様々な技術に圧倒されましたが、さらにMackerelのシステム基盤自身もMackerelでモニタリングしていることで、その運用ノウハウからさらにMackerelサービスも進化していきそうです。
Q&A
- Q. 現在のAWSのリージョンは東京のみか？外形監視を他のリージョンからやる予定はあるか？
- A. 現在は東京リージョンのみであるがチーム内ではそういう話も出ているので将来的にはやる可能性はある。
- Q. AWS移行によりコストはどう変わったか?
- A. 当初は同じくらいになる予定だったが、今はそうなるように頑張っている。
- Q. AZ間の通信は発生するか?
- A. Redis ClusterのAZ間の通信が発生する。
大丈夫！ Mackerel には CRE がいます 株式会社はてな 井上様
はてなCREの井上様による、Mackerelの価値、それらをユーザに届けるためのMackerelプロダクトチームにおけるCREというロールの役割、具体的な取り組みについてのお話でした。
印象的だったのは、CREチームのKPIとして、問い合わせに対する"同営業日中の返答率 90%"、"翌営業日中の返答率99%"に加えて、"やりとりの平均回数2回未満"を掲げている点でした。現状の平均値は1.5-1.6回だそうで、お問い合わせ文面から、お客様の環境や状況、問題点を正確に探り当てる能力の高さを感じることができました。 また、エンジニアでもあるため、単なるお客様とのやり取りに止まらず、コードを書いて解決策を提示したり、ドキュメントを作成したりMackerelブログを書いたり、ハンズオンや説明会を開催したりと、CREの幅広い役割について理解できました。
freeeでMackerelを使って一年間サービスを運用してみた事例紹介 Freee 浅羽様
Freee 浅羽様からのFreeeでのMackerelの活用事例のお話でした。
導入前はVPCごとにZabbixを複数利用しており、Zabbixは機能豊富だがSRE３名で運用するには厳しくなってきたため移行を検討し、プロダクトの成長性、AutoScalingとの親和など多面的に評価された上でMackerelを選ばれたとのこと。また、NewRelicやCloudWatchなど、複数の監視ツールを組み合わせて使われいるそうです。目的に応じて複数のプロダクトを組み合わせて使うというのも良いですね。
Mackerelに関しては普段はSRE/開発チーム共にダッシュボードやサービス一覧を見たり、定期的に実施するパフォーマンス振り返り会でSREがどういう部分を見て何を判断しているかを開発チームと話して認識合わせする、障害時等にもグラフに投稿機能を使ってslackとかでシェアして見れるようにしている、デプロイした時は特にアラートが出やすいのでデプロイジョブのなかでアノテーション機能を使って記録しておく、アラート通知は基本的にはslackでWarning, Criticalといったアラートレベルに応じて見る人が異なる、など他チームとのコミュニケーションのためにうまく利用しているようです。 また、ダッシュボードの作成はmkrコマンドで行い、YAML形式の設定ファイルをバージョン管理しているとのことです。
QA
- Q. Zabbixの方が良かったと思うところ
- A. 移行に伴い監視項目を整理して、Mackerelに合わせて変更したのであまり意識はしていない。
Mackerelを導入して変わったN個のこと GMO ペパボ 高石様
GMOペパボ高石様より、ホスト1000台規模の環境でのMackerel活用事例のお話でした。 前半はMackerel導入&活用状況、後半は主に独自実装で様々なメトリックを収集している事例のご紹介でした。
元は複数のNagiosだったそうですが情報の一元管理や動的に変化できるクラウドライクなインフラ構成に対応するためにMackerelに移行したそうです。ただ、メンバーとしてジョインした時からMackerelがあったため、当時の詳細についてはご存知ないとのことでした。
アラート通知は日中の監視はslack、夜中はpagerduty/wakerとtwilioを連携されての電話通知とのこと。wakerを建てる前にpagerdutyを使い始めたため２つあり、使い分けているようです。後になってwakerが作られた経緯など少し気になりました。
後半では独自実装で以下のメトリックを収集している事例のご紹介でした。 Mackerelの運用上の課題をMackerelを使って解決する、Mackerelで管理しているホスト情報を使って課題を解決する、取得したいメトリックを自前実装で取得してMackerelに保存する、といったものが主だったかと思います。かなり使い込んでいる印象で圧倒されました。
- サービスディスカバリとして使う
- 退役忘れ・ロール設定忘れをチェックする
- ロール毎のサーバ数を数える
- Consul未所属サーバの検知
- リリースタイムの計測
- ステータスコード毎のリクエスト数を取得
- Sidekiqのジョブ数監視
- TreasureDataのジョブ数監視
- GHEのディスク使用量監視
- お問合わせの数を監視
QA
- Q. 運用ツールとしてMackerelでのモニタリングを活用されているということだが、他に面白い使い方しているものはあるか
- A. 金の相場の監視とかは弊社メンバーが個人でやっていた(会場笑)。AWSなどの外部サービスの料金を保存して可視化したい。
Driving Mercari with 50+ custom Plugins 株式会社メルカリ 長野様
メルカリ 長野様からの活用事例のご紹介でした。 細かなService, Roleの設計や様々な独自プラグインを使って監視については世界展開するサービスならではという感じで圧巻でした。
Mercariのシステムは、日本ではさくらの専用サーバを、USではAWSとGCPを、UKではGCPが使われており、これらのコアな部分でMackerelが使われているそうですが、US,UKのGCPの部分は他のプロメテウス、stackdriverが使われており、さらにkuradoと呼ばれる独自ツールやNewRelicも組み合わせているそうです。なお、元は日本、US, UK の環境ごとにZabbixがあったそうですが、複数リージョンで別々のZabbixの管理は手間がかかるためにMackerelに乗り換えたそうです。
Service設計についてはリージョンごとに分け、外形監視用に分けて専用の通知チャネルを用意し、さらにQA環境、マイクロサービスごとにも分けているとのこと。外形監視は頻繁には来ないが影響範囲が大きいので、SREのみならず、CSやプロデューサー、他のエンジニアなども参加しているチャンネルを準備しているそうです。
Role名の設計についてはPrefixつけるようにし、アラート通知の除外フラグなどの意味を持たせており、conf.d以下にRole毎のconfファイルを置いてincludeさせ、ROLEの自動付与をAnibleを使ってうまくやっているようでした。
セッション内で紹介されたカスタムプラグインについてはいくつかは以下で公開されています。 さくらの専用サーバ上でのメモリエラーやHW RAIDの監視などについても紹介がありましたが、上記の中にはないようで、どんな実装か気になりました。
その他の取り組みとして、ペパボ様同様お問い合わせ数や監視漏れしてるサーバの通知などもモニタリングしているとのことでした。
AWS Ecosystem with Mackerel AWS Japan 酒徳様
カスタマーユースでのAWSのイノベーション(devops周りのサービスのアップデート)とAWSコンピテンシープログラムについてのお話でした。
まず最初の大きなアップデートとしては・・・ロゴが変わった(会場笑)。
今やAWSのサービスは90以上あるが、その中でのdevops関連サービスとしては、CodeCommit(ソースコードのバージョン管理)、CodeBuild(ビルド自動化)、CodeDeploy/CloudFormation/ElasticBeanstalk(デプロイ自動化)、CodePipeline(ワークフロー管理)とあるが、これらをどう組み合わせれば良いのかというのをよく質問されるとのこと。これらはカスタマーフィードバックに入っており、一元的にデプロイするための AWS CodeStar というサービスがリリースされたのでこれを使うのが良いようです。(ただしまだ東京リージョンにはない)
マルチアカウント、マルチリージョンでのCI/CDに関する質問が多いとのことで、これはCloud Formation スタックという機能によって解決可能、また、CloudFormationで作った設定を誤って消してしまうケースが多いのでこれにプロテクションがかけられるようになったそうです。この辺は使ったことないので全然わからん・・・ AWS X-Rayというデプロイした時のデバッグやトレースが取れるサービスも紹介されてましたがこれもわからん・・・
AWSコンピテンシープログラムについてですが、業界のデフォルトとなるような仕組みとしての、AWSのエコシステムを支える企業は日本だけでも400以上あるそうです。では、これらの中からどれ使えば良いか、というのを判断する基準にもなるのがコンピテンシープログラムだそうです。 はてなのMackerelはこの中のDevOpsコンピテンシープログラムに対して、AWS Incが定める基準をクリアして取得され、これは日本では事例がない初のものとのこと。 AWS Inc側でも期待値が高く、特に評価されている点として、サービスディスカバリ機能、毎週のアップデート、AWSインテグレーションでのセキュリティ要件を満たしている点、Mackerelのアーキテクチャ、マネージドサービスをふんだんに利用している点などを挙げられていました。
最後に、パートナー各社のAWS上での実装について説明されている動画(英語)と、re:Invent についてのご紹介で締めくくられました。
まとめ
Mackerelはまだそれほど使っていないものの、いろいろな環境での事例を聞けてとても参考になりました。単なるサーバインフラの監視に止まらず、様々なモニタリングを行うためのサービスという印象でした。 企画・運営してくださったはてなの皆様、登壇者の皆様、ありがとうございました。
