초당 수십만 아니 그 이상의 데이터가 들어온다면 그것을 어떻게 처리할 수 있을까?
하나라도 흘린다면 로그 정합성에 문제가 생길테고... 유실된 정보에 대한 책임은 어떻게...
그렇다면 우선 데이터를 다 받는 것부터 해야하지 않을까?
대량의 로그를 처리하기 위해 고민하다가 실시간 메시지 큐 형태의 Kafka를 알게되었다.
Kafka® is used for building real-time data pipelines and streaming apps. It is horizontally scalable, fault-tolerant, wicked fast, and runs in production in thousands of companies.
카프카는 실시간 데이터를 처리하는데 사용되며, 확장도 좋고 속도도 빠르다고 한다.
카프카의 구조부터 살펴보자
카프카는 기본적으로 정보를 생산하는 Producers(이하 프로듀서)와 Consumers(이하 컨슈머)로 구성된다.
말그대로 생산자는 데이터를 생산하고, 소비자는 생산된 데이터를 가져다가 사용하는 존재이다.
이를 잘 사용하기 위해서 카프카는 총 4가지 핵심 API를 제공한다.
1. Producer API - 데이터 생산을 위한 API
2. Consumer API - 데이터 소비를 위한 API
3. Streams API - 애플리케이션이 stream processor 역할을 수행하게하고, 소비와 생산을 돕는 API
4. Connector API - 재사용 가능한 생산자 또는 소비자를 구축하고 실행할 수 있도록 돕는 API
이런게 있다 정도만 알고, 다음으로 넘어가자.
카프카를 이해하기 위해서 반드시 알아야 하는 용어 몇가지가 있다.
Brokers: 일종의 서버라고 생각하면 쉽다.
Topic: 생산자가 생산한 메시지를 저장할 수 있는 곳
Partition: Topic을 파티션단위로 나눌 수 있다. (최소 1개 부터 그 이상으로 나눌 수 있다.)
각 파티션은 메시지를 식별할 수 있는 고유 offset 번호를 가지고 있다.
메시지를 구분하기 위해서 파티션 번호와 offset 번호를 이용한다.
단위의 순서는 offset -> partition -> topic -> brokers
번외로, 카프카의 관리를 위해서는 주키퍼가 필요하다.
카프카 뿐만아니라 하둡, 스파크 등 분산 처리를 위한 시스템들은 모두 주키퍼를 사용하면 편하다.
각 서버의 관리를 편하게 할 수 있도록 한다.
카프카의 특별한 기능
1. 메시지 보유 기간 설정
- 일반적인 메시지 큐는 생산되어 있는 데이터를 소비자가 소비시킬 경우 데이터가 사라진다.
- 하지만, 카프카는 사용자가 설정한 기간동안 데이터를 보관한다.
- 만약, 보유 기간 7일을 설정한 토픽이 존재한다면, 7일동안은 마음껏 이용가능하다.
- 7일이 지나면 공간확보를 위해 지워진다.
2. 리더와 팔로워
- 1개의 리더와 0개 이상의 팔로워가 존재
- 리더는 파티션에 대한 모든 읽기 및 쓰기 요청을 처리하는 반면 팔로어는 리더를 수동으로 복제한다.
- 리더가 실패하면 팔로워 중 하나가 자동으로 새로운 리더가된다.
- 각 서버는 일부 파티션의 리더가되고 다른 파티션의 팔로워를 수행하므로 클러스터 내에서 로드 균형이 유지된다.
3. 데이터 보증
- 동일한 프로듀서가 2개의 메시지를 생산할경우 먼저 보낸 M1은 M2보다 낮은 오프셋을 가진다.
- 컨슈머는 로그에 저장된 순서대로 메시지를 확인한다.
'BigData > Kafka' 카테고리의 다른 글
| Kafka 자주 사용하는 명령어 정리 (0) | 2023.03.15 |
|---|---|
| Kafka connect를 활용하여 HDFS에 데이터 넣기 (0) | 2023.03.14 |
| Kafka connect를 활용하여 Elasticsearch에 데이터 넣기 (0) | 2021.08.04 |
| (해결X) Kafka producer memory buffer issue (0) | 2021.07.22 |