제 3의 그룹이 토픽이 필요할때 만들고 더 이상 니즈가 없으면 컨슈머 삭제하고 토픽도 삭제.
레코드 안에 타임 스탬프를 기록하여 병렬 처리 하여도 타임 스탬프 순서로 처리.
파티션은 기본적으로 3개 사용 하지만 컨슈머 랙에 따라 파티션을 늘림. 파티션을 늘리는 일은 큰 일이다. 리밸런스에 영향을 주고 줄이는 것도 안된다.
중단되고 다시 켜지는 동안 컨슈머 랙이 발생할 수 밖에 없다. 이 컨슈머 랙이 얼마정도 될 수 있는지 메시지 로드가 얼마정도 걸리는지 한계 사항을 정하고 처리한다. 또는 무중단 배포도 고려.
서버와 클라이언트 간의 네트워크 통신. 클라이언트 CPU/RAM. 카프카 배치 옵션등, ...
다양한 환경을 바꿔가며 테스트가 필요하다.
클라이언트에서 커밋을 하려고 하는데 브로커가 죽음 -> 커밋 못함 -> 클라이언트가 중복 처리될 수 있음.
고려 사항
서버에서 아무리 처리를 잘 하여도 클라이언트 쪽에서도 중복 처리 되는 경우를 고려해야함.
- 클라이언트 내부적으로 메모리를 유지하는 방법 있음.
로그를 잘 남겨서 카프카 처리 상태를 잘 기록 해야함. 외부 모니터링도 사용하여 모니터링도 잘 해야함.
- 단 브로커나 컨슈머가 제대로 실행중이라는 가정으로.
카프카 클라이언트와 브로커가 동일 서버에 돌아가는 경우는 거의 없음
- 카프카 클라이언트 : 레코드를 polling 하는 프로세스/서버
카프카 클라이언트 역할만 수행하는 서버를 따로 두기도 한다. 카프카 클라이언트를 수행하는 서버에서 비즈니스 로직까지 같이 수행하면 모니터링시 비즈니스 로직 문제인지 카프카 문제인지 혼동될 수 있음.
mohadang