配信失敗の処理¶

イベントの配信に失敗した場合に適用されるKnative Eventingコンポーネントのイベント配信パラメーターを設定できます。

サブスクリプションのイベント配信の構成¶

次の例に示すように、Subscriptionオブジェクトにdelivery specを追加することで、各サブスクリプションのイベント配信方法を構成できます。

apiVersion: messaging.knative.dev/v1
kind: Subscription
metadata:
  name: example-subscription
  namespace: example-namespace
spec:
  delivery:
    deadLetterSink:
      ref:
        apiVersion: serving.knative.dev/v1
        kind: Service
        name: example-sink
    backoffDelay: <duration>
    backoffPolicy: <policy-type>
    retry: <integer>

解説

deadLetterSink specには、デッドレターシンクの使用を有効にするための構成設定が含まれています。これは、サブスクライバーに配信できないイベントに対して何が起こるかをサブスクリプションに通知します。これが構成されている場合、配信に失敗したイベントはデッドレターシンクの宛先に送信されます。宛先には、KnativeサービスまたはURIを使用できます。この例では、宛先はexample-sinkという名前のServiceオブジェクト、つまりKnativeサービスです。
backoffDelay配信パラメーターは、失敗後にイベント配信の再試行が試行されるまでの時間遅延を指定します。 backoffDelayパラメーターの期間は、ISO 8601形式で指定します。たとえば、PT1Sは1秒の遅延を指定します。
backoffPolicy配信パラメーターは、再試行バックオフポリシーを指定するために使用できます。ポリシーは、linearまたはexponentialのいずれかで指定できます。 linearバックオフポリシーを使用する場合、バックオフ遅延は再試行間で指定された時間間隔です。 exponentialバックオフポリシーを使用する場合、バックオフ遅延はbackoffDelay*2^<numberOfRetries>に等しくなります。
retryは、イベントがデッドレターシンクに送信されるまでにイベント配信が再試行される回数を指定します。

Brokerのイベント配信の構成¶

次の例に示すように、delivery specを追加することで、各Brokerのイベント配信方法を構成できます。

apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
  name: with-dead-letter-sink
spec:
  delivery:
    deadLetterSink:
      ref:
        apiVersion: serving.knative.dev/v1
        kind: Service
        name: example-sink
    backoffDelay: <duration>
    backoffPolicy: <policy-type>
    retry: <integer>

解説

deadLetterSink specには、デッドレターシンクの使用を有効にするための構成設定が含まれています。これは、サブスクライバーに配信できないイベントに対して何が起こるかをサブスクリプションに通知します。これが構成されている場合、配信に失敗したイベントはデッドレターシンクの宛先に送信されます。宛先には、Knativeサービス、Kubernetesサービス、URIなど、Knative Eventingシンク契約に準拠する任意のアドレス指定可能なオブジェクトを使用できます。この例では、宛先はexample-sinkという名前のServiceオブジェクト、つまりKnativeサービスです。
backoffDelay配信パラメーターは、失敗後にイベント配信の再試行が試行されるまでの時間遅延を指定します。 backoffDelayパラメーターの期間は、ISO 8601形式で指定します。たとえば、PT1Sは1秒の遅延を指定します。
backoffPolicy配信パラメーターは、再試行バックオフポリシーを指定するために使用できます。ポリシーは、linearまたはexponentialのいずれかで指定できます。 linearバックオフポリシーを使用する場合、バックオフ遅延は再試行間で指定された時間間隔です。これは、バックオフ遅延が再試行ごとに指定された間隔で増加する線形増加遅延です。 exponentialバックオフポリシーを使用する場合、バックオフ遅延は再試行ごとに指定された間隔の乗数で増加します。
retryは、イベントがデッドレターシンクに送信されるまでにイベント配信が再試行される回数を指定します。最初の配信試行は再試行回数に含まれないため、配信試行の合計回数はretry値+1に等しくなります。

Brokerのサポート¶

次の表に、各Broker実装タイプでサポートされている配信パラメーターをまとめます。

Brokerクラス	サポートされている配信パラメーター
googlecloud	`deadLetterSink`、`retry`、`backoffPolicy`、`backoffDelay`
Kafka	`deadLetterSink`、`retry`、`backoffPolicy`、`backoffDelay`
MTChannelBasedBroker	基盤となるチャネルに依存
RabbitMQBroker	`deadLetterSink`、`retry`、`backoffPolicy`、`backoffDelay`

注意

deadLetterSinkは、GCP Pub/SubトピックのURIである必要があります。 googlecloud Brokerは、exponentialバックオフポリシーのみをサポートします。

チャネルのイベント配信の構成¶

失敗したイベントは、使用中の特定のチャネル実装に応じて、deadLetterSinkに転送される前に拡張属性で拡張される場合があります。これらの拡張属性は次のとおりです。

knativeerrordest
- タイプ: 文字列
- 説明: 失敗したイベントが送信された元の宛先URL。これは、失敗したイベントが発生した操作に基づいて、delivery URLまたはreply URLのいずれかになります。
- 制約: すべてのHTTPリクエストには宛先URLがあるため、常に存在します。
- 例
  - 「http://myservice.mynamespace.svc.cluster.local:3000/mypath」
  - ...任意のdeadLetterSink URL...
knativeerrorcode
- タイプ: 整数
- 説明: 最後のイベントディスパッチ試行からのHTTPレスポンスStatusCode。
- 制約: すべてのHTTPレスポンスにはStatusCodeが含まれているため、常に存在します。
- 例
  - "500"
  - ...任意のHTTPステータスコード...
knativeerrordata
- タイプ: 文字列
- 説明: 最後のイベントディスパッチ試行からのHTTPレスポンスBody。
- 制約: HTTPレスポンスBodyが空の場合は空になり、長さが過剰な場合は切り捨てられる場合があります。
- 例
  - 「内部サーバーエラー: イベントの処理に失敗しました。」
  - 「{"key": "value"}」
  - ...任意のHTTPレスポンスBody...

チャネルのサポート¶

次の表に、各チャネル実装でサポートされている配信パラメーターをまとめます。

チャネルタイプ	サポートされている配信パラメーター
GCP PubSub	なし
インメモリ	`deadLetterSink`、`retry`、`backoffPolicy`、`backoffDelay`
Kafka	`deadLetterSink`、`retry`、`backoffPolicy`、`backoffDelay`
Natss	なし