本記事はソラコムが提供する「SORACOM公式ブログ」に掲載された「IoTプロジェクトの課題から考えるSORACOM Beam・Funk・Funnelのメリットと選び方」を再編集したものです。
目次
SORACOM Beam・Funk・Funnelの共通点と異なる点サービスの概要と各サービスの違い
デバイスからSORACOM IoT プラットフォームまでのセキュアな通信経路
クラウドサービスの利用とIoTデバイスの課題
通信プロトコルによるバッテリー消耗とデータ通信量の増加
送信設定の変更が難しい
SORACOM Beam・Funk・Funnelの選び方
1. SORACOM BeamとFunnelの選び方は「データ送信後の応答の同期 / 非同期」
2. SORACOM BeamとFunkによる、Function as a Serviceへの連携
3. MQTT通信ならSORACOM Beam
4.その他
さいごに
皆さま、こんにちは。ソラコムのソリューションアーキテクト松永(ニックネーム: taketo)です。
さて今回のブログでは、SORACOMのデータ転送系サービス SORACOM Beam(ビーム)・Funk(ファンク)・Funnel(ファネル)についてハイライトし、なぜIoTでこれらが有用なのか?どのように使い分ければ良いのか?をご説明したいと思います。
SORACOM Beam・Funk・Funnelの共通点と異なる点
サービスの概要と各サービスの違い
SORACOM Beam・Funk・Funnelは、いずれもデバイス側の通信をプロトコル変換し認証情報など付加してデータ転送をするサービスです。転送先や認証情報の設定をSORACOMのユーザーコンソールから行なうことができ、デバイス側の変更が不要となります。特に、デバイス側で暗号化や送信設定をしなくとも宛先にデータ送信ができる点が非常にご好評頂いているポイントですね。
サービスの大きな違いとしては、転送先が大きく異なる点です。他にも細かい違いがあるのですが後半で具体的な選定方法と交えて解説しておりますので、是非最後まで読んでください!
- SORACOM Beam:カスタムのエンドポイントへ転送(例:HTTPSやMQTTSなど)
- SORACOM Funk:Function as a Serviceへ転送(例:AWS Lambdaなど)
- SORACOM Funnel:クラウドサービスやSORACOM パートナースペース企業様(弊社パートナー企業様)のソリューションへ転送(例:Amazon Kinesis Data Streamsなど)
ここまで説明するとそもそもデバイス側でTLSといったアプリケーションレイヤでの通信暗号化処理を実装をしないでも本当に大丈夫なの?といった疑問を持たれる方がいらっしゃるのではないでしょうか。この点についても補足致します。
デバイスからSORACOM IoT プラットフォームまでのセキュアな通信経路
デバイスから暗号化が不要な理由は、セルラー通信の仕組みとSORACOMのシステム構成にあります。実際にTLSといったアプリケーションレイヤの暗号化なしで通信するネットワーク経路は、デバイスからSORACOMのIoT プラットフォームまでですが、各区間での通信について解説します。
デバイス←→基地局間:
この区間は、3GやLTEといったセルラー通信自体に暗号化がされています。詳しくは、「SORACOMが実現するIoTデバイスとデータのセキュリティ:3G/LTEのSIM認証」でも解説しておりますが、通信レイヤーで暗号化がされているため、アプリケーションレベルでの暗号化の有無を気にしなくて良い区間です。
基地局←→キャリア施設間:
不特定多数が利用できるインターネットとは異なり、限られた施設管理者や限られたアクセス権限でセキュアに管理されている閉域ネットワークのため、セキュアな区間です。
キャリア施設←→SORACOMのIoT プラットフォーム間:
キャリア施設からSORACOMのIoT プラットフォームまでは専用線接続で接続されており、閉域網でセキュアとなっております。
SORACOMのIoT プラットフォーム←→クラウド間:
今回ご紹介するSORACOM Beam・Funk・Funnelをご利用いただくことで、これらのサービスが皆様に代わって暗号化を行います。
SORACOM Beam・Funk・Funnelのセキュアな通信経路の仕組みについては理解頂けたかと思います。実際の事例からどのようなケースでメリットがあるのか解説していきます。
クラウドサービスの利用とIoTデバイスの課題
クラウドサービスの連携では、インターネットを介した通信経路のため暗号化処理を施すことや、可読性の高いJSONフォーマットが必須とされることが一般的です。一方でIoTデバイスは、バッテリー駆動のデバイスやUDP・TCPなど低レイヤーの通信プロトコルのみで、HTTP等の上位レイヤーは自前実装になることもあります。この場合には、バッテリー消耗など様々な課題が生じます。これらについて解決方法も交えてご紹介します。
通信プロトコルによるバッテリー消耗とデータ通信量の増加
IoTは必ずしも給電できる環境があるわけではなく、バッテリー駆動で動作しているものがあります。このようなデバイスの場合、通信の暗号化や不必要なデータ送信により消費電力が増加してしまうとバッテリーの持ちにも影響してしまいます。
SORACOM Beamを利用しこれを解決している事例として、ミクシィ様の例を具体的に見てみましょう。ミクシィ様は「みてねみまもりGPS」という子どもの位置情報を把握できるサービスを展開されています。その中で、バッテリー駆動で位置情報をクラウドへ送信するデバイスを開発しています。このようなBtoC製品ではバッテリーの持ちはユーザーエクスペリエンスとして重要な要素となりますが、どのようにバッテリー消費を抑えているのでしょうか。
システム構成を確認すると、データの送信先はAWSクラウドでHTTPSでの通信インターフェースがある一方で、デバイスからはUDPでデータ送信しSORACOM BeamがUDP→HTTPSへ変換してデータ転送しています。以前ご紹介した「実測!IoT通信プロトコルのオーバーヘッドの実態と削減方法」でも、HTTPSの通信量はUDPに比べて最大で約20倍のデータ量になることがわかっており、SORACOM Beamによりデバイスの省電力化を実現していることがわかります。直接デバイスからAWSへHTTPSでデータ送信することも技術的には可能ですが、通信量やバッテリーの消耗に影響が出てしまうのをうまく解決されていますね。
こちらの事例は、2022年7月に開催されたIoTカンファレンス「SORACOM Discovery 2022」でも解説されています。動画がありますのでこちらも併せてご覧ください。(ミクシィみてね見守り事例)
送信設定の変更が難しい
IoTにおけるファームウェアのアップデートが課題になるケースがあります。例えば、既存の製品を扱う場合、その認証情報の変更や送信先の変更が難しいケースがあります。
具体的なケースとして、ラトック様の「LTE-M CO2センサー RS-LTECO2 スターターキット」を見てみましょう。RS-LTECO2は、SORACOM Unified EndpointへUDPでデータ送信するファームウェアがプリインストールされています。一般的には、ファームウェアで設定されているデータの送信先を変更するには、デバイス自体に変更の仕組みを実装したり、最近ではスマートフォンの設定アプリから行なったりしますが、いずれにしても手間がかかるものです。
SORACOM Unified Endpointは、デバイスから送信されたデータを、Beam などに転送するためのエントリポイントを提供するサービスです。具体的にはデバイスからHTTPで「uni.soracom.io
」へデータ送信するようにしておくと、実際のデータの送信先は SORACOM Beamで指定された転送先に転送することが可能です。この場合は、SORACOM Unified Endpointを経由した形ですが、SORACOMのBeamやFunk、Funnelを利用して転送先を変更することができます。共通して言えるのは、データ送信先の変更が必要になった際、デバイス側のファームウェア変更が不要となります。
このように、SORACOMのBeamやFunk、Funnelを利用することで送信先や認証情報の変更をデバイスの変更なく実施できる点がポイントです。
SORACOM Beam・Funk・Funnelの選び方
最後に3つのサービスの選び方について解説していきます。基本的に転送先のサービスと通信プロトコルがSORACOM Beam・Funk・Funnelのどれに対応しているのかという点で選択することになります。しかし、例えばAWS IoT Coreなど連携先のサービスによってSORACOM BeamでもFunnelでも対応している場面があります。その点も踏まえてご説明致します。
選定のステップごとに解説致しますので、お客様のIoTプロジェクトでもポイント1から確認し適切なサービスを選定してみてください。
1. SORACOM BeamとFunnelの選び方は「データ送信後の応答の同期 / 非同期」
AWS IoT CoreなどSORACOM BeamとFunnelのどちらでも送信できる転送先があります。
このような場合、同期処理、つまりデバイスのデータ送信時に転送先のクラウドサービスからの応答を取得する必要があるか確認してください。もしくは、SORACOM BeamとFunnelまでデータが到達した時点で送信完了とし、クラウドサービスからの応答が不要となれば非同期処理で良いということになります。
SORACOM Beamは転送先の応答をデバイスに同期処理で返すサービスです。一方で、SORACOM Funnelは非同期にリクエストを処理します。Funnelはデバイスからのデータ送信を大量に捌けるシステム構成をとっておりデバイスからのデータは非同期で転送先に転送され、転送先のクラウドサービスからの応答はデバイス側に返されません。
非同期でデータを送信しても良いケースでFunnelの対応しているサービス一覧に連携対象のサービスがあればFunnel経由で送信する方法が良いでしょう。その他、デバイスがデータを送信し、その転送先のサービスの応答をデバイスが受け取るといった同期処理が必要な場合にはSORACOM Beamを検討します。
2. SORACOM BeamとFunkによる、Function as a Serviceへの連携
次に、連携先のサービスがFunction as a Service(以降、FaaS)である場合、SORACOM Beam・Funkのどちらでもデータ送信が可能です。
2022年12月にSORACOM Beamのアップデートで、AWS Signature V4といった認証情報の付加もできるようになり、それまでFaaSへの連携ではSORACOM Funkをご案内しておりましたがBeamでもAWS LambdaやAzure Functionsへ転送できるようになりました。
SORACOM BeamでFaaSを呼び出す場合は、「HTTPエントリポイント」を利用するとAWS LambdaとAzureへデバイスからのアクセスパスごとに複数のFaaSへ連携することができます。HTTPエントリポイントは複数作成が可能なため、異なるエンドポイント、つまり複数のFaaSへの振り分けが必要な時に利用できます。そのため、送信先のFunctionが複数存在し、デバイスからHTTPで送信が可能な場合はSORACOM Beamを検討してください。具体的な利用方法は公式ドキュメントをご確認ください。
一方で、SORACOM FunkではAWS Lambda、Microsoft Azure Functions、Google Cloud FunctionsのFaaS全てに対応しており、TCPやUDPといったHTTP以外でも連携が可能です。デバイスによって低レイヤーの通信プロトコルを利用する場合はSORACOM Funkをご利用ください。
3. MQTT通信ならSORACOM Beam
MQTT通信を想定されているお客様は、SORACOM Beamをご利用ください。
その際に、活用いただきたいのが「Beam の multi credentials per group 機能」です。SIMごとに認証情報を分ける仕組みですがMQTT通信ではデバイス証明書(X.509証明書)をデバイス(SIM)ごとに割り当てるのがベストプラクティスです。是非ご活用下さい!
4.その他
ここまで来るとあとはシンプルです。連携先のサービスと認証方法に対応したサービスを選びましょう。各サービスの対応サービスや対応している認証方法は各サービスのドキュメントをご覧ください!
- SORACOM Beam:対応プロトコルやサポートされている認証方法が連携先のサービスにあっているか仕様をご確認ください。
- SORACOM Funkと連携サービス
- SORACOM Funnel連携サービス
さいごに
最後まで読んで頂き有難うございました!SORACOM Beam・Funk・Funnelは松永のイチオシサービス群です。初回リリースから数年経過しておりますが、先日もBeamがAWS Signature V4などに対応するなど進化が止まりません!是非使ってみてください!
― ソラコム松永 (taketo)
投稿 IoTプロジェクトの課題から考えるSORACOM Beam・Funk・Funnelのメリットと選び方 は SORACOM公式ブログ に最初に表示されました。
この連載の記事
-
第474回
デジタル
SORACOM Flux の AI アクションに Amazon Bedrock – Anthropic Claude 3.5 Haiku を追加、Teltonika RUT240 の価格を改訂 takuyaのほぼ週刊ソラコム 11/02-11/15 -
第473回
デジタル
IoTセキュリティの基本知識と実践をご紹介 ― 10/31開催:SORACOMユーザー向けオンラインセミナー開催レポート -
第472回
デジタル
SORACOM Flux に追加された Incoming Webhook をつかってインタラクティブな Flux アプリを作る -
第471回
デジタル
サーバールームの異常な温度上昇を通知する新規掲載レシピのご紹介 -
第470回
デジタル
Virtual Private Gateway (VPG) Type-F2 が正式リリースになりました! -
第469回
デジタル
暗号化非対応のTCPクライアントでもNapterまでの通信を暗号化する方法 -
第468回
デジタル
SORACOM Beam や SORACOM Flux の開発・デバッグに使える HTTP モックサーバーを素早く作る方法 -
第467回
デジタル
IoTプラットフォームSORACOMの契約回線数が700万を突破、次世代SIMテクノロジー「iSIM」を商用化、搭載モジュールを提供開始 takuyaのほぼ週刊ソラコム 10/12-11/02 -
第466回
デジタル
カメラとAIで楽器演奏シーンを簡単に残す、IoTプロトタイピングの裏側 -
第465回
デジタル
数千を超えるIoT機器を管理!生成AIで設備運用を効率化するhacomonoの挑戦