Client·Temporal Service·Worker는 서로 다른 역할입니다. 그림에서 코드 실행과 기록 보관 위치를 구분합니다.
↔ 드래그하여 이동
원리와 활용
Client의 시작 요청이 Task Queue를 거쳐 Worker의 코드 실행과 Event History 기록으로 이어지는 과정을 살펴봅니다.
Workflow는 실행 순서를 정의하고 Activity는 외부 작업을 수행합니다. 둘의 코드는 Worker에서 실행합니다.
Temporal Service는 작업을 예약하고 Event History를 보관합니다. Worker가 Task Queue를 polling해 Workflow Task와 Activity Task를 처리합니다. 외부 API·DB 작업은 Activity에 두며 저장·예약 비용과 운영할 Worker가 필요합니다.
장시간 주문 처리나 여러 서비스 호출을 재시도·복구 가능한 실행으로 구성할 때 역할과 배치 경계를 확인합니다.
실패·재시도와 멱등성
예제는 같은 주문 키로 최대 세 번 시도합니다. 첫 대기는 1초이며 다음 대기는 2초로 늘어납니다.
↔ 드래그하여 이동
원리와 활용
Activity 재시도와 응답 유실을 비교하고, 같은 요청의 외부 효과를 중복시키지 않는 멱등 키를 확인합니다.
Activity는 다시 실행될 수 있습니다. 외부 작업의 중복 방지는 호출 대상의 멱등 처리와 함께 설계합니다.
예제 정책은 최대 3회, 처음 1초·이후 2배 대기입니다. 첫 요청은 실패하고 두 번째는 처리 뒤 응답이 유실됩니다. 외부 API가 같은 키의 저장 결과를 돌려줘 세 번째 요청의 중복 효과를 막습니다. 실제 재시도 가능 여부는 오류 유형·timeout·정책에 달려 있습니다.
결제·메일·외부 쓰기 작업에서 처리 성공과 결과 보고 사이의 장애를 다룰 때 사용합니다. 재시도가 외부 효과의 정확히 한 번 실행을 보장하지는 않습니다.
Event History와 Replay
결제 Activity 완료가 History에 기록된 예제입니다. 외부 결제 작업은 이미 한 번 수행됐습니다.
↔ 드래그하여 이동
원리와 활용
Worker가 중지된 뒤 기록된 결과로 상태를 복원하고, 아직 실행하지 않은 작업부터 이어가는 과정을 살펴봅니다.
Replay는 Workflow 코드를 다시 실행하며 Event History와 맞춰 상태를 복원합니다. 완료가 기록된 Activity는 결과를 재사용합니다.
예제는 결제 완료가 기록된 뒤 Worker가 중지됩니다. 새 Worker는 같은 History에 맞는 명령을 생성해 결제 결과를 복원하고 배송 Activity부터 진행합니다. Workflow 코드의 결정성과 호환되는 변경이 필요하며 긴 History는 복원 비용을 늘릴 수 있습니다.
Worker 재시작·교체 중에도 장기 실행을 이어가거나 Workflow 코드 변경의 호환성을 판단할 때 사용합니다. 완료가 기록되지 않은 외부 작업은 별도 재시도·멱등 설계가 필요합니다.
Timer와 Signal
예제 Workflow는 5분 Timer 뒤 외부 승인을 기다립니다. 시간과 입력의 대기를 서로 구분합니다.
↔ 드래그하여 이동
원리와 활용
Worker가 없는 동안에도 유지되는 Timer와 외부 Signal이 Workflow를 다시 진행시키는 과정을 살펴봅니다.
Timer와 Signal은 Workflow의 대기를 History의 이벤트로 이어갑니다. 대기 중인 Workflow마다 Worker 스레드를 붙잡지 않습니다.
예제는 5분 Timer 뒤 외부 승인을 기다립니다. Service가 동작 중이면 Worker가 없어도 Timer 만료와 Signal을 기록할 수 있고, 사용 가능한 Worker가 다음 Workflow Task를 처리합니다. 실제 재개 시점은 Service·Worker 가용성과 스케줄링에 달려 있습니다.
장기 승인·후속 알림처럼 외부 입력이나 시간을 기다리는 절차에 사용합니다. SDK Timer는 초 미만의 정밀 실행 예약이나 무조건 즉시 재개를 보장하는 장치가 아닙니다.