메시지 플랫폼 무엇이 좋을까

안녕하세요.

 

이번에는 프로젝트에서 메시지 플랫폼을 선택했던 과정에 대해 써보도록 하겠습니다.

 

먼저 프로젝트는 마이크로 서비스 아키텍처를 사용하고 있습니다.

각 서비스는 각자의 관심사에 맞게 분리되어 있습니다.

그렇다 보니 다른 서비스와 연동을 하는 일이 왕왕 있습니다. 

상품을 판매하는 서비스는 상품의 재고를 관리하는 서비스와 연동이 되어야 하듯이요.

 

이때 저희는 이벤트 방식과 API방식을 필요에 따라 적절한 곳에 사용하고 있습니다.

각자의 목적에 맞게 사용되는 곳이 다르기에 뭐가 더 좋다는 것이 아닙니다.

 

비교

이벤트의 장점은 서비스 간의 의존성을 분리할 수 있습니다. 

의존성이 분리되면 타 서비스의 간섭이 줄어들고 코드가 변경되어야 하는 이유가 줄어들게 됩니다.

 

API를 사용했을 때는 성공/실패 여부를 사용자가 바로 확인해야만 하는 작업에 사용될 수 있습니다.

또 서비스 간 트랜잭션을 쉽게 구현할 수도 있습니다.

 

 

구현이 쉬운 API 방식 말고 이벤트 방식을 사용하는 이유는 무엇일까요.

몇 가지 이유가 있었습니다.

 

 

여러 개의 서비스와 연동(의존성의 분리)

서비스 1의 액션이 일어나서 타 서비스에 해당 내용을 전파해야 할 경우 각자 API로 연결해줘야 합니다.

이는 쉬운 구현이 장점이지만 각자의  트랜젝션 여부를 판단해 성공/실패등의 컨트롤을 해주어야 합니다.

또한 Service 4가 생기면 코드를 수정해줘야 합니다.

 

그래서 저희는 이벤트 브로커에 이벤트를 게시하고 각 서비스가 각자의 목적에 맞게 가져가는 구조로 해당 문제를 쉽게 해결할 수 있다고 판단했습니다.

 

위의 방법을 구현하는 방법은 여러 가지가 있는데요.

유명한 Kafka와 AWS의 SNS + SQS 조합이 있습니다.

이 외에도 많은 이벤트/메시지 브로커들이 있습니다.

 

1. Kafka

 

KAFKA

먼저 카프카는 pub/sub 구조로 대부분의 것은 사용자가 커스텀할 수 있습니다.

커스텀이 자유롭듯이 대부분을 직접 구축해야 하는 단점이 있습니다.

퍼블리싱 전략과 컨슘 전략을 세워야 합니다.

 

 

2. SNS + SQS

여러 서비스 전파의 문제를 해결하려면 단일 SQS 구조로는 힘듭니다. 하나의 소비자가 먼저 메시지를 사용하면 메시지는 중복으로 처리할 수 없기 때문에 Service 3는 메시지를 읽을 수 없게 됩니다. 

SQS

이를 위해 더 확장성 있는 시스템 구조로 사용되는 것이 AWS의 SNS를 사용하는 것입니다.

SNS는 kafka와 같이 pub/sub구조로 kafka를 대체할 수 있지만 특성상 메시지를 보내고 바로 삭제하기에 메시지 손실등이 발생할 수 있으므로 SQS와 함께 사용하는 경우가 많습니다.

(SNS도 retry와 DLQ를 설정할 수 있습니다. 다만 SQS를 붙임으로써 데이터의 지연처리 효과를 얻을 수 있습니다.

Push방식과 Pull방식의 차이인 것 이지요.)

 

SNS + SQS

 

 

 

 

 

이렇게 여러 가지 방법들이 있을 때 무엇을 사용해야 할까요.

각자 장단점이 있고 현재 우리에게 가장 어울리는 것은 무엇인지 고민이 필요했습니다.

 

모두 결과론적으로 보면 목적에 충족하는 동작을 합니다.

SNS + SQS는 Kafka와 별반 다르지 않지만 저는 AWS에서 쉬운 관리와  DLQ 등도 쉽게 구현, 안정성을 높이 평가해 간단한 구조나 작은 규모일 경우는 SQS + SNS가 카프카 보다 더 어울리는 구조라고 생각합니다.

 

 

 

• https://stackoverflow.com/questions/44359995/aws-sns-case-of-multiple-subscribers 
• https://birdgang82.medium.com/aws-service-communication-amazonsns-dff3ab3b17b6