SLOのすすめ
- 1. SLO のすすめ Takeo Sawada Dropbox, Inc. September 25, 2017
- 2. 自己紹介 名前 澤田 武男 Twitter @SawadaTakeo 2013 - 2014 Ads Backend SRE @Google HQ Display Ads Backend など 2014 - 2017 Source SRE @ Google NY Piper (Google のプロプライエタリなソースコン トロールシステム) Git (Android, Chrome, code.google.com, Cloud Source Repositories) ローンチ調整エンジニア (LCE, SRE 本 27 章) SLO の策定、モニタリング、障害対応、 PRR(SRE 本 32 章) など 2017 - Build SRE @ Dropbox Changes (内製の CI ツール) Bazel クラスタ
- 4. 今日の話題 SRE 本第 II 部 原則 から 4 章: 「サービスレベル目標」 外部に直接面していないような サービスでもサービスレベル目 標を有効に使ってほしい 5 章: 「トイルの撲滅」
- 5. サービスレベル目標
- 6. サービスレベル目標とは何か 用語: SLI vs SLO vs SLA SLI - Service Level Indicator: 指標 例: リクエストの成功率 SLO - Service Level Objective: 目標 例: 各四半期中の全リクエストの成功率は 99.9%以上です。 SLA - Service Level Agreement: 合意 例: SLO が満たされなかった場合、利用料の 50%を返金します。 サービスレベル目標: あるサービスの信頼性についての数値目標
- 7. SLO を定義するメリット どのくらいの信頼性を目指すのかをはっきりさせる コストや開発速度とのトレードオフをしっかりと議論する機 会になる SLO によってサービスのアーキテクチャ、チーム体制、モニ タリングの感度、障害対応などが変わってくる 「高い信頼性」という曖昧な目標から、チームメンバーが共 有する 1 つの数値目標へ エラーバジェットでトレードオフのバランスを取る (SRE 本 3 章) 過剰な要求からチームを守る あらかじめステークホルダーに SLO を共有し合意しておく 達成困難な信頼性目標を要求された時に参照できる 過剰に依存されるのを避ける ユーザに対してあらかじめ「期待できる信頼性」を示しておく 自サービスより高い信頼性が求められるサービスに不適切に 組み込まれるのを避ける
- 8. SLO の定義のしかた 1. SLI にするメトリクスを決める 2. 目標を決める 3. Profit!!! サービス、ユーザ、チームなどによるので「正しいやり方」は無い
- 9. SLI の選びかた ユーザ体験の満足度への近さ モニタリングの容易さ 安定して収集し分析できるメトリクス シンプルさ SLI はできるだけ少なくする さまざまなカテゴリ 可用性 (Availability) レイテンシー (Latency) 耐久性 (Durability) スループット (Throughput) まずは可用性から始めてみよう
- 10. SLI をモニターする ユーザートラフィックを直接計測する エラーの分類:リクエストが失敗した原因がユーザにあるか サービス側にあるかを正しく分類する 全てのリクエストを SLO でカバーすべきか考える (リクエス トの種類、サイズなど) トラフィックパターンに影響を受けやすい プローブ用のトラフィックを生成し計測する (ブラックボッ クスモニタリング) ユーザ環境に近い地点で計測できる 全てのコードパス、リクエストパスを検査するのは大変 ref. SRE 本 6 章 「分散システムのモニタリング」
- 11. SLO の定義の色々 例えば “99.9%の Uptime” と言っても... ある期間中の全てのリクエストとエラーを集計したエラー率 が 0.1%以下 ある期間を数分のウィンドウ単位に分割し、99.9%以上の ウィンドウでエラー率が x% 以下 ある期間を数分のウィンドウ単位に分割し、各ウィンドウの エラー率を平均したものが 0.1% 以下 Amazon S3, Google Cloud Storage などがこの形式 サービスの特性、ユーザの期待などに合わせて適切な定義を選ぶ
- 12. SLO が達成できなかったら？ リリースをフリーズ 障害の多くは変更に付随して発生する 信頼性に関する改善の優先順位を上げる 目標そのものを見直す ref. SRE 本 3 章 3.4 エラーバジェットの活用
- 13. Public SLA へ 外部に公開する SLA はプロダクトデザインレベルの選択に なる SRE が技術的な判断や情報を提供しつつ、開発者、PM と議 論する
- 17. トイルが多すぎると SRE のポジションのキャリア上の魅力が減る 採用が難しくなる SWE への転出 生産性の低下 手作業によるミスの発生 Google では 50%を目標にしている。 ref. SRE 本 5 章 5.4 トイルは常に悪なのか？
- 18. トイルの削減: オンコール対応の例 行っている作業を見直し、地道に自動化、改善していくしかない 週に数十以上のページ (アラート) が発生して多大なオンコー ル対応負荷が生じていた (SRE 本 11 章 11.3 バランスの取れ たオンコール) 対応 毎週プロダクションミーティングを開催 (SRE 本 31 章 31.1) その週におきた全てのアラートとその対応をレビュー 重大な障害にはポストモーテムを書き、その後ポストモーテ ムレビューを実施 (SRE 本 15 章) 場当たり的な修正に変えて 根本的な原因の修正。時間のかかるものはプロジェクト化 他チームのバグの積極的な修正依頼 プレイブック (手順書) の強化 不要なアラートの見直し 数ヶ月の取り組みでページ頻度が 1/5 程度に