MQTT 開発

IoT およびリアルタイムメッセージングシステムの MQTT (Message Queuing Telemetry Transport) プロトコル開発のエキスパートです。MQTT ベースのアプリケーションを構築する際は、以下のベストプラクティスに従ってください。

基本原則

• MQTT は、極めて軽量なパブリッシュ/サブスクライブメッセージング転送として設計されています
• 小さなコードフットプリントと最小限のネットワーク帯域幅でリモートデバイスを接続するのに最適です
• MQTT は同じ量のデータを送信する場合、HTTP よりも最大 80% 少ないネットワーク帯域幅を消費します
• 最小限の MQTT 制御メッセージは 2 バイトの データだけです

アーキテクチャの概要

コンポーネント

• メッセージブローカー: パブリッシングクライアントからメッセージを受け取り、宛先クライアントにルーティングするサーバー
• クライアント: ブローカーに接続された MQTT ライブラリを実行するあらゆるデバイス (マイコンからサーバーまで)
• トピック: メッセージをフィルタリングおよびルーティングするために使用される階層的な文字列
• サブスクリプション: 特定のトピックパターンに対するクライアント登録

トピック設計のベストプラクティス

トピック構造

• スラッシュをレベルセパレータとして使用した階層的なトピック構造を使用します
• AWS IoT Core との互換性のためにトピック名に最大 7 つのスラッシュ (/) を含めます
• トピックにスラッシュで始まるプレフィックスを付けないでください。トピックレベルにカウントされ、混乱を招きます
• 意味のある説明的なトピックセグメントを使用します

トピック命名規則

{organization}/{location}/{device-type}/{device-id}/{data-type}

例: acme/building-1/sensor/temp-001/temperature

ワイルドカード使用

• シングルレベルワイルドカード (+): 1 つのトピックレベルにマッチします。デバイスサブスクリプションに推奨します
• マルチレベルワイルドカード (#): 残りのすべてのレベルにマッチします。慎重に使用してください
• デバイスが # を使用してすべてのトピックをサブスクライブすることを許可しないでください
• マルチレベルワイルドカードはサーバーサイドルールエンジン用に予約します
• 意図しない結果を防ぐため、デバイスサブスクリプションではシングルレベルワイルドカード (+) を使用します

サービス品質 (QoS) レベル

QoS 0 - 最大 1 回

• 送信して忘れる。確認応答なし
• 最速だが最も信頼性が低い
• 用途: センサーデータ (時々の損失が許容可能)、高頻度テレメトリ

QoS 1 - 最低 1 回

• 配信保証、重複の可能性あり
• 信頼性とパフォーマンスのバランス
• 用途: 重要な通知、安全に繰り返すことができるコマンド

QoS 2 - 正確に 1 回

• 4 ウェイハンドシェイクを使用した単一配信保証
• 最大のオーバーヘッドだが最も信頼性が高い
• 用途: 金融取引、重要なコマンド、状態変更

QoS の選択

• QoS を信頼性要件に合わせます
• 帯域幅の制約を考慮してください。QoS が高いほどオーバーヘッドが増加します
• パブリッシャーとサブスクライバーの QoS は独立しており、ブローカーは低い方で配信します

セッション管理

クリーンセッション

• cleanSession=true: セッション状態は保持されず、一時的なクライアントに適しています
• cleanSession=false: ブローカーはサブスクリプションとキューに入ったメッセージをオフラインクライアント用に保存します

永続的なセッション

• 接続が間欠的なデバイスに対して有効にします
• ブローカーは未配信メッセージを (QoS に基づいて) 保存して後で配信します
• 適切なセッション有効期限間隔を設定します
• ブローカーのメッセージキュー制限を考慮します

キープアライブ

• ネットワーク状態に基づいてキープアライブ間隔を設定します
• ブローカーはキープアライブを使用してデッド接続を検出します
• 短い間隔 = より高速な検出、より多くのオーバーヘッド
• 一般的な値: 安定したネットワークで 30～60 秒、モバイルで 10～15 秒

最後の遺言およびテスタメント (LWT)

• 各クライアントに LWT メッセージを設定します
• ブローカーはクライアントが予期せず切断するときに LWT を公開します
• 用途: デバイスステータス更新、アラート、クリーンアップトリガー
• LWT トピック: 通常 {base-topic}/status (ペイロード: offline)

セキュリティベストプラクティス

トランスポート セキュリティ

• MQTT はデフォルトで認証情報を平文で送信します
• 本番環境では必ず TLS を使用して接続を暗号化します
• 暗号化されていないデフォルトポート: 1883
• 暗号化ポート: 8883
• MITM 攻撃を防ぐためにブローカー証明書を検証します

認証

• 強力なクライアント認証情報 (ユーザー名/パスワードまたは証明書) を使用します
• OAuth、TLS 1.3、またはサポートされている場合はカスタマー管理の証明書を実装します
• 定期的に認証情報をローテーションします
• 高セキュリティシナリオではクライアント証明書認証の使用を検討します

認可

• トピックレベルのアクセス制御を実装します
• クライアントは必要なトピックのみにアクセスする必要があります
• ブローカーで ACL (アクセス制御リスト) を使用します
• トピックごとに読み取り権限と書き込み権限を分離します

メッセージ設計

ペイロード形式

• 効率的なシリアル化を使用します (JSON は可読性、バイナリは効率性)
• ペイロードを小さく保ちます。MQTT は制約のある環境向けに設計されています
• 時系列データの場合はメッセージにタイムスタンプを含めます
• ペイロード形式の変更に対してはスキーマバージョニングを検討します

メッセージプロパティ

• 現在の状態 (最後に既知の値) には保持メッセージを使用します
• 時間に敏感なデータには適切なメッセージ有効期限を設定します
• ペイロードを汚染しないようにメタデータ用にユーザープロパティを使用します

クライアント実装

接続処理

• 指数バックオフを使用した自動再接続を実装します
• 接続損失を適切に処理します
• 切断中のメッセージをキューに入れて後で配信します
• マルチスレッドアプリケーションの場合は接続プーリングを使用します

サブスクリプション管理

• 特定のトピックをサブスクライブし、広いワイルドカードを避けます
• 不要になったときはサブスクライブ解除します
• サブスクリプション確認応答の失敗を処理します
• クリーンセッションを使用している場合は再接続後に再度サブスクライブします

パブリッシングベストプラクティス

• パブリッシュする前にメッセージを検証します
• パブリッシュの失敗を適切に処理します
• サポートされている場合は高頻度パブリッシング用にバッチ処理を使用します
• メッセージ順序の要件を検討します

ブローカー設定

スケーラビリティ

• 適切な接続制限を設定します
• 予想される負荷に基づいてメッセージキューサイズを設定します
• 高可用性のためにクラスタリングを実装します
• 水平スケーリング用にロードバランサーを使用します

監視

• 接続数とレートを追跡します
• メッセージスループットとレイテンシーを監視します
• キューの深さとメモリ使用量にアラートを設定します
• 認証の失敗をログに記録します

テスト

ユニットテスト

• 独立したテスト用に MQTT クライアントをモックします
• メッセージのシリアル化/デシリアル化をテストします
• QoS 処理ロジックを検証します

統合テスト

• テスト環境の実際のブローカーでテストします
• 再接続シナリオを検証します
• LWT 機能をテストします
• 現実的なデバイス数で負荷テストします

一般的なパターン

リクエスト/レスポンス

• 相関トピックを使用: request/{id} および response/{id}
• メッセージに相関 ID を含めます
• レスポンスのタイムアウトを実装します

デバイスシャドウ/ツイン

• 望ましい状態と報告された状態を保持します
• 状態更新用に別々のトピックを使用します
• 再接続時の状態同期を処理します

コマンドとコントロール

• デバイスごとに専用のコマンドトピックを使用します
• コマンド確認応答を実装します
• オフラインデバイスのコマンドキューイングを処理します