프로젝트의 API 윤곽이 잡혔겠다, 이제는 MSA의 기본 조건이 되는 비동기 처리를 적용해야 했다. 이때 비동기 처리는 트래픽이 쌓인 순간에 로직 처리에 있어 지연이 발생할 수 있는 부분(처리 비용이 높은 부분)에 적용해줌으로써 서비스의 가용성을 높여준다. 그리고 이를 적용할 비즈니스 로직에 있어서 적용 부분 이후에 바로 이어서 진행해야 할 순차적인 작업이 있는지 여부에 따라 적용 가능 여부가 판가름 난다. 내가 진행하고 있는 프로젝트는 여러 상황별로 고려해야할만큼 규모가 크지는 않았고, DB 접근에 대해서만 비동기 처리를 적용해주면 되었다.
다만 비동기 처리 적용하는 데에 있어서 어떠한 방식을 채택할지는 조금 고민이 되었다. 대표적인 선택지는 세 가지가 있었다.
- CompletableFuture
- RabbitMQ
- Apache Kafka
우선 Java에서 지원하는 CompletableFuture는 적용하는 데에 가장 어려움이 없긴 하지만, 단일 JVM 내에서 비동기 작업을 관리하기 때문에 MSA 분산 환경에서는 부적합했다. 그렇다면 남은 건 RabbitMQ와 Apache Kafka인데, 둘 다 처음 써보기 때문에 고민이 필요했다.
일단 이 둘은 약간 극과 극이라고 할 수 있을텐데, 왜냐하면 RabbitMQ는 설정이 간단하지만 처리 속도가 Kafka에 비해 현저히 낮으며, 반면 Kafka는 처리 속도와 안정성에 있어서는 가장 좋지만 단지 비동기 처리를 위해서만 Kafka를 적용한다는 게 분명 오버 엔지니어링이었기 때문이다. 그래서 이 둘 중 무엇을 선택할지에 대해서도 꽤 많은 시간을 들여야 했는데, 결국엔 Kafka를 적용하기로 했다. 이유는 다음과 같았다.
- RabbitMQ는 핵심 비즈니스 로직에 적용하기에는 처리량이 Kafka에 비해 현저히 낮았다. 물론 적용이 아예 불가능하다는 건 아니고, 또 현재 내 프로젝트가 운영 단계에 있는 것도 아니니 당장은 RabbitMQ를 적용해도 문제가 아니긴 했다. 그렇지만 서비스의 완성도를 고려한다면 RabbitMQ는 아쉬운 선택이었다. RabbitMQ는 애플리케이션의 비즈니스 로직 처리에 적용되기 보다는 애플리케이션의 설정 정보를 전달하는 정도가 적절하겠다고 판단했다.
- 한편으로는 이런 생각도 들었다. Kafka가 어렵다고 아쉬운 RabbitMQ를 적용해도 되나? 오버 엔지니어링인 건 분명 맞지만, 그럼 Kafka보다 관리하기 간편하면서도 처리 속도도 높은 메세지 큐가 더 있나? 애써 찾아보면 없진 않을 수도 있겠지만, 언젠가는 Kafka 자체도 부딪혀야 할 산이라고 판단했다. 오버 엔지니어링이면 뭐 어떤가 싶기도 하고.
- 사실 그냥 Kafka를 더 해보고 싶었다.
이렇게 비동기 처리를 위해 Apache Kafka를 적용하기로 큰 맘 먹고 결정. 그래서 결국 강의도 하나 새로 결제해서 듣기 시작했다... 이때는 이게 지금 내 건강을 악화시키는 큰 원인이 되리라고는 생각을 못했지...
