Mackerel Dayに行ってきました | イベントレポート

2017年10月5日開催のMackerel Dayに行ってきたので、イベントのレポートです

イベント概要

エンジニアをワクワクさせる「直感的サーバー監視サービス」 Mackerel（マカレル）の正式リリースから3周年を祝して Mackerel Day を開催します。
今回はAWS様の大きな会場をお借りしました、たくさんの方にお越しいただけますので、ぜひふるってご参加ください。
当日はMackerelを古くから使っているユーザ様から今年新たにご利用を始めたユーザ様まで幅広いユーザ様がご登壇していただきます。

Mackerelリリース3周年の振り返りとこれからの成長について

• Time 14:10〜14:30
• Speaker はてな 杉山 様
• slide

選ばれる理由

• 導入が簡単でわかりやすい
• 開発スピード(毎週リリース)
• マルチクラウド
• 日本語サポート

おすすめ機能

1. 多彩なアラート通知
   • チャットへのグラフ月通知
   • SMSや電話加電で通知(Twilio)
2. URL外形監視
   • SSL証明書の有効期限
   • カスタムヘッダ・メソッド
3. AWSインテグレーション
4. 大規模環境との親和性
   • 任意の権限でユーザーをオーガニゼーションへマッピング
5. グラフアノテーション

直近の主要なリリース

1. Azureインテグレーション
2. グラフボード機能
   • サービス内に任意のグラフを集めたページを作成可能（便利！！）
3. システムプラットフォームの堅牢化
   • ディザスタリカバリを想定
   • スケーラビリティの確保
4. DevOps Competency初認定

リリース予定

• メトリックデータの粒度を維持しながら保持 一分粒度を400日保持
  ※その他にも色々…

どういう方向で成長させていくのか

世の中の流れ

• 動的でかつ複雑化するインフラ環境
• クラウドサービス
• コンテナを始めとする仮想化技術

Mackerelとしての使命

• エンジニアにとってエッジなサービス
• ビジネスを加速化させるための仕組みであること
• 監視するだけでなく動的で複雑なインフラをより簡単にわかりやすくする仕組み
• DevOpsライフサイクルの中核として効率化を促進

shitake4.hatenablog.com

アプリケーションエンジニアがMackerelで楽しく監視構成している事例

• Time 14:35〜14:55
• Speaker DMM.com ラボ様
• slide

アプリケーションエンジニアがMackerelで楽しく監視構成している事例 from Keiko Nishioka

観点

• アプリケーションエンジニアから見た事例

導入ストーリー

• DMM.makeでの事例
• オンプレミスからクラウドへ移行
• クラウド移行することに伴いエンジニアの責務が変化

移行プロジェクトについて

• 使用するサービスAWS
• アプリケーションは大きく分けて３つが移行対象
• 担当は2人（専任ではない）

監視どうするか？

今まで

• Zabbixで監視し、アラートが着たら対応
• 監視サービスを独自にホスティングは厳しい

これから(構想)

• AWSで一括管理を想定
• CloudWatchとLambda

採用するための観点

比較するに当たっての観点

• 利便性

Mackerelは簡単かつ柔軟に設定できた。メトリクス取るのが楽

監視構成

監視対象

1. EC2,ALB,RDS アプリケーションのホスティング以外はマネージドサービスにお任せ
2. EC2
   • 各種メトリクス
   • ミドルウェア、アプリの死活監視
   • Checking log
3. その他 AWSインテグレーションにお任せ

Ansibleでのエージェント設定

• 狙った構成がサクッと入った
• 楽
• 気持ちいい

監視設定の管理

1. Jenkinsからmkr monitors push
   • 設定のJSONはGit管理
   • 各種メトリクス監視、URL外形監視
2. WEB上で設定をお試しすること多し
3. チャンネル設定は手設定

サービス・通知レベル毎にチャンネル設定

得られた価値

• 楽な監視構成
• つまづくことがほぼなし
  1. エージェントの設定
  2. プラグインの利用
• 日本語ドキュメント

気づき

• リソースが余ってる
• 通知時のグラフでパッと見てヤバさを把握できる
• アプリケーションエンジニアでも異常がわかる
• Monitors設定はオンプレベースで確認中

まとめ

• 必要充分な監視を行えている
• アプリケーションエンジニアでも扱える
• 導入が楽で、運用が楽しい

Mackerel インフラ基盤 AWS 移行の舞台裏

• Time 15:00〜15:20
• Speaker はてな 大野　様
• Slide

AWS移行の流れ

• Mackerelのサービス名を分けて移行
• DB、アプリケーション、DNSと切り分けて移行完了

※お客様から遠いところから移行

なぜAWSへ移行？

1. 時系列データベース
2. データセンター運用コストの削減

クラウドに移行して問題を解決したい！！

時系列データベースの移行

• mackerel-agent, APIが送るメトリックを保存
• 時系列データベースは自分たちで作り直した
• 移行時にはデータをコピーしながら2拠点（aws,データセンター）に書き込んでいた

時系列データベースの運用(Redis Cluster)

想定していた状態

• Elasticacheで運用

懸念点

1. 動的にスケールできない
2. クラスター作成後のノードが追加削除できない

実際の状態

Redis ClusterをEC2上で動かしている

Redis Cluster

複数のレディスをシャードとして分割している

1. キーでシャードを分けている
   • シャードが偏ることがある、つまり負荷が偏る
2. シャードが偏るとどんなことが起きるのか
   • CPU使用率がボトルネックになっている
   • maxmemoryにあたって書き込めなくなる
3. メトリックはredisプラグインで収集している

DNSキャッシュサーバ

社内の権威サーバーがデータセンタにある

• データセンタのサーバに問い合わせる構成
• 拠点ごとに権威サーバはない
• 社内ツールを使う為に依存している

Unbound

メリット

1. キャッシュを効率的にフラッシュできる
2. 他のキャッシュサーバの選択肢
   • dnscache
     • フラッシュさせるには停止が必要
   • dnsmasq
     • すべてのレコードをフラッシュしてしまう

unbound 運用

1. VPC内のリゾルバはTTL60で固定されている
   • MackerelホストのunboundはGoogle public DNSに問い合わせる
2. .ioドメイン不調時にはすぐに気づいた
   • Mackerelもmackerel.ioにメトリックを投稿している

アクティブスタンバイ構成の実現

1. DBはアクティブ、スタンバイ
   • keeepaliveでmaster,backup構成
2. keepalivedによるフェイルオーバ

AWSでのネットワークモニタリング

DCではスイッチからメトリックを収集していた

ネットワーク安定性モニタリング

• SNMPプラグイン
  • TCPパケットの再送、再送パケットの割合が見れる

AZ間の通信料モニタリング

• iptablesのチェインでみる
  • vpcフローログでなくても見れる

まとめ

1. AWS移行の見えない部分についてのお話
2. AWS移行は様々な技術に支えられている
3. AWSに移行したことでMackerel自体の監視、モニタリングも進化している
4. まだまだエージェントプラグイン便利にできる

shitake4.hatenablog.com

大丈夫！ Mackerel には CRE がいます

• Time 15:25〜15:55
• Speaker はてな 井上 様
• slide

CREとは?

顧客信頼性エンジニア

CREが在籍していることの意味

Mackerelによって提供されているもの

• サーバ監視が効率化されるという価値
• 動的なインフラ管理を実現することでDevOpsが加速されるという価値

→これらの価値はサービスが利用されることで生まれる価値

価値を支えるものは？

1. プロダクトそのもの
2. ユーザーからの信頼
   1. 技術力によって支えられている
   2. 向上させる他の要因

向上させる他の要因とは？

1. 投げかけた質問に対し的確な回答
2. プラグインの導入法などに対してドキュメントがあること
3. 知らない人が短期間で把握できること

上記３点を解決するのがCRE

CREは具体的に何をやっているのか？

投げかけた質問に対し的確な回答

• 寄せられた問い合わせにたして、出来る限り力になる
• 技術的な課題には立ち向かいたくなる
  • インフラエンジニア、SREという肩書は少数精鋭
  • インフラ基盤の安定運用というミッションに対しても、その少人数のメンバーに大きな責任がのしかかっているという現状

具体的な努力

• Mackerelとセットで使われることの多い技術・プロダクトについても日々理解を深める
• ミドルウエアの最新バージョンのコミットを追いかける
• 社内勉強会
• 輪読会

価値を向上させるもの1 投げかけた質問に対し的確な回答

成果（前期実績）

1. 同営業日中の返答率：90％
2. 〜翌営業日の返答率　99％
3. やりとり（往復）の平均回数　2.0未満

価値を向上させるもの2 プラグインの導入法などに対してドキュメントがあること

• 公式Webヘルプがいつでも閲覧可能
  • ヘルプドキュメント
  • APIドキュメント
• 公式ブログ

ドキュメントの管理方法

• 公開されているドキュメントはGithubで管理
• 公開までのフローをコマンドラインで公開可能

価値を向上させるもの3 知らない人が短期間で把握できること

• ハンズオンを開催
• 直接説明に伺う
• 魅力を伝える為にイベントに登壇

freeeでMackerelを使って一年間サービスを運用してみた事例紹介

• Time 16:00〜16:20
• Speaker freee 浅羽 様
• slide

導入前の話

1. Zabbixを使用

   • VPC毎にzabbix serverを運用
   • 機能が豊富なので作り込めば色々なことが出来る
     • しかし作り込みや運用に時間を取れない状況

2. いくつかのプロダクトを評価した観点

   • 移行のしやすさ
   • プロダクトの進化スピード
   • 使いやすさ
   • コスト
     • AutoScalingとの親和性

ZabbixからMackerelへ

現在の監視構成

• Mackerel
• NewRelic
• CloudWatch
• Bugsnag
• Deep Security as a Service

Service, Role, Hostの考え方

プロビジョニングやデプロイはEC2タグで処理を分けているので、タグの情報をそのままMackerelへ移植

サービス開発エンジニアとのコミュニケーション

• ダッシュボードかサービス一覧のグラフを眺める
  • 定期的にパフォーマンス振り返り会を実施
  • ぽちぽち作るのは面倒なのでmkrコマンドで作る
  • さらに深掘りしたい場合は、NewRelicで確認する
• 何かあったときやグラフをシェアしたいとき

デプロイの記録を行う

• いつデプロイしたかわかるように記録

サービスメトリックの使い所

1. サービスに紐づくメトリック
   1. レスポンスタイム
   2. 非同期ワーカーの未処理のキュー
   3. サーバ台数
2. サービスメトリックの放り込み方

アラート通知

1. 基本的にはslackに通知
   1. WarningはSREが見る
   2. Criticalは広めに通知
2. 夜中のアラート
   1. PagerDutyなどは使わずに雑にbotが電話をかけていく
   2. slackに誰か反応したら電話を切る

Mackerelの設定

1. Host Statusの初期状態はstandby

   • AutoScalingのUserDataが動いている間はアラート出したくない
   • UserDataの中でmkrを叩いてworkingに戻す
     • 構築でコケた場合も

2. 実験的機能

   1. とりあえずonにしておく

Mackerelに欲しい機能

1. 毎月の支払い（レシート）をPDFで欲しい
2. AWSインテグレーションも自動退役機能が欲しい
   1. EC2でないリソースを主にstaging環境で作ったり消したりするので、消すスクリプトを作った
   2. タグ・除外タグをサービスごとに設定出来ると嬉しい

まとめ

全く問題なく運用できてます

質問

1. Zabbixの頃のほうがよかったことはあるか？
   • 特にない。Mackerelで出来ないものもあったが、そもそも監視する必要のないものだったりしたので、監視すべきことが整理出来たのが、よかった

shitake4.hatenablog.com

Mackerelを導入して変わったN個のこと

• Time 16:25〜16:55
• Speaker GMOペパボ 高石 様
• slide

使用状況

• サービス：20
• メンバー:100
• ロール:300
• ホスト：1000
• サービスメトリック:300
• 外形監視：70

Mackerelが使われるキッカケ

1. nagiosの管理が大変
   • サーバーの追加、削除時に設定ファイルの更新が必要
   • SERF&イベントハンドラでいちおう自動化は可能
   • 監視サーバーが複数ある
     • どこをみればいいのかわからない
2. クラウドらしい仕組みへの移行
3. サーバーの管理を手で行っていた
4. サーバーがボコボコ生まれ変わる時代だと厳しい
5. 監視設定の追加
6. 情報の一元管理
   • サーバ自体とパッケージ情報も管理したい
     • パッケージ更新したっけ？をなくしたい
   • 監視サーバーが複数あるのも同様の問題

Mackerelに移行した結果どうなったか？

1. nagiosの管理が大変
   • nagiosの管理が不要
2. クラウドらしい仕組みへの移行
   • サーバーの管理が楽
3. 情報の一元管理
   • Mackerelのページを見ればすべて載っている

どのような使い方？

1. サービスディスカバリとして使う
   • 何かをデプロイするときに、デプロイ先を知りたい
2. 退役忘れ、ロール設定忘れをチェックする
3. 退役忘れで無駄にライセンス消費
4. ロール設定忘れて、運用に支障
5. ロール毎のサーバー数を数える
6. consul未所属サーバーの検知
7. リリースタイムを計測したい
   • 改善したときにどの程度改善出来るのか知りたい
8. ステータスコード毎のリクエスト数を取得
9. sideKiqのジョブ数監視
   • ジョブが詰まって障害になっている時に気づきたい
   • 過去の特定時点でどの程度ジョブが溜まっているかみたい
10. TreasureDataのジョブ数監視
    • ジョブが詰まると他のジョブに影響することがある
    • エラーには気づけるが、その後リカバリ作業が必要
    • ジョブ数を関しして、閾値を超えたらアラートしたい
11. GHE(GitHub Enterprise)のディスク使用量監視
    • ディスク利用量が突如異常な増加
    • いまいち原因が分からないので監視したい
12. お問い合わせ数を監視
    • お問い合わせが急増していないか知りたい
    • リリース後の思いがけないバグ

まとめ

• やりたいことに集中できる
• １つのダッシュボードを見ればすべてわかる
• インフラ周りだけでなくいろんなものを気軽にモニタリング

Driving Mercari with 50+ custom Plugins

• Time 17:00〜17:40
• Speaker メルカリ長野 様
• slide

メルカリ＆インフラストラクチャの紹介

• 日本 さくらインターネット（石狩DC）
• アメリカ　(AWS, GCP)
• イギリス (GCP)

Mackerel導入理由

1. 異なるインフラストラクチャの監視項目・内容を共通化する
   • 以前はregion毎にzabbixを利用。バージョンがずれたり監視内容の差が発生
   • Service/Roleを利用することで管理
2. サービスメトリクスの柔軟な使い勝手
3. nagios互換のplugin

Mackerel以外の監視

1. Kurado
   • 基本的なメトリクスはこちらで管理
2. NewRelic
   • アプリケーションのチューニングの参考

Service/Role設計&デプロイ

1. サービスを行うregion毎にServiceを分ける
2. 外形監視は別Service
   • 通知チャンネルを分けるため
3. QA環境・マイクロサービス

Role設計

Role名のPrefixに意味を持たせる

• role-　サーバーの基本的な役割
  • role-mysql, role-applicationなど
• z- 共通の役割
  • 多くのサーバーはz-commonに属する
• x- 監視上のフラグ
  • role-mysqlはレプリケーション監視を行うが、x-mysql-masterを追加することで監視除外する

ROLEの自動付与

サーバに付与するRoleをどこかで自動で設定したい
conf.d以下のファイルに #role-def:ロール名 を追加すると起動時に読み込み、agentの起動オプションとして利用

1. Roleのprefixに意味を持たせる。conf内にRole名を書いて自動で設定
2. confはansibleで配布

監視にまつわる数字

1. 監視ルール数: 265
2. Host毎の監視ルール数
   • Mysql 34
   • Application 39
   • Search 36
3. カスタムプラグイン +50

カスタムプラグイン

z-commons

1. check_resolver
   • resolv.confを独自に読み込んで名前解決する
2. diff-detector
   • コマンド結果の変化があるとアラート
   • 'cat /etc/passwd', 'uname -a', 'hostname' を見ている
3. check-iptables
   • さくらの専用サーバはすべてglobal ipを持つ。不要なサーバはdisableにして運用
   • 不用意な iptables --list　でiptables_filterが読み込まれ、パフォーマンスに影響するのを発見
4. check-uptime
   • 不意な再起動を検知
   • 閾値は2分-10秒。1回アラートが来てすぐに復旧する
   • Mysqlやmemcachedでも行っている
5. check-inode
   • inode 枯渇防止
6. check-machine-exceptions
   • メモリ異常を検知した際のログを監視
7. check-raid-disk(MegaRAID)
   • MegaCLIを使い各物理Diskの状態を監視
8. mackerel-plugin-ntpq
   • OffsetとリモートとのSync状況の可視化
9. mackerel-plugin-linux-lite
   • 2Coreから56Coreまでサーバがある
   • 一貫した監視閾値を設けやすいように可視化

z-commons以外のplugin

1. periodic-checker
   • 特定の時間のみ監視を行う
2. check-dns-rr
3. check-spf-and-reserve-lookup
   • メール配信にて利用
   • サーバが持っているGlobalIPすべて確認
4. chech-mysql-slave-sql-error
   • レプリケーションが止まった時に、その理由も通知してくれると便利で作ったPlugins便利で作ったPlugins
5. check-mysql-msr
   • MySQLのMulti Source Replicationの監視
6. mackerel-plugin-msr
   • check-msyql-msrの可視化

その他の取り組み

1. 問い合わせ数の監視
   • 多くの人が参加するChannelへ通知
   • 障害の検知、影響範囲の把握
2. 監視されていないサーバの自動抽出
3. slackへの通知
   • 1日2回slackへ通知
     • 監視されていないサーバ
     • standby,poweroffのサーバ

まとめ

1. コードを書いて問題を解決する
2. Mackerelは使い勝手のいい監視ツール

AWS Ecosystem with Mackerel

• Time 17:45〜18:15
• Speaker 酒徳 様

DevOps関連サービス

• ソースコードのバージョン管理
  • CodeCommit
• ビルド自動化
  • CodeBuild
• デプロイ自動化
  • CodeDeploy
  • CloudFormation
  • ElasticBeanstalk
• ワークフロー管理
  • CodePipeline

CloundFormation

• Infrastructure as a code
  • AWSリソースの環境構築を自動化
• ChangeSet Support
• StackSet Support

Security

1. ユーザ/クレデンシャル管理
2. アクセス権限管理
3. 権限の委任と監査

イベント行ってみての所感

これからMackerel使いこなしていきたいなと考えてのイベント参加だったので、使うのが楽という発表を聞いて色々と触ってみたりしたいという欲求が更に高まりました

読者です 読者をやめる 読者になる 読者になる