スマートロック開発におけるSLI/SLOを用いた解錠体験の改善 / Improving the unlocking experience using SLI/SLO in smart lock development

Copyright © 2024 Bitkey Inc. All right reserved. スマートロック開発におけるSLI/SLOを用いた解錠体験の改善株式会社ビットキー　三河内
拓也 2024.06.03

2 Copyright © 2024 Bitkey Inc. All right reserved. Outline
1. 自己紹介 2. サービス紹介 3. 今回のテーマ 4. サービスレベル定義 5. サービスレベル計測 6. サービスレベルの改善と運用 7. まとめと今後の展望

3 Copyright © 2024 Bitkey Inc. All right reserved. 1.
自己紹介

自己紹介三河内拓也 Takuya Mikouchi 2017 2020 データコンサル企業でデータアナリストとしてのキャリアをスタート。様々な業界のデータ活用プロジェクトに従事ビットキーにジョインデータエンジニア・データアナリストとして、データ分析基盤の構築からデータ活用まで一貫して担当最初のミッションは「プロダクト品質の定量化」ここで初めて「SLI・SLO」の世界に触れる 2023 SREチームに兼務「SLI・SLO」の運用をSREのメンバと共に推進 Datadog RUMが好きです

サービス紹介

設立　　：2018年5月　拠点　　：東京・大阪・福岡・宮崎従業員数：約230名

サービス紹介 homehubは「暮らし」に関わる様々な体験を実現する。その中心にあるのがスマートロック

10 Copyright © 2024 Bitkey Inc. All right reserved. workhubは「働く空間」と「働くひとや業務」をつなぎ、快適な仕事を実現する。こちらも多くの体験の中心にスマートロックがある
2. サービス紹介

サービス紹介弊社が製造開発したスマートロックだけでなく、チップを組み込んだ製品なども扱ってます。BLE通信で解錠するケースがほぼほぼ ▪HW製品群スマホで解錠テンキー・NFC リモコンゲートウェイこの他にも色々あるよ！

今回のテーマ

13 Copyright © 2024 Bitkey Inc. All right reserved. homehub/workhubはスマートロックを中心に、様々な体験を実現しているので、スマートロックの解錠体験の品質を高めることがサービスの満
足度に直結します 3. 今回のテーマ

14 Copyright © 2024 Bitkey Inc. All right reserved. ビットキーでは、品質の定量化と改善のために、SREのプラクティスであるサービスレベルを用いています
3. 今回のテーマ ▪（補足）サービスレベルとは？サービスレベル指標：SLI ・サービス品質を数値または指標として表すもの・ユーザ視点で測定され、ユーザにとってサービスが期待通りに機能しているかどうかを示す指標例：GCSの可用性、成功率、レイテンシサービスレベル目標：SLO ・SLIに対する目標例：GCSの可用性はStandard ストレージ、シングルリージョンで99.9% サービスレベル契約：SLA ・サービス提供対象との合意 ref：https://cloud.google.com/blog/ja/products/devops-sre/sre-fundamentals-sli-vs-slo-vs-sla

15 Copyright © 2024 Bitkey Inc. All right reserved. 今回はスマートロックの解錠体験（特にBluetooth通信での解錠の成功率）における、サービスレベルの定義〜計測〜運用までをビットキーでは
どう進めていったかを主に話をします 3. 今回のテーマサービスレベル指標：SLI ・サービス品質を数値または指標として表すもの・ユーザ視点で測定され、ユーザにとってサービスが期待通りに機能しているかどうかを示す指標例：GCSの可用性、成功率、レイテンシサービスレベル目標：SLO ・SLIに対する目標例：GCSの可用性はStandard ストレージ、シングルリージョンで99.9% ×

16 Copyright © 2024 Bitkey Inc. All right reserved. スマートロックの解錠体験をサービスレベルの世界で扱う上で難しいのが、現実世界が関わってきていること・・・
これについてどんな悩みがあったか、どうアクションしたかも交えながら、お話していきます 3. 今回のテーマ ▪悩みポイントを先に紹介しておくと 😨「目の前にスマートロックがないのに、解錠コマンドを実行する」、「運用上電池をわざと抜いている」みたいな物理的に絶対に失敗するケースってどう扱う？ 😨色々考慮した結果、計測ロジックが複雑になりがちだけど、 Datadogじゃ計測しづらくない？？？ 😨「本来かざすべき QRコードとは別の QR コードをかざして解錠が失敗した」みたいなユーザの現実世界の行動が起因した失敗ケースはどう扱う？

17 Copyright © 2024 Bitkey Inc. All right reserved. 今回話さないこと
• Software的にこういう実装をしたら解錠成功率が改善しました • Hardware的にこういう設計・製造の見直しをしたら改善しました • Hardware製品の品質保証周りのあれこれ → 今回話すのは、改善に寄与したサービスレベルの定義〜計測〜運用の一連のプロセスを実行していった話を順番に伝えていきます 3. 今回のテーマ

サービスレベル定義

サービスレベル定義ビットキーがサービスレベルの対象にしている体験の紹介（抜粋） ※今回言及しませんが他にも様々な解錠体験、ユーザにおいて重要な解錠以外の体験を定義・計測していますアプリによる解錠（homehub）・マンションの自分の部屋やエントランスの出入り顔認証（workhub）・大型ビルのエントランス、フラッパーゲート（パタパタするあれ）出入り・オフィスの入口、オフィス内の各部屋やブースの出入り QR認証（workhub）・大型ビルのエントランス、フラッパーゲート（パタパタするあれ）出入り

サービスレベル定義サービスレベルの対象にする体験をどのように決めたか本来は例えば、マンションの入居体験のようなユーザ体験をジャーニーにし、その中の重要な各体験を指標にする（ref. CUJ）今回は解錠にピンが止まってたので、あらゆる解錠体験を洗い出した上で現在の利用頻度から決めたビジネス的な重要度、プロダクトの関心度から判断して対象にすることもありました将来予想される利用頻度から決めることもある

サービスレベル定義各体験からサービスレベル指標にどう落とし込んだか・定義したか ①関係者を集める（SRE・Software Enginner・Firmware Engineer・PdM…） ②その指標を計測する背景と目的を認識合わせしておく ③対象の体験を分解したフロー図をみんなで作成 ④フロー図内の試行・成功イベントから算出式に落とし込む（レイテンシなら計測範囲）

サービスレベル定義ここから定義フェーズのポイントを紹介します 3つあります

サービスレベル定義ポイント①：指標を計測する背景と目的を認識合わせは必ず ①関係者を集める（SRE・Software Enginner・Firmware Engineer・PdM…） ②その指標を計測する背景と目的を認識合わせしておく ③対象の体験を分解したフロー図をみんなで作成 ④フロー図内の試行・成功イベントから算出式に落とし込む（レイテンシなら計測範囲） 💡後々指標を定義していくときに発生する悩みポイントの解決に効いてくるので必ずやる!!!

サービスレベル定義ポイント②：定義は割り切りが大事 ※本当はもっと細かい・・・ 😨「目の前にスマートロックがないのに、解錠コマンドを実行する」みたいな物理的に絶対に失敗するケースってどう扱う？

サービスレベル定義ポイント②：定義は割り切りが大事 ※本当はもっと細かい・・・ 😨「目の前にスマートロックがないのに、解錠コマンドを実行する」みたいな物理的に絶対に失敗するケースってどう扱う？・この場合は、真に失敗してるかログ上判別ができない and ユーザ体験上レアケースでSLIにそれほど寄与しないと判断し、考慮しないことに決定

サービスレベル定義ポイント②：定義は割り切りが大事 ※本当はもっと細かい・・・ 😨「目の前にスマートロックがないのに、解錠コマンドを実行する」みたいな物理的に絶対に失敗するケースってどう扱う？・この場合は、真に失敗してるかログ上判別ができない and ユーザ体験上レアケースでSLIにそれほど寄与しないと判断し、考慮しないことに決定 ↓ 💡ポイント：一定の割り切りが大事。これは集計クエリのロジックやトラッキングする情報自体を単純化することにも繋がり、今後のSLI運用の容易さにも寄与する ※ただしSLOでは一定の失敗があることの考慮が必要

サービスレベル定義ポイント③：何を意思決定したくて計測したい指標なのかから定義を決めていく 😨「本来かざすべきQRコードとは別の QRコードをかざして解錠が失敗した」みたいなユーザの現実世界の行動が起因した失敗ケースはどう扱う？ ※理解のために、実際の処理とは異なる表現をしている部分が多々あります

28 Copyright © 2024 Bitkey Inc. All right reserved. ・この場合は、解錠精度だけでなく、QR認証体験全体を評価
したかったので、ユーザの勘違いも我々の製品の落ち度と捉え失敗イベントに分類した 4. サービスレベル定義ポイント③：何を意思決定したくて計測したい指標なのかから定義を決めていく 😨「本来かざすべきQRコードとは別の QRコードをかざして解錠が失敗した」みたいなユーザの現実世界の行動が起因した失敗ケースはどう扱う？ ※理解のために、実際の処理とは異なる表現をしている部分が多々あります

サービスレベル定義ポイント③：何を意思決定したくて計測したい指標なのかから定義を決めていく 😨「本来かざすべきQRコードとは別の QRコードをかざして解錠が失敗した」みたいなユーザの現実世界の行動が起因した失敗ケースはどう扱う？ ※理解のために、実際の処理とは異なる表現をしている部分が多々あります・この場合は、解錠精度だけでなく、QR認証体験全体を評価したかったので、ユーザの勘違いも我々の製品の落ち度と捉え失敗イベントに分類した ↓ 💡ポイント：ステップ②で計測目的を認識合わせておくと、定義を迷うポイントで柔軟な判断が可能 →要は計測目的に照らし合わせたときに、厳密な定義が必要か必要でないか判断できるということ

サービスレベル定義このステップを踏んでいくと、サービスレベル指標の定義が決まるアプリによる解錠成功率（homehub）・解錠ボタンを押した → 解錠が成功した・ドアの前に居るか居ないかは考慮しない顔認証成功率（workhub）・登録されている顔をかざした → 解錠が成功した・顔をうまくかざせてるかは考慮しない QR認証成功率（workhub）・QRコードをかざした→解錠が成功した・workhubが発行した解錠以外の用途のQRコードがかざされた場合は失敗とするが、利用可能時間外にQRコードをかざした場合は成功とする

サービスレベル計測

サービスレベル計測サービスレベル計測のためのアーキテクチャ

33 Copyright © 2024 Bitkey Inc. All right reserved. ここから計測フェーズのポイントを紹介します
4つあります 5. サービスレベル計測

サービスレベル計測まず気になるのはBigQuery

サービスレベル計測 💡 以下のようなケースに対して、複雑な集計をしたいのでBigQueryを採用している 😨「運用上電池をわざと抜いている」みたいなスマートロックは計測対象外にしたい！！！ 😨「処理上リトライしているので最後に成功してればOK」にしたいからsessionIdごとに判定したい！！！ ※ログ設計と実装をめっちゃ頑張ればできるかもしれないが・・・

サービスレベル計測（余談）GrafanaはBigQueryにクエリ投げれる（Datadogにも欲しい・・・Snowﬂakeにはクエリ投げられるらしい） https://grafana.com/grafana/plugins/grafana-bigquery-d atasource/

サービスレベル計測 💡 リアルタイムに品質を監視するという需要もあるため、Datadogでも並行して計測リアルタイムに品質を監視するという需要もあるため、 Datadogでも並行して計測を行っている。 ※Datadogはログ量で課金されるため、節約のため基本 Errorログしか連携してないが、サービスレベルの計測のためのログのみError以外も連携している

サービスレベル計測 💡 クエリがカオスになりがちなので、Airﬂowやdbtのようなツールで管理するのがおすすめ BigQueryなどのDHW製品で計測していくとクエリが増えていき、カオスになるのでワークフローを管理できる製品も合わせて使うといいです（例：Airﬂow, dbt←おすすめ）

サービスレベル計測 💡 コア体験だけでなく広くプロダクトの品質を監視しておくことも重要だと再認識した各バックエンドへのリクエストの成功率やレイテンシをここで監視 →フロー図では考慮できてなかったケースの不具合を検知できる場合があったりする

サービスレベルの改善と運用

41 Copyright © 2024 Bitkey Inc. All right reserved. ここでは運用方法というより、ポイントのみ語ります
6. サービスレベルの改善と運用

サービスレベルの改善と運用市場リリース前と後、それぞれで運用のポイントを紹介していきますリリース前リリース後

サービスレベルの改善と運用市場リリース前では、アプリ（バージョンアップ含め）やプロダクトのSLIを確認していたりするリリース前リリース後 • 😨QAには力入れてるけど、ユーザ相当の利用環境はまた別なんだよね・・・

サービスレベルの改善と運用市場リリース前では、アプリ（バージョンアップ含め）やプロダクトのSLIを確認していたりするリリース前リリース後 • 😨QAには力入れてるけど、ユーザ相当の利用環境はまた別なんだよね・・・ ◦ 💡社員や自社オフィスにTestﬂightなどで、リリース予定バージョンを配布し、成功率をモニタリングしている

サービスレベルの改善と運用市場リリース前では、アプリ（バージョンアップ含め）やプロダクトのSLIを確認していたりするリリース前リリース後 • 😨QAには力入れてるけど、ユーザ相当の利用環境はまた別なんだよね・・・ ◦ 💡社員や自社オフィスにTestﬂightなどで、リリース予定バージョンを配布し、成功率をモニタリングしている ◦ 💡その際、物理的な環境（ドアの材質など）が成功率に影響を与えるので、比較する際は検証対象のスマートロックやメンバを適切に選定する必要がある ↑ SLO本に統計学の章があるのも納得！

サービスレベルの改善と運用市場リリース後は、監視自体はSREが主体的に行ってます。また定期的に開発者と数値を眺める場の設計において工夫ポイントがありますリリース前リリース後 • 😨QAには力入れてるけど、ユーザ相当の利用環境はまた別なんだよね・・・ ◦ 💡社員や自社オフィスにTestﬂightなどで、リリース予定バージョンを配布し、成功率をモニタリングしている ◦ 💡その際、物理的な環境（ドアの材質など）が成功率に影響を与えるので、比較する際は検証対象のスマートロックやメンバを適切に選定する必要がある ↑ SLO本に統計学の章があるのも納得！ • 😨SREで頑張ってダッシュボード作ったけど、開発者が見てくれないんだよね・・・ ◦ プロダクトのフェーズによっては、あると思います（弊社も数年前は...）

サービスレベルの改善と運用市場リリース後は、監視自体はSREが主体的に行ってます。また定期的に開発者と数値を眺める場の設計において工夫ポイントがありますリリース前リリース後 • 😨QAには力入れてるけど、ユーザ相当の利用環境はまた別なんだよね・・・ ◦ 💡社員や自社オフィスにTestﬂightなどで、リリース予定バージョンを配布し、成功率をモニタリングしている ◦ 💡その際、物理的な環境（ドアの材質など）が成功率に影響を与えるので、比較する際は検証対象のスマートロックやメンバを適切に選定する必要がある ↑ SLO本に統計学の章があるのも納得！ • 😨SREで頑張ってダッシュボード作ったけど、開発者が見てくれないんだよね・・・ ◦ プロダクトのフェーズによっては、あると思います（弊社も数年前は...） ◦ 💡モニタリングはSREが積極的に行い、開発者にディスパッチしていく ◦ 💡 週次や隔週で数値を見る会を実施

サービスレベルの改善と運用市場リリース後は、監視自体はSREが主体的に行ってます。また定期的に開発者と数値を眺める場の設計において工夫ポイントがありますリリース前リリース後 • 😨QAには力入れてるけど、ユーザ相当の利用環境はまた別なんだよね・・・ ◦ 💡社員や自社オフィスにTestﬂightなどで、リリース予定バージョンを配布し、成功率をモニタリングしている ◦ 💡その際、物理的な環境（ドアの材質など）が成功率に影響を与えるので、比較する際は検証対象のスマートロックやメンバを適切に選定する必要がある ↑ SLO本に統計学の章があるのも納得！ • 😨SREで頑張ってダッシュボード作ったけど、開発者が見てくれないんだよね・・・ ◦ プロダクトのフェーズによっては、あると思います（弊社も数年前は...） ◦ 💡モニタリングはSREが積極的に行い、開発者にディスパッチしていく ◦ 💡 週次や隔週で数値を見る会を実施 ▪ 😨これもなんとなくファシリしづらい時があります,,,

サービスレベルの改善と運用市場リリース後は、監視自体はSREが主体的に行ってます。また定期的に開発者と数値を眺める場の設計において工夫ポイントがありますリリース前リリース後 • 😨QAには力入れてるけど、ユーザ相当の利用環境はまた別なんだよね・・・ ◦ 💡社員や自社オフィスにTestﬂightなどで、リリース予定バージョンを配布し、成功率をモニタリングしている ◦ 💡その際、物理的な環境（ドアの材質など）が成功率に影響を与えるので、比較する際は検証対象のスマートロックやメンバを適切に選定する必要がある ↑ SLO本に統計学の章があるのも納得！ • 😨SREで頑張ってダッシュボード作ったけど、開発者が見てくれないんだよね・・・ ◦ プロダクトのフェーズによっては、あると思います（弊社も数年前は...） ◦ 💡モニタリングはSREが積極的に行い、開発者にディスパッチしていく ◦ 💡 週次や隔週で数値を見る会を実施 ▪ 😨これもなんとなくファシリしづらい時があります,,, ▪ 💡 SLI/SLO以外のSREに関連する話も相談し合う時間にし、参加者のメリットを増やすようにアレンジしました • 例：インフラ構成どうしたらいいだろう？

サービスレベルの改善と運用 SLIをデータとして捉え、CSやHardwareチームへの提供したりなど、広い用途で活用しています to Hardware to Customer Support

サービスレベルの改善と運用 SLIをデータとして捉え、CSやHardwareチームへの提供したりなど、広い用途で活用しています to Hardware to Customer Support • 😨市場でどのくらいの品質を維持できているのだろうか？

サービスレベルの改善と運用 SLIをデータとして捉え、CSやHardwareチームへの提供したりなど、広い用途で活用しています to Hardware to Customer Support • 😨市場でどのくらいの品質を維持できているのだろうか？ ◦ 💡提供しちゃいましょう ◦ 💡その際、彼らの品質保証の際の条件と我々の計測条件の違いを明確にするため、フロー図と合わせて提供すると良いと思います ◦ 実際部品などが変わった際（製品自体や製造ロット）、SLIが大幅に改善したことがあります

サービスレベルの改善と運用 SLIをデータとして捉え、CSやHardwareチームへの提供したりなど、広い用途で活用しています to Hardware to Customer Support • 😨市場でどのくらいの品質を維持できているのだろうか？ ◦ 💡提供しちゃいましょう ◦ 💡その際、彼らの品質保証の際の条件と我々の計測条件の違いを明確にするため、フロー図と合わせて提供すると良いと思います ◦ 実際部品などが変わった際（製品自体や製造ロット）、SLIが大幅に改善したことがあります • 😨顧客の言う「カギが開かない・反応が遅い」の内容は様々なのでヒアリングに時間がかかるんだよね・・・

サービスレベルの改善と運用 SLIをデータとして捉え、CSやHardwareチームへの提供したりなど、広い用途で活用しています to Hardware to Customer Support • 😨市場でどのくらいの品質を維持できているのだろうか？ ◦ 💡提供しちゃいましょう ◦ 💡その際、彼らの品質保証の際の条件と我々の計測条件の違いを明確にするため、フロー図と合わせて提供すると良いと思います ◦ 実際部品などが変わった際（製品自体や製造ロット）、SLIが大幅に改善したことがあります • 😨顧客の言う「カギが開かない・反応が遅い」の内容は様々なのでヒアリングに時間がかかるんだよね・・・ • 😨問い合わせが来る前に、困っている顧客、うまく使えていない顧客を把握しサポートしたいんだよね・・・

サービスレベルの改善と運用 SLIをデータとして捉え、CSやHardwareチームへの提供したりなど、広い用途で活用しています to Hardware to Customer Support • 😨市場でどのくらいの品質を維持できているのだろうか？ ◦ 💡提供しちゃいましょう ◦ 💡その際、彼らの品質保証の際の条件と我々の計測条件の違いを明確にするため、フロー図と合わせて提供すると良いと思います ◦ 実際部品などが変わった際（製品自体や製造ロット）、SLIが大幅に改善したことがあります • 😨顧客の言う「カギが開かない・反応が遅い」の内容は様々なのでヒアリングに時間がかかるんだよね・・・ • 😨問い合わせが来る前に、困っている顧客、うまく使えていない顧客を把握しサポートしたいんだよね・・・ ◦ 💡社内システムやダッシュボードから顧客ごとのSLIを参照できるようにしてます

まとめと今後の展望

まとめと今後の展望 😨やはりSoftwareの監視とは一味違う部分もある現実世界や物理環境の状況を定義の中で考慮し、計測ロジックに落とし込むところ ※といいつつも、結局リクエストに対する成功失敗やレイテンシで表現できるって点では変わらない側面もあるが 💡そのなかでデータエンジニア・アナリストの得意なアプローチを取ることが有用 BigQueryを活用する。統計学のアプローチを改善に活かすまとめ

59 Copyright © 2024 Bitkey Inc. All right reserved. “SLOは単なるデータである”
* オライリー・ジャパン「SLO サービスレベル目標」の P15 より参照ちなみにSRE本にもこんな記載がある。（だいぶ曲解するが）IoTのような文脈では、サービスレベルを様々な形で計測・活用することが必要だと思いました（今回は”データ”にフォーカスしたが、品証の文化とかも取り入れたら良さそう） 7. まとめと今後の展望

まとめと今後の展望ちゃぶ台をひっくり返すが、、、SREのプラクティスは素晴らしく、オブザーバビリティツールも素晴らしいので、そちらに寄せていくアプローチ本日共に登壇してくださったLuupさんの提唱するCMCのような、 Hardwareのシグナルを用いたサービスレベル設計今後の展望

61 Copyright © 2024 Bitkey Inc. All right reserved. わたしたちは、ともに働く仲間を募集しております！
職種の一例としては... 1. SRE 2. Software Engineer（WEB、モバイル） 3. PdM 4. UI/UXデザイナー 5. EM … など、様々なポジションで募集中です！ご興味があれば右のQRコードまたは、 X(Twitter):@i_am_miko__ までご連絡ください！ We Are Hiring ! 7. まとめと今後の展望

スマートロック開発におけるSLI/SLOを用いた解錠体験の改善 / Improving the...

スマートロック開発におけるSLI/SLOを用いた解錠体験の改善 / Improving the unlocking experience using SLI/SLO in smart lock development

More Decks by 株式会社ビットキー / Bitkey Inc.

Other Decks in Technology

Featured

Transcript