kafka, rabitmq, sqs 사용시 고려사항 - 마이크로 서비스 아키텍처

sqs 같은 비동기식 구현에서 만약에 처리되지 않은 메세지가 있다면.

아래 4가지 방법을 쓴다.

1. 재처리

메세지 처리 중 에러가 발생했을때 다시 처리하도록 하는 방법

최대 재처리 횟수를 정해야한다. - 보통 3~5번

에러 발생 후 바로 재처리하면 같은 원인으로 에러가 날 수 있다.

일정 시간 기다렸다가 재처리한다.

1번째 에러 발생시 - 1초후

2번째 에러 발생시 - 5초후

세번째 30초후

 

2. 무시

에러가 난 메세지를 무시하고 없애는 방식이다.

 

3. 알림

에러가 발생했을때 관리자에게 알려주는 방식이다.

 

4. 사람이 처리

에러 처리 부분이 복잡하거나 규모가 큰 경우 에러처리를 해주는 컴포넌트를 만든다.

Error hospital 이라고 부른다.

처리 중 에러가 난 메세지들을 모아서 다양한 정책으로 재처리한다.

 

 

큐 메세지 전달 패턴

1. fire forgot - 큐에 메세지를 보내고 처리 여부에 상관없이 메세지가 잘 보내졌으면 응답한다.

2. pub sub - 메세지를 publish 하고 n 개의 컴포넌트들이 구독한다.

애져의 토픽 같은 역할을 한다.

3. 라우팅 - 메세지 큐에서 조건에 따라 다른 컴포넌트를 1개 호출한다.

 

메세지 큐 구성시 고려사항

1. 메세지를 어디에 저장할 것인가

- 파일, 메모리, DB 같은 선택지들이 있다.

메모리는 성능은 좋은데 장애시 메세지가 유실될 수 있다.

파일은 성능은 좋으나 처리되지 않은 메세지를 처리하려면 공유 파일 저장소 같은 것을 써야한다.

RDBMS는 관리는 좋으나 가장 느리다.

 

2. out of memory error 고려

큐에서 메세지를 안 꺼내고 계속 담아두면 메모리를 너무 많이 쓴다.

 

3. 트랜잭션 지원하는지

AMQP 같은 경우에는 트랜잭션 기능을 지원하지 않는다.

큐에서 메세지를 가져갔지만 처리 되지 못했으면 큐에 다시 넣거나 에러 큐로 가야한다.

 

 

TPS 단위

카프카 같은 큐의 성능을 나타낼때도 쓴다.

transaction per seconds 초당 트랜잭션의 개수를 말한다.

카프카 같은 경우 10만 tps 이상의 성능을 낸다.

rabitmq 같은 경우 2만 tps 정도의 성능을 낸다.

 

마이크로 서비스 아키텍처 읽고 정리 중