Monitoring Seminar in mercari

Monitoring Seminar in mercari に行ってきました！ 📊

• Monitoring Seminar in mercari - connpass
• Twitter ハッシュタグ #mxm_monitoring

メモを晒す。

メルカリのサービスの監視について

メルカリのサービスの監視の変遷についての話。

• 最初はさくらインターネットで日本向けサービスをやっていて ZABBIX を使っていた
• その後さくらの専用サーバとさくらのクラウド併用
• US サービスが出来て、これはAWSで監視は ZABBIX
• ZABBIX は2個あって( JP, US ) 監視項目が異なったりして複雑なトリガーは動かなかったりとかがあった

その時の ZABBIX の課題。

• ZABBIX サーバ運用の負担
• トリガーの管理が大変
• 通知も改善したい

その後 Mackerel を導入。 JP も US も両方Mackerel。

• サービスメトリックから導入を初めた(手軽なので)
• ZABBIX のトリガーを Mackerel のプラグインに移植

Mackerelで嬉しかったこと。

• 監視ツールの運用がなくなった
• JP と US で監視項目が合わせられた
  • インフラの違いなどによる細かな差異は Ansible template などで吸収

UK では GCP も導入されたが、監視の設定が楽だった。

今はマイクロサービス化を進めている。 Mackerel, Datadog、Stackdriver, Prometheus も使っている。

Mackerel でのサーバ監視例。

色々監視している。

• /etc/passwd の差分監視とか
• レプリケーション用のスレッドの確認とか

「監視は継続的なテスト」 by 奥一穂

感想

Mackerel 以外にもいろんな監視ツールを組み合わせている！

/etc/passwd のさ分監視とかなるほどなあと思った。

マイクロサービスの監視

マイクロサービスの監視についての話。

なんでマイクロサービス化をしているか？

• メルカリはスケーラビリティに関する問題がる
• 100人位エンジニアがいるとコードをいじるときもいろんな調整がいる
• 調整するのは大事なことではあるけど、開発の速さは犠牲になる
• マイクロサービス化で責務を分ければ調整も減って開発スピードもあがる
• そのサービスに合わせたもっとも早いサイズで開発をするためにマイクロサービス化している

Kubernetes を利用している。

マイクロサービスをどうモニタリングするか？

1. データ収集
2. 可視化やアラート
3. アラートがくれば調査して治す

コンテナのログは Stackdriver でやっている。

マイクロサービス化して開発者が自分で監視を組み込むようにしている。具体的には Kubernetes の設定の中に監視設定について追加している。

そうすることによって、 SRE チームと調整せずに監視を開始できる。また、開発者が監視の設定をできるようにインフラを見れるようになっている。

SREの仕事は開発者が色々出来る土台をつくること。

感想

マイクロサービス化の目的はマイクロサービス化することで責務を分散し、サービスごとの裁量で開発できるようになる。それによるスピードの向上。

調整の手間減らしていくのいいな。

Mackerel 自身のモニタリング、監視について

Mackerel 自身のモニタリングはどうしているのかという話。

Mackerel の監視 は Mackerel で行っている。

しかし、 Mackerel が落ちると Mackerel を監視できないので、ステージングの Mackerel で本番環境の Mackerel を監視している。

ステージングの監視は本番のMackerelで監視している。

ほかには Nagios や Pingdom もつかっている。

Mackerelは AWS で動いているので、AWS のリソースの外から監視する意味で Pingdom や Nagions をさくらに立てて使っている。

一部の監視はまだ Mackerel に移せていないものがあり、 Mackerel に移行していくロードマップ。移行したら Nagios はいらなくなる。

Mackerelは NLB を使っているが NLB は ICMP を受け付けていないので tcp で監視している。

Keepalived で Mackerel をアクティブスタンバイ構成にしている。

監視の例。

• tcp 3-way ハンドシェイクのモニタリング
• iptablesの監視
  • トラフィックの管理
  • どこからどこの通信なのかを見たいためにやっている。iptablesのチェインを作ってやっている

感想

Mackerel で Mackerel を監視する話は Mackerel がゲシュタルト崩壊(コンパイラのコンパイルをコンパイラでやる的な…)。

iptable の使い方が面白かった。 3-way ハンドシェイクとか、低レイヤーの監視面白い。

開発者と監視

開発者と監視

開発者がテストを書くのは当たり前になったが、監視はどうかというとまだ微妙。

「監視とはシステムに対する高速健康診断」と言える。「不安な場所を監視する」ことが重要。

• たとえばバッチ時間かかり過ぎとかキューたまり過ぎとかガチャの確率とか

そういう不安に思う場所を監視すると良い。

「監視の口を開ける」

• あるポートにアクセスすると json でシステムの値が返ってくるとか
• ステータスをとってこれるインターフェースが、アプリケーション側に用意されている、用意することが重要
  • h2oに要望出して実装されてる例

感想

監視のための口を空けるというのがなんだか面白かった。なるほど…。

監視は何も考えないでやると意味のない値いくらでも取れてしまうので、まさに「不安な場所を監視する」のは良いなあと思った。

まとめ

名言が色々紹介されていた。

Mackerel のプラグインまた何か作ってみようかな。 🐟