1. 카프카의 탄생
링크드인 팀은 단방향 통신을 통해 source application에서 target application으로 연동하는 코드를 작성하여 시스템 운영을 하고 있었음.
시스템이 커질수록 단방향 파이프라인은 점점 많아졌고, target application에 장애가 생기면 source application까지 문제가 전파되었음.
이러한 문제를 해결하기 위해 링크드인 팀은 신규 시스템을 만들게 되었고, 이 것이 아파치 카프카.
각각의 애플리케이션 끼리 연결하는 방식이 아니라 한 곳에 데이터를 중앙집중할 수 있도록 구성하였음.
카프카를 중앙에 배치함으로써 애플리케이션 사이의 결합도를 낮추게 되었음.
카프카의 특징
1. 카프카 내부에 데이터를 저장하는 파티션(partition)은 FIFO Queue 자료구조와 유사함
2. 일부 카프카 클러스터에 문제가 발생하더라도, 여러 대의 서버를 구축하여 데이터를 복제하는 구조이기 때문에 안정성을 확보할 수 있음
2. 빅데이터 파이프라인에서 카프카의 역할
아파치 카프카가 왜 데이터 파이프라인으로 적합한가?
높은 처리량
- 카프카는 프로듀서가 브로커로 데이터를 보낼 때 와, 컨슈머가 브로커로부터 데이터를 받을 때 모두 묶어서 전송
- 동일한 데이터를 보낼 때, 네트워크 통신 횟수를 최소한으로 줄인다면 동시간 내에 더 많은 데이터를 전송할 수 있음
- 파티션 단위를 통해 동일 목적의 데이터를 여러 파티션에 분배하고 데이터를 병렬처리할 수 있음
확장성
- 데이터가 적을 때는 최소한의 브로커 수로 운영하다가, 데이터가 많아지면 클러스터의 브로커 개수를 scale out 할 수 있음
- 반대로 데이터가 적어지면 브로커 개수를 scale in 할 수 있음
영속성
- 카프카는 전송받은 데이터를 메모리에 저장하지 않고 파일시스템에 저장
- 파일시스템에 저장하는 것이 느리다고 생각할 수 있지만, I/O 성능 향상을 위해 페이지 캐시 영역을 메모리에 따로 생성하여 사용함
- 한번 읽은 파일 내용은 메모리에 저장시켰다가 다시 사용하는 방식
- 디스크 기반의 파일시스템을 사용하기 때문에, 브로커 애플리케이션이 종료되더라도 재실행 시 데이터를 안전하게 처리할 수 있음
고가용성
- 3대 이상의 서버들로 운영되는 카프카 클러스터는 일부 서버에 장애가 발생해도 데이터를 지속적으로 처리할 수 있음
- 클러스터로 이루어진 카프카는 데이터의 복제(replication)을 통해 고가용성의 특징을 갖기 때문
💡왜 3대 이상이어야 하나?
3대로 구성하는 것을 권장하는 것이지, 꼭 3대이어야 하는 것은 아니다.
2대로 운영해도 안정적으로 데이터를 처리할 수 있지만, 브로커 간에 데이터가 복제되는 시간 차이로 일부 데이터가 유실될 수 있다고 한다.
유실을 막기 위해 min.insync.replicas 옵션을 사용하는데, 이 옵션을 2로 설정하면 최소 2개 이상의 브로커에 데이터가 완전 복제됨을 보장할 수 있다.
이 옵션을 2로 사용할 때는 브로커를 3개 이상으로 운영해야 한다. 왜냐하면 3개중 1개의 브로커에 장애가 나더라도 지속적으로 데이터를 처리할 수 있기 때문이다.
min.insync.replicas 옵션 값보다 작은 수의 브로커가 존재할 때는 토픽에 더는 데이터를 넣을 수 없다.
3. 카프카 기본 개념
3-1. 카프카 브로커/클러스터/주키퍼
카프카 브로커 (broker)
- 카프카 클라이언트와 데이터를 주고받기 위한 주체.
- 데이터를 분산 저장하여 장애가 발생하더라도 안전하게 사용할 수 있도록 함.
데이터 저장, 전송
- 프로듀서로 부터 데이터를 전달 받으면 프로듀서가 요청한 토픽의 파티션에 데이터를 저장. 컨슈머가 데이터를 요청하면 파티션에 저장된 데이터를 전달함.
- 앞서서 데이터는 파일시스템에 저장한다고 설명한 바 있다. 페이지 캐시를 사용하여 입출력 속도를 높였으며, 동일한 파일의 접근이 일어나면 디스크에서 읽지 않고 메모리에서 직접 읽는다.
- OS단에서 페이지 캐시를 사용하기 때문에 카프카 브로커의 힙 메모리 사이즈를 크게 설정할 필요가 없음.
데이터 복제, 싱크
- 카프카 데이터 복제는 파티션 단위로 이루어짐
- 복제된 파티션은 리더(leader)와 팔로워(follower)로 구분됨. 프로듀서/컨슈머와 직접 통신하는 파티션을 리더 파티션, 복제 데이터를 가지고 있는 파티션을 팔로워 파티션이라고 함.
- 데이터가 일부 유실되어도 되며, 데이터 처리 속도가 중요하다면 파티션 복제 개수를 1 또는 2로 설정하면 된다.
- 리더 파티션을 갖고 있는 브로커가 중단되면, 팔로워 파티션 중 하나가 리더 파티션으로 위임됨
데이터 삭제
- 컨슈머가 데이터를 가져가더라도 토픽의 데이터는 삭제되지 않음 (오직 브로커만이 삭제 가능)
- 데이터 삭제는 파일 단위로 이루어지는데, 이 단위를 로그 세그먼트(log segment)라고 함. 파일 단위로 삭제되므로 특정 데이터만 삭제할 수 없음
- 세그먼트는 데이터가 쌓이는 동안 파일 시스템으로 열려있으며, 특정 설정값에 지정된 용량에 도달하면 닫히게 됨.
컨트롤러
- 클러스터 내의 다수 브로커 중 한 개가 컨트롤러의 역할을 함
- 다른 브로커들의 상태를 체크하고 특정 브로커가 클러스터에서 제외된 경우, 해당 브로커에 존재하는 리더 파티션을 재분배함
컨슈머 그룹
- 컨슈머 그룹은 토픽의 특정 파티션으로부터 데이터를 가져가고, 이 파티션의 어느 레코드까지 가져갔는지 확인하기 위해 offset을 커밋함
코디네이터
- 클러스터의 다수 브로커 중 한 대는 코디네이터 역할을 함
- 컨슈머 그룹의 상태를 체크하고 파티션을 컨슈머와 매칭되도록 분배함
주키퍼
- 카프카의 메타데이터를 관리하는 데에 사용됨
3-2. 토픽과 파티션
토픽
- 카프카에서 데이터를 구분하기 위해 사용되는 단위
- 토픽은 1개 이상의 파티션을 소유하며, 파티션에 저장되는 데이터를 레코드(record)라고 함
파티션
- 그룹으로 묶인 컨슈머들이 레코드를 병렬처리 할 수 있도록 매칭됨
- 각 파티션은 FIFO Queue 자료구조와 유사하지만, 데이터를 consume하더라도 해당 데이터가 파티션에서 삭제되지 않음
- 즉, 토픽의 레코드는 여러 컨슈머 그룹들이 동일한 데이터를 여러 번 가져 갈 수 있음
3-3. 레코드
- 파티션에 저장되는 데이터
- 타임스탬프, 메시지 키, 메시지 값, 오프셋, 헤더로 구성되어 있음
- 타임스탬프에는 주로 프로듀서에서 해당 레코드를 생성했을 때의 시간이 저장되지만, 프로듀서가 레코드를 생성할 때 임의의 시간 값을 타임스탬프로 설정할 수 있음. 또한 토픽 설정에 따라 브로커에 적재된 시간(LogAppendTime)으로 설정될 수도 있다.
- 메시지 키는 메시지 값을 순서대로 처리하거나 메시지 값의 종류 구분을 위해 사용됨
- 레코드가 파티션에 저장될 때 메시지 키가 존재한다면, 메시지 키의 해시 값으로 파티션을 지정하게 됨.
- 즉, 동일한 메시지 키라면 동일한 파티션에 저장됨
- 파티션 개수가 변경되면 메시지 키와 파티션 매칭이 달라짐에 유의해야 함
- 메시지 키가 존재하지 않는다면, 라운드 로빈 방식으로 파티션에 적재됨
이전 댓글