일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
31 |
- Oracle 사용자명
- ora-01722
- Oracle 사용자명 입력
- 무료 오라클 설치
- Oracle 18c 설치
- Oracle 18c HR schema
- ORA-00922
- Orace 18c
- Oracle 테이블 띄어쓰기
- oracle
- 오라클 캐릭터셋 확인
- Oracle Express Edition
- Oracle 윈도우 설치
- 서평단
- oracle 18c
- 윈도우 Oracle
- 무료 오라클 데이터베이스
- 비전공자를 위한 데이터베이스 입문
- 오라클 캐릭터셋 조회
- Oracle 18c HR
- Oracle 테이블 대소문자
- ORA-12899
- 오라클 캐릭터셋 변경
- Oracle 초기 사용자
- Today
- Total
The Nirsa Way
[Apache Kafka] 카프카의 핵심 요소 (Topic, Partition, Offset, Consumer Group, KRaft, Replication, Durability) 본문
[Apache Kafka] 카프카의 핵심 요소 (Topic, Partition, Offset, Consumer Group, KRaft, Replication, Durability)
KoreaNirsa 2025. 7. 18. 13:19
카프카의 핵심 요소
카프카의 핵심 요소는 크게 Topic, Partition, Offset, Consumer Group, KRaft, Replication, Durability으로 구성되어 있습니다.
1. Topic
메시지를 분류하는 논리적 단위입니다. 생산자는 Topic에 메시지를 발행(Publish) 하고, 소비자는 Topic을 구독(Subscribe)하여 메시지를 가져갑니다.
2. Parttion, Offset
각각의 Topic은 여러 개의 Partition으로 분할되어 병렬 처리가 가능합니다. Partition은 메시지를 물리적으로 저장하는 단위로써 메시지는 파티션 내에서 Offset을 기준으로 정렬됩니다.
또한 Offset은 파티션 내 메시지의 고유한 순번으로써 Consumer는 각 partition에 대해 어디까지 읽었는 지 Offset을 추적합니다. Kafka는 Consumer의 Offset을 Kafka 내부에 저장하여 사용합니다.
만약 Producer 1,2,3이 각각 Topic에 메시지를 보냈다고 생각해 봅시다.
이후 특정 로직에 따라 메시지를 각 파티션에 저장합니다.
위의 부분에서 Key 기반과 Round-Robin 방식으로 나뉘게 되는데, Key 기반은 Producer가 보낸 데이터에 Key가 있다면 "해당 Key % Partition의 수"를 한 결과 값으로 1이 나오면 Partition 1, 2가 나오면 Partition 2로 저장됩니다. 이후 Consumer가 각 파티션의 메시지를 읽고 처리하게 됩니다.
이렇게 Key 기반을 사용하게 되면 동일한 Key에 의해 다음 메시지도 같은 Partition으로 저장되기 때문에 순서가 보장되어 일반적으로 많이 사용되는 방식입니다. 단, 특정 파티션으로 쏠리는 현상이 발생할 수 있습니다.
반대로 만약 Key가 존재하지 않는다면 Round-Robin 방식을 사용하게 되는데 파티션에 랜덤으로 분배하기 때문에 순서가 보장되지 않는 단점이 존재합니다.
그 외 Custom Partitioner를 사용하여 원하는 파티션에 저장될 수 있도록 하는 방법도 존재합니다.
※ Key와 Value
Producer가 메시지를 보낼 때 Key, Value를 보내게 되는데 Value는 데이터를 생각하시면 됩니다. Key의 경우 Kafka는 같은 Key는 같은 Partion으로 보내서 메시지 순서를 보장하므로 동적인 값이 아니라 사용자 ID, 주문 ID, 장바구니 ID와 같은 고유한 값을 가진 정보를 Key에 담아 보냅니다.
3. Consummer Group
여러 Consummer를 하나의 그룹(Consummer Group)으로 묶으면 카프카는 해당 그룹 안의 Consummer들 간에 파티션을 나눠 처리하게 됩니다. 하나의 메시지는 하나의 Consummer Group으로 들어가며 해당 메시지는 그룹에 포함되는 단 하나의 Consummer에게만 전달되며 이로 인해 그룹 단위의 병렬 처리를 처리할 수 있습니다.
이로 인해 동일 그룹 내에서 중복으로 볼 수 없으므로 하나의 메시지를 여러 Consummer가 보려면 여려 개의 Cosunmmer Group을 구성해야 합니다.
4. KRaft
Kafka Broker의 메타데이터(컨트롤러 선출, Topic 정보 등)를 관리하며 3.x 이후 KRaft가 도입되었습니다. KRaft는 자체 내부 메타데이터 로그 및 컨트롤러를 통해 동작합니다.
KRaft Controller Conde라는게 존재하는데 이는 "Kafka 클러스터의 메타데이터 전체를 관리하는 노드"를 의미합니다. 이중 Raft 알고리즘으로 선출된 리더(Leader)가 모든 Topic과 Partion 등의 메타 데이터를 최종적으로 관리하는 역할을 수행합니다.
리더로 선출되지 않은 노드들은 Follower로 동작하여 리더의 메타데이터를 복제하고 Hot Strandby합니다.
해당 과정에서 조금 더 설명을 포함하면 Controller가 Partion을 Broker에 배치하며 (배치 기록은 Raft Log에 기록) 각 Broker는 자신에게 할당된 Partion을 생성합니다.
5. Replication
각 Partition의 데이터를 여러 Broker에 복제본(Replica) 형태로 저장하는 것을 말합니다. 복제본 중 하나는 Leader로 지정되어 읽기 및 쓰기를 담당하며 나머지 복제본은 Follower로 동작하여 Leader의 데이터를 실시간으로 동기화 합니다. 만약 Leader에게 장애가 발생하면 Controller가 새로운 리더를 선출하여 클러스터가 정상적으로 동작할 수 있도록 합니다.
6. Durability
기록된 메시지가 손실되지 않고 안전하게 저장되는 특성을 가지며 DUrability를 보장하는 메커니즘은 Log 파일 기반 저장, REpl;ication, acks 설정 등을 통해 관리 됩니다.
마무리 및 구조 파악
최종적으로 정리하면 아래와 같은 구조를 가지게 됩니다. KRaft Controller의 경우 리더가 모든 메타 데이터 변경 사항(Topic 생성, Partition 배치 등)에 대해 Leader가 처리하며 Raft Log에 기록하게 되는데, Follower Controller들은 해당 로그를 보고 메타데이터를 복제합니다.
또한 Kafka Broker Nodes는 실제 데이터를 저장하는 노드로써 역할을 수행하게 됩니다.
'Development > Apache Kafka' 카테고리의 다른 글
[Apache Kafka] 실시간 메시지 병렬 처리 실험 - 1 (셋팅, JMeter, plugins-manager) (1) | 2025.07.22 |
---|---|
[Apache Kafka] 적절한 파티션 수를 구하는 방법 (5) | 2025.07.21 |
[Apache Kafka] Spring Boot와 연동하여 간단한 주문 시스템 만들기 (요청/응답 받기) (6) | 2025.07.21 |
[Apache Kafka] 리눅스에 카프카 설치하기 (0) | 2025.07.19 |
[Apache Kafka] 기본 개념 이해하기 (메시지 브로커, Pub/Sub, Producer/Consumer, 스트리밍) (2) | 2025.07.18 |