AWS IoT Analytics

解決する課題

• IoTデバイスから上がる大量で不揃いな生データを、欠損や外れ値を含んだまま分析するのが難しい
• データの前処理（フィルタ・補完・変換）のパイプラインを、ETL基盤を自前で構築せずに用意したい
• センサーデータを時系列に蓄積し、SQLやノートブックで分析・可視化できる状態にしたい

主要概念と用語

• チャネル（Channel）: 生データを受け取って未加工のまま貯める入り口。IoT Coreのルールや直接送信でメッセージを取り込む
• パイプライン（Pipeline）: チャネルのデータに前処理を順に適用する処理の連なり。フィルタ、属性の追加・削除、Lambda呼び出し、メッセージの補完などのアクティビティを並べる
• データストア（Data Store）: パイプラインを通った処理済みデータを蓄積する保存先。ここに溜まったデータがクエリの対象になる
• データセット（Data Set）: データストアに対するクエリ結果。SQLで抽出するSQLデータセットと、コンテナで処理するコンテナデータセットがある
• アクティビティ（Activity）: パイプライン内の個々の処理ステップ。メッセージの選別や項目の変換、外部ロジックの呼び出しを担う
• メッセージの補完（Enrichment）: デバイスレジストリの属性などを参照し、メッセージに文脈情報を付け足す処理

仕様・制限・クォータ

• 提供終了前は、チャネル → パイプライン → データストア → データセットという一方向の構成だった
• IoT CoreのルールやAPIで取り込み、フィルタ・補完・Lambda変換後にSQL等で分析していた
• 2025年12月15日以降はコンソール、API、リソースへアクセスできないため、この構成を新規利用できない
• 移行後は各サービスのメッセージサイズ、配信速度、保持期間、再試行、同時実行のクォータを個別に確認する

内部の仕組み

横にスクロール

提供終了前のAWS IoT Analyticsは、IoTデータを分析可能な状態へ整える一連のデータパイプラインでした。チャネルが生データを受け取り、パイプラインがフィルタ、属性変換、Lambda処理、レジストリ情報の補完を順に適用していました。

処理済みデータはデータストアへ蓄積され、データセットとしてSQLやコンテナ処理へ渡されていました。移行では、この名称をそのまま再現するのではなく、取り込みをIoT Core、配信をData Firehose、保存をS3、カタログをGlue、問い合わせをAthena、可視化をQuick Suiteというように責務へ分解します。

設計パターン / ベストプラクティス

• 取り込みと保存を先に切り替える: IoT CoreのルールからData FirehoseやS3へ並行出力し、欠損なく保存できることを確認する
• 変換は再実行可能にする: LambdaやGlueの処理へ入力識別子を渡し、再試行しても重複しないようにする
• 生データを不変で残す: 変換後だけでなく、元のペイロードと受信時刻をS3へ保存して再処理に備える
• スキーマ変更を分離する: Glueの表定義を版管理し、古い端末と新しい端末の形式を同時に読める移行期間を置く
• 新旧結果を照合する: 件数、最小・最大時刻、代表集計を比較してから旧処理を廃止する

運用・監視

• IoT Coreのルール失敗、Data Firehoseの配信失敗、S3への到着遅延をCloudWatchで監視する
• 失敗レコードをS3の隔離領域へ退避し、原因修正後に再処理できるようにする
• Athenaの実行失敗と走査量、Glueのスキーマ変更、Quick Suiteの更新失敗を個別に監視する
• 端末送信数、受信数、保存数、分析対象数を突き合わせ、経路ごとの欠損を検知する

コスト

• IoT Analyticsの料金ではなく、IoT Core、Data Firehose、Lambda、S3、Glue、Athena、Quick Suiteを個別に見積もる
• S3の圧縮・列指向形式とライフサイクル、Athenaのパーティションで保存量と走査量を抑える
• 再試行や二重配信にも費用が発生するため、失敗率と重複率をコスト監視へ含める

セキュリティ

• 移行先のIoT Core、Data Firehose、Lambda、Glueには最小権限の実行ロールを設定し、受け渡すS3プレフィックスや暗号鍵を限定する
• 退避した生データ、変換定義、SQL、移行台帳はS3で暗号化し、保持期間と削除権限を分ける
• 通信はTLSで保護し、KMS鍵を使う場合はサービスごとの復号・データキー生成権限を必要な経路だけに許可する
• CloudTrailと各サービスの配信ログを保存し、移行後の構成変更と失敗レコードの再処理を追跡できるようにする

関連サービス・比較

移行後の確認例

# 移行先S3の保存件数と最新オブジェクトを確認
aws s3api list-objects-v2 \
  --bucket <telemetry-bucket> \
  --prefix raw/ \
  --query "{Count:KeyCount,Latest:reverse(sort_by(Contents,&LastModified))[0]}"

# Athenaの移行後クエリ実行状況を確認
aws athena list-query-executions \
  --work-group <work-group> \
  --max-results 10