프로듀서 서버 실행시키고, 컨슈머 서버 두 대 중 Consumer-0의 서버만 실행시켜보자.
컨슈머 서버 로그 확인하기
컨슈머 서버 로그를 자세히 살펴보면 Consumer-0의 서버가 파티션 0, 1, 2에 할당된 걸 알 수 있다. 즉, Consuemr-0의 서버가 파티션 0, 1, 2에 있는 메시지들을 전부 처리한다.
** email.send- 뒤에 붙어있는 숫자가 파티션 번호이다.
API 요청 보내면서 컨슈머 서버 로그 확인하기
API 요청을 연속으로 세 번 보낸 뒤에 컨슈머 서버의 로그를 확인해보자.
하나의 컨슈머 서버가 파티션 3개에 할당되어 있다고 하더라도, 컨슈머 서버는 한 번에 하나의 작업만 처리하는 걸 확인할 수 있다. 여러 작업을 병렬적으로 처리하지 않으니 3개의 메시지를 처리하는 데 비교적 시간이 오래걸리는 걸 확인할 수 있다.
그럼 메시지를 병렬적으로 처리하기 위해 컨슈머 서버를 하나 더 띄워보자.
컨슈머 서버 추가로 띄우기
컨슈머 서버 두 대 중 Consumer-1의 서버를 추가로 실행시키자.
Consumer 서버 로그 확인하기
Consuemr 서버 로그를 자세히 살펴보면 Consumer-0의 서버가 파티션 0, 1의 메시지를 처리하고,Consuemr-1의 서버가 파티션 2에 있는 메시지를 처리하게끔 바뀌었다. Consumer 서버 대수에 맞게 알아서 파티션을 분배했다.
API 요청 보내면서 컨슈머 서버 로그 확인하기
API 요청을 연속으로 3번 보낸 뒤에 컨슈머 서버의 로그를 확인해보자.
2개의 컨슈머 서버가 토픽의 메시지를 병렬적으로 처리하는 걸 확인할 수 있다. 컨슈머 서버가 하나일 때보다 훨씬 효율적으로 처리한다는 걸 알 수 있다.
✅ 그림으로 이해하기
파티션이 하나 였을 때는 컨슈머 서버가 여러 대이더라도 소용이 없었다. 왜냐하면 하나의 파티션은 하나의 컨슈머 서버에서만 담당해서 처리할 수 밖에 없기 때문이다. 그래서 아래 그림과 같이 파티션을 늘렸다.
파티션을 늘리면 각 컨슈머가 담당할 수 있는 파티션이 생기기 때문에 메시지를 병렬적으로 처리할 수 있게 되기 때문이다. 대형 마트에 비유를 하자면, 계산할 수 있는 카운터가 많을수록 계산을 기다리는 손님을 훨씬 빠르게 처리할 수 있는 것과 같다.
하지만 여기서 아쉬운 점이 있다.
하나의 컨슈머 서버가 메시지를 처리할 때 사용하는 리소스(CPU, 메모리 등)가 부족한 상태라면 다른 컨슈머 서버를 늘리는 게 맞다. 하지만 이번 실습에서는 메일 작업 하나가 무거운 작업도 아닐 뿐더러, 하나의 컨슈머 서버의 리소스(CPU, 메모리 등)가 부족한 상태도 아니었다.
그래서 다음 강의에서는 컨슈머 서버를 늘리지 않고 여러 파티션의 메시지를 병렬적으로 처리하는 방법에 대해 알아보자.
