Backlog の運用監視 / Operational Monitoring of Backlog

by 株式会社ヌーラボ

Slide 1

Slide 1 text

Backlog の運用監視松浦祐亮 ‒ Nulab Inc. Geeks Who Drink in Fukuoka モニタリング勉強会 Edition

Slide 2

Slide 2 text

自己紹介 ‒ Yusuke Matsuura @matsuzj ‒ Nulab Inc. ‒ Site Reliability Engineer @Backlog ‒ 趣味は登山・キャンプ ‒ Job ‒ Web サービスの開発/運用を始めて11年ぐらい経ちます ‒ アプリケーションエンジニアからインフラ方面へ ‒ 現在は運用・改善・トラブルシュート等 ‒ Team ‒ 2015年7月から Nulab のインフラ担当としてジョイン ‒ 2016年9月から SRE チームを2名で発足 ‒ 2017年8月から SREメンバーが追加されて3名体制へ

Slide 3

Slide 3 text

話す内容 1. Backlog の歴史と経緯 2. Backlog の運用と監視の概要 3. 運用監視内容と改善サイクルについて 4. 今後改善したいこと

Slide 4

Slide 4 text

1. Backlog の歴史と経緯

Slide 5

Slide 5 text

有料契約数の推移 2006年に Backlog の正式版をリリースして11年経過 2017年4月時点で利用契約数は50,000 そのうち有料契約数は5,000 無料契約数は45,000 もう少しで有料契約数が6,000

Slide 6

Slide 6 text

増える運用環境 2011年からAWSへ移行3環境で開始 2013年に4環境 2015年に5環境 2017年に7環境現在のサーバ数は200台弱まで増えた

Slide 7

Slide 7 text

11年もやってるとレガシーなシステムになって運用も大変なんじゃない？

Slide 8

Slide 8 text

改善内容 ‒ 開発・UI変更・Nulab Apps 連携（認証機能強化）・クレジットカード決済対応・Jenkins にてCI/CDを実施しておりだいたい2週間に一回はアプリケーションがデプロイされています・機能単位で Play / Scala へ移行中

Slide 9

Slide 9 text

改善内容 ‒ 運用・Infrastructure as Code の実施（Terraform, Ansible, Serverspec, awspec）・運用環境をより安定性の高いものへ移行（EC2, ALB , RDS for Aurora, ElasticCash, VPC）・ミドルウェアの改善・開発（Proxy サーバ設置, Git SSH サーバの更新、画像配信方法の変更）

Slide 10

Slide 10 text

長くBacklog を使っていただけるようにメンバー全員で常に改善を実施しています

Slide 11

Slide 11 text

前置きが長くなりましたが運用と監視について説明していきます

Slide 12

Slide 12 text

2. Backlog の運用と監視概要

Slide 13

Slide 13 text

監視概要仮想マシン ( AWS 提供 ) 外部ホスト OS ミドルウェアアプリケーション Cloudwatch mackerel サービス ( Backlog ) nagios Serverspec awspec Fluentd

Slide 14

Slide 14 text

Nagios ユーザーの操作に近いところを監視しています・アプリケーションの外形監視・Git にログインできるか・WebDAV にログインできるか・SSL 証明書の有効期限は過ぎていないか・RDS のAレコードのチェック（フェイルオーバーの検知）

Slide 15

Slide 15 text

Mackerel ホスト単位の監視はすべて Mackerel (mon)で実施・2014年からMackerelを使用・Role単位でグラフがみれるため傾向分析がしやすい・インスタンスのスケールアップした後傾向分析しやすい・さっとプラグインを作成できるのがお気に入り

Slide 16

Slide 16 text

Mackerelグラフサンプル

Slide 17

Slide 17 text

Fluentd ・アプリケーションログをパースして通知したい場合等に利用・すべての環境の MySQL スローログを集約し、毎日 pt‒ query‒digest で傾向分析する

Slide 18

Slide 18 text

Serverspec サーバの構成をテスト・変更点がレポジトリに push された場合に Jenkins にてテストを実施・日に3回 Jenkins によるテストを実施・ミドルウェアやアプリケーションの設定値が正しいか・ディスクのマウント先が正しいか・必要なデーモンが起動しているか・サーバプロビジョニングが正しく行われたか・Serverspec が通ってから Mackerel を起動します

Slide 19

Slide 19 text

awspec AWSリソースの設定をテスト・RDSの構成チェックやパラメータグループの設定・EIPが正しいインスタンスにアタッチされているか・EBSが正しいインスタンスにアタッチされているか・永続化層は Terraform では作成しないためテストを書いている

Slide 20

Slide 20 text

監視まとめ・Mackerel だけ監視することはできるが、冗長化のため Nagios は残しています・無駄に見えるところもあるが多重でチェックをかけるようにしている・複雑になっても気づかないよりはましなので監視項目を増やしたが少し煩雑になってきている・マネージドのサービスを使っていないインスタンスはいつでも入替えられるように構成管理のテストを充実させています・通知のチャネルは Typetalk 使ってます

Slide 21

Slide 21 text

3. 運用監視内容と改善サイクルについて

Slide 22

Slide 22 text

改善内容日々の運用状況をみて発生ベースで対応しています・アプリケーションの負荷状況をみてアプリケーションサーバを増やす・DBサーバの負荷状況に応じてスケールアップする・アプリケーションのデプロイに問題があれば状況をみてロールバックを実施、原因がわかっていればサーバの数を増やす、スケールアップをして次のリリースまで運用することもある( リリース予定は Google Calendar に記載 ) ・わりとフレキシブルに構成変更をしています

Slide 23

Slide 23 text

監視内容を改善するタイミング Topic for Nagios Topic for CI/CD Topic for Mackerel サーバの状況が変わるアクションは随時Typetalkで監視し検知するようにしている日々の運用監視の兆候をチェックし状況に応じて、サーバを操作したり、監視項目を追加している Nulaber Topic for DEV Nulabers ‑ SRE/DEV

Slide 24

Slide 24 text

4. まとめ・今後改善したいこと

Slide 25

Slide 25 text

問題点今回改めて本を読みました Mackerel を生かしきれてない箇所がめだった・Ansible での Role が細分化されていない箇所があるため、そのまま監視項目が反映されている・独自プラグインを書いているものも多いので公式によせていく

Slide 26

Slide 26 text

まとめ・今後改善したいこと・監視内容は日々の積み重ね・定期的な監視項目の見直しが足りていない・不要なものは削除する・ホストが日々増えていくが、削減に対する意識が足りなかった・増えた go‒check‒plugins をチェックする・mkr で Mackerel 監視項目のコード化・マルチロールによる運用に変更・通知先の統一（PagerDuty導入）