Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
SLI/SLO をストリーム アラインドチームに導入した話
Search
Tsukasa OISHI
March 10, 2023
Technology
220
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
SLI/SLO をストリーム アラインドチームに導入した話
Tsukasa OISHI
March 10, 2023
More Decks by Tsukasa OISHI
See All by Tsukasa OISHI
怖くないメモリ肥大化
tsukasa_oishi
1
120
JITをたどるとそこはYARVの中
tsukasa_oishi
0
590
The Cacher in the Rye
tsukasa_oishi
1
6k
ISeqで遊ぼう
tsukasa_oishi
0
5.3k
Rubyを30倍速くした話
tsukasa_oishi
0
1.3k
はてブ砲をくらったときのお話
tsukasa_oishi
0
2.3k
食べログで動いている自作ライブラリのお話
tsukasa_oishi
0
330
奥さんとプログラミングを両立させる方法
tsukasa_oishi
0
120
MiyazakiResistanceを作ってみたよ
tsukasa_oishi
0
1.1k
Other Decks in Technology
See All in Technology
Issue 駆動でスペシャリストの意図を届ける、AI 実装のアクセシビリティ向上
thkt
0
110
負債のメタファと2026年 / Debt Metaphor in Agentic Engineering Age 202609 Edition
twada
PRO
8
3.4k
LTのテーマ どうきめてる?〜5つの型と私のやり方〜
yama3133
1
110
「ピッケル本」日本語版は4.0(第6版)が出版されるべき / pickaxe4-nagoyark05
kakutani
1
150
研究開発部の紹介 / Sansan R&D Profile
sansan33
PRO
5
25k
株式会社シーエーシー エンジニア向け会社紹介資料
cac
0
57k
AI時代の「技術的負債」の変質ー概念の終焉と再解釈、エージェントと共に向かう先
nwiizo
0
2.7k
AI に書かせたその API、 “信頼” できますか?
nagix
0
110
What the customer really needed
kawaguti
PRO
3
190
AIによるクリエイティブ生成を行う上での試行錯誤
plaidtech
PRO
0
150
10分で知る最近のOmarchy
komagata
0
350
ADKで始める業務改善 - AIエージェント開発時の考えと設計
harappa80
2
150
Featured
See All Featured
Navigating Algorithm Shifts & AI Overviews - #SMXNext
aleyda
1
1.6k
Documentation Writing (for coders)
carmenintech
77
5.5k
HU Berlin: Industrial-Strength Natural Language Processing with spaCy and Prodigy
inesmontani
PRO
0
700
Efficient Content Optimization with Google Search Console & Apps Script
katarinadahlin
PRO
1
850
Site-Speed That Sticks
csswizardry
13
1.5k
Exploring anti-patterns in Rails
aemeredith
4
510
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
128
56k
Optimising Largest Contentful Paint
csswizardry
37
4k
How to train your dragon (web standard)
notwaldorf
97
6.8k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
56
3.5k
We Have a Design System, Now What?
morganepeng
55
8.3k
Tips & Tricks on How to Get Your First Job In Tech
honzajavorek
1
740
Transcript
SLI/SLO をストリーム アラインドチー ムに導入した話 2023-03-09
スピーカー紹介 2022 年 6 月 Ubie株式会社 Ubie Discovery 入社。 プロダクト開発エンジニアとして病院・クリニック向けのプロダクト
「ユビー AI 問診」の開発・運用や、 Ubie のシステムアーキテク チャを生産性の面から改善していく業務に携わっている。 Twitter: @tsukasa_oishi GitHub: @tsukasaoishi おおいしつかさ Ubie株式会社
テクノロジーで人々を適切な医療に案内する
なぜストリーム アラインドチームに SLO が必要になっ たか? 何を計測するべきか、クリティカル ユーザージャーニー から導き出す SLI と
SLO を決める どのようにして SLI を計測し、可視化したか 01 03 02 04
なぜストリーム アラインドチー ムに SLO が必要に なったか? 01
None
None
変更容易性の低下 責務がわかりにくい 個人による活動の限界
ストリーム アラインドチームの誕生
Place Image Here 運用タスクの増加
SLI/SLO
なにを計測するべきか クリティカル ユーザージャー ニーから導き出す 02
SLI をどう決めたらいいんだろう?
None
ユーザー ジャーニー全体 の時間や完走率を計測し たが失敗した • ユーザー ジャーニー全体の時間は、ユーザーによっ てばらつきが大きく、 SLO を決定しにくい
• 完走率も時間帯によってばらつきが大きい • 完走率が低い = 信頼性が低下しているとは言えない
ユーザーが価値を得るための 一連の体験の中で、もっとも重 要なアクションを SLI にする
SLI と SLO を決める 03
ユーザーに提供している価値が毀損していること を、何をもって表せるか?
そのアクションによる結果が正しい挙動で稼働 し続けていること。 これが保てなければ価値を提供できているこ とにはならない。 そのアクションによる結果が想定の範囲内の 時間で価値を提供できていること。 正しい挙動で稼働し続けられても、時間がか かっていたら意味がない。 SLI 可用性
レイテンシ
サービス A サービス B サービス C サービス D サービス E
サービス F どこで計測するのか
サービス A サービス B サービス C サービス D サービス E
サービス F どこで計測するのか
サービス A サービス B サービス C サービス D サービス E
サービス F どこで計測するのか
クライアント サイドでの レンダリングの 計測を 検討したが採用しなかっ た • ユーザーの価値を毀損しているかどうかの要因となる のは、レンダリングよりも API
コールだった • レイテンシの大部分は API コールが占める • API コールの成否が可用性に大きく影響する
サービス A サービス B サービス C サービス D サービス E
サービス F どこで計測するのか
SLO を決める
サービス全体を見ている PO なども交えて議論
まずは緩めの値で開始し、運用しながら適正 な値に近づけていくことに
どのようにして SLI を 計測し、可視化したか 04
ログ受付 prometheus exporter Pub/Sub Monitoring grafana BigQuery
ログ受付 prometheus exporter Pub/Sub Monitoring grafana BigQuery API コールを計測。 ある程度バッファリング
してから送信
ログ受付 prometheus exporter Pub/Sub Monitoring grafana BigQuery Go で実装した prometheus
exporter
ログ受付 prometheus exporter Pub/Sub Monitoring grafana BigQuery PodMonitoring リソースを定義 しておくことで
GMP がメトリクス を取りに来てくれる
Google Cloud Managed Service for Prometheus(GMP)は terraform で設 定している Terraform
resource “google_monitoring_slo” “ubie_a_team_latency” { service = google_monitoring_cs.ubie_a_team.service_id project = local.project_id display_name = “monthly ubie a team latency p95 < ??ms” slo_id = “ubie-a-team-latency” goal = 0.95 calendar_period = “MONTH” request_based_cli { distribution_cut { Distribution_filter = “metrics.type=...” range { min = 0 max = ?? } } } }
Grafanaで可視化
まとめ
開発と運用のリソース配分のひとつの指標と して SLI/SLO を利用しました。 SLI をどうやって決めるのか、悩んでいるとこ ろも多いと思うので参考にしていただけたら幸 いです。
Thank you. Proprietary + Confidential