데브옵스
Amazon MSK Express Broker에서 Kafka 트랜잭션 워크로드를 최적화하는 방법
두줄요약
MSK Express의 Kafka 트랜잭션 병목을 네트워크·코디네이터·클라이언트 한도로 분석했습니다.\n묶음 크기와 프로듀서 수를 먼저 조정하고 병목별 확장 전략을 제시했습니다.
문제 상황
- Amazon MSK Express Broker의 네트워크 기준선만으로 예측하기 어려운 Kafka 트랜잭션 처리량
- 작은 트랜잭션 묶음에서 CPU·네트워크 여유에도 코디네이터 한도에 막히는 현상
구조와 흐름
__transaction_state복제 ack, 참여 파티션의 control record 기록을 포함한 커밋 경로- 네트워크·코디네이터·클라이언트 한도 중 최솟값으로 결정되는 클러스터 처리량
commitTransaction()동기 대기와 묶음 크기÷커밋 지연으로 산정되는 프로듀서 처리량
트레이드오프
- 묶음 크기 확대로 커밋 고정비용 분산 및 처리량 향상
- 큰 묶음에 따른 read_committed 지연 증가, 실패 시 재처리 범위 확대, 업무 단위 제약
- 작은 묶음의 코디네이터 병목에는 scale out, 큰 묶음의 네트워크 병목에는 scale up 선택
성능/운영 포인트
- 프로듀서 수 증가 시 처리량과 커밋 지연을 함께 측정해 최적 동시성 탐색
- scale out 이후
__transaction_state파티션 재배치로 코디네이터 부하 분산 - CloudWatch 네트워크·CPU와 애플리케이션의 커밋 수·P50/P99 지연 동시 모니터링
