copied!

OpenSLO とは？

Kai Sato

2023.2.7

copied!

はじめに

OpenSLO の概要に触れながら SLO as Code の現状についてお話しします。

OpenSLOとは？

OpenSLO とは、サービスレベル目標 (SLO)、それに関連するリソースの記述形式を標準化する試みです。
SLO の SaaS を展開している Nobl9 が中心となって策定し、2021年5月にバージョン 1.0 を発表しました。

SLO をコードで扱うツールは以前からありましたが、SLO のデータ表現方法が確立されていなかった中、OpenSLO が発表されました。

リポジトリ https://github.com/OpenSLO/OpenSLO

OpenSLO の特徴

Kubernetes YAML フォーマットで記述し、リソースとして以下が定義可能です。

DataSource
SLO
SLI
AlertPolicy
AlertCondition
AlertNotificationTarget
Service

参考 https://github.com/OpenSLO/OpenSLO/blob/main/README.md#general-schema

目的

このプロジェクトの大きな目的は、SLO を定義するためのオープンな仕様を提供し、ベンダーにとらわれない共通のアプローチを可能にすることです。

Schema (SLO の例)

SLO、SLI の計算方法や計算に使うデータソースはどこから取ってくるか、などを記述しています。

apiVersion: openslo/v1
kind: SLO
metadata:
  name: foo-slo
  displayName: Foo SLO
spec:
  service: foo
  indicator: # inlined SLI
    metadata:
      name: foo-error
      displayName: Foo Error
    spec:
      ratioMetric:
        counter: true
        good:
          metricSource:
            metricSourceRef: datadog-datasource
            type: Datadog
            spec:
              query: sum:trace.http.request.hits.by_http_status{http.status_code:200}.as_count()
        total:
          metricSource:
            metricSourceRef: datadog-datasource
            type: Datadog
            spec:
              query: sum:trace.http.request.hits.by_http_status{*}.as_count()
  objectives:
    - displayName: Foo Total Errors
      target: 0.98

対応するツール

OpenSLO は SLO を記述するためのスキーマのみを定義しているため、このフォーマットに対応した外部ツールが必要です。

OpenSLO/oslo
- OpenSLO の yaml のバリデーション、指定したフォーマットに変換してくれる
- 今のところ nobl9 の設定ファイルのみ対応
  ex: oslo convert -f file1.yaml -f file2.yaml -o nobl9
OpenSLO/slogen
- Sumologic という SaaS に提供するための SLO ダッシュボード、モニター、SLI データを OpenSLO の設定ファイルから生成する CLI ツール
- リソースは Terraform 経由で生成される
slok/sloth
- Prometheus 向けの SLO ジェネレーター
- 独自の記述形式と OpenSLO に対応

SLO as Code で実現されるかもしれないこと

基本的なニーズは以下になると筆者は考えます。

大量の SLO を運用している場合、SLO の設定や見直しが起きた時に変更を効率化できる
- 大量の SLO を運用している場合、SLO の設定や見直しが起きた時に1つ1つ手作業で行うのは辛い
- Terraform で SLO を管理している場合はこれが享受できる
ベンダー移行時に円滑に移行できる
- 例えば Datadog での運用がコスト的に難しく、Prometheus に移行するとなった場合に、
  最初から OpenSLO を使っていれば楽に移行できる
- Terraform でもリソースの表現形式が違うので、この場合にOpenSLO で定義しておけば、簡単に実現できそう

OpenSLO がどう使われるのか

1. OpenSLO を介して、各モニタリングサービスの設定ファイルを出力する

Datadog をはじめとするモニタリングサービスに合わせたフォーマットでエクスポートできると、
ツール移行が発生した際の工数削減にもなり、テンプレート化のうえサービス間での転用もできるようになるため、運用負荷の軽減が見込めます。

2. SLO generator

https://github.com/google/slo-generator

Cloud Monitoring、 Prometheus、Datadog、Elasticsearch、Dynatrace からデータソースを指定し、SLO, Error Budget, Burn Rate などを計算します。

計算結果を Cloud Monitoring、Bigquery、cloudevent、PubSub、Prometheus、Datadog、Dynatrace に送信できます。OpenSLO にはまだ対応していません.

特徴

Python 製の CLI と Web サービス (API)
規格化した仕様から各モニタリングシステムへ SLO を送信できる

設定

SLO configuration と Shared configuration の2つの設定ファイルを定義する必要があります。以下がサンプルです。

Shared configuration

backends:
  cloud_monitoring/dev:
    project_id: <project_id>
exporters: 
	cloud_monitoring/dev: 
		 project_id: <project_id>

SLO configuration

apiVersion: sre.google.com/v2
kind: ServiceLevelObjective
metadata:
  name: gae-app-availability
  labels:
    service_name: gae
    feature_name: app
    slo_name: availability
spec:
  description: Availability of App Engine app
  backend: cloud_monitoring/dev
  method: good_bad_ratio
  exporters:
  - cloud_monitoring
  service_level_indicator:
    filter_good: >
      project=${GAE_PROJECT_ID}
      metric.type="appengine.googleapis.com/http/server/response_count"
      resource.type="gae_app"
      ( metric.labels.response_code = 429 OR
        metric.labels.response_code = 200 OR
        metric.labels.response_code = 201 OR
        metric.labels.response_code = 202 OR
        metric.labels.response_code = 203 OR
        metric.labels.response_code = 204 OR
        metric.labels.response_code = 205 OR
        metric.labels.response_code = 206 OR
        metric.labels.response_code = 207 OR
        metric.labels.response_code = 208 OR
        metric.labels.response_code = 226 OR
        metric.labels.response_code = 304 )
    filter_valid: >
      project=${GAE_PROJECT_ID}
      metric.type="appengine.googleapis.com/http/server/response_count"
  goal: 0.95

まとめ・感想

いかがでしたでしょうか。

OpenSLO が出てきてまだ間もないため対応ツールが少なく、SLO as Code としても未成熟でプラクティスもまだ確立されていないですが、
標準化のフォーマットとしては OpenSLO が確立されていきそう、という印象を受けました。

OpenSLO の動向は引き続き注視しようと思います。

参考

運用の効率化を支える AWS Systems Manager Automation の紹介

aws-vault のすすめ