들어가기 앞서
이전 포스팅까지는 카프카에 대한 기본 개념에 대해 알아보았습니다. 이번 포스팅부터는 기술에 대한 개념 보다는 운영환경에서 어떻게 활용하면 좋을지에 대해 알아볼 예정입니다. 책의 챕터 4에 해당하니 참고 해주시면 감사하겠습니다.
카프카에 대해 기본적인 공부를 위해 방문하신 분들은 아래 글 추천 드립니다.
카프카(kafka)에 대해 알아보자 - (1) 카프카의 기본 개념 (브로커, 토픽, 파티션, 레코드)
카프카(kafka)에 대해 알아보자 - (2) 카프카의 기본 개념 (프로듀서, 컨슈머)
https://www.yes24.com/product/goods/99122569
아파치 카프카 애플리케이션 프로그래밍 with 자바 - 예스24
아파치 카프카 애플리케이션 개발을 위한 「실전 가이드」아파치 카프카란 무엇일까? 카프카 애플리케이션은 어떻게 만들까? 데이터 파이프라인을 만들기 위해 어떤 카프카 라이브러리를 사용
www.yes24.com
토픽과 파티션
Kafka를 사용하는 것은 토픽을 만드는 것으로 시작되며, 삭제되면 해당 토픽의 데이터는 모두 사라지고 데이터 파이프라인도 중단됩니다. 즉, Kafka에서 토픽은 데이터 생명주기의 시작과 끝으로 매우 중요한 역할을 합니다.
파티션 개수 설정 시 고려사항
Kafka의 파티션은 병렬 처리의 핵심 단위로, 성능과 직결됩니다. 적절한 파티션 개수를 설정하기 위해 아래 세 가지를 반드시 고려해야 합니다.
1. 데이터 처리량
데이터 처리량이 많은 토픽이라면, 파티션을 늘려 병렬성을 확보해야 합니다. 예를 들어, 프로듀서가 초당 1000개의 메시지를 발행하고, 컨슈머가 초당 100개만 처리할 수 있다면 최소 10개의 파티션이 필요합니다. 이때 파티션 수만큼 컨슈머 스레드를 운영하면 병렬 처리를 극대화할 수 있습니다. 컨슈머의 성능은 서버 사양이나 GC 튜닝 등을 통해 개선할 수 있지만, 다른 시스템과의 연동 특성상 큰 성능 향상을 기대하기는 어렵습니다. 반면, 파티션 수를 늘려 병렬 컨슈머를 운영하는 것이 가장 현실적이고 효과적인 처리량 향상 방법입니다.
2. 메시지 키 사용 여부
메시지 키를 사용하는 경우, 데이터 순서를 보장받기 위해 동일 키는 항상 같은 파티션으로 보내야 합니다. 이때 파티션 수가 변경되면 키-파티션 매핑이 깨져 순서 보장이 어려워집니다. 따라서 메시지 순서를 중요하게 여긴다면 파티션 수 변경을 피해야 하며, 불가피한 경우 커스텀 파티셔너를 도입해야 합니다. 또한 처음부터 충분한 파티션 수를 확보해 두는 것이 바람직합니다. 반면, 순서 보장이 필요 없다면 이후 처리량 증가에 따라 파티션을 점진적으로 늘리는 것도 가능합니다.
3. 브로커와 컨슈머의 리소스 영향도
파티션 수가 많아지면 Kafka 브로커가 관리해야 할 파일 수가 늘어나고, 이는 OS의 파일 핸들 제한에 영향을 줄 수 있습니다. 브로커 1대당 파티션 수를 모니터링하며, 필요 시 브로커 수를 늘려 파티션 부하를 분산하는 전략이 필요합니다.
토픽 정리 정책 (cleanup.policy)
Kafka는 토픽 데이터를 보존하거나 삭제하는 방식에 대해 설정할 수 있습니다. 데이터를 장기간 보존할 수도 있고, 저장소 절약 및 비용 절감을 위해 정기적으로 삭제할 수도 있습니다.
Kafka는 클러스터가 유지되는 한 데이터를 삭제하지 않도록 설정할 수 있습니다. 이 경우, 과거 데이터를 오프셋을 이용해 일주일 혹은 한 달 이상 지난 시점으로도 다시 조회할 수 있습니다. 그러나 데이터를 장기간 삭제하지 않으면 저장소 사용량이 지속적으로 증가하게 되고, AWS MSK나 EC2 EBS 등에서는 비용이 동반 상승하게 됩니다.
따라서 불필요한 데이터를 정리하고 싶다면 cleanup.policy 옵션을 활용해 데이터를 자동으로 삭제할 수 있습니다. Kafka는 cleanup.policy 옵션으로 다음 두 가지 정책을 제공합니다:
1. 삭제 정책 (delete)
Kafka의 기본 정책으로, 대부분의 일반적인 토픽에 설정됩니다. 지정된 보존 시간(retention.ms)이나 용량(retention.bytes)을 초과한 데이터는 세그먼트 단위로 삭제됩니다.
- 세그먼트란?
- 토픽 파티션별로 생성되는 물리적인 저장 단위입니다.
- 파일 이름은 해당 세그먼트의 최소 오프셋으로 지정됩니다.
- 세그먼트 크기는 segment.bytes로 설정하며, 이를 초과하면 새로운 세그먼트가 생성됩니다.
- 현재 데이터를 저장 중인 세그먼트를 ‘액티브 세그먼트’라고 부릅니다.
- 삭제 시점
- Kafka는 주기적으로 세그먼트의 마지막 수정 시간과 retention.ms를 비교해, 초과된 세그먼트를 삭제합니다.
- 또한 전체 토픽 데이터의 크기가 retention.bytes를 초과하면 가장 오래된 세그먼트부터 삭제됩니다.
삭제된 데이터는 복구가 불가능하므로 중요한 데이터는 별도 저장소에 보관하거나 백업 정책을 운영해야 합니다.
2. 압축 정책 (compact)
Kafka에서 말하는 '압축'은 zip, tar 등 압축 포맷이 아니라, 메시지 키 기준으로 오래된 데이터를 삭제하고 최신 값만 유지하는 전략입니다. 예를 들어, 오프셋 4, 5, 6에 동일한 키가 존재한다면, 가장 최신 오프셋(6)의 레코드만 남기고 이전 레코드(4, 5)는 삭제됩니다. 따라서 파티션의 오프셋 순서와 무관하게 특정 메시지 키의 최신 상태만 유지됩니다.
이 정책은 Kafka Streams의 KTable처럼 키 기반 상태를 관리해야 하는 토픽에 유용합니다. 데이터 흐름보다 키의 최신 상태가 중요한 경우, 불필요한 데이터를 줄이고 저장소를 효율적으로 사용할 수 있습니다.
- 압축 적용 대상
- 압축은 액티브 세그먼트를 제외한 나머지 세그먼트에 대해서만 수행됩니다.
- 압축 시작 기준: min.cleanable.dirty.ratio
- 클린 로그(중복 제거된 영역)와 더티 로그(압축 전 영역)의 비율을 의미합니다.
- 비율이 클수록 압축은 드물게 일어나며, 적게 설정하면 자주 일어납니다.
예: 클린 3개, 더티 3개일 경우 비율은 0.5입니다. 이 비율이 설정값을 넘어서야 압축이 수행됩니다.
- 운영 팁
- 값이 높으면 압축 효과는 크지만 저장 공간을 오래 점유할 수 있습니다.
- 값이 낮으면 자주 압축이 발생해 최신 상태를 빠르게 유지할 수 있지만 브로커에 부하가 생길 수 있습니다.
따라서 토픽의 특성과 사용 패턴에 따라 적절한 압축 설정이 필요합니다.
ISR (In-Sync Replicas)
ISR은 리더 파티션과 데이터가 완전히 동기화된 팔로워 파티션들의 집합입니다. 동기화란, 리더 파티션의 최신 오프셋까지 모든 데이터를 팔로워가 복제한 상태를 의미합니다.
예를 들어, 리더에 0~3번 오프셋이 있을 때 팔로워도 0~3번 오프셋을 모두 갖고 있어야 동기화된 것으로 간주됩니다. 이런 동기화가 완료된 상태에서는 리더나 팔로워 중 하나의 브로커에 장애가 발생하더라도 데이터 유실 없이 안전하게 서비스를 운영할 수 있습니다.
ISR이 중요한 이유
팔로워 파티션은 리더로부터 데이터를 복제하는 데 일정한 지연이 존재합니다. Kafka는 replica.lag.time.max.ms라는 설정을 통해 이 지연을 감시합니다. 만약 팔로워가 해당 시간 내에 리더 데이터를 복제하지 못하면, ISR에서 제외됩니다. 이는 싱크되지 않은 팔로워가 리더로 승격되는 위험을 방지하기 위함입니다.
리더 선출 조건과 설정
Kafka는 리더 브로커에 장애가 발생했을 경우, 새로운 리더를 선출해야 합니다. 이때 중요한 설정이 unclean.leader.election.enable입니다.
- false: ISR에 포함되지 않은 팔로워는 리더가 될 수 없습니다. 데이터 유실은 없지만, 리더 브로커가 복구될 때까지 서비스가 중단됩니다.
- true: 동기화되지 않은 팔로워도 리더가 될 수 있습니다. 서비스 중단은 방지할 수 있지만, 일부 데이터가 유실될 수 있습니다.
운영 정책에 따른 선택
- 데이터 무결성이 더 중요할 경우: false로 설정
- 서비스 무중단이 우선일 경우: true로 설정
운영 환경에 따라 이 설정을 적절히 선택해야 하며, 서비스 특성상 데이터 유실이 치명적이라면 false로, 반대로 고가용성이 필수라면 true를 고려해야 합니다.
'Kafka, RabbitMQ' 카테고리의 다른 글
| 카프카(kafka)에 대해 알아보자 - (5) 카프카 딥다이브 (프로듀서, 컨슈머) (2) | 2025.05.28 |
|---|---|
| 카프카(kafka)에 대해 알아보자 - (2) 카프카의 기본 개념 (프로듀서, 컨슈머) (0) | 2025.05.27 |
| 카프카(kafka)에 대해 알아보자 - (1) 카프카의 기본 개념 (브로커, 토픽, 파티션, 레코드) (0) | 2025.05.23 |
| 카프카(kafka)에 대해 알아보자 (0) | 2025.05.23 |
| RabbitMQ에 대해 알아보자 - (12) Producer 트랜잭션 전략 (0) | 2025.05.20 |
