IoTのデータ保存をSREの観点で考える

1. SORACOM UG Hiroshima #12 IoTのデータ保存を SREの観点で考える 成功の定義と⽋損データの復旧の2つの観点から Topotal, Inc - SRE as a Service / Wataru Tsuda（@gr1m0h） 1
2. Wataru Tsuda @gr1m0h SWE, SRE @ Topotal, Inc. - 複数社で SRE の技術⽀援に従事 - IoT関連事業会社を2社経験 コミュニティ活動 - SRE Lounge Hiroshima - SRE Magazine - SORACOM UG Hiroshima Website: grimoh.net SORACOM UG Hiroshima #12 | gr1m0h 2
3. SRE as a Service - 技術⽀援 私たちは Cross-Company Embedded SRE として、課題を解決する。 クライアントが変わっても、SRE としてやるべきことは変わらない。 SRE のプロフェッショナルを、 今すぐチームに。 事業成⻑を続ける SRE の仕組みづくりを プロフェッ ショナルが並⾛サポート
4. Waroom - SaaS Slackで完結できる。AI による情報⾃動収集‧ポストモーテム⾃動⽣成。 蓄積したインシデント情報の可視化と分析。 つらいインシデント対応を楽に、 学びに、そしてゼロに。 迅速な復旧と学びを得るための インシデントマネジメン トサービス
5. 今⽇の流れ IoT のデータ保存を、2つの観点で考える 01 成功の定義 送信結果ではなく、期限内に保存先で参照できたデータを成功とする 02 ⽋損データの復旧 障害で成功に届かなかったデータを、保存先に戻す 2つとも、利⽤者が参照できる保存先のデータを基準にし、測定データごとの ID で照合する SORACOM UG Hiroshima #12 | gr1m0h 4
6. 前提 SLI は、利⽤者から⾒たサービスの状態を測る指標 利⽤者の満⾜度 直接は測れない SLI = SLI → Service Level Indicator 満⾜度の⽬安として測る指標 SLO → Service Level Objective SLI の⽬標値 良いイベントの数 Web API の例 対象イベントの数 正常に応答したリクエスト ∕ 有効なリクエスト 出典: Google SRE Book「Service Level Objectives」、Google SRE Workbook「Implementing SLOs」 SORACOM UG Hiroshima #12 | gr1m0h 5
7. 01 観 点 成功の定義 IoT のデータは、デバイスから保存先まで、いくつものサービスを経由して届く。今回の構成な ら、デバイス → SORACOM → AWS IoT Core → 保存先。 この観点では、何をもってデータが届いたとみなすかを考える 6
8. 01 課題と対策 送信の完了と、保存の完了を分けて確認する Beam が受け取る PUBACK を返す → IoT Rule で処理 デバイスが受け取る「成 功」 → 保存先に書き込む → 利⽤者が参照できる ここから先の結果は、デバイスには返らない 01 ID と内容で突き合わせる 02 受付と参照の時間差を前提にする 測定データごとに event_id を付ける。件数だけで は、重複や別のデータが混ざっても気づけない ⾮同期の構成では、受付直後はまだ参照できないことが ある。失敗した処理の再試⾏‧再処理まで設計する MQTT 3.1.1 では、受信側は後続の配送を完了する前に PUBACK を返せる。出典: OASIS「MQTT Version 3.1.1」、W. Vogels「Eventually Consistent」 SORACOM UG Hiroshima #12 | gr1m0h 7
9. 01 再現 SORACOM Arc‧Beam から AWS IoT Core へ送る構成を作る Mac IoT Device Simulator Paho MQTT‧QoS 1 MQTT → SORACOM Beam 201912 MQTTS → 通常保存先 AWS IoT Core → クライアント証明書 IoT Rule CloudWatch Logs → …/telemetry error action …/rule-errors soratun → Arc の WireGuard トンネル MQTT 通信はこの中 を通る SORACOM CLI：設定を確認する soratun：つなぐ Arc ⽤のクライアント。バーチャル SIM の情報で WireGuard トンネルを作り、Wi-Fi から SORACOM につ なぐ Beam の転送先と認証情報 ID を確認 soracom groups get … \ | jq '.configuration.SoracomBeam' Beam → AWS IoT Core は MQTTS。証明書と秘密鍵は Beam の認証情報ストアに登録し、シミュレーターには持たせない。出典: SORACOM「SORACOM Arc」「soratun」「Beam MQTT エン トリポイント」 SORACOM UG Hiroshima #12 | gr1m0h 8
10. 01 再現 実測 通信を⽌める実験と、保存先の権限を外す実験をする 通信を15秒⽌める 保存先の権限を外す soratun に SIGSTOP → 15秒後に SIGCONT 完了待ち2秒‧ 測定データ18件 IoT Rule の保存先を、権限のないロググループに変更 デバイス側の送信 送信側で失敗扱い（再送な し） 保存先にあった測定データ 再送1回までの重複 結果 成功 5件 通常の保存 AccessDenied 18 / 18 error action 元データを保全 3件 後⽇の再投⼊ 通常保存先に回復 どちらの実験でも、送信側の結果だけでは、保存先にデータがあるかは判断できなかった 停⽌対象は Mac 上の Arc クライアントで、SIM の圏外の再現ではない。再投⼊は AWS CLI の iot-data publish で、Arc‧Beam を通していない SORACOM UG Hiroshima #12 | gr1m0h 9
11. 01 再現 実測 実験1の結果を、3通りの⽅法で集計する 実験1（通信を15秒停⽌‧測定データ18件）。％は、作った18件を分⺟にした SLI の値 集計の⽅法 再送なし 再送1回まで 送信側の失敗扱いを⽋損とする 5件欠損 72% 2件欠損 89% 保存先の件数をそのまま使う 18件 100% 21件 117% 18 / 18 100% 18 / 18 100% event_id で照合し、重複を除く 結果 良いイベントの決め⽅で、同じ実験でも SLI の値が変わった。event_id で照合すると、どちら の条件でも18件すべて保存されていた SORACOM UG Hiroshima #12 | gr1m0h 10
12. 01 課題と対策 設計案 期限内配送SLIを、鮮度‧網羅性‧正しさで設計する 期限は⽤途ごとに決める 異常の通知：すぐ必要 履歴の分析：後からでよい 期限内に参照できた対象データのユニーク数 期限内配送 SLI その期間に測定‧配送されるべき対象データの数 鮮度 freshness 網羅性 coverage 正しさ correctness 遅れは測定時刻から測る 分⺟はデバイス⼀覧と測定予定 から決める 分⼦は ID で重複を除く 受付時刻が基準だと、 通信が切れていた間の遅れが⼊らない 受信ログからは作らない 期限前のデータは失敗にしない 再送の重複で件数を増やさない 内容も元データと照合する Google SRE Workbook「Implementing SLOs」のデータパイプラインの例を当てはめた設計例。今回は未実装 SORACOM UG Hiroshima #12 | gr1m0h 11
13. 02 観 点 ⽋損データの復旧 IoT デバイスは、通信が切れている間もデータを測り続ける。通信が戻ると、たまったデータがまと めて届く。 この観点では、成功に届かなかったデータを、障害が終わった後にどう保存先へ戻すかを考える 12
14. 02 課題と対策 再送‧再処理を冪等にする 冪等 何回受け取っても、結果が1回分と変わらない性質 01 id: a1 id: a1 → 保存先に1件 同じデータには、同じ ID と内容を使う 再送でも再投⼊でも、event_id と測定時刻を変えない 02 保存先で重複を判定する ⼀意制約や処理済みの記録を使う。ID を付けただけでは重複は防げない 03 同じ ID で内容が違えば、エラーにする ID が同じでも、内容が変わっていないかを照合する 出典: AWS Builders' Library「Making retries safe with idempotent APIs」 SORACOM UG Hiroshima #12 | gr1m0h 13
15. 02 課題と対策 再試⾏と、復旧時の負荷を制御する 起こりうること たまったデータが⽚付くまでの時間 Thundering Herd B / (μ − λ) 多数のデバイスが同時に再接続し、アクセスが集中する Retry Storm 再試⾏が負荷を増やし、失敗と再試⾏がさらに増える 決めておくこと B 未処理の件数 λ 新しく届く件数（毎秒） μ 保存できる件数（毎秒） Exponential Backoff と jitter で再試⾏の時刻を散らす 再試⾏する層と、全体の試⾏回数の上限 再試⾏で直らないエラーは、設定を直してから再処理 μ ≤ λ なら未処理は減らない。jitter は時刻をず らすだけで、μ は増えない B / (μ − λ) は届く件数と保存できる件数が⼀定の場合の⾒積もり。出典: AWS Builders' Library「Timeouts, retries and backoff with jitter」、Google SRE Book「Handling Overload」 SORACOM UG Hiroshima #12 | gr1m0h 14
16. 02 課題と対策 設計案 観測した状態ごとに、復旧の扱いを決める 観測した状態 運⽤での扱い 復旧の確認 通信中断‧送信のタイムアウト 対象 ID を照合し、重複を考慮して再送 新しい測定値の更新、対象データの到達と内 容 保存の権限エラー 保存先‧権限を直し、退避したデータを再処 新しいデータの保存、障害中の ID と元デー 理 タの照合 復旧後も未処理が減らない 要求量‧再試⾏量‧処理能⼒を⾒直す 未処理の件数、⼀番古い未処理の待ち時間 未処理が0件でも、途中で捨てられたデータは保存先に⽋損したまま。 復旧の確認も SLI と同じく、保 存先で参照できるデータを基準にする error action は Rule action が失敗したときに元データを残す仕組み。接続認証や SQL のエラーは対象外 SORACOM UG Hiroshima #12 | gr1m0h 15
17. 02 再現 ローカルで再 現 同時2件までの保存先に、並列数を変えて送る Subscriber（並列数 8 / 2） 保存サービスへ送る。失敗したら1秒後に再配送 ↓ 並列数 8 並列数 2 要求（再送を含む） 69 45 HTTP 503 24 0 約5.16秒 約2.69秒 45件を送った結果 HTTP 保存サービス 同時2件まで（1件100ms）。超過分は HTTP 503 ↓ 全件の処理まで SQLite 結果 並列数を8にすると503と再配送が増え、2並列より全件の処理に時間がかかった ローカルで各1回。同時処理数の上限はアプリで意図的に設けたもの。構成は NATS JetStream → Subscriber → HTTP 保存サービス → SQLite SORACOM UG Hiroshima #12 | gr1m0h 16
18. ま と め IoT のデータ保存で、考えておくべき2つの観点 01 成功の定義 デバイスの「送信成功」と、⽤途ごとの期限内に保存先で参照できること を区別して確認しているか 02 ⽋損データの復旧 障害中に⽋損したデータを、重複や負荷を増やさずに戻せるか 2つとも、利⽤者が参照できる保存先のデータを基準にし、測定データごとの ID で照合する ご⾃⾝のサービスでも、この2つの観点で⾒直してみてください 17
19. References 参考資料 SORACOM Arc SORACOM Beam MQTT エントリポイント users.soracom.io/ja-jp/docs/arc/ users.soracom.io/ja-jp/docs/beam/mqtt/ AWS IoT Rules: Error action MQTT Version 3.1.1 docs.aws.amazon.com/iot/…/rule-error-handling.html docs.oasis-open.org/mqtt/…/mqtt-v3.1.1-os.html Paho MQTT Go v1.5.1 token.go Google SRE Book: Service Level Objectives github.com/eclipse-paho/paho.mqtt.golang sre.google/sre-book/service-level-objectives/ Google SRE Workbook: Implementing SLOs Making retries safe with idempotent APIs sre.google/workbook/implementing-slos/ aws.amazon.com/builders-library/… Timeouts, retries and backoff with jitter Google SRE Book: Handling Overload aws.amazon.com/builders-library/… sre.google/sre-book/handling-overload/ soratun Eventually Consistent users.soracom.io/ja-jp/docs/arc/soratun-overview/ allthingsdistributed.com/2008/12/… asdf-soracom github.com/gr1m0h/asdf-soracom SORACOM UG Hiroshima #12 | gr1m0h 18