temporal 사용 후기

https://docs.temporal.io/

Documentation | Temporal Documentation

 

temporal은 Microservice Architecture에서 주로 사용되는 플랫폼으로, Temporal Application은 Temporal Workflow Execution들로 구성된다.

Temporal Workflow Execution은 다음과 같은 특징을 지닌다.

• resumable: 실행이 일시정지한 후 다시 재개될 수 있다.
• recoverable: 실행이 실패했을 때 복구할 수 있다.
• reactive: 외부 이벤트에 반응할 수 있다.

기존 기술과 비교

---

• 기존 기술은 fail시 execution state가 lost되어 resumable하지 않기 때문에 retry할 경우 처음부터 다시 시작해야 한다. 반면 temporal은 activity 단위로 state를 저장할 수 있기 때문에 activity 단위로 resume할 수 있다.
• temporal은 signal과 query를 이용, function execution과 통신을 할 수 있다.

 

템포럴 구조

---

템포럴 클러스터(서버)는 다음과 같이 구성된다. 

• frontend service: 라우팅, 인증 등을 수행
• history service: 데이터 유지
• matching service: 스케줄링을 위한 taskqueue를 운영
• worker service: 실제 워크플로우 수행

추가적으로 여러 개의 클러스터 사이의 동기화를 위해 database가 사용될 수 있다.

 

보다 자세한 설명...

---

사실 위의 설명만 읽으면 그래서 템포럴이 무엇을 하는지 알기 쉽지 않다.

템포럴은 하나의 플랫폼인 만큼 구성하고 있는 요소가 많기 때문이다.

자세한 내용은 공식 도큐멘트를 참조하면 좋지만, 내용이 너무 많기 때문에 요약이 필요하다.

 

MSA vs Monolithic Architecture

태초의 프로그램은 모두 monolithic architecture를 사용했다.

이 아키텍쳐는 하나의 큰 유닛의 프로그램이 존재해서 그 프로그램은 하나의 코드를 기본으로 하고 있고, 개발이 쉽다는 장점이 있다.

하지만 monolithic 아키텍쳐는 크기가 커질 수록 개발이 힘들어지고, flexible하거나 reliable하지 않다는 단점이 있다. 

즉 스케일 인/아웃이 필요한 부분만 따로 구성할 수 없다는 말이다.

 

이러한 단점을 극복하기 위해 나온 것이 MicroService Architecture(MSA)이다.

각각의 서비스를 어플리케이션으로 분리해서 business logic과 database를 가질 수 있도록 하는 것이다.

이렇게 구성하면 각각의 서비스마다 코드가 분리되어 더 작은 단위의 개발이 가능하고, 자원이 더 필요한 부분만 scale in/out을 할 수 있다.

하지만 end-to-end test가 어려워지고, 각각의 서비스 간의 통신이 발생할 수 있어 오버헤드가 더 커진다.

또한, 서비스 간의 통신이 제대로 이루어졌는지 신뢰할 수 없다. 즉, 버그가 발생할 수 있는 부분이 하나 더 추가되는 것이다.

 

Temporal

그래서 microservice 기반에서 monolithic한 부분을 추가해서 단점을 보완한 것이 temporal이다.

temporal에서는 통신이 temporal server를 거쳐서 이루어진다.

temporal frontend를 통해 들어오는 패킷이 temporal server에서 비어있는 taskqueue로 스케줄링되고, 해당 taskqueue를 가진 worker에서 실행된다.

이 과정에서 taskqueue에 들어온 task들의 상태는 temporal에 저장된다.

 

Workflow vs Activity

Temporal을 구성하고 있는 큰 축이다. 

Taskqueue에는 workflow나 activity 모두 스케줄링할 수 있는데, 보통 activity를 단독으로 실행하지 않고, 하나의 workflow 내에서 여러 개의 activity를 포함하는 식으로 구성한다.

workflow와 activity는 구분하기가 어려운데, activity를 하나의 작업 단위(email 보내기, transcoding 등)로 생각하면 되고, workflow는 activity를 여러개 실행할 수 있는 더 큰 개념으로 여기면 된다. Activity가 activity를 호출하는 것을 권장하지 않는 대신, workflow 안에서 activity를 실행하는 것은 괜찮다.

 

Temporal 장단점

---

오래 사용해보지는 않았지만, 여러 가지 기능을 사용해 보면서 temporal의 장단점을 파악해 보았다.

 

장점

1. 에러 처리의 공수를 줄이고 로직에만 집중할 수 있다: 네트워크 에러 등의 이유로 micro service 사이의 통신이 실패할 수 있다. 사실 request를 보낸 측에서는 어떤 이유로 실패했는지 모를 수도 있고, 실패에 대한 처리를 복잡하게 해 주어야 한다. 하지만 temporal이 reliable하게 하는 역할을 해 주므로 로직에만 집중 가능하다.
2. 긴 프로세스에 대한 health check도 가능하다: long-living workflow라는 것도 존재하는데, 오랜 시간 수행하는 워크플로우를 말한다. 해당 프로세스가 죽었는지 살았는지 체크하는 것은 쉽지 않은데 이에 대한 체크도 heartbeat, signal 등을 통해 쉽게 구현 가능하다.

단점

1. 대용량 파일 처리가 어렵다: frontend <-> worker 사이에 1MB가 넘는 파일 전송이 어렵다. frontend <-> worker 사이의 param을 서버에서 모두 저장하기 때문이다. 이 때문에 file 저장 등의 작업을 frontend service에서 처리해야 하는 치명적 단점이 있다. 개념적으로 보면 긴 실행시간을 가지기 때문에 frontend가 아닌 worker에서 처리하는 것이 맞는데도 말이다. 
2. latency가 증가한다: frontend <-> worker의 한 단계를 더 거치기도 하고, 템포럴 서버 내에서 스케줄링, 큐잉이 발생하기 때문에 단순 frontend에서의 작업 실행과 frontend에서 workflow 호출 후 작업 실행을 비교했을 때 엄청난 차이가 난다. 단순 db select 작업의 경우 frontend만은 80ms, worker 포함하면 1s까지도 나오기도 한다. 아무리 작업 완료를 보증한다고 해도 이 정도의 큰 차이는 용인하기 힘들다.

이런 단점을 해결하기 위해서는 optimization과 더 좋은 방법이 필요할 듯 하다.