일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- computer science
- Java
- mysql
- 스프링 부트
- 스프링 배치
- spring cloud
- CS
- 자바
- CI/CD
- Container
- 스프링
- HTTP
- spring batch
- 도커
- 컨테이너
- web server
- ORM
- 데이터베이스
- 백엔드
- Spring
- vm
- Spring Security
- 웹 서버
- 스프링 시큐리티
- virtualization
- JPA
- 가상화
- spring boot
- 영속성 컨텍스트
- 배포
- Today
- Total
개발 일기
[Kafka] 느슨한 서버 간 통신을 위한 Message Queue - Kafka 본문
[Kafka] 느슨한 서버 간 통신을 위한 Message Queue - Kafka
개발 일기장 주인 2025. 2. 11. 16:25Apache Kafka 공식 홈페이지에 들어가보면 설명이 있다.
Apache Kafka is an open-source distributed event streaming platform used by thousands of companies for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications.
개인적으로는 distributed event streaming platform에 집중하면 좋을 것 같다. 왜 distributed인지는 Kafka의 구조를 찾아보니 감을 잡을 수 있었다.
Kafka의 기본 구조
Kafka의 전체적인 구조를 정리하면 다음과 같다.
- Kafka 클러스터
- 여러 개의 브로커(Broker)로 구성된 분산형 클러스터
- 데이터를 저장하고, 프로듀서와 컨슈머 간의 메시지 전달을 담당
- Zookeeper 클러스터 (Zookeeper 앙상블)
- Kafka 클러스터를 관리하는 역할
- 브로커 정보, 파티션 할당, 리더 선출 등의 메타데이터를 저장하고 관리
- 프로듀서(Producer)
- Kafka 클러스터에 메시지를 전송하는 역할
- 메시지는 특정 토픽(Topic)의 하나 이상의 파티션(Partition)에 저장됩니다.
- 컨슈머(Consumer)
- Kafka에서 메시지를 읽어오는 역할
- 컨슈머 그룹(Consumer Group)을 사용해 여러 개의 컨슈머가 병렬로 데이터를 처리할 수 있다.
위의 구조 중 카프카 클러스터를 우선적으로 보고자 한다.
카프카 클러스터(Kafka Cluster)
- 위에서도 적었 듯이 Kafka 클러스터는 여러 브로커로 구성되어 있다.
- 한 브로커가 죽어도 다른 브로커가 그 역할을 대신하기에 고가용성이 보장된다.
- 아래 사진과 같이 하나의 브로커에는 여러 개의 토픽이 존재할 수 있으며, 각 토픽은 여러 개의 파티션으로 나뉘고, 각 파티션은 다시 세그먼트로 분할된다.
토픽, 파티션, 세그먼트
- 토픽(Topic) - "파일 시스템의 폴더"
- Kafka에서 데이터(메시지/이벤트)를 구분하는 논리적인 단위
- 한 개의 토픽은 한 개 이상의 파티션으로 구성
- 예를 들어, "주문 생성 이벤트" 같은 데이터를 각각 저장하려면 각각의 토픽을 만들면 된다
- 파티션(Partition) - "파일"
- 토픽은 여러 개의 파티션으로 나뉜다.
- 각 파티션은 데이터를 분산 저장하고, 병렬로 처리할 수 있도록 도와준다.
- Kafka는 파티션을 여러 브로커에 나누어 저장하여 확장성과 장애 대응을 높인다.
- 파티션은 추가만 가능한(Append-Only). 그렇기 때문에 프로듀서가 넣은 메시지는 파티션의 맨 뒤에 추가 된다.
- 세그먼트(Segment) - "파일 내부의 저장 블록"
- 각 파티션은 내부적으로 여러 개의 세그먼트로 나뉜다.
- Kafka는 데이터를 로그(log) 형태로 저장하며, 파티션 내부에서 일정 크기가 되면 새로운 세그먼트를 생성합니다.
- 즉, 파티션이 커지면서 새로운 "저장 블록"이 계속 추가되는 방식입니다.
Kafka에서 메시지 순서가 유지되는 이유
Kafka는 분산 메시징 시스템이지만, 특정 조건에서 순서를 보장할 수 있다.
1️⃣ 컨슈머는 오프셋(Offset) 기준으로 메시지를 읽는다
Kafka의 메시지는 파티션(Partition) 내부에서 오프셋(Offset) 순서대로 저장됩니다. 컨슈머는 이 오프셋을 기준으로 하나씩 메시지를 읽기 때문에, 같은 파티션 내에서는 메시지 순서가 유지된다.
📌 정리
✅ 같은 파티션 내에서는 메시지가 입력된 순서 그대로 읽힘!
---
2️⃣ 같은 토픽이라도 여러 개의 파티션(Partition) 에 저장될 수 있음
Kafka의 토픽(Topic) 은 내부적으로 여러 개의 파티션으로 나뉘어 저장된다.
이때 각 파티션은 독립적으로 메시지를 저장하며, 별도의 컨슈머가 읽는다.
즉, 같은 토픽이라도 여러 파티션에 걸쳐 메시지가 저장될 수 있기 때문에, 순서가 변할 가능성이 있다.
---
3️⃣ 프로듀서(Producer)는 파티션을 선택하는 방식이 2가지
Kafka에 데이터를 전송하는 프로듀서(Producer)는 메시지를 보낼 때 어떤 파티션에 저장할지 선택해야 한다.
이 방식에 따라 순서 보장이 달라진다.
(1) Round Robin 방식 (기본)
👉 특별한 키를 지정하지 않으면 Kafka는 여러 개의 파티션에 골고루(Round Robin) 메시지를 분배한다.
👉 이 경우 같은 종류의 데이터가 다른 파티션에 저장될 가능성이 있어 순서가 유지되지 않는다.
(2) Key 기반 해싱 방식 (순서 유지 가능!)
👉 특정한 Key 값을 설정하면, Kafka는 같은 Key 값을 가진 메시지를 같은 파티션에 저장한다.
👉 같은 파티션 내에서는 순서가 보장되므로, 순서를 유지하고 싶다면 Key 값을 활용하면 된다.
📌 정리
✅ Key 값 없이 메시지를 보내면 순서가 깨질 가능성이 있음!
✅ 같은 Key 값을 가지면 항상 같은 파티션으로 가서 순서 유지 가능!
---
4️⃣ 컨슈머 그룹(Consumer Group)과 메시지 처리 순서
Kafka의 컨슈머는 컨슈머 그룹(Consumer Group) 단위로 동작한다.
(1) 한 개의 파티션은 컨슈머 그룹 내에서 한 개의 컨슈머에게만 할당
👉 같은 컨슈머 그룹 내의 여러 컨슈머가 하나의 파티션을 공유할 수 없다.
👉 즉, 한 파티션의 메시지는 하나의 컨슈머가 순서대로 가져간다.
(2) 파티션 수보다 컨슈머 수가 많으면 일부 컨슈머는 대기
👉 Kafka의 파티션 개수보다 컨슈머 수가 많으면 일부 컨슈머는 할당받을 파티션이 없어서 일을 못 한다.
👉 반대로 컨슈머 수보다 파티션 개수가 많으면, 일부 컨슈머는 여러 개의 파티션을 할당받을 수도 있다.
📌 정리
✅ 한 개의 파티션은 하나의 컨슈머에게만 할당됨 → 파티션 내에서 순서 보장!
✅ 하지만 여러 파티션이 있으면 각 파티션 간 순서는 다를 수 있음!
Apache Kafka에서의 파티션 및 복제
Kafka는 대량의 데이터를 안정적으로 처리할 수 있는 분산형 스트리밍 플랫폼입니다. 이 시스템은 **토픽(Topic)**을 **파티션(Partition)**이라는 단위로 나누어 데이터를 분산 저장하고 처리합니다. 파티션은 각기 다른 브로커에 분배되어 저장되며, Kafka의 성능과 고가용성, 확장성을 지원하는 중요한 역할을 합니다.
1. 파티션의 역할과 분배
Kafka에서 토픽은 여러 개의 파티션으로 나누어집니다. 각 파티션은 독립적인 로그 파일로 관리되며, Kafka 클러스터 내에서 여러 브로커에 분배됩니다. 하나의 파티션은 오직 하나의 브로커에만 할당되며, 동일한 파티션은 여러 브로커에 복제되지 않습니다. 즉, 각 파티션은 특정 브로커에서만 관리됩니다.
예를 들어, Kafka 클러스터에 3개의 브로커가 있을 경우, 3개의 파티션을 가진 토픽이 있다면 각 파티션은 다음과 같이 분배됩니다:
- 파티션 0 → 브로커 1
- 파티션 1 → 브로커 2
- 파티션 2 → 브로커 3
이러한 분배 방식은 데이터의 병렬 처리 및 부하 분산에 중요한 역할을 합니다.
2. 복제와 고가용성
각 파티션은 기본적으로 복제되어 여러 브로커에 저장됩니다. 이를 통해 데이터의 고가용성을 확보할 수 있습니다. 예를 들어, 파티션 0이 브로커 1에 저장된다면, 복제본은 브로커 2나 브로커 3에도 저장될 수 있습니다. 이 복제 설정은 KAFKA_REPLICATION_FACTOR라는 환경 변수로 정의할 수 있으며, 이 값에 따라 각 파티션의 복제본 수가 결정됩니다.
복제 설정이 2로 되어 있을 경우, 다음과 같은 방식으로 복제본이 분배될 수 있습니다:
- 파티션 0 → 브로커 1 (원본), 브로커 2 (복제본)
- 파티션 1 → 브로커 2 (원본), 브로커 3 (복제본)
- 파티션 2 → 브로커 3 (원본), 브로커 1 (복제본)
복제를 통해 하나의 브로커가 장애를 일으킬 경우, 다른 브로커에서 데이터를 제공할 수 있어 시스템의 고가용성을 보장할 수 있습니다.
3. 파티션 분배의 중요성
파티션 분배는 Kafka의 성능에 중요한 영향을 미칩니다. 여러 브로커에 파티션이 분배되므로, 데이터 처리 및 저장 부하가 브로커 간에 고르게 분산됩니다. 이를 통해 데이터 처리 속도와 시스템 성능이 향상되며, 트래픽이 집중되는 특정 브로커의 부하를 줄이는 효과를 가져옵니다.
또한, 파티션 복제를 통해 시스템 장애 시에도 데이터 손실을 방지하고, 클러스터의 신뢰성을 높일 수 있습니다. 복제된 데이터를 통해 다른 브로커가 빠르게 데이터를 제공하고, 장애 발생 시에도 서비스가 지속적으로 운영될 수 있도록 합니다.
Kafka의 파티션과 복제는 분산 시스템의 핵심 요소로, 높은 성능과 고가용성을 제공하며, 대규모 데이터 처리 및 이벤트 기반 시스템에서 중요한 역할을 합니다.
'Back-End > Spring Cloud + MSA + Kubernetes' 카테고리의 다른 글
[분산 환경] 분산 환경에서의 트랜잭션 처리 (0) | 2025.03.10 |
---|---|
[분산 환경] 분산 환경에서 느슨한 결합을 위한 이벤트 기반 아키텍처 (0) | 2025.03.10 |
[Spring Cloud] Spring Cloud Config Server - 2 (Spring Cloud Bus & RabbitMQ) (0) | 2025.02.11 |
[Spring Cloud] Spring Cloud Config Server - 1 (0) | 2025.02.10 |
[Spring Cloud] Spring Cloud Gateway & Spring Cloud LoadBalancer (0) | 2025.02.10 |