freee での SLO の実践について

Enabling SRE チームの oracle です。チーム内で SLO の推進を担当しております。 freee での SLO の実践についてご紹介させて頂きます。

改めてSREとは

皆さんご存知のように SRE とは Google 社が実践してきたシステム運用のノウハウを書籍化したことで一般的に知られるようになった言葉です。日本語版の書籍が発売されてからもう5年経ちました。 Google が提唱しているアプローチを皆さんは実践できていますでしょうか。

freee では SRE チームの前身はインフラという部署でした。同じように部署を新設ではなくて名前を変更した企業も多いのではないでしょうか。チームの名称は何であれ問題はありません。重要なのは SRE を実践しているのか、していないかです。freee は SRE を実践できていたかというとそうではありませんでした。

信頼性とは

SRE の実践とはそもそもなんでしょうか。信頼性(reliability)の維持です。なぜ信頼性が重要であるかですが、一度限りの取引ですと、需要と供給がその瞬間釣り合っていれば良いですが、特にWEBサービスのような多くのユーザに長期に渡ってサービスを提供し続けるビジネスモデルでは、ユーザに満足して頂くこと、問題なくサービスを使って頂くこと、長期に渡ってそれができていればユーザからの信頼を勝ち取れるようになります。ユーザーからの信頼があればさらに長期に渡ってサービスを利用してもらえるようになります。それがビジネスの成功に繋がると言っても過言ではありません。

理屈としてはとても簡単なことですが、ユーザに満足して頂くこと、問題なくサービスを使って頂くこと、長期間に渡ってとなると簡単ではありません。

信頼性の維持は重要だけれども、その命題の中で点を線にすることは組織や文化の変化も必要と思われる部分があるために難しさがあると思っています。

信頼性の維持を中心に据える

という考え方をした時に理解がクリアになったような気がします。

中心があるということはその周りがあるということになります。その周りとは、プロダクトの開発を担当する方、運用を担当をする方、その他も含めて関わる多くの方です。ビジネスの成功に繋がるサービスの信頼性の維持は関わるすべての方が一様にその責務を負うべきです。

そして一層意識する必要がある時代になって来ていると思います。なぜならば、昔と違ってプロダクトに対して大きなの変化のインパクトを抑えるために小さな変更を常に加え続けるようなトレンドになって来ていますし、分散システムを前提としたアーキテクチャとなってきているため、個々のノードの変化も絶えず生じています。そのためコンスタントに変化する中で従来の安定性思考の運用では信頼性の維持はとても難しいです。

そういったトレンドの中で信頼性の維持には、従来の運用チームが変化を受け入れる事、そして従来の開発チームが安定性を受け入れることの2つの視点が必要となります。これが class SRE implements DevOps ということだと思います。

https://www.youtube.com/watch?v=uTEL8Ff1Zvk#t=5m03s

SLOについて

ビジネスの成功の鍵である信頼性の維持を行うのが SRE の責務です。そして、その責務を実現するためは、組織の中にDevOpsの両方の性質を持つこと、あるいは、DevチームとOpsチームの協業により成立させることが必要です。加えて信頼性を定量的に評価するためには、期間を定め、定期的な見直しをすることで信頼性スタックの維持を図ることも求められます。信頼性スタックとは、サービスレベル目標(SLO)とサービスレベル指標(SLI)とエラーバジェットという3つの要素のことを指します。重要な観点としては、信頼性スタックを用いてシステム的に完璧な状態を目指すのではなく、実現可能性を考慮して、適切な猶予を設けて運用することがポイントとなります。

freee での SLO の実践

SLO が信頼性を維持するための手法であるならば、それを行っていないとなると SRE を実践しているとは言えないかもしれません。以前の freee では SLO はありませんでした。

前置きがとても長くなりましたが、無いところからどうやって SLO を実践していったのかをご紹介したいと思います。

複雑さの認識

それまでは横断的に SRE チームが各プロダクトを運用をしていましたが、分散化されたシステムと増えていくプロダクトの中でシステムのアラートが上がるとこれはどれだけの影響なのか判断しづらくなっていました。どの状態が正常なのかを明確にしていく必要がありました。その中でやはり SLO を取り入れることでそれがクリアになると期待して取り組み始めました。

SLO の理解

Enabling SRE チーム内でまずは SLO について少人数で先行して理解や習得をはじめました。 The Art of SLOs のワークショップを少人数で開催してお互いの理解の共有をしました。また参考書籍としてはImplementing Service Level Objectives と SRE 本の後続本である The Site Reliability Workbook を読みました。

https://www.amazon.co.jp/Implementing-Service-Level-Objectives-Practical/dp/1492076813 https://www.amazon.co.jp/Site-Reliability-Workbook-Practical-Implement/dp/1492029505

あとオンライン学習として coursera コースの習得を行いました。 www.coursera.org

先行した少人数で Enabling SRE チーム内でワークショップを簡易化したものを作成して共有を行いました。

プロダクトチームとコラボーレーション

Enabling SRE チーム内である程度理解が進んだところで、プロダクトチームとコラボーレーションして進めることにしました。

ただ、現在のfreeeは開発組織も大きく複雑になっており、大々的に開始するのは困難な状況なため、Googleのベストプラクティクスに従い、まずはプロトタイプとなるプロダクトを選定して協力いただくことでスモールスタートさせました。SLOのプレ導入にあたってはどうしても試行錯誤を重ねる必要がありました。隔週での進捗会やSNSツールを用いた非同期のコミュニケーションを通じて、リモートワーク環境下でも円滑に進めることができました。

SLO の策定

プロトタイプとなって頂いたプロダクトチームである人事労務チームではドメインごとに更にチームが別れています。各ドメインのチームで SLO を策定する担当者を立てて頂きました。そしてドメインごとに主要な機能を一つ選定し、SLO を作ってみました。

Art of SLOs のワークショップの中でカスタマーユーザージャーニーを一つの単位としその中でも重要な部分を SLO とするチュートリアルとなっているのでそれに習いました。

freee ではモニターリングツールとして datadog を利用しています。アプリケーションの log も datadog に統合しているため、SLI になりうるメトリクスを作るのは難しくありませんでした。精度は常に改善の余地がありますが、最初のお試しの段階では比較的にやりやすいものでした。アプリケーションログに記載されている status code や response 時間をフィルターして、error rate や latency のメトリクスを作成しそれを SLO の SLI としました。

SLO の改善

当初は基準値がどの辺りにすべきかが分かっていませんでしたので、ひとまずは 92%くらいに設定して様子を見ました。しばらく期間を置いて確認してみると、設定した SLO が満たされていないものもありました。

SLO の考え方として100% を目指すことが目的ではなく、90% でもユーザが不満を感じていなければそれで良しというものです。 90%を割っている状態が良いものか、それとも取るべき SLI がおかしかったのかを含めて、プロダクトチームで調査や確認などを行いました。

小さいイテレーションを回しながら、プロダクトチームのそれぞれのドメイン担当の方が SLO についてなれてきた状態で、さらに別の機能の SLO を作成するようになりました。

さらなる改善

ドメイン毎にさらに SLO を策定した後は slo-decision-matrix のマトリクスに従って、SLO の精度を高めていくようにしています。初期は開発者主導で設定していますが、本当にユーザの信頼性を図れているかなどは PM や CS とも相談する流れになろうとしています。

これから

SLO の中で重要な部分は実はエラーバジェットだと考えております。エラーバジェットというのは許容できる不具合となりますが、もう一つの性質としては、信頼性維持のためのトリガーとなります。現在のフェーズはまだカバーすべき SLO とその適切さを探る段階ではありますが、エラーバジェットが超過した時に SLO の回復に務めなければ信頼性の維持はできません。そのためにエラーバジェットポリシーの策定がこの後のフェーズになります。

そして、Enabling SRE チームとしてはその他のプロダクトチームにも SLO の横展開を行っていく予定です。