SREチームのjoooee0000です。
1年前に家族で出かけようとペーパードライバー講習に通い一念発起して車を購入したのですが、運転が下手すぎて家族がもう乗りたくないと言っており、売る流れになっていて悲しいです。
今回は、フルサイクル開発体制を支援する仕組みとして行っている定期システムモニタリングの効果についてお話しようと思います。
前提：バックエンドチームの開発体制について
私たちのバックエンドチームは フルサイクル開発体制 をとっています。
開発者自身が設計から運用まで一気通貫で責任を持つ体制です。
そのうえで、専門性をもつEnabling SREチームが横断的にシステム運用をサポートしています。
Enabling SREは日々の開発や運用に直接入るのではなく、チームごとの運用定例などを通して課題の発見や改善の後押しを行い、開発者がより安心してサービスを育てられる環境を支えています。
余談ですが、この間開催されたSRE NEXTで、開発者がシステムの運用に責任を持てるよう支援しているチームが多いことを実感しました。そのようなチーム運用を行っている方の参考になれば幸いです！
定期のシステムモニタリングについて
すでに触れましたが、私たちのチームはEnabling SREチームが主導してフルサイクル開発体制を支える様々な取り組みを行っています。
その中でも、特に効果を実感できた取り組みのうちの一つがチームで行う定期システムモニタリングです。週1でチームでダッシュボードを見て、システムの状況を把握する取り組みです。
今までも、そのような機会をチームで設けることはSREのプラクティスとして聞いたことがありましたが、実施する前は下記のような不安がありました。
- 開発者にこの時間を意味のある時間として捉えてもらえるか
- SREチームのメンバーの一方的な会にならないか
- 毎回同じことの繰り返しになり、形骸化しないか
しかし、実際に実施してみるとメリットがとても多いことを体感することができました。
そこで、どのように定期のシステムモニタリングを実施しているかや、得られた効果、実際の開発者の声などを紹介していきます。
どのように実施しているか
実際には、Enabling SREとフルサイクル開発チームが合同で行う運用定例という週1、30分間の定例の中でシステムモニタリングを実施しています。運用定例の目的は下記のようなものがあります。
- 運用課題の発見と改善サイクル促進
- SREの開発メンバーへの支援機会
アジェンダはチームごとにカスタマイズされていますが、概ねこのような感じです。
- 前回のTODOチェック
- 運用課題 / 依頼の共有
- ProductionReadinessCheckの確認
- システムモニタリング
- クラウドインフラ周りのメトリクスダッシュボードの先週との比較
- APM
(ProductionReadinessCheckの確認についてはこちらのブログで言及しています！)
司会進行はEnablingSREではなく開発チームのメンバーが行います。
リーダーが行うチームもあれば、ローテーションで行っているチームもあります。
得られた効果について
実際に定期のシステムモニタリングを通してSRE / 開発者が実感した効果を紹介します。
1. システムメトリクスの知見が得られる
毎週ダッシュボードをみて振り返りをすることで、「この数値は何を意味しているのか？」を通して重要指標の知見を得ることができました。また、一人で眺めるのと違い、すぐにメトリクスの意味を把握することができることも良いポイントです。
チームによってはローテーションでモニタリングツールを操作しながら定例を行うので、いろんなメンバーがハンズオンでモニタリングツールの利用方法を習得することもできています。
その結果、CloudWatchメトリクスやAPM（Application Performance Monitoring）の指標をより深く掘り下げることができるようになったと、定例に参加している9割の開発メンバーが実感してくれていました。
📣 開発者の声
特にCloudWatchのダッシュボードの見方に関して理解度が高まりました
2. 関わるシステムのリクエスト傾向や特性の知見が得られる
モニタリングを通じて、
- トラフィックのピーク時間帯
- 依存関係のあるサービス
- システム上の課題
といったポイントを効率的に把握できています。
トラフィックのピーク時間帯や依存関係の把握などは、システム運用において大事な視点になります。
また「リクエスト数がなぜ急に増えているのか（新機能リリースによる影響など）」といった背景も議論できるため、SREとして開発チームの動き方の理解が深まりました。
最近ドメイン知識のないシステムの運用定例に参加を始めた事がありましたが、システムについてのナレッジ共有によりサービス特性を短期間でキャッチアップすることができました。
チーム全体で知見を共有し、属人化を防げているという実感も持つことができています。
📣 開発者の声
このような場がないとSentryアラート棚卸しやパフォーマンスを定点観測して変化をキャッチアップすることを忘れたり特定の人に偏るので、短い時間でもメンバーで見る場がある状態は良いのではと思っています
3. 開発の成果を“運用の視点”からフィードバックできる
新しい開発や改善がどのようにシステムに影響を与えるかを、運用の観点からのフィードバックが得られやすくなりました。例えば、N+1問題が与えるレスポンス速度への影響や、無駄なリクエストがどれくらいインフラコストを消費してしまうか、などです。
さらに、その気づきをチーム内で共有することで、知見が広がり再現性のある改善サイクルが生まれています。
(弊社のルールでslack名に本名がのっているので伏せています)
4. 見過ごされがちな“じわじわ効いてくる問題”に気づける
アラートになるほどではないけれど、放置するとシステムに確実にダメージを与えるような問題に気づくことができるようになりました。このような問題は、時間が経ってから調査すると膨大な時間がかかることがあります。
まるでボディブローのように効いてくるこの種の問題を、定例での観察を通して早期に発見できるようになりました。
直近の事例だと、無駄なリクエストを減らしてコンテナのコスト削減やDBのインスタンス台数の削減につながった事例がありました。
📣 開発者の声
即時性、緊急性はないがシステムの健康状態としてネガティブな状況を検知した時、これまでは放置されがちだったのが以前に比べてアクションされる頻度は増えたのではないかと思い、これは良い動きだなと思います。
開発者に取った実際のアンケート結果
実際にどのようなメリットを感じたか、開発者アンケートを取りました。
結果はこんな感じでした！
1位 メトリクスやAPMのみかたの知見を得られた (88.9%)
1位 関わるシステムのリクエスト傾向や特性がわかった (ピークタイムや平日/土日の違いなど) (88.9.%)
3位 開発リリースしたものがシステムにどう影響を与えているのかフィードバックが得られた(N+1問題やリクエスト増、レスポンスタイムの悪化など) (77.8%)
4位 システム構成の理解が深まった (66.7%)
5位 ナレッジの属人化を防げた (55.6%)
5位 システムモニタリングがなければ気付けなかった課題に気づくことができた (55.6%)
他にも…
最近システムメンテナンスでRDSのエンジンバージョンと、AuroraServerlessのプラットフォームバージョンのアップグレードを行いました。
メンテナンスに参加したメンバーだけでなく、その効果の振り返りなどもチーム全員で共有することができ、みんなで盛り上がりました。
効果が実感できるとチームの士気も高まります！
まとめ
今回は定期のシステムモニタリングの実践方法と効果や開発者の声を紹介しました。
まだ実践したことがない、同じことにトライしようとしているが踏ん切りがつかないという方の参考になれば幸いです！
Discussion