IoTサービス開発者が知るべき97のこと

※タイトルは例のシリーズのオマージュです

IoTLTアドベントカレンダーの22日目担当のimaimaiです！

IoTは総合格闘技というだけあり、様々なところで様々な問題が起こります。更に、実際にSaaSにて運用していくにはそれなりの準備が必要です。かくいう私も、3年間に渡る開発の過程で荒野に落ちる様々な地雷を踏み抜いてきました。あらゆる箇所で踏み抜いた経験や、やっていてよかったことを97個つらつらと書き連ねてみました。今後サービスを作りたい方にはチェックリスト的に、サービスを作っている方には「あーわかるー」と思いながら読んでいただけたりすると幸いです！

※ 特定の技術というよりかは、なるべく広く一般的に書いたつもりですが、技術スタックにもよりますし対象ドメインにもよると思います。iSTCは製造業向けにIoTサービスを提供していて (事業参考スライド) 、クラウド側はAWSにて構築しています (クラウド構成参考記事)

原則 

1. IoTは手段である、目的にしない
2. IoT化の価値は時間・距離制約を超える/データ連携/物理世界と情報世界の接合が可能なこと
3. 境界面では問題が起こると心得よ
4. 正解はない制約条件付最適化。選択肢を多く持ち、制約で絞る
5. 運用まで意識した選定を行う
6. KPIは成功の可否判断と対策が可能なものに。PoCなどを通じて選定する
7. 単純性は不可逆な品質。できる限り守っていく。
8. やった量ではなく、それにより産まれた結果に注目する
9. ヒアリング時は、現象を掘り下げ真のペインを見つけ出す努力をする
10. 100の進言より1のプロトタイプ。わかりやすい恩恵はさっさと作ってしまう。

ハードウェア

11. ハードウェアの在庫とリードタイムを意識したスケジューリングを
12. リードタイムの長い部品は持って複数種類選定しておく
13. 製品のEOLを考慮に入れる(突然の死も頭の片隅に)
14. 上記を考慮した管理台帳を何かしらの形で用意し、営業ツールとの連携を測る(どこに何があるかの在庫と出荷の管理)
15. ハードウェアとソフトウェアのアップデート難易度は違うことを意識する
16. 物理的な環境との適応性(防塵防爆性、耐久温度、etc...)をチェックする
17. マイナーアップデートなどが起こってカオスになりがちなので、型番とバージョンをつけて管理する

センサ

18. センサチェック項目を参考にする。 参考 : エンジニアに聞く、センサー選びの要所
19. データのチャタリングに気をつける。(フォトカプラなどを噛ますなど)
20. アナログセンサ/デジタルセンサの特性を理解しておく(変換の必要性、サンプリング周期など)
21. 出力が線形でない可能性があるので注意(linearityチェック)
22. センサ自体が電源を必要とするかどうかチェックする。
23. 設置する固定具が一般には用意されていないので、制作もスケジュールに入れておく
24. 固定具には3Dプリンターで自作や、試作では樹脂ねんどなどを使用するとよい
25. 現場でセンサを設置する際、手元で動作確認のできる携帯型のチェッカーを用意
26. 電池で動作させるときは省電力のため、大きめの抵抗を置きプルアップ電流を押さえるようにする(ただし大きすぎるとノイズに弱くなるので注意)
27. 電池駆動設備は電池寿命時に警告ランプなどを出せる仕組みを装備する
28. 半導体センサは温度特性（高温で感度が落ちる）があるので注意する

ゲートウェイ・SIM

29. AC電源を必要とする場合、導入説明時に終夜電源を推奨する。
30. 場所によっては熱・スス・油などがあるので、できるだけ防塵防水などのシールをする
31. 再起動時に滞りなくスクリプトが起動するようにsystemctlなどを仕込む
32. 時刻が狂うと処理も狂う。NTPサーバなどに問い合わせて、定期的に時刻合わせをする
33. 定期アップデートをどうするか(OTAで行う or 外部との通信を断つ(VPN経由のみの接続))を決める
34. エッジコンピューティングを行う場合はOTAのアップデートがほぼ必須になる
35. ゲートウェイの障害対応をどうするか(sshで入ってバグ対応 or センドバック方式 or etc…)かを決める
36. SIMプランは用途に応じて(太く短くor細く長く)。例 : 少しずつ24時間トラフィックが流れる場合、従量課金だと微妙な場合がある。(128kb/sには収まるけど、月10GBはいくとか)
37. セキュリティが要求されるところはVPNを張るか通信を暗号化するなどの対策を講じる
38. HTTP/MQTTはそれぞれの良し悪しを把握して選定する(MQTTはヘッダが軽く双方向で、センサデータ通信には良い。HTTPは既存のRESTの形態が使えるのでとっつきやすい)
39. 通信方式に合わせて後段のアーキテクチャも変える必要があるので注意する
40. GWのセルラーモジュールによってはSSHできないものもあるのでチェック(インターフェース型など)
41. SIMの通信が切れたときのために、センサーデータを一時的に吐き出すバックアップ処理をつくる
42. 外部からの無線通信が切れた場合のために、ロガーや監視の仕組みを入れる(エッジでもクラウド上でも良い)
43. センサー→GWの到達時刻とGW→クラウド到達時刻は一致しない(レイテンシがある)ので、どちらも用意しておいたほうが良い

通信モジュール/マイコン

44. 本気の量産化の知見を知っておく 参考1.IoT設計製造のテンプレ・ガントチャート 参考2.メイカーとスタートアップのための量産入門
45. 用途に応じて通信方式をきちんと選ぶ。参考 : IoTの中核部分「通信技術」の奥深さと可能性に迫る
46. 障害がどこかを切り分けるために、ゲートウェイ、送信機共にハートビートを送るようにする
47. マイコン系のコード管理を疎かにするとバグのトレースで面倒なことが起こる。バージョン管理をする(GitHubなど)
48. 製品の説明のために、センサがデータ取得できているかの部分と、取得したデータをGWに送れているか(欠損率)をデータとして取っておく
49. 欠損の原因は、電波干渉/マイコン性能不足/データ衝突などがあるので切り分ける
50. ペアリングはどういう手続きで行われるかチェック。後々ゲートウェイに紐づく送信機を増やすコストを意識
51. 電池残量がわかるように残量も情報として載せて送ると運用上良い
52. 海外展開は各国の電波法が異なる。他社との連携を強化して対応できるようにする
53. 複数台に拡張することを考え、一意に定まるIDを準備/利用する(MACアドレスから引っ張ってくるなど)
54. 周波数帯によってはWiFi等と干渉し、展示会等で思った以上のパフォーマンスが出ないこともあるので注意。場合によっては有線でも良い

アプリ/クラウド

55. センサデータ処理系がボトルネックになることが多いので注意する
56. 各要素を接合している限りサンプリング定理からは逃れられない。1sに1回の処理を3つつなぐと最大3sの遅延。
57. あまりに遅延が重なるようならイベント駆動型を考える
58. (特にセンサデータ収集部で)処理に対するリソース消費が時間によってどう変化しているのかを把握しておく(O(N) or else)
59. 深刻な影響を及ぼすのは計算処理ロジックの不整合なので、テストづくりにきちんと時間を割く
60. データ収集と分析とを考えるとき、ラムダアーキテクチャは相性が良い
61. 高速な応答が必要な部分はキャッシュを行う(コンテンツキャッシュ/KVSのキャッシュなど)
62. データのTTLを決定し、キャッシュ・DB・ストレージへの流れを設計する
63. コンテナとオーケストレータを活用し、スケーラビリティと冗長性を確保すると運用しやすくなる
64. 後々の運用を考えて、活用できるクラウドベンダのマネージドサービスは使う(ロックインしたくない場合は要考慮)
65. RDBはコネクションの枯渇とインデックス未貼付による性能劣化に注意。
66. データ取得処理はN+1問題に注意する
67. 処理要件がある程度決まっている、マスタが重要なデータだとRDBで設計しSQLで処理が相性がよい(気がする)。
68. クラウドベンダの責任範囲を踏まえた上でのセキュリティ対策を講じる
69. データの保存先を気にする顧客もいる。特に海外展開時のリージョンは注意が必要
70. サーバーパフォーマンスチェックはdstatというのがかなり見やすく網羅的で良い(参考 : Dstat)
71. リアルタイム部分は整合性より速さ重視なのでCQRSを意識してデータ操作部と更新部を分離すると良い

フロントエンド/UI設計

72. 実物あるのと無いので相手の印象が変わるので、スケッチレベルでも作るとスムーズ。
73. リアルタイム性がどこまで必要なのか、顧客の気持ちとコンピュータの気持ちになって考える(すでにフロントまでに様々な遅延が重なっている場合も考慮する)
74. ドメイン/バックグラウンドによって慣れているUIは違うもの。製造業だとqwertyよりあいうえお順に並んだキーボードのほうが使いやすいという意見もあったりする
75. かっこいいデザインとわかりやすいデザインは違うので、対象ドメインを意識する
76. 製造業だとアプリ内のみで操作が閉じないことも多い(紙の出力文化)ので、印刷画面やCSV出力を用意すると良い
77. ボトルネック箇所を同期処理させていないかチェックする(あれば非同期やLazy load)
78. 装飾に余分な意図を持たせない。意味・意図で分ける
79. 処理の高速化は顧客満足度に直結するので最優先に対応する
80. ただし一度処理を早くしすぎると少し遅くなってクレームがくるので、初手でパフォーマンスをあげすぎるのも考えもの
81. フロントとバックエンドは分離してAPIでつなぐほうがベター(後々の仕事の割り振り的に)
82. ロード時に何も出さないのとNow Loading...を出すのとで変わる。我慢して待ってもらえるようになる

開発・運用

83. テスト書く。後々絶対助けられる。
84. 本番環境を模擬したデータを投入するシミュレーション環境を作ってテストを行うことでバグ発見/消去の効率化を測る
85. ステージングとプロダクション環境を切り分けて進める。
86. β版を一部公開してPoCができる環境を作れるとベター(A/Bテスト的な)
87. デプロイ時にダウンタイムが発生しないよう、ブルーグリーンデプロイメントなどを活用する
88. マイクロサービスだとトレースが難しいので、予め見れるように設定しておく(Xrayなどの分散トレーシングを用いる)
89. GitHub Actionsなどのトリガーをうまく使うとスムーズにデリバリできる
90. (特に製造業)は土日が休みとは限らないので注意。また、GW/お盆/正月が大規模メンテチャンス
91. 疎結合にしておいてサービスメッシュなど用意すると、別言語でも開発を並行して進めやすくなる
92. 詳細アクセスログを仕込み、ABテストなどの結果の解像度を上げる
93. アラート疲れが起こるのでアラートは深刻なものだけ通知できるなどの階層をつける
94. なるべくすべての情報が集約された仕様書を作っておく。更新を忘れずに。
95. 同じ問題を二度起こさぬよう、ポストモーテムを実施する
96. 大規模リリース時には開発と同時にLPの準備/名前・価格の決定/プレスリリースの準備なども忘れずに仕込む。結構時間がかかる。
97. 人が作っているものなので、なんだかんだ緊急時/追い込み期は面着でのコミュニケーションがとても大切。人との信頼関係は大切に、誠実に向き合う。

まとめてみて、

やはりいろんな技術を組み合わせて1つのサービスができているんだなと改めて実感しました。主観も入っているので参考程度になればと思います！

ちなみにこの記事を社内で共有すると、どんどんノウハウが増えていき、もはや97には収まらず秘伝のタレのようになっております！作っていく過程でいろんなことを学んでいたんだなあと改めて気付かされました。たまに振り返ってまとめるのは大事ですね。ではではっ