SQS, Kafka?

고민의 시작

---

프로젝트 진행 중에 변경할 사항이 생겼다.

지금까지는 스프링 내에서 In-Memory Queue에 직접 담아두는 방식으로 거래 트랜잭션을 처리했다.

이 방법은 속도는 빠를지언정 서버가 다운되는 등의 갑작스러운 상황에 대응할 수 없었다. 특히 kubernetes의 pod는 잦은 스케일링으로 인해 거래 엔진의 갯수가 일정하지 않으므로 트랜잭션 관리에 어려움이 있었다.

이 부분을 해결하고자 큐를 외부로 분리해서 중앙집중적으로 관리하는 게 낫다고 판단했다.

그렇다면 여기서 또 다른 고민이 생긴다.

 

어떤 툴을 사용해야 하는가?

---

각 툴의 종합 평가(스파이더 차트)

 

위 차트는 설명을 위한 참고일 뿐, 절대 기준으로 삼으시면 안됩니다.

 

SQS, Kafka, RabbitMQ 등등 다양한 선택지가 있었다. 모두 훌륭한 툴이지만 당연히 하나만 골라야 한다.

그럼 여기서 팀의 현재 상황과 요구사항을 볼 필요가 있었다.

 

감당할 수 있는 비용이어야 한다.

선택을 해야 할 쯤에는 운영 비용이 15만원 이상 남아있었다. 다만 프로젝트 기간이 한달 가량 남았고, 클라우드 프로바이더가 제공하는 서비스의 비용 발생 구조를 완전히 이해한 게 아니기 때문에 섣불리 아무거나 도입할 수는 없었다. (물론 이건 엔지니어로써도 어불성설이다)

시간은 부족했다.

배포환경에서 발생한 오류 해결, 문서 작업, 최적화 작업 등 해야 할 일이 잔뜩 있었다. 이 작업에만 시간을 할애할 수는 없었다. 더군다나 성능 최적화 작업까지 고려하면 함부로 맡길 수도 없었다.

낮은 성능은 용납 못한다.

프로젝트 자체가 암호화폐 모의투자 플랫폼이다. 모의지만 엄연히 거래 플랫폼이기에 성능을 아예 희생할 수는 없다고 판단했다.

 

 

이런 상황에서 SQS와 Kafka를 고민한 끝에 SQS로 정하였다.

이유는 다음과 같다.

소스코드 변경을 최소한으로 할 수 있다.

@SqsListener
public void processTransaction(Doe doe) {
	...
}

SQS는 리스너 방식이기 때문에 프로세스가 시작함과 동시에 메세지를 처리한다. 위에서 보이듯 어노테이션을 붙이면 소스코드 수정에 들어가는 수고가 줄어든다. Kafka는 리스너 방식이 아니며, kafka에 맞춰 코드를 수정해야 한다. 심지어 클래스 한두 개가 바뀌는 정도가 아니기에 부담으로 다가왔다.

비용이 합리적이다.

MSK 비용

AWS에서 제공하는 kafka 서비스는 시간 당 과금이다. 현재 테스트 환경인데 클러스터를 구축해놓으면 아무것도 하지 않는 상태에서도 과금이 진행된다. 남은 비용으로 고려했을 때 합리적이지 못하다고 생각했다. Kafka를 kubernetes 클러스터 내에 pod로 구축하는 경우도 있겠다만 위와 같은 소스코드의 이유로 기각하였다. 반면에 SQS는 요청 당 과금이다. 심지어 처음 한 달은 1백만 개 요청 처리가 무료다!

꽤 괜찮은 성능?

AWS에서 언급하길 SQS에서 높은 처리량 옵션을 켠다면 금융 분야에서도 활용할 수 있다고 한다. 위에 업로드한 종합 평가 이미지를 보면 알겠지만 성능면에서 표준 SQS는 미달이다. 다만 따로 알아본 결과, 이 옵션만 켜면 성능(처리량)면에서 준수한 결과가 나왔다.

사실 기존에 사용하고 있는 Redis Streams도 선택지에 있었지만 이 또한 거래 체결 로직의 소스코드를 필요 이상으로 변경해야 했고, 성능면에서 높은 처리량 옵션의 SQS와 큰 차이가 없었다.

 

 

"어떤 툴을 사용해야 하는가?"

상황에 따라서 다르다. 예산이 더 여유롭고, 프로젝트가 더 크다면(정말 거래소 규모로 만들어야 한다면) Kafka를 선택했을 것 같다.

무엇을 더 중요시에 하는지에 따라서 다르다. 역량을 쌓아나가면서 느낀 거지만 엔지니어는 결국 문제를 상황에 맞게 해결해야 하는 직업이라고 생각한다. 때론 비용을 지불해서 성능을 극대화시켜야 하고, 때론 성능을 일부 희생해서 안정성을 보장해야 하기도 한다. 다양한 옵션을 두고 최적의 선택을 할 수 있는 엔지니어가 될 수 있도록 오늘도 노력한다.