「Web - MQTTブローカー」の版間の差分
| 34行目: | 34行目: | ||
<br> | <br> | ||
[[ファイル:MQTT Broker 1.png|フレームなし|中央]] | [[ファイル:MQTT Broker 1.png|フレームなし|中央]] | ||
<br><br> | |||
== パブリックMQTTブローカーサービス (無料 / 有料) == | |||
* HiveMQ Cloud (無料枠あり) | |||
*: 100台までのデバイス接続可能。 | |||
*: TLS暗号化対応。 | |||
*: 10[KB]/秒までのデータ転送可能。 | |||
*: <br> | |||
* CloudMQTT (現在はUpstashの一部) | |||
*: スモールスケール向けの無料プラン有り。 | |||
*: 管理画面が理解しやすい。 | |||
*: セキュリティ設定が充実している。 | |||
*: <br> | |||
* AWS IoT Core | |||
*: AWSの完全マネージドサービス | |||
*: 高度なセキュリティ機能 | |||
*: 他のAWSサービスと連携可能 | |||
*: 従量課金制 | |||
*: <br> | |||
* test.mosquitto.org (テスト向けは無料) | |||
*: <u>テストや学習用</u> | |||
*: セキュリティの保証が無いため、本番環境での使用は非推奨である。 | |||
<br><br> | |||
== パブリックMQTTブローカーサービスとオンプレミスの比較 == | |||
==== パブリックMQTTブローカーサービス ==== | |||
===== メリット ===== | |||
* すぐに利用開始可能 | |||
* 運用管理不要 | |||
* 高可用性 | |||
* 自動スケーリング | |||
* セキュリティ対策済み | |||
<br> | |||
===== デメリット ===== | |||
* コストが発生 (規模による) | |||
* カスタマイズの制限 | |||
* ベンダーロックイン | |||
* データの管理場所に制約 | |||
<br> | |||
==== オンプレミス ==== | |||
===== メリット ===== | |||
* コスト削減可能 | |||
* 完全なカスタマイズ制御 | |||
* データの完全な管理 | |||
* ネットワーク遅延の最適化 | |||
<br> | |||
===== デメリット ===== | |||
* 保守運用の負担 | |||
* セキュリティ対策が必要となる。 | |||
* スケーリングの手間 | |||
* 可用性の確保が必要となる。 | |||
<br> | |||
==== 推奨される環境 ==== | |||
開発を始める場合は、まず、パブリックサービスの無料枠を使用して、システムの動作確認や要件の明確化を行う。<br> | |||
その後、本番環境に適したソリューションを選択することを推奨する。<br> | |||
<br> | |||
===== 開発 / テスト段階 ===== | |||
最初は、test.mosquitto.org や HiveMQ Cloudの無料枠を使用することを推奨する。<br> | |||
これは、素早く開発を始められ、かつ、コストがかからないからである。<br> | |||
<br> | |||
===== 小規模な本番環境の場合 ===== | |||
HiveMQ Cloud や CloudMQTT の小規模プランを使用することを推奨する。<br> | |||
これは、運用の手間を省けることができ、コストが安いからである。<br> | |||
<br> | |||
===== 大規模な本番環境 ===== | |||
AWS IoT Core 等のエンタープライズサービスを使用することを推奨する。<br> | |||
<br> | |||
または、十分な運用体制がある場合は自身で構築する。<br> | |||
これは、スケーラビリティとセキュリティを重視する必要がある。<br> | |||
<br><br> | <br><br> | ||
2024年11月13日 (水) 06:05時点における版
概要
MQTTブローカーは、IoTデバイスやアプリケーション間のメッセージ通信を仲介する重要なコンポーネントである。
出版社と購読者の関係に似たPublish / Subscribeモデルを採用しており、各デバイスやアプリケーションはブローカーを介してメッセージをやり取りする。
ブローカーの主な役割は、発行されたメッセージを適切な購読者に配信することである。
例えば、温度センサがデータを発行すると、そのトピックを購読している全てのクライアントにブローカーが自動的にメッセージを転送する。
セキュリティ面では、ユーザ認証や暗号化通信をサポートしており、機密性の高い情報でも安全に扱うことができる。
また、QoS (Quality of Service) レベルを設定することにより、メッセージの配信保証レベルを制御できる。
人気のあるMQTTブローカーとしては、Mosquitto、HiveMQ、EMQX等がある。
これらはオープンソースで提供されており、小規模なプロジェクトから大規模な商用システムまで幅広く利用されている。
ブローカーの特徴的な機能として、トピックベースのフィルタリングがある。
トピックは階層構造を持ち、ワイルドカードを使用することで柔軟なメッセージのルーティングが可能である。
例えば、"sensors / temperature/+"というトピックを購読することで、全ての温度センサからのデータを受信できる。
また、多くのブローカーは永続化機能を備えており、クライアントが一時的にオフラインになった場合でも、メッセージを保持して、再接続時に配信することができる。
これにより、不安定なネットワーク環境でも確実なメッセージングが実現できる。
スケーラビリティの面では、クラスタリングやロードバランシングをサポートしているブローカーも多く、大規模なIoTシステムの構築も可能である。
MQTTブローカーは、IoTシステムにおける中心的な役割を果たしており、効率的で信頼性の高いメッセージング基盤を提供する。
メッセージングの基本的なフロー
下図では、MQTTの非同期メッセージング方式、および、1対多の通信パターンを表現している。
また下図において、以下に示す要素を表現している。
- Publisher (発行者) として温度センサと湿度センサを配置する。
- MQTTブローカーを配置する。
- Subscriber (購読者) として、データロガー、モニタリングアプリ、アラートシステムを配置する。
- また、トピックベースの通信 (sensors/tempやsensors/humidity)、ワイルドカードの使用 (sensors/+およびsensors/#) を示している。

パブリックMQTTブローカーサービス (無料 / 有料)
- HiveMQ Cloud (無料枠あり)
- 100台までのデバイス接続可能。
- TLS暗号化対応。
- 10[KB]/秒までのデータ転送可能。
- CloudMQTT (現在はUpstashの一部)
- スモールスケール向けの無料プラン有り。
- 管理画面が理解しやすい。
- セキュリティ設定が充実している。
- AWS IoT Core
- AWSの完全マネージドサービス
- 高度なセキュリティ機能
- 他のAWSサービスと連携可能
- 従量課金制
- test.mosquitto.org (テスト向けは無料)
- テストや学習用
- セキュリティの保証が無いため、本番環境での使用は非推奨である。
パブリックMQTTブローカーサービスとオンプレミスの比較
パブリックMQTTブローカーサービス
メリット
- すぐに利用開始可能
- 運用管理不要
- 高可用性
- 自動スケーリング
- セキュリティ対策済み
デメリット
- コストが発生 (規模による)
- カスタマイズの制限
- ベンダーロックイン
- データの管理場所に制約
オンプレミス
メリット
- コスト削減可能
- 完全なカスタマイズ制御
- データの完全な管理
- ネットワーク遅延の最適化
デメリット
- 保守運用の負担
- セキュリティ対策が必要となる。
- スケーリングの手間
- 可用性の確保が必要となる。
推奨される環境
開発を始める場合は、まず、パブリックサービスの無料枠を使用して、システムの動作確認や要件の明確化を行う。
その後、本番環境に適したソリューションを選択することを推奨する。
開発 / テスト段階
最初は、test.mosquitto.org や HiveMQ Cloudの無料枠を使用することを推奨する。
これは、素早く開発を始められ、かつ、コストがかからないからである。
小規模な本番環境の場合
HiveMQ Cloud や CloudMQTT の小規模プランを使用することを推奨する。
これは、運用の手間を省けることができ、コストが安いからである。
大規模な本番環境
AWS IoT Core 等のエンタープライズサービスを使用することを推奨する。
または、十分な運用体制がある場合は自身で構築する。
これは、スケーラビリティとセキュリティを重視する必要がある。
MQTTブローカーの構築 : オンプレミス