【第1回】aliehubのOTAアップデートにおけるAWS IoTの活用方法を紹介

技術解説

はじめに

こんにちは！アクセルラボのプラットフォーム開発グループのキエンです。今回は、弊社のIoTゲートウェイ aliehubにおいて、AWS IoTを使用したOTA（Over-The-Air）アップデートシステムの実装について共有したいと思います。

aliehubは、様々なメーカーの多様なIoTデバイスを接続・管理するために設計されたIoTゲートウェイです。スマートロック、スイッチ、センサーから赤外線デバイスまで、Matterプロトコルやプロプライエタリプロトコルをサポートし、IoTデバイスとクラウドプラットフォーム間の重要な橋渡し役を担っています。

AWS IoT Coreやaliehubに馴染みのない方は、aliehubにおけるAWS IoT Coreの活用についての記事を参考にして、このプラットフォームと製品について理解を深めていただければと思います。

業界の背景と課題

IoTファームウェア管理の課題

IoTが急速に普及する時代において、分散配置された数千台のIoTデバイスのファームウェア管理とアップデートは大きな課題となっています。私たちが直面した主な問題は以下の通りです。

  • デバイスの多様性: aliehubは様々なメーカーの多様なIoTデバイスをサポート
  • 信頼性: ネットワーク経由のファームウェアアップデートは中断される可能性があり、いわゆる文鎮化する（起動不能になる）リスク
  • セキュリティ: ファームウェアが安全に転送され、改ざんされないことの保証
  • スケーラビリティ: 数千台のデバイスの同時アップデートサポート
  • 監視とロールバック: アップデート進捗の追跡とエラー時の復旧機能

OTA全体像と構成要素

OTAシステム概要

aliehubのOTAシステムは、2つの主要なアップデートタイプで設計されています。

  1. ファームウェアアップデート: ゲートウェイのメインアプリケーションアップデート
  2. サブデバイスアップデート: サブデバイスのファームウェアアップデート

OTAシステム構成図

全体アーキテクチャの構成要素：

  • Admin API：管理画面から管理者がOTAジョブを作成・監視するためのインターフェース（一括更新対応）
  • Front API：ユーザーアプリから個別デバイスのファームウェア確認・更新を行うためのAPI
  • AWS IoT Jobs：OTAジョブの配信・進捗管理を行う中央サービス
  • Amazon S3：ファームウェアパッケージとチェックサムファイルの保存先
  • MQTTブローカー（AWS IoT Core）：クラウドとデバイス間のリアルタイム通信チャネル
  • aliehub Gateway：クラウドからのOTAジョブを受信し、サブデバイスを含むローカル環境に配信・更新を行うハブデバイス

Fleet Indexingと一括アップデート

OTAシステムの重要な機能として、AWS IoT Fleet Indexingとの統合による効率的な一括アップデートがあります。

Dynamic Thing Groups:

  • 個別デバイス指定ではなくクエリ条件を使用
  • 例：attributes.firmwareVersion < "2.1.0"で古いバージョンの全デバイスをターゲット
  • 単一のジョブドキュメントで数百台のデバイスを同時アップデート可能

クエリベースターゲティング:

  • バージョン、製品タイプ、場所などの属性でデバイスをフィルタリング
  • リアルタイム条件に基づいてデバイスを自動的に含める/除外する
  • 数千台規模でのスケール時の管理負荷を最小化

Fleet Indexing用のShadow設計:

Fleet Indexingを最適化するため、IoT Coreの記事で紹介したshadow設計を適用しています。

  • Named Shadow: 各サブデバイスが個別のnamed shadowを持ち、独立した状態管理を実現
  • Unnamed Shadow：AWS IoT Core の Fleet Indexing では、インデックスに登録できる named shadow 名がアカウントあたりデフォルトで最大 10 種類に制限されているため、各サブデバイスの named shadow はインデックス化せず、unnamed shadow のみを用いてサブデバイス全体のバージョン情報を集約。

Unnamed Shadowの構造:

{
  "state": {
    "reported": {
      "SPOT_Mini": {
        "3c93": {
          "version": "0.1.2.17"
        }
      },
      "Lock_X": {
        "12a9": {
          "version": "1.2.3"
        }
      }
    }
  }
}

このアプローチにより：

  • unnamed shadowを通じてサブデバイスのバージョンを効率的にクエリ可能
  • named shadowで各デバイスの詳細な状態管理を維持
  • AWS IoT CoreのFleet Indexing制限を回避

OTAデータフロー

  1. 管理者 は 管理画面（Admin API 経由） から、クエリ条件やターゲットIDを指定して一括OTAジョブを作成
  2. ユーザー は アプリ（Front API 経由） から、更新可能デバイスを確認し、個別OTAジョブを作成
  3. AWS IoT Jobsがクエリをデバイスリストに解決してジョブドキュメントを作成
  4. aliehubがMQTT経由でジョブを受信し、S3からパッケージをダウンロード
  5. チェックサム検証とアップデート実行
  6. MQTT経由でAWS IoT Coreにステータスを報告

クラウド・デバイス間の役割分担

クラウド側の役割（AWS IoT Core + バックエンド）

AWS IoT Jobs Service:

  • OTAジョブのライフサイクルを作成から完了まで管理
  • 正しいターゲットデバイスへのジョブルーティング
  • ジョブ実行状況のリアルタイム追跡

Admin API（管理画面）:

  • クエリ条件またはターゲットIDを使用した一括OTAジョブの作成・管理
  • 管理者による複数デバイスの同時ファームウェア更新をサポート
  • 効率的なターゲティングのためのFleet Indexing統合

Front API（ユーザーアプリ）:

  • ユーザーアプリ向けの更新可能デバイス確認エンドポイント提供
  • ユーザーによる個別デバイスのファームウェア更新を許可
  • ユーザーとデバイス間のアクセス権限と所有権の検証

共通バックエンドサービス:

  • 安全な事前署名URLを作成するためのS3統合
  • OTAリクエストの検証と認証
  • 全プロセスのログ記録と監視

Amazon S3:

  • 暗号化されたファームウェアパッケージの保存
  • 検証用チェックサムファイルの保存
  • 期限付きの安全なダウンロード用事前署名URLの提供
aliehub Gatewayの役割

AWS IoT Device Client:

  • ジョブ通知を受信するためのMQTTトピックの購読
  • 対応するジョブハンドラーの実行
  • クラウドへのリアルタイムジョブステータスを報告

ジョブハンドラー:

  • メインアプリケーションのファームウェアアップデート処理
  • サブデバイスファームウェアアップデート処理

ローカル処理:

  • S3からのパッケージダウンロードと検証
  • バックアップとロールバックメカニズム
  • 必要時の再起動調整

なぜAWS IoT Jobsを選択したのか？

多くのソリューションを評価した結果、以下の理由でAWS IoT Jobsの採用を決定しました。

  • AWS IoT Coreとの深い統合: 既存のMQTTインフラストラクチャを活用可能
  • ジョブライフサイクル管理: ジョブの全状態（QUEUED、IN_PROGRESS、SUCCEEDED、FAILED）を完全サポート
  • 柔軟なターゲティング: 特定のデバイスまたはクエリによるターゲット指定が可能
  • タイムアウトとリトライ: 自動タイムアウト機能と必要時のリトライメカニズム

設計課題と技術的解決策

1. タイムアウトとエラーハンドリング戦略

OTAジョブは長時間を要し、中断されやすいという課題がありました。様々なネットワーク環境でのファームウェアダウンロードとインストール時間を分析した結果、各ジョブに30分のタイムアウトを設定し、ダウンロードとインストールに十分な時間を確保することにしました。AWS IoT Jobsのタイムアウト機能と自動リトライロジックを活用することで、この課題を解決しています。

2. プロダクト検証と安全性チェック

間違ったデバイスタイプに誤ったファームウェアをインストールすることを防ぐため、ジョブ作成前にプロダクト互換性をチェックする仕組みを実装しました。デバイスプロダクトタイプとファームウェアターゲットを検証するバリデーションロジックにより、デバイスのブリック化を防いでいます。

3. Fleet Indexingと一括アップデート戦略

数千台のデバイスを効率的に管理するため、AWS IoT Fleet Indexingとの統合による一括アップデート機能を実装しました。

Fleet Indexing制限への対応:

AWS IoT CoreのFleet Indexing制限（アカウントあたり最大10個のnamed shadowまで）により、各サブデバイスのnamed shadowをインデックス化せず、unnamed shadowのみでサブデバイス全体のバージョン情報を集約する戦略を採用しました。

このアプローチにより、unnamed shadowを通じてサブデバイスのバージョンを効率的にクエリ可能にし、named shadowで各デバイスの詳細な状態管理を維持しながら、AWS IoT CoreのFleet Indexing制限を回避しています。

次回予告

今回は、aliehubのOTAシステムの全体アーキテクチャとAWS IoT Jobsの選択理由について解説しました。次回は、このアーキテクチャを実際のプロダクション環境で運用する中で「どのような落とし穴に遭遇し、どう解決したのか」、実装の舞台裏の秘密に迫ります。どうぞお楽しみに！

📩 お問い合わせ・採用情報

本ブログを読んでいただきありがとうございます。 もし内容にご興味を持っていただけましたら、以下よりお気軽にお問い合わせ・ご応募ください。

スマートホームの導入をご検討中の企業様へ：

👉お問い合わせ - SpaceCore（スペースコア）

技術にご興味を持たれたエンジニアへ：

アクセルラボではエンジニア採用を強化しています。 私たちの技術やビジョンに共感し、スマートホームの未来を共に創っていきたい方のご応募をお待ちしています。

👉 Accel lab 採用サイト - アクセルラボのリクルートサイト