こんにちは。ぐるなびでSREをしている江島です。
普段はコンテナ基盤の運用やサービスの品質向上に向けたSRE活動といった業務を行っています。
9月6日に開催された「Cloud Operator Days Tokyo 2024」で登壇し、「モニタリング品質向上」をテーマに発表を行いました。今回の記事では、その内容を掘り下げ、具体的な方法や実践的なアプローチについて解説していきます。
Cloud Operator Days Tokyo(CODT) とは
「Cloud Operator Days Tokyo (CODT)」は、クラウドシステムの運用者に焦点を当て、日本のオペレーターの底力を高めることを目的とする技術イベントです。 運用の自動化やパブリッククラウドの運用、オブザーバビリティなどクラウドにまつわる様々なテーマでのセッションが行われていました。
モニタリング品質向上の背景
今回は「モニタリング品質向上」というテーマで発表しました。 背景として、ぐるなびでは昨年度からSRE活動に注力を始め、サービスの信頼性の取り組み方について模索していました。 オライリーが出版しているSRE本ではSRE活動の実践として最も基本的であり、土台となる要素はモニタリングであると述べています。システムの規模に関わらず、土台の部分を固めていくことで今後のSRE活動の促進につながると考え、モニタリング品質向上という活動を行ってきました。
ぐるなびのモニタリング構成
ぐるなびではサービスの環境としてオンプレミスとクラウドの2つを利用しています。 それぞれの環境についてモニタリングシステムの構成を紹介します。
オンプレミスのモニタリングシステム構成
オンプレミスではZabbixに各種データを集約してアラートルールを設定しています。
アラートを検知した場合、PagerDutyに連携して通知を行うといった仕組みになります。
特徴
- SREチームがZabbixを管理
- SREチームがモニタリングの項目や閾値を管理
クラウドのモニタリングシステム構成
クラウド環境ではZabbixの部分をNewRelicに置き換えてモニタリングシステムを構築しています。 もともとNewRelicはオブザーバビリティを向上させるために導入していたため、クラウド環境を一元管理するためモニタリングもNewRelicに集約しています。
特徴
- SREチームがNewRelicを管理
- 開発チームがモニタリングの項目や閾値を管理
対象
オンプレミスとクラウド環境の特徴を比較すると、管理者に違いがあります。
オンプレミス環境ではすべてSREがシステムの運用を行っていましたが、クラウド環境では開発チームがモニタリング項目や閾値の管理を行っています。
今回の取り組みでは開発チーム管理のクラウド環境に絞って活動を行いました。
クラウド環境に絞ったのは以下の理由になります。
- オンプレミス環境はSREが長い期間運用しており、ある程度の品質を担保できている
- クラウド環境は開発チームが運用しており、チーム毎に品質の差がある
- クラウドシフトの最中なので、クラウド環境に注力すべきである
先述した理由だと、「クラウド環境のモニタリングもSREチームがやればいいのでは？」という声が聞こえてきそうです。ですが、SREチームの仕事を増やしたくないから開発チームが運用しているのではなく、サービスの信頼性向上のためこういった形で運用しています。
SREチームの前身はインフラ基盤を管理するチームでした。サーバーやDBを開発チームに提供していたため、システム全体の構成を把握できていました。その結果、なにをモニタリングするべきか、閾値はどんな値にするかを決めて運用することができていました。
一方でクラウド環境では、開発チームが自身でシステムの全体構成を構築します。当然システム毎に要件は異なるため、最適なシステム構成も違います。こうなるとSREチームではすべてのシステム構成を正しく把握できません。
どんなモニタリングをすべきかはシステムを理解していないとできません。そのため、一番システムを理解している開発チームがモニタリングの運用をしていくべきだと考え、現在はこのような形で運用しています。
モニタリングの課題
ここからは実際にクラウド環境のモニタリングでどのような課題があったかについてお話していきます。
モニタリング運用のあるべき姿について考え、現状何ができていないかを比較して課題を整理しました。
■ あるべき姿
☑ 開発チームがモニタリングを導入・運用できている
☑ 開発チームに対してモニタリングの品質向上の働きかけができている
■ あるべき姿と比較した課題
☑ 開発チームがモニタリングを導入・運用できている
- NewRelicの理解度に個人差がある
- モニタリングを運用したことがなく、設定項目などがわからない
☑ 開発チームに対してモニタリングの品質向上の働きかけができている
- どのチームが管理しているか・どんなサービスなのかがわからないため開発チームに働きかけできていない
- クローズしても残り続けている設定があり、どれが利用中かわからない
- いつ・どのような変更があったのかわからない
整理した課題を見ていくと、モニタリングに対して開発チームの認知負荷が高いこと、SREチームのNewRelic管理コストが高いことがわかってきました。
取り組み内容
これら課題を解決する手段として、ぐるなびではTerraformの導入を行いました。 Terraformを導入した理由は大きく以下の3つになります。
- モニタリング導入のハードルを下げる
- 保守性の向上
- Githubと併せて運用フローを整備できる
Terraformの導入理由と課題を見比べながら、取り組み内容を見ていきます。
モニタリング導入のハードルを下げる
先述の通り、課題としてモニタリングに対する個人の理解度や運用経験の少なさといった点がありました。
この問題を解決するために、Terraformで設定ファイルのテンプレートを作成しました。
例えばサーバーの監視をする場合は、AとBのメトリクスを取得してCという閾値を超えたらアラートを発報するというテンプレートを作成します。
あくまでテンプレートなので、システムごとにチューニングをする必要はありますが、最初の導入という点ではハードルが下がりました。
保守性の向上
Terraformの導入は開発チームに対する効果だけではなく、SREチームの運用に対しても効果があります。
これまでは開発チームごとに命名規則を決めてモニタリング設定を導入していました。
運用改善のためにNewRelicの命名規則をドキュメントで用意したものの、以前の運用とごちゃまぜになり、必ずしも遵守されていない状態でした。
Terraformを導入してからはテンプレートにチーム名とサービス名を変数として入力することで、自動的に命名規則に沿った名前に設定されます。
これにより、クローズしたサービスに気づける、どのチームに改善を働きかければよいかわかるなどSREチームの運用課題の解決につながりました。
Githubと併せて運用フローを整備できる
Terraformを利用した設定の反映はGithub Actionsを利用しています。
TerraformとGithub Actionsを併せて利用することで、反映前にモニタリング設定をSREチームが必ず確認するというフローを組み込むことができるようになりました。
設定内容に足りない部分がある、不要な設定が入っているといった場合、設定前に開発チームと話すことができます。
Github Actionsを利用したことで、あるべき姿の「開発チームに対してモニタリングの品質向上の働きかけができている」を実現することが可能になりました。
取り組みの成果
モニタリング設定のTerraform化を行ったサービスの一例をもとに取り組みの成果をお話します。
Terraform化する前の状態は以下のような状態でした。
■取り組み前
- モニタリング項目・閾値が適切ではなくアラートが多発している
- 大量のアラートが出ていることで対応が鈍化
- 大事なアラートが埋もれてしまう
SREチームがモニタリングの内容に関与できていなかったため、サービス影響がない項目が入っていたり、一度導入した後のチューニングができていませんでした。結果として重要なアラートに気づけない・対応に遅れるといった事象が起きていました。
Terraform化を行うと同時に開発チームと確認しながらサービス影響があるものだけにアラートを絞ったところ、インシデント数とインシデントの平均確認時間を大きく改善することができました。
■取り組み後
- インシデント数 97.5%減少
- インシデントの平均確認時間 10min → 1min
モニタリングの品質向上は障害の早期発見と早期対応につながり、サービスの信頼性向上となることが実例からも確認することができました。
まとめ
今回はモニタリング品質向上の取り組みについてお話させていただきました。
最後に本記事のまとめです。大きなポイントとしては2つです。
☑モニタリングの品質向上は、サービスの品質向上に直結する
取り組みの成果での記述にもあるように、モニタリングの品質をあげることで障害に対しての対応速度が向上します。さらに余計なアラートが出なくなるので、その分開発に注力することができるようになります。
モニタリングはSRE活動の基礎となります。モニタリングの品質を改善することで信頼性は向上しますし、この部分を固めることで今後の活動の成果が出やすくなると感じています。
☑コード化はノウハウを共有しやすく、一定の水準まで品質を担保できる
コード化はこれまでSREチームが培ってきたスキルや経験をあまりモニタリングに詳しくない開発者も活かすことができます。モニタリングの品質を上げるという取り組みのアプローチ方法は様々あると思うが、コード化は効果的な一つの手段でした。
今後もモニタリングをはじめ様々な取り組みでサービスの信頼性向上に努めて行きたいと思います。
最後まで読んでいただきありがとうございました。
