2017年10月30日(月)に行われたGeeks Who Drink in福岡 モニタリング勉強会edition でヌーラボの松浦が発表した、「Backlogの運用監視」の資料です。
Backlog の運用監視松浦 祐亮 ‒ Nulab Inc.Geeks Who Drink in Fukuokaモニタリング勉強会 Edition
View Slide
自己紹介‒ Yusuke Matsuura @matsuzj ‒ Nulab Inc.‒ Site Reliability Engineer @Backlog‒ 趣味は登山・キャンプ‒ Job‒ Web サービスの開発/運用を始めて11年ぐらい経ちます‒ アプリケーションエンジニアからインフラ方面へ‒ 現在は運用・改善・トラブルシュート等‒ Team‒ 2015年7月から Nulab のインフラ担当としてジョイン‒ 2016年9月から SRE チームを2名で発足‒ 2017年8月から SREメンバーが追加されて3名体制へ
話す内容1. Backlog の歴史と経緯2. Backlog の運用と監視の概要3. 運用監視内容と改善サイクルについて4. 今後改善したいこと
1. Backlog の歴史と経緯
有料契約数の推移2006年に Backlog の正式版をリリースして11年経過2017年4月時点で利用契約数は50,000そのうち有料契約数は5,000無料契約数は45,000もう少しで有料契約数が6,000
増える運用環境2011年からAWSへ移行3環境で開始2013年に4環境2015年に5環境2017年に7環境現在のサーバ数は200台弱まで増えた
11年もやってるとレガシーなシステムになって運用も大変なんじゃない？
改善内容 ‒ 開発・UI変更・Nulab Apps 連携（認証機能強化）・クレジットカード決済対応・Jenkins にてCI/CDを実施しておりだいたい2週間に一回はアプリケーションがデプロイされています・機能単位で Play / Scala へ移行中
改善内容 ‒ 運用・Infrastructure as Code の実施（Terraform, Ansible,Serverspec, awspec）・運用環境をより安定性の高いものへ移行（EC2, ALB , RDS for Aurora,ElasticCash, VPC）・ミドルウェアの改善・開発（Proxyサーバ設置, Git SSH サーバの更新、画像配信方法の変更）
長くBacklog を使っていただけるようにメンバー全員で常に改善を実施しています
前置きが長くなりましたが運用と監視について説明していきます
2. Backlog の運用と監視概要
監視概要仮想マシン ( AWS 提供 )外部ホストOSミドルウェアアプリケーションCloudwatchmackerelサービス ( Backlog )nagiosServerspecawspecFluentd
Nagiosユーザーの操作に近いところを監視しています・アプリケーションの外形監視・Git にログインできるか・WebDAV にログインできるか・SSL 証明書の有効期限は過ぎていないか・RDS のAレコードのチェック（フェイルオーバーの検知）
Mackerelホスト単位の監視はすべて Mackerel (mon)で実施・2014年からMackerelを使用・Role単位でグラフがみれるため傾向分析がしやすい・インスタンスのスケールアップした後傾向分析しやすい・さっとプラグインを作成できるのがお気に入り
Mackerelグラフサンプル
Fluentd・アプリケーションログをパースして通知したい場合等に利用・すべての環境の MySQL スローログを集約し、毎日 pt‒query‒digest で傾向分析する
Serverspecサーバの構成をテスト・変更点がレポジトリに push された場合に Jenkins にてテストを実施・日に3回 Jenkins によるテストを実施・ミドルウェアやアプリケーションの設定値が正しいか・ディスクのマウント先が正しいか・必要なデーモンが起動しているか・サーバプロビジョニングが正しく行われたか・Serverspec が通ってから Mackerel を起動します
awspecAWSリソースの設定をテスト・RDSの構成チェックやパラメータグループの設定・EIPが正しいインスタンスにアタッチされているか・EBSが正しいインスタンスにアタッチされているか・永続化層は Terraform では作成しないためテストを書いている
監視まとめ・Mackerel だけ監視することはできるが、冗長化のためNagios は残しています・無駄に見えるところもあるが多重でチェックをかけるようにしている・複雑になっても気づかないよりはましなので監視項目を増やしたが少し煩雑になってきている・マネージドのサービスを使っていないインスタンスはいつでも入替えられるように構成管理のテストを充実させています・通知のチャネルは Typetalk 使ってます
3. 運用監視内容と改善サイクルについて
改善内容日々の運用状況をみて発生ベースで対応しています・アプリケーションの負荷状況をみてアプリケーションサーバを増やす・DBサーバの負荷状況に応じてスケールアップする・アプリケーションのデプロイに問題があれば状況をみてロールバックを実施、原因がわかっていればサーバの数を増やす、スケールアップをして次のリリースまで運用することもある( リリース予定は Google Calendar に記載 )・わりとフレキシブルに構成変更をしています
監視内容を改善するタイミングTopic for NagiosTopic for CI/CDTopic for Mackerelサーバの状況が変わるアクションは随時Typetalkで監視し検知するようにしている 日々の運用監視の兆候をチェックし状況に応じて、サーバを操作したり、監視項目を追加しているNulaberTopic for DEV Nulabers‑ SRE/DEV
4. まとめ・今後改善したいこと
問題点今回改めて本を読みましたMackerel を生かしきれてない箇所がめだった・Ansible での Role が細分化されていない箇所があるため、そのまま監視項目が反映されている・独自プラグインを書いているものも多いので公式によせていく
まとめ・今後改善したいこと・監視内容は日々の積み重ね・定期的な監視項目の見直しが足りていない・不要なものは削除する・ホストが日々増えていくが、削減に対する意識が足りなかった・増えた go‒check‒plugins をチェックする・mkr で Mackerel 監視項目のコード化・マルチロールによる運用に変更・通知先の統一（PagerDuty導入）
インフラエンジニア募集https://nulab‑inc.com/ja/about/careers/
nulabinc
ciniml
kojira
fujiwara3
oracle4engineer
microcms
htsuruo
takemikami
leekwangsoo1995
techtekt
sakiengineer
vividtone
ohmori_yusuke
lara
bermonpainter
danielanewman
notwaldorf
erikaheidi
jmmastey
zakiwarfel
62gerente
bluesmoon
marktimemedia
kneath
tammielis