- replication 개념
- kafka 기반 대용량 MSA 실시간 스트리밍
- 파티션, 컨슈머
참고링크 : kafka overview > 1) data producer & consumer test
[개념]
아파치 카프카는 실시간으로 레코드의 스트림을 게시, 구독, 저장, 처리할 수 있는 분산 데이터 스트리밍 플랫폼입니다.
다양한 소스에서 데이터 스트림을 처리하고 여러 컨슈머에게 전달하기 위해 설계되었습니다.
간단히 말해서, 카프카는 단순히 A지점에서 B지점으로 데이터를 이동시키는 것뿐 아니라 A지점에서 Z지점과 필요한 모든 곳으로 동시에 대규모 데이터를 이동시킬수 있습니다.
아파치 카프카는 전통적인 엔터프라이즈 메시징 시스템의 대안이며, 이제는 다양한 엔터프라이즈 요구 사항에 적용 가능한 오픈 소스 데이터 스트리밍 솔루션으로 사용 되고 있습니다.
스트리밍 데이터
스트리밍 데이터는 실시간 정보의 지속적인 흐름이자 이벤트 기반 아키텍처(event driven architecture) 소프트웨어 모델의 기반입니다.
현대적인 애플리케이션은 스트리밍 데이터를 사용하여 데이터를 처리, 저장, 분석합니다.
스트리밍 데이터는 데이터 세트에 발생한 변경 사항이나 이벤트의 실행 로그(대개 매우 빠른 속도로 변경됨)라고 볼 수도 있습니다.
빠르게 이동하는 대규모 데이터 세트로서 스트리밍 데이터의 소스일 수 있는 경우는 금융 거래, 사물 인터넷(IoT) 센서 데이터, 물류 운영, 소매 주문 또는 병원 환자 모니터링 등 다양합니다.
차세대 메시징처럼 데이터 스트리밍은 이벤트에 대한 실시간 응답이 필요한 상황에 적합하다고 할 수 있습니다.
Kafka를 통한 비동기식 통합
마이크로서비스(Microservices)는 개발 환경을 바꾸어 놓았습니다.
공유 데이터베이스 계층과 같은 종속성을 줄여 개발자들이 더욱 민첩하게 작업을 수행하도록 해줍니다.
그러나 개발자가 구축 중인 분산형 애플리케이션이 데이터를 공유 하려면 특정한 유형의 통합 환경이 필요합니다.
널리 사용되는 통합 옵션으로 동기식 방법이 있는데, 이는 서로 다른 사용자 간 데이터를 공유하는 데 애플리케이션 프로그래밍 인터페이스(API)를 활용합니다.
또 다른 통합 옵션으로는 중간 데이터 스토어에 데이터를 복제하는 비동기식 방법이 있습니다.
Apache Kafka는 바로 이런 맥락에 등장하는 솔루션으로, 다른 개발팀의 데이터를 스트리밍하여 데이터 스토어를 채우면 해당 데이터를 여러 팀과 이들의 애플리케이션 간에 공유할 수 있게 됩니다.
아파치 카프카 구성 요소
- Producer : 데이터를 Kafka 클러스터에 보내는 역할을 합니다. 애플리케이션에서 이벤트나 메시지를 생성하고 이를 특정 주제(Topics)로 전송합니다.
- Broker : Kafka 클러스터 내의 서버를 의미합니다. 이들은 Producer로부터 데이터를 받고, 이를 저장한 후 Consumer에게 제공합니다. 각 Broker는 클러스터의 일부로 기능하며, 데이터 분산 및 복제를 통해 높은 가용성을 유지합니다.
- Topic : 메시지를 구분하는 논리적인 채널입니다. 데이터를 카프카 클러스터에 저장할 때, 각 메시지는 특정 주제에 연관되어 있어야 합니다.
- Partition : 각 Topic은 여러 개의 Partition으로 나눌 수 있으며, 이로 인해 데이터의 병렬 처리가 가능해집니다. Partition은 메시지 순서를 보장하고, 각 Partition은 하나의 Broker에 저장됩니다.
- Consumer : 카프카 클러스터에서 데이터를 읽는 애플리케이션입니다. Consumer는 Topic을 구독하여 메시지를 읽고 처리합니다.
- Consumer Group : 여러 개의 Consumer가 함께 작동하여 특정 Topic의 메시지를 분산 처리할 수 있게 합니다. 각 Partition은 한 Consumer에만 할당되어 메시지 처리를 중복하지 않도록 합니다.
- Zookeeper: 카프카 클러스터의 메타데이터와 상태를 관리하는 데 사용됩니다. Broker의 동작 및 클러스터 상태를 관리하며, Failover 및 구성을 조정합니다.
리더와 팔로워
Replication은 토픽 단위로 동작하는 것이 아닌 파티션 단위로 동작한다는 것을 꼭 기억해야한다. 각 파티션의 복제본들은 서로 다른 브로커에 위치한다. 파티션의 원본을 리더, 복제본을 팔로워라고 부르며 각 파티션 마다 존재한다. 필자는 Kafka replication 개념을 처음 공부할 때, 3개의 파티션이 있을 때 (0, 1, 2) 0번 파티션의 팔로워가 1, 2번 파티션이라고 헷갈리곤 했는데, 0, 1, 2는 서로 독립적이며 모두 각자의 팔로워를 가진다는 것을 꼭 기억하자.
만약 N개의 노드, N개의 replication이 있다고 가정하면, N-1까지의 브로커 장애에도 tolerant 하다. 이를 가능케 하는 것이 리더와 팔로워이다.
Kafka에서는 동일한 복제본들을 리더와 팔로워로 구분함으로서, 서로 다른 역할을 분담시킨다.
복제본 중 하나가 리더로 선출되며, 모든 읽기와 쓰기는 리더를 통해서만 가능하다. 다시말해, 프로듀서와 컨슈머는 파티션 리더로 부터만 읽기와 쓰기를 요청하는 것이다.
Kafka의 replication(복제)은 데이터의 신뢰성과 고가용성을 높이기 위해 토픽의 각 파티션 데이터를 여러 브로커에 복제하는 역할을 합니다 1.
Kafka 복제의 주요 역할
- 데이터 내구성: 파티션의 데이터를 다수의 브로커에 복제하여 하나의 브로커가 장애가 발생해도 다른 브로커에 동일한 데이터를 유지함으로써 데이터 유실을 방지합니다.
- 고가용성 구현: 파티션의 리더 브로커가 다운되면, 복제본을 가진 다른 브로커가 새로운 리더가 되어 서비스가 중단 없이 계속 운영될 수 있습니다.
- 복제본 관리: 각 파티션은 'replication factor' 설정에 따라 여러 복제본을 유지하며, 리더와 팔로워로 역할이 나뉩니다. 리더는 클라이언트 요청을 담당하고, 팔로워는 리더의 데이터를 실시간 복제합니다.
- 관점 정리
- 장애 복구: 리더 브로커가 장애로 인해 사용할 수 없게 되면, ISR(In-Sync Replica, 동기화된 복제본) 내에서 다음 리더가 자동으로 선출됩니다.
- 확장성: 복제본 수를 조절함으로써 필요한 수준에 따라 장애 허용 범위나 분산 저장 전략을 유연하게 운영할 수 있습니다.
정리
Kafka의 replication은 데이터 유실을 막고, 장애 발생 시 빠른 복구를 지원해 서비스 연속성을 확보하는 핵심 기능입니다.
Replication
카프카 아키텍쳐의 핵심.
클러스터에서 서버가 장애가 생겼을 때, 카프카의 가용성을 보장하는 가장 좋은 방법이 복제이기 때문이다.
그렇다면 Replication은 무엇일까? Replication은 파티션의 복제를 뜻한다.
Replication이 1이라면 파티션은 1개만 존재한다는 것이고, 2라면 파티션은 원본 한개와 복제본 1개로 총 2개가 존재한다.
Replication이 3이라면 원본1+복제본2로 총 3개가 존재한다.
다만 브로커 개수에 따라 Replication 개수도 제한이 된다. 브로커 개수가 3개이면 Replication은 4가 될 수 없다.
원본1개의 파티션을 Leader Partition, 나머지 2개의 파티션은 Follower Partition이라 부른다.
이 Leader, Follower Partition을 합쳐서 ISR(In Sync Replica)이라 부른다.
그렇다면 왜 Replication을 사용할까? Replication은 파티션의 고가용성을 위해 사용한다.
만약 브로커가 3개인 카프카에서 Replication이 1이고 Partition이 1인 topic이 존재한다고 가정해 보자. 갑자기 브로커가 어떠하 이유로 사용불가하게 된다면 해당 파티션은 복구가 불가능하다. 하지만 Replication이 2라면 브로커 1개가 죽더라도 복제본, 즉 Follower Partition이 존재하므로 복제본으로 복구가 가능하다. 나머지 1개가 남은 Follower Partition이 Leader Partition 역할을 승계하게 되는 것이다.
Replication이 고가용성을 위해 중요한 역할을 한다면 Replication이 많을수록 좋은게 아니냐는 생각을 할 수 있다. 하지만 Replication이 많아지면 많아질수록 브로커의 리소스 사용량도 늘어나게 된다. 따라서 카프카에 들어오는 데이터량과 Retention Date(저장시간)을 잘 생각해서 Replication 개수를 정하는 것이 좋다. 예를 들어, 3개 이상의 브로커를 사용한다면 Replication의 개수는 3으로 설정하는 것이 좋다.
카프카에는 다양한 데이터가 들어갈 수 있는데, 그 데이터가 들어가는 공간을 토픽이라 한다.
카프카에서는 토픽을 여러 개 생성할 수 있다. 토픽은 데이터베이스의 테이블이나 파일시스템의 폴더와 유사한 성질을 가지는데, 이 토픽에 프로듀서가 데이터를 넣게 되고, Consumer는 데이터를 가져가게 된다.
토픽은 이름을 가질 수 있는데, 목적에 따라 무슨 데이터를 담는지(click_log, send_sms, location_log) 명확하게 명시하면 추후 유지보수 시 편리하게 관리할 수 있다.
하나의 토픽은 여러 개의 파티션으로 구성될 수 있으며, 첫번째 파티션 번호는 0번부터 시작한다.
하나의 파티션은 큐와 같이 내부에 데이터가 파티션 끝에서부터 쌓이게 된다.
이후 Consumer가 붙으면 데이터를 가장 오래된 순서대로 가져가게 된다. 더 이상 데이터가 들어오지 않으면 Consumer는 또 다른 데이터가 들어올 때까지 기다린다.
이때 중요한 점은, Consumer가 record를 가져가도 데이터는 삭제되지 않는다. 파티션에 그대로 남는 것이다. 그렇다면 파티션에 남은 데이터는 누가 가져갈까? 만약 새로운 Consumer가 붙는다면 다시 0번부터 가져가서 사용할 수 있다. 다만 Consumer 그룹이 달라야 하고, auto.offset.reset=earliest라는 추가 설정이 필요하다. 이렇게 설정하면 동일 데이터에 대해 두번 처리할 수 있는데, 이는 카프카를 사용하는 아주 중요한 이유이기도 하다.
예를 들어 한 파티션 내 동일 데이터들에 대해 한 Consumer는 Elastic Search에 저장하기도 하고, 백업을 위해 Hadoop에 저장할 수 도 있다.
이제 한 토픽 내 파티션이 2개 이상인 경우에 대해 알아보자.
예를 들어 데이터 7이 토픽에 들어가야 하는데, 사실 Producer가 데이터를 보낼 때 키를 지정할 수 있다.
1) 키가 null이고, 기본 파티셔너 사용할 경우
-> round robin으로 할당
2) 키가 있고, 기본 파티셔너 사용할 경우
-> 키의 해시(hash)값을 구하고, 특정 파티션에 할당
파티션 설정 시 조심해야 할 점은, 파티션은 늘릴 순 있지만 줄일수는 없다는 점이다.
그렇다면 파티션을 늘릴 때는 언제일까? 바로 Consumer의 개수를 늘려서 데이터 처리를 분산시킬 수 있을때이다.
그렇다면 파티션의 데이터는 언제 삭제될까? 옵션에 따라 달라진다. record가 저장되는 최대 시간과 크기를 지정할 수 있다.
log.retention.ms : 최대 record 보존 시간 log.retention.byte : 최대 record 보존 크기(byte)
참고링크(브로커와 컨슈머 갯수 설계 관련) :
출처 : https://hoing.io/archives/4907
출처 : https://m.blog.naver.com/jyk2367/223091449545
출처 : https://m.blog.naver.com/jyk2367/223091422468?recommendTrackingCode=2
카프카는 대용량의 데이터를 실시간으로 처리하고 분산하는 분산 스트리밍 플랫폼이에요. 특히 여러 애플리케이션이나 시스템 간에 데이터를 이벤트(event) 형태로 주고받을 때 사용돼요.
카프카의 핵심 개념
카프카는 데이터를 저장하고 주고받는 데 필요한 3가지 핵심 개념을 가지고 있어요.
- 프로듀서 (Producer) ✍️
- 데이터를 만드는 주체예요.
- 예를 들어, 웹사이트에서 사용자가 '구매하기' 버튼을 누르면, 이 행위가 '주문 이벤트'가 되어 카프카로 전송돼요.
- 프로듀서는 이 이벤트를 카프카의 특정 토픽에 보내는 역할을 해요.
- 컨슈머 (Consumer) 👂
- 카프카에 저장된 데이터를 가져와서 사용하는 주체예요.
- 예를 들어, '주문 이벤트'를 필요로 하는 '재고 관리 시스템', '배송 시스템', '결제 시스템' 등이 모두 컨슈머가 될 수 있어요.
- 컨슈머는 자신이 구독한 토픽의 데이터를 가져와서 처리해요.
- 토픽 (Topic) 📁
- 데이터가 저장되는 공간이에요.
- 프로듀서가 데이터를 보낼 때, "이건 '주문'에 관한 데이터야"라고 지정해주는 데이터 분류 체계예요.
- 컨슈머는 자신이 관심 있는 토픽만 구독해서 데이터를 가져가요.
카프카의 작동 방식
카프카의 데이터 흐름은 메시지를 보내는 사람(프로듀서)과 받는 사람(컨슈머)이 직접 연결되지 않는다는 특징이 있어요.
- 프로듀서가 데이터를 토픽에 보냄: 프로듀서는 데이터를 직접 컨슈머에게 보내는 것이 아니라, 카프카 클러스터에 있는 특정 토픽에 데이터를 보관해요.
- 데이터 저장: 카프카는 프로듀서가 보낸 데이터를 순서대로 로그(log) 형태로 저장해요. 이 데이터는 컨슈머가 가져간 후에도 일정 기간 보관돼요.
- 컨슈머가 데이터를 가져감: 컨슈머는 자신이 필요한 토픽에서 데이터를 꺼내 읽어가요. 여러 컨슈머가 동시에 같은 토픽의 데이터를 읽을 수도 있어요.
카프카의 장점
- 대용량 데이터 처리: 초당 수백만 건의 이벤트를 처리할 수 있는 높은 처리량을 자랑해요.
- 높은 확장성: 서버(브로커)를 수평적으로 늘리면 시스템 용량을 쉽게 확장할 수 있어요.
- 데이터 보존: 데이터를 일정 기간 보관하기 때문에, 컨슈머가 데이터를 놓치더라도 나중에 다시 읽을 수 있어요.
쉬운 비유로 이해하기
카프카는 택배 물류 시스템과 비슷하다고 생각하면 쉬워요.
- 프로듀서는 택배 기사예요. 상품(데이터)을 들고 와서 특정 분류(토픽)에 넣어두죠.
- 토픽은 물류 창고의 분류된 구역이에요. "여기는 옷", "여기는 신발"처럼요.
- 컨슈머는 택배를 받는 고객이에요. "나는 옷만 받아갈 거야"라고 하면 옷 구역에 있는 물건만 가져가요.
이 시스템에서 택배 기사(프로듀서)와 고객(컨슈머)은 직접 만나지 않아요. 물류 창고(카프카)라는 중간 지점을 통해 효율적으로 데이터를 주고받는 거죠.
'기타' 카테고리의 다른 글
| 38. VMware (2) | 2025.08.30 |
|---|---|
| 33. Redis (2) | 2025.08.30 |
| 47. 통합가시성 (0) | 2025.08.29 |
| 46. Cloud 비용 최적화 (0) | 2025.08.29 |
| 45. Azure Temporary disk (0) | 2025.08.29 |