可用性の維持・向上のための振り返り: Error Actual Analysis

概要

• 現在、チームで取り組んでいる振り返り(Error Actual Analysis)を紹介します
  • Error Budget の取り組みにプラスして行うことで可用性の維持・向上を意図しています

※ Error Actual / Error Actual Analysis は一般的な用語でなくここでの独自用語です

Error Actual Analysis の目的

1. SLO違反を未然に防ぐ
2. SLO違反していない状態で過剰に反応しないようにする

Error Actual Analysis とは

• Error Actual Analysis とは、Error Actual (実績) を分析(Analysis)することでError Budget (予算) の枯渇を未然に防ぐための振り返り のこと
  • Error Budget の消費率を確認するのではなく、Error Budget を消費したエラーの内訳 を洗い出し、改善に向けた施策を打つためのもの (Error Budget の運用を補完する)

Error Budget とは

• Error Budget = 100% - SLO(%)
  • SLO(サービスレベル目標) とは
    • システムの可用性を担保するための基準となる目標値(≒ 目標稼働率)
      • 必ずしも可用性だけではないが、ここでは簡単のため、最も基本となる可用性として取り上げる
  • Error Budget は エラーを起こしても良い予算(信頼性低下の許容量) を表している
  • 例: Availability の SLO 99.9% → Error Budget 0.1%分
    • SLO 違反 = Error Budget 枯渇

Error Budget の役割

• Error Budget が枯渇した場合、リリースの回数を減らすなどのアクションを取り、SLOの維持・改善を図ることができる
• 一方で、Error Budget に余裕がある場合に、即時のアクションを取らない意思決定も可能である
• 参考
  • なぜSLOがあるのか

Error Actual

• Error Actual : Error Budget の消費量 & 消費内訳
  • 消費内訳の例: メールアドレス変更登録リクエストのエラー がBudget消費80%の内約半分を占めている

Error Actual Analysis の 意義

• Error Budget を使い切らなかった場合に明確なアクションが定義されていない
  • → 将来的に Budget 枯渇の原因となるエラーを事前に察知し損なうリスクがある
• Error Budget を使い切らなくても定期的にその内訳(Error Actual)を洗い出し、分析することで将来の枯渇リスクを減らすことができる
• Burn Rate の監視とは意義が異なる¹

Error Actual Analysis 運用の全体像

• Error Actual Analysis の実施するMTGを定期的に実施する
  • 毎週、2-5人、20-45分程度で実施
• 定期的にBudget 消費内訳を分析し、タスクを起票することで、Budget 枯渇を防ぐ

注意点

• 毎日はやりすぎ
  • 毎日MTGを実施してしまうと、結果的に過剰に反応することになり、Error Budget を設定した意味がなくなる
• SLO 自体のチェックは毎日見ること(これは SLO / Error Budget の運用でそうなっているはず)

Error Actual Analysis は以下のステップで進めます。

① Budgetの消費内訳の列挙

• MTG 前 に行っておく

• 前回から今回までの間の Budget の消費内訳を列挙

  • ツールなどでリクエストごとにエラー数をまとめておく

• エラー数順に列挙した例

メソッド	URL	エラー数	成功数	総数	エラー率(=エラー/総数)
POST	https://hoge.example.com/v1/pet	4	830	834	0.004796
GET	https://hoge.example.com/v1/user/logout	2	9477	9479	0.000211
GET	https://hoge.example.com/v1/pet/{petId}	1	52756	52757	0.000019
POST	https://hoge.example.com/v1/store/order	1	127110	127111	0.000008

ポイント

• 何が Budget を削っていたかがわかるようにしておく
  • → 影響が大きいものが何かがわかるようにしておくことで、[② 調査対象のピックアップ](#② 調査対象のピックアップ)を実施しやくすなる
• エラー数以外の情報も追加することで、後のステップで役立つ
  • リクエストごとのエラー率
    • → [② 調査対象のピックアップ](#② 調査対象のピックアップ)` のピックアップの際に利用できる
  • エラーの詳細情報
    • → [④ エラーの原因調査 & タスク化](#④ エラーの原因調査 & タスク化) の調査の際に利用できる

② 調査対象のピックアップ

• MTG 前 に行う
• 列挙されてものから、調査が必要なものをピックアップする
• 標準的な ピックアップの基準
  • 同一のエラーが 1週間で 3 回以上発生しているかどうか
    • 総リクエスト数に応じて回数は変更する
    • 上の例だと POST https://hoge.example.com/v1/pet が対象となる
• 調査対象が、1-5個くらいになるようにピックアップの基準を設定する
  • 翌週(翌スプリントなど)に調査・改善着手を実施できる程度の個数

ポイント

• 闇雲にすべてを実施してしまうと、 Budget を設定した意味 がなくなるので、適切なピックアップの基準を設けて置くこと
• ユースケースに応じて、エラー数の他のピックアップの基準を追加・変更することも可能
  • 例1: 増加見込みのリクエストのエラーであれば
    • ← 利用が増えることが見込まれるAPIに着目しておくことで将来のBudget消費を抑えることが期待できる
  • 例2: エラー率が0.5%を超えるものなら
    • ← エラーが起きやすいものを調査することで、共通原因の他のエラーを減らすことが期待できる

③ 改善タスクの効果確認

• MTG 中 に行う
• 以前の Error Actual Analysis で実施したSLO改善タスクによって改善されているかを評価
• 評価の基準
  • 改善対象のエラーの数が減り、[② 調査対象のピックアップ](#② 調査対象のピックアップ) のピックアップから外れているかどうか？
• 評価の結果
  • エラーが十分減少し、ピックアップされていない場合
    • Error Budget の消費が抑えられ、将来のリスクも減少したことを称える
  • エラーが十分減少せずに再びピックアップされている場合
    • [危険信号] 原因特定の仕方自体や検証方法に問題がある可能性が高い
    • → 調査手法を再検討し、調査に必要な情報が足りないなら監視の強化などを検討する

④ エラーの原因調査 & タスク化

• MTG 中 に行う
• エラーの原因をその場で調査する
• 追加調査 or 原因解消 のタスクを起票

ポイント

• 時間が限られているので、予備調査の時間を3分-5分程度とし、時間をかけすぎないようにする
  • チームの人数が多い場合は手分けして実施する
• 調査してわかったことを前提にしてタスク化を実施
  • 調査は完了しなくても良く、わかったところまでの情報を基にタスクを作成する
• 数が多くて時間内に終わらない場合、調査対象が多すぎることを意味している
  • → ピックアップ基準が甘すぎるので、[② 調査対象のピックアップ](#② 調査対象のピックアップ)のピックアップ基準の見直しを実施
  • ※ Error Budget が枯渇している状態であれば、早急な対応が必要なので別途時間を確保して対応する

1. Error Budget の burn rate の監視は、Budget の消費の勢いに注目するもので、主に短期(時間・日)で Budget の枯渇を未然に防ぐために利用されることが多い。Error Actual Analysis では、Budget の消費内訳に注目し、エラー詳細を確認するもので、 特に中長期(週・月)でのBudget 枯渇を未然に防ぐことにも繋がる。この性質のため、消費の内訳が変化しやすく、エラー詳細も変わりやすいフェーズ(サービス成長期など)に特に有効と考えられる ↩