Producer는 Leader만 Write하고 Consumer는 Leader로부터만 Read함 Follower는 Broker 장애시 안정성을 제공하기 위해서만 존재
Follower는 Leader의 Commit Log에서 데이터를 가져오기 위해 요청(Fetch Request)으로 복제
Leader 장애 -> 새로운 Leader를 선출
Kafka 클러스터는 Follower 중에서 새로운 Leader를 선출 Client(Producer/Consumer)는 자동으로 새 Leader로 전환
Partition Leader에 대한 자동 분산: Hot Spot 방지
auto.leader.rebalance.enable: 기본값 enable leader.imbalance.check.interval.seconds: 기본값 300 sec . 300초마다 leader 분산에 불균형 여부 check leader.imbalnce.per.broker.percentage: 기본값 10 . 다른 브로커보다 10% 이상 더 많이 가져가면 불균형으로 판단
Rack Awareness: Rack간 분산하여 Rack 장애를 대비
동일한 Rack 혹은 Available Zone상의 Broker들에 동일한 "rack name" 지정 복제본(Replica-Leader/Follower)은 최대한 Rack 간에 균형을 유지하여 Rack 장애 대비 Topic 생성시 또는 Auto Data Balancer/Self Balancing Cluster 동작 때만 실행
Kafka Broker는 Partition에 대한 Read 및 Write를 관리하는 소프트웨어 . Kafka Server라고 부르기도 함 . Topic 내의 Partition들을 분산, 유지 및 관리 . 각각의 Broker들은 ID로 식별됨(ID는 숫자) . Topic의 일부 Partition들을 포함 -> Topic 데이터의 일부분(Partition)을 갖을 뿐 데이터 전체를 갖고 있지 않음 . Kafka Cluster: 여러 대의 Broker들로 구성됨 . Client는 특정 Broker에 연결하면 전체 클러스터에 연결됨 . 최소 3대 이상의 Broker를 하나의 Cluster로 구성해야 함 -> 4대 이상을 권장함
Zookeeper: Broker를 관리
Zookeeper는 Broker를 관리 (Broker 들의 목록/설정을 관리)하는 소프트웨어
. 변경사항에 대해 Kafka에게 알림: 토픽 생성/제거, Broker 추가/제거 등
. Zookeeper는 홀수의 서버로 작동하게 설계되어 있음(최소 3, 권장 5)
. Zookeeper에는 Leader(writes)가 있고 나머지 서버는 Follower(reads)
Zookeeper 아키텍쳐: Leader/Follower 기반 Mater/Slave 아키텍쳐
Zookeeper는 분산형 Configuration 정보 유지, 분산 동기화 서비스를 제공하고 대용량 분산 시스템을 위한 네이밍 레지스트리를 제공하는 소프트웨어
분산 작업을 제어하기 위한 Tree 형태의 저장소 -> Zookeeper를 사용하여 멀티 Kafka Broker들 간의 정보(변경 사항 포함) 공유, 동기화 등을 수행
.변경사항에 대해 Kafka에게 알림: 토픽 생성/제거, Broker 추가/제거 등
. Zookeeper는 홀수의 서버로 작동하게 설계되어 있음(최소 3, 권장 5)
. Zookeeper에는 Leader(writes)가 있고 나머지 서버는 Follower(reads)
Zookeeper Failover: Quorum 알고리즘 기반
Quorum(쿼럼)은 "정족수"이며, 합의체가 의사를 진행시키거나 의결을 하는데 필요한 최소 인원을 뜻함
분산 코디네이션 환경에서 예상치 못한 장애가 발생해도 분산 시스템의 일관성을 유지시키기 위해서 사용
Producer: 메시지를 생산해서 Kafka의 Topic으로 메시지를 보내는 애플리케이션
Consumer: Topic의 메시지를 가져와서 소비하는 애플리케이션
ConsumerGroup: Topic의 메시지를 사용하기 위해 협력하는 Consumer들의 집합
. 하나의 Consumer는 하나의 Consumer Group에 포함되며, Consumer Group 내의 Consumer들은 협력하여 Topic의 메시지를 분산 병렬 처리함
Producer와 Consumer의 분리(Decoupling)
. Producer와 Consumer는 서로 알지 못하며, 각각 고유의 속도로 Commit Log에 Write 및 Read를 수행
. 다른 Consumer Group에 속한 Consumer들은 서로 관련이 없으며, Commit Log에 있는 Event를 동시에 다른 위치에서 Read할 수 있음
Kafka Commit Log
Commit Log
. 추가만 가능하고 변경 불가능한 데이터 스트럭쳐
Offset . Commit Log에서 Event의 위치
Kafka Offset: Commit Log에서 Event의 위치
Producer가 Write하는 LOG-END-OFFSET과 Consumer Group의 Consumer가 Read하고 처리한 후에 Commit한 CURRENT-OFFSET과의 차이(Consumer Lag)가 발생할 수 있음
Topic, Partition, Segment: Logical View
Topic: Kafka 안에서 메시지가 저장되는 장소, 논리적인 표현
Partition . Commit Log, 하나의 Topic은 하나 이상의 Partition으로 구성 . 병렬 처리(Throughput 향상)를 위해서 다수의 Partition을 사용
Segment . 메시지(데이터)가 저장되는 실제 물리 File
. Segment File이 지저된 크기보다 크거나 지정된 기간보다 오래되면 새 파일이 열리고 메시지는 새 파일에 추가됨
Topic, Partition, Segment: Physical View
Topic 생성 시 Partition 개수를 지정하고, 각 Partition은 Broker들에 분산되며 Segment File들로 구성됨 Rolling Strategy: 특정 용량이나 시간에 따라 Segment 파일을 분리 . log.segment.bytes(default 1GB) . log.roll.hours(default 168 hours)
파일을 Rolling하여 분리/생성
Active Segment: Partition당 하나의 Active Segment
Partition당 오직 하나의 Segment가 활성화(Active) 되어 있음 -> 데이터가 계속 쓰여지고 있는 중
Topic, Partition, Segment의 특징
Topic 생성 시 Partition 개수를 지정 - 개수 변경 가능하나 운영 시에는 변경 권장하지 않음
Partition 번호는 0부터 시작하고 오름차순
Topic 내의 Partition들은 서로 독립적임
Event(Message)의 위치를 나타내는 Offset 이 존재
Offset은 하나의 Partition에서만 의미를 가짐 - Partition 0 의 offset 1은 Partition 1의 offset 1과 연관 없음
Offset값은 계속 증가하고 0으로 돌아가지 않음
Event(Message)의 순서는 하나의 Partition 내에서만 보장
Partition에 저장된 데이터(Message)는 변경이 불가능(Immutable)
Partition에 Write되는 데이터는 맨 끝에 추가되어 저장됨
Partition은 Segment File들로 구성됨 - Rolling 정책: log.segment.bytes, log.roll.hours
초기 빅데이터 플랫폼은 End-to-End로 각 서비스 앱으로부터 데이터를 배치로 모았었는데, 이러한 구조는 유연하지 못했고 실시간으로 생성되는 데이터들에 대한 인사이트를 서비스 앱에 빠르게 전달하지 못하는 단점이 있었습니다.
또한 원천 데이터로부터 파생된 데이터의 히스토리를 파악하기가 어려웠고, 계속되는 데이터의 가공으로 인해 데이터가 파편화되면서 데이터 거버넌스를 지키기 어려웠습니다.
이를 해결하기 위해 개선한 아키텍처가 람다 아키텍처입니다.
[람다 아키텍처]
- 배치 레이어: 배치성 데이터를 모아서 특정 시간마다(시간, 일, 월 단위) 일괄 처리(=배치 데이터 처리)
- 스피드 레이어: 서비스에서 생성되는 원천 데이터를 실시간으로 분석(=실시간 데이터 처리)
- 서빙 레이어: 배치/스피드 레이어에서 처리한 데이터(가공된 데이터)를 최종 저장
배치 데이터에 비해 낮은 지연으로 분석이 필요한 경우, 스피드 레이어를 통해 데이터를 분석할 수 있습니다.
스피드 레이어에서 가공,분석된 실시간 데이터는 사용자 또는 서비스에서 직접 사용할 수 있지만, 필요한 경우 서빙 레이어로 데이터를 보내서 저장하고 사용합니다.
** 람다 아키텍쳐에서 카프카는 스피드 레이어에 위치 -> 서비스 애플리케이션들의 실시간 데이터를 짧은 지연 처리/분석할 수 있기 때문
- 람다 아키텍처의 단점
데이터를 분석/처리하는데 필요한 로직이 두벌로 각각의 레이어에 따로 존재한다 배치 데이터와 실시간 데이터를 융합하여 처리할 때 다소 유연하지 못한 파이프라인을 생성해야 한다.
데이터를 배치 처리하는 레이어와 실시간 처리하는 레이어를 분리한 람다 아키텍처는 데이터 처리 방식을 명확히 나눌 수 있었지만, 레이어를 두 개로 나뉘기 때문에 생기는 단점이 있습니다.
이를 해결하기 위해 한 개 로직을 추상화하여 배치 레이어와 스피드 레이어에 적용하는 형태를 고안한 트위터의 서밍 버드가 있었지만, 결국 컴파일 이후에는 배치 레이어와 스피드 레이어에 각각 디버깅과 배포를 해야했기 때문에 문제가 완벽하게 해결되지는 못했습니다.
이러한 람다 아키텍처의 단점을 해소하기 위해 제이 크랩스는 카파 아키텍처를 제안했습니다.
[카파 아키텍처]
- 카프카를 최초로 개발한 개발자 제이 크랩스(Jay Kreps)가 제안 - 배치 레이어를 제거하고 모든 데이터를 스피드 레이어에서 처리
- 배치 레이어 때문에 발생한 로직의 파편화, 디버깅, 배포, 운영 분리에 대한 이슈 제거
카파 아키텍처는 람다 아키텍처와 유사하지만, 배치 레이어를 제거하고 모든 데이터를 스피드 레이어에 넣어서 처리한다는 점이 다릅니다. 람다 아키텍처에서 단점으로 부각되었던 로직의 파편화, 디버깅, 배포, 운영 분리에 대한 이슈를 제거하기 위해 배치 레이어를 제거한 카파 아키텍처는 스피드 레이어에서 모든 데이터를 처리하므로 엔지니어들이 효과적으로 개발과 운영을 가능하게 했습니다.
[스트리밍 데이터 레이크 아키텍처]
- 2020년 카프카 서밋에서 제이 크랩스(Jay Kreps)가 제안 -배치 데이터, 스트림 데이터 처리를 스트림 레이어에서 처리
- 처리 완료된 데이터를 스피드 레이어에 저장 - 마치 카프카가 하둡을 대체하는 것과 유사
2020년 카프카 서밋에서 제이 크랩스는 카파 아키텍처에서 서빙 레이어를 제거한 스트키밍 데이터 레이크를 제안했습니다.
제이 크랩스는 람다 아키텍처에서 스피드 레이어로 사용되는, 카프카의 분석과 프로세싱을 완료한 거대한 용량의 데이터를 오랜 기간 데이터를 저장하고 사용할 수 있다면, 서빙 레이어를 제거하여 서빙 레이어와 스피드 레이어가 이중으로 관리되는 운영 리소스를 줄일 수 있다고 생각했습니다.
데이터가 필요한 모든 고객과 서비스 애플리케이션은 카프카를 창조함으로써 데이터의 중복, 비정합성과 같은 문제에서 벗어날 수 있게 되는 것입니다.
하지만 아직은 카프카를 스트리밍 데이터 레이크로 사용하기 위해 개선해야 하는 부분이 많이 남아있습니다.
먼저 자주 접근하지 않는 데이터를 비싼 자원을 들여 유지할 필요가 없습니다. 카프카 클러스터에서 자주 접근하지 않는 데이터는 오브젝트 스토리지와 같이 저렴하고 안전한 저장소에 옮겨 저장하고, 자주 사용하는 데이터만 브로커에서 사용하는 구분 작업이 필요합니다.
카프카 클러스터가 단계별 저장소를 가질수 있도록 추가 기능을 개발중에 있고, 아마도 가까운 미래에는 콜드 데이터는 오브젝트 스토리지에, 핫 데이터는 카프카에서 활용할 수 있게 될 것으로 보입니다.
