PairsにおけるSLI/SLO再定義

Embed

Start on current slide

Slide 1

Slide 1 text

1 © 2021 eureka, Inc. All Rights Reserved. CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy All Hands Meeting PairsにおけるSLI/SLO再定義   SRE Lounge #13  2021/11/19    © 2021 eureka, Inc. All Rights Reserved.

Slide 2

Slide 2 text

© 2021 eureka, Inc. All Rights Reserved. Takumi Ogawa (twitter: @_ogady_) - 株式会社エウレカ  - SREチーム  - SRE Lounge/SRE NEXT運営  - 守備範囲  - インフラ構築〜監視運用、セキュリティ対応、必要に応じてプログラムの修正やパフォーマンス最適化etc..  - 最近は趣味で絵を書いてます  About Me

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

© 2021 eureka, Inc. All Rights Reserved. 6 恋活・婚活マッチングアプリオンライン結婚相談所サービス真剣な交際・結婚を望むすべての人向け 1年以内の結婚を望むすべての人向け Pairsは日本で最も使われている恋活・婚活マッチングアプリ日本人特有の交際相手探し、恋愛に対する障壁を和らげるために設計 24時間365日オペレーターが待機し公的身分証明書の確認、お問い合わせ、パトロール監視に対応登録からお相手の紹介まで全てスマホで利用可能プロのコンシェルジュチームによる24時間サポート毎月20名(紹介10名+検索10名)のお相手候補出典：MMD研究所xスマートアンサー「2020年マッチングサービス・アプリの利⽤実態調査」より  

Slide 7

Slide 7 text

Slide 8

Slide 8 text

© 2021 eureka, Inc. All Rights Reserved. SLI/SLOとは（おさらい）  - SLO（サービスレベル目標）  - サービス信頼性/可用性の数値目標  - SLI（サービスレベル指標）  - サービスの動作を直接測定した指標、数値  - エラーバジェット  - SLOをベースにした損失可能な信頼性  - SLOを割らない限り、ユーザーに対して信頼性が担保できているとする 

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© 2021 eureka, Inc. All Rights Reserved. 従来のSLI/SLO  達成はされているが、以下のような事実があった。  - 意味合いとしてはほぼ外形監視レベルでしかない  - 重要なエラーが発生している場合などのアラート基準にはなりえない  - 開発チームとの強い合意形成や重要性のすり合わせがあって決められている訳ではない  - 高品質とはどこまでなのか？  - 開発チームとしてもどこまでやるのか？  - SLO達成時でも顧客が一部重要機能を使えない事は普通に発生していた      ユーザーハピネスを図る指標としてSLOが機能していなかった 

Slide 12

Slide 12 text

© 2021 eureka, Inc. All Rights Reserved. SLOを設定することの意義を再確認する  SLO設定の意義は  ユーザーハピネスに紐づいているリアルな指標を得ることで、  - 顧客がサービスに満足しているかを測定し、判断軸や議論に役立てる事  - 高品質という終わりのない世界と適切に向き合う為の境界線を引く事で不要・過剰な消耗を避ける  その前提として、  「設定したSLOが満たされている = ユーザーが満足に使えている状態である」  これが担保されていないと、そもそもエラーバジェットの運用以前の話     

Slide 13

Slide 13 text

© 2021 eureka, Inc. All Rights Reserved. SLI/SLO再定義  適切なSLI/SLOとは  - SLOはユーザーハピネスに重点を置いた指標  - つまり、ユーザーの中心的なアクションという観点からSLOを作成する必要がある      顧客の体験を補足するには、クリティカルユーザージャーニーを利用できます。クリティカルユーザージャーニーは、あるユーザーの体験の中核部分となるタスクの並びで、サービスのきわめて重要な側面です。  (引用: サイトリライアビリティワークブック)

Slide 14

Slide 14 text

© 2021 eureka, Inc. All Rights Reserved. SLI/SLO再定義  Pairsにおける新しいSLI/SLO  - SLOを形成するSLIは以下の要素を含む  - サービスにおけるユーザーの重要な操作の成功率 = クリティカルユーザージャーニーをベースにしたSLI  - 指標の悪化がサービス満足度に影響しやすい物  - サービス停止時に影響が計上される  - SRE/Backend双方が重要と判断するものであり、共同で改善作業をする事に合意形成ができるもの     

Slide 15

Slide 15 text

© 2021 eureka, Inc. All Rights Reserved. SLI/SLO再定義  - SLI: 重要操作に紐づくAPIのリクエスト成功率（not 5XX率）  - ログイン  - 新規登録  - いいね  - メッセージの送受信  - さがす  - 足跡をつける/見る  - 課金関連  - SLO: 99.95%（window:1ヶ月）  - これまでの総リクエストベースのSLOが達成してきた実績値で設定  - [Optional] Burn Rate（後述）     

Slide 16

Slide 16 text

© 2021 eureka, Inc. All Rights Reserved. 実装案  1. ALBログを活用する方法  - ALBログ出力が5分リアルタイム性に欠ける  - データパイプライン組まないといけない → あまり面倒見たくない＆コストがかかる  2. ログをサンプル抽出する方法  - 全体数のサンプルにしてしまうと監視対象の重要操作APIアクセスの母数がかなり減ってしまい、標本誤差ベースで信頼性が低下してしまう  3. Cloud Loggingに出力しているrequest_logから重要操作毎のAPIアクセスを集計する方法  - 監視対象の重要操作APIアクセス全量を集計対象にできるため指標の信頼性を担保できる  SLI/SLO実装 

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

© 2021 eureka, Inc. All Rights Reserved. SLI/SLO実装  Burn Rate Alertsの設定  - Burn Rateとは  - SLOに対して相対的にエラーバジェットをどれだけの速度で消費しているかの傾きを示す  - Burn Rate Alertsを設定することで、継続的なエラーバジェット消費に気づける  - SLOの閾値アラートがなった時にはもう信頼性は損なわれている  - アラートは複数ウィンドウ & 複数BurnRateに対して設定するのが推奨される  (引用: サイトリライアビリティワークブック)  

Slide 20

Slide 20 text

© 2021 eureka, Inc. All Rights Reserved. SLI/SLO実装  PairsのDatadog Burn Rate Alertsの設定（一部）  resource "datadog_monitor" "burn_rate_1h" { name = "[${var.service} ${var.region} ${var.operation}] slo(5xx) burn rate alert(1h window)" type = "slo alert" message = < ``` ## 概要 - ${var.service} ${var.region} ${var.operation} availability SLO(5xx) Burn Rateが上昇しており、このままだと SLO budgetが枯渇する可能性があります - budgetを消費しきらないように調査 /チューニングしてください ``` **[インシデントチケットを切る ](${var.jira["incident_ticket"]})** [JP Health Check Dashboard](${var.datadog_dashboard["jp_healthcheck"]}) / [JP Error Log](${var.datadog_logs_saved_views["pairs_jp_main_err"]}) [TW Health Check Dashboard](${var.datadog_dashboard["tw_healthcheck"]}) / [TW Error Log](${var.datadog_logs_saved_views["pairs_tw_main_err"]}) [KR Health Check Dashboard](${var.datadog_dashboard["kr_healthcheck"]}) / [KR Error Log](${var.datadog_logs_saved_views["pairs_kr_main_err"]}) {{/is_alert}} {{#is_recovery}} ${var.service} ${var.region} ${var.operation} availability SLO(5xx) burn rate alert recovery {{/is_recovery}} @slack-pairs-infra-critical EOF query = "burn_rate(\"${datadog_service_level_objective.availability.id}\").over(\"30d\").long_window(\"1h\").short_window(\"5m\") > 14.4" thresholds = { critical = 14.4 } renotify_interval = 5 notify_no_data = false include_tags = false } 1時間もしくは5分間の間にBurnRateが14.4 以上かどうかを閾値に設定 

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

© 2021 eureka, Inc. All Rights Reserved. 実運用に乗せてみた  こういうことがしたかった  - この指標をベースにSRE/Backendチーム間で意思決定を行えるようにしたい  - 重要操作のSLOに問題がないかをSRE/Backendチームでモニタリングしたい  - 重要操作のフィルターが適切かを定期的にレビューし、SLIの信頼性を担保したい  週次でやってる、SRE/Backend共有会をSLOについてメインに話す会に変更     

Slide 25

Slide 25 text

© 2021 eureka, Inc. All Rights Reserved. 実運用に乗せてみた  SRE/Backend共有会では、、、  - SRE/Backend共有会では作成したSLOダッシュボードを見る  - エラーバジェットが消費されている場合は根本原因追求および対応の義務が発生し、SRE/Backendチーム合意の上で以下対応を実施する  - 5XXを出している操作はどれか確認  - 5XXである≒アプリケーションエラーが出ているはずなので確認  - エラーが出ておらず、その他特に問題なさそうな場合は、そもそもSLOの計測値が適切かを調査  - 見つかった問題の修正対応/根本原因解決をSRE/Backendチーム合意の上でNextとして起票、対応     

Slide 26

Slide 26 text

© 2021 eureka, Inc. All Rights Reserved. 2ヶ月ほどの運用の中で得られた知見  - 重要操作SLI/SLOのAPIの各メソッドが全て1メトリクスにまとまっていた  - 流量の少ないAPIエラーが埋もれてしまい、特定機能が使えていないが信頼性は問題なしと見えてしまう  - 例えば、メッセージを見ることはできているが送ることができてないなど  　 → 流量や性質も全然違うものなのでHTTPメソッド別にみた方が良い  - 今回はコスト観点でアプリケーションのミドルウェアから出しているrequest_logを使ってSLIを計測していた  - 「API側で5XXで返していても、Nginxでは499(クライアントから切断)で返却している」という事象が発生すると偽陽性が上がる  　 → ユーザーに近いところで観測する重要性を再確認  実運用に乗せてみた     

Slide 27

Slide 27 text

© 2021 eureka, Inc. All Rights Reserved. よかったこと  - ユーザーがPairsを使う上で基本となる操作ごとにSLI/SLOを定義することで、具体的にどの操作の信頼性が損失されているかを観測できるようになった  - SLOアラートも、実際に影響が出ているユーザー操作に紐づくアラートになった  - Backendチームと共通の重要指標として合意できたため、「エラーバジェットが消費されている = 信頼性が低下してる」という共通認識のもとでNextを議論できるようになった 

Slide 28

Slide 28 text

© 2021 eureka, Inc. All Rights Reserved. 今後の展望      - 運用は始まったばかりなので、SLI/SLOを育てて知見を溜めていく  - そもそも継続して見直していくことが求められる指標  - よりユーザー操作の実態を示すSLIとして、クライアントからの操作ログを新設したい  - クライアント側からSDKでDatadogにカスタムメトリクスを送る etc…  - API成功率だけでは、クリティカルユーザージャーニーの信頼性を正確に測れない  - これが達成されるとクライアントチームも巻き込んで信頼性の話ができる  - 開発チーム主体で、SLI/SLOの運用を自立的にできるようにしたい  - SLI/SLOが、現実化されている指標（CCチームの不具合問い合わせ数など）と相関しているかを見えるようにしたい  - SLI/SLOがユーザーハピネスを数値化できているか、を確認するため 