[Kafka] Kafka 이론 및 실습(Window10 Local 환경)

본 내용은  아파치 카프카 애플리케이션 프로그래밍 with 자바 를 읽고 아파치 카프카 데브원영 강의를 들으며 공부한 내용입니다.

목차
0. 에필로그
1. 카프카란
  1) 카프카의 개요 및 설명
  2) 카프카의 구성
2. 카프카 실습
  1) windows 10 Linux 설치 및 카프카 설치
  2) Producer - Consumer 통신 (Window Local 환경)

---

0. 에필로그

Kafka 공부하기 전에 OS와 네트워크 DB 개념에 대해 알고 있으면 더 효과적으로 이해할 수 있을 것 같다. 책에 있는 java 코드는 깃허브에서 같이 공부해보기로 했다.

우선, 아래와 같은 고민을 하고 있다면 카프카는 해결을 위한 훌륭한 방안이 되어 줄 수 있다.

1. 동기/ 비동기 데이터 전송에 대한 고민이 존재하는가?
2. 실시간 데이터 처리에 대한 고민이 있는가?
3. 현재 데이터 처리량에 대한 한계를 느끼는가?
4. 새로운 데이터 파이프라인이 복잡하다고 느끼는가?
5. 데이터 처리의 비용 절감을 고려 중인가?

 

---

1. 카프카란

1.  카프카의 개요 및 설명

데이터를 전송하는 source application과 데이터를 받는 target application이 존재한다. 아래에서 보이는 producer, consumer로 이해해도 좋다. 처음에는 단방향으로 데이터를 전송했으나 각 application이 많아지면서 배포와 장애에 대응하기 어려워졌다. 또한 데이터 파편화(데이터가 확보되는 경로들이 서로 이질적이어서 데이터의 계보에 단절이 생기는 경우 발생)가 심화되었다.

이를 해결하기 위해 LinkedIn 회사에서 아파치 카프카를 직접 개발하였고, 이는 소스 어플리케이션과 타겟 어플리케이션 사이의 의존도, 즉 커플링을 완화해주었다. 이제 카프카를 통해 대용량 데이터를 수집하고 사용자들이 실시간 스트림으로 소비할 수 있다. 

 

위 사진에서 source와 target에 각각 '로그'라는 단어를 기억해두자! (이후 나옴)
이렇듯 카프카는 프로듀서와 컨슈머 사이에 존재하며, 이 안에는 기본적으로 FIFO 형식의 큐로 이루어져 있다. 프로듀서에서 넘기는 데이터의 포맷은 상관이 없다. 다양한 타입을 상속받을 수 있기 때문!

---

2. 카프카의 구성

broker (+replication (OS의 RAID 개념과 비슷하게 연상된다.))

• 카프카가 설치되어있는 서버 단위로, 보통 3개 이상을 설치하는 것을 권장한다.
• 만약 broker이 3개이고 replication이 3이라면(broker의 개수>=replication의 개수이어야 함) 1개의 broker에는 leader(원본), 2개의 follower(복제본)이 존재하게 된다. 이를 ISR(In Sync Replica)라고 한다.
• replication으로 인해 Kafka의 특징인 고가용성이 보장된다. 즉 복제본으로 복구가 가능하다는 점이 강력하다.

cluster

• 하나 이상의 브로커로 구성된 집합체이다.

zookeeper (역할이 Network의 OpenFlow protocol 개념과 비슷하게 연상되며, 파일시스템 형식으로 구성되어있다.)

• 분산시스템을 사용하기 때문에 주키퍼라는 안정적인 코디네이션 어플리케이션이 추가로 필요하다. 주키퍼는 카프카의 메타데이터를 관리할 때 사용된다.
• 비유를 들면, Server가 주키퍼라면 Client가 카프카이다.
• znode는 주키퍼에서 사용하는 데이터 저장 단위이다. 상태 정보들이 key-value 형태로 저장된다.
• zookeeper는 kafka에서 서서히 없애는 중이라고 한다 !

---

토픽 (위 그림에서 Kafka아래 큰 박스에 해당한다)

• 각각의 메시지를 목적에 맞게 구분할 때 사용한다.
• 메시지를 전송하거나 소비할 때 Topic을 반드시 입력한다.
• Consumer는 자신이 담당하는 Topic의 메시지를 처리한다.
• 한 개의 토픽은 한 개 이상의 파티션으로 구성된다.

파티션(토픽 내부에 존재하는 3개의 작은 박스에 해당한다.)

• 분산 처리를 위해 사용된다.
• Topic 생성 시 partition 개수를 지정할 수 있다. (파티션 개수 변경 가능. *추가만 가능)
• 파티션이 1개라면 모든 메시지에 대해 순서가 보장되지만 파티션이 여러개라면 라운드 로빈 방식으로 클러스터가 분배해서 분산처리 되므로 순서 보장할 수 없다. 물론 파티션이 여러개일 때 분산처리 하고 싶지 않다면 key값을 일일히 할당해도 된다.
• 파티션 내부에서 각 메시지는 offset(고유 번호)로 구분된다.
• 파티션은 여러 개의 브로커에 걸쳐서 저장된다.
• 파티션이 많을 수록 처리량은 좋지만 장애 복구 시간이 늘어난다. trade-off를 잘 판단하여 개수 할당해야 한다. 파티션 개수를 추가할 수는 있지만 삭제할 수는 없다.
• 파티션 속은 메시지 큐 방식으로 운영되며, 메시지들은 한 번 생성되어 사용되었다고 삭제되지 않는다! 이것이 Kafka 의 가장 큰 이점이다. 예를 들어 위 그림에 send_sms에 담긴 메시지들이 여러개 들어있다고 하자. 만약 이 메시지들을 시각화하고 싶다면 ES에 저장할 수도 있고, 백업하고 싶어 하둡에 저장할 수도 있다. 여러 번 재사용이 가능하다!

프로듀셔 

• Topic에 해당하는 메시지 생성
• 특정 Topic으로 데이터를 publish
• 처리 실패할 시 재시도 가능

컨슈머

• Topic partition으로부터 데이터를 polling하여 가져온다.
• Partition offset 위치 기록(commit)
• Consumer group을 통해 병렬처리

 

---

2. 카프카 실습

1. windows 10 Linux 설치 및 카프카 설치

우선 실습 전에 카프카 명령어를 사용하기 위한 Windows 10 Linux 설치와 카프카 설치가 필요하다. 나는 ec2는 사용하지 않고 일단 로컬에서만 코드를 작동시켜 보기로 하였다

👉 Windows 10 Linux 설치 방법 (PowerShell 관리자 권한)

wsl --install

wsl --set-default-version 2

👉 로컬에서의 카프카 설치 방법!

# 카프카 다운로드
$ curl https://archive.apache.org/dist/kafka/2.5.0/kafka_2.12-2.5.0.tgz --output kafka.tgz

# 카프카 압축해제
$ tar -xvf kafka.tgz

# 폴더 이동
$ cd kafka_2.12-2.5.0/

# 카프카 버전 확인
bin/kafka-broker-api-versions.sh --bootstrap-server [Your Host IP]:9092

 

2. Producer - Consumer 통신 (Window Local 환경)

이후 producer를 만들고,

consumer를 만들어 실행시키면 아래와 같이 메시지들이 도착하게 된다!