はじめに
こんにちは！アクセルラボのプラットフォーム開発グループのキエンです。 前回は、弊社のIoTゲートウェイ「aliehub」におけるOTA（Over-The-Air）アップデートシステムの全体アーキテクチャと、なぜAWS IoT Jobsを選択したのかという設計判断について解説しました。
連載第2回となる今回は、そのアーキテクチャを実際のプロダクション環境で運用する中で「どのような落とし穴に遭遇し、どう解決したのか」、実装の舞台裏に迫ります。AWS IoT Jobsの制限に直面した時の対処法や、エラーハンドリングの進化過程など、IoTシステムの実装に携わる技術者の方や、大規模IoTデバイス管理に関心のあるプロダクトマネージャーの方に、特に参考にしていただける内容です。
実装の困難と解決方法
ジョブドキュメント生成の複雑さ
遭遇した問題
OTAシステムの実装初期段階で、最初に直面した大きな壁がジョブドキュメントの生成でした。AWS IoT Jobsでは、各デバイスに送信するジョブの詳細をJSON形式のドキュメントで定義する必要があります。
当初、私たちは手動でこれらのドキュメントを作成していましたが、すぐに問題が明らかになりました。ファームウェアパッケージのS3 URLは署名付きURLである必要があり、有効期限があります。さらに、デバイスタイプごとに異なるパラメータ（インストールスクリプト、チェックサムファイルなど）を含める必要がありました。
初期のテストでは、手動作成したジョブドキュメントの約30%で何らかのエラーが発生していました。URL の記述ミス、チェックサムファイルパスの間違い、デバイスタイプに適していないパラメータ設定など、人的ミスが頻発していたのです。
解決方法
この問題を解決するため、ジョブドキュメント生成を完全に自動化するコンバーター関数を開発しました。以下の処理を行うシステムを構築しました。
- 自動URL生成: ファームウェアパッケージのS3パスから、適切な有効期限（24時間）を持つ署名付きURLを自動生成
- デバイス固有設定: デバイスタイプに応じた適切なインストールスクリプトとパラメータを動的に選択
- 整合性チェック: チェックサムファイルの存在確認と署名付きURL同時生成
- JSON構造化: すべての情報を統合してAWS IoT Jobs形式の正確なJSONドキュメントを作成
この自動化導入後、ジョブドキュメント関連のエラー率は大幅に減少し、新しいデバイスタイプのサポート追加も数分で完了するようになりました。
Fleet Indexingの制限との戦い
遭遇した問題
システム開発過程で、AWS IoT Core Fleet Indexingの重要な制限を発見しました。AWSアカウントあたり、Fleet Indexingでインデックス化できるnamed shadowは最大10個までという制限です。
この発見は、私たちにとって青天の霹靂でした。aliehubシステムでは、各サブデバイス（ロック、スイッチ、センサーなど）が独自のnamed shadowを持っており、設計上多種類のサブデバイスタイプをサポートする予定でした。この制限により、「特定のファームウェアバージョン以下のすべてのデバイス」のような条件でのバルクアップデートが不可能になる危機に直面しました。
解決方法
この問題に対して、最終的にハイブリッドシャドウ戦略を考案しました。
- Named shadow: 各サブデバイスの詳細な状態管理に継続使用（Fleet Indexing対象外）
- Unnamed shadow: Fleet Indexing専用として、すべてのサブデバイスのファームウェアバージョン情報を集約
Unnamed shadowの構造は以下のようになります。
{ "state": { "reported": { "SPOT_Mini": { "12a9": {"version": "0.1.2.17"}, "34b1": {"version": "0.1.2.15"} }, "Lock_X": { "56c3": {"version": "1.2.3.4"} } } } }
この戦略の実装により、Fleet Indexingの制限を回避しながら、効率的なバルクアップデート機能を実現できました。現在では、デバイス台数の拡張に対応できるクエリベースの一括アップデートシステムが構築されています。
エラーハンドリングとデバッグの改善
遭遇した問題
システムの初期バージョンでは、OTAジョブが失敗した際の原因特定が非常に困難でした。AWS IoT Jobsは基本的なステータス（成功/失敗）は提供しますが、失敗の詳細な理由は各デバイスからの報告に依存します。
デバイスからは単純に「失敗」という報告しか来ないことが多く、ネットワークエラーなのか、ストレージ不足なのか、チェックサム不一致なのかが分からない状況でした。
解決方法
信頼性向上のため、以下の機構を実装しました。
- タイムアウト設定: サブデバイスOTA操作に15分のタイムアウトを設定し、ネットワーク遅延処理用に5秒のバッファを追加
- パッケージ抽出リトライ: パッケージ抽出失敗時に最大5回のリトライロジックを実装し、一時的なネットワーク問題に対応
- チェックサム検証: インストール前にダウンロードしたパッケージのMD5チェックサムを自動検証し、データ整合性を保証
- ポーリング機構: 5秒間隔のポーリングで最大180回チェックし、OTA完了ステータスを監視
これらの改善により、OTA操作の成功率が大幅に向上し、問題発生時の根本原因特定が容易になりました。
学んだ教訓とベストプラクティス
運用監視の重要性
開発・テスト過程を通じて、単にOTAジョブが成功したかどうかだけでなく、以下の指標を継続的に監視することの重要性を学びました。
- ジョブ実行時間の分布: 通常は数分から十数分だが、ネットワーク環境により大幅に時間がかかるケースも
- エラータイプ別の発生頻度: ネットワーク関連のエラーが多くを占めることが判明
- デバイスタイプ別の成功率: 特定のハードウェアで特有の問題があることを発見
- 地域・環境別のパフォーマンス: ネットワーク環境による差異を確認
これらの監視データにより、プロアクティブな改善施策を実施できるようになりました。
セキュリティとコスト最適化のバランス
署名付きURLの有効期限設定は、セキュリティとコストのバランスを取る重要な要素でした。短すぎると低速ネットワーク環境でダウンロードが失敗し、長すぎるとセキュリティリスクが増加します。
テストデータを分析した結果、大多数のデバイスは比較的短時間でダウンロードを完了できることが分かりましたが、一部のデバイスは長時間を要するケースもありました。今後、デバイスのネットワーク状況を事前に評価し、動的に有効期限を調整する仕組みの導入を検討しています。
まとめ
aliehubのOTAシステム実装は、技術的な課題だけでなく、運用面での多くの学びをもたらしました。AWS IoT Jobsは強力なプラットフォームですが、実際の開発・テスト環境でも予期しない制限や課題に遭遇することがあります。
重要なのは、これらの課題を一つずつ丁寧に解決し、システムの信頼性と保守性を継続的に改善することです。現在では開発・テスト段階でのOTAジョブが安定稼働しており、将来の商用展開に向けた準備が整いつつあります。
今回紹介した経験が、同様のシステムを構築する他のチームの参考になれば幸いです。特に、AWS IoT Fleet Indexingの制限やエラーハンドリングの重要性について、私たちが学んだ教訓を活かしていただければと思います。
おわりに
2つのパートにわたってaliehubのOTAシステムについて紹介してきました。Part 1でアーキテクチャと設計判断、Part 2で実装の具体的な課題と解決策をお伝えしました。
IoTデバイスのOTAシステムは、単なる技術的な実装を超えて、ユーザー体験、運用効率、セキュリティなど多角的な視点での設計が必要です。私たちの経験が、IoT業界全体の発展に少しでも貢献できれば幸いです。
最後までお読みいただき、ありがとうございました。
📩 お問い合わせ・採用情報
本ブログを読んでいただきありがとうございます。 もし内容にご興味を持っていただけましたら、以下よりお気軽にお問い合わせ・ご応募ください。
スマートホームの導入をご検討中の企業様へ：
技術にご興味を持たれたエンジニアへ：
アクセルラボではエンジニア採用を強化しています。 私たちの技術やビジョンに共感し、スマートホームの未来を共に創っていきたい方のご応募をお待ちしています。
