Service Discovery(Eureka)와 Temporal의 역할 비교
마이크로서비스 아키텍처(MSA)를 설계함에 있어 **서비스 간 통신(Inter-service Communication)**은 가장 중요한 고려 사항 중 하나다. 전통적으로는 Netflix Eureka와 같은 Service Discovery 패턴이 주로 사용되었으나, 최근 Temporal과 같은 워크플로우 오케스트레이션 엔진이 도입되면서 두 기술의 역할 범위에 대한 논의가 필요해졌다.
본 글에서는 Eureka로 대표되는 Service Discovery 패턴과 Temporal의 워크플로우 패턴을 비교하고, 각 기술이 마이크로서비스 통신을 처리하는 방식의 차이와 아키텍처적 공존 방법에 대해 정리한다.
1. Service Discovery의 본질: 동적 네트워크 주소의 해결
MSA 환경에서는 서비스 인스턴스가 오토스케일링(Auto-scaling) 등에 의해 수시로 생성 및 소멸한다. 따라서 고정된 IP 주소를 기반으로 통신하는 것이 불가능하다.
Eureka와 같은 Service Discovery 메커니즘은 이 문제를 해결하기 위한 동적 전화번호부(Registry) 역할을 수행한다.
- 동작 방식: Client 서비스가 Registry에 Target 서비스의 위치(IP/Port)를 조회한 후, 해당 주소로 **직접 요청(Direct Call)**을 보낸다.
- 통신 형태: 주로 HTTP(REST) 또는 gRPC를 이용한 동기식(Synchronous) 통신에 사용된다.
- 핵심 가치: 실시간성(Real-time)과 낮은 지연 시간(Low Latency).
2. Temporal의 접근 방식: 큐(Queue) 기반의 실행 보장
Temporal은 단순한 통신 도구가 아닌, 분산 시스템에서의 상태 관리와 **내구성 있는 실행(Durable Execution)**을 보장하는 오케스트레이션 엔진이다. Temporal은 서비스 간 통신을 위해 **태스크 큐(Task Queue)**와 폴링(Polling) 방식을 채택한다.
- 동작 방식: 워크플로우(Requester)가 특정 태스크 큐에 작업을 적재하면, 워커(Worker) 프로세스가 해당 큐를 폴링하여 작업을 가져간다.
- 통신 형태: 비동기식(Asynchronous) 메시지 전달에 가까우며, 서버의 물리적 위치(IP)를 알 필요가 없다.
- 핵심 가치: 신뢰성(Reliability)과 작업 완료 보장.
3. 핵심 논점: Temporal이 Service Discovery를 대체하는가?
"Temporal을 도입하면 Eureka는 불필요한가?"라는 질문에 대한 답은 통신의 목적에 따라 달라진다.
3.1. 대체 가능한 영역: 비동기 트랜잭션 및 워크플로우
Temporal을 사용하는 작업 범위 내에서는 Service Discovery가 불필요하다. 워크플로우(Orchestrator)는 워커의 IP 주소가 아닌 **'논리적인 큐의 이름'**만 알면 되기 때문이다. 워커가 큐를 폴링하는 구조이므로, 로드 밸런싱과 라우팅이 큐 레벨에서 자연스럽게 해결된다.
3.2. 대체 불가능한 영역: 실시간 데이터 조회
사용자 인터페이스(UI)에 즉각적으로 데이터를 표시해야 하는 단순 조회(GET) 요청의 경우, Temporal을 거치는 것은 비효율적이다. 큐에 작업을 넣고 워커가 가져가기를 기다리는 오버헤드가 발생하기 때문이다. 이러한 **초저지연(Ultra-low latency)**이 요구되는 통신에는 Eureka나 Kubernetes DNS를 통한 Direct Call 방식이 적합하다.
4. 아키텍처 패턴 비교: Orchestration vs Choreography
Temporal의 큐 기반 통신은 Kafka를 이용한 이벤트 기반 아키텍처(EDA)와 유사해 보일 수 있으나, **제어권(Control Flow)**의 위치에서 결정적인 차이가 있다.
4.1. Choreography (Event-Driven)
- 각 서비스가 이벤트를 발행하고 구독하며, 비즈니스 로직이 분산되어 있다.
- 서비스 간의 결합도는 낮으나, 전체 비즈니스 프로세스의 흐름을 파악하고 디버깅하기 어렵다. (Observability 저하)
4.2. Orchestration (Temporal)
- 중앙 집중형 제어: 워크플로우 코드가 전체 비즈니스 로직의 순서와 상태를 제어한다.
- Hub-and-Spoke 모델: 워커는 작업을 수행한 후 반드시 중앙(Temporal Service)에 결과를 보고하고, 워크플로우는 그 결과에 따라 다음 작업을 지시한다.
- 큐를 사용하지만 논리적 흐름이 중앙에 집중되어 있어 코드 가독성과 유지보수성이 뛰어나다.
5. 결론 및 아키텍처 제언
현대의 MSA 환경에서는 API Gateway와 Temporal을 결합한 하이브리드 아키텍처가 가장 합리적이다.
-
Ingress Layer (API Gateway + Discovery):
- 외부 트래픽의 진입점 역할을 수행한다.
- 인증/인가 및 단순 데이터 조회 요청은 Service Discovery를 통해 백엔드 서비스로 직접 라우팅하여 응답 속도를 확보한다.
-
Business Logic Layer (Temporal):
- 결제, 주문 처리, 데이터 배치 등 상태 관리가 필요하고 복잡도가 높은 비즈니스 로직은 Temporal 워크플로우로 위임한다.
- 이 계층에서는 IP 기반의 Discovery가 아닌, 큐 기반의 오케스트레이션을 통해 시스템의 회복 탄력성(Resilience)을 극대화한다.
결과적으로 두 기술은 상호 배타적인 관계가 아니며, **'속도(Latency)'**와 **'신뢰성(Reliability)'**이라는 서로 다른 요구사항을 충족시키기 위해 상호 보완적으로 사용되어야 한다.
Service Discovery(Eureka)와 Temporal의 역할 비교
마이크로서비스 아키텍처(MSA)를 설계함에 있어 **서비스 간 통신(Inter-service Communication)**은 가장 중요한 고려 사항 중 하나다. 전통적으로는 Netflix Eureka와 같은 Service Discovery 패턴이 주로 사용되었으나, 최근 Temporal과 같은 워크플로우 오케스트레이션 엔진이 도입되면서 두 기술의 역할 범위에 대한 논의가 필요해졌다.
본 글에서는 Eureka로 대표되는 Service Discovery 패턴과 Temporal의 워크플로우 패턴을 비교하고, 각 기술이 마이크로서비스 통신을 처리하는 방식의 차이와 아키텍처적 공존 방법에 대해 정리한다.
1. Service Discovery의 본질: 동적 네트워크 주소의 해결
MSA 환경에서는 서비스 인스턴스가 오토스케일링(Auto-scaling) 등에 의해 수시로 생성 및 소멸한다. 따라서 고정된 IP 주소를 기반으로 통신하는 것이 불가능하다.
Eureka와 같은 Service Discovery 메커니즘은 이 문제를 해결하기 위한 동적 전화번호부(Registry) 역할을 수행한다.
2. Temporal의 접근 방식: 큐(Queue) 기반의 실행 보장
Temporal은 단순한 통신 도구가 아닌, 분산 시스템에서의 상태 관리와 **내구성 있는 실행(Durable Execution)**을 보장하는 오케스트레이션 엔진이다. Temporal은 서비스 간 통신을 위해 **태스크 큐(Task Queue)**와 폴링(Polling) 방식을 채택한다.
3. 핵심 논점: Temporal이 Service Discovery를 대체하는가?
"Temporal을 도입하면 Eureka는 불필요한가?"라는 질문에 대한 답은 통신의 목적에 따라 달라진다.
3.1. 대체 가능한 영역: 비동기 트랜잭션 및 워크플로우
Temporal을 사용하는 작업 범위 내에서는 Service Discovery가 불필요하다. 워크플로우(Orchestrator)는 워커의 IP 주소가 아닌 **'논리적인 큐의 이름'**만 알면 되기 때문이다. 워커가 큐를 폴링하는 구조이므로, 로드 밸런싱과 라우팅이 큐 레벨에서 자연스럽게 해결된다.
3.2. 대체 불가능한 영역: 실시간 데이터 조회
사용자 인터페이스(UI)에 즉각적으로 데이터를 표시해야 하는 단순 조회(GET) 요청의 경우, Temporal을 거치는 것은 비효율적이다. 큐에 작업을 넣고 워커가 가져가기를 기다리는 오버헤드가 발생하기 때문이다. 이러한 **초저지연(Ultra-low latency)**이 요구되는 통신에는 Eureka나 Kubernetes DNS를 통한 Direct Call 방식이 적합하다.
4. 아키텍처 패턴 비교: Orchestration vs Choreography
Temporal의 큐 기반 통신은 Kafka를 이용한 이벤트 기반 아키텍처(EDA)와 유사해 보일 수 있으나, **제어권(Control Flow)**의 위치에서 결정적인 차이가 있다.
4.1. Choreography (Event-Driven)
4.2. Orchestration (Temporal)
5. 결론 및 아키텍처 제언
현대의 MSA 환경에서는 API Gateway와 Temporal을 결합한 하이브리드 아키텍처가 가장 합리적이다.
Ingress Layer (API Gateway + Discovery):
Business Logic Layer (Temporal):
결과적으로 두 기술은 상호 배타적인 관계가 아니며, **'속도(Latency)'**와 **'신뢰성(Reliability)'**이라는 서로 다른 요구사항을 충족시키기 위해 상호 보완적으로 사용되어야 한다.