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