동아리에서 Kafka를 주제로 발표하게 되었는데, 준비하며 학습 내용들을 기록용으로 업로드합니다.
내용은 Kafka의 개념부터 시작하여 탄생배경, 구성 요소들을 차례로 설명하며 kafka 기초에 대해 정리하였습니다.
본 자료는 '[책] 아파치 카프카 애플리케이션 프로그래밍 with 자바 – 최원영지음' 을 참고하여 만든 자료로,
혹시 문제가 있거나 내용상에 오류가 있다면 공유 부탁드립니다 :)
목차
1. 카프카란?
2. 카프카의 탄생배경
2-1. 이전의 구조
2-3. 그 이후
3. 카프카 구성요소
4. 브로커 Broker
5. 토픽과 파티션
5-1. 토픽과 파티션이란?
5-2. 토픽과 파티션 (1) - Producer와 연결 측면
5-3. 토픽과 파티션 (2) - Consumer와 연결 측면
6. 데이터 복제와 컨트롤러
6-1. 데이터 복제 (Kafka Replication)란?
6-2. 데이터 복제 (Kafka Replication)란? – 파티션 설정
6-3. 컨트롤러란?
1. 카프카란?
카프카란 링크드인에서 개발한 오픈소스 분산 이벤트 스트리밍 플랫폼인데요,
쉽게 생각하면 비동기 처리를 위한 PUB/SUB 기반의 메시징 큐라고 생각하시면 됩니다.
PUB/SUB 은 발신자 Publish, 수신자 Subscribe의 약어로, 발신자publish는 데이터 전송을 하고, 수신자Subscribe는 원하는 메시지만 구독하는 방식입니다.
kafka는 주로 실시간 데이터 처리할때 쓰는 플랫폼 인데요, kafka의 탄생배경부터 알아보겠습니다.
2. 카프카의 탄생 배경
2-1. 이전의 구조
그림은 2011년 기준 링크드인의 아키텍처 데이터 파이프라인 구조인데요,
보시다시피 Point to Point 방식 즉 1:1 로 단방향 통신으로 소스애플리케이션과 타깃 애플리케이션이 소통하는 구조였습니다.
이러한 형태는 아키텍처가 거대해지고, 소스 애플리케이션과 타깃 애플리케이션을 연결하는 파이프라인 개수가 많아지면서 문제 발생합니다.
소스코드와 버전 관리 이슈도 있고, 특히 타깃 애플리케이션 장애 발생 시, 소스 어플리케이션에 영향을 준다는 치명적인 단점이 존재했습니다.
이에 링크드인의 데이터 팀은 신규 시스템을 만들기로 결정하여, 아파치 카프카가 탄생하게 되엇습니다.
2-2. 그 이후
카프카가 생기고 나서는, 소스 애플리케이션에서 생성되는 데이터를 어디에 맵핑할지 결정하는 과정없이, 일단 카프카로 넣으면 됩니다.
그림을 보면 카프카가 중앙에 위치하여 각각의 애플리케이션끼리 연결되어 있습니다. 이러한 중앙 집중화형태는 데이터 관리에 용이해졌습니다.
또한 이러한 중앙배치형태는 "소스 애플리케이션과 타깃 애플리케이션 사이의 의존도를 최소화하여 커플링을 완화하였다.”라고 할 수 있는데요
이 의미는 기존의 1:1 매칭의 데이터 파이프라인은 커플링으로 인해 한쪽 이슈가 다른 한쪽 어플리케이션에 영향을 미치곤 하는데요, 카프카는 이러한 의존도를 줄였다는 의미를 뜻합니다.
효율적 측면에서 획기적인 변화를 불러온 카프카는 대규모의 데이터를 안전하고 빠르게 처리할 수 있다는 강점을 가졌는데요,
현재 넷플릭스, 우버, 에어비엔비 등의 글로벌 기업은 물론이고, 국내의 카카오, 네이버 등의 It 기업에서도 사용되고 있습니다. (사진참고)
3. 카프카 구성요소
그러면 본격적으로 카프카의 구성요소에 대해 알아보겠습니다.
카프카를 데이터 플로우 관점에서 보면, 카프카 프로듀서, 카프카 브로커, 카프카 컨슈머 로 크게 3가지로 나눌 수 있습니다.
그림을 보시면 카프카 브로커가 중심에 있는데요 브로커는 카프카 핵심 엔진, 즉 데이터를 저장하는 하는 서버라고 생각하시면 됩니다.
그리고 아까 처음에 말씀드릴때 카프카는 메세징 큐라고 했는데요, 카프카에서는 데이터를 주는 쪽을 프로듀서, 카프카에서 처리한 데이터를 받는 곳을 컨슈머라고 합니다.
컨슈머의 경우, 처리 속도 향상을 위해 개별 컨슈머 인스턴스를 하나로 묶어 ‘컨슈머 그룹' 으로 관리하기도 합니다.
(예를 들면, 프로듀서에서 서비스의 클릭 로그를 카프카로 전송하면, 카프카는 이를 기록하고,
elasticsearch와 같은 컨슈머가 이 레코드를 요청하여 가져가는 흐름이 될 수 있습니다).
더 자세히 들어가면, 카프카는 프로듀서와 컨슈머들이 카프카의 적재된 자신의 메시지를 구분하기 위해 데이터 구분 단위인 ‘토픽＇이 사용되는데요, 토픽은 말 그대로 메시지 묶음이라고 생각하시면 됩니다.
(예시로는 서비스에서 클릭로그와, 위치 로그가 발생되고, 이를 kafka를 통해 저장하고 처리하기 원한다면, 카프카에 clicklog와 locationlog라는 이름을 가진 토픽을 생성하여, 각각 로그에 대한 메시지 집합을 만들어 관리할 수 있습니다.
토픽은 1개이상의 파티션을 소유하는데요, 파티션은 데이터 저장 공간으로, 토픽 내의 데이터 단위입니다.
그리고 이때 저장되는 데이터를 ‘레코드’라고 합니다.
<오른쪽 상단의 확대된 그림>을 보시면 프로듀서에서 카프카 토픽으로 데이터가 저장되는 파트를 상세히 표현해보았는데요,
레코드는 타임스탬프, 메시지 키, 메시지 값, 오프셋, 헤더로 구성되어 있습니다.
메시지 값은 메시지의 실질적 데이터이고, 메시지 키는 메시지 값을 순서대로 처리하거나 메시지 값의 종류를 나타내기 위해 사용합니다.
타임스탬프는 레코드 생성 시간을 의미하고 레코드가 브로커로 전송되면 값이 지정되어 저장됩니다. 오프셋 역시 레코드가 브로커로 전송되면 값이 정해지는데요, 오프셋은 컨슈머가 데이터를 가져갈 때 사용되는 숫자로, 값은 브로커에 저장될때 이전에 전송된 레코드의 오프셋에 1을 추가하여 생성됩니다.
레코드의 다른 특성으로는 브로커에 적재되면 수정 불가하고, 로그 보유 기간 또는 용량 제한에 의해서만 삭제된다는 특징이 있습니다.
그리고 다시 메인 중앙의 그림을 보시면 주키퍼라고 있는데요,주키퍼는 카프카의 메타데이터를 관리하는 용도로, 주키퍼를 통해 어떤 데이터가 카프카 브로커 저장하는지 확인하고 생성된 토픽도 확인 가능합니다.
하지만 최근 주키퍼를 사용하지 않고 점차 제거해가는 추세인데요, 주키퍼 특성상 카프카 브로커 밖에서 관리한다는 특징이 운영에 있어 비효율적이고 보안 문제도 있다고 하여 제거되는 추세라고 합니다.
다음 슬라이드에서 브로커부터 카프카의 각 구성 요소에 대해 더 자세히 알아보겠씁니다.
4. 브로커 Broker
브로커는 아까 위에서 카프카 클라이언트와 데이터를 주고받기 위해 사용하는 주체이자, 서버를 브로커라고 했는데요,
브로커는 데이터를 분산 저장하여 장애가 발성하더라도 안전하게 사용할 수 있게 도와주는 애플리케이션입니다.
하나의 서버에 한 개의 카프카 브로커 프로세스가 동작을 하는데요, 보통 서버 1대로 카프카 기본 기능이 실행되긴 하지만, 데이터를 안전하게 보관하고 처리하기 위해서 3대 이상의 브로커 서버를 1개의 클러스터로 묶어 운영합니다.
카프카 클러스터로 묶은 브로커들은 프로듀서가 보낸 데이터를 안전하게 저장하고 복제하는 역할을 수행합니다.
데이터 저장 관점으로는, 앞서 설명했듯, 프로듀서가 요청한 토픽의 파티션에 데이터를 저장을 합니다.이때 데이터는 메모리가 아닌 파일시스템에 저장되며, 파일시스템 사용시 메모리에 비해 저하된 디스크 입출력 속도를 높이기 위해 페이지 캐시를 사용하여 속도 문제를 해결했습니다.
5. 토픽과 파티션
5-1. 토픽과 파티션이란?
다음은 토픽과 파티션에 대해 자세히 알아보겠습니다.
파티션은 큐(queue)와 비슷한 구조로, FIFO 구조와 같이 먼저 들어간 레코드는 컨슈머로 먼저 가게됩니다. 다만 데이터를 가져간다고 레코드는 삭제되지 않습니다.
두번째로는
파티션은 카프카 병렬처리의 핵심으로 그룹으로 묶인 컨슈머들이 레코드를 병렬로 처리할 수 있도록 매칭됩니다.
컨슈머의 처리량이 한정된 상황이라면, 가장 좋은 방법은 컨슈머의 개수를 늘려 스케일 아웃하는 것이다. 컨슈머 개수를 늘림과 동시에 파티션 개수도 늘리면 증가하기 때문에, 처리 속도가 향상됩니다.
5-2. 토픽과 파티션 (1) - Producer와 연결 측면
다음은 토픽과 파티션에 대해서 producer에서 어떻게 레코드를 받고, 컨슈머에서 어떻게 데이터를 가져가는지 그 과정을 자세히 살펴보겠습니다.
먼저 프로듀서에서 레코드를 받는 부분인데요,
메시지 키와 값이 담긴 레코드는 토픽의 파티션에 저장이 됩니다. 이때 키가 null인 경우 라운드 로빈 방식으로 할당되고, 메시지 키가 지정되어 있다면, key의 해시값을 작성하여 존재하는 파티션 중에 한 개로 할당됩니다.
즉 메시지의 키가 동일한 경우 동일한 파티션으로 전송되는 특성이 잇습니다.
이러한 메시지 키와 파티션 할당을 담당하는 것이 프로듀서의 파티셔너 인데, 프로듀서가 레코드 데이터를 보내면 무조건 파티셔너를 통해 브로커에 전송됩니다.
5-3. 토픽과 파티션 (2) - Consumer와 연결 측면
다음은 컨슈머에서 브로커에 잇는 파티션의 데이터를 가져가는 방식입니다.
컨슈머가 토픽에서 데이터를 가져오는 것을 ‘폴링’이라고 하는데요, 컨슈머가 데이터를 가져가더라도 토픽의 데이터는 삭제되지 않으며, 이는 여러 컨슈머 그룹들이 토픽의 데이터를 여러 번 가져갈 수 있도록 합니다.
컨슈머 그룹은 토픽이 특정 파티션으로부터 데이터를 가져가서 처리하고, 이 파티션의 어느 레코드까지 가져갔는지 확인하기 위해 오프셋 커밋을 합니다.
커밋이란 깃허브의 커밋과 같은 의미상으로, 컨슈머가 특정 레코드까지 처리를 완료했다고 레코드의 오프셋 번호를 카프카 브로커에 저장하는 것을 의미합니다. 이때 커밋한 오프셋은 _consumer_offsets 이름의 내부 토픽에 저장됩니다.
6. 데이터 복제와 컨트롤러
6-1. 데이터 복제 (Kafka Replication)란?
그리고 데이터 복제 및 싱크 관점에서 알아볼건데요, 데이터 복제는 카프카를 장애 허용 시스템(fault tolerant system)으로 동작하도록 하는 원동력으로, 카프카 복제는 파티션 단위로 이뤄집니다.
복제를 하는 이유는 클러스터로 묶인 브로커 중 일부에 장애가 발생하더라도 데이터가 삭제되지 않고 안전하게 사용하기 위해서입니다.
카프카가 어떤식으로 데이터를 복제하는지는 다음 슬라이드에서 그림과 같이 설명하겠습니다.
다음은 브로커 3대인 경우를 도식화한 그림인데요, 데이터 복제는 파티션 단위로 이뤄진다고 햇습니다.
보시면 복제된 파티션이 브로커 3대에 모두 있는 것을 확인할 수 있는데요, 이때 복제된 파티션 안에서도 리더 파티션과 팔로워 파티션으로 나뉩니다.
리더는 프로듀서와 컨슈머와 직접 통신하는 파티션이고, 나머지 복제 데이터를 갖고 있는 파티션을 팔로워라고 합니다.
팔로워 파티션들은 리더 파티션의 오프셋을 확인하여 현재 자신이 가지고 있는 오프셋과 차이나는 경우 리더 파티션으로부터 데이터를 가져와서 자신의 파티션에 저장합니다.
만약 리더 파티션이 있는 브로커에서 장애가 발생하여 리터 파티션이 동작하지 않는 상태라면, 팔로워 파티션 중에 하나가 리터 파티션 지위를 넘겨받습니다.
6-2. 데이터 복제 (Kafka Replication)란? – 파티션 설정
파티션 복제 개수의 경우는 토픽 생성할때 설정할 수 있으며,
복제 개수 최솟값은 1(즉 복제 없음)이고 최댓값은 브로커 개수입니다.
이 복제 개수는 운영시 데이터 종류마다가 다르게 설정하는데요, 보통 중요 정보등 유실되면 안되는 데이터는 복제개수를 3으로 설정한다고 합니다.
그리고 파티션은 위에서 설명했듯이 카프카의 병렬처리의 핵심인데요, 파티션의 개수가 많아질수로 1:1맵핑되는 컨슈머 개수가 늘어나기 때문에, 적절한 파티션 개수를 두는 것이 좋습니다.
토픽 생성시 파티션 개수 고려사항으로는 데이터 처리량, 메시지 키 사용여부, 그리고 브로커, 컨슈머 영향도가 있고요, 파티션 개수 공식은 다음과 같습니다.
컨슈머 데이터 처리량에 파티션 개수를 곱한 양이 프로듀서 전송 데이터 량보다 커야된다는 공식인데요, 이를 풀이하면 컨슈머 전체 데이터 처리량이 프로듀서 데이터 처리량보다 많아야한다 그런 의미입니다.
6-3. 컨트롤러란?
그리고 컨트롤러라는 개념이 있는데요, 이는 클러스터의 다수 브로커 중 한대가 맡는 역할로, 컨트롤러는 다른 브로커들의 상태를 체크하고 브로커가 클러스터에서 빠지는 경우 해당 브로커에 존재하는 리더 파티션을 재분배하는 역할을 합니다.
만약 컨트롤러 역할을 하는 브로커에 장애가 생기면 다른 브로커가 컨트롤러 역할을 합니다.
그 외에도 kafka 스트림즈와 커넥트 등 추가적인 내용이 있으니 이는 공식 사이트나, 책을 통해 살펴보시면 좋을 것 같습니다.
'#️⃣ Data Engineering > Kafka' 카테고리의 다른 글
| [Kafka] Kafka 클라이언트 (0) | 2023.02.13 |
|---|---|
| [Kafka] 토픽과 파티션, 레코드 (0) | 2023.02.13 |
| [Kafka] Kafka 개념과 컴포넌트 (0) | 2023.02.13 |
