가상 면접 사례로 배우는 대규모 시스템 설계 기초 2 - 분산 메시지 큐

분산 메시지 큐

1. 메시지 모델

1. point-to-point model : 전통적인 메시지 큐. 큐에 전송된 메시지는 한 소비자만 가져갈 수 있음. 메시지를 가져갔다는 뜻으로 ACK 를 보내면, 큐에서 해당 메시지가 삭제됨. 

2. publish-subscribe model : 토픽에 메세지를 보내고 토픽으로부터 메세지를 받음. 메세지는 해당 토픽을 구독하는 모든 소비자들에게 전달됨. 메세지는 토픽에 보관됨. 토픽을 여러 파티션으로 나눠서, 메시지를 균등하게 각각의 파티션에 보내어 분산 배치함. 

2. 문제의 설계 요구 조건 

• 메세지 큐의 기본 조건 : 생산자는 메시지를 큐에 보내고, 소비자는 큐에서 메시지를 꺼낼 수 있어야 한다. 
• 기본 기능 외에도 성능, 메시지 전달 방식, 데이터 보관 기간 등을 고려해야 한다. 

3. 개략적 설계안 

1. 클라이언트 

• 생산자
• 소비자 

2. 핵심 서비스 및 저장소 

• 브로커 : 파티션들을 유지한다. 하나의 파티션은 토픽에 대한 부분 집합.
• 저장소 :
  • 데이터 저장소 : 메시지를 보관한다.
  • 상태 저장소 : 소비자의 상태를 저장한다. 
  • 메타데이터 저장소 : 토픽 설정, 속성 등을 저장한다.
• 조정 서비스
  • 서비스 탐색 : 어떤 브로커가 살아있는지 알려준다.
  • 리더 선출 : 컨트롤러 역할. 파티션 배치를 책임진다.

4. 상세 설계 

1. 데이터 저장소 

• 선택지 1) 데이터 베이스 : 저장 요구사항을 맞출 수는 있지만, 메시지 큐 데이터 사용 패턴에 적합하지 않음. 읽기 연산과 쓰기 연산이 동시에 대규모로 빈번하게 일어나는 메시지 큐에 적합하지 않음 -> 오히려 병목이 됨. 
• 선택지 2) 쓰기 우선 로그 WAL : Write Ahead Log 는 새로운 항목이 추가되면 append-only 만 하는 방식. MySQL 의 복구 로그가 WAL 로 구현되어 있음. WAL 에 대한 접근 패턴은 읽기 / 쓰기 모두 순차적이고, 접근 패턴이 순차적일 때 디스크는 좋은 성능을 보인다. 

 

• 디스크가 접근 패턴이 순차적일 때 효과적인 이유 

- 랜덤 접근 시에, 디스크는 헤드를 이동하고, 원판이 돌아서 위치를 맞추기를 기다린 후에 데이터 접근 (읽기 / 쓰기) 작업을 한다. 실제 데이터 처리보다 이동 및 대기 시간이 더 커질 수 있다. 

- WAL 은 순차적으로 write 작업은 계속 뒤에 append 만 시키고, read 작업은 앞에서부터 읽도록 시키기 때문에 디스크에서 성능이 효과적이다. 

2. push model vs pull model

push model : 브로커가 소비자에게 메시지를 보내는 방식

• 장점 : 브로커는 메시지를 받는 즉시 소비자에게 보낼 수 있음. 
• 단점 : 소비자가 메세지를 처리하는 속도가 생산자가 메시지를 생성하는 속도보다 느린 경우, 소비자에게 큰 부하가 걸릴 가능성이 있음. 

pull model : 소비자가 메시지를 땡겨와서 가져가는 방식 

• 장점 : 메시지를 소비하는 속도를 소비자가 결정 가능함. 소비하는 속도가 생산 속도보다 느려지면, 소비자를 늘려서 해결할 수 있음. 혹은 기다릴 수 있음. 배치 처리에 적합함. 
• 단점 : 브로커에 메시지가 없어도 소비자가 데이터를 끌어가려고 하는 시도를 할 것임. -> 대부분 메세지 큐는 롱 폴링 모드를 지원해서, 일정 시간은 기다리도록 하게 함. 메시지가 올 때까지 서버가 잠깐 붙잡고 기다려주는 방식. 숏 폴링은 계속 요청을 보내서 네트워크를 낭비하는데, 롱 폴링은 서버 부담이 줄어든다는 장점이 있음.

대부분의 메시지 큐는 pull model 을 지원한다.