Work illustrations by Storyset
N2i はディップ株式会社様と共同で面接コボットというプロダクトを開発しています。 面接コボットでは New Relic というモニタリングプラットフォームを使用しているのですが、今回 New Relic の担当者様主催の SLI ワークショップに参加することになりました。 この記事ではワークショップにて学んだ内容を技術ブログにまとめさせていただきます。
※以降、引用で表記したものはワークショップ内で説明があった表現を利用させていただいております。
SLA, SLO, SLIについて
最初に SLA, SLO, SLI それぞれの定義について確認です！
SLA とは？
SLA とは Service Level Agreement という意味合い通り、サービス事業者が利用者に対して、「どの程度の品質を保証できるのか」を明示したものです。 筆者はとある受託案件にて、SLA を参考に目標が達成されなかった場合の対応について、PM としての策定経験があります。
SLO, SLI とは？
SLO は Service Level Objective つまりサービスレベル目標、SLI は Service Level Indicator つまりサービスレベル指標を指します。 セットで記載されることが多く サービス事業者が「目標として設定されるもの」 であるものです。
SLOを定めることによって、それに逸脱しないという明確な基準を持って、新機能のリリースを推進することができる SLOは運用チーム、開発チーム、プロダクトチームの共通言語として活用することができる
ワークショップでは上記のように説明していただきました。
それぞれの項目の決定・策定
次に SLI, SLO を何にするか決めていきます。
SLI の策定
先に SLI の策定から行います。SLI は上記の考え方をベース利用者がコボットで行う最もメジャーな操作の流れを書き出しました。 その中でサービスにとって重要なことを SLI として計測すべき対象として定義しました。
SLI の計測
次に New Relic を操作して SLI の計測を行います。
今回、設定の詳細は伏せさせて頂きますが、実際の計測結果は下記のようになりました。
ワークショップにて筆者のグループでは、コボット上に取り込んだ応募者が正しく表示されることを SLI の計測対象として設定したため APM で計測されている対象の API が正しくレスポンスを返せている割合を計測しています。
SLO の設定
SLI の計測ができたので SLO を決めていきます。
サービス事業者は監視ツールのエラー率を高めるわけにサービス提供をしているわけではありません。 ワークショップにて SLO について下記のように教えていただきました。
SLOを超えていれば、ほとんど全てのユーザーはサービスに満足している
この考えに従って、今回は下記画像のように SLO を定めました。
※このSLOはワークショップの演習として設定したもので、正式なものは別途検討予定です
ちなみに SLO はサービス事業者が設定する目標になるため SLA で設定する値よりは高く設定されるケースが多いです。
なぜ SLO を定めるのか？
SLO を定めることでその達成状況に合わせてプロダクトの方針を決めることができます。
- SLO が未達成であれば、新機能のリリースよりもエラー原因の解消に注力する
- SLO 達成済みであれば、新機能のリリース計画を立てる
このように SLO の達成率に従った意思決定が可能となるわけです。 また、SLO を定義することでチーム内でプロダクトの状況を関係者が共通言語として活用することができます。
SLOは運用チーム、開発チーム、プロダクトチームの共通言語として活用することができる
また、SLO が達成できていることはユーザの満足度につながっているはずです。 もし SLO が達成していてもユーザの満足度があがっていないのであれば、SLO を見直したり、計測する SLI を見直すことでより SLO を活用することができます。
ワークショップに参加してみて...
初めは New Relic 主催のワークショップということで New Relic の APM の使い方を中心に学ぶ会と考えていました。（こちらも今後開催があれば参加してみたい） 実際は SLO, SLI の座学とワークを通して SLO を運用するための知識を得られる有益な場でした。 参加者はビジネス・アプリ・インフラの領域の人でチームが構成されていたため、SLI の議論の際には様々な重要だと思う機能の話が出たりして面白かったです ！ この度はワークショップを開催いただきありがとうございました！
