街じゅうを"駅前化"する電動マイクロモビリティのシェアサービス「LUUP」のIoTとSRE

https://sre-next.dev/2022/schedule#jp55 の発表資料です。

Transcript

1. 0gm (@ktykogm)
   2022年5月15日 17:00 - 17:30 Track A
   https://sre-next.dev/2022/schedule#jp55
   街じゅうを"駅前化"する電動マイクロ
   モビリティのシェアサービス「LUUP」
   のIoTとSRE
   

   View Slide

2. Luup, Inc. 2
   自己紹介と謝辞
   https://twitter.com/srenext/status/1508283404554752000?s=20&t=HwnH5TeE9e-i4YF_iHCH_Q
   whoami && thankseveryone
   はじめまして。0gmと申します。
   こんな人:
   - “2歳児の父”
   - “メルカリJPのMicroservices SREチームに所属”
   - “SRE NEXTの運営メンバー（SRE Loungeという母体の運営も参加）”
   - “SRE NEXT 2022 メルカリのスポンサー担当”
   - “副業でLuupのSREをお手伝い”
   SRE Loungeの仲間とSRE NEXTを立ち上げました。
   子供が産まれてからコミュニティ活動にあまり時間が使えず。
   でも今回nari(@fukubaka0825)さんがChairmanを引き受けてくれました！！
   また、（私以外の）他のメンバーもめちゃくちゃ頑張って今回開催出来ました！
   この場を借りて運営仲間とコミュニティの皆に感謝の意を表します！！！
   

   View Slide

3. Luup, Inc. 3
   用語
   • SRE
   • Site Reliability Engineering, 信頼性工学を指します。
   • SREs
   • SREs are engineers, SREを専門的に実践するエンジニア
   • LUUP
   • 電動モビリティシェアサービス
   • Luup
   • LUUPの開発会社
   https://sre.google/sre-book/preface/
   

   View Slide

4. Luup, Inc. 4
   最近の事例など
   メルカリで行っていること
   Embedded SREsとしてフリマアプリのサービス開発チームに参加し、信頼性を高めることを専門としてメル
   カリで働いています。 メルカリで普段行っていることは去年11月に行われたSRE Lounge #13と、2月の終
   わりに会社のブログで紹介しましたので、そちらも御覧いただけると幸いです。
   

   View Slide

5. Luup, Inc. 5
   「面白そうだから」だけでもいいですが、他にも理由があります。
   なぜメルカリのSREsがLuupのSRE？
   昨年10月よりLuup社にて、SRE導入のお手伝い
   実はIoT分野に飛び込んだのは今回が初めてです。
   「なぜメルカリのSREsがLuup社のお手伝いをしているのか」
   • 技術スタックおよび組織が異なる環境で、SREを導入・実践していくことはスキルアップに繋がる
   • メルカリでもIoTが使われている箇所がある
   • IoTは今後ますます増えることが考えられる
   メルカリもLuupも環境に配慮したサービスという共通点を持っています。
   

   View Slide

6. Luup, Inc. 6
   大きく3つ
   この発表で伝えたいこと
   • IoTとWeb・アプリの違い
   • IoT x SREの世界観
   • IoT x SREの課題と未来
   

   View Slide

7. Luup, Inc. 7
   Luupのプロダクト紹介
   Luupとは何か
   

   View Slide

8. Luup, Inc. 8
   ここから先は
   LUUPにおけるSREの説明と
   IoTとWebの違いおよびIoT x SREの世界観を紹介してい
   きます。
   

   View Slide

9. Luup, Inc. 9
   公開済の構成図
   ※MQTTの部分は双方向にあるので、わかりやすくそこだけ追記しています。
   https://note.com/luup/n/nb493b83a2bfd
   LUUPの現状構成
   

   View Slide

10. Luup, Inc. 10
    いよいよWebとの違い、IoTの世界観や課題の話に入っていきますが...
    具体的な話に入る前に
    IoTを知らない人でも分かるように
    まずは簡単な技術説明やWebとの違いを説明してから
    IoT x SREの課題や対応の話に入っていきます。
    

    View Slide

11. Luup, Inc. 11
    必要な知識
    IoTで信頼性を高めるという目標を達成するために
    • IoT
    • 通信プロトコル
    • MQTT
    • ソケット通信の場合もあります
    • 通信プロトコルはその他多数ありますが、代表的なのはMQTTであるため、割愛します。
    • 近距離無線通信規格・センサー
    • BLE
    • ハードウェアデバイス, ファームウェア
    • ものによって仕様が異なる部分が多い
    • これらはM2M（Machine to Machine）監視にも関係
    • セキュリティもWebと異なる部分がある
    • サイドチャネル攻撃、ファームウェア書き換え、FPGAへの脅威とセキュリティ
    • SREはこれらの専門家ではありませんが無関係ではありません
    • Web
    • SRE
    • インフラ
    

    View Slide

12. Luup, Inc. 12
    必要な知識
    IoTで信頼性を高めるという目標を達成するために
    • IoT
    • 通信プロトコル
    • MQTT
    • ソケット通信の場合もあります
    • 通信プロトコルはその他多数ありますが、Luupでは現在使用していません。また、代表的なの
    はMQTTであるため、割愛します。
    • 近距離無線通信規格・センサー
    • BLE
    • ハードウェアデバイス, ファームウェア
    • ものによって仕様が異なる部分が多い
    • これらはM2M（Machine to Machine）監視にも関係
    • セキュリティもWebと異なる部分がある
    • サイドチャネル攻撃、ファームウェア書き換え、FPGAへの脅威とセキュリティ
    • SREはこれらの専門家ではありませんが無関係ではありません
    • Web
    • SRE
    • インフラ
    

    View Slide

13. Luup, Inc. 13
    MQTT はHTTPに比べて次のようなメリットがあります。（3G回線上での比較）
    https://www.advanet.co.jp/2020/10/14/mqtt-introduction/
    MQTT vs HTTP性能比較
    ●
    スループットが93倍UP
    ●
    送信時のバッテリー使用量が91.5%減
    ●
    受信時のバッテリー使用量が99.4%減
    ●
    接続保持電力が50%減
    ●
    ネットワークオーバーヘッドが87.5%減
    

    View Slide

14. Luup, Inc. 14
    Difference between MQTT and HTTP protocols:
    https://www.geeksforgeeks.org/difference-between-mqtt-and-http-protocols/
    MQTT vs HTTP性能比較
    

    View Slide

15. Luup, Inc. 15
    MQTTの特徴
    ●
    Pub/Sub
    ○
    パブリッシャー ⇒ MQTTブローカー ⇒ サブスクライバー という流れになる
    ○
    ワイルドカード指定ができる
    ■
    + = シングルレベル
    ■
    # = マルチレベル
    ○
    メッセージを保持する
    ○
    セッションを永続的にするかどうか選択ができる
    ○
    QoSの設定ができる
    ○
    一度に送信出来るサイズ
    ■
    最大データサイズは268MB
    ■
    最大トピックサイズは65kB
    ●
    備えていない機能
    ○
    シリアライズ
    ■
    e.g., + Protocol Buffers
    ○
    セキュリティ
    ■
    HTTPと同じくTLSが使われます
    

    View Slide

16. Luup, Inc. 16
    クライアントライブラリやツールなどの一覧
    https://mqtt.org/software/
    MQTT
    LuupではTypeScriptにてFirebaseからCloud Functionsを経由してMQTTにてpublishを行い、キックボー
    ドなどに備えている施錠用IoTデバイスのunlock, lockを制御する機能などを開発しています。
    

    View Slide

17. Luup, Inc. 17
    SIMによるコミュニケーション
    IoTデバイスとクラウドとの架け橋
    • SORACOM公式ドキュメント
    • https://developers.soracom.io/en/docs/
    • SIM監視用のCLIやAPI
    • https://users.soracom.io/ja-jp/docs/event-handler/configure-with-api/
    • IoTデバイスの死活監視を考える（SORACOM UG Online #9）
    • https://github.com/nmikuni/soracom-ping-monitoring-sample
    • SORACOMデバイスpingをCLIから試してみた
    

    View Slide

18. Luup, Inc. 18
    ビーコンやセンサーで利用する近距離無線規格
    https://esg.teldevice.co.jp/iot/azure/column/column23.html
    BLE(Bluetooth Low Energy)
    • 特徴
    • 免許不要の無線通信規格で、安価に利用できる
    • 消費電力が少ない
    • 複雑な設定不要でペアリングできる
    • 世界標準規格で汎用性が高く、搭載製品が豊富
    

    View Slide

19. Luup, Inc. 19
    IoT Core
    IoTに特化したクラウドサービス
    • AWS IoT Core
    • https://aws.amazon.com/jp/iot-core/
    • Google Cloud IoT Core
    • https://cloud.google.com/iot-core
    

    View Slide

20. Luup, Inc. 20
    ※現在開発・準備中の車体が含まれます
    M2M(Machine to Machine)とは
    • IoT
    • Internet of Things の略
    • モノをインターネットに接続して遠隔操作を行う技術
    • インターネットへの接続が前提
    • M2M
    • Machine to Machineの意味
    • インターネットとの接続の有無は見ない
    

    View Slide

21. Luup, Inc. 21
    IoT特有のSRE監視ポイント
    IoTのためのObservabilityとSLO
    観測・監視が必要な箇所 説明 観測・監視について
    電動モビリティ バイクやキックボードの本体 ハードウェアの異常検知情報などは
    IoTデバイスを介してエンドポイントに送られる。
    IoTデバイス 電動モビリティに搭載されている施錠・解錠などの各種（可動）装置（アプリから
    操作）と周辺設備、装置にも
    IoTデバイスが使われる。
    IoT = Internet of Thingsというわけで通信モデムを備える。
    ハードウェアの情報を伝えるためにサーバと常時
    M2M監視を行っている。
    「通信は生きているけど、電動モビリティが利用できない」、「利用中に故障」といった問題の検知や
    予防をするにはハードウェア情報の一部を監視する必要がある。
    SIM LuupではSORACOM社のSIMサービスを利用。IoTデバイスと外の世界をつ
    なぐために必要。
    SORACOM側からCLIおよびAPIでSIM監視が可能。 ここではAvailabilityだけではなくLatencyや
    Sessionも観測が必要。
    サーバー、Pub/Sub、LB VM Instanceなどで右記のとおり。一部コンテナ化 + IoT Coreに移行予定 ここはWeb・アプリのインフラで行う監視と同等。 ※ IoT Coreに移行した場合は監視方法が変わ
    る。
    ただし、一部のIoTデバイスからのイベント情報（ログ、エラー）はそのままでは
    SLOとして扱えないも
    のが存在。（後述）
    Firebase + Cloud Functions クライアントアプリとのゲートウェイであり、トリガー Firebaseは標準でクライアント側の一部の観測は標準機能として備わっているが、
    SREに必要なも
    のが全て揃っているというわけではない。よって追加が必要な観測・監視があれば適宜追加が必
    要。たとえば接続する
    Cloud Functionsとのlatencyやエラー率、それぞれのクオータ監視、
    SLO。ま
    た、IoTデバイスの操作結果は
    Firebase SDK for Cloud Functionsを通してFunctions側にロギン
    グされるため、そちらも監視する必要がある。
    クライアントアプリ クラッシュ率やパフォーマンスなどは
    Firebaseにて観測可能。 上記のとおり、クライアントの観測は一部
    Firebaseで一部標準で備わっている。必要なアラートや
    SLOは追加する必要がある。 責任分界点 = LUUPのサービス or スマホ側どちらの問題か線引き
    が必要。
    

    View Slide

22. Luup, Inc. 22
    ※この他にIoT以外の部分（Webシステム、アプリ）の監視対象があります。
    ※現在開発・準備中の車体が含まれます
    LUUPのIoT範囲の監視対象
    

    View Slide

23. Luup, Inc. 23
    Web・アプリの世界ではCUJを重視し、そこからSLI ⇒ SLOの設計に落とし込んでいきます。
    CUJだけではIoTのSLI・SLO設計は困難？
    https://speakerdeck.com/0gm/sabisutozu-zhi-falsekuo-da-wozhi-eruembedded-sres?slide=10
    しかしIoTの場合はそれでは足りないことに気が付きました。
    

    View Slide

24. Luup, Inc. 24
    まず、CUJを考えてみます
    なぜIoTではCUJだけでは足りないのか
    次のようなことが一つのCUJになるでしょう。
    ● LUUPの電動モビリティの施錠をする
    ● 乗り終わったらLUUPの電動モビリティを撮影してサービスを終了する ※1
    CUJなので主語は全て「User = お客様」になります。
    ※1: LUUPのサービス利用の終了時に必要なアクションは「専用ポートに駐車をして撮影」です。
    

    View Slide

25. Luup, Inc. 25
    まず、CUJを考えてみます
    なぜIoTではCUJだけでは足りないのか
    「施錠」「撮影」「ライドの終了」が重要監視対象。
    CUJに入らないけど、重要な監視対象とは？
    

    View Slide

26. Luup, Inc. 26
    ハードウェアの監視、M2M監視
    なぜIoTではCUJだけでは足りないのか
    例題：バッテリー異常があった場合を考えてみます。
    バッテリーの問題ですから解錠・施錠だけではなく、走行中のトラブルも考えられます。
    CUJで考えると以下のアクションに入ります。
    1.
    電動モビリティを解錠する
    2.
    電動モビリティに乗って移動する
    3.
    電動モビリティを駐車して施錠をする
    

    View Slide

27. Luup, Inc. 27
    例題：バッテリー異常
    ※これははあくまで例です。IoTデバイスや電動モビリティおよびアプリ側のサポート状況によって異なるため、様々なケースがあります。
    なぜIoTではCUJだけでは足りないのか
    1. 電動モビリティを解錠する
    a. 可用性を観測する
    b. 遅延を観測する
    2. 電動モビリティに乗って移動する
    c. サービスの状態を「ライド中」に変更
    i. 可用性を観測する
    ii. 遅延を観測する
    d. 移動中のGPSとマップの更新
    i. 可用性を観測する
    ii. 遅延を観測する
    3. 電動モビリティを駐車する
    a. 駐輪ポートと駐輪位置をBLEビーコンや
    GPSを使って測定して合否判定する
    i. 可用性を観測する
    ii. 遅延を観測する
    4. 電動モビリティを施錠する
    a. 可用性を観測する
    b. 遅延を観測する
    

    View Slide

28. Luup, Inc. 28
    例題：バッテリー異常
    ※これははあくまで例です。IoTデバイスや電動モビリティおよびアプリ側のサポート状況によって異なるため、様々なケースがあります。
    なぜIoTではCUJだけでは足りないのか
    1. 電動モビリティを解錠する
    a. 可用性を観測する
    b. 遅延を観測する
    2. 電動モビリティに乗って移動する
    c. サービスの状態を「ライド中」に変更
    i. 可用性を観測する
    ii. 遅延を観測する
    d. 移動中のGPSとマップの更新
    i. 可用性を観測する
    ii. 遅延を観測する
    3. 電動モビリティを駐車する
    a. 駐輪ポートと駐輪位置をBLEビーコンや
    GPSを使って測定して合否判定する
    i. 可用性を観測する
    ii. 遅延を観測する
    4. 電動モビリティを施錠する
    a. 可用性を観測する
    b. 遅延を観測する
    実装方法に関係なく、電動モビリティのバッテリーを必ず使う部分のうち、
    バッテリー異常の影響が大きく出るSLO監視対象
    

    View Slide

29. Luup, Inc. 29
    例題：バッテリー異常
    ※これははあくまで例です。IoTデバイスや電動モビリティおよびアプリ側のサポート状況によって異なるため、様々なケースがあります。
    なぜIoTではCUJだけでは足りないのか
    1. 電動モビリティを解錠する
    a. 可用性を観測する
    b. 遅延を観測する
    2. 電動モビリティに乗って移動する
    c. サービスの状態を「ライド中」に変更
    i. 可用性を観測する
    ii. 遅延を観測する
    d. 移動中のGPSとマップの更新
    i. 可用性を観測する
    ii. 遅延を観測する
    3. 電動モビリティを駐車する
    a. 駐輪ポートと駐輪位置をBLEビーコンや
    GPSを使って測定して合否判定する
    i. 可用性を観測する
    ii. 遅延を観測する
    4. 電動モビリティを施錠する
    a. 可用性を観測する
    b. 遅延を観測する
    ライド中にバッテリー異常で停止すると？...
    GPS情報では突然のバッテリー異常で停
    止したことが検知できない！！
    

    View Slide

30. Luup, Inc. 30
    例題：バッテリー異常
    なぜIoTではCUJだけでは足りないのか
    ライド中にバッテリー異常で停止すると？...
    Q. ライド中のサーバとの死活監視やSIMのセッション監視で分かるのでは？
    

    View Slide

31. Luup, Inc. 31
    例題：バッテリー異常
    なぜIoTではCUJだけでは足りないのか
    ライド中にバッテリー異常で停止すると？...
    Q. ライド中のサーバーとの死活監視やSIMのセッション監視で分かるのでは？
    A. 分かります。問題発生時に検知は可能です。
    しかし、現実世界のハードウェアなのでWebのようにリトライ等で高確率に解決するも
    のではありません。
    ● 例: 近くにLUUPの駐輪ポートも交換できる電動モビリティもないところで停止
    ○ お客さまはすぐにやり直しができずに非常に悪い体験
    Webのように簡単にやり直せないので、「 95%ileや99%ile（が合理的）でOK」というわけにいかないエラーがあります。
    また、問題のあるデバイスとユーザージャーニーが直接結びつくのはそのデバイスを利用したときだけです。
    よって、IoTでCUJをベースにしたSLOの場合、バーンレートアラートでも遅いことが想定できます。
    

    View Slide

32. Luup, Inc. 32
    ハードウェアのイベント情報からSLOを設ける
    どうすればIoTで適切なSLOを設定できそうか
    「M2MもしくはMachineからの重要なコミュニケーション」は何か
    言い換えれば「ハードウェアイベントに対するCUJのような意味」
    その適切な表現が存在しないことが発覚。
    言葉の定義は円滑なコミュニケーションを図る上で重要。
    そこで我々内部では、それをCUJと区別するためにもCMC（Critical Machine Communication）と名付けま
    した。
    ※ あくまでコミュニケーションコストや認識齟齬のリスクを下げるため。もしSRE分野で別のデファクトスタンダードな表現が生まれたらそちらに
    変更するつもりです。
    

    View Slide

33. Luup, Inc. 33
    ハードウェアのイベント情報からCMCを見つけ出し、SLOを設ける
    どうすればIoTで適切なSLOを設定できそうか
    ファームウェア仕様書 -> SREsがCMCになりそうなハードウェアイベントを精査 -> PdM等を交えて議論
    -> CMCを決定 -> SLI設計 -> SLO設計
    しかし様々なパターンが存在...
    MQTTによるJSON、ソケット通信によるCSV形式の電文、etc..
    最終的には人間が分かる状態にしないとSLOには持っていけない。
    電文の例:
    0,0.0,0,0.0,,,,,0440,0130,16B0,02092053,26&99,2,41,0,54095,4053,89,0,0,1,,0.0&0.00&0,100,4E41
    

    View Slide

34. Luup, Inc. 34
    ここでは通常はサーバーに人間が読める状態でログ管理されているのでは？という疑問にお答えします。
    IoTデバイスのイベント情報は人間が読めない？
    サーバー上ではそのようなログがないことがあります。
    （すべてのログがそうではありません）
    しかし管理用スマホアプリ上では人間が読めるログに変換されています。
    サーバーには無いのに、なぜでしょう。
    

    View Slide

35. Luup, Inc. 35
    管理用スマホアプリ上では人間が読めるログにコンバートされていますがサーバーには無いケース
    IoTデバイスのイベント情報は人間が読めない？
    なぜ？？
    IoTは物理的なアクションがともなうため。
    その対象の近くで作業を行う必要がとても多い。
    サーバー上に人間が読めるログがあってもIoT開発者はあまり嬉しくない。
    しかしSREの観点では人間がそのまま理解できるログがどこかに集約した形で必要。
    

    View Slide

36. Luup, Inc. 36
    ログ管理の標準化が必要
    IoT x SREの課題
    IoTに効率よくSREを導入していくために。
    M2MもMQTTで最初から人間が読める状態にて標準化がよい？
    しかし、IoTのリソースは限られている ＋ スケーラビリティが無いとビジネスの成長に追いつけなくなってし
    まい、信頼性を失う。
    かといってソケット通信の生の電文からコンバートしていくやり方は変更への耐性に弱く、保守や運用には
    向いていない。
    標準化でMQTTを採用した場合、スケーラビリティを確保するには。
    

    View Slide

37. Luup, Inc. 37
    設計および議論を開始...
    図は現在設計中のものです。執筆時点では
    PoCも未実施です。
    MQTTの圧縮
    MQTT側でシリアライズ出来ないか調べてみると、
    Protocol Buffersでかなり減らせることはわかりまし
    た。
    https://ipsj.ixsq.nii.ac.jp/ej/?action=pages_view_
    main&active_action=repository_view_main_item
    _snippet&all=mqtt&title=&creator=&des=protoco
    l%20buffers&jtitle=&pubYearFrom=&pubYearUn
    til=&idx=&count=20&order=16&pn=1&page_id=
    13&block_id=8
    

    View Slide

38. Luup, Inc. 38
    SRE Lounge #8
    https://blog.soracom.com/ja-jp/2019/03/27/report-sre-lounge8/
    思い出す、テクノロジーの総合格闘技
    

    View Slide

39. Luup, Inc. 39
    現在と今後
    LuupのSRE
    ● 現在
    ○ SLO監視を導入準備
    ○ SRE NEXT/Loungeの運営仲間である@ogadyも副業でサポート
    ■ Enabling SREを開始
    ○ インフラも強化
    ● 今後（一部は検討中）
    ○ IoTのハードウェアイベント管理の標準化を進める
    ■ MQTT圧縮などスケーラブルな方法かつ扱いやすい方法を採用する
    ○ IoT x Webインフラを強化する
    ○ IoT x SREを加速させる
    

    View Slide

40. Luup, Inc. 40
    調べてみると...
    おまけ
    WoT(Web of Things)なんかもあり、W3Cで管理されているようです。
    これはWebの技術や標準化されたものをIoTにも入れていこうとしている規格のようで
    す。
    ● https://www.nic.ad.jp/ja/materials/iw/2016/proceedings/t08/t8-ashimura.pdf
    ● https://www.w3.org/TR/wot-usecases/
    このあたりも知らない世界なので、現在調べて学んでいるところです。
    

    View Slide

41. Luup, Inc. 41
    IoT x SRE全体をとおして
    まとめ
    ● 長距離通信（IoT, M2Mも含まれる）
    ○ HTTPよりかなり軽量かつ扱いやすい
    MQTTを使うことが多い
    ○ ソケット通信の生電文も扱う
    ● 近距離無線（M2M）
    ○ BLEによるセンサーやデバイス制御を行う
    ○ それらのエラーも必要に応じてSLOに入れる必要がある。下記SLOにて。
    ● IoTデバイス
    ○ リソースは限られている
    ■ いかに小さく効率よく通信および処理を行わせるかが勝負
    ● ログ
    ○ 人間がそのまま読めるログがあることを期待しないほうが良い
    ○ ログフォーマットを含めた多くのものは標準化されていない
    ○ 標準化を含めていかに効率的に
    SREを導入していくか（監視を入れていくか）が重要になってきます。
    ● SLO
    ○ IoTでもM2Mでも重要なハードウェアイベント（
    CMC）があれば必要
    ● Webの知識は十分役に立つ
    ● 対応範囲はネットワークを含めた低レイヤーから高レイヤーまで
    

    View Slide

42. View Slide