18장 - 분산 메세지 큐

1. 큐를 사용하는 이유#

• 결합도 완화 : 컴포넌트간 독립적 운영 가능
• 규모 확장성 개선 : 퍼블리셔와 컨슈머의 수평적 확장이 용이함
• 가용성 개선 : 특정 컴포넌트의 장애가 전파되지 않음
• 성능 개선 : 한곳의 레이턴시가 전파되지 않음
• 대표적으로 카프카, 래빗MQ 등이 있음

2. 요구사항 정리#

• 퍼블리셔는 메시지를 보낼 수 있어야 함
• 컨슈머는 메세지를 수신할 수 있어야 함
• 반복적/단편적 수신이 가능해야 함
• 메시지는 생성 순으로 전달되어야 함
• 전달 방식은 최소 한 번, 최대 한 번 정확히 한 번 가운데 설정 가능해야 함
• 대역폭 설정이 가능해야 함
• 분산 시스템으로 규모 확장이 가능해야 함
• 지속성/내구성을 가져 영구적으로 데이터가 저장되어야 함

2.1. 전통적 메시지 큐와 다른점#

• RabbitMQ 같은 전통적 MQ는 메세지의 보관을 중요시 여기지 않음

  • 처리 용량을 넘어서면 디스크에 저장한다만 감당 수준이 아주 낮음
  • 그리고 순서도 보장하지 않음

3. 청사진 그리기#

3.1. 메시지 모델#

• 메세지 모델은 크게 1:1 모델, Pub-Sub 모델로 구분된다.
• 1:1 모델은 전통적 모델로 하나의 메세지는 하나의 소비자에게만 전달 가능하다.
• 펍섭모델은 토픽 개념을 통해서 같은 토픽을 구독하는 모든 소비자가 같은 메세지를 수신받을 수 있다.

3.2. 브로커#

• MQ하나로 감당하기 힘들면 샤딩을 통해 극복한다.
• 샤딩된 메세지는 파티션마다 특정 오프셋으로 순서가 보장되어 보관되며 이런 파티션 서버를 브로커라 부른다.
• 퍼블리셔가 만든 메세지는 무작위의 파티션에 들어간다.

3.3. 소비자 그룹#

• 역할에 따라 어떤 메세지를 받을지 구분해놓을 수 있다.

  • 요런걸 소비자 그룹이라 한다.
• 소비 순서를 보장하려면 한 그룹에서 특정 파티션을 읽을 때 그룹 단위로만 접근 가능하고, 파티션의 오프셋이 크면 읽지 안도록 한다.

4. 설계#

4.1. 데이터 저장소#

• 읽기와 쓰기가 빈번한데 갱신이나 삭제는 발생하지 않는다.
• 순차적인 읽기와 쓰기가 대부분을 차지한다.
• 데이터베이스로는 읽기/쓰기가 빈번한 환경의 패턴 지원이 어렵고 병목이 생길 수 있다.
• 쓰기 우선 로그(WAL)를 사용하여 문제를 해결할 수 있다.

  • 레코드가 순차적으로 쌓이며 세그먼트로 나눌경우 비활성 세그먼트는 읽기만 제공한다.

4.2. 생산자 측 작업 흐름#

• 메세지를 생산자가 버퍼에 보관 후 일관 전송하면 대역폭을 아낄 수 있다.

4.3. 소비자 측 작업 흐름#

• 푸시 방식

  • 장점 - 낮은 지연
  • 단점

    • 소비자 처리 속도가 생산자보다 느릴 경우 부하 발생 가능성
    • 생산자 전송 속도에 의존적
• 풀 방식

  • 장점

    • 소비 속도를 소비자가 알아서 결정 가능
    • 소비 속도가 생산 속도보다 느리면 해결하거나, 기다리거나 선택할 수 있다.
    • 일괄처리에 적합

      • 마지막 로그 위치부터 일괄적으로 가져와 공격적으로 처리 가능
  • 단점

    • 데이터가 없어도 계속 가져가려 해서 비용적 낭비 발생

      • 문제 극복을 위해 롱 폴링을 이용한다.
• 풀 모델이 더 많은 장점을 가지므로 풀 모델로 결정
• 코디네이터 = 같은 토픽을 구독하는 사용자 그룹을 관리하는 주체

  • 코디네이터는 소비자 신규/삭제/장애 모든 이벤트에 대응한다.

4.4. 규모 확장성#

• 생산자 = 독립적인 객체로 비교적 규모확장이 손쉽다.
• 소비자 = 코디네이터에 의해 소비자 그룹이 조정된다.
• 브로커 = 한시적으로 시스템 설정 파티션 수보다 허용 수를 늘려서 처리한다.

  • 브로커 장애는 다른 확인 후 다른 브로커의 리더를 선정 후 새로운 사본이 원본을 따라잡은 뒤 동작을 개시
• 파티션

  • 추가는 비교적 간단한데 추가 후 새로운 메시지가 쌓이면 된다.
  • 삭제는 사용자가 모두 사용 한 후 삭제하여 저장소를 반환한다.
  • 이 일렬의 과정에서 사용자들을 모두 리밸런싱한다.