재시도 이벤트

고급

미리보기 — Eventarc Advanced

이 기능에는 서비스별 약관의 일반 서비스 약관 섹션에 있는 'GA 이전 제공 서비스 약관'이 적용됩니다. GA 이전 기능은 '있는 그대로' 제공되며 지원이 제한될 수 있습니다. 자세한 내용은 출시 단계 설명을 참조하세요.

이벤트는 여러 가지 이유로 거부될 수 있습니다. 예를 들어 서비스 중단으로 인해 이벤트 수신기 서비스를 일시적으로 사용할 수 없거나 이벤트를 처리할 때 서비스에 오류가 발생하거나 서비스 리소스가 고갈될 수 있습니다. 이와 같은 일시적인 오류는 재시도할 수 있습니다.

이벤트가 이벤트 수신자에게 전송되지 않을 수도 있습니다. 예를 들어 이벤트가 구성된 예상 스키마와 일치하지 않거나 이벤트 메시지를 최종 대상에 라우트하기 전에 이벤트 미디에이션이 실패할 수 있습니다. 이 경우 지속적인 오류가 발생합니다.

일시적인 오류

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초 지연으로 시작하며, 실패할 때마다 지연 시간이 두 배로 늘어납니다 (최대 60초 및 5회 시도까지).

Google Cloud 콘솔 또는 gcloud beta eventarc pipelines update 명령어를 사용하여 기본 재시도 정책을 변경할 수 있습니다.

기본 백오프 계수 2는 변경할 수 없습니다.

콘솔

1. Google Cloud 콘솔에서 Eventarc > 파이프라인 페이지로 이동합니다.

   파이프라인으로 이동

2. 파이프라인 이름을 클릭합니다.

3. 파이프라인 세부정보 페이지에서 수정을 클릭합니다.

4. 파이프라인 수정 페이지의 재시도 정책 섹션에서 다음 필드를 수정합니다.

   • 최대 시도 횟수: 재시도 횟수입니다. 기본값은 5회입니다. 임의의 양의 실수여야 합니다. 1로 설정하면 재시도 정책이 적용되지 않으며 메시지 전송이 한 번만 시도됩니다.
   • 최소 지연 시간 (초): 초 단위의 초기 지연 시간입니다. 기본값은 1초입니다. 1~600의 값이어야 합니다.
   • Max delay (seconds): 최대 지연 시간(초)입니다. 기본값은 60초입니다. 1~600의 값이어야 합니다.

   최소 지연 시간과 최대 지연 시간을 동일한 값으로 설정하여 선형 백오프를 구성할 수 있습니다.

5. 저장을 클릭합니다.

gcloud

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

다음을 바꿉니다.

• PIPELINE_NAME: 파이프라인의 ID 또는 정규화된 식별자입니다.
• MIN_DELAY: 초 단위의 초기 지연 시간입니다. 기본값은 1초입니다. 1~600의 값이어야 합니다.
• MAX_DELAY: 최대 지연 시간(초)입니다. 기본값은 60초입니다. 1~600의 값이어야 합니다.
• MAX_ATTEMPTS: 재시도 횟수입니다. 기본값은 5번입니다. 임의의 양의 실수여야 합니다. 1로 설정하면 재시도 정책이 적용되지 않으며 메시지 전송이 한 번만 시도됩니다.

다음 예에서는 최소 지연과 최대 지연을 동일한 값으로 설정하여 선형 백오프를 구성합니다.

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 고급 버스에서 수신한 모든 메시지를 저장하는 BigQuery 데이터 세트와 파이프라인 로그를 저장하는 BigQuery 데이터 세트가 각각 하나씩 생성됩니다.

6. 실패한 메시지를 식별하려면 message_uid 필드에서 두 BigQuery 데이터 세트를 조인하는 쿼리 문을 사용하여 조인합니다.

7. 실패한 메시지를 식별한 후 Eventarc Publishing API를 사용하여 메시지를 버스에 다시 게시할 수 있습니다. 예를 들어 Cloud Run 서비스 또는 작업을 배포하여 BigQuery에서 메시지를 읽고 Eventarc 고급 버스에 직접 게시할 수 있습니다.

이벤트 핸들러 멱등성 만들기

재시도할 수 있는 이벤트 핸들러는 다음 일반 가이드라인을 사용하여 멱등성을 가져야 합니다.

• 다양한 외부 API를 사용하면 매개변수로 멱등 키를 제공할 수 있습니다. 이러한 API를 사용한다면 이벤트 소스와 ID를 멱등 키로 사용해야 합니다. (제작자는 source + id가 고유한 이벤트마다 고유해야 합니다.)
• 또한 CloudEvents 속성 xgooglemessageuid를 사용하여 무관성을 제공할 수 있습니다. 이 속성의 값은 Eventarc 고급 메시지의 message_uid 필드와 동일합니다. 이벤트 게시 작업을 고유하게 식별합니다. 예를 들어 동일한 이벤트가 버스에 두 번 게시되면 각 이벤트가 이벤트 핸들러로 전송될 때 서로 다른 xgooglemessageuid 값을 갖게 됩니다.
• 멱등성이 있으면 재시도해도 안전하므로 최소 1회 전송 시 잘 작동합니다. 따라서 안정적인 코드를 작성하기 위한 일반적인 권장사항은 재시도와 멱등성을 결합하는 것입니다.
• 코드에 내부적으로 멱등성이 있어야 합니다. 예를 들면 다음과 같습니다.
  • 결과에 변화 없이 변형이 2번 이상 발생할 수 있는지 확인합니다.
  • 상태가 변형되기 전에 트랜잭션에서 데이터베이스 상태를 쿼리합니다.
  • 모든 부가적인 결과에 자체적으로 멱등성이 있는지 확인합니다.
• 코드에 관계없이 서비스 외부에서 트랜잭션 검사를 시행합니다. 예를 들어 특정 이벤트 ID가 이미 처리되었음을 어딘가에 기록하는 상태를 유지합니다.
• 중복 호출을 대역 외로 처리합니다. 예를 들어 중복 호출 후 삭제하는 별도의 삭제 프로세스를 둡니다.

다음 단계

• 문제 해결
• 감사 로그 보기