IoTの沈黙をどう検知する？Web系エンジニアが挑んだ苦難と改善記録

大西時雨

株式会社hacomono IoT本部 BackendDev

2021年8月にhacomonoに入社し、SREエンジニアとして香川県の離島からヤギを育てながらフルリモートで働いています。 新卒でWebデザイナーとしてIT業界に飛び込み、その後バックエンドエンジニア、インフラエンジニアを経験しており、最近はIoTに関わることが増えてきました。

タイトル：IoTの沈黙をどう検知する？Web系エンジニアが挑んだ苦難と改善記録
IoTサービス運用に挑戦した際に痛感したのがサーバ運用とは違う「デバイス運用の難しさ」でした。 本セッションでは、主に入退館デバイスを題材に、Web系エンジニアが運用改善・死活監視・状態検知を可能にしていくための苦難を紹介します。

https://hacomono.connpass.com/event/351264/

Transcript

1. Last Update 2022.03.16 IoTの沈黙をどう検知する？ Web系エンジニアが挑んだ苦難と改善記録
2. 2 自己紹介 • 大西 時雨(オオニシ シグレ) ◦ GitHub @a4t ◦ X(旧Twitter): iwanomoto • 経歴 ◦ 新卒: Webデザイナー ◦ 徐々にWeb系Backendエンジニア ◦ 10年ぐらいWeb系SRE (インフラ系) ◦ 前職はIoTデバイス開発 (1年間) ◦ hacomonoでは1年ぐらいIoTデバイス開発 • ビジネス領域 toCからtoBに徐々に移行
3. 3 会員管理・予約・振替・キャンセル・決済・請求管理・売上管理・債権管理 入退館・EC・POS・本人認証カメラ・QRリーダー・ ・総合フィットネスクラブ ・ヨガ・ピラティス ・パーソナルジム ・24時間ジム フィットネスクラブ ・屋外運動場 ・屋内運動場 ・体育館 ・水泳プール ・学校 ・レジャー施設 公共運動施設 ・Jリーグ（サッカー） ・Bリーグ（バスケットボール） ・野球チーム・サッカーチーム etc スポーツチーム ・スイミングスクール ・ダンス・バレエスクール ・ゴルフスクール ・テニススクール ・カルチャースクール ・空手・体操スクール ・サッカースクール 運動スクール ウェルネス施設の手続きをすべてデジタル化 ウェルネス産業を、新次元へ。
4. 約9,000店舗・施設での導入実績 ヨガ・ピラティス パーソナルジム 24時間ジム 総合スポーツクラブ 運動スクール プロスポーツ（サッカー・バスケ） 公共運動・学校施設 ゴルフ サウナ・エステ コワーキング
5. 　　　　　 5 Confidential Corporate Book 組織構成 Engineering Organization Product データ デザイン 開発 基盤 CTO室 IoT データ戦略部 UX部 運用保守部 モバイル部 SRE部 プラットフォー ム部 インターン CTO室 QA部 リアーキテク チャ＆イネー ブルメント部 Engineering Office部 IoT部 デザイン部 フルタイム 128名 業務委託 32名 （2025年3月現在） PM PM部 新規事業 開発室 データ基盤部 新規事業 開発室 情報 システム サポート サポート部 フィーチャー 部 情報 システム部
6. 6 hacomonoのIoT部 ミッション 「hacomonoが提供するサービス体験の多角化と最大化のためのアフターデジタルデバイスの開発 ・提供」 プロダクト Lock QR 入退館システム Lock Wireless スマートロック Link デバイス連携 KeyBox 鍵ボックス AIカメラ 人物検知カメラ
7. 7 Lock QR - 入退館 1 2 3 予約 Webサービス上から予約 来店 予約時間に「QRコードかざす」 解錠 予約確認できたらドアが開く 入館の流れ
8. 8 Lock Wireless - スマートロック 1 2 3 予約 Webサービス上から予約 来店 予約時間になると「解錠ボタン」 がスマホに表示 解錠 予約確認できたらドアが開く 入館の流れ
9. 9 AIカメラ - 人物検知カメラ 1 2 3 検知 エッジデバイスで検知、一次解析 解析 クラウド側で分析・集計 アクション 分析結果を元にアクションを起こす 運用の流れ
11. Lock QRを中心した苦難の紹介 難しさ
12. 12 Lock QR - 入退館 1 2 3 予約 Webサービス上から予約 来店 予約時間に「QRコードかざす」 解錠 予約確認できたらドアが開く 入館の流れ
13. 13 Lock QR - 入退館 1 3 4 予約 Webサービス上から予約 来店 予約時間に「QRコードかざす」 解錠指示 権限があれば解除指示 hacomonoはドアを作ってない 2 解錠 デバイスからの指示でドアを開ける
14. Webサービスとの違い 難しさ
15. 入力装置の違い 難しさ
16. 16 入力装置の違い 明るさ 屋外の設置による太陽光 スマホ画面の明るさ 角度・距離・読み取り精度 QRリーダーに対して斜め 近すぎて読み取れない QRリーダーの精度が悪い PC・スマホはキーボードとマウス、IoTは？
17. 環境の違い 難しさ
18. 18 環境の違い 野ざらし 雨に打たれる 太陽光の紫外線劣化 害虫 虫の内部侵入 デバイス破壊 サーバールームのような綺麗な環境ではない SLA 99.9%？なにそれ？
19. 出荷後の修正の難しさ 難しさ
20. 20 出荷後の修正の難しさ デプロイ ローリングアップデートとかできない 失敗したら文鎮化の可能性 再起動 反映するのに再起動が必要 しかし再起動すると起動しないことも (電力不足・SDカード不良) 安易にUpdateを行うと危険 起動しないと遠隔操作もできないので詰み
21. 21 実際に起こったトラブル • SDカードが割れる • 店舗のネットワーク不調なのに、hacomonoに問い合わせきてしまう • ドア付近のポスターのQRコードを読み取ってしまう • エアコンを送風口をバーコードとして認識する
22. 22 実際に起こったトラブル • SDカードが割れる • 店舗のネットワーク不調なのに、hacomonoに問い合わせきてしまう • ドア付近のポスターの QRコードを読み取ってしまう • エアコンを送風口をバーコードとして認識する
23. 23 ドア付近のポスターにある QRコードを読み取ってしまう 道路沿いの屋外設置だとトラックやタクシーのボディの QRコードに反応 自動ドアに貼られたポスターでドア開閉のたびに反応 ピピッ
24. 24 エアコンを送風口をバーコードとして認識する QRコード + 二次元バーコードを読み込むリーダーを使用 エアコンの送風口をバーコードとして読み込んでしまう 常にデバイスが鳴り響くのでうるさいと問い合わせ発生 ピピッ
25. トラブルが起こった時の影響 被害
26. 26 トラブルが起こった時の影響 hacomonoは解錠指示を出しているだけ 閉じ込めには本来関与していない デバイス故障、ネットワーク切断で出れないは そもそも消防法的に問題アリ けど、 退館時間はしっかり取りたい 店舗に来たのに入れない 時間を開けてたのに・・・ 毎日の日課が・・・ 店舗から出れない 店舗に閉じ込められた！ このあと約束が・・・
27. リテラシーとか店舗の運営体制とか 運用
28. 28 リテラシーとか店舗の運営体制とか 24時間365日の稼働要 求 無人店舗に設置されるシステムは常時稼働が大前提 運用レベルは toB >>>>>>>>>> toC で厳しい運用基準が求められる 予測不能な物理的障害 停電・ダンベルの衝突など想定外の物理的ダメージが発生 機器は必ず壊れるという前提で開発設計・運用設計を行う 顧客の理解不足 エンジニアは特殊で、普段から故障のことを考えて運営していない (バックアップ・フェイルセーフなど) 非常時は ◯◯ に電話と掲示 → 電話先が24/365運用されてない
29. 29 リテラシーとか店舗の運営体制とか システム・デバイス設計の改善 顧客理解・運用場所を想定した設計 運用体制の整備 顧客リテラシーの向上 設計でカバー出来ない範囲を補填する体制構築 顧客の理解・協力の元に盤石な体制構築 顧客は運用を楽にしたいからSaaSを導入 運用が大変になるものは 製品の設計として貧弱 数万台一台や二台はトラブルを引くと考えがち、当事者から見れば 発生率100%
30. よくある失敗・悩み 設計
31. デバイスの状態と不一致 設計
32. 32 デバイスの状態と不一致の失敗 デバイス 管理画面
33. 33 デバイスの状態と不一致 しきい値によるアラート 電池残量の通知設計 電池残量が20%以下の時にデバイスから電池交換を通知 管理画面上の表示で 電池交換推奨状態に変更させる ネットワーク切断状態時に発生 通知がクラウドに対して届かない 再送の仕組みがない 状態の不一致 デバイスは 電池交換推奨状態 クラウドは 正常稼働状態
34. 34 デバイスの状態と不一致の失敗 デバイス 管理画面 通信断
35. 35 デバイスの状態と不一致 このタイミングでネットワークが不通
36. 36 デバイスの状態と不一致の改善点 エッジ側に処理を寄せすぎた ことが失敗点 デバイスのアラートを送るのではなく 状態を定期的に送る といった設計にしておくと良い クラウドならしきい値などもTry & Errorで変更しやすい 状態のズレも発生しない CPU 20% MEMORY 60% BATTERY: 20%
37. ネットワークトラブル？電源断？故障？ 設計
38. 38 ネットワークトラブル？電源断？故障？ デバイスとハートビートを行って監視 しかし 途絶えた時の調査が難しい
39. 39 ネットワークトラブル？電源断？故障？ 考えられるトラブル 1. ネットワークトラブル 2. デバイスの故障 3. 電源断
40. 40 ネットワークトラブル？電源断？故障？ 解消をするには以下の行動を順番に行う
41. 41 ネットワークトラブル？電源断？故障？ 解消をするには以下の行動を順番に行う 無人店舗で どうやって？
42. 42 ネットワークトラブル？電源断？故障？ デバイスの不具合: 生産側の責任 電源断やネットワークトラブル: 店舗側の責任 しかし区別がつかない、行ってみないとわからない 店舗の担当者も現地まで1時間以上かかるような場所にいる 契約も含めた事前の運用設計が重要 必ず揉め事に繋がる
43. 43 ネットワークトラブル？電源断？故障？ コスト NW 電源 故障 全国かけつけサービス 💰💰💰💰💰💰💰💰💰 ⭕ ⭕ ⭕ スタンバイのデバイス 💰💰💰💰 ❌ 🔺 ⭕ 無停電電源装置 (UPS) 💰💰💰💰 ❌ ⭕ ❌ 非常用回線 💰💰 ⭕ ❌ ❌ 監視専用デバイス 💰 ❌ 🔺 🔺 何を選ぶかはコストと効果次第・正解はプロダクト次第 オンラインのアーキテクチャで解決できないなら、物理的なアーキテクチャも考える
44. IoTデバイスの「 Internet」のあり方 設計
45. 45 IoTデバイスの「 Internet」のあり方 ネットワーク関連のトラブルは高頻度で起こる • 通信先のAPIが落ちている • 回線自体が切れている • IPv6 ↔ IPv4の切り替わり
46. 46 IoTデバイスの「 Internet」のあり方 「Internet」がなくなった時の設計がとても重要 家の鍵が開かない可能性がある製品なんて買いたくない • 物理鍵で開けれる設計にする • オフラインの接続でも開けれる設計にする • PINコードで開けれるようにする 基本設計はスタンドアローン +αの機能がInternetにあると考える 短時間のネットワーク切断は耐えうる設計にする hacomono Lock Wireless
47. 最後に まとめ
48. 48 最後に IoTとはいえWeb系のエンジニアの知識は十分に活かせる ただ、戦場はクリーンなサーバールームや Elasticな環境ではない SLAのとても低いサーバ使っていると考えてコストと天秤にかける いつもサーバは壊れるという前提で設計している皆さんなら、 IoTのデバイスでも大丈夫
49. ご清聴
 ありがとうございました