PairsにおけるSLI/SLO再定義

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 
 

View Slide

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

View Slide

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

View Slide

Mission
人生に「あってよかった」と思ってもらえるものを。 
To provide a life-changing service that people will remember with great fondness.

View Slide

Vision
かけがえのない人との出会いを生み出し、 
日本、アジアにデーティングサービス 
文化を定着させる。 
To help people ﬁnd their life partner
and make dating services a social norm in Japan and Asia.

View Slide

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

View Slide

ここから本題 
 
~ PairsのSLI/SLOを再定義、運用した話 ~ 

View Slide

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

View Slide

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

View Slide

従来のSLI/SLO 
何が問題だったのか 
 
 

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

SLI/SLO実装 
SLI/SLOのメトリクス収集方法 

View Slide

SLI/SLO実装 
SLOダッシュボード 

View Slide

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

View Slide

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 = <{{#is_alert}}

```
## 概要
- ${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
以上かどうかを閾値に設定 

View Slide

SLI/SLO実装 
SLI/SLO再定義完了！！ 

View Slide

SLI/SLO実装 
SLI/SLO再定義完了！！ 
運用に乗せることで初めて意味がある 
 
 

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

We’re hiring!
エウレカではエンジニアを積極採用中！ 
カジュアル面談もお待ちしております！ 

View Slide

30

View Slide

PairsにおけるSLI/SLO再定義

PairsにおけるSLI/SLO再定義

ogady

More Decks by ogady

Other Decks in Technology

Featured

Transcript