Oracle Cloud Infrastructureドキュメント

キュー内の多数のコンシューマ・グループへのメッセージのファンアウト

単一のOCIキューから多数のコンシューマ・グループにメッセージを送受信し、各グループにフィルタを適用することで、スケーラブルで低レイテンシのプルベースのアプリケーション間メッセージングを実現

ファンアウトを使用すると、1つのメッセージを異なるコンシューマ・グループに同時に送信できるため、1つのキューから多数のチームまたはサービスと更新を簡単に共有できます。これは、だれがどのメッセージを取得するかを正確に制御できるため、すべてのグループには関連するもののみが表示されるため便利です。

ファンアウトを使用するには、各メッセージに添付されたメッセージ属性を評価するフィルタを作成します。フィルタがtrueと評価されるコンシューマ・グループのみがメッセージを受信します。

コンシューマ・グループ

コンシューマ・グループは、キュー内の永続的で論理的な配信パスです。各コンシューマ・グループは、設定したフィルタに基づいてメッセージを個別に受信します。
ノート

コンシューマ・グループをキューで使用する前に、コンシューマ・グループを有効にする必要があります。これは、キューを作成または編集するときに実行できます。
キューのコンシューマ・グループを有効にすると、キュー・サービスによってプライマリ・コンシューマ・グループと呼ばれるデフォルト・グループが自動的に作成されます。デフォルト・グループにフィルタを追加したり、削除することはできませんが、必要に応じて無効にできます。このグループはスーパーセットと考えることができます。有効になっているかぎり、他のグループに設定されたフィルタに関係なく、キューにパブリッシュされたすべてのメッセージを受信します。
ノート

プライマリ・グループは、すべてのメッセージに宛先があることを確認します。プライマリ・コンシューマ・グループを非アクティブに設定した場合、そのグループを介してメッセージは受信されません。プライマリ・グループが非アクティブで、他のグループのフィルタと一致しない間は、送信されたすべてのメッセージが削除されます。これらのメッセージはリカバリできません。メッセージが失われないようにするには、特定のメッセージを破棄しないかぎり、プライマリ・コンシューマ・グループを有効にしたままにします。

デフォルトのコンシューマ・グループに加えて、特定のコンシューマにメッセージを配信するために必要な数のコンシューマ・グループを追加できます。各グループは他のグループとは独立して動作するため、メッセージは個別に配信、フィルタリングおよび追跡されるため、消費者間の分離と公平性が確保されます。各グループにフィルタを設定して、受信するメッセージを制御できます。フィルタを設定しないか、フィルタを空のままにすると、グループはデフォルト・グループと同様にすべてのメッセージを受信します。

デフォルトの(プライマリ)コンシューマ・グループと作成するコンシューマ・グループの違いを次に示します。

機能 デフォルト・コンシューマ・グループ(プライマリ) その他のコンシューマ・グループ
作成方法 コンシューマ・グループが有効化されると自動的に作成されます。 必要に応じて手動で作成
削除可能 いいえ はい
無効にできます。 はい はい
フィルタを設定できます。 いいえ はい
すべてのメッセージを受信 はい(有効な場合) フィルタに一致するメッセージのみ、またはフィルタが設定されていない場合はすべてのメッセージ
DLQ配送数を設定できます いいえ はい
OCID キューOCIDと同じ グループ当たりの一意のOCID

使用例

請求イベントのキューを作成するとします。デフォルトのコンシューマ・グループは請求コンプライアンス・チーム用であり、コンプライアンス上の理由からすべてのメッセージを受信する必要があります。また、エグゼクティブ経費を処理するチームに別のコンシューマ・グループを追加し、このグループが属性team = "exec-expenses"のメッセージのみを受信するようにフィルタを設定します。これにより、エグゼクティブ経費チームのノイズが軽減され、関連するメッセージのみが得られるようになります。

メッセージおよび属性

メッセージには、オプションで属性、プロデューサによって追加情報(メタデータ)として追加されたキーと値のペアを含めることができます。属性は、メッセージに関する詳細(リージョン、優先度、イベント・タイプなど)を記述し、コンシューマ・グループへのメッセージのきめ細かなフィルタリングおよびターゲティングの実行に役立ちます。

属性を作成する際のプロデューサに関するいくつかのガイドラインを次に示します。

  • 属性のキーと値では大文字小文字が区別されます。
  • 属性値は、サポートされているデータ型のいずれかである必要があります。
    • 文字列: UTF-8でエンコードされた文字列。
    • 数値: 整数または10進数値。
  • 属性は、合計メッセージ・サイズにカウントされます。
属性キーに名前を付ける際のヒントを次に示します。
  • 属性キーは、文字またはアンダースコア(_)で開始する必要があります。
  • 属性キーには、文字、数字、ハイフン(-)またはアンダースコア(_)のみを含めることができます。
  • キーの周囲に引用符を使用しないでください。

フィルタリング

フィルタを使用して、コンシューマ・グループが受信するメッセージを制御します。メッセージがパブリッシュされると、キュー・サービスは、各メッセージの属性に対してフィルタをチェックして、メッセージをそのコンシューマ・グループに配信するかどうかを決定します。メッセージがコンシューマ・グループに配信されるのは、そのフィルタが属性と一致する場合のみです。
ノート

フィルタは、メッセージ本文ではなく、メッセージ属性でのみ機能します。

フィルタは、コンシューマ・グループの作成時に作成します。各コンシューマ・グループは独自のフィルタを持つことができ、コンシューマ・グループごとに1つのフィルタを作成できます。

フィルタ式は、グループが取得するメッセージを決定するために記述するSQLのようなルールです。

フィルタ式の制約

フィルタ式を記述して使用する方法を定義するルールを次に示します。これにより、フィルタは必要な方法で機能します。
  • フィルタ式では大/小文字が識別されます。たとえば、:region = "us-ashburn-1"は:region = "US-ASHBURN-1"とは異なります。
  • フィルタ式は、最大256文字です。

フィルタ評価

OCI Queue Serviceがフィルタをチェックするとどうなりますか。また、どのフィルタにも一致しないメッセージはどうなりますか。
  • キュー・サービスは、メッセージが最初にキューにパブリッシュされたときにのみフィルタをチェックします。
  • キュー・サービスは、メッセージが最初にキューにパブリッシュされたときにのみフィルタをチェックします。コンシューマ・グループを後で再有効化したり、そのフィルタを変更しても、キュー内の既存のメッセージは遡及的に評価されません。更新されたフィルタに対して新しいメッセージのみがチェックされます。
  • メッセージに一致するコンシューマ・グループのフィルタがなく、プライマリ・グループが無効になっている場合、メッセージは削除され、取得できません。メッセージが削除されるたびに、キューはメトリックを発行します。このメトリックは、コンソールのキュー・サービスまたはOCIのモニタリングで表示できます。

フィルタ式モデル

使用できるフィルタ式のタイプは次のとおりです。

キーの存在

キー・プレゼンス・フィルタを使用して、メッセージに特定の属性が含まれているかどうかを確認します。

フィルタ式の例を次に示します。

  • :region: 値が何であるかに関係なく、region属性が設定されているメッセージと一致します。
  • NOT :region: region属性を持たないメッセージと一致します。

文字列フィルター

文字列フィルタを使用して、テキスト属性の値に基づいてメッセージを照合します。テキスト内の完全一致、差異またはパターンをチェックできます。

フィルタ式の例を次に示します。

  • :name = "Bob": name属性が正確に'Bob'であるメッセージを照合します。
  • :name != "Bob": name属性が'Bob'でないメッセージと一致します。
  • hasPrefix(:name, "Bo"): name属性が'Bo'で始まるメッセージと一致します。
  • hasSuffix(:name, "ob"): name属性が'ob'で終わるメッセージと一致します。
  • NOT hasPrefix(:name, "Bo"): name属性が'Bo'で始まらないメッセージと一致します。

数値フィルタ

数値フィルタを使用して、数値属性の値に基づいてメッセージを照合します。

いくつかの例を示します。

  • :age = 40: age属性が40のメッセージと一致します。
  • :age != 40: age属性が40でないメッセージと一致します。
  • :age > 40: age属性が40より大きいメッセージと一致します。
  • :age >= 40: age属性が40以上のメッセージと一致します。
  • :age < 40: age属性が40より小さいメッセージと一致します。
  • :age <= 40: age属性が40以下のメッセージと一致します。

論理フィルタ

論理演算子を使用してルールを組み合せ、より柔軟なフィルタを作成します。サポートされている演算子は、AND、ORおよびNOTです。
ノート

演算子の優先順位は、カッコ( )が最も優先され、次にNOT、AND、ORが優先されます。

いくつかの例を示します。

  • :name = "Bob" AND :age = 40: name属性が「Bob」で、ageが40であるメッセージを照合します。
  • :name = "Bob" OR :age = 40: name属性が「Bob」またはageが40であるメッセージと一致します。
  • :name = "Bob" AND NOT :age: name属性が'Bob'で、age属性がないメッセージと一致します。

複雑なフィルタ

複数のフィルタをカッコおよび複数の論理演算子と組み合せることで、より複雑なロジックを使用します。
ノート

演算子の優先順位は、カッコ( )が最も優先され、次にNOT、AND、ORが優先されます。

次はその例です。

  • :name = "Bob" AND NOT (:age > 40 OR :location = "Chicago"): name属性が"Bob"で、ageが40を超えていないか、locationが'Chicago'でないメッセージを照合します。

IAMポリシー

ファンアウトおよびコンシューマ・グループの操作に必要なIAMポリシーを確認します。

ベストプラクティス

  • 小さいフィルタから開始して、メッセージ配信が期待どおりに機能していることを確認します。複雑なフィルタ・ロジックをゆっくり追加し、移動中にテストします。
  • OCIモニタリングで削除されたメッセージ・メトリックを監視します。これにより、一致するフィルタがないため、削除されたメッセージを捕捉できます。
  • すべてのプロデューサからのメッセージ属性に一貫したネーミングを使用します。これにより、フィルタの記述と保守がより簡単かつ信頼性の高いものになります。
  • 属性キーが[文字またはアンダースコア(_)で始まる]ルールに従っていない場合は、文字、数字、ハイフン(-)またはアンダースコア(_)のみを含めて、フィルタ式に引用符を追加します。