[댕댕어디가] MSA 아키텍처 전환기(4) - 서비스간 비동기 통신하기

 

project-service와 region-service 간에는 통신이 필요합니다.

 

그 중에서 이번에는 비동기 통신이 필요한 경우 어떻게 해결했는지 이야기해보려 합니다.

 

대표적인 예시에는 방문 횟수 증가 로직이 있습니다.

: 유저가 A라는 지역의 A1 시설을 방문하면, 이를 인증하기 위해 실시간 리뷰를 작성하여 방문 횟수를 증가시킵니다. 이때, A 지역에서 방문 횟수가 가장 많은 유저가 땅의 주인이됩니다.

 

해당 로직을 service별로 역할을 나누어보면 다음과 같습니다.

 

• 유저 실시간 리뷰 작성 요청 -> project-service 에서 실시간 리뷰 저장 -> region-service에서 방문 횟수 증가 및 새로운 땅의 주인 판별

위의 로직을 처리하기 위해서는 MSA 아키텍처에서는 서비스 간의 통신이 필요합니다.

• project-service 리뷰 저장 후 방문횟수 증가 요청  -> region-service에서 방문 횟수 증가 및 땅 주인 판별

 

그럼 위 같은 통신 로직을 구성하기 위해 어떤 방법이 있을지 고민해보겠습니다.

 

1. 서비스간 통신 방법

서비스간 통신 방법에는 동기 VS 비동기로 나뉩니다.

 

동기로 통신하는 경우에는 http, grpc를 이용하는 방법이 있습니다. 

• 장점 : 단순하며, 디버깅에 용이합니다.
• 단점 : 응답 지연, 서비스 간 결합이 강해지면서, 장애 전파 및 유연성 저하됩니다.

비동기로 통신하는 경우에는 메시지 큐, 이벤트 스트리밍을 이용하는 방법이 있습니다.

• 장점 : 결합도가 느슨해지며 장애 격리,서비스 간 부하를 분산하여 대량의 요청을 처리, 확장성에 용이합니다.
• 단점 : 트랜잭션에 어려움을 겪을 수 있으며, 디버깅 어려움, 비용 증가가 있습니다.

2. 비동기 통신 선택 이유

project-service와 region-service 간 비동기 통신으로 결정하였으며 그 이유는 아래와 같습니다.

1) project-service와 region-service 간에는 강한 결합이 필요한 경우가 없습니다.

2) project-service에서 region-service 으로 많은 요청이 예상되는데, 이때 동기로 실행된다면 병목 현상이 생기기 때문입니다.

3) project-service와 region-service 간에는 집요한 트랜잭션이 요구되지 않습니다.

 

 

3. 비동기 통신 수단 - 메세지 브로커 VS 이벤트 브로커

메세지 브로커

• 서비스 간의 메세지를 전달하는 중개 역할을 합니다.
• 대규모 메세지 기반 미들웨어 아키텍처에서 주로 사용합니다.
• 프로듀서와 컨슈머 간에 메세지를 통신하고 네트워크를 맺는 용도로 사용합니다.
• 데이터 보내고 처리하고 즉시 또는 짧은 시간 내에 삭제합니다.
• 장애 발생 시 메세지의 손실을 방지하고, 메세지의 순서를 보장하는 등의 기능이 포함되어 있습니다.
• ex. 레디스 큐, 레빗엠큐

이벤트 브로커

• 메세지 브로커 역할을 할 수 있습니다.
• 이벤트라는 레코드를 장부에 하나만 저장하고 인덱스를 통해 개별 액세스를 관리합니다.
• 업무상 필요한 시간 동안 이벤트를 큐에 저장할 수 있습니다.
  
  • 브로커에 저장함으로써 단일 진실 공급원으로 사용할 수 있음
  • 장애가 일어난 지점부터 재처리할 수 있음
  • 많은 양의 데이터를 처리할 수 있음
• 이벤트의 순서를 보장하고, 이벤트 데이터를 영구적으로 저장하는 등의 기능을 제공합니다.
• ex. 카프카, AWS 키네시스

4. 비동기 통신 수단 - 카프카 선택 이유

위의 차이점을 고려하여 이벤트 브로커인 카프카를 선택하였습니다.

 

카프카에 대한 장점

• 다중 컨슈머로 인해 컨슈머에 대한 결합도가 낮다.
  • 하나의 메세지를 여러 컨슈머가 공유할 수 있기 때문
• 메세지를 지속성 있게 저장할 수 있다.
  • 이로써 컨슈머들이 항상 실시간으로 데이터를 읽어올 필요가 없다. -> 트래픽 폭주에도 데이터 유실 위험 없음
• 확장성이 좋다.
  • 데이터 증가에 따라 수백 개의 브로커로 구성된 대큐모 클러스터로 이루어진 프로덕션 환경으로 옮기면 된다.
  • 파티셔닝에 따른 수평적 확장이 가능하다.

카프카에 대한 단점

• 복잡하여 기술적인 이해가 있어야 안전한 세팅이 가능하다.
• 기본적으로 브로커가 3개 필요하기 때문에 서버 비용이 들 수 있다.

 

카프카 선택 이유

위의 장단점을 기반으로, 현재 상황에 맞춰 고민해 보았습니다.

• 메세지 순서 유지가 가능하며 유실 위험이 없다.
  • Project -Service 와 Region-Service 간에는 실시간 리뷰 작성으로 인한 땅 지역의 현재 주인을 갱신하는 이벤트가 필요하기 때문에 순서는 절대적으로 필요하며 유실 위험이 있어서는 안됩니다.
  • 카프카는 중간에 서버가 다운되어도, 메세지가 삭제되지 않기 때문에 멈췄던 곳부터 다시 읽을 수 있어 유실 위험이 없습니다.( 다른 브로커들과의 차이점)
• 확장성이 뛰어나다.
  • 아직은 작은 서비스이지만, 이후에 서비스가 성장하고 기능이 추가되었을 때, 확장이 용이하다는 점입니다.
• pub/sub 패턴으로, 여러 수신자에게 데이터를 전달할 수 있다.
  • 땅 주인이 갱신되었을 때, 또는 스토리 업로드 시 등 기획 측면에서 하나의 이벤트를 여러 컨슈머가 받아야하는 경우가 있는데, 카프카는 하나의 메세지에 대해 여러 컨슈머가 읽을 수 있습니다.