Kafka

토픽은 카프카에서 데이터 스트림을 구분하는 논리적 단위이다. 특정 유형의 메시지나 이벤트를 그룹화하는 카테고리나 피드 이름으로 생각할 수 있다. 예를 들어, '사용자_클릭'이나 '주문_트랜잭션'과 같은 이름을 가질 수 있다. 프로듀서는 특정 토픽에 메시지를 발행하고, 컨슈머는 관심 있는 토픽을 구독하여 메시지를 읽는다.

토픽은 하나 이상의 파티션으로 나뉜다. 파티션은 토픽을 병렬 처리하고 확장성을 제공하기 위한 물리적 단위이다. 각 파티션은 순서가 보장되는 불변의 레코드 시퀀스이며, 새로운 레코드는 파티션의 끝에만 추가된다. 파티션 내 각 레코드는 오프셋이라는 고유한 순차 ID로 식별된다. 오프셋은 파티션 내에서만 의미가 있으며, 전역적으로 고유하지는 않다.

파티션은 카프카 클러스터 내의 여러 브로커에 분산되어 저장된다. 이를 통해 단일 브로커의 성능 한계를 넘어 처리량과 저장 용량을 확장할 수 있다. 컨슈머 그룹은 여러 파티션에 걸쳐 메시지를 병렬로 소비할 수 있으며, 각 컨슈머는 일반적으로 하나 이상의 파티션을 전담하여 메시지를 읽는다.

프로듀서는 Kafka 클러스터에 데이터를 발행하는 클라이언트 애플리케이션이다. 프로듀서는 메시지를 특정 토픽으로 전송하며, 라운드 로빈 방식이나 메시지 키를 기반으로 한 해싱 방식 등을 사용하여 메시지를 파티션에 할당한다. 메시지 키를 지정하면 동일한 키를 가진 메시지는 항상 같은 파티션에 기록되어 순서가 보장된다. 프로듀서는 배치 전송, 압축, 재시도 메커니즘을 통해 높은 처리량과 신뢰성을 제공한다.

컨슈머는 토픽에서 데이터를 읽어 처리하는 클라이언트 애플리케이션이다. 컨슈머는 하나 이상의 컨슈머로 구성된 컨슈머 그룹의 일부로 동작하며, 그룹 내에서 파티션은 각 컨슈머에게 분배된다. 이를 통해 메시지 처리의 병렬성과 확장성을 달성한다. 컨슈머는 자신이 읽은 위치인 오프셋을 커밋하여 관리하며, 장애 발생 시 이 오프셋을 기반으로 복구할 수 있다.

프로듀서와 컨슈머는 완전히 분리되어 있으며, 서로를 알 필요 없이 토픽을 통해 데이터를 주고받는다. 이는 느슨한 결합을 가능하게 하는 Kafka의 핵심 설계 원칙이다. 컨슈머는 자신의 처리 속도에 맞춰 데이터를 풀(pull) 방식으로 가져오며, 이는 프로듀서의 속도에 영향을 받지 않고 배치 처리 등을 최적화할 수 있는 장점을 제공한다.

브로커는 아파치 카프카 시스템의 기본 실행 프로세스이자 서버 노드입니다. 각 브로커는 하나 이상의 토픽을 호스팅하며, 토픽 내 파티션의 리더 또는 팔로워 역할을 담당합니다. 브로커의 주요 역할은 프로듀서로부터 데이터를 수신하여 디스크에 저장하고, 컨슈머의 데이터 요청에 응답하여 메시지를 전달하는 것입니다. 또한 브로커는 다른 브로커들과 지속적으로 통신하여 클러스터 상태를 동기화하고, 리플리케이션과 ISR 메커니즘을 통해 내결함성을 유지합니다.

여러 대의 브로커가 모여 하나의 카프카 클러스터를 형성합니다. 클러스터는 시스템의 확장성과 가용성을 보장하는 핵심 단위입니다. 클러스터 내에는 모든 브로커의 메타데이터를 관리하고 파티션 리더 선출을 조정하는 특별한 브로커인 주키퍼 앙상블[1] 또는 컨트롤러가 존재합니다. 클라이언트(프로듀서/컨슈머)는 클러스터에 연결하여 특정 브로커와 직접 통신하며, 클러스터는 클라이언트에게 투명하게 작동합니다.

클러스터의 구성과 성능은 브로커의 수와 배치에 따라 결정됩니다. 일반적인 구성 요소는 다음과 같습니다.

클러스터를 운영할 때는 브로커 간의 네트워크 지연 시간을 최소화하고, 디스크 I/O 성능을 고려하여 브로커를 배치해야 합니다. 또한, 클러스터의 규모는 처리해야 할 데이터의 양과 가용성 요구사항에 따라 결정됩니다.

리플리케이션은 카프카가 제공하는 핵심적인 내결함성 메커니즘이다. 각 파티션의 데이터는 복제본을 생성하여 여러 브로커에 분산 저장함으로써, 단일 브로커 장애 시에도 데이터 유실과 서비스 중단을 방지한다. 복제본 중 하나는 리더로 선출되어 모든 읽기/쓰기 요청을 처리하며, 나머지는 팔로워로서 리더의 데이터를 비동기적으로 복제한다. 이 구조는 고가용성을 보장하면서도 일관된 읽기 지점을 제공한다.

리더와 팔로워의 상태를 관리하는 핵심 개념이 ISR(In-Sync Replica)이다. ISR은 리더와 동기화 상태를 유지하는 팔로워들의 집합을 의미한다. 팔로워는 주기적으로 리더에게 페치 요청을 보내 데이터를 복제하며, 리더는 이들의 상태를 추적한다. 설정된 임계값 내에서 리더를 따라잡지 못하거나 통신이 단절된 팔로워는 ISR에서 제외된다. ISR 내의 복제본만이 새로운 리더로 선출될 자격을 가진다.

리더 선출은 주로 브로커 장애 시 발생한다. 리더 브로커가 다운되면, 컨트롤러 역할을 하는 브로커가 ISR 목록에서 새로운 리더를 선출한다. 이때 ISR 내의 복제본만 후보가 되므로, 데이터 일관성이 보장된다. 리플리케이션 팩터는 일반적으로 3으로 설정하여 하나의 브로커 장애를 허용하는 구성이 일반적이다. 리플리케이션과 ISR 메커니즘은 카프카가 확장 가능하면서도 안정적인 분산 시스템으로 동작할 수 있는 기반을 제공한다.

Apache Kafka의 고성능 스트리밍 능력은 단일 브로커가 초당 수십만 건의 메시지를 처리하고, 클러스터 수준에서는 초당 수백만 건의 메시지 처리도 가능하도록 설계되었다. 이 성능은 디스크에 대한 순차적 읽기/쓰기 방식, 제로 카피 기술의 활용, 그리고 효율적인 배치 처리에 기반한다. 특히 메시지를 디스크에 저장하지만, 운영체제의 페이지 캐시를 적극 활용하여 메모리 접근 속도에 가까운 성능을 제공한다.

성능을 결정하는 핵심 요소는 다음과 같다.

이러한 설계 덕분에 Kafka는 기존의 메시지 큐 시스템보다 훨씬 높은 처리량을 제공하면서도, 디스크 기반의 영속성을 보장한다. 이는 실시간 로그 집계나 대규모 이벤트 소싱과 같이 높은 처리량과 데이터 안정성이 모두 요구되는 시나리오에서 결정적인 장점으로 작용한다.

Apache Kafka는 수평적 확장성과 높은 내결함성을 핵심 설계 원칙으로 삼는다. 확장성은 브로커라고 불리는 서버를 클러스터에 쉽게 추가함으로써 달성된다. 데이터는 토픽 단위로 분할되어 여러 브로커에 걸쳐 분산 저장되므로, 시스템의 처리 용량과 저장 용량을 선형적으로 증가시킬 수 있다. 이는 트래픽이 급증하는 상황에서도 추가 하드웨어 투입을 통해 대응할 수 있음을 의미한다.

내결함성은 리플리케이션 메커니즘을 통해 보장된다. 각 파티션의 데이터는 복제본을 여러 브로커에 분산 저장한다. 리더 파티션이 장애를 일으키면, ISR(In-Sync Replica) 목록에 있는 팔로워 파티션 중 하나가 새로운 리더로 자동 선출된다. 이 과정은 클라이언트에게 거의 투명하게 이루어지며, 데이터 유실 없이 서비스를 지속할 수 있다.

이러한 설계는 프로듀서와 컨슈머가 서로 직접 연결되지 않는 이벤트 기반 아키텍처의 이점과 결합된다. 시스템의 일부 구성 요소가 일시적으로 중단되더라도, Kafka 자체가 버퍼 역할을 하며 데이터를 안정적으로 보유한다. 결과적으로 전체 데이터 파이프라인의 가용성과 복원력이 크게 향상된다.

Apache Kafka는 데이터를 영구적으로 저장하는 로그 기반의 메시지 시스템으로, 데이터의 보존 기간과 삭제 방식을 제어하는 다양한 정책을 제공한다. 이러한 정책은 디스크 공간 관리와 데이터 접근성 간의 균형을 맞추는 데 핵심적이다.

데이터 보존의 기본 단위는 토픽이며, 주로 보존 기간(Retention Time)과 보존 크기(Retention Size) 두 가지 기준으로 설정된다. 가장 일반적인 방식은 retention.ms 설정을 통해 메시지가 브로커에 도착한 시점부터 특정 시간(예: 7일)이 지나면 자동으로 삭제하는 것이다. 대안으로 retention.bytes를 설정하여 특정 파티션이 지정된 크기(예: 1GB)에 도달하면 오래된 데이터부터 삭제할 수도 있다. 두 정책 중 먼저 충족되는 조건에 따라 데이터가 삭제된다. 또한, cleanup.policy 설정을 compact로 변경하면 키 기반 로그 압축(Log Compaction) 정책을 적용할 수 있다. 이 정책은 동일한 키를 가진 메시지 중 가장 최신의 값만을 유지하고 이전 값을 삭제하여, 각 키의 최종 상태를 유지하면서도 저장 공간을 효율적으로 관리한다[2].

이러한 정책은 운영 요구사항에 따라 세부적으로 조정된다. 실시간 분석 파이프라인에서는 짧은 보존 기간(몇 시간에서 몇 일)을, 이벤트 소싱이나 감사 로그 저장과 같은 경우에는 훨씬 긴 기간(수주에서 수개월) 또는 무제한 보존을 설정하기도 한다. 데이터 삭제는 백그라운드에서 주기적으로 수행되며, 설정된 보존 정책을 초과한 세그먼트 파일을 제거하는 방식으로 이루어진다. 관리자는 kafka-configs.sh 도구를 사용하거나 토픽 생성 시 옵션을 지정하여 토픽별로 보존 정책을 유연하게 구성할 수 있다.

실시간 데이터 파이프라인은 Apache Kafka의 가장 대표적인 사용 사례 중 하나이다. 이는 다양한 소스 시스템에서 발생하는 데이터를 실시간으로 수집, 처리, 변환하여 다른 시스템으로 전달하는 흐름을 구축하는 것을 의미한다. 기존의 배치 기반 데이터 처리와 달리, 데이터가 생성되는 즉시 파이프라인을 통해 흐르기 때문에 분석이나 의사 결정에 필요한 최신 정보를 거의 실시간에 가깝게 제공할 수 있다.

Kafka는 이러한 파이프라인의 중앙 허브 역할을 한다. 프로듀서는 데이터베이스 변경 로그, 애플리케이션 로그, 센서 데이터, 웹사이트 클릭 스트림 등 다양한 소스에서 데이터를 실시간으로 토픽에 발행한다. 반면, 컨슈머는 해당 토픽을 구독하여 데이터를 읽어와 실시간 분석 시스템, 검색 인덱스, 데이터 웨어하우스, 알림 시스템 등 다양한 목적지로 전송한다. 이 구조는 소스와 목적지 시스템 간의 직접적인 결합을 제거하여 시스템의 유연성과 확장성을 크게 향상시킨다.

실시간 데이터 파이프라인의 일반적인 구성 요소와 Kafka의 역할은 다음과 같다.

이러한 파이프라인을 통해 기업은 고객 행동 분석, 사기 탐지, 시스템 상태 모니터링, 실시간 추천 엔진 등 다양한 실시간 애플리케이션을 구축할 수 있다. Kafka의 높은 처리량과 낮은 지연 시간, 그리고 강력한 내구성은 실시간 데이터 흐름의 핵심 요구사항을 충족시키는 데 기여한다.

이벤트 기반 아키텍처(Event-Driven Architecture, EDA)는 시스템의 구성 요소 간 통신이 이벤트의 생산, 감지, 소비 및 반응을 통해 이루어지는 소프트웨어 설계 패러다임이다. Apache Kafka는 이러한 아키텍처를 구현하는 데 있어 핵심적인 이벤트 브로커 또는 이벤트 백플레인의 역할을 한다. 이벤트는 시스템 내에서 발생한 상태 변화나 중요한 사건을 나타내는 기록이며, Kafka는 이러한 이벤트 메시지를 안정적으로 저장하고 배포하는 플랫폼을 제공한다.

이 아키텍처에서 프로듀서는 특정 토픽에 이벤트를 발행한다. 이벤트를 필요로 하는 다양한 컨슈머 애플리케이션은 해당 토픽을 구독하여 독립적으로 이벤트를 처리한다. 이는 전통적인 동기식 요청-응답 모델과 달리, 발행자와 구독자 간의 느슨한 결합을 가능하게 한다. 하나의 이벤트가 발행되면, 여러 하류 시스템이 각자의 속도와 비즈니스 로직에 따라 이를 처리할 수 있다.

이 접근 방식은 복잡한 분산 시스템을 구성하는 데 유리한 특성을 제공한다. 시스템의 확장성이 향상되며, 새로운 기능을 추가하더라도 기존 시스템을 크게 변경하지 않고 새로운 컨슈머를 연결하기만 하면 된다. 또한 장애가 발생한 특정 서비스가 다른 서비스의 정상 작동에 직접적인 영향을 미치지 않는 격리성을 제공한다. 마이크로서비스 아키텍처와의 조합이 특히 효과적인 이유이다.

일반적인 사용 패턴으로는 주문 생성, 재고 변경, 사용자 활동 추적과 같은 도메인 이벤트의 전파가 있다. 예를 들어, '주문 완료' 이벤트가 발행되면, 재고 관리, 배송 준비, 포인트 적립, 분석 데이터베이스 동기화 등 여러 서비스가 이를 동시에 구독하여 각자의 작업을 수행한다.

로그 집계는 Apache Kafka의 가장 대표적이고 초기부터 널리 사용된 사용 사례 중 하나이다. 이는 다수의 서버나 분산 시스템에서 생성되는 방대한 양의 로그 데이터를 중앙에서 실시간으로 수집, 저장, 처리하기 위한 목적으로 활용된다.

기존의 로그 수집 방식은 각 애플리케이션 서버에 로그 파일을 기록하고, 이를 주기적으로 수집하여 HDFS나 S3 같은 저장소에 옮기는 배치 처리 방식이 일반적이었다. 반면, 카프카를 사용하면 애플리케이션은 로그 메시지를 프로듀서를 통해 카프카 토픽에 실시간으로 발행한다. 각 로그 유형(예: 애플리케이션 로그, 시스템 로그, 접근 로그)은 별도의 토픽으로 구분될 수 있다. 이후 컨슈머를 통해 Elasticsearch, Splunk 같은 검색 및 분석 시스템으로 전송하거나, Hadoop 클러스터로 보내 대규모 배치 분석을 수행할 수 있다.

이 방식은 몇 가지 뚜렷한 장점을 제공한다. 첫째, 로그 생성 애플리케이션과 로그 소비 시스템 간의 결합도를 낮춘다. 애플리케이션은 단지 카프카에 로그를 보내기만 하면 되며, 로그의 최종 저장소나 처리 방식이 변경되어도 애플리케이션 코드를 수정할 필요가 없다. 둘째, 높은 처리량과 실시간성을 보장한다. 카프카의 고성능 스트리밍 특성으로 인해 초당 수백만 건의 로그 메시지를 처리할 수 있다. 셋째, 내결함성과 데이터 안정성을 제공한다. 리플리케이션을 통해 로그 데이터가 손실되지 않도록 보장하며, 컨슈머 장애 시에도 오프셋을 통해 중단 지점부터 다시 처리할 수 있다.

결과적으로, 카프카는 로그 데이터의 통합된 허브 역할을 수행하며, 신뢰할 수 있고 확장 가능한 로그 집계 인프라의 핵심 구성 요소로 자리 잡았다.

카프카 클러스터는 여러 대의 브로커로 구성된다. 일반적으로 프로덕션 환경에서는 최소 3개 이상의 브로커로 클러스터를 구성하여 내결함성을 확보한다. 각 브로커는 고유한 ID로 식별되며, 하나 이상의 주키퍼 또는 KRaft[3] 앙상블에 연결되어 메타데이터 관리와 컨트롤러 선출 등의 조정 작업을 수행한다.

클러스터 구성 시 주요 고려 사항은 브로커의 수, 하드웨어 사양, 네트워크 구성이다. 브로커 수는 필요한 처리량, 복제 팩터, 가용성 요구사항에 따라 결정된다. 하드웨어 측면에서는 디스크 I/O 성능이 가장 중요한 요소이며, SSD 사용이 권장된다. 네트워크는 브로커 간, 그리고 프로듀서/컨슈머와의 통신에 충분한 대역폭과 낮은 지연 시간을 보장해야 한다.

구성 파일(server.properties)을 통해 각 브로커의 세부 설정을 관리한다. 필수 설정 항목은 다음과 같다.

클러스터를 배포한 후에는 kafka-topics.sh와 같은 명령줄 도구를 사용해 토픽을 생성하고, 파티션 수와 리플리케이션 팩터를 설정하며, 브로커와 토픽의 상태를 모니터링한다. 클러스터에 브로커를 추가하거나 제거하는 작업은 온라인 상태에서도 가능하며, 이를 통해 시스템의 확장성을 유연하게 관리할 수 있다.

카프카 클러스터의 안정적인 운영과 최적의 성능을 보장하기 위해서는 지속적인 모니터링과 체계적인 성능 튜닝이 필수적이다. 주요 모니터링 지표는 브로커, 프로듀서, 컨슈머 각각에 집중해야 한다. 브로커 수준에서는 네트워크 및 디스크 I/O, CPU 사용률, JVM 가비지 컬렉션 빈도와 지연 시간, 파티션의 리더 불균형 여부, ISR 크기 변화 등을 점검한다. 프로듀서와 컬슈머 측면에서는 프로듀서의 전송 지연, 재시도율, 컬슈머의 지연 및 처리량이 핵심 지표이다. 이러한 지표는 JMX를 통해 노출되며, Prometheus, Grafana와 같은 도구를 활용해 대시보드를 구성하고 이상 징후에 대한 알림을 설정하는 것이 일반적이다.

성능 튜닝은 하드웨어 구성, 카프카 구성, 애플리케이션 구성의 세 가지 차원에서 접근한다. 하드웨어 차원에서는 고성능 SSD 사용, 충분한 메모리 확보, 네트워크 대역폭 확장이 기본이다. 카프카 브로커 구성에서는 num.network.threads, num.io.threads, log.flush.interval.messages, log.flush.interval.ms 등의 파라미터를 워크로드에 맞게 조정하여 처리량과 지연 시간의 균형을 찾는다. 또한, 적절한 리플리케이션 팩터 설정과 파티션 개수 산정은 병렬 처리 성능과 내결함성을 결정하는 핵심 요소이다.

애플리케이션 측면의 튜닝도 중요하다. 프로듀서는 batch.size, linger.ms, compression.type 설정을 통해 네트워크 왕복 횟수를 줄이고 압축 효율을 높일 수 있다. 컬슈머는 fetch.min.bytes, max.poll.records 설정을 조정하여 폴링 효율을 개선하고, 적절한 컬슈머 그룹 내 인스턴스 수를 설정하여 파티션 소비를 균등하게 분배해야 한다. 성능 튜닝은 일회성 작업이 아니라, 데이터 양과 패턴의 변화에 따라 지속적으로 검증하고 최적화해야 하는 과정이다.

Apache Kafka는 SSL/TLS 또는 SASL을 통한 인증을 지원하여 클라이언트와 브로커 간의 신원을 확인한다. 주요 SASL 메커니즘으로는 SASL/PLAIN, SASL/SCRAM, SASL/GSSAPI (Kerberos) 등이 있다. 이를 통해 프로듀서, 컨슈머, 관리 도구 등이 클러스터에 접근하기 전에 자신을 증명해야 한다.

인증된 사용자나 애플리케이션에 대한 접근 제어는 ACL을 통해 이루어진다. ACL은 특정 리소스 (예: 토픽, 컨슈머 그룹, 클러스터)에 대해 특정 작업 (예: 읽기, 쓰기, 생성, 삭제)을 허용하거나 거부하는 규칙이다. ACL은 사용자, 그룹 또는 모든 사용자(*)를 대상으로 설정할 수 있으며, 기본 정책은 모든 접근을 허용하거나 거부하도록 구성할 수 있다.

ACL 관리는 kafka-acls 명령줄 도구를 사용하거나, Kafka Broker 설정 파일을 통해 수행할 수 있다. ACL 정보는 ZooKeeper 또는 Kafka 자체의 내부 토픽(__cluster_metadata)에 저장된다. 보안 강화를 위해 RBAC와 같은 더 세분화된 권한 모델을 제공하는 Confluent Platform과 같은 상용 배포판도 존재한다.

Apache Kafka 클러스터 내에서 데이터의 기밀성과 무결성을 보호하기 위해 전송 중 암호화와 저장 데이터 암호화를 지원합니다. 전송 계층 보안(TLS, 이전의 SSL)은 브로커와 클라이언트(프로듀서, 컨슈머, 기타 도구) 간의 통신, 그리고 브로커 간 통신을 암호화하는 데 사용됩니다. 이를 통해 네트워크 스니핑으로부터 데이터를 보호합니다.

데이터 저장 단계에서의 암호화는 Kafka 자체 기능보다는 일반적으로 외부 시스템에 의존합니다. 예를 들어, 토픽 데이터가 저장되는 디스크 볼륨 수준에서 전체 디스크 암호화(FDE)를 적용하거나, 운영 체제나 클라우드 공급자의 암호화 파일 시스템을 활용합니다. 이는 물리적 미디어 분실이나 서버 해킹 시 데이터가 유출되는 것을 방지합니다.

암호화 구성은 server.properties 및 클라이언트 설정 파일에서 수행됩니다. 전송 암호화를 위해 TLS 인증서를 구성하고, 보안 프로토콜(SSL 또는 SASL_SSL)을 지정해야 합니다. 암호화는 성능 오버헤드를 동반할 수 있으므로, 보안 요구사항과 처리량 및 지연 시간 요구사항 사이의 균형을 고려하여 적용해야 합니다.

Kafka Connect는 Apache Kafka와 외부 시스템(예: 데이터베이스, 클라우드 스토리지, 검색 인덱스) 간에 데이터를 안정적으로 스트리밍하기 위한 프레임워크이다. 이 도구는 Kafka 클러스터와 다른 시스템 사이에서 데이터 커넥터를 실행하기 위한 표준화된 방법을 제공하여, 반복적인 데이터 통합 작업을 단순화한다. 커넥터는 소스 커넥터와 싱크 커넥터 두 가지 주요 유형으로 나뉜다. 소스 커넥터는 외부 시스템에서 데이터를 읽어 Kafka 토픽으로 전송하고, 싱크 커넥터는 Kafka 토픽의 데이터를 소비하여 외부 시스템에 쓴다.

Kafka Connect의 핵심 장점은 확장성과 관리 용이성에 있다. 이는 분산 모드 또는 독립 실행형 모드로 실행될 수 있다. 분산 모드에서는 여러 워커 노드에 걸쳐 커넥터 작업을 분산시켜 확장성과 내결함성을 제공한다. 또한 REST API를 통해 커넥터를 쉽게 배포, 구성, 모니터링할 수 있어 운영 부담을 크게 줄인다. 커넥터는 단일 태스크 또는 다중 태스크로 실행될 수 있으며, 각 태스크는 데이터 처리의 일부를 담당하여 병렬 처리를 가능하게 한다.

커넥터 생태계는 매우 풍부하며, Confluent Hub와 같은 커뮤니티 플랫폼을 통해 다양한 사전 제작 커넥터를 제공한다. 주요 커넥터의 예는 다음과 같다.

또한 Kafka Connect는 데이터 변환과 오류 처리를 위한 단일 메시지 변환 기능을 지원하며, Exactly-Once Semantics를 보장할 수 있다. 이를 통해 복잡한 ETL 파이프라인을 구축하지 않고도 신뢰할 수 있는 실시간 데이터 통합 플랫폼을 구성할 수 있다.

Kafka Streams는 Apache Kafka 클러스터에 저장된 데이터를 실시간으로 처리하기 위한 클라이언트 라이브러리이다. 이 라이브러리는 Kafka를 스트림 처리 플랫폼으로 확장하는 핵심 구성 요소 중 하나로, 별도의 외부 처리 클러스터 없이도 Kafka 토픽의 데이터를 읽고, 변환하고, 집계하여 다른 토픽에 다시 쓸 수 있는 기능을 제공한다. Java와 Scala 애플리케이션에 내장되어 실행되며, 마이크로서비스나 독립 실행형 애플리케이션의 형태로 배포된다.

주요 기능으로는 상태 저장(stateful) 및 상태 비저장(stateless) 연산, 윈도우 기반 집계, 조인 연산 등이 포함된다. 예를 들어, 사용자 클릭 스트림을 실시간으로 집계하거나, 여러 관련 스트림의 데이터를 결합하는 작업을 쉽게 구현할 수 있다. 내부적으로는 토폴로지를 구성하는 태스크 단위로 병렬 처리를 수행하며, 상태 저장 연산을 위한 로컬 RocksDB 저장소를 활용한다.

다른 스트림 처리 프레임워크와 비교했을 때, Kafka Streams는 Kafka와 긴밀하게 통합되어 있다는 점이 특징이다. 카프카 컨슈머 그룹 프로토콜을 기반으로 자동으로 확장성과 내결함성을 제공하며, Exactly-Once Semantics(정확히 한 번 처리)를 지원한다. 또한 DSL(고수준 선언형 API)과 Processor API(저수준 명령형 API) 두 가지 프로그래밍 모델을 제공하여 개발자의 요구에 맞는 유연성을 보장한다.

Kafka Streams 애플리케이션은 이벤트 스트림을 실시간으로 변환하거나, KTable을 통해 최신 상태의 뷰를 유지하는 등 복잡한 스트림 처리 로직을 구축하는 데 널리 사용된다. 이는 Kafka Connect나 Schema Registry와 함께 Kafka 에코시스템을 구성하는 중요한 요소이다.

Schema Registry는 아파치 카프카 생태계에서 Avro, JSON Schema, Protobuf와 같은 스키마를 중앙에서 저장하고 관리하기 위한 서버 애플리케이션이다. 이는 Confluent 플랫폼의 핵심 구성 요소로 개발되었으며, 데이터 직렬화와 호환성 보장을 위한 표준화된 접근 방식을 제공한다. 프로듀서와 컨슈머는 Schema Registry에 등록된 스키마를 참조하여 데이터를 직렬화하거나 역직렬화한다. 이를 통해 페이로드 크기를 줄이고, 데이터 형식의 일관성을 유지하며, 스키마의 진화를 안전하게 관리할 수 있다.

주요 기능은 스키마의 버전 관리와 호환성 검사이다. 새로운 스키마가 등록될 때, Schema Registry는 구성된 호환성 정책(예: 백워드 호환성, 포워드 호환성, 풀 호환성)에 따라 기존 버전과의 호환성을 자동으로 검증한다. 호환성 검사를 통과하지 못하면 등록이 거부되어 데이터 파이프라인의 중단을 방지한다. 또한 스키마 ID를 통해 스키마를 효율적으로 조회할 수 있으며, RESTful API를 제공하여 다양한 클라이언트와 통합이 용이하다.

사용 시 이점은 명확하다. 데이터 형식의 불일치로 인한 오류를 사전에 방지하고, 스키마 에볼루션을 지원하여 장기적으로 운영되는 시스템의 유지보수성을 높인다. 또한 Avro와 같은 이진 형식을 사용할 때 스키마 정보를 매 메시지에 포함시키지 않고 짧은 스키마 ID만 전송하면 되므로 네트워크 대역폭과 저장 공간을 절약할 수 있다. Schema Registry는 데이터 거버넌스와 데이터 계약을 실현하는 데 중요한 역할을 한다.