Amazon MSK Express Kafka 트랜잭션 병목 분석 및 최적화 가이드

• Kafka 트랜잭션 사용 시 express.m7g.2xlarge 3대 클러스터에서 처리량이 네트워크 기준선의 64%에서 멈추는 현상 확인
• 병목 원인이 브로커 CPU나 네트워크가 아닌 코디네이터 왕복 및 __transaction_state 복제 ack 대기임을 실측으로 입증
• 트랜잭션 묶음 크기, 프로듀서 수, 클러스터 확장 순서로 조정해야 하며, 묶음 크기에 따라 scale out과 scale up의 효율이 달라짐
• 프로듀서를 두 배로 늘려도 처리량이 증가하지 않고 커밋 지연만 늘면 코디네이터 한도임을 판별할 수 있음

병목 진단 및 원인

• 커밋 경로에서 발생하는 고정 비용이 트랜잭션 묶음 크기와 무관하게 발생하여 처리량 상한을 결정함
• EndTxn 및 WriteTxnMarkers 처리 시간의 85~90%가 복제 ack 대기(RemoteTimeMs)로 측정됨
• 브로커 CPU 사용률이 44%로 낮고 네트워크 스로틀링이 없었음에도 처리량이 정체되는 이유를 설명

최적화 전략

• 트랜잭션 묶음 크기를 키워 커밋 고정 비용을 분산시키는 것이 비용 대비 효과가 가장 큼
• 프로듀서 수를 늘려도 처리량이 오르지 않는 지점은 코디네이터 한도이므로 묶음 크기 조정 후 확장 검토
• scale out 시 __transaction_state 파티션을 전 브로커에 분산해야 고부하 구간에서 최대 71%의 성능 손실을 방지할 수 있음
• 네트워크 한도, 코디네이터 한도, 클라이언트 한도 중 최소값을 기준으로 초기 사이징을 수행해야 함