whitepaper

MQTTによるIoTスケーラビリティと互換性の強化

IoTの急速な拡大により、企業は実験段階を終えて、数百万台の接続デバイスを伴う大規模な導入へと移行しています。デバイス数が増加し、データ流量が激増する中、企業は自社のIoTアーキテクチャが効率的に拡張可能であり、設計段階からセキュリティを確保し、長期的な相互運用性、互換性をサポートできることを保証しなければなりません。MQTTはIoT通信の標準プロトコルとして定着しつつありますが、真のエンタープライズグレードのパフォーマンスを実現するには、単にブローカーを導入するだけでは不十分です。スケール、セキュリティ、シンプルさを最初から考慮した「IoTファースト」のアプローチが必要です。

概要

IoTは転換点を迎えています。もはや誰もがユースケースやアプローチを理解しようとする新参者ではありません。企業は、接続にかかる時間を最小限に抑えつつ、数百万台規模の接続デバイスを積極的に導入しようとしています。デバイスデータはIoTプラットフォームに送信され、保管と初期分析が行われ、市場での差別化、コスト削減、市場垂直分野の法規制への準拠を可能にします。このような状況下、背景で、IoTプラットフォームには、企業がビジネスニーズを満たせるよう、安全でスケーラブルかつ革新的なソリューションを提供することが求められています。

MQTTは、デバイスメーカーとソリューションプロバイダーの双方にとって導入が容易であり、コストと市場投入までの時間を削減できることから、最適なプロトコルとして台頭してきました。本稿では、MQTTに焦点を当て、世界中の企業から信頼され、全世界で数千万台の接続デバイスを管理するCumulocityが、10年以上にわたるIIoTの経験を活かして、6,000万台のデバイスと毎秒100万メッセージに対応する検証済みの第3世代マネージドMQTTサービスをどのように構築したかについて解説します。

なぜMQTTなのか？

MQTTは軽量で効率的なオープンプロトコルであり、小型デバイスでも簡単に実装でき、メッセージペイロードに制限を課しません。MQTTクライアントは非常に小さなフットプリントで実装できるため、リソースに制約のあるデバイスに理想的なプロトコルです。また、MQTTブローカーがメッセージの処理方法を理解するために必要なメッセージヘッダー内の追加データも、同様に最小限に抑えられています。このプロトコルは軽量かつ効率性を重視して設計されており、低帯域幅や不安定なネットワークでも確実に動作します。リアルタイム通信をサポートし、多数のデバイスへの拡張が容易で、頻繁に接続・切断を繰り返すクライアントにも対応できるため、デバイスが分散された過酷な環境に最適です。これらの要因によりソフトウェア開発のオーバーヘッドが軽減され、1999年の誕生以来、MQTTの利用は拡大し続け、現在ではIoT通信分野を席巻し、事実上のグローバルスタンダードとなっています。

IoTの課題

IoTソリューションにとって最大の課題の一つは、数百万台のデバイスを安全に、最小限の複雑さで接続するという問題を解決することです。なぜこれが課題となるのでしょうか？IoTに関連するこれらの問題を個別に見てみましょう。

スケール。デバイスの数は、2015年の推定38億台から、現在では推定198億台へと増加しており、2034年には406億台に達すると予測されています。この成長の背景には、企業が自社の設備・機器を接続することで、資材使用量の削減、リアルタイムのパフォーマンス監視、遠隔設備（機器）管理といった大きなメリットを実現でき、ひいては総コストの削減につながると認識していることがあります。この成長の結果、1つのIoTテナントが数百万台のデバイスを接続する状況が見られます。各デバイスには数百個のセンサーが搭載されている可能性があり、それらすべてがIoTプラットフォームにデータを送信し、そこで保存・分析される必要があります。これにより、基盤となるハードウェアからホスティングソフトウェア、ソリューション自体に至るまで、インフラストラクチャのあらゆる側面において、IoTソリューションのスケーリングにプレッシャーが掛かってきています。
セキュリティ。デバイスメーカーは、オンプレミスであれクラウドであれ、デバイスをIoTソリューションに接続する際に対処すべき複数の課題に直面しています。その中でも最も差し迫った課題は、「あなたが申告した本人であることを、どうすれば確認できるのか？」という点です。一見単純な質問に思えるかもしれませんが、もし侵害されたデバイスが検知されずにIoTソリューションにアクセスできてしまった場合、悪意のある攻撃者は甚大な被害をもたらす可能性があります。また、包括的なデバイスソフトウェアのライフサイクル管理を義務付ける「サイバーレジリエンス法」の要件も忘れてはなりません。
シンプルさ。多くのデバイスは、設置や管理を担当する担当者が必ずしもITスキルを本職としない環境で運用されています。こうした状況では、導入を確実にするために、現場でのセットアップ作業を最小限に抑えるか、あるいは不要にすることが不可欠です。さらに、前述した接続と管理における規模の要求も加わります。つまり、手動による介入を最小限に抑えつつ、デバイスの一括登録、リモート管理、および診断が可能な仕組みが求められます。

本稿の後半では、MQTTおよびIoTソリューションをスケーラブルかつセキュアにし、将来にも対応できるものにするために必要な要素について検討しながら、これらの分野についてさらに詳しく解説します。以下が主な内容です：

スケーリングやパフォーマンスに関する大げさな主張を見極め、何が実現可能か、そしてそれが自社のニーズとどのように関連しているかを理解する方法
セキュリティに関する主要な課題とその解決策
デバイス環境の複雑さという課題に対処しつつ、シンプルさを重視する方法
Cumulocityの第3世代マネージドMQTTサービスが、6,000万台のデバイス規模で毎秒100万メッセージの処理実証済みの「IoTファースト」アーキテクチャをどのように実現しているか。

パイロット段階を超え、グローバルにスケールするIoTシステムの構築を真剣に検討されているなら、本稿は必読です。MQTTが標準である理由を説明するだけでなく、レジリエンス、効率性、長期的な競争優位性を生み出すためにどのように実装するかを示しています。

IoTにおけるMQTT

数百件に及ぶIoTプロジェクトの経験から、IoTではMQTTに対して特有の要件が課されており、標準的なメッセージング環境で使用される一般的なメッセージブローカーとは、若干異なるアプローチと注意が必要となります。

下記の図1は、従来のESBソリューションの大まかなアーキテクチャを示しています。

図1. 従来のESBメッセージブローカーアーキテクチャ

このアーキテクチャでは、比較的少数のアプリケーションがブローカーによって平等に扱われます（「対称型パターン」）。アプリケーション間のピア・ツー・ピア通信が一般的であり、すべてのコンポーネントは通常、安全で管理されたエンタープライズグレードのインフラストラクチャ上に展開されます。

一方、下の図2は、広範囲に散在する多数デバイスからデータを取り込む、産業用IoTプラットフォームアーキテクチャの関連コンポーネントを示しています。

図2. IoT MQTTエンドポイントアーキテクチャ

このアーキテクチャでは、メッセージブローカーは双方を異なる方法で処理する必要があります（「非対称パターン」）。一方には、数百万台、あるいは数億台もの接続デバイスが存在する可能性があります。デバイス間のピアツーピア通信は一般的ではなく、完全にセキュリティを確保できない環境にデバイスが展開されている場合、セキュリティ上のリスクとなることもあります。MQTTプロトコルエンジンは、メッセージブローカーから論理的に分離して示されています。これは、プラットフォームが他のIoTデバイスプロトコルを使用するデバイスもサポートし、すべてのデバイスデータが最終的に共有メッセージングバックボーンにパブリッシュされるためです。

もう一方の側には、少数ながら、高度にスケーラブルかつ信頼性の高い方法でデータを処理する必要があるアプリケーションが存在します。通信の観点では、IoTブローカーはデバイスからプラットフォームへのトラフィックおよびプラットフォームからデバイスへのトラフィックを最適化する必要がありますが、デバイス間トラフィックは標準的な要件ではありません。

要約すると、MQTTブローカーの両側には大きく異なる要件があり、従来のMQTTブローカーを超える機能がIoT MQTTブローカーに求められます。以下の表1は、考慮すべきスケーラビリティと堅牢性における具体的な相違点の一部を示しています。

表1. アプリケーションとIoTデバイス接続の比較

このセクションの残りでは、スケール、セキュリティ、シンプルさのさまざまな側面を詳細に見ていきます。

スケール

インフラストラクチャに巨額な費用をかけずにスケールする方法

前述の通り、産業用IoT（IIoT）では、接続数とスループットの両面で非常に大規模な処理が求められると予想されています。

これらの要件を満たすためには、IoTに特化したMQTTエンドポイントは、特定のパターンに重点を置く必要があります。

主なユースケースは「ファンイン（fan-in）」シナリオであり、ここでは数百万台のデバイスがプラットフォームにデータを送信し、それを比較的少数のアプリケーションが消費します。
このシナリオにおけるメッセージトラフィックは明らかに非対称です。一般的なIoT環境では、デバイスからクラウドへの通信量が、クラウドからデバイスへの通信量を100倍から1,000倍、場合によってはそれ以上に上回ります。つまり、IoT MQTTブローカーは、スケーラビリティ要件を満たすために、各方向のデータをどのように処理するかについて、異なるアーキテクチャ上の判断を下す必要があります。
毎秒数百万件のメッセージを処理するためにアプリケーションをスケールさせるには、IoTブローカーは「パーティション化されたサブスクリプション」と「アプリケーションインスタンス管理」という2つの機能を提供する必要があります。これらのPub/Subへのアプローチにより、基盤となるインフラに過度な負荷をかけることなくスケーリングが可能になります。
- パーティションサブスクリプション： 受信したデバイスデータは個別の論理パーティションに分割されます。通常、これはMQTTブローカーをフロントエンドとして使用し、永続化処理を基盤となるメッセージングバスに委ねることで実現されます。デバイス側のMQTTクライアントから見れば、特に変わった点はなく、標準的な方法でトピックにメッセージをパブリッシュします。内部的には、トピック構造の処理においてメッセージングバスの技術を活用し、リソース使用量を最小限に抑え、メッセージのライフサイクルを管理しています。
- アプリケーション管理： 各論理パーティションには、メッセージの処理を担当する関連付けられたアプリケーションインスタンスが必要です。アプリケーションは状態管理のロジックを担当します。これは、パーティションとアプリケーションの1対1の関係によって実現されます。

スケーリングに関連して、しばしばスケーリングと混同されがちなのがパフォーマンスの問題です。パフォーマンスとは、所定のワークロード下におけるシステムの応答性を指します。通常、MQTTブローカーに提供される情報はスループットです。この数値ついては、具体的に何が測定されているかを正確に理解するのが困難な場合があります。多くの場合、同時接続デバイス数がスケーリングの指標として用いられますが、それがどのように達成されているかについての情報はほとんど提供されません。

注意すべき点：

シナリオ： 標準的なMQTTのシナリオは、ほとんどのIoTソリューションに当てはまるものではありません。そのため、適切なシナリオを見極める必要があります。具体的には、多数のデバイスが、それよりはるかに少ない数のアプリケーションに対してメッセージを送信する（ファンイン）構成であり、アプリケーションからデバイスへのトラフィックはごくわずかであるという状況が理想的です。

マーケティング計算：多くのウェブサイトは「マーケティング数学」を使用します。多くのウェブサイトでは「マーケティング上の計算」が用いられます。例えば、20のパブリッシャーから毎秒100メッセージを送信し、それを1,000のサブスクライバーにファンアウトさせ、毎秒200万メッセージのスループットであると主張するケースです。確かに200万メッセージがサブスクライバーに配信されますが、このユースケースでは毎秒2,000件のユニークなメッセージしか存在しません。よりIoTに特化したユースケースを考えてみましょう。1,000台のデバイスがそれぞれ毎秒2,000メッセージをパブリッシュし、パーティション化されたサブスクリプションを使用して各メッセージが20人のサブスクライバーのうちの1人に配信される場合です。表向きのスループットはどちらのケースでも全く同じです（サブスクライバーに毎秒200万メッセージが配信されます）。しかし、ファンインのシナリオでは、それらのメッセージはすべて一意であり、システムが処理する総作業量ははるかに大きくなります。

サービス品質(QoS)： 適用するQoSレベルも、実現可能なパフォーマンスとスケーラビリティに影響を与えます。QoS 0（ファイア・アンド・フォーゲット）は、メッセージ損失のリスクはあるものの、著しく優れたスループットを実現できます。これは、一部のIoTユースケースでは全く問題にならない場合もあります。QoS 1（少なくとも1回）は、確認応答処理やメッセージの永続化によるオーバーヘッドが大きいため、特定のユースケースにおいて最大パフォーマンスは低くなります。QoS 2（正確に1回）は、IoTアプリケーションでは一般的ではないサービス品質です。

要するに、ご自身とユースケースにとって何が重要かを確認し、公表されている数値を達成するために使用されたインフラに関する情報が公開されているかどうかを確認することが重要です。

セキュリティ

複雑さを最小限に抑え安全性を確保する方法

IoT分野におけるセキュリティは極めて重要です。リアルタイムに近いかたちでの分析がもたらす変革を積極的に取り入れている多くの業界は、医療、公益事業、国家重要インフラなど、規制の厳しい市場でもあります。

IoT用MQTTブローカーには、マルチテナント機能、デバイスの分離、そして理想的には組み込みの認証局（CA）を備えたPKIベースの認証という3つのセキュリティ機能が必要です。CumulocityのMQTTサービスはこれら3つすべてを備え、GDPR、ISO 27001、およびSOC 2規格への準拠を実現しています。

デバイスは通常、セキュリティチェーンにおける弱点となります。ティア4データセンターで稼働するアプリケーションとは対照的に、デバイスはあらゆる場所に展開されるため、より容易に侵害される可能性があります。したがって、万が一デバイスが侵害された場合でも、被害を限定し、悪意のある攻撃者がより広範なIoTソリューション内で悪事を働くための入り口とならないようにすることが極めて重要です。

これには、当社が「デバイス分離」と呼ぶ機能が必要です。大まかに言えば、これはデバイスが自身のトピックスペースにのみデータを送信でき、他のデバイスがそのトピックスペースを購読したり、そこにデータを公開したりできないことを意味します。デバイス側から見れば、接続されているクライアントは自身のみであり、トピックスペース全体への排他的なアクセス権を持っています。デバイス分離により、たとえ1台のデバイスが侵害されたとしても、攻撃者は例えば他のデバイスに対してファームウェア更新リクエストを送信することができません。なぜなら、他のデバイスのトピックスペースにデータを公開することは不可能だからです。

デバイス分離は、機能を制限することなくセキュリティを向上させることが実証されています。このモデルでは「ピアツーピア」のデバイス間通信は不可能ですが、実際には問題にはなりません。第一に、ピアツーピア通信はアプリケーション側で実装することでエミュレート可能です。アプリケーションはデバイスからメッセージを取得し、他のデバイスにパブリッシュすることができます。第二に、複数のファームウェアバージョンや関連するMQTTペイロードのバリエーションが存在するデバイスネットワークにおいてピアツーピア通信を実現するには、各デバイスが（過去および将来の）すべてのペイロードバリエーションを理解している必要があり、実際には困難です。そして第三に、ピアツーピア通信は例外的な要件であり、当社の経験では、IoTソリューションの5%未満でしか必要とされません。

以下の図3は、デバイスごとのMQTTトピックスペースの使用により、デバイスとテナントを互いに分離する方法を示しています。図には示されていませんが、アプリケーション側では、アプリケーションは単一のテナントのコンテキストで動作し、そのテナント内のすべてのデバイスメッセージデータにアクセスできます。

図3. デバイスとテナントの分離

セキュリティに関する議論において、証明書ベースの認証に触れずに語ることはできません。この認証手法は現在、ベストプラクティスと見なされていますが、実際には参入障壁があるため、IoT分野での普及は遅れています。証明書ベースの認証には、信頼できる認証局（CA）からの証明書購入や、PKIソリューションを必要とする証明書ライフサイクル管理といった追加コストが伴います。PKIソリューションの導入にはライセンス費用に加え、管理に時間と労力が必要です。Cumulocityは、簡素化された証明書ライフサイクル管理を実現する組み込みの認証局（CA）と、外部PKIシステムとのシームレスな統合という2つのオプションを提供し、大規模な環境においても安全なID管理を保証します。

シンプルさ

ユーザーがデバイスを使いたくなるようにシンプルに保つ方法

セキュリティとスケーラビリティはCumulocityのIoTプラットフォームが担うため、あとはデバイスを接続するだけです。このプロセスは、ローコード設定や、デバイス管理、コックピット、分析ビルダーといったすぐに使えるツールによって、より迅速かつシンプルになります。ここで重要なのは、IoTソリューションが必要な機能の80%を提供し、顧客固有の要件については設定やソリューション自体へのコーディングによる拡張で対応できるようにすることです。

データの送信を開始する前に幅広い機能を検討する必要があるIoTプラットフォームもあれば、すぐに使えるソリューションを提供するプラットフォームもあります。自社に最適なIoTプラットフォームを選択する鍵は、達成すべき目標と、そのうちのどれだけが提供されているかを理解することにあります。また、今後5年間で自社のIoT導入プロセスをどのように進めていくかを把握しておくことも重要です。プラットフォームの切り替えは、時間的にも収益への影響の面でも、多大なコストを伴うプロジェクトになり得るためです。この意思決定プロセスの一環として、IoTプラットフォームのアーキテクチャを確認し、それが第一にIoTプラットフォームであるのか、それとも第一にMQTTブローカーであるのかを検討してください。最先端の分析機能を備えたデバイス管理やソフトウェアライフサイクル管理を提供するプラットフォームをお探しの場合は、IoTプラットフォームを第一に据えたソリューションに焦点を絞る必要があります。一方、既存のソリューションやアプリケーションとの統合を最優先とする場合は、MQTTブローカーを主軸としたソリューションでもニーズを満たせる可能性があります。

Cumulocityの次世代MQTTサービス

ここでは、弊社の次世代MQTT戦略である「Cumulocity MQTT Service」が、お客様のIoT導入プロセスをどのように支援できるかについてご紹介します。本サービスは、お客様の当面のニーズに応えるソリューションを提供すると同時に、将来にわたる要件にも対応します。

Cumulocity MQTT Serviceは、MQTT（当社のチームメンバーは、MQTTを市場に導入した当初のチームの一員でした）と産業用IoT市場（Cumulocityは、Nokia IoT Platformを担当したチームから派生して設立されました）の両方に対する深い知見を基に設計されています。これらの専門知識により、今日のIoT市場のニーズに焦点を当て、MQTTの利点を最大限に活かした業界をリードするサービスを構築することができました。

スケール

CumulocityのMQTTサービスは、IoT向けに特別に構築されており、現在数百万台のMQTTデバイスを接続しているお客様のニーズを満たすよう設計されています。また、IoTの導入や事業運営の拡大に伴い、数千万台規模への拡張も見込まれています。お客様からのご意見を設計に反映させることで、インフラへの追加コストを抑えつつ、拡張性を確保しています。

CumulocityのMQTTサービスでは、汎用性のあるメッセージングバスが基底となる永続化および管理レイヤーを提供しています。このアーキテクチャにより、以下のことが実現されます。

MQTTなどの単一プロトコルに縛られることなく、LwM2Mなどの他のプロトコルに同じアプローチを使用でき、Cumulocityに接続するすべてのデバイスに一貫した動作を提供できます。
メッセージングバスの両側で異なるプロトコルをサポートできるため、デバイス側ではMQTTを使用し、アプリケーションでは別のプロトコルを使用してデータを受け取る（サブスクライブする）ことができます。
大容量データを単一のアプリケーションに効率良くストリーミングできます。

Cumulocityは、6,000万台の接続されたMQTTクライアントが、メッセージブローカーに対して合計で毎秒100万件のメッセージを送信する環境でテストされています。また、MQTT以外のプロトコルを使用する単一のアプリケーションエンドポイントが、同じく毎秒100万件のメッセージを消費する環境でもテストされています。他のベンチマークでは、これを毎秒200万件と記載する場合がありますが、これはファンアウトのユースケースにおいては有用な指標となり得るものの、システム全体のスループットを過大評価するものです。したがって、当社ではデバイスからIoTプラットフォームまでエンドツーエンドで正常に配信されたユニークなメッセージの数を測定することを採用しています。

セキュリティ

Cumulocityは、プラットフォームアーキテクチャに組み込まれたマルチテナント方式から、最新のセキュリティ課題への対応に向けた絶え間ないイノベーションに至るまで、セキュリティに対する当社の取り組みに自信を持っています。

MQTTサービスはマルチテナントアーキテクチャを拡張し、認証プロセスの一環として、デバイスが特定のテナントに紐付けられることを保証します。 Cumulocityのテナントは完全に互いに隔離されています。つまり、異なるテナントに属する2つのデバイスが同じMQTTクライアント識別子を使用して接続しても、互いに完全に隔離された状態が維持され、一方のデバイスから他方への干渉は一切発生しません。MQTTサービスはこの仕組みをさらに拡張し、各デバイスがテナント内で独自のトピック階層を持つことを保証します。これにより、万が一デバイスが侵害された場合でも、そのデバイスから他のデバイスへの二次的な侵害が発生することはありません。

証明書ベースの認証は、MQTTデバイスを認証するための推奨される方法です。証明書ベースの認証の導入障壁を下げるために、Cumulocityでは証明書の署名および証明書ライフサイクル管理を行う認証局（CA）を提供しています。組織内で既に利用しているPKIがある場合は、その証明書も使用可能です。これらの機能は、Cumulocityプラットフォームに接続する際、他のプロトコルと同様に、新しいMQTTサービスでもまったく同じように動作します。 MQTT サービスを利用する際のさらなる強化点として、不正なデバイスが有効なデバイスになりすますことを防ぐため、証明書のコモンネーム（CN）を MQTT クライアント識別子と一致させるよう設定することが追加要件となっています。

デバイスの分離に加え、Cumulocity の多様な導入オプションはエンドツーエンドのセキュリティアプローチを提供し、お客様のビジネスケースに最適な選択肢を採用することを可能にします：

ThinEdge

MQTTサービスは、thin-edge.ioユーザーにとって、これまで不可能だった多くの魅力的な新しいユースケースを切り拓きます。

MQTTサービスは、クライアントがカスタムトピックやペイロード形式を使用できる柔軟性を備えており、これによりユーザーは、デバイス上およびクラウドにおけるデータの取り扱い方法を再考できるようになります。ユーザーは、データ正規化を支援する明確なデータモデルを維持しつつ、テレメトリデータをバイナリ形式（protobufなど）でパブリッシュすることで、消費帯域幅を削減できるようになります。

また、外部センサーやデバイスの統合も容易になり、デバイス上でデータを最初にデコードすることなく、thin-edge.ioを介してデータを透過的にクラウドへ送信できるようになります。

Edge

インターネット露出を制限する必要がある環境向けに設計されたCumulocity Edgeは、クラウドと同じエンタープライズグレードの機能とセキュリティをローカル環境で提供し、ハイブリッド環境全体で一貫した運用を可能にします。Nick Ponomar MQTTに関するストーリーを組み込めるかどうかははっきりとしませんが、Edgeを全体的なストーリーの一部としてEdgeを含めるべきだと確実に思います。

クラウド

Cumulocityには、信頼の基盤（トラストアンカー）の構築、証明書の署名、および証明書のライフサイクル管理をすべてCumulocity内で実行できる認証局（CA）機能が備わっています。これにより、すべてのお客様にとって、証明書ベースの認証を導入する際のハードルが低くなります。

証明書発行機関（CA）機能（証明書ベースの認証を可能にする）と、標準で搭載されたMQTTデバイス分離機能を組み合わせることで、Cumulocityは今日の市場において最も安全なIoTソリューションの一つとなっています。デバイスの形状に関わらず、Cumulocityへデータを送信する際のセキュリティを確保するために、追加の設定や専門的な知識は必要ありません。

シンプルさ

お客様との議論から得られた重要なポイントは、デバイスを接続する際に、決めるべきポイントや設定項目を最小限に抑えたいという要望です。私たちはこの声に耳を傾け、それに応じてMQTTサービスを設計しました。

Cumulocityは、MQTTサービスに接続するデバイスが使用するMQTTクライアント識別子、トピックスキーマ、またはペイロード形式について、いかなる制限も課しません。ほとんどのデバイスは、サーバーアドレスと認証情報（信頼された証明書、またはユーザー名とパスワード）を設定するだけで、接続してパブリッシュを開始できるはずです。もちろん、ほとんどのデバイスはCumulocityのドメインモデルをネイティブにサポートしていないため、マッピングを提供する必要があります。これは、カスタムマイクロサービス、Dynamic Mapperなどの既存ツール、あるいは今後提供されるAI搭載のCumulocity Data Preparation機能によって実装可能です。

Data Preparationでは、以下の機能を標準で提供予定です：設定不要で新しいデバイスをCumulocityプラットフォームに自動的に登録する機能です。デバイスがCumulocityと接続されるようになると、Data PreparationではJavascriptスマート関数を使用して、デバイスデータをCumulocityのフォーマットにマッピングできるようになります。Javascriptスマート関数は、プロトコルの記述に基づいて、あるいはデバイスからのメッセージを動的に解析することで、AIを使用して生成できます。必要に応じて、スマート関数を手動で作成することも可能です。

一方、SmartREST または JSON-over-MQTT 形式を使用して、すでに Cumulocity ドメインモデルをサポートしているデバイスは、これまでと全く同じように動作し続けることができます。1つのデバイスが、同じMQTTセッション内で、SmartRESTトピックにSmartRESTメッセージを、他のトピックに「汎用」メッセージを送信することも可能です。現在、Cumulocityの標準フォーマットを使用するメッセージは、Cumulocityコア内の既存のMQTTエンドポイントにブリッジされています。長期的なロードマップでは、このエンドポイントをコアから切り離し、すべてのMQTTトラフィックを単一のMQTTサービスエンドポイントで処理する予定です。

Cumulocityのマルチテナント機能とMQTTサービスのデバイス分離機能により、トピックスキーマの競合やデバイス間の望ましくない相互作用を心配することなく、デバイスを導入(オンボード)できます。相互に互換性のないデバイスであっても、マッピング層が各デバイスのタイプを適切に処理できる限り、同じテナント内で共存することが可能です。

結論

CumulocityのマネージドMQTTサービスは、IoT向けに特別に設計されており、実証済みの拡張性（1億台のデバイスに対応）、99.9%の稼働率、エンタープライズグレードのセキュリティを兼ね備え、デバイスの導入（オンボーディング）を簡素化し、展開を加速します。

Cumulocityのサービスは、既存のエンタープライズ向けブローカーを改造したものではありません。IoT向けに専用設計されており、デバイス管理、分析、自動化との統合が図られています。

安全性を標準装備 デバイスの分離機能により、あるデバイスが別のデバイスのデータにアクセスすることを防止します。TLS暗号化により、すべての通信が保護されます。デバイスへの証明書バインディングにより、接続の瞬間から身元保証が徹底されます。 実証済みのスケーラビリティとパフォーマンス 本システムは、1億台の接続デバイスおよび毎秒100万メッセージの処理能力が実証されています。水平スケーリングにより、再設計なしで拡張が可能です。 エンタープライズグレードのメッセージングバックボーン メッセージングバックボーンは、必要なインフラを肥大化させることなくスケーリングできる能力に加え、数多くのメリットを提供します。デバイスが使用するプロトコルに関係なく、アプリケーションはプロトコルに依存しない方法でデバイスのペイロードを処理できます。また、アプリケーションは、MQTTのような軽量でデバイス指向のプロトコルでは標準的ではない、エンタープライズグレードのメッセージング機能を利用できます。これには、キー共有サブスクリプション、デッドレターキューやその他のエラー処理メカニズム、累積確認応答、階層型ストレージなどが含まれます。 簡単なデバイスオンボーディング Thin Edgeとの統合により、特に証明書認証を行うデバイスのオンボーディングが簡素化されます。SmartRESTブリッジは、単一のMQTTエンドポイントを通じてデバイス管理をさらに一元化します。また、Cumulocity Data Preparationは、自動データマッピング機能により、デバイスの登録を容易にします。 競合優位性 Cumulocityは、IoTへの注力、セキュリティ、スケーラビリティ、導入の容易さ、そして15年にわたるIoTの経験によって他社との差別化を図っています。一般的なブローカーとは異なり、数百万台のデバイス、頻繁な再接続、およびマルチプロトコル統合に対応するように設計されています。

今すぐ行動を

今こそ、自社組織をIoTのリーダーシップに向けて準備し、体制を整えるべき時です。接続するデバイスが数千台であれ数百万台であれ、適切なアーキテクチャの有無が、イノベーションのスピードや大規模な運用効率を左右します。今すぐCumulocityチームにご連絡いただき、MQTT戦略の策定を始めましょう。当社は、お客様の現在のニーズを満たし、将来の目標にも柔軟に対応できる、世界最高水準のIoTメッセージングソリューションの設計、移行、導入を支援いたします。

ゲームを変えるIoTソリューションの構築を始める準備はできていますか？

素早くスタート。

簡単にスケール。

市場と共に進化。

IoTエキスパートにお問い合わせ