Temporal
분산 애플리케이션을 위한 오픈소스 Workflow Orchestration 플랫폼으로, 핵심은 내구성 있는 실행(Durable Execution) 이다. 즉 서비스에 문제가 생기거나 네트워크가 끊겨도, 애플리케이션의 작업 흐름(워크플로우)이 상태를 잃지 않고 끝까지 완료되도록 보장한다.
오케스트레이션이란? 데이터 이동·변환·검증·전달과 같은 작업을 올바른 순서로, 적시에, 대규모로 실행되도록 구성하고 관리하는 프로세스.
1. 개요
1.1 사용처
- 결제 처리
- 주문 관리
- 데이터 파이프라인
- 인프라 프로비저닝
1.2 필요한 이유
분산 시스템의 복잡성
- 네트워크 실패 및 타임아웃 발생
- 서비스 간 부분적 실패(Partial Failure)
- 신뢰할 수 없는 원격 프로시저 호출
전통적 접근의 한계
- 복잡한 재시도 로직을 직접 구현
- DB를 이용한 수동 상태 추적
- 보상 트랜잭션 관리의 어려움
Temporal의 해결책
- 상태 자동 저장
- 투명한 재시도 메커니즘 제공
- 워크플로우의 지속성 보장
2. 핵심 개념
2.1 Workflow (오케스트레이터)
비즈니스 로직을 정의하는 내구성 있는 상태 함수.
특징: 결정성(Determinism)
- 동일 입력 시 항상 동일 출력 보장
- 상태가 지속되며 장애 시 복구 가능
- 직접적인 외부 API 호출 금지
2.2 Activity (작업 실행기)
실제 작업을 수행하는 최소 실행 단위.
특징: 비결정성 허용
- 외부 시스템 호출(HTTP, DB)
- 랜덤 값 생성, 시간 조회 가능
- 재시도 정책(Retry Policy) 적용 대상
Workflow가 설계도라면, Activity는 망치와 톱처럼 실제로 일을 하는 도구다. Activity는 Workflow의 지휘에 따라 작업을 수행하는 '실행자' 역할을 한다.
3. 아키텍처
3.1 서버 구성 요소
| 서비스 | 역할 | 세부 |
|---|
| Frontend Service | 요청을 받는다 | gRPC API 엔드포인트 제공 / 인증·인가 및 Rate Limiting 수행 |
| History Service | 상태를 기록한다 | Workflow 실행 상태 및 뮤테이션 관리 / Event Sourcing 기반 데이터 영속화 |
| Matching Service | 작업을 분배한다 | Task Queue 관리 및 폴링 매칭 / 가용 Worker에 Task 분배·할당 |
| Worker Service | 시스템을 관리한다 | 아카이빙·복제 등 내부 작업 실행 / 시스템 워크플로우 처리 및 스케줄링 |
3.2 네임스페이스(Namespace)
- 테넌시(Tenancy) 및 리소스의 논리적 분리
- 환경 구분(개발·스테이징·프로덕션)
- 보안 및 접근 제어(RBAC) 단위
3.3 Task Queue
- 워크플로우/액티비티 전달 통로
- 특정 Worker 그룹으로 태스크 할당
- 부하 분산 및 우선순위 제어
3.4 Worker Grouping
종류
- Workflow Task Queue
- Activity Task Queue
특징
- 특정 태스크 큐를 폴링하는 전용 워커 그룹 구성
- 논리적 큐를 통해 유연한 확장성 및 리소스 격리 구현
4. 내구성과 재시도 메커니즘
장애 대응력이 뛰어난 분산 시스템 구축의 핵심.
| 메커니즘 | 목적 | 내용 |
|---|
| 이벤트 소싱 | 상태를 기록 | 모든 상태 변경을 이벤트로 기록 / 전체 실행 이력 보존 / 신뢰할 수 있는 단일 진실 공급원(SSOT) |
| 자동 재시도 정책 | 일시적 오류 극복 | Activity 실패 시 지수 백오프 적용 / 복구 가능한 오류 자동 대응 / 커스텀 재시도 간격·횟수 설정 |
| 워크플로우 재개 | 인프라 장애를 견딤 | 서버 재시작 시 상태 자동 복원 / 로컬 변수 및 실행 지점 유지 / 타임아웃 시 타 Worker로 이전 |
| Replay 메커니즘 | 디버깅·테스트 보장 | 히스토리 재생을 통한 상태 재구성 / 결정론적 실행 보장 / 복구 과정의 중복 연산 방지 |
5. 실행 흐름 (Workflow Execution Flow)
- 시작 요청 — 클라이언트가 Frontend API를 통해 워크플로우를 트리거한다.
- 이벤트 기록 — 모든 상태 변화는 History Service에 영속적으로 기록되어 장애 복구에 활용된다.
- Task 할당 — Matching Service가 대기 중인 Worker에게 Task를 안전하게 분배한다.
- Activity 실행 — Worker가 Workflow Definition을 실행하며 필요한 Activity를 호출한다.
- 완료 및 반환 — 비동기 작업인 Activity가 완료되면 워크플로우는 상태를 업데이트하고 종료한다.
6. 모니터링과 가시성
- Temporal Web UI
- 워크플로우 상태 시각화
- 실시간 이벤트 히스토리 추적
- 실행 중인 작업 및 결과 확인
- 운영 메트릭 및 로깅
- Prometheus / Grafana 연동
- SDK 수준의 구조화된 로깅
- 시스템 성능 및 처리량 지표
- 고급 검색 및 필터링 (Visibility API)
7. 실제 사용 사례
- 결제 처리 — 여러 단계를 거치는 결제 워크플로우에서 중간에 실패하면, 진행된 모든 작업을 정확히 되돌리는 보상 트랜잭션이 필수다. Temporal은 이 복잡한 과정을 안정적으로 오케스트레이션한다.
- 주문 관리 — '주문 생성 → 재고 확인 → 배송 추적 → 완료'까지, 하나의 비즈니스 트랜잭션이 며칠에 걸쳐 진행될 수 있다. Temporal은 이런 장기 실행 프로세스의 전체 생명주기 관리에 탁월하다.
- 데이터 파이프라인 — 대규모 ETL/배치 처리는 시간이 오래 걸리고 실패하기 쉽다. Temporal은 이를 안정적으로 스케줄링하고, 장애 시 자동 재시도하여 데이터 무결성을 보장한다.
- 사용자 가입 플로우 — 이메일 인증 → KYC 신원 확인 → 계정 활성화까지 여러 비동기 단계가 순차 진행되어야 한다. Temporal은 이런 비동기식 계정 활성화 프로세스를 끊김 없이 처리한다.
8. 비슷한 솔루션 비교
| 제품 | Long-running | 코드 기반 | 클라우드 종속 | 난이도 |
|---|
| Temporal | 매우 강함 | 매우 강함 | 없음 | 높음 |
| Cadence | 매우 강함 | 매우 강함 | 없음 | 높음 |
| Camunda | 강함 | 보통 | 없음 | 중 |
| Conductor | 강함 | 약함 | 없음 | 중 |
| Step Functions | 보통 | 약함 | AWS | 낮음 |
| Durable Functions | 보통 | 강함 | Azure | 낮음 |
| Airflow | 약함 | 강함 | 없음 | 중 |
| Argo | 약함 | 강함 | K8s | 중 |
Best Practices: https://docs.temporal.io/best-practices/worker
9. 용어
- Saga 패턴: 여러 서비스에 걸친 긴 트랜잭션을 관리하는 방식. 하나가 실패하면 이미 성공한 작업들을 취소하는 보상 작업을 실행한다.
- Tenancy(테넌시): 여러 사용자(테넌트)가 물리적·논리적 서버나 애플리케이션 리소스를 공유하는 방식 또는 그 환경.
- RBAC(Role-Based Access Control): 사용자의 '역할'을 기반으로 시스템·네트워크·데이터에 대한 접근 권한을 부여하는 보안 모델.
- KYC(Know Your Customer): 금융 기관이나 가상자산 사업자가 거래 전 고객의 신원을 확인·검증하는 법적 의무 절차. 자금세탁·사기·테러 자금 지원 등 금융 범죄 예방이 목적이다.
10. Q&A
Q. Namespace와 Task Queue의 용도를 '멀티 테넌시'와 '로드 밸런싱' 관점에서 설명하면?
- Namespace (멀티 테넌시): 하나의 Temporal 클러스터 내에서 여러 팀이나 환경(개발·스테이징·프로덕션)을 논리적으로 격리하는 단위. 각 네임스페이스는 독립적인 구성(유지 기간, 아카이빙 정책, 접근 제어)을 가질 수 있어 보안 경계와 리소스 격리를 제공한다.
- Task Queue (로드 밸런싱): Worker가 작업을 수신하기 위해 폴링하는 경량 동적 큐. 동일 Task Queue에 여러 Worker가 연결되면 작업이 자동 분산된다. 또한 특정 버전·특화 로직을 가진 Worker가 특정 큐를 수신하게 하여 마이크로서비스 간 느슨한 결합과 확장성을 구현한다.
Q. Activity에서 여러 개의 API를 호출하는 경우 중간 상태를 저장하나요?
- 저장하지 않는다. Activity는 원자적(Atomic) 단위로 취급되어 중간 상태가 History에 기록되지 않는다.
- 여러 API를 한 Activity에 섞는 게 불안하다면, 각 호출을 별도의 Activity로 쪼갤 수 있다. 순차 또는 병렬 실행이 모두 가능하다.
Q. 상태 저장은 DB 저장소가 필수인가요?
- 필수다. History Service는 단순 로그가 아니라 워크플로우를 재현하는 설계도이므로 무결성이 보장되는 저장소가 필요하다.
- Temporal에는 Retention Period 설정이 있어, 완료된 워크플로우 데이터는 지정 기간이 지나면 자동 삭제된다.