こんにちは。Cloud Automator、SREチームの尾崎です。
いよいよ冬が近づいてきましたね。
この記事では以前の「New Relic実践入門 監視からオブザーバビリティへの変革 書評 -後編-」
の中で触れた、Cloud AutomatorのSREチームについて、SREチームが出来た背景と日々の取り組みを紹介したいと思います。
Cloud Automatorとは
はじめに、Cloud Automatorを簡単に紹介します。
Cloud Automatorは弊社サーバーワークスが提供している、AWS運用自動化サービスです。EC2の定時停止や定時起動といったことはもちろん、RDSやWorkSpacesといったAWSリソースの運用を自動化することが出来ます。
例えば、業務終了後にEC2インスタンスを自動停止したり、業務開始前にEC2インスタンスを自動起動させるといった設定をWeb上で簡単に設定することが出来ます。
詳しくはサービスサイトをご覧ください。
私はそのCloud Automatorの開発しつつ、Cloud AutomatorのSREチームの一員としてサービスの信頼性を向上させるべく日々業務を行っております。
SREチームが発足した背景
Cloud AutomatorのSREチームは2021年の3月に発足した新しいチームです。それ以前は開発メンバーが開発業務の合間にインフラのメンテナンスといった運用業務を行ってきました。リリース前のQA(ステージング)環境のメトリクスについても、開発者が気づいたときに気づいた人が確認するという状態になっていました。
そんな中、2021年の3月にCloud Automatorで障害が発生してしまいます。その障害は事前にQA環境のメトリクスをきちんと確認さえしていれば未然に防ぐことが出来ましたが、上記のようにきちんとした運用・確認体制が出来ておらず、それが結果として障害につながってしまいました。
開発チーム内で障害の原因を分析した結果、根本原因は次の通りであると判断しました。
- リリース前のQAに設定している監視設定が昔に設定されたものであり、その監視設定のしきい値が現在のQA環境向けのしきい値として妥当ではなかった。
- そもそもメトリクスを定期的に確認する仕組みが無く、しきい値の妥当性を見直す機会もほとんど無かった。
- 監視設定やインフラ周りは開発者各人がベストエフォートで対応してきた結果、責任を持つ人(チーム)が存在しておらず、監視設定やインフラを継続的にメンテナンス出来ているとは言えない状態になっていた。
これを受けてCloud Automatorのサービス障害を未然に防ぐため、監視設定やインフラの整備についての責任を負うSREチームを発足させました。
発足にあたっては「安定したCloud Automatorのサービス提供に必要な業務をチームとして取り組み、運用業務の属人化・断片化を防ぐとともに、発展性のある運用業務の仕組みづくりを行う」とチームの目的を明文化しました。
明文化することでSREチームの存在目的を明確にさせ、SREチームが発足するきっかけとなったような障害を二度と発生させないようにするためです。
SREチームのこれまでの取り組み
SREチームが発足してまずやったことは、本番環境を含めた全環境向けの取得していたメトリクスの精査、監視設定の見直しです。
これらの改善に注力するため、定期的なリリースサイクルを一度ストップすることとしました。
もともとの出発点がQA環境の監視設定の不十分さだったので、最優先課題でしたし、そもそも監視設定が出来ていないと障害を未然に防ぐだけでなく障害を検知することも出来ないため、SREチーム一丸となって対応しました。
さらに、それまで十分に出来ていなかった負荷試験もQA環境に導入しました。
メトリクスの精査、監視設定の見直しを行い、負荷試験も導入し、障害からストップしていたリリースを再開できるようになりました。再開まで約1ヶ月かかりましたが、この期間で行った対応は今もサービスの安定提供に大きく寄与しています。
その他にもコンピューティングリソース最適化やCloud Automatorのリリースフロー改善といった、これまでなかなか手が付けられなかった部分も、SREチーム発信で内部的な開発ロードマップに乗せてもらい取り組んできました。
また、SREとしてメトリクスの確認や監視設定だけではなく、SLO・SLIの策定と設定もおこない、SLO・SLIに基づいた判断やSLOを満たすためにインフラの増強もしたりしています。
SREチームでは毎週定例を設け、メトリクスやアラートの確認を継続的に行っています。
そこで確認しているダッシュボードは毎週のSREチーム週次定例で確認しているダッシュボードは、アラートに設定しているしきい値を表示することで、しきい値の妥当性も確認しています。
ダッシュボードはアラートに設定されているしきい値と同期するように、1つの定義ファイルからアラート設定とダッシュボードを生成するようにして、ダッシュボードで見ている値がアラートのしきい値となるように工夫しています。
Cloud AutomatorのSREチームのこれまでとこれから
Cloud AutomatorのSREチームが発足してから半年以上が経ちました。
当初、チーム体制を取ることに対してそこまで深く考えていませんでしたが、チーム体制として本当に良かったと感じています。
現在は3名のチームで、チームとして気軽にディスカッションが出来ること、なにかあったときに責任がある者同士、協力体制が組みやすいということに大きなメリットを感じています。
ちなみに、立ち上がったばかりの頃はSRE業務が各メンバーの日々の業務の大半を占めていましたが、最近では以前のようにサービス開発業務の占める割合も増えてきています。
しかしこの半年間で、ユーザーはCloud Automatorが安定して提供されることを当然と思っている(有料サービスですしもっともです)、そして我々がサービスを安定して提供するためには地道な運用業務が必要不可欠である、ということを学びました。
Cloud Automatorというサービスがある限り運用業務に終わりが来ることはありません。
今のSREチームは全員がソフトウェアエンジニア出身なため、これまで以上にコード等による自動化を取り入れたりして効率よくトイルを撲滅しつつ、SRE業務と開発業務を両立させていければなと考えています。
そしてその取り組みが、障害の未然防止につながり、なおかつ障害が発生してもいちはやく復旧できる仕組み作りにつながると考えています。
