mqtt-development

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 ウェイハンドシェイクにより、1 回だけの配信が保証されます
• オーバーヘッドは最大ですが、信頼性も最も高くなります
• 用途：金融取引、重要なコマンド、状態の変更

QoS の選択

• 信頼性の要件に合わせて 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 を含めます
• レスポンスにタイムアウトを実装します

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

• 目標状態と報告状態を維持します
• 状態更新には個別のトピックを使用します
• 再接続時の状態同期を処理します

コマンドと制御

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