クイズ：バッチの再試行と処理の重複

completions: 1인 Job이 Complete이고 원장에는 같은 주문의 배송이 두 건 있습니다. 가장 정확한 해석은?

• 실행 완료 조건과 외부 업무의 처리 횟수는 별도로 확인해야 한다
• Complete 조건이 배송 한 건을 보증하므로 원장 집계부터 제외해야 한다
• 성공한 Pod가 하나이면 실패 Pod의 요청은 외부에서도 취소된다
• parallelism을 1로 설정했다면 같은 주문의 중복 저장은 발생할 수 없다

restartPolicy: Never인데 같은 Job 소유의 Pod A는 Failed, Pod B는 Succeeded이고 두 컨테이너의 restartCount는 0입니다. 무엇을 구분한 관측인가요?

• 컨테이너가 같은 Pod 안에서 재시작해도 restartCount는 변하지 않는다
• Pod 내부 재시작 없이 Job 컨트롤러가 대체 Pod를 만들 수 있다
• Never 설정이 있었으므로 두 Pod는 서로 다른 Job에 속해야 한다
• 새 Pod가 생겼으므로 실패한 Pod의 외부 요청은 존재하지 않는다

backoffLimit: 0인 Job이 저장 직후 실패했고 합성 배송은 한 건 남았습니다. 운영자가 새 Job으로 재실행하기 전에 할 일은?

• 실패한 Job이므로 부작용은 없다고 보고 새 업무 키로 다시 실행한다
• 재시도 제한을 더 크게 바꾸면 기존 배송이 자동 취소되는지 기다린다
• 안정적인 업무 키로 기존 처리 결과를 확인하고 재실행 계약을 적용한다
• 실패 Pod를 삭제하면 원장도 초기화되므로 먼저 Pod부터 지운다

같은 업무 키의 요청 두 개가 동시에 도착할 때 합성 원장이 배송을 한 번만 만들도록 하는 핵심 계약은?

• 두 클라이언트가 각자 새 UUID를 만든 뒤 중복 조회를 생략한다
• 각 Pod의 메모리에 처리 완료를 적고 다른 Pod의 상태는 보지 않는다
• 조회와 삽입을 나눈 뒤 둘 다 없다고 판단하면 각각 행을 추가한다
• 유일한 업무 키와 하나의 쓰기 트랜잭션으로 조회·삽입을 처리한다

다른 이름의 Job으로 같은 업무를 재실행해도 중복 배송을 만들지 않으려면 어떤 값을 유지해야 하나요?

• 논리적인 업무 범위와 주문을 식별하는 안정적인 키
• 새 Job이 생성될 때 API 서버가 부여한 고유 UID
• 각 실행 프로세스가 시작할 때 새로 만든 무작위 키
• 요청을 보내는 Pod의 새 이름과 컨테이너 시작 시각

안전한 모드에서 Job 재시도와 별도 Job 재실행까지 요청은 세 번, 배송은 한 건입니다. 보존해야 할 관측 자료는?

• 배송이 한 건이므로 첫 요청만 남기고 중복 요청 이력은 삭제한다
• 세 요청의 실행 식별자와 같은 배송 번호를 가리키는 연결을 남긴다
• 최종 Job의 Complete 조건만 남기고 원장과 실패 Pod는 제외한다
• 요청 횟수와 배송 횟수가 같아지도록 두 번째 배송 행을 보충한다

Job이 activeDeadlineSeconds를 넘겨 DeadlineExceeded로 실패했습니다. 프로그램은 종료 전에 배송을 저장했습니다. 어떤 결론이 맞나요?

• 시간 제한이 끝나면 그 Job의 외부 저장도 같은 시각에 취소된다
• backoffLimit이 남아 있으면 시간 제한 이후에도 계속 재시도한다
• 실행 종료와 업무 취소는 다르므로 남은 배송 결과를 따로 확인한다
• Failed 조건이 있으므로 원장에 남은 배송은 성공으로 집계할 수 없다

CronJob에 concurrencyPolicy: Forbid를 지정했습니다. 멱등 처리에 대한 올바른 설명은?

• 같은 주문을 처리하는 모든 수동 Job도 서로 겹치지 않게 막는다
• 다른 CronJob에서 시작한 같은 업무도 하나의 실행으로 자동 합친다
• 실패 후 외부 원장에 저장된 중복 결과는 CronJob이 자동 제거한다
• 같은 CronJob의 실행 겹침 제한과 업무 중복 처리 계약은 별개다