🤖

IoTサービスでSLIを設計する時の考え方 "CMC" について

2024/06/12に公開

はじめに

LuupのSREチームに所属している、ぐりもお(@gr1m0h)です。

これまで、登壇の際に、度々CMC: Critical Machine Communication (以下、CMC) の重要性についてお話ししてきました。しかし、その説明は主に登壇時の資料や動画、ブログに留まっており、CMC自体を中心に掘り下げて説明する機会がありませんでした。

https://zenn.dev/luup_developers/articles/sre-grimoh-20230517

https://zenn.dev/luup_developers/articles/sre-grimoh-20231002

また、CMCという考え方はLuupだけでなく、他社のIoTサービスでも有用だと考えていますので、コミュニティへの貢献としてこの概念について文章に残しておきたいと思っていました。

そこで、今回はCMCをメインにしたブログを書きたいと思います。

また、この内容は IoT Expands! というイベントでお話しした内容になります。

https://bitkey.connpass.com/event/317162/

資料は以下です。

IoTサービスでSLIを設計する

LUUPを例にして、IoT領域のサービスでSLIを考えてみましょう。

以下の図はLUUPの構成を簡略化したものです。
電動キックボード、電動アシスト自転車からSORACOM Beamを経由してGoogle Cloud、AWS IoTなどに接続しています。

https://soracom.jp/services/beam/

image1

この図を見てわかる通り、お客様のモバイルデバイスだけでなく、電動キックボードや電動アシスト自転車などの車両もLUUPのシステムを利用しているクライアント端末であると考えられます。そのため、LUUPではお客様の体験を考慮してSLIを設計すること、IoT機器の動作を考慮してSLIを設計することの2つが重要です。

お客様の体験を考慮してSLIを設計する

まず、お客様の体験を考慮してSLIを設計することについて考えてみます。

お客様の体験を考慮してSLIを設計する際には、クリティカルユーザージャーニー(以下、CUJ)という考え方を活用します。

以下は「Site Reliablity Workbook」からの引用です。

究極的にはSLOの主眼は顧客体験の改善であるべきです。したがって、SLOはユーザーを中心に置くアクションについて書かれるべきです。
顧客の体験を補足するには、クリティカルユーザージャーニーを利用できます。クリティカルユーザージャーニーは、あるユーザーの体験の中核部分となるタスクの並びで、サービスのきわめて重要な側面です。[1]

CUJは、お客様が目的を達成するために行うサービス操作です。数多くのお客様の体験(ユーザージャーニー)の中から、サービスにとって特に重要な中核的な体験をCUJとして定義します。

CUJに関連付けられた操作を計測するSLIは、お客様の体験を反映したSLIとなるため、CUJという考え方を活用してSLIを設計していきます。

例として、CUJを車両の施錠と設定したSLOについて紹介します。

車両の施錠を行うには、施錠のAPIが使える状態にあることが重要です。そのため、施錠のAPIのAvailabilityをSLIと設定します。

具体的には、APIのステータスコードのうち、500系と400系の一部をエラーとしてSLIを設定し、計測しています。

SLOは、過去30日の目標値99%と設定して運用しています。

IoT機器の動作を考えてSLIを設計する

次にIoT機器の動作を考えてSLIを設計することを考えてみます。

お客様の体験を考慮してSLIを設計する時はCUJを活用しましたが、IoT機器の動作を考慮する際にはどうすれば良いでしょうか?

IoT機器の動作は、お客様の体験を支える要素の1つであり、基本的には24時間365日稼働し続けています。また、お客様の行動とは別に、非同期でクラウド側との通信が行われています。

お客様の行動とは別に動いているので、ユーザージャーニーという枠組みで整理することができません。そのため、CUJという考え方では整理できないので、CUJとは別のアプローチを考える必要があります。

そのため、Luup社内でCUJと区別するためCMC:クリティカルマシンコミュニケーション(以下、CMC)というIoT機器の動作に注目した考え方を定義しました。

CMC: Critical Machine Communication

IoTサービスにおけるSLIで測定すべきなのは、マシンが期待通りに動作できる状態であるかです。その計測対象をCMCと定義しています。

バッテリーが切れていないか、サーバーと接続されているかなど数多くのIoT機器の動作(マシーンコミュニケーション)の中からサービスにとって特に重要な中核的な動作がCMCとなってきます。

CMCのSLIへの活用方法はCUJと同様です。

CMCに関連する操作を計測したSLIはIoTの動作を反映したSLIとなりますし、CMCを基にSLIを設定することで、IoT機器が期待通りに動作できる状態であるかを計測することができます。

CUJ、CMC、SLI、SLOを図で整理すると以下のようになります。CUJとCMCが同じレイヤーの概念ということがわかります。

image2

CMCは、SRE NEXT 2022での登壇が初出です。

CMC based SLI

では、実際にどのようにLUUPでCMC based SLIを考えたのか紹介します。

LUUPでCMCを設定する上で色々IoT機器のメトリクスはありますが、どこがクリティカルなのかを考えました。
その結果、IoT機器が利用できないことがクリティカルだとしました。
LUUPの場合、サービスの根幹である移動というものが提供できなくなってしまいます。

つまり、IoT機器が使えるかどうか、Availabilityをみていくのが良いと考えました。

車両のAvailabilityを取得し、SLOとして設定することで、以下を実現したいと考えています。

  • お客様が利用できる車両を増やすこと
  • お客様が利用できない車両を減らすこと

お客様が利用できる車両を増やす

お客様が利用できる車両を増やすことについてです。

お客様が利用できる車両を増やす方法は、以下の2つがあると思います。

  1. そもそもの車両数を増やすこと
  2. 不具合改修車両のサービスイン

1はハードウェアチームやサービスオペレーションの領域、2はサービスオペレーションも含みますが、一部システムで対応できる領域です。

SLO活動では、2を対象に活動します。
車両の信頼性を上げて、サービスインできる車両数を増やしていきます。

お客様が利用できない車両を減らす

お客様が利用できない車両を減らすことについてです。

不具合のある車両があれば、お客様が利用しようとする前に予めサービス上利用できない状態にしたいです。

これによって、ユーザー体験や安全性、決済など様々な観点からトラブルを減らすことができると思います。

また、お客様が利用できない車両の割合が増えてきたら検知したり、不具合を確認したタイミングでサービスアウトなどを行いたいです。

SLIの設計

CMCを定義したので、具体的にメトリクス化し信頼性指標(SLI)を設計していきます。

LUUPでは普段、車両とクラウドは定期通信しているのですが、この定期通信や施錠・解錠のタイミングでFirestoreに車両データが入ってきます。

今回CMCを基にしたSLIを考えていく中で、そのデータをCloudRunを使って定期的に集計するようにしました。CloudRunからBQに送ってRedashで表示しています。

image3

集計しているデータは以下の3つです。

  1. 車両の利用可能台数
  2. 車両の利用不可台数
  3. 車両の利用不可理由

Redashでは、このように利用不可車両と利用可能車両を確認することができます。

image4

Redash Dashboardを確認すると、利用不可原因として以下が記載されています。

  • 電池切れ
  • 保険・ナンバー待ち
  • 初期投入待ち
  • 自動メンテ
    • x分にy回施錠・解錠できない車両を自動でサービスアウト
    • サービスオペレーションとして現場を回っているメンバーが車両を回収し、修理・問題ないことが確認されたあとサービスイン
  • 自動メンテ_HWエラー検知
    • 指定のHWエラーコードがx分にy回インターフェースされた車両に対して自動でサービスアウト
    • サービスイン周りは"自動メンテ"同様

image5

利用不可理由を見ていくと、IoTチームやSREチームでコントロールできないものが多くあります。
SLOはSLOの運用者でコントロールできる状態にしたいので、ソフトウェア側でコントロールできないものは除外する、SLIを絞り込む必要があることがわかってきます。

ということで、SLIは(物理的な車両の問題を除く)市場投下車両のうち、利用可能な車両の比率としました

Good Eventを利用可能車両数、Bad Eventを自動メンテと自動メンテ_HWエラー検知を足した利用不可車両数として、Total Eventをその合計としています。

自動メンテによるサービスアウトによって車両を提供できていない割合が一定値を超えるとSLO違反になるようなSLOを想定しています。

また、上記をSLOとして運用していくためには、車両の異常を検知し、適切にサービスアウトする必要があります。この点については、SRE NEXT 2023での登壇内容に詳しく説明されています。

https://zenn.dev/luup_developers/articles/sre-grimoh-20231002#iotチームに対して

SLIの実装として、Redashでダッシュボード化しました。
GoodイベントとBadイベントの推移と割合を表示しています。

image6

さいごに

Luupで定義したCMC: クリティカルマシンコミュニケーションという概念について紹介しました。

Luupでは、CMCを基にしたSLIの設計を行いましたが、SLOの設定や運用はこれからです。

形になったタイミングで、CMCを基にしたSLOについてもブログや登壇でお話しできればと思います。

もしCMCに関心があり、より詳しい話を聞きたい、または議論したいという場合は、お気軽に声をかけてください!

また、CMCという概念はLuup以外でも紹介されています。(ビットキーさん、ありがとうございます!)

今後、他社のIoTサービスでもCMCという考え方がSLOの検討に活用され、登壇などで紹介されることを期待しています。

最後に、弊社のプロダクト開発やSRE、使用技術に興味を持っていただけた方は、以下のリンクからお気軽にご連絡ください!私のX(Twitter)アカウントでもDMを受け付けています。
副業や転職をお考えの方だけでなく、気軽に話を聞きたいという方も大歓迎です!

https://recruit.luup.sc/

脚注
  1. https://sre.google/workbook/implementing-slos/#modeling-user-journeys ↩︎

Luup Developers Blog

Discussion