Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

ktykogm

May 15, 2022
Tweet

More Decks by ktykogm

Other Decks in Technology

Transcript

  1. 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を引き受けてくれました!! また、(私以外の)他のメンバーもめちゃくちゃ頑張って今回開催出来ました! この場を借りて運営仲間とコミュニティの皆に感謝の意を表します!!!
  2. Luup, Inc. 3 用語 • SRE • Site Reliability Engineering,

    信頼性工学を指します。 • SREs • SREs are engineers, SREを専門的に実践するエンジニア • LUUP • 電動モビリティシェアサービス • Luup • LUUPの開発会社 https://sre.google/sre-book/preface/
  3. Luup, Inc. 11 必要な知識 IoTで信頼性を高めるという目標を達成するために • IoT • 通信プロトコル •

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

    MQTT • ソケット通信の場合もあります • 通信プロトコルはその他多数ありますが、Luupでは現在使用していません。また、代表的なの はMQTTであるため、割愛します。 • 近距離無線通信規格・センサー • BLE • ハードウェアデバイス, ファームウェア • ものによって仕様が異なる部分が多い • これらはM2M(Machine to Machine)監視にも関係 • セキュリティもWebと異なる部分がある • サイドチャネル攻撃、ファームウェア書き換え、FPGAへの脅威とセキュリティ • SREはこれらの専門家ではありませんが無関係ではありません • Web • SRE • インフラ
  5. 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%減
  6. Luup, Inc. 15 MQTTの特徴 • Pub/Sub ◦ パブリッシャー ⇒ MQTTブローカー

    ⇒ サブスクライバー という流れになる ◦ ワイルドカード指定ができる ▪ + = シングルレベル ▪ # = マルチレベル ◦ メッセージを保持する ◦ セッションを永続的にするかどうか選択ができる ◦ QoSの設定ができる ◦ 一度に送信出来るサイズ ▪ 最大データサイズは268MB ▪ 最大トピックサイズは65kB • 備えていない機能 ◦ シリアライズ ▪ e.g., + Protocol Buffers ◦ セキュリティ ▪ HTTPと同じくTLSが使われます
  7. 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から試してみた
  8. Luup, Inc. 18 ビーコンやセンサーで利用する近距離無線規格 https://esg.teldevice.co.jp/iot/azure/column/column23.html BLE(Bluetooth Low Energy) • 特徴

    • 免許不要の無線通信規格で、安価に利用できる • 消費電力が少ない • 複雑な設定不要でペアリングできる • 世界標準規格で汎用性が高く、搭載製品が豊富
  9. 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
  10. Luup, Inc. 20 ※現在開発・準備中の車体が含まれます M2M(Machine to Machine)とは • IoT •

    Internet of Things の略 • モノをインターネットに接続して遠隔操作を行う技術 • インターネットへの接続が前提 • M2M • Machine to Machineの意味 • インターネットとの接続の有無は見ない
  11. 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 スマホ側どちらの問題か線引き が必要。
  12. Luup, Inc. 24 まず、CUJを考えてみます なぜIoTではCUJだけでは足りないのか 次のようなことが一つのCUJになるでしょう。 • LUUPの電動モビリティの施錠をする • 乗り終わったらLUUPの電動モビリティを撮影してサービスを終了する

    ※1 CUJなので主語は全て「User = お客様」になります。 ※1: LUUPのサービス利用の終了時に必要なアクションは「専用ポートに駐車をして撮影」です。
  13. 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. 遅延を観測する
  14. 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監視対象
  15. 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情報では突然のバッテリー異常で停 止したことが検知できない!!
  16. Luup, Inc. 31 例題:バッテリー異常 なぜIoTではCUJだけでは足りないのか ライド中にバッテリー異常で停止すると?... Q. ライド中のサーバーとの死活監視やSIMのセッション監視で分かるのでは? A. 分かります。問題発生時に検知は可能です。

    しかし、現実世界のハードウェアなのでWebのようにリトライ等で高確率に解決するも のではありません。 • 例: 近くにLUUPの駐輪ポートも交換できる電動モビリティもないところで停止 ◦ お客さまはすぐにやり直しができずに非常に悪い体験 Webのように簡単にやり直せないので、「 95%ileや99%ile(が合理的)でOK」というわけにいかないエラーがあります。 また、問題のあるデバイスとユーザージャーニーが直接結びつくのはそのデバイスを利用したときだけです。 よって、IoTでCUJをベースにしたSLOの場合、バーンレートアラートでも遅いことが想定できます。
  17. 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
  18. Luup, Inc. 36 ログ管理の標準化が必要 IoT x SREの課題 IoTに効率よくSREを導入していくために。 M2MもMQTTで最初から人間が読める状態にて標準化がよい? しかし、IoTのリソースは限られている

    + スケーラビリティが無いとビジネスの成長に追いつけなくなってし まい、信頼性を失う。 かといってソケット通信の生の電文からコンバートしていくやり方は変更への耐性に弱く、保守や運用には 向いていない。 標準化でMQTTを採用した場合、スケーラビリティを確保するには。
  19. 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
  20. Luup, Inc. 39 現在と今後 LuupのSRE • 現在 ◦ SLO監視を導入準備 ◦

    SRE NEXT/Loungeの運営仲間である@ogadyも副業でサポート ▪ Enabling SREを開始 ◦ インフラも強化 • 今後(一部は検討中) ◦ IoTのハードウェアイベント管理の標準化を進める ▪ MQTT圧縮などスケーラブルな方法かつ扱いやすい方法を採用する ◦ IoT x Webインフラを強化する ◦ IoT x SREを加速させる
  21. 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/ このあたりも知らない世界なので、現在調べて学んでいるところです。
  22. Luup, Inc. 41 IoT x SRE全体をとおして まとめ • 長距離通信(IoT, M2Mも含まれる)

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