아파치 카프카란?
- 아파치 카프카는 웹사이트, 어플리케이션, 센서 등에 취합한 데이터를 스트림 파이프라인을 통해서 실시간으로 관리하고 보내기 위한 분산 스트리밍 플랫폼이다. 데이터를 생성하는 어플리케이션과 데이터를 소비하는 어플리케이션 간의 중재자 역할을 함으로써 데이터의 전송 제어, 처리, 관리 역할을 한다. 즉, 카프카는 플랫폼에 서비스를 연결하여 다양한 서비스에서 나오는 데이터 흐름을 실시간으로 제어하는 서비스의 중추역할을 하는 플랫폼이다.
구성 요소
- Cluster : 여러 대의 컴퓨터들이 연결되어 하나의 시스템처럼 동작하는 컴퓨터들의 집합
- Producer : 데이터를 만들어내어 전달하는 전달자의 역할
- Consumer : Producer에서 전달한 데이터를 Broker에 요청하여 메시지(데이터)를 소비하는 역할
- Broker : 생산자와 소비자와의 중재자 역할
- Topic : 보내는 메시지를 구분하기 위한 카테고리화
- Partition : 토픽을 구성하는 데이터 저장소로서 수평확장이 가능한 형태
- Zookeeper : 분산 코디네이션 서비스를 제공하는 오픈소스 프로젝트로 클러스터에서 구성 서버들끼리 공유되는 데이터를 유지하거나 어떤 연산을 조율하기 위해 주로 사용된다.
카프카 프로듀서(Producer)
- 프로듀서는 브로커에 특정 토픽(혹은 파티션 영역까지)을 지정하여 메시지를 전달하는 역할을 담당한다.
메시지 구조
- 토픽(Topic)
- 토픽 중 특정 파티션 위치(Partition)
- 메시지 생성 시간(Timestamp)
- 메시지 키(Key)
- 메시지 값(Value)
메시지 전달 과정
- 프로듀서는 먼저, 전달 받은 메시지를 Serializer가 지정된 설정을 통해 직렬화합니다. 메시지의 키와 값은 바이트 뭉치 형태로 변환됩니다. 그 후 Partitioner를 통해 토픽의 어떤 파티션에 저장될지 결정된다. 이 과정을 파티셔닝(Partitioning)이라고 한다. Partitioner의 별도의 설정을 하지 않은면 Round Robbin형태로 파티셔닝을 한다. 설정된 포맷에 맞춰 메시지를 압축한다. 압축을 마친 후, 프로듀서는 지정된 만큼 메시지를 저장했다가 TCP 프로토콜을 통해 한 번에 브로커로 전달합니다. 배치 큐에 저장된 레코드 배치들을 sender가 설정된 조건에 만족한 레코드 배치를 브로커로 전송한다. Sender 스레드는 네트워크 비용을 줄이기 위해 piggyback 방식으로 조건을 만족하지 않은 다른 레코드 배치를 조건을 만족한 것과 함떼 브로커로 전송한다.
카프카 브로커(Broker)
- 브로커는 일반적으로 '카프카'라고 불리는 시스템을 말한다. 브로커는 하나 이상의 리스너(listener)를 통해 외부 요청을 받습니다. 초기 메타 데이터 전달 과정에서 클라이언트로 advertised.listeners라는 리스너 정보가 전달되고 이 정보를 바탕으로 클라이언트가 브로커를 찾을 수 있다.
내부 동작 요소
- 컨트롤러(Controller)는 하나의 브로커에 부여되는 역할로 브로커들의 생존 여부(liveness)를 체크한다. 임의의 브로커가 중단되었을 경우, 해당 브로커에 있던 리더 파티션을 탈락시키고 다른 팔로워 파티션들 중 하나를 리더로 뽑는다. 컨트롤러는 카프카의 failover전략 중 중요한 부분을 담당한다. 참고로 컨트롤러가 중단되는 경우에는 주키퍼가 새로운 컨트롤러를 선출한다.
메시지 저장과 메시지 파일 관리
- 메시지를 로그(log) 자료구조 형태로 디스크에 저장한다. 로그 자료구조는 새로운 쓰기 작업이 중간에 삽입되지 않고 오로지 끝에서만 되는 append-only 특징을 가지고 이미 쓰여진 메시지는 변경이 불가능하다. 그렇기 때문에 빠른 쓰기 작업이 가능하다.
- 메시지가 브로커에 저장될 때는 메시지 내용과 함께 오프셋 정보가 저장된다. 오프셋은 메시지를 구분하는 식별자 역할을 하며, 메시지의 삽입에 따라 0부터 꾸준히 증가한다.
- 브로커에 저장되는 메시지들은 파티션 별로 세그먼트(segment)라는 파일로 저장된다. 예를 들어 토픽 A에 3개의 파티션이 있다면, 각 파티션이 위치한 브로커의 log.dirs 하위에는 해당 파티션의 세그먼트 파일이 존재한다. 그리고 프로듀서가 파티션으로 발행되는 메시지를 세그먼트 파일에 쓰고, 컨슈머는 이 파일을 읽어감으로써 메시지를 구독한다.
카프카 토픽(Topic)
토픽(Topic)
- 토픽(Topic)은 메시지를 구분하는 논리적인 단위.
- 프로듀서는 메시지를 토픽으로 발행하고, 소비자는 토픽을 구독한다.
파티션(Partition)
- 모든 토픽은 각각 대응하는 하나 이상의 파티션(Partition)이 브로커에 구성되고, 발행되는 토픽 메시지들은 파티션들에 나뉘어 저장된다. 이렇게 하나의 토픽에 대하여 여러 파티션을 구성하는 가장 큰 이유는 분산 처리를 통한 성능향상에 있다. 카프카는 하나의 토픽에 대해 여러 프로듀서가 발행할 수 있고, 여러 컨슈머가 구독할 수 있다. 일반적으로 2개 이상의 파티션을 서로 다른 브로커에 별렬 구성하여 요청의 부하를 분산시켜 준다. 이에 따라 토픽에 관한 성능도 향상시킬 수 있다.
- 파티션의 가장 큰 특징은 하나의 파티션 내에서는 메시지 순서가 보장된다. 그러나 파티션 간의 순서는 보장되지 않는다.
파티션 복제(Replica)
- 카프카는 서비스 안정성과 장애 수용(Fault-Tolerance)에 관한 요소로 파티션의 복제(Replica) 기능을 제공한다.
- 하나의 파티션은 1개의 리더 Replica와 그 외 0개 이상의 팔로어 replica로 구성된다. 리더는 파티션의 모든 쓰기, 읽기 작업을 담당하고 팔로워는 리더의 메시지들을 복제하고, 리더에 장애가 발생할 경우 리더 자리를 승계받을 준비를 한다.
- 리더 레플리카와 동기화된 레플리카들의 그룹을 ISR(In-Sync Relica)라고 한다.
카프카 컨슈머(Consumer)
- 일반적으로 컨슈머(Consumer)가 토픽을 구독(Subscribe) 혹은 읽는다(Read)고 하는데, 이는 컨슈머가 토픽 파티션에 저장된 메시지들을 가져오는 것을 말한다. 컨슈머는 다음 3가지 특징을 통해 더욱 효율적이고 유연한 메시지 구독 기능을 제공한다.
Polling 구조
- 다른 메시징 큐는 메시지 큐에서 메시지를 Push 한다. 이런 Push방식의 가장 큰 단점은 메시지 큐가 컨슈머 측의 처리 성능을 염두해야 한다. 이와 반대로 카프카는 컨슈머가 브로커로부터 메시지를 요청하는 Polling구조로 설계되어있다. 이러한 구조의 가장 큰 장점은 각 컨슈머가 자신의 환경에 메시지 구독 성능을 최적화할 수 있다. 추가로 브로커는 컨슈머의 환경을 고려할 필요가 없다.
단일 토픽의 멀티 컨슈밍
- 하나의 토픽에 서로 다른 컨슈머 애플리케이션이 동시에 구독할 수 있다. 이것이 가능한 이유는 컨슈머가 메시지를 읽을 때 브로커의 메시지가 삭제되는 것이 아니기 때문이다. 대신에 각 컨슈머가 어느 토픽 파티션의 어느 오프셋까지 읽었는지를 컨슈머 오프셋이라는 토픽에 저장한다.
- 컨슈머 애플리케이션이 메시지 구독 중 중단되었다가 다시 구동되는 경우, 컨슈머 오프셋에 저장된 정보를 통해 자신이 어디서부터 메시지를 읽어야하는 지 알 수 있다.
컨슈머 그룹
- 컨슈머는 하나 이상의 컨슈머가 컨슈머 그룹(Consumer Group)을 구성하여 하나의 토픽을 구독할 수 있다.
- 컨슈머 그룹 내의 컨슈머는 토픽 파티션의 소유권을 나눠 갖습니다. 컨슈머 그룹에 컨슈머가 추가되거나 삭제되게 되면 컨슈머 그룹 내부에서 파티션의 소유권이 재조정 된다. 이러한 파티션 소유권 재조정을 리밸런싱(Rebalancing)이라고 한다.
카프카의 Pub-Sub 모델
- 카프카의 발행/구독 모델은 송신자가 메시지를 특정 수신자에 직접적으로 보내는 프로그래밍 모델이 아닌, Publisher(Producer)가 보내는 메시지를 Topic에 보내고 Subscriber(Consumer)는 해당 Topic을 구독함으로써 메시지를 가져오는 프로그래밍 모델이다.
Reference
아크데이타
카프카 구성요소
아파치 카프카 공식 문서
아파치 카프카란 무엇인가?
언제나 김김/Kafka 101
2023