Upgrade to Pro — share decks privately, control downloads, hide ads and more …

PairsにおけるSLI/SLO再定義

ogady
November 19, 2021

 PairsにおけるSLI/SLO再定義

ogady

November 19, 2021
Tweet

More Decks by ogady

Other Decks in Technology

Transcript

  1. 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.
  2. © 2021 eureka, Inc. All Rights Reserved. Takumi Ogawa (twitter:

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


    - PairsのSLI/SLOを再定義、運用した話
 - 従来のSLI/SLOがどうなっていたか
 - SLOの役割を改めて確認する
 - SLI/SLO再定義
 - SLI/SLO実装
 - 実運用にのせてみて
 - よかったこと
 - 今後の展望

  4. © 2021 eureka, Inc. All Rights Reserved. Vision かけがえのない人との出会いを生み出し、
 日本、アジアにデーティングサービス


    文化を定着させる。
 To help people find their life partner and make dating services a social norm in Japan and Asia.
  5. © 2021 eureka, Inc. All Rights Reserved. 6 恋活・婚活マッチングアプリ オンライン結婚相談所サービス

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

  6. © 2021 eureka, Inc. All Rights Reserved. ここから本題
 
 ~

    PairsのSLI/SLOを再定義、運用した話 ~

  7. © 2021 eureka, Inc. All Rights Reserved. SLI/SLOとは(おさらい)
 - SLO(サービスレベル目標)


    - サービス信頼性/可用性の数値目標
 - SLI(サービスレベル指標)
 - サービスの動作を直接測定した指標、数値
 - エラーバジェット
 - SLOをベースにした損失可能な信頼性
 - SLOを割らない限り、ユーザーに対して信頼性が担保できているとする

  8. © 2021 eureka, Inc. All Rights Reserved. - SLI
 -

    ALBのメトリクスで (総リクエスト数- 5XX数)/総リクエスト を計測
 - ≒ 総リクエストのうち正常に返却できた割合を計測
 - SLO
 - 99.95%(window:1ヶ月)
 - ここ最近はずっと達成していた
 従来のSLI/SLO

  9. © 2021 eureka, Inc. All Rights Reserved. 従来のSLI/SLO
 達成はされているが、以下のような事実があった。
 -

    意味合いとしてはほぼ外形監視レベルでしかない
 - 重要なエラーが発生している場合などのアラート基準にはなりえない
 - 開発チームとの強い合意形成や重要性のすり合わせがあって決められている訳ではない
 - 高品質とはどこまでなのか?
 - 開発チームとしてもどこまでやるのか?
 - SLO達成時でも顧客が一部重要機能を使えない事は普通に発生していた
 
 
 ユーザーハピネスを図る指標としてSLOが機能していなかった

  10. © 2021 eureka, Inc. All Rights Reserved. SLOを設定することの意義を再確認する
 SLO設定の意義は
 ユーザーハピネスに紐づいているリアルな指標を得ることで、


    - 顧客がサービスに満足しているかを測定し、判断軸や議論に役立てる事
 - 高品質という終わりのない世界と適切に向き合う為の境界線を引く事で不要・過剰な消耗を避ける
 その前提として、
 「設定したSLOが満たされている = ユーザーが満足に使えている状態である」
 これが担保されていないと、そもそもエラーバジェットの運用以前の話
 
 

  11. © 2021 eureka, Inc. All Rights Reserved. SLI/SLO再定義
 適切なSLI/SLOとは
 -

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

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

  13. © 2021 eureka, Inc. All Rights Reserved. SLI/SLO再定義
 - SLI:

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

  14. © 2021 eureka, Inc. All Rights Reserved. 実装案
 1. ALBログを活用する方法


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

  15. © 2021 eureka, Inc. All Rights Reserved. SLI/SLO実装
 Burn Rate

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

  16. © 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 = <<EOF {{#is_alert}} <!channel> ``` ## 概要 - ${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}} <!channel> ${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 以上かどうかを閾値に設定

  17. © 2021 eureka, Inc. All Rights Reserved. 実運用に乗せてみた
 こういうことがしたかった
 -

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

  18. © 2021 eureka, Inc. All Rights Reserved. 実運用に乗せてみた
 SRE/Backend共有会では、、、
 -

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

  19. © 2021 eureka, Inc. All Rights Reserved. 2ヶ月ほどの運用の中で得られた知見
 - 重要操作SLI/SLOのAPIの各メソッドが全て1メトリクスにまとまっていた


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

  20. © 2021 eureka, Inc. All Rights Reserved. よかったこと
 - ユーザーがPairsを使う上で基本となる操作ごとにSLI/SLOを定義することで、具体的にどの操作の信頼性が損失されているかを観

    測できるようになった
 - SLOアラートも、実際に影響が出ているユーザー操作に紐づくアラートになった
 - Backendチームと共通の重要指標として合意できたため、「エラーバジェットが消費されている = 信頼性が低下してる」という共通認識 のもとでNextを議論できるようになった

  21. © 2021 eureka, Inc. All Rights Reserved. 今後の展望
 
 


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