3단계: 상세 설계
- 주요 개념
- 로테이션 디스크
- 수정하지 않는 메시지 저장 방식
- 일괄 처리 방식
데이터 저장소
- 메시지 큐의 데이터 패턴은 아래와 같다.
- 읽기와 쓰기가 빈번하게 발생한다.
- 갱신/삭제 연산은 발생하지 않는다.
- 전통적인 메시지 큐는 메시지가 적절히 소비되지 않는 경우를 제외하고 메시지를 지속 보관하지 않는다.
- 순차적인 읽기/쓰기가 대부분이다.
선택지 1: 데이터베이스
- 구현방식
- 관계형 데이터베이스를 사용해서 토픽별 테이블을 만든다.
- NoSQL 데이터베이스를 사용해서 토픽별 컬렉션을 만든다.
- 그러나 이와 같이 DB를 사용하는 방식은 이상적이지 않다.
- 읽기와 쓰기 연산이 동시에, 대규모로 발생하기 때문이다.
선택지 2: 쓰기 우선 로그(Write-Ahead Log)
- WAL은 쓰기만 하는(append-only) 일반 파일이다.
- MySQL의 복구 로그(redo log)나 주키퍼의 트랜잭션 로그 등이 이에 해당한다.
- 접근 패턴이 순차적일 때 디스크는 높은 성능을 보이므로 큐에 적합하다.
- 다만 파일이 계속해서 커질 수는 없으므로, 세그먼트(segment)로 나누어 관리한다.
- 세그먼트는 특정 크기에 도달하면 새로운 세그먼트로 교체된다.
- 활성 세그먼트에 쓰기를 하고, 비활성 세그먼트는 읽기만 한다.
- 오래된 비활성 세그먼트는 삭제된다.
디스크 성능 관련 유의사항
- 흔히 디스크는 느리다고 생각한다.
- 하지만 이는 랜덤 읽기/쓰기에 해당한다.
- 반면, 순차적 읽기/쓰기는 빠르다.
메시지 자료 구조
- 메시지 자료 구조 설계가 대역폭 달성에 중요하다.
- 생산자, 메시지 큐, 소비자 사이의 계약이다.
- 잘 설계된 메시지는 수정(복사)가 일어나지 않아 높은 대역폭을 달성할 수 있다.
메시지 키
- 메시지의 키는 파티셔닝에 사용된다.
- 그러나 키가 파티션 번호인것은 아니다.
- 이를 통해 후에 파티션이 추가/삭제되어도 메시지를 균등하게 분배 할 수 있다.
- 일반적으로 사용하는 키의 개념과는 다르다.
- 키를 바탕으로 조회나 검색을 하지 않으며, 고유성을 보장할 필요도 없다.
메시지 값
- 메시지 값은 메시지의 페이로드이다.
- 일반 텍스트일 수도 있고, 압축된 데이터일 수도 있다.
메시지의 기타 필드
- 키, 값 외에도 아래와 같은 필드가 존재 할 수 있다.
- 토픽(topic): 메시지가 속한 토픽의 이름
- 파티션(partition): 메시지가 속한 파티션의 ID
- 오프셋(offset): 파티션 내 메시지의 위치. 메시지는 토픽, 파티션, 오프셋을 알면 유일하게 식별 가능하다.
- 타임스탬프(timestamp): 메시지가 생성된 시간
- 크기(size): 메시지의 크기
- CRC(Cyclic Redundancy Check): 메시지의 무결성을 검증하는 체크섬
일괄 처리
- 생산자, 소비자, 메시지 큐에서 모두 일괄 처리를 적극적으로 사용한다.
- 이를 통해 대역폭을 향상시킬 수 있다.
- 네트워크 통신 오버헤드를 줄일 수 있다.
- 디스크 I/O를 줄일 수 있다.
- 더 큰 규모의 순차쓰기/순차읽기를 가능하게 한다.
- 하지만 더 큰 일괄처리를 위해 대기하는 시간으로 인해 지연시간이 발생한다.
생산자 측 작업 흐름
-
생산자가 특정 브로커에게 메시지를 보내기 위해 라우팅 계층이 필요하다.
-
라우팅 계층은 특정 토픽/파티션 내의 브로커의 상태를 확인하고, 리더 브로커에게 메시지를 전달한다.
-
리더 브로커는 메시지를 받고 자신을 따르는 다른 브로커에게 사본 메시지를 전달한다.
-
충분한 수의 브로커가 메시지를 받으면, 리더 브로커는 데이터를 디스크에 기록(commit)한다.
-
기록이 완료되면 메시지가 소비 가능한 상태가 되며, 생산자에게 응답을 보낸다.
-
여기서, 라우팅 계층을 생산자 내부로 넣고, 내부 버퍼를 마련하는 방식으로 개선할 수 있다.
- 이를 통해 네트워크 오버헤드를 줄일 수 있다.
- 버퍼를 통한 일괄 처리를 통해 대역폭을 향상시킬 수 있다.
소비자 측 작업 흐름
- 소비자는 특정 파티션의 오프셋을 바탕으로 메시지를 일괄적으로 가져온다.
안녕하세요!