[공유] 카프카 개념_인스피언

​

안녕하세요. 인스피언입니다.

​

신입 직원이 정리해주는 IT 용어 정리 시간입니다.

​

오늘은 카프카(Kafka)에 대해 알아보는 시간을 가지겠습니다.

​

블로그 원문은 아래서 확인 가능합니다 ↓

카프카 개념과 카프카 Topic

 

---

 

 

Kafka

 

LinkedIn에서 최초로 만들고 오픈소스화 한 확장성이 뛰어난 분산 메시지 큐(FIFO : First In First Out)가 카프카입니다.

 

- 소스 애플리케이션은 아파치 카프카에 데이터를 전송합니다.

​

- 타겟 애플리케이션은 카프카에서 데이터를 가져옵니다.

​

- 예시로 소스 애플리케이션은 쇼핑몰의 클릭 로그, 은행의 결제 로그 등을 보냅니다.

​

- 타겟 애플리케이션은 로그 적재, 로그 처리 등의 역할을 합니다.

​

- 소스 애플리케이션에서 보낼 수 있는 데이터 포맷은 거의 제한이 없습니다.( json, tsv, avro etc...)

​

​

카프카를 통해 무엇을 할 수 있을까요?

 

카프카는 확장성이 뛰어난 분산 메시지 큐(FIFO : First In First Out)로, 각종 데이터를 담는 토픽(Topic)이라는 개념이 있는데 쉽게 말하면 큐(queue)라고 보면 됩니다.

​

queue에 데이터를 넣는 역할은 Kafka Producer가 하고 queue에서 데이터를 가져가는 역할은 Kafka Consumer가 합니다.

​

Producer와 Consumer는 라이브러리로 되어 있어서 애플리케이션에서 구현이 가능합니다.

​

이와 같이 카프카는 아주 유연한 queue 역할을 합니다.

​

​

Kafka의 특징

 

- 분산 아키텍쳐 구성, Fault-tolerance한 architecture(with zookeeper), 데이터 유실 방지를 위한 구성이 잘되어 있습니다.

  고가용성으로서 서버가 이슈가 생기거나 갑작스럽게 랙(전원)이 내려 간다는 상황에서도 데이터를 손실없이 복구할 수 있습니다.

​

- Pub / Sub 메시징 모델을 채용합니다.

​

- Producer가 Batch형태로 broker로 메시지 전송이 가능하여 속도가 개선됩니다.

​

- 파일 시스템에 메시지를 저장하므로, 데이터의 영속성을 보장합니다.

​

- Consume된 메시지를 곧바로 삭제하지 않고 offset을 통한 consumer-group별, 개별 consume이 가능합니다.

​

- 낮은 지연(latency)과 높은 처리량(Throughput)을 통해서 아주 효과적으로 아주 많은 데이터를 처리할 수 있습니다.

​

​

이러한 운영상의 특징들 때문에 많은 기업이 내부에 카프카를 사용하고 있습니다.

​

​

Kafka 사용 주요 사례

 

1. LinkedIn : activity streams, operational metrics, data bus(400 nodes, 18k topics, 220B msg/day in May 2014)

​

2. Netflix : real-time monitoring and event processing

​

3. Twitter : as part of their Storm real-time data pipelines

​

4. Spotify : log delivery, Hadoop

​

5. 11번가 : 카프카를 이용한 비동기 주문시스템(카프카 컨슈머 애플리케이션 배포 전략 medium post)

​

​

Kafka Topic은 무엇일까?

 

카프카에는 다양한 데이터가 들어갈 수 있는데 그 데이터가 들어가는 공간을 Topic이라고 말합니다.

​

카프카에서는 토픽을 여러 개 생성할 수 있습니다.

​

토픽은 데이터베이스의 테이블이나 파일 시스템의 폴더와 유사한 성질을 가지고 있는데, 이 토픽에 Producer가 데이터를 넣게 되고 Consumer가 데이터를 가져가게 됩니다.

​

토픽은 이름을 가질 수 있어, 목적에 따라 클릭로그, send sms, location log 등과 같이 무슨 데이터를 담는지 명확하게 명시하면 추후 유지보수 시 편리하게 관리할 수 있습니다.

​

​

Kafka Topic내부

하나의 토픽은 여러 개의 파티션으로 구성될 수 있으며, 첫번째 파티션 번호는 0번부터 시작합니다.

하나의 파티션은 queue와 같이 내부에 데이터가 파티션 끝에서부터 차곡차곡 쌓이게 됩니다.

​

클릭로그 Topic에 Kafka Consumer가 붙게 되면 데이터를 가장 오래된 순서대로 가져가게 됩니다.

(0번부터 가져간다는 뜻) 더이상 데이터가 들어오지 않으면 Consumer는 또 다른 데이터가 들어올때까지 기다립니다.

이 때 Consumer가 토픽 내부의 파티션에서 데이터를 가져가도 데이터는 삭제되지 않고 파티션에 그대로 남아 있습니다.

​

​

​

 

Consumer Group이 다르고 auto.offset.reset=earliest로 설정되어 있는 경우

 

새로운 Consumer(Targe Application #1)가 붙었을 때 다시 0번부터 가져가서 사용할 수 있습니다.

​

이처럼 사용할 경우 동일 데이터에 대해서 두번 처리할 수 있는데 이는 카프카를 사용하는 아주 중요한 이유이기도 합니다.

​

​

파티션이 2개 이상인 경우, 데이터 3이 토픽에 들어가야 하는데 어느 파티션에 들어가야 할까?

 

프로듀서가 데이터를 보낼 때 키를 지정할 수 있습니다.

​

1. 만약 키가 null, 즉 키를 지정하지 않고 기본 파티셔너 설정을 사용한다면 round-robin으로 파티션이 지정됩니다.

2. 만약 키가 있고, 기본 파키셔너를 사용할 경우 키의 해시값을 구하고 특정 파티션에 항상 할당됩니다.

위의 예시에서는 key를 따로 설정하는 것을 가정하지 않았으므로 데이터 3은 파티션1번에 들어가게 됩니다.

그리고 round-robin으로 데이터가 파티션에 나눠져서 들어가게 됩니다.

​

파티션을 늘리는 것은 가능하지만 다시 줄일 수 없기 때문에 파티션을 늘리는 것은 아주 조심해야 합니다.

​

이 때 토픽에 새로운 파티션을 한 개 더 추가하면 key와 파티션의 매칭이 깨지기 때문에 key와 파티션 연결은 보장되지 않기 때문에 주의해야 합니다.

​

​

파티션을 늘리는 이유?

 

파티션을 늘리면 컨슈머의 개수를 늘려서 데이터 처리를 분산시킬 수 있습니다.

​

​

 

이렇게 데이터가 늘어나면

파티션의 데이터는 언제 삭제될까?

 

삭제되는 타이밍은 옵션설정이 가능합니다.

​

log.retention.ms: 데이터가 저장되는 보존 시간

log.retention.byte : 데이터가 저장되는 보존 크기

​

이를 지정하게 되면 일정한 기간 혹은 용량동안 데이터를 저장할 수 있게 되고 적절하게 데이터가 삭제될 수 있도록 설정할 수 있습니다.

​

​

---

 

[참고자료]

빅 데이터 처리를 위한 아파치 Kafka 개요 및 설명

 

---