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

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を引き受けてくれました！！ また、（私以外の）他のメンバーもめちゃくちゃ頑張って今回開催出来ました！ この場を借りて運営仲間とコミュニティの皆に感謝の意を表します！！！

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

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

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

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

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

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

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

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

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

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

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%減

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

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

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

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から試してみた

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

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

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

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 スマホ側どちらの問題か線引き が必要。

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

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の場合はそれでは足りないことに気が付きました。

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

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

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

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. 遅延を観測する

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監視対象

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情報では突然のバッテリー異常で停 止したことが検知できない！！

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

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

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

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

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

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

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

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

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

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

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/ このあたりも知らない世界なので、現在調べて学んでいるところです。

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

No content