SLOの実装・SLOに基づくアラート

💡

SREにSLOが必要な理由エンジニアは限りのあるリソース可用性100%の罠 SLOの実際目標の定義ターゲットの選択シンプルさを保つ「絶対」は避ける SLOは最小限にとどめる最初から完璧でなくてもよい SLOは理にかなった強制機構である 4大シグナルレイテンシトラフィックエラーサチュレーションまとめ

SREにSLOが必要な理由

サービスレベル目標（SLO）はサービスの信頼性の目標レベルを示すものである
SLOは信頼性に関して意思決定を下す上で鍵となるものであり、SREの実践の中核とも言える

エンジニアは限りのあるリソース

エンジニアリングにかける時間は、最も重要なサービスの最も重要な部分に投資されるべき
新しい顧客を得たり現状の顧客を保つための機能への投資と、それらの顧客を満足させ続けるような信頼性とスケーラビリティへの投資との適切なバランスを見つけ出す必要がある

可用性100%の罠

システムを担当すると、可用性やSLOを100%に設定したいという要望がある場合がある
- つまり障害を起こさないシステムであってほしいということ
- これは数値として提示されなくても、「障害を絶対に起こさないでほしい」や、実際に障害が起きたときに「次は絶対に起こさないように」「なぜ障害を起こしてしまうのか？ありえない」などの言葉で表現される場合がある
- しかし多くの場合に可用性100%は不適切な目標である
可用性100%を達成するには、多くの場合システムを過度に冗長化させる必要がある
- AWS Route53というサービスは可用性100%であるが、2018年時点で20以上のエッジロケーションにシステムが冗長化されており、ある箇所で障害が発生すると瞬時に別の国のシステムに切り替わるようになっている
  - https://dev.classmethod.jp/articles/report-reinvent-2018-1128-arc408/
  - また顧客ごとに分離された複数のシステムが裏側で提供されるようになっていたりと、複数の方法やレイヤーで冗長化が行われている
- これを自社のシステムで実現するには、ユーザーが満足するレベルを超えて不必要であり、反対に運用コストがかかりすぎる（人の管理コスト的にも金銭的コスト的にも）
レイテンシを悪化させることなく「無限に」負荷をスケールさせ、「常に」利用できるシステムを求めたくものだが、これは現実的な要求ではない
- 可用性100%とは裏を返せば、リスク0の変更しかできない。しかしリスク0の変更とはほとんどの場合に存在せず、それは過剰に高価で保守的なシステムを要求することにつながる。
  - 「無限に」お金があるなら求めてもいいが、お金は無限ではない
- SREは現実の世界で運用と開発のバランスを取る方法を模索する
  - 開発をしようと思うのならば、可用性100%とは過剰な目標であることに気づくべき

SLOの実際

実際にSLOを考えよう
ユーザーが気にすることを考え、そこから指標を決定していく

目標の定義

SLOでは計測の方法と計測値が適正である条件を指定して設定する
例えば以下のように
- API呼び出しの99%が100ミリ秒以下で完了すること
- パフォーマンスカーブの形が大事であれば以下のように複数を設定する
  - API呼び出しの90%が1ミリ秒以下で完了すること
  - API呼び出しの99%が10ミリ秒以下で完了すること
  - API呼び出しの99.9%が100ミリ秒以下で完了すること
- 特定の処理で重要なクライアントが設定される場合にはそのように設定してもいい
  - 1kB以上のペイロードを持つAPI呼び出しの99%が10ミリ秒以下で完了すること

ターゲットの選択

SLI/SLO/SLAにはプロダクトやビジネスの事情が大きく反映される
- エンジニア、市場投入までの期間、利用できるハードウェア、資金などの事情から制約があり、トレードオフを行わなければいけない
  - 「可用性100%の罠」で述べたように、高い可用性を確保するためにはそれ相応のコストがかかる
SREにおいて適切なSLOを設定するために以下の指標に基づいて考えてみよう

シンプルさを保つ

複雑な集計が必要なSLIはシステムのパフォーマンスの変化を掴みづらくしてしまう
複雑な集計があると、原因の追求も難しくなる

「絶対」は避ける

「無限に」負荷をスケールさせ、「常に」利用できるようなシステムは求めたいが、こういった要求は現実的ではない
- 前の節の「可用性100%の罠」参照
ユーザーが満足するレベルを超えて不必要に良いものであることは、運用のためのエンジニアの能力を不必要に消耗させる
- そしてエンジニアの能力は限りあるリソースである

SLOは最小限にとどめる

SLOはシステムの属性をカバーする必要最小限であるべき
業務の優先事項を決定づけたことがないSLOは十分な価値のないSLOかもしれない

最初から完璧でなくてもよい

SLOの定義とターゲットはシステムの振る舞いを学ぶにつれて、見直して良い
初めに緩めのターゲットから始めてそれを少しずつ厳しくしていくとよい

SLOは理にかなった強制機構である

SLOは、SREやプロダクト開発者の仕事の優先順位を決める上で、主要な要因になるものであり、そうあるべきである
SLOにはユーザーの関心ごとが反映され、良いSLOとは開発チームにとって有益で、理にかなった強制機構である
- ユーザーの体験を損ねるような（例えばレイテンシを悪化させるような）開発は、SLOの基準によって許可されない
  - SLOは開発者が満たすべき最低限の基準を提供する
- SLOが満たされていない時間が続くようなら運用作業を、満たされていれば価値を最大化する（開発を行う）というように、チームを動かす強い基準となる
しかし、よく考えられていないSLOは、過剰に厳しいSLOを満たすためにチームに超人的努力を促したり、甘すぎるSLOはプロダクトの質の低下を招く

4大シグナル

SRE本第6章「分散システムのモニタリング」より
モニタリングを行う時に、ユーザーが直接利用するシステムでメトリクスを4つだけ計測できるならこの4つに集中するべき
- レイテンシ、トラフィック、エラー、サチュレーション

レイテンシ

リクエストを処理してレスポンスを返すまでにかかる時間
処理に成功したリクエストのレイテンシと、失敗したリクエストのレイテンシを区別することが重要
- 例えば、データベースなどバックエンドへの接続が失敗した場合の500エラーはきわめて高速に返されるが、これで全体のレイテンシに含めて計算してしまうとミスリードにつながる（失敗はしているがレイテンシは高速であるという誤った結論になる可能性がある）
- さらに低速なエラーというのは追跡して原因を調査する必要がある場合が多い
  - データベースにアクセスしようとしているがタイムアウトなど
  - したがってエラーのレイテンシも追跡することが重要

トラフィック

システムに対するリクエストの量
毎秒のHTTPリクエスト数で計測することが多いが、システムの性格によって異なる計測が必要になる場合もある
- 動画配信サービスであれば、ネットワークI/Oレートや同時セッション数などを気にするかもしれない
- ストレージシステムを提供していたら、毎秒のトランザクションや取得数を計測する必要があるかも

エラー

処理に失敗したリクエストのレート
失敗には以下の3種類が主に存在する
- 明示的な場合
  - HTTPの500番台など
- 暗黙的な場合
  - HTTPで200の成功レスポンスを返しているが、内容が誤っている
- ポリシーによる場合
  - レスポンスタイムを1秒以下にすると約束しているが、1秒以上かかっている
プロトコルのレスポンスコードは多くの場合には障害の状況を完全には表現していないので、追跡するためには二次的なプロトコルが必要になる場合がある
- システム独自のエラーコードを定義する
- AWSにおけるX-Rayなどで追跡できるようにしておく
- 構造化されたログを出力するようにする

サチュレーション

サービスがどれだけ「手一杯」になっているかを示す
最も制約のあるリソースに重点を置いてシステムの利用率を計測する
- メモリに制約があればメモリ
- I/Oに制約があるならI/O、CPUに制約があるならCPU使用率、など
注意しなければいけないのは、多くのシステムでは利用率が100%になる前にパフォーマンスは低下する
- したがって利用率のターゲットを100%よりある程度手前に設定しておく必要がある
サチュレーションは多くの場合には間接的な指標である
- 基本的にはレイテンシの方が先行して悪化する
- したがってサチュレーション指標は「問題になりかかっている」あたりで対処されていないと、システムとしては既に問題になっているケースが多い

まとめ

エンジニアリングは限りのあるリソースであり、機能への投資と顧客を満足させ続けるような信頼性への投資との適切なバランスを探る必要がある
SLI/SLOはサービスの信頼性の目標であり、SLOはチームの判断を決定する強制機構として作用する
SLOには4大シグナルとして「レイテンシ」「トラフィック」「エラー」「サチュレーション」が考えられ、最初はこれらから設定するとよい