皆さんこんにちは。
マッチングアプリ、タップル誕生でSREをしている袴田です。
本日は『タップルにおけるSLOの取り組み』と題して、弊社SREがどのようにSLOを運用しているか説明します。
システム品質の目標値であるSLO
SLOを一言で言えば、システム品質の目標値です。
e-wordsによるSLOの定義は以下の通りでした。
提供するサービスやサービスを構成するシステムや機材などに関して、性能や可用性、データ管理、運用体制、サポート体制、セキュリティなどの目標水準や目標値を設定し、利用者に提示する。
参考:http://sp.e-words.jp/w/SLO.html
SLOを利用して期待値をコントロールする
SLOを利用することで、システム提供者と利用者間の期待値をコントロールできます。システム利用者からすれば、不具合ゼロのシステムを期待しますが、そのようなシステムは存在しません。システム提供者が許容できる不具合の程度を加味してシステム品質をSLOとして設定することで、システム提供者と利用者間の期待値を擦り合わせることが出来ます。
とりあえず運用してみた
弊社では、システム利用者であるユーザにSLOを公表することで、サービスの信頼性をアピールすることを念頭に、まずはお試しのSLOを作ることにしました。まずは、レイテンシ、エラーレート、稼働率にて計測開始して、一旦仮の目標値を設定して運用開始しました。SLO設定後はバックエンドエンジニア内でのみ一定期間運用することで、ある程度のSLO運用の温度感を掴むことにしました。しかし、結局毎回SLOの進捗を共有するのみで、改善アクションはほぼ生まれず、SLOが宙に浮いているような存在になってしまいました。
SLOは一夜にして成らず
SLOが宙に浮いてしまった存在になった理由は、緩めの目標値にしすぎていたためでした。障害が発生しようが毎月のSLOは超過達成で、特にSLO起因での改善アクションは生まれず、SLOが今後ワークするイメージがつかめませんでした。では、レイテンシやエラーレートにおいて厳しめの目標値を立てれば良いかというと、それらの改善タスクを優先度高く実行するイメージも湧きませんでした。例えば、サーバのレイテンシSLOを平均100msにしたとして、レイテンシが50msから100msに悪化したとして、この50msの違いをユーザは感じづらいと思います。さらに、クライアント側で非同期通信していたりする箇所もあり、多少のレイテンシの悪化ではサービスに影響を与えません。それよりは新規機能の開発、チームの作業効率化、あるいは顕在化しているリスクを潰す方がコスパが良いのではないかと感じました。
―ということで、SLOの運用どうしようかなぁ・・・という状態で月日が流れました
弊社の当時の状態
SREが誕生して、サービスの信頼性を継続的に管理する体制が弊社に整ってきました。比較的システムが安定稼働はしているものの、信頼性向上のための足元課題は沢山あるので、優先度を決めて消化していかなければいけません。ただ、足元課題ばかりを対処していては、足元課題が減った時に、優先度の低いタスクを消化することになりSREチームとしてのバリューを発揮しづらくなります。弊社SREはそもそも、信頼性を担保しつつ事業成長を促進させることをミッションに掲げているので、課題ドリブンのタスクではなく、事業成長を促進させるシステムの理想状態を定義して、その実現に向けた中長期戦略と並行して足元課題に取り組む必要があります。
足元課題と中長期戦略を並行して取り組む工夫
足元課題をある程度許容して、中長期戦略を実行するというのは、実はSLOの運用と似ているのではないかと感じました。足元課題をどの程度まで許容するかの目標値を決めて、それを開発チーム全体に共有し、共通の目標とすることで、開発を優先したい開発チームと、信頼性を担保したいSREチームの2チーム間で期待値をコントロールする事ができます。また、開発チーム全体の目標とすることで、開発チームを巻き込んで一緒に改善作業に取り組むことにできたので、当時2人のSREチームの人手不足もある程度解消できました。
未実施の再発防止策をSLOとして管理
当時の弊社ではポストモーテムの文化は根付いていたのですが、開発タスクの優先度が非常に高く、ポストモーテムの再発防止策になかなか手がつけられていない状態でした。SREとしても既に発生した障害の再発防止を放置したくはありません。そうかと言って、全てに対応しきれません。そこで、未実施の再発防止策を定量評価することでスコア化し、それらの合計値をリスクスコアと名付け、一定スコア未満に保つように、開発チームと取り決めを行い、SLO化することにしました。
リスクスコアの設計
１. 発生した障害を3段階のインパクトに分けます
2. 障害に紐づく再発防止策毎にインパクトに応じたスコアをつけます
3. このスコア合計値を常に100点以下に保つことを目標にします
100点のスコアを超えた時は、開発メンバーを再発防止策消化タスクに強制アサインして、100点を下回るまで改善する取り決めを開発チームとしました。
当時SREでは定期的にSLOの啓蒙活動と共にリスクスコアの共有をして、あまりスコアが上がりすぎないように呼びかけを行っていました。
リスクスコアのシステム設計
未実施再発防止策のラベルのついたGitHubのIssuesを、AWSのLambdaで定期収集してDatadogにPostしていました。
リスクスコアを運用して良かったこと
未実施の再発防止策に限られますが、それらの改善作業を推進するための大きな後ろ盾が出来たと思います。リスクスコアが高いときには、開発エンジニアに改善作業を呼びかけることで、しっかりと作業してくれますし、開発チームのビジネスサイドのメンバーも理解してくれます。また、一度障害が立て続けに発生して、リスクスコアがSLOで定める100点を超えたときには、施策開発のいくつかのラインをストップさせて開発エンジニアと協力して改善作業をすることが出来ました。
また、もう一つ良かったことは、SLOの文化がチームに浸透したことです。レイテンシやエラーレートといった指標よりも、直感的にリスクを感じることのできる、未実施の障害再発防止策の方がビジネスサイドのメンバーも意識しやすかったのでは無いかなと感じています。もちろん、何度も繰り返しSLOについてはアナウンスしていたため、相乗効果ではないかと思います。
リスクスコアの改善点
運用しているうちにどうしても解決しづらい再発防止策が蓄積していきます。例えば、インパクト的には非常に低い障害であっても、改善策がとても難易度の高いものだったりすると、戦略的に再発防止策改善の見送りがされて、それが蓄積していきます。
一度そういったタスクが溜まった時には棚卸しをして対応しましたが、本来であればこういった事態を見越して、現実的なラインで再発防止策を設定するべきです。
最後に
会社の上司が言っていましたが、SLOの運用は体重測定に似ています。太りたくないと思って毎日体重計に乗っていれば、日常的に改善のアクションができます。同様に、組織に潜むリスクを可視化して日々意識することが大切だと思います。タップルではリスクスコアの導入により、多くのリスクが貯まる前に改善アクションができるようになっており、かつ、リスクを許容しつつ中長期戦略の実行にも踏み切れているため、リスクスコアを運用して良かったなと思っています。