グリー開発本部 Meetup #3 モニタリングに参加してきました #GDMeetup

概要

そーだいさんのPHPerのためのWebサービスのモニタリングの話を聴いて以来、モニタリングに注力していました。今回は「入門監視」という素晴らしい本と、それに伴うイベントがあるということで参加してきました。

入門監視にさらっと書いてある、自動復旧の話を掘り下げる
自前の配信基盤Yururaで、複数のアラート（クリティカル、ワーミング、チケット）を投げ分けている
アラートの傾向を分析して、自動復旧へアプローチしていった
- アラートの多くが、コマンド一発 or 数発で解決することがわかった
AWS System Managerで自動復旧させる
- チャットの実行ログは残す
- 最初は人間が確認していて、問題ないことを確認して、自動化した
- アラートレポートで、アラートを可視化している
AWS環境なら、AWS System ManagerとかAWS Lambdaで大体できる

自前でアラート配信基盤を作っているのは、強いの一言です。自分は「複数のアラートを投げ分けたいと思いつつ、そこまで工数がかからないといいな…」と思いましたｗ

自動復旧に向かう前に、人間が介入するフェーズがあるのが良いですね。補助輪を外すフェーズは、人間相手でも機械相手でも必要。

入門監視の内容について、トーク&補足という感じでした。入門監視を全部読めていないですが、なんとかついていけてよかったです。

自分的には、モニタリングが属人化してしまっているので、なんとか改善せねばと思いました。

エモすぎる話
モニタリング環境を自前で用意した
- アクセスログから、社内のヘビーユーザを割り出し、ヒアリングした
- gangliaを選定した
  - pythonでmoduleを追加できる
  - 拡張性が高そうだった
  - フロントエンドは自分で書いた
- 数千台、数千メトリクスを取得している
  - 全ては見ることは不可能なので、重要な部分以外は後から書き出すようにした
サーバを減らす際は、減らしすぎないことに注意する
- サーバを減らして障害になったらいけない
  - とはいえ、減らす事でコストダウンをしたい
- サーバを減らす基準は、組織内で決めておくと良い
今はSaaSでやった方が良い
- 10年前はSaaSのコストが高かった
- 今はコストダウンしている
  - ちなみに、SaaSの4分の1で運用できるので、Greeではgangliaを使っていく
モニタリングは学びのチャンス
環境、OS、ミドルウェアの変化を見逃さないようにしよう

低レイヤーを知っているエンジニアの強さを感じる。 MySQLのメトリクスだけで3桁の項目を観ているとか、すごすぎて言葉も出ない。

低レイヤーの知識は、10年経っても生きてくると思うので、自分も学ばねばと感じました。

入門監視の松浦さん（doublemarket(@dblmkt)さん | Twitter）による、監視の話もグリーの監視事情も面白かったです。

グリーさんは、監視に結構力を入れていて、自分たちとの差を感じました。自分たちも「アラートの分析をせねば」と感じ入る次第です。

スピーカーの方々、運営のグリーの方々、ありがとうございました！