再試行イベント

イベントが不承認となる理由は複数あります。たとえば、イベント レシーバー サービスが停止により一時的に利用できなくなる、サービスがイベントの処理中にエラーを検出する、サービス リソースが枯渇するなどの可能性があります。このような一時的なエラーは再試行できます。

イベントがイベント受信者に配信されないこともあります。たとえば、イベントが構成された想定のスキーマと一致しない場合や、イベント メッセージが最終的な宛先にルーティングされる前にイベントのメディエーションが失敗する場合があります。このような場合、永続的なエラーが発生します。

一時的なエラー

Eventarc Advanced には、一時的なエラーを処理する機能が用意されています。これらの一時的なエラーは再試行できます。次のエラーコードが含まれます。

• HTTP 408 Request Timeout
• HTTP 409 Conflict
• HTTP 429 Too Many Requests
• HTTP 500 Internal Server Error
• HTTP 502 Bad Gateway
• HTTP 503 Service Unavailable
• HTTP 504 Gateway Time-out

永続的なエラー

一時的なエラーとは対照的に、永続的なエラーには次のものがあります。

• 構成された再試行回数が上限に達したときに発生するエラー
• イベントが宛先にルーティングされる前に失敗したときに発生するエラー
• 再試行できないと見なされるエラーコードを返すエラー（一時的なエラーとしてリストされているエラーコード以外など）

永続的なエラーを手動で特定して適切に処理できます。

一時的なエラーを再試行する

Eventarc Advanced は、再試行可能なエラーを処理するために指数バックオフ遅延を使用します。デフォルトの再試行ポリシーは 1 秒の遅延から始まり、試行が失敗するたびに遅延が 2 倍になります（最大 60 秒、5 回の試行）。

デフォルトの再試行ポリシーは、 Google Cloud コンソールまたは gcloud beta eventarc pipelines update コマンドを使用して変更できます。

2 のデフォルトのバックオフ係数は変更できません。

gcloud beta eventarc pipelines update PIPELINE_NAME \
    --min-retry-delay=MIN_DELAY \
    --max-retry-delay=MAX_DELAY \
    --max-retry-attempts=MAX_ATTEMPTS

gcloud beta eventarc pipelines update my-pipeline \
    --min-retry-delay=4 \
    --max-retry-delay=4 \
    --max-retry-attempts=5

メッセージをアーカイブして永続的なエラーを処理する

メッセージを受信すると、BigQuery テーブルにメッセージを書き込むことができます。これにより、永続的なエラーを手動で特定し、適切に処理できます。

以下では、イベント メッセージのアーカイブ、永続的なエラーの特定、影響を受けるイベントの再試行に必要な手順の概要について説明します。

1. バスを作成します。バスを適切に構成します（Google ソースからイベントを公開するなど）。
2. Pub/Sub トピックを作成します。この Pub/Sub トピックは、パイプラインのターゲット宛先になります。
3. Pub/Sub トピックの BigQuery サブスクリプションを作成します。BigQuery サブスクリプションは、メッセージの受信時に既存の BigQuery テーブルにメッセージを書き込むエクスポート サブスクリプションの一種です。または、BigQuery サブスクリプションの作成時にテーブルを作成することもできます。

4. バス（--cel-match="true" を使用）で受信したすべてのメッセージを Pub/Sub トピックに転送するパイプラインと登録を作成します。パイプラインの再試行ポリシーを構成します。

   たとえば、次のコマンドはパイプラインと登録を作成します。

   gcloud beta eventarc pipelines create my-archive-pipeline \
       --destinations=pubsub_topic='my-archive-topic',network_attachment='my-network-attachment' \
       --min-retry-delay=1 \
       --max-retry-delay=20 \
       --max-retry-attempts=6 \
       --location=us-central1
   

   gcloud beta eventarc enrollments create my-archive-enrollment \
       --cel-match="true" \
       --destination-pipeline=my-archive-pipeline \
       --message-bus=my-message-bus \
       --message-bus-project=my-google-cloud-project \
       --location=us-central1
   

5. 別の BigQuery データセットにパイプラインログを転送します。

   これで、Eventarc Advanced バスで受信したすべてのメッセージを保存する BigQuery データセットと、パイプライン ログを保存する BigQuery データセットの 2 つの BigQuery データセットが作成されます。

6. 失敗したメッセージを特定するには、message_uid フィールドで両方の BigQuery データセットを結合するクエリ ステートメントを使用します。

7. 失敗したメッセージを特定したら、Eventarc Publishing API を使用して、それらのメッセージをバスに再度パブリッシュできます。たとえば、BigQuery からメッセージを読み取り、Eventarc Advanced バスに直接パブリッシュする Cloud Run サービスまたはジョブをデプロイできます。

イベント ハンドラをべき等にする

再試行可能なイベント ハンドラは、次の一般的なガイドラインに沿ってべき等にする必要があります。

• 多くの外部 API では、べき等のキーをパラメータとして指定できます。このような API を使用している場合は、イベントのソースと ID をべき等のキーとして使用します。（プロデューサーは、ソースと ID がイベントごとに一意であることを確認する必要があります）。
• また、CloudEvents 属性 xgooglemessageuid を使用して、べき等性を提供することもできます。この属性の値は、Eventarc Advanced メッセージの message_uid フィールドと同じです。イベントの公開アクションを一意に識別します。たとえば、同じイベントがバスに 2 回パブリッシュされる場合、イベント ハンドラに送信されるときに、各イベントに異なる xgooglemessageuid 値が設定されます。
• べき等では再試行が安全に行われるため、at-least-once 配信でうまく機能します。したがって、信頼性の高いコードを書くための一般的なベスト プラクティスは、べき等と再試行を組み合わせることです。
• コードが内部でべき等であることを確認します。次に例を示します。
  • 結果が変わらずにミューテーションが 2 回以上起こることを確認する。
  • 状態を変更する前にトランザクション内のデータベース状態を照会する。
  • すべての副作用がそれ自体べき等であることを確認する。
• コードとは関係なく、トランザクション チェックをサービスの外側に置きます。たとえば、指定されたイベント ID がすでに処理されたことを記録している場所の状態を保持します。
• 重複した呼び出しを帯域外で処理するたとえば、重複した呼び出しの後にクリーンアップする別のクリーンアップ プロセスを用意します。

次のステップ

• 問題のトラブルシューティングを行う
• 監査ログの表示