안녕하세요 Dibrary입니다.
이번에는 Data처리에 핵심 기술인 Apache Kafka에 대해 정리해보겠습니다.
분산 스트리밍 플랫폼. 데이터를 유실없이 안전하게 전달하는 것이 주 목적인 ‘메시지 시스템’에서 데이터를 처리할 수 있습니다.
분산 스트리밍 플랫폼. 데이터를 유실없이 안전하게 전달하는 것이 주 목적인 ‘메시지 시스템’에서 데이터를 처리할 수 있습니다.
기본 아이디어는 Pub / Sub 모델 입니다.
메시지를 관리하는 Queue가 중앙에 있고, 독립적으로 발행, 소비가 이뤄집니다.
카프카의 특징
1. Pub / Sub 모델
2. 확장성
3. 메시지 순차처리
4. 분산처리
Producer는 데이터를 push , Consumer는 데이터를 pull 합니다.
Foo와 Bar는 각각 3개의 Partition으로 나뉘어 있으며, Replica가 3이므로 3개의 복제본으로 복제됩니다.
카프카 클러스터
Broker = 카프카 서버
Zookeeper = 분산 코디네이터 시스템. Leader 선정 방법 제공
Topic = 데이터 관리할 때 기준 개념. 토픽은 1개 이상의 Partition으로 구성
Partition = 각 토픽 당 데이터를 분산 처리하는 단위. Replica의 수만큼 Partition이 각 서버에 복제됩니다.
Leader, Follower = 리더가 모든 읽기, 쓰기 연산 담당. 팔로워는 리더의 데이터를 복사하기만 합니다.
카프카 클러스터는 1개 이상의 Broker로 구성됩니다. 각 Broker는 정수형 ID로 구분합니다. Broker끼리 연결하면 클러스터가 됩니다. 브로커는 3개 이상을 가지는 것이 좋습니다. Topic을 생성하면 카프카가 자동으로 Partition을 Broker에 분배합니다. 각 Broker는 전체 Broker와 Topic들, Partition에 대한 metadata를 가지고 있습니다.
Partition은 운영 도중 그 수를 늘릴 수는 있으나, 줄일 수 없고 각 Partition은 서로 독립적입니다.
한 번 쓰여진 데이터는 변경이 불가능합니다. 데이터는 key값이 제공되지 않으면 Partition에 랜덤하게 할당됩니다.
각 Partition 속 메시지는 오름차순 ID처럼 Offset을 가지고 있고, Partition에 저장된 데이터는 설정기간 동안 데이터를 디스크에 보관합니다.
Offset은 속해있는 Partition에서만 의미 있는 값입니다. 순서는 속해있는 Partition에서만 보장 됩니다.
카프카 클러스터에서 데이터를 가져오게 될 때는 Consumer Group 단위로 가져옵니다. 가져와야 하는 Topic 안의 Partition의 데이터를 pull하고 각 Consumer Group안의 Consumer들이 Partition이 나뉘어져 있는 만큼 데이터를 처리합니다.
클러스터에서 Broker가 다운되면 다른 Broker가 데이터를 처리해줍니다.
쓰기, 읽기 연산은 Leader만 가능.
프로듀서 (Producers)
Topic에 데이터를 쓰는 개체. 어떤 Broker의 Partition에 저장해야 하는지 저장 위치를 압니다.
다수의 Broker와 Partition으로 인해 기본적으로 로드밸런싱이 되어 있습니다.
데이터 저장 성공 여부를 acks를 통해 확인할 수 있습니다.
- Acks = 0 은 저장 확인 여부를 기다리지 않는다. (손실 가능)
- Acks = 1 은 리더의 저장 확인 여부만을 기다린다. (일부 손실 가능)
- Acks = all은 리더 및 복제본의 확인 여부를 기다린다. (손실 가능 0%)
key값이 없으면 메시지(데이터)는 Round-Robin방식으로 Broker에 전송합니다. (로드 밸런싱)
key값이 있으면 메시지는 하나의 Partition에만 지속적으로 전송합니다.
컨슈머 (Consumers)
토픽으로부터 데이터를 읽습니다.
데이터는 각 Partition에 들어온 순서대로 읽습니다.
읽는 Partition의 순서는 정해져 있지 않습니다.
컨슈머 그룹은 개별 컨슈머들을 하나로 묶은 논리적 그룹 단위입니다.
컨슈머 그룹 내의 컨슈머 개수가 Partition 숫자보다 많으면 비활성화되는 컨슈머가 존재합니다.
컨슈머 그룹 단위로도 Offset관리를 합니다. 읽어 들인 위치를 기록하는 Offset은 __consumer_offsets으로 관리합니다.
데이터를 읽어 들인 순간에 Offset이 기록됩니다. 컨슈머가 중지되면 Offset에 저장된 위치부터 다시 데이터를 읽습니다.
Offset 기록 시점 정책
- At most once = 컨슈머가 메시지를 받는 순간 기록. 처리가 잘못되어도 메시지는 이미 삭제되어있음.
- At least once = 컨슈머가 데이터를 처리하는 순간 기록. 데이터를 중복처리 해도 문제 없는 프로세스에만 적용.
- Exactly once = 카프카에서 카프카로의 전송에서만 가능. 외부 시스템과의 연결을 할 때는 연산을 여러 번 해도 결과가 달라지지 않는 컨슈머만 가능 (멱등성)
주키퍼 (Zookeeper)
카프카 클러스터의 Broker 리스트를 가지고 관리합니다. 새로운 Topic 추가, Broker 장애, Topic 삭제 등의 변경 정보를 카프카에 전달합니다.
Zookeeper는 홀수 개의 서버를 가지고 있어야 합니다. (쿼럼 규칙)
쓰기를 담당하는 리더 서버 1개와 읽기를 담당하는 팔로워 서버로 구성됩니다.
분산 스트리밍 플랫폼. 데이터를 유실없이 안전하게 전달하는 것이 주 목적인 ‘메시지 시스템’에서 데이터를 처리할 수 있습니다.
'프로그래밍 > Data process' 카테고리의 다른 글
| Airflow에서 보기 편하게 Task를 묶어주는 - TaskGroup (0) | 2022.10.31 |
|---|---|
| Hadoop 기본 구조 및 원리 (2) | 2022.09.23 |
| 파이썬으로 AWS S3에 있는 파일 GET, PUT하기 (0) | 2022.09.16 |
| AWS - S3 프리티어로 사용해보기 (버킷생성) (0) | 2022.09.15 |
| Python을 이용해서 HDFS의 파일 읽어오기 (0) | 2022.08.17 |