配信保証
配信保証または「配信モード」は、メッセージングシステムが処理するメッセージの配信をどの程度強く保証するかを定義します。各モードにはいくつかのトレードオフがあります。メッセージ配信に関する保証を強化するにつれて、システムはメッセージが配信されることを確認するために、より多くのチェックや確認を行う必要があり、またはメッセージが指定された回数だけ配信されることを保証するために状態を維持する必要があります。これにより、システムのレイテンシが増加し、全体的なスループットが低下します。各「実際の」メッセージは、配信されたと見なされる前に、追加の2〜4メッセージと同等の追加のラウンドトリップを必要とする場合があります。
Pub/SubはMQTTプロトコルに基づいており、メッセージごとの配信保証やサービスの品質 ↗に関する柔軟性を提供します。
| レベル | デフォルト | 現在サポートされている | 詳細 | 最適な用途 |
|---|---|---|---|---|
| 最多一度 (QoS 0) | はい | はい | 「ベストエフォート」と呼ばれることが多く、メッセージは受信の正式な確認なしに公開され、再送信されません。 このモードは、送信または配信されたメッセージに対して追加の確認パケットを生成しないため、パフォーマンスオーバーヘッドが最も少ないです。 ネットワークやシステム全体の信頼性に応じて、受信者が受信を確認する必要がないため、一部のメッセージが失われる可能性があります。 | テレメトリ、メトリクス、イベントデータなど、データポイントが迅速に上書きされる場合や、高速でメッセージが送信され、クライアントのリソース利用を最小限に抑えたい場合。 QoS 0は、確認オーバーヘッドがないため、最も低いレイテンシを提供し、したがってクライアントごとのスループットが最も高くなります。 |
| 最少一度 (QoS 1) | - | いいえ | 通常、ハンドシェイクまたは「確認」プロトコルを通じて実装され、メッセージは受信者によって正式に確認されるまで再送信されます。 システムの動作や構成に応じて、メッセージは再送信され、したがって複数回配信される可能性があります。追加の確認パケットによる小さなオーバーヘッドが発生します。 | トランザクション処理、ほとんどのチャットメッセージング、IoTデバイスへのリモートコマンド処理など。 受信者は、各メッセージがユニークな識別子または「冪等性キー」を持つことを確認することで、重複を処理できることが多いです。メッセージが複数回受信されても、データベース層は重複キーを拒否します。 |
| 正確に一度 (QoS 2) | - | いいえ | 達成が最も難しく、クライアント、サーバー、ネットワークの両方でメッセージごとに重要なオーバーヘッドが発生します。 配信を確認する方法だけでなく、メッセージが一度だけ受け入れられ、重複が破棄されることを保証するために、送信者と受信者の追加の状態が必要です。 | 受信者がメッセージを一度だけ受け取る必要がある処理ユースケース。メッセージレートが比較的低く、レイテンシが主要な懸念事項でない場合に理想的です。 これは通常非常に稀であり、QoS 2は追加の確認パケットのために自然にレイテンシを増加させ、スループットを低下させます。発行者、受信者、または永続性層が冪等挿入を処理できるように変更できない場合にのみQoS 2を使用するべきです。 |
各モードにはいくつかのトレードオフがあります。メッセージ配信に関する保証を強化するにつれて、システムはメッセージが配信されることを確認するために、より多くのチェックや確認を行う必要があり、またはメッセージが指定された回数だけ配信されることを保証するために状態を維持する必要があります。これにより、システムのレイテンシが増加し、全体的なスループットが低下します。各「実際の」メッセージは、配信されたと見なされる前に、追加の2〜4メッセージと同等の追加のラウンドトリップを必要とする場合があります。
MQTTは、他のメッセージングシステムが行うように、ブローカーやトピックごとではなく、メッセージごと（PUBLISHレベル）で配信保証を指定します。
- これにより、追加の柔軟性が提供されます。小さな割合の「失われた」メッセージを許容できる一般的なメトリクスやテレメトリデータは、デフォルトのQoSレベル0（最多一度）で送信できます。
- 例えば、1000のセンサー読み取りのうち5〜10のメッセージが失われても、特にペイロードが小さく、データが次の読み取りによって迅速に上書きされる場合、後続のデータ分析に影響を与える可能性は低いです。
- しかし、他のケース、例えば他のユーザーにチャットメッセージを配信する場合や、中央システムにトランザクションデータを公開する場合は、より高いQoSレベルを設定できること — QoSレベル1は「最少一度」に対応し、QoSレベル2は「正確に一度」に対応します — これにより、これらのメッセージのみが追加のオーバーヘッドを負担します。 ほとんどのユースケースでは、QoSレベル0は高ボリュームのテレメトリやセンサーデータに最適であり、配信の具体的な確認が必要ない場合です。他のケース、例えばトランザクションデータ、チャットメッセージ、またはユーザー向け通知を公開する場合は、QoSレベル1（「最少一度」）が推奨されます。