[Kafka] 카프카의 특징과 내부구조 (브로커, 프로듀서, 컨슈머, 파티션)

Kafka 개념 정리 - 1

 

기존의 데이터 전송방식 문제점

카프카를 사용하기 이전에는 애플리케이션간 데이터 전송시 직접 연결해서 전송하는

엔드 투 엔드(end to end)방식을 사용했었습니다.

 

소규모일때는 문제가 되지않았지만 시스템의 규모가 커지면서 애플리케이션의 개수가

늘어나게되자 애플리케이션간에 데이터 전송 관계가 복잡해지게 되었습니다.

그 영향으로 타겟 애플리케이션에 장애가 발생할경우 연결된 소스 애플리케이션에도 영향을

끼치게 되는 문제가 생기게 되었습니다.

 

카프카(Kafka) 탄생

2011년 구인/구직관련 사이트인 링크드인에서는 이런 문제를 해결하기위해 애플리케이션간에

직접 통신을 하는게 아닌 데이터의 중앙 집중화를 하는 시스템을 만들 었는데

이 시스템이 바로 아파치 카프카(Apache Kafka) 입니다.

 

 

카프카의 개발로 인해서 애플리케이션간 의존도가 낮아지고 소스 애플리케이션 에서는

카프카에 데이터를 전송만하면 되고 타겟 애플리케이션은 카프카에서 데이터를 요청만

하게되는 방식으로 바뀌었습니다.

 

카프카의 특징

빅데이터 관점에서 데이터의 종류는 텍스트가 될수도있고 사진, 동영상 모든 형태를 포함합니다.

그리고 이러한 데이터들이 모이는장소를 데이터 레이크(Data Lake) 즉, 데이터의 호수라는 뜻인데

발생하는 모든 데이터를 한곳에 저장하려고 하면 문제가 발생하게 될것입니다.

 

시스템의 규모가 커질수록 데이터 수집시 복잡도가 올라가게 됩니다.

이런 문제를 해결하기 위해서는 데이터 수집과 적재를 안정화하고 유연하게 확장할수 있는

데이터 파이프라인이 필요하게 되는데 카프카가 바로 그 대안입니다.

 

1. 확장성(Scale out, in)

시스템을 운영하다보면 예상치못하게 트래픽이 과도하게 증가할수 있습니다.

평소에는 50개의 브로커 서버로 운영을하다가 사용량이 급격하게 증가하여 브로커 서버가

500개 정도가 필요하게 되면 카프카는 스스로 자원을 늘려서 데이터를 처리하고 다시 사용량이

평소수준으로 돌아오게 되면 역시 스스로 자원을 반납합니다.

 

2. 높은 성능

기존 엔드투 엔드 방식에서는 데이터 전송시 한건씩 처리하다보니 복잡도가 올라가게 되면

서버의 부담이 크게 증가하였습니다.

카프카는 프로듀서와 컨슈머가 브로커를 통해 데이터를 주고받을때 한번에 대량의 데이터를

주고받도록 설계되있습니다. 또한 파티션과 컨슈머의 개수를 동일하게 늘려 병렬처리를

함으로써 데이터 전송 효율을 높였습니다.

 

3. 데이터의 영속성

카프카는 데이터를 파일시스템에 저장합니다. 일반적인 메시징 시스템의 경우 속도를위해

메모리 영역에 데이터를 저장하지만 카프카는 디스크에 저장하면서도 속도문제를 해결합니다.

파일시스템의 페이징캐시 영역에 데이터를 저장하여 입출력속도를 보완하였고 파일시스템에

저장되다보니 시스템이 종료되더라도 데이터는 사라지지 않습니다.

 

4. HA(고가용성)

카프카는 브로커 서버를 3개 이상으로 운영하는것을 지향하는데 고가용성을 위함입니다.

3개 이상의 브로커 서버를 운영함으로써 일부 서버에 문제가 발생되더라도 데이터는

모든 브로커에 저장 되므로 데이터 처리를 무중단형태로 운영할수 있습니다.

 

카프카의 기본 개념

프로듀서

데이터를 파티션 내부의 큐로 전송하는 애플리케이션 입니다.

 

컨슈머

파티션내부의 큐에서 데이터를 가져가는 애플리케이션 입니다.

 

파티션

프로듀서에서 받은 데이터가 저장되는 공간입니다. 내부는 큐형태로 이루어져 있으며

레코드라고 부릅니다. FIFO 방식으로 데이터를 입출력하게 됩니다.

 

 

 

카프카(Kafka)의 내부 구조

 

브로커(Broker)

브로커는 카프카 클라이언트와 데이터 전송을 위한 역할을 하고 데이터를 분산 저장하여

안전하게 사용할수 있도록 하는 애플리케이션 입니다.

기본적으로 브로커 서버 하나만으로도 운영은 가능하지만 데이터의 안전성을 위해

3개 이상의 브로커서버를 하나의 카프카 클러스터로 묶어서 운영하는것이 일반적입니다.

 

1. 데이터 입출력 방법

프로듀서가 데이터 전송시 지정한 토픽의 파티션에 데이터를 저장한후 컨슈머가 데이터를

요청하면 해당 파티션에 있는 데이터를 제공합니다.

 

이때 데이터는 파일시스템에 저장되는데 일반적으로 파일시스템은 입출력 속도가 느립니다.

그래서 카프카는 페이지캐시(Page Cache) 를 사용하여 데이터의 입출력 속도를 보완했습니다.

페이지 캐시

리눅스 OS에서 파일입출력의 성능 향상을 위해 읽었던 파일의 내용을 페이지 캐시 영역에

저장했다가 동일한 데이터의 접근이 일어나면 디스크가 아닌 페이지 캐시 영역에서 읽는방식.

 

 

2. 데이터 복제 (Replication)

카프카의 데이터 복제는 파티션 단위를 기준으로 합니다. 토픽 생성시 파티션의 복제 개수를

설정하는데 1개부터 브로커의 개수만큼 최대로 지정할수 있습니다.

 

리더 파티션(Leader Partition), ack

프로듀서, 컨슈머와 직접적으로 데이터를 통신하는 파티션입니다.

만약 리더파티션이 있는 브로커 서버에 장애가 발생하면 팔로워 파티션중 하나가 리더가 됩니다.

 

프로듀서에서 토픽으로 데이터 전송시 리더파티션이 받게되는데 이때 프로듀서에서는 ack 옵션을

지정할수 있습니다. ack 옵션에 대한 내용은 아래와 같습니다.

 

• 0 : 데이터 전송만하고 전송 결과값은 받지 않습니다. 전송 결과를 받지않기 때문에 처리속도는

  가장 빠르지만 파티션간 데이터 복제여부를 알수없고 데이터 유실 가능성이 있습니다.

• 1 : 데이터 전송에 대한 결과값은 받지만 파티션간 레코드 복제 여부에 대한 결과값은 받지

  않습니다. 이 방법역시 리더파티션이 존재하는 브로커 서버에 문제가 생길 경우 데이터

  유실 가능성이 존재합니다.

• all : 데이터 전송에 대한 결과값도 받고 파티션간 레코드 복제 여부에 대한 결과값도 받습니다.

  데이터유실은 없지만 0, 1 옵션에 비해 속도가 느립니다.

 

 

팔로워 파티션(Follower Partition)

리더파티션의 오프셋과 자신의 오프셋을 비교하여 다를경우 리더파티션의 데이터를 가져와서

자신의 파티션에 저장하는데 이 과정을 복제(replication) 라고 합니다.

 

 

 

3. 데이터 삭제

파티션의 데이터 입출력은 FIFO 방식이지만 컨슈머가 데이터를 가져가도 삭제되지 않고

프로듀서, 컨슈머가 삭제에 대한 요청을 할수도 없습니다.

데이터 삭제는 브로커가 하고 삭제는 로그세그먼트 라는 파일 단위로 하게됩니다.

 

로그 세그먼트

로그 세그먼트에는 여러가지 데이터가 같이 존재하여 특정 데이터만 삭제할수 없습니다.

세그먼트 파일의 기본값은 1GB 이고 설정할수 있지만 너무 작게하면 데이터 저장을위해

세그먼트를 자주 열고닫기 때문에 부하가 발생할수 있으므로 조심해야 합니다.

 

4. 컨트롤러(Controller)

카프카 클러스터 내부의 브로커 서버들중 하나는 컨트롤러 역할을 합니다.

컨트롤러 브로커는 다른 브로커 서버들의 상태를 확인하고 브로커 서버가 클러스터에서

빠지게 되면 해당 브로커서버의 리더 파티션을 재 분배합니다.

 

5. 코디네이터

클러스터의 브로커중 하나는 코디네이터 역할을 하는데 컨슈머 그룹의 상태를 확인하고

파티션을 컨슈머와 매칭되도록 합니다.

만약 매칭중인 컨슈머가 그룹에서 빠지면 매칭이 끊긴 파티션을 다른 컨슈머에 매칭시켜서

데이터 처리에 공백이 없도록 하는데 이 과정을 리밸런스(Rebalnce) 라고 합니다.

 

6. 오프셋 커밋

컨슈머 그룹은 특정 토픽의 파티션에서 데이터를 가져가고 해당 파티션의 어느 레코드까지

가져갔는지 다음에 알수있게 오프셋을 커밋합니다. 그래서 컨슈머가 다음번 데이터 요청시

커밋되있는 오프셋을 기준으로 데이터를 가져갑니다.