試験運用中のプロダクトにSLOを導入する

ツール導入前の課題

従来のTOKIUMでは、システムの稼働状況を確認のデータとして、データベースの負荷状況やAWS ALBの5XXエラー率などを利用していました。
この方法は一定の効果をあげてはいたものの、データベース以外の問題に気づきにくかったり、重要機能にフォーカスして状況を確認することが難しい状況でした。

どのような状態を目指していたか

SLOを導入し、システムの信頼性を観測可能な状態を目指しました。 導入の第一歩として、試験運用中のプロダクトにSLOを導入することにしました。

モニタリングは基本的にDatadogを利用しているため、他サービスとの検討は行なっていません。
Datadog SLOには以下3つの種類が存在しており、それらのいずれを選択するかを検討しました。

• metrics base SLO
• time slice SLO
• monitor base SLO

結果的には、metrics base SLOとtime slice SLOを併用して利用することにしました。

• SREの一般的プラクティスに準じたSLOを算出可能であること
• ダッシュボードで可視化可能であり、多種多様な形でビジュアライズができること
• SLOの数値が長期的保持可能であり、振り返りができること（少なくとも1年）

time slice SLOと、metrice base SLOを並行運用することになりました。
以下が決め手となりました。

• time slice SLO ：稼働率ベースでSLOが算出可能であり、マネージャーなどへの説明に利用しやすいこと
• metrics base SLO：エラー率をそのままSLOに反映可能なため、チームで品質を確認する値として適している点

monitor base SLOは、以下の理由から利用しませんでした。

• 複数のメトリクスからSLOを算出したい場合に利用するものという認識だが、そのようなニーズは存在しなかった
• 他2つのSLOと比較し、メトリクスの保持期間など様々な点で機能的に劣っていた

現在はサービスイン直後でユーザー数が少ない状態であっても、SLOがあることで重要機能の監視設定の不足に気づくことができました。

1. 関係者への合意獲得 当初SREチームはtime slice SLOのみを導入することを想定していましたが、プロダクトエンジニアのレビューを経た結果、time sliceのみだと短時間のスパイクがSLOに反映されないことなどを指摘され、設計を見直す必要が出ました。

2. それぞれのSLOの違いのキャッチアップ time sliceとmetrics baseでは、SLOの算出方法に大きな違いがありますが、それらの違いを理解して比較検討することにもかなりの時間を要しました。

以下に当てはまる方は、ぜひDatadog SLOは一考の余地があると思います。

• 既にlogsやmetricsなどをDatadogに収集している
• SLOの導入を検討している

Datadog SLO自体には料金がかからないので、まずは試しに設定してみて、組織として利用することを検討してみるのが良いと思います。

現在は一つのプロダクトにしか導入していないが、最終的にはTOKIUMの全プロダクトにSLOを導入することを目指しています。