폭증하는 트래픽을 처리하고 안정적인 운영환경을 위한 Workflow

분산 시스템, 특히 MSA(마이크로서비스 아키텍처)나 EDA(Event-Driven Architecture) 기반 시스템을 운영하다 보면
비즈니스 로직의 상태 관리, 에러 처리, 재시도, 보상 트랜잭션 같은 복잡한 문제가 반드시 등장한다.

 

이런 복잡성을 단순화하기 위해 등장한 것이 바로 Temporal이다.

Temporal이란 무엇인가?

Temporal은 “복잡한 분산 시스템에서 안정적이고 확장 가능한 애플리케이션을 만들기 위한 오픈소스 플랫폼”이다.
핵심은 단순하다.

개발자는 비즈니스 로직에만 집중하고, 나머지 복잡한 분산 처리(재시도, 상태관리, 장애복구)는 Temporal이 책임진다.

 

왜 필요한가? — 분산 시스템에서의 고질적인 문제들

EDA 아키텍처의 장점은 명확하다.
서비스 간 결합도가 낮고, 각 서비스가 자율적으로 확장 가능하며, 병렬처리가 가능하다.

하지만 현실적인 문제도 많다:

에러 핸들링	메시지 중간 실패 시 재시도 로직을 직접 구현해야 함
상태 관리	워크플로우가 어디까지 진행됐는지 추적하기 어려움
보상 트랜잭션(Saga)	실패 시 이전 단계 롤백 로직을 직접 관리해야 함
데이터 일관성	분산된 서비스 간 데이터 동기화 어려움
장애 복구	중간 장애 시 작업 재개, 순서 보장 어려움

 

기존 방식 vs Temporal 방식

✈️ 예시: 항공사 예약 시스템

기존 방식

 

예약 요청 → 결제 → 마일리지 적립 → SMS 전송

각 단계가 다른 서비스로 구현되어 있다면,

• 결제가 실패했을 때 예약을 취소해야 하고
• 마일리지 적립이 실패하면 재시도해야 하며
• SMS 발송 실패 시 보상 로직을 추가해야 한다.

즉, 에러 핸들링 / 상태 관리 / 재시도 / 롤백을 모두 직접 작성해야 한다.

Temporal 방식

예약Workflow() {
  reserveFlight();
  processPayment();
  addMileage();
  sendSms();
}​

각 단계를 함수(Workflow Activity) 로 정의하면,
Temporal이 다음을 자동으로 처리한다:

• 단계별 상태 저장 (히스토리 DB)
• 재시도 및 복구
• 중간 실패 시 워크플로우 재개
• 장애 복구 및 로그 유지

개발자는 단순히 “무엇을 수행할지”만 정의하면 된다.

 

내부 아키텍처 — Temporal이 어떻게 동작하나?

Temporal은 서버(Temporal Server) 와 클라이언트(Worker, SDK) 로 구성된다.

 

Frontend Service	모든 요청의 진입점. 클라이언트 요청을 내부 서비스로 분배
History Service	워크플로우의 상태 및 이벤트 로그를 모두 저장
Matching Service	대기 중인 작업과 워커를 매칭, 큐 관리 및 분배 수행
Worker Service (System Worker)	시스템 내부 관리 작업 수행 (아카이빙, 데이터 정리 등)
Persistent Layer (DB)	워크플로우 상태, 실행 히스토리, 이벤트 로그를 저장

 

클라이언트 구성

템퍼럴 플랫폼과 상호작용하고, 워커플로우 시작, 조회, 쿼리실행 같은 작업을 하게해주는 구성