도입한 이유?
MSA 로 전환을 하고 MS 끼리 통신하는 방법은 여러가지가 있습니다.
물론 REST API 만 활용하여도 충분히 통신할 수 있다고 생각합니다.
하지만 MS 끼리의 결합도를 낮추고 성능 향상을 위해 메시지 플랫폼을 도입하고자 합니다. 메시지 플랫폼을 사용해본 경험이 없기때문에 어떤 플랫폼을 사용할지부터 고민하였습니다.
또한 MSA 에선 DDD 와같은 아키텍처 패턴들이 존재하는데 스케줄링을 통한 서비스 자동화가 되어있고 스터디를 구축하고 규칙을 만들어놓으면 나머지 서비스는 이벤트 기반으로 자동화가 되어야하기때문입니다.
먼저 각 메시지 플랫폼별 비교입니다.
제가 확인한건 SQS,SNS,Kafka,RabbitMQ 을 확인했고 다음과 같이 비교하였습니다.
| SQS | SNS | Kafka | RabbitMQ | |
|---|---|---|---|---|
| 오픈소스 | - | - | 오픈소스 | 오픈소스 |
| 브로커 구분 | 메시지 브로커 | 메시지 브로커 | 이벤트 브로커 | 메시지 브로커 |
| Queue/Topic | Queue | Topic | Topic | Queue |
| 동기/비동기 | 둘 다 가능 | 비동기 | 비동기 | 둘 다 가능 |
| 메시지 전달 보장 수준 | At least once(Standard),Exactlyonce(FIFO) | 메시지 전달 후 삭제하기 때문에 상실 가능. | At most once,At least once,Exactly once | At most once,At least once |
| 메시지 순서 보장 수준 | Standerd - Best effort,FIFO - 순서 보장 | - | 한 컨슈머 그룹 기준으로 파티션의 메시지는 순서 보장 | 하나의 큐에 하나의 컨슈머 연결시 순서 보장 |
| 모니터링 | SQS 콘솔, Cloud Watch 콘솔 이용 가능 | SQS 콘솔, Cloud Watch 콘솔 이용 가능 | 모니터링 오픈소스 연동해야함. | 모니터링 오픈소스 연동해야함. |
| 성능 | 300TPS | 무제한TPS | 100000TPS | 20000TPS |
| 개발 언어 | - | - | Scala | Erlang |
| 프로토콜 | - | HTTP, HTTPS, SMTP, SMS, SQS, application, lambda and firehouse | Binary protocol over TCP | AMQP, MQTT, STOMP |
메시지 보장수준
| 종류 | 개요 | 재전송유무 | 중복 삭제 유무 | 비고 |
|---|---|---|---|---|
| At Most Once | 1회 전달 시도 | X | X | 메시지는 중복되지 않지만 상실될 수 있음 |
| At Least once | 적어도 1회는 전달 | O | X | 메시지가 중복될 가능성은 있지만,상실되지는 않음 |
| Exactly Once | 1회만 전달 | O | O | 중복되거나 상실되지도 않고 확실하게 메시지가 도달하지만, 성능이 나오지 않음 |
메시지 플랫폼은 다양한 종류가 있습니다. 이중에서 선택하는것부터 많은 고민을 했는데
1. 메시지 보장수준
제가 눈여겨본건 이외에 Kafka의 메시지전달보장 수준을 눈여겨봤습니다 Spring Batch를 사용해 일괄처리를하고 Batch의 기능으로 성능을 향상 시킬수 있다고 생각하였고 중복되거나 메시지가 상실되면 성능의 이슈보다 많은 에러가 발생할 것이라 생각하였습니다.
2. batch 기능
kafka는 batch로 일괄처리가 가능합니다 이는 Spring batch를 사용했을때 시너지 효과를 기대할 수 있을것이라 판단했습니다.
3. 오픈소스
kafka는 오픈소스로 하기때문에 비용적인면에서 부담이 되지않았습니다.
4. 이벤트 기반
제가 알고있는바로는 Kafka는 이벤트/메시지 둘다 지원하는것으로 알고있지만 Schedule 기능을 활용한 Spring batch는 이벤트로 발생시켜 브로커에게 발송한다면 좋은 아키텍처를 구성할 수 있다고 생각하였습니다.
5. 성능
Exactly once 의 메시지 전달보장 수준을 사용했을때 성능이 나오지 않는다는 표를 확인할 수있습니다. 하지만 우리는 스케줄링 기능을 통해 Spring batch에 일괄적으로 처리합니다. 이 스케줄링기능은 1일 1~2회 실시할 예정입니다. 따라서 성능의 이슈는 크게 문제가 되지 않을것이라 생각했습니다.
또한 Kafka의 개발언어는 JVM 기반인 Scala입니다. 이는 JVM 구조를 이해하는데 도움이 될것이라 생각도 하였습니다.
프로젝트 도입
위와같은 이유로 Kafka 를 도입하려고 했고 다음은 프로젝트에 어떻게 적용할 것인가?
kafka정리
Kafka내용까지 다룬다면 내용이 너무 방대해질것같아 위의 링크에 정리해뒀습니다.
GitHubRepository 코드는 깃허브에 정리해뒀습니다. 물론 실제코드와는 차이가 많습니다. 단순히 Kafka를 모놀리식 프로젝트에 적용한 것이기때문에 내용보단 카프카 송수신 성공유무에 초점을 뒀습니다. Spring Batch또한 tasklet 방식에서 Chunk processing으로 전환할 예정입니다. 아래는 해당코드의 객체를 송수신한 과정의 결과 입니다.
회고
현재는 Spring Batch를 활용한 이벤트기반으로 데이터를 전달하는 것만 사용할 예정이지만 트래픽이 증가하여 데이터 파이프라인은 구축해야한다면 지금 Kafka를 설정해놓은것이 많은 비용을 절감시킬것이라 생각합니다. 다양한 메시지 플랫폼이 있었고 엄청난 차이가 있다고 생각이 들진않았지만 하나의 플랫폼 은 익혀야 겠다고 생각하였고 이번 프로젝트에 도입하였습니다.
