IoT デバイスから送られるデータは、収集して終わりではありません。分析基盤に保存する、異常検知に使う、関数で処理する、メッセージ基盤から複数のシステムへ分岐するなど、後段の使いかたに合わせて流し方を設計します。
このページでは、デバイスから SORACOM へ送信したデータを、クラウドサービス、ストレージ、関数、メッセージ基盤へ流すときの設計を整理します。クラウド別の具体的な手順は、ボタンデバイスのクラウド別連携パターン を参照してください。
このページが役立つケース
- デバイスからクラウド分析基盤、ストレージ、関数、メッセージ基盤へどうデータを流すか決める場合。
- SORACOM Beam、SORACOM Funnel、SORACOM Funk の役割を整理する場合。
- デバイス側にクラウド SDK、証明書、アクセスキーなどを持たせる範囲を減らす場合。
- 単一のクラウド連携ではなく、データを後段の複数用途へ分岐する構成を検討する場合。
- AWS IoT Core、Amazon Kinesis Data Streams、Amazon Data Firehose、Azure Event Hubs、Google Cloud Pub/Sub などのメッセージ基盤やストリーム基盤を、SORACOM とどう組み合わせるか整理する場合。
まずデータの流れを分けて考える
データパイプラインは、最初に 3 つの領域に分けて考えます。
| 領域 | 決めること | 主な確認事項 |
|---|---|---|
| デバイスから SORACOM まで | デバイスがどのプロトコル、どのデータ形式で送るか。 | HTTP、TCP、UDP、Unified Endpoint の利用、バイナリパーサーの利用、データサイズ。 |
| SORACOM での転送 | Beam、Funnel、Funk のどれで接続先へ渡すか。 | 転送先の種類、同期 / 非同期、認証情報の置き場所、1 グループあたりの転送先。 |
| クラウド側の後段処理 | 単一用途で処理するか、複数用途へ分岐するか。 | ストリーム処理、蓄積、関数実行、通知、分析、重複や順序の扱い。 |
デバイス側では、送信先を Unified Endpoint などのデータ送信先に固定しておくと、接続先の変更や認証情報の変更を SORACOM 側で扱いやすくなります。転送先を変えるたびにファームウェアを変更しにくい場合や、多数デバイスを同じ方針で管理する場合に有効です。
Beam、Funnel、Funk を選ぶ
転送先の種類で選ぶ
最初に、データをどこへ渡すかで候補を絞ります。
| サービス | 向いている転送先 | 向いているケース |
|---|---|---|
| SORACOM Beam | 任意の HTTP / HTTPS サーバー、TCP / TCPS サーバー、MQTT / MQTTS ブローカーなど。 | 任意の API やサーバーへ転送する。送信先が複数あり、HTTP エントリポイントなどで振り分ける。転送先のレスポンスをデバイスで受け取る。 |
| SORACOM Funnel | アダプターが用意されたクラウドサービスやパートナーサービス。 | AWS IoT Core、Amazon Kinesis Data Streams、Amazon Data Firehose、Azure Event Hubs、Google Cloud Pub/Sub などへ、デバイス側 SDK なしでデータを渡す。 |
| SORACOM Funk | AWS Lambda、Azure Functions、Google Cloud Functions などの FaaS。 | 受信したデータを関数で処理し、必要に応じて関数のレスポンスをデバイスに返す。 |
Beam、Funnel、Funk は、いずれもデバイスから SORACOM までの通信と、SORACOM から転送先までの通信を分けて設計できます。デバイス側は HTTP、TCP、UDP などの比較的シンプルな送信に留め、SORACOM 側で TLS、認証情報、転送先の設定を扱う構成にできます。
デバイス側プロトコルも選定条件に含める
デバイス側で使える通信プロトコルは、サービス選択時の前提条件です。ただし、対応プロトコルだけでサービスを決めず、転送先の種類、同期応答の要否、データ形式、後段での分岐方法を合わせて判断します。
| 観点 | Beam | Funnel | Funk |
|---|---|---|---|
| デバイス側から使う主な入口 | HTTP、TCP、UDP、MQTT など。 | TCP、UDP、HTTP。 | UDP、TCP、HTTP。 |
| 先に確認すること | 任意のサーバーや API へ転送するか、レスポンスをデバイスへ返すか。 | 対応クラウドサービスへ非同期に取り込むか。TCP / UDP のデータ単位やデータ形式を後段で扱えるか。 | FaaS を呼び出し、関数のレスポンスをデバイスで扱うか。送信データ形式とレスポンス形式をデバイス側で扱えるか。 |
| 向いている判断 | 転送先の自由度やプロトコル変換を優先する場合。 | クラウドのメッセージ基盤やストリーム基盤へ取り込み、後段で分岐する場合。 | 関数で即時処理し、必要に応じて処理結果を返す場合。 |
応答が必要かで選ぶ
同じ転送先に見えても、デバイスが転送先の処理結果をすぐに受け取るかで選択が変わります。
| 判断軸 | 選定方法 |
|---|---|
| 転送先のレスポンスをデバイスで受け取る | Beam または Funk を検討します。Beam と Funk は同期で処理され、転送先サーバーや関数からのレスポンスを受け取れます。 |
| データが SORACOM に届いたらデバイス側の送信を完了してよい | Funnel を検討します。Funnel は非同期で処理され、転送先サービスからのレスポンスはデバイスに返りません。 |
| デバイス自身で処理結果を見て再送する | Funnel ではなく、Beam などレスポンスを扱える構成を検討します。 |
| 後段で大量データを受け、処理や蓄積へ流す | Funnel でメッセージ基盤やストリーム基盤へ渡し、後段で分岐する構成を検討します。 |
Funnel はスケーラビリティを重視した非同期転送です。データの到達順序は保証されず、同じデータが重複して転送されることがあります。後段では、タイムスタンプや一意の ID を使って、順序、重複、再処理を扱えるようにします。
ファンアウトの分岐点を決める
ここで扱うファンアウトは、デバイスから集めたデータをクラウド側で複数の用途へ分岐する構成です。デバイスから SORACOM へ送られた 1 つのデータを、保存、分析、通知、関数処理などの複数用途へ広げる場合は、どこを分岐点にするかを決めます。
| 分岐点 | 向いているケース | 主な注意点 |
|---|---|---|
| 関数 | 受信後すぐに軽い処理を行い、結果に応じて後段へ渡す。 | 関数のタイムアウト、入力サイズ、レスポンスサイズ、再実行時の重複処理を確認する。 |
| メッセージ基盤 | 受信データを複数の処理や通知へ分岐する。 | Topic、Rule、Consumer、権限、順序、重複、失敗時の再処理を設計する。 |
| ストリーム基盤 | 多数デバイスの時系列データを継続的に取り込み、分析や保存へ流す。 | シャード、パーティション、取り込み容量、後段処理の遅延、料金を確認する。 |
| 配信サービス | データをストレージや分析基盤へ直接保存する。 | 保存先の形式、バッチ化、変換、失敗ログ、再送方法を確認する。 |
たとえば AWS で複数の処理へ分岐する場合、Funnel で AWS IoT Core にデータを送り、AWS IoT Core のルールで AWS Lambda、Amazon SNS、Amazon DynamoDB などへ分岐できます。保存や分析への取り込みを優先する場合は、Funnel で Amazon Data Firehose に送り、Amazon S3 などに保存する構成も選択肢になります。
Azure では Event Hubs、Google Cloud では Pub/Sub のようなメッセージ基盤を分岐点にすると、デバイス側の実装を増やさず、クラウド側で後段の処理を増やしやすくなります。
分岐点はデバイス側ではなくクラウド側に置きます
デバイスから複数の送信先へ個別に送ると、送信回数、認証情報、ファームウェア変更、失敗時の再送制御がデバイス側に増えます。多数デバイスでは、SORACOM からメッセージ基盤やストリーム基盤へ渡し、クラウド側で分岐する構成を優先して検討します。
構成パターン
1. 任意の API やサーバーへ転送する
自社 API、SaaS、独自サーバー、任意の MQTT ブローカーなど、Funnel や Funk の転送先として用意されていない宛先へ送る場合は、Beam を検討します。
Beam は、デバイスから SORACOM までの通信と、SORACOM から転送先までの通信を分けて扱えます。デバイス側は軽いプロトコルで送信し、Beam から先を HTTPS や MQTTS で保護する構成にできます。転送先のレスポンスをデバイスへ返す場合にも候補になります。
2. 関数で処理する
データを受け取ったあとに、関数で変換、判定、通知、外部 API 呼び出しなどを行う場合は、Funk を検討します。
Funk は、対応する FaaS の関数を呼び出し、関数のレスポンスをデバイスに返せます。デバイス側で複雑な処理を行いにくい場合や、処理内容をクラウド側で変更する場合に向いています。
Funk を選ぶ場合は、次の項目を確認します。
- 利用する FaaS が Funk の設定で対応しているか。
- 関数の実行時間、入力サイズ、レスポンスサイズが、利用するクラウドサービス側の制限に収まるか。
- デバイスが関数のレスポンスをどう扱うか。
- 短い間隔で送信する場合に、リクエスト数、料金、上限をどう扱うか。
3. 対応クラウドサービスへ非同期で取り込む
データをクラウドサービスへ取り込み、後段の保存、分析、処理へ渡す場合は、Funnel を検討します。
Funnel のアダプターは、転送先サービスに合わせた認証やプロトコル変換を担当します。デバイス側にクラウド SDK を入れたり、転送先ごとの認証処理を実装したりする範囲を減らせます。
Funnel を選ぶ場合は、次の項目を確認します。
- 転送先サービスが Funnel のアダプターで対応しているか。
- 転送先サービスで必要な認証情報を、認証情報ストアで管理できるか。
- 非同期転送で問題ないか。
- 到達順序の非保証、重複転送、エラーログを考慮し、後段で整合性を扱えるか。
- リクエスト数と転送先クラウドサービス側の料金を合わせて確認しているか。
4. メッセージ基盤やストリーム基盤で分岐する
データを複数用途へ展開する場合は、Funnel でメッセージ基盤やストリーム基盤へ送り、クラウド側で分岐する構成を検討します。
| 転送先 | 主な使いかた |
|---|---|
| AWS IoT Core | IoT のメッセージブローカーとルールエンジンを使い、Lambda、SNS、DynamoDB などへ分岐する。 |
| Amazon Kinesis Data Streams | 多数デバイスの時系列データをストリームとして処理する。 |
| Amazon Data Firehose | S3、Redshift、OpenSearch Service などへ保存する。必要に応じて Lambda で変換する。 |
| Azure Event Hubs | Azure 側のストリーム処理や分析基盤へデータを流す。 |
| Google Cloud Pub/Sub | Google Cloud 側の処理、分析、BigQuery 連携などへデータを流す。 |
ファンアウト構成では、分岐先を増やしやすい一方で、各分岐先の失敗、遅延、重複、料金が別々に発生します。最初に「必ず保存するデータ」「即時処理するデータ」「あとから分析するデータ」を分けて、後段の責務を整理します。
設計順序
1. データの用途を分ける
最初に、データを何に使うかを分けます。
- 即時判定や通知に使う。
- 時系列で保存する。
- 後から分析する。
- 外部システムへ連携する。
- 複数の用途へ同時に分岐する。
すべてのデータを同じ経路に流す必要はありません。即時性が必要なデータと、保存や分析に使うデータでは、遅延、重複、順序、料金の見かたが変わります。
2. デバイスが受け取るべき応答を決める
デバイスが送信後に受け取る情報を決めます。
- 転送先の処理結果を使ってデバイス側の動作を変えるなら、Beam または Funk を検討します。
- データを送信したらデバイス側は完了してよいなら、Funnel を検討します。
- 送信失敗時にデバイスが再送するなら、デバイスが判断できるレスポンスを設計します。
- 後段で再処理するなら、データに時刻、一意 ID、送信元識別子を含めます。
3. 転送先の種類を決める
転送先が任意のサーバーなのか、対応クラウドサービスなのか、FaaS なのかを決めます。
| 転送先 | 主な候補 |
|---|---|
| 任意の API、サーバー、MQTT ブローカー | Beam |
| 対応クラウドサービス、メッセージ基盤、ストリーム基盤 | Funnel |
| FaaS の関数 | Funk |
同じクラウドサービスでも、構成によっては複数の選択肢があります。たとえば AWS Lambda を呼び出す場合は Funk だけでなく Beam も候補になります。複数の関数へ振り分けたい場合や、HTTP のパスで分けたい場合は Beam、FaaS に直接渡してレスポンスを扱いたい場合は Funk を検討します。
4. クラウド側で分岐する場所を決める
複数用途に分岐する場合は、分岐点をクラウド側に置きます。
- AWS IoT Core のルールで複数の AWS サービスへ分岐する。
- Kinesis Data Streams や Event Hubs の Consumer で複数処理へ渡す。
- Pub/Sub の Topic と Subscription で処理を分ける。
- Data Firehose で保存先に流し、必要に応じて変換処理を挟む。
分岐点を増やす前に、必ず保存する経路、失敗時に再処理する経路、通知だけでよい経路を分けます。
5. 到達、順序、重複、再送を決める
データパイプラインでは、送信できることだけでなく、失敗したときにどう扱うかを決めます。
| 確認すること | 設計の考え方 |
|---|---|
| 到達確認 | デバイス側で確認するか、クラウド側のログやメトリクスで確認するかを分ける。 |
| 順序 | Funnel やメッセージ基盤では順序が入れ替わる可能性を考慮し、時刻や連番を持たせる。 |
| 重複 | 少なくとも 1 回の転送やクラウド側の再処理を考慮し、一意 ID で重複排除できるようにする。 |
| 再送 | デバイスで再送するか、後段で再処理するかを決める。 |
| エラー確認 | Funnel のエラーログ、サービス使用履歴、転送先クラウド側のログを合わせて確認する。 |
6. 料金とログの確認方法を決める
Beam、Funnel、Funk は、リクエスト数や利用条件に応じて料金が発生します。さらに、転送先のクラウドサービス側でも、取り込み、保存、関数実行、メッセージ配信、ストリーム処理の料金が発生します。
設計時は、次の確認先を分けておきます。
- SORACOM 側のリクエスト数、エラーログ、サービス使用履歴。
- 転送先クラウドサービス側の受信件数、処理失敗、再試行、保存量。
- 関数やメッセージ基盤のタイムアウト、入力サイズ、出力サイズ、同時実行、スループット。
- 無料枠や VPG 経由時の扱いを含む料金条件。
転送先の料金と上限も確認してください
SORACOM 側で送信できても、転送先クラウドサービス側でスループット、ペイロードサイズ、関数タイムアウト、同時実行数、保存先容量などの制限に達することがあります。サービス選定時は、SORACOM の料金と上限だけでなく、転送先クラウドサービス側の料金と上限も合わせて確認してください。
関連する SORACOM ドキュメント
- 任意のサーバーへの転送: SORACOM Beam
- 対応クラウドサービスへの転送: SORACOM Funnel
- Function as a Service (FaaS) への転送: SORACOM Funk
- 複数サービスへの転送入口: SORACOM Unified Endpoint
- データ形式の変換: バイナリパーサー
- Funnel の転送先と特徴: SORACOM Funnel の特徴
- Funk の転送先と特徴: SORACOM Funk の特徴
- Funnel の通信プロトコルとデータサイズ: 利用可能な通信プロトコル (TCP、UDP、HTTP)
- Funnel のエラーログ: エラーログ
- データ送信の通信量とデバイス負荷: データ送信の通信量とデバイス負荷を抑える
- データ送信の保護方式: データ送信を暗号化または閉域接続で保護する
- クラウド別の具体的な連携手順: ボタンデバイスのクラウド別連携パターン
元記事・元資料
このページは、以下の記事・資料をもとにしています。
正確な内容や最新の情報を確認するときは、元の記事・資料もあわせて参照してください。
- SORACOM 公式ブログ: IoTプロジェクトの課題から考えるSORACOM Beam・Funk・Funnelのメリットと選び方
- SORACOM 公式ブログ: SORACOM Funnel AWS IoT アダプタの効果的な使い方
- SORACOM 公式ブログ: 新サービス SORACOM Funk を発表
- SORACOM 公式ブログ: Stream IoT Cellular Data Directly into AWS Kinesis Firehose with Soracom Funnel
- SORACOM 公式ブログ: 新機能: SORACOM が Google Cloud Platform と連携出来るようになりました
- SORACOM 公式ブログ: Connecting IoT devices to AWS Kinesis and Microsoft Azure
- Speaker Deck: サーバーレスで始める IoTデータパイプラインとファンアウトのアーキテクチャー
- Speaker Deck: サーバーレスで作る IoT ファンアウト・パターンの実装