Pub/Subの仕組み
Cloudflare Pub/Subは、リモートクライアントとの間でメッセージを送信（公開）するための強力な方法です。
Pub/Subを理解するための4つの主要な概念があります：
ブローカーとネームスペースは、クライアント、トピック、およびそれに関連する権限を整理するための基本的な「コンテナ」です。
-
ネームスペースは、場所、エンドカスタマー、環境（本番 vs. ステージング）、または組織内のチームによって整理できるブローカーのコレクションです。始めるときは、通常1つのネームスペースで十分です。ネームスペースはすべての顧客に対してグローバルに一意です。
-
ブローカーは、MQTTで「サーバー」を指すために一般的に使用される用語ですが、MQTTの「サーバー」は実際には、あるクライアントセットからメッセージを受け取り、次のクライアントに送信するリレーまたはプロキシであるため、典型的なクライアントサーバーアーキテクチャと区別するためにブローカーという用語が使用されます。クライアントとその資格情報はブローカーにスコープされ、ブローカー自体はTCPポート上でクライアントからのMQTT接続を受け入れるアドレス指定可能なエンドポイントです。
例えば、acme-telemetryというネームスペースとdev-brokerというブローカーを作成することができます。これにより、認証されたクライアントが接続し、メッセージを送信（公開）し、受信（サブスクライブ）できるエンドポイントdev-broker.acme-telemetry.cloudflarepubsub.comが定義されます。
すべてのクライアントは、ブローカーに接続する許可があることを証明するために認証を行う必要があり、資格情報はブローカーごとにスコープされます。dev-broker.acme-telemetry.cloudflarepubsub.comの資格情報を持つクライアントは、同じアカウント内であってもprod-broker.acme-telemetry.cloudflarepubsub.comに接続するためには別の資格情報セットが必要です。
- 認証はMQTT標準に基づいており、ユーザー名とパスワード（しばしばトークン認証と呼ばれる）認証や、実装特有の相互TLS（しばしばTLSクライアント資格情報と呼ばれる）に基づく認証が可能です。
- Cloudflare Pub/Subでは、クライアントごとのトークンを発行するのが最も簡単な方法です。トークンは認証フローにおけるパスワードの代わりを果たします。これらのトークンは、Cloudflareによってのみ生成できる署名されたJSON Web Tokens ↗です。署名されているため、クライアントID、権限、またはトークンに埋め込まれた他の主張は、署名を無効にすることなく変更することはできません。
認証がどのように処理されるかについての詳細は、認証と承認を参照してください。
トピックはPub/SubとMQTTのコア概念であり、すべてのメッセージは公開されたトピック内に含まれています。MQTTでは、トピックは異なるトピックレベルを示すために/（スラッシュ）文字で区切られた文字列であり、サブスクライバーのための階層を定義します。重要なことに、MQTTプロトコルの利点の1つは、トピックを中央で定義する必要がないことです。クライアントは、ブローカーがそのクライアントに対して許可している限り、任意のトピックに公開できます。これにより、必要に応じてメッセージを柔軟にグループ化できます。
Pub/Subクライアントは、同時にパブリッシャーとサブスクライバーの両方になることができ、複数のトピックに同時に公開およびサブスクライブできます。
トピックを構築し命名する際のベストプラクティスのセットとして：
- トピックを一貫した階層として定義します。たとえば、location/data-type/data-format/。たとえば、EUのクライアントがHTTPメトリクスデータを公開する場合、
eu/metrics/request_countに公開することで、サブスクライバーがデータをより簡単に特定できるようにします。 - トピック名の大文字と小文字の一貫性を確保します。トピックはMQTTプロトコルで大文字と小文字を区別し、
eu/metrics/request_countにサブスクライブしているクライアントは、EU/metrics/request_count（大文字の「EU」）に公開されたメッセージを受信することはありません。 - 過度に長いトピック名を避けます（MQTT仕様は最大65Kバイトをサポート）。長いトピック名はペイロードサイズを増加させ、パブリッシャーとサブスクライバーの両方でメッセージ処理のコストを増加させます。
- トピック名に先頭スラッシュを避けます。
/us/metrics/transactions_processedはus/metrics/transactions_processedとは異なるトピックです。先頭のスラッシュは不要です。
Cloudflare Pub/Subが構築されているMQTT標準では、メッセージはPUBLISHパケット ↗内のペイロードとして定義されています。ペイロード自体は、ほとんどの開発者が扱うことに慣れているUTF-8文字列であるか、より複雑なユースケースやProtobufやMessagePackなどの他のシリアライズデータ形式を使用する場合のバイトストリーム（「バイト配列」）です。
MQTT v5.0に基づくPub/Subでは、ペイロードが文字列かバイトストリームかを示す追加のフィールドを設定することもできます。payloadFormatIndicator（バイトの場合は0、文字列の場合は1）プロパティと、MIMEタイプ ↗を受け入れるcontentTypeプロパティの両方を使用して、クライアントはペイロード形式をより明確に定義できます。
Pub/Subメッセージを送信する際のベストプラクティスのセットとして、次のことを考慮すべきです：
- メッセージのサイズを適切に保ちます。クライアントでデータを1KB（または2〜3秒ごと）までバッファリングすることは、メッセージサイズ、スループット、および全体的なシステムのレイテンシを最適化する良い方法です。
- メッセージを公開する際に
payloadFormatIndicatorプロパティを設定します。これにより、サブスクライバーやワーカーにメッセージの解析方法についてのヒントを与えます。 contentTypeプロパティをペイロードのMIMEタイプに設定します。たとえば、application/jsonやapplication/x-msgpackなど、特にクライアントが異なる形式でメッセージを積極的に公開している場合に追加のヒントとして役立ちます。