5.6. イベント配信
イベントがイベントシンクに配信されなかった場合に適用されるイベント配信パラメーターを設定できます。デッドレターシンクを含むイベント配信パラメーターを設定すると、イベントシンクへの配信に失敗したすべてのイベントが再試行されるようになります。それ以外の場合、未配信のイベントは破棄されます。
5.6.1. チャネルとブローカーのイベント配信動作パターン
さまざまなチャネルとブローカーのタイプには、イベント配信のために従う独自の動作パターンがあります。
5.6.1.1. Knative Kafka のチャネルとブローカー
イベントが Kafka チャネルまたはブローカーレシーバーに正常に配信される場合、受信側は 202 ステータスコードで応答します。つまり、このイベントは Kafka トピック内に安全に保存され、失われることはありません。
受信側がその他のステータスコードを返す場合は、イベントは安全に保存されず、ユーザーがこの問題を解決するために手順を実行する必要があります。
5.6.2. 設定可能なイベント配信パラメーター
以下のパラメーターはイベント配信用に設定できます。
- dead letter sink
-
deadLetterSink配信パラメーターを設定して、イベントが配信に失敗した場合にこれを指定されたイベントシンクに保存することができます。デッドレターシンクに格納されていない未配信のイベントは破棄されます。デッドレターシンクは、Knative サービス、Kubernetes サービス、または URI など、Knative Eventing シンクコントラクトに準拠する任意のアドレス指定可能なオブジェクトです。 - retries
-
retry配信パラメーターを整数値で設定することで、イベントが dead letter sink に送信される前に配信を再試行する必要のある最小回数を設定できます。 - back off delay
-
backoffDelay配信パラメーターを設定し、失敗後にイベント配信が再試行される前の遅延の時間を指定できます。backoffDelayパラメーターの期間は ISO 8601 形式を使用して指定されます。たとえば、PT1Sは 1 秒の遅延を指定します。 - back off policy
-
backoffPolicy配信パラメーターは再試行バックオフポリシーを指定するために使用できます。ポリシーはlinearまたはexponentialのいずれかとして指定できます。linearバックオフポリシーを使用する場合、バックオフ遅延はbackoffDelay * <numberOfRetries>に等しくなります。exponentialバックオフポリシーを使用する場合、バックオフ遅延はbackoffDelay*2^<numberOfRetries>と等しくなります。
5.6.3. イベント配信パラメーターの設定例
Broker、Trigger、Channel、および Subscription オブジェクトのイベント配信パラメーターを設定できます。ブローカーまたはチャネルのイベント配信パラメーターを設定すると、これらのパラメーターは、それらのオブジェクト用に作成されたトリガーまたはサブスクリプションに伝播されます。トリガーまたはサブスクリプションのイベント配信パラメーターを設定して、ブローカーまたはチャネルの設定をオーバーライドすることもできます。
Broker オブジェクトの例
apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
...
spec:
delivery:
deadLetterSink:
ref:
apiVersion: eventing.knative.dev/v1alpha1
kind: KafkaSink
name: <sink_name>
backoffDelay: <duration>
backoffPolicy: <policy_type>
retry: <integer>
...
Trigger オブジェクトの例
apiVersion: eventing.knative.dev/v1
kind: Trigger
metadata:
...
spec:
broker: <broker_name>
delivery:
deadLetterSink:
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: <sink_name>
backoffDelay: <duration>
backoffPolicy: <policy_type>
retry: <integer>
...
Channel オブジェクトの例
apiVersion: messaging.knative.dev/v1
kind: Channel
metadata:
...
spec:
delivery:
deadLetterSink:
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: <sink_name>
backoffDelay: <duration>
backoffPolicy: <policy_type>
retry: <integer>
...
Subscription オブジェクトの例
apiVersion: messaging.knative.dev/v1
kind: Subscription
metadata:
...
spec:
channel:
apiVersion: messaging.knative.dev/v1
kind: Channel
name: <channel_name>
delivery:
deadLetterSink:
ref:
apiVersion: serving.knative.dev/v1
kind: Service
name: <sink_name>
backoffDelay: <duration>
backoffPolicy: <policy_type>
retry: <integer>
...
5.6.4. トリガーのイベント配信順序の設定
Kafka ブローカーを使用している場合は、トリガーからイベントシンクへのイベントの配信順序を設定できます。
前提条件
- OpenShift Serverless Operator、Knative Eventing、および Knative Kafka が OpenShift Container Platform クラスターにインストールされている。
- Kafka ブローカーがクラスターで使用可能であり、Kafka ブローカーが作成されている。
- OpenShift Container Platform でアプリケーションおよび他のワークロードを作成するために、プロジェクトを作成しているか、適切なロールおよびパーミッションを持つプロジェクトにアクセスできる。
-
OpenShift (
oc) CLI がインストールされている。
手順
Triggerオブジェクトを作成または変更し、kafka.eventing.knative.dev/delivery.orderアノテーションを設定します。apiVersion: eventing.knative.dev/v1 kind: Trigger metadata: name: <trigger_name> annotations: kafka.eventing.knative.dev/delivery.order: ordered ...サポートされているコンシューマー配信保証は次のとおりです。
unordered- 順序付けられていないコンシューマーは、適切なオフセット管理を維持しながら、メッセージを順序付けずに配信するノンブロッキングコンシューマーです。
ordered順序付きコンシューマーは、CloudEvent サブスクライバーからの正常な応答を待ってから、パーティションの次のメッセージを配信する、パーティションごとのブロックコンシューマーです。
デフォルトの順序保証は
unorderedです。
Triggerオブジェクトを適用します。$ oc apply -f <filename>
