3-shake SRE Tech Talk #3 SLO違反への対処を継続的に改善する試み

SRE Tech Talk #3 SLO違反への対処を 継続的に改善する試み 2022/3/18 Yuki Ando

Yuki Ando / あんどぅ AWS好きの駆け出しSRE 経済ニュースメディアのSREチーム所属 好きなAWSのサービス：ECS、CodeDeploy 好きなSREのプラクティス：SLO、非難なきポストモーテム文化 @integrated1453 JAWS-UG SRE支部 AWS認定ネットワーク本 2

＼突然ですがみなさん／

SLO違反への対処やってますか？？🤔

今日話すこと （所属会社の事業やSREとは何かについては触れません） 1 SLO違反への対処とは 2 SLO違反への対処をどうやって改善するか 3 わかったこと 5

今日話すこと 1 SLO違反への対処とは 2 SLO違反への対処をどうやって改善するか 3 わかったこと 6

SREが関わるテーマ 信頼性に関わることすべて： SRE Book 目次より SLO トイルの撲滅 分散システムのモニタリング 自動化 リリースエンジニアリング インシデント対応 ポストモーテムと根本原因分析 オンコール対応 過負荷への対応 …etc 7

サービスレベル目標(SLO) 顧客体験(CUJ)からSLI/SLOを決め、SLOを基準にサイトの信頼性を維持していく POINT 01 02 03 クリティカルユーザー サービスレベル指標 サービスレベル目標 ジャーニー(CUJ) (SLI) (SLO) SLOの主眼は顧客体験の ユーザーにとって重要であ SLIで計測されるサービス 改善。ユーザーにとって重 ると考えられるサービスの レベルのターゲット値 要なサービス上のタスクの アウトカムに対する評価と 顧客が満足するレベルに ステップを補足する その計測方法 調整していく POINT POINT 8

サービスレベル目標(SLO) 顧客体験(CUJ)からSLI/SLOを決め、SLOを基準にサイトの信頼性を維持していく APIのリクエスト成功率 記事ページのレイテンシー をアクセスログから 計測する スマホアプリから プッシュ通知された最新の 経済ニュースを読みたい 100ms以内で応答した リクエストの割合>80% 可用性>99.8% POINT 01 02 03 クリティカルユーザー サービスレベル指標 サービスレベル目標 ジャーニー(CUJ) (SLI) (SLO) SLOの主眼は顧客体験の ユーザーにとって重要であ SLIで計測されるサービス 改善。ユーザーにとって重 ると考えられるサービスの レベルのターゲット値 要なサービス上のタスクの アウトカムに対する評価と 顧客が満足するレベルに ステップを補足する その計測方法 調整していく POINT POINT 9

教科書的なSLI/SLO 「サイトリライアビリティワークブック 2章 SLOの実装」を参考に作成 SLIの種類 SLI 顧客の階層 SLO 可用性 リクエスト成功率 有料会員 99.9%以上 無料会員 99.8%以上 モバイルアプリ 90%以上 Web 80%以上 モバイルアプリ 99%以上 Web 95%以上 レイテンシー 100ms以内のレスポンス 1000ms以内のレスポンス

SREが関わるテーマ 信頼性に関わることすべて： SRE Book 目次より SLO トイルの撲滅 分散システムのモニタリング 自動化 リリースエンジニアリング SLO違反への対処 インシデント対応 ポストモーテムと根本原因分析 オンコール対応 過負荷への対応 …etc 11

「サイトリライアビリティワークブック 付録B エラーバジェットポリシー」より SLO違反のポリシー 以下の場合、チームは機能の開発作業の代わりに信頼性に関する作業をしなければならない。 コードのバグあるいは手続き的なエラーがサービスそのもののエラーバジェット超過を引き起こした。 ストモーテムによって強い依存性を和ら 分類を間違えられたエラー る必要 明らかになった。 、サー スのSLO違反の原因となるようにエラー ェットをきちんと消費 しなかった。 「信頼性こそが、あらゆるプロダクトの基本的な機能である」というSREの発想のもと、 SLO/エラーバジェットポリシーが信頼性の門番として機能するようにみえる ジ バ が げ ビ 12 が ポ 教科書的なエラーバジェットポリシー

つまりこういうこと？ SLOをモニタリングして、SREが信頼性の門番になる？ SRE？ 開発チーム あ、SLO違反になってる😠 みんな〜〜！信頼性を回復す るために機能の開発中断する やで〜〜〜！！！💪

つまりこういうこと？ SLOをモニタリングして、SREが信頼性の門番になる？ SRE？ 開発チーム は？ は？ あ、SLO違反になってる😠 みんな〜〜！信頼性を回復す るために機能の開発中断する やで〜〜〜！！！💪 は？ は？ は？ は？ は？ は？

SLO違反したら全開発チームの作業止めるとか 現実的にはありえない

「SREの探求 22章 成功の文化としてのSRE」より フェー 1 : 消火活動/事後対応 「システムを何とか動かし続ける」と同時に、自動化を通 て新たなア ローチを構築 フェー 2 : 門番 ロ クションシステムに対する変更は必 承認を受けて通過しなけれ フェー 3 : 支持者/ 合意したター ットを ートナー ならない唯一の関門として機能する ートナー 達成し、その後も引き続き満足していけるように支援する フェー 4 : 触媒 あらゆるサー スの構想から廃止ま に関与して、適切なツールを提供 きるように支援する プ で ば じ ず パ で が パ ゲ ビ ズ ズ ズ ズ 16 ダ プ SRE実施のフェーズ

「門番」から「支持者」へ 開発チームがSLOのモニタリングと改善を自走できるまでは、信頼性を高めるサポートをする SRE 開発チーム この前リリースしたAPIが原因で、 ページを表示するまでの時間が遅く なってるみたいです〜 ありがとう！ユーザーのため に機能を追加したのに、ユーザー 体験が悪くなるところだった🙏

「門番」から「支持者」へ Google CloudのBlogにもいいことが書いてありました SLO の規定内でサービスが稼働していたとしても、積極的に信頼性を向上させることは、障害の将来的 なリスクを抑え、効率性を改善し、そしてコスト削減につながります。一方、SLO を満たしていないか らといって、すぐに内部での機能開発を完全にやめてしまう組織はほとんどありません。 (中略) 関連する開発チームにも知らせましょう。このプロセスは手動でもかまいません。SRE チームは違反を フィルターにかけて集約し、意味のあるコンテキストを提供するなど価値を付け加えることも可能です。 https://cloud.google.com/blog/ja/products/gcp/consequences-of-slo-violations-cre-life-lessons

• https://cloud.google.com/blog/ja/products/gcp/consequences-of-slo-violations-cre-life-lessons

／ 違反をフィルターにかけて集約し、意味のある コンテキストを提供するなど価値を付け加える ＼

エスカレーションするまでの時間も信頼性に影響 「SREの探求 4章 インシデントのメトリクスを用いたSREの大規模な改善」より 適切なエンジニアが関与するまでの エンゲージ時間(TTE)がインシデント全体 の軽減時間(TTM)に含まれる SLO違反への対処として、エラーバジェ ットを消費する原因となった機能および 担当チームを素早く特定する必要がある

SLO違反時のSREからの見え方 Webのレイテンシーが問題ということしかわからない。この状態からどうする？ SLIの種類 SLI 顧客の階層 SLO 可用性 リクエスト成功率 有料会員 99.9%以上 無料会員 99.8%以上 モバイルアプリ 90%以上 Web 80%以上 モバイルアプリ 99%以上 Web 95%以上 レイテンシー 100ms以内のレスポンス 1000ms以内のレスポンス

／ エラーバジェットを消費する原因となった機能と 担当チームを素早く特定して、信頼性を回復するため の情報提供をしたい ＼

今日話すこと 1 SLO違反への対処とは 2 SLO違反への対処をどうやって改善するか 3 わかったこと 23

SLO違反からエスカレーションまでの調査 アクセスログを集計してSLOをモニタリングしている場合 SLO違反となったタイムウィンドウよりも高解像度でSLOを確認する 1dayのSLO違反であれば、hourlyのSLO達成状況を見て、悪化している時間帯を特定する エラーレートやレイテンシーが高いAPIエンドポイントを特定する エンドポイント別のエラーレート・レイテンシーの集計を行い、過去の傾向と比較する エラーバジェットの消費が発生し始めた時間帯の前後のイベントを確認する 機能のリリース、インフラ作業、エンドユーザーへのPush通知、マスプロモーション インフラリソースのプロビジョニングが十分だったかを確認する ECSのタスク数、DBのCPUやメモリ使用率、I/Oスループット 24

毎回実施するのは大変なので、 New Relicで素早く確認できるようにしました

SLO違反からエスカレーションまでの調査 アクセスログを集計してSLOをモニタリングしている場合 SLO違反となったタイムウィンドウよりも高解像度でSLOを確認する 1dayのSLO違反であれば、hourlyのSLO達成状況を見て、悪化している時間帯を特定する エラーレートやレイテンシーが高いAPIエンドポイントを特定する エンドポイント別のエラーレート・レイテンシーの集計を行い、過去の傾向と比較する エラーバジェットの消費が発生し始めた時間帯の前後のイベントを確認する 機能のリリース、インフラ作業、エンドユーザーへのPush通知、マスプロモーション インフラリソースのプロビジョニングが十分だったかを確認する ECSのタスク数、DBのCPUやメモリ使用率、I/Oスループット 26

直近24hに絞り込んで詳細を確認するリンクをブックマーク登録 SLOアラートを検知後、24h以内のSLO達成状況を確認するダッシュボードのリンクを登録 アクセスログを都度集計していると 毎回時間がかかるので、リンクから一瞬 で確認できるのは便利です。 27

SLO違反からエスカレーションまでの調査 アクセスログを集計してSLOをモニタリングしている場合 SLO違反となったタイムウィンドウよりも高解像度でSLOを確認する 1dayのSLO違反であれば、hourlyのSLO達成状況を見て、悪化している時間帯を特定する エラーレートやレイテンシーが高いAPIエンドポイントを特定する エンドポイント別のエラーレート・レイテンシーの集計を行い、過去の傾向と比較する エラーバジェットの消費が発生し始めた時間帯の前後のイベントを確認する 機能のリリース、インフラ作業、エンドユーザーへのPush通知、マスプロモーション インフラリソースのプロビジョニングが十分だったかを確認する ECSのタスク数、DBのCPUやメモリ使用率、I/Oスループット 28

API別のレスポンスやエラー率を、直近1日と1週間で比較 SLOアラートを検知後、24h以内の500Errorとレイテンシーが高い順ランキングを、直近1週間と比較 29

SLO違反からエスカレーションまでの調査 アクセスログを集計してSLOをモニタリングしている場合 SLO違反となったタイムウィンドウよりも高解像度でSLOを確認する 1dayのSLO違反であれば、hourlyのSLO達成状況を見て、悪化している時間帯を特定する エラーレートやレイテンシーが高いAPIエンドポイントを特定する エンドポイント別のエラーレート・レイテンシーの集計を行い、過去の傾向と比較する エラーバジェットの消費が発生し始めた時間帯の前後のイベントを確認する 機能のリリース、インフラ作業、エンドユーザーへのPush通知、マスプロモーション インフラリソースのプロビジョニングが十分だったかを確認する ECSのタスク数、DBのCPUやメモリ使用率、I/Oスループット 30

デプロイのイベントとエラー／レイテンシーの変化を確認する New RelicのDeployment MarkerをCI/CDに組み込み、変化のトリガーになってそうな変更を特定 Deployしたユーザーとrevisionを特定 31

SLO違反からエスカレーションまでの調査 アクセスログを集計してSLOをモニタリングしている場合 SLO違反となったタイムウィンドウよりも高解像度でSLOを確認する 1dayのSLO違反であれば、hourlyのSLO達成状況を見て、悪化している時間帯を特定する エラーレートやレイテンシーが高いAPIエンドポイントを特定する エンドポイント別のエラーレート・レイテンシーの集計を行い、過去の傾向と比較する エラーバジェットの消費が発生し始めた時間帯の前後のイベントを確認する 機能のリリース、インフラ作業、エンドユーザーへのPush通知、マスプロモーション インフラリソースのプロビジョニングが十分だったかを確認する ECSのタスク数、DBのCPUやメモリ使用率、I/Oスループット 32

SLOとインフラリソース状況を同じダッシュボードで確認できるようにする New RelicのAWSインテグレーションでSLOダッシュボードにECSタスク数やCPU使用率を表示 インフラがソフトウェアの機能特性や ユーザーのアクセスパターンが変化した ことに対応できているかを確認 33

今日話すこと 1 SLO違反への対処とは 2 SLO違反への対処をどうやって改善するか 3 わかったこと 34

わかったこと コンテキストを補足して開発チームへのエスカレーションを早めることがサイト信頼性を高めること につながるので、日々のSLO違反への対処を地道に改善していくとよい SLO違反の発生 検出時間 インシデント 継続… エンゲージ時間 検出時間 エンゲージ時間 修正時間 信頼性回復 ・SLO再遵守 35

＼ご清聴ありがとうございました／