데이터 스트리밍의 중요성
데이터 스트리밍은 데이터가 생성되는 즉시 지속적으로 데이터를 수집, 처리, 분석하는 기술을 말합니다.
해당 방법은 전통적인 배치 처리 방식과 대비되며, 실시간으로 정보를 파악하고 즉각적인 피드백 루프를 생성할 수 있다는 점이 가장 큰 장점입니다. 아래는 스트리밍 데이터 처리가 쓰이고 있는 예시입니다.
예를 들어, 금융 서비스 업계에서는 주식 시장의 변동을 실시간으로 감지하고 자동으로 거래를 실행하는 알고리즘 거래 시스템이 필요합니다. 또한, 전자상거래 플랫폼은 사용자의 클릭스트림 데이터를 실시간으로 분석하여 개인화된 상품 추천을 제공해야 합니다.
이처럼 최신에 들어서는, 웬만한 기업은 서비스의 원활한 운영과 실시간 데이터 분석을 위해 스트리밍 데이터를 처리하려고 노력하고, Kafka나 Flink와 같은 프레임워크를 하나 이상 채용하여 사용하고 있습니다.
본 글의 말미에는 가장 인기있는 스트리밍 데이터 처리 프레임워크인 Kafka 를 소개할 예정입니다.
그 전에, 스트리밍 데이터에 대한 이해를 위해 필요한 주요 개념들 (ex: EDA, Topic, Micro-batch, etc)을 먼저 설명하려고 합니다.
가장 먼저 스트리밍 데이터 플랫폼을 알아보기 위해 필요한 개념은 이벤트 기반 아키텍처 (Event-Driven-Architecture) 입니다.
이벤트 기반 아키텍처 (Event-Driven-Architecture)
비즈니스는 수도 없이 많은 동적인 사건들의 발생으로 이루어져 있습니다. 유저의 회원가입부터 로그인, 장바구니 담기, 상품 구매, 상품 재구매 까지 모두 이벤트의 일종이라고 볼 수 있습니다.
이벤트 기반 워크플로우에서는 데이터 엔지니어링 수명 주기의 다양한 부분에서 이벤트를 생성, 라우팅, 소비의 프로세스가 진행됩니다.
이벤트 기반 아키텍처에서는 위에서 설명한 워크플로우를 기반으로 다양한 서비스간 통신을 진행합니다.
출처: https://akasai.space/architecture/about_event_driven_architecture/
해당 아키텍처의 장점은 이벤트의 상태를 여러 서비스에 분산시키기 때문에, 오프라인 상태가 되거나, 분산 시스템에서 노드에 장애가 발생하거나, 여러 소비자 또는 서비스가 동일한 이벤트에 접근하도록 할 때 유용하다는 점입니다. 보통, 서비스가 느슨하게 결합된 경우에는 항상 이벤트 중심 아키텍처를 포함합니다.
이벤트 기반 아키텍처는 아래와 같은 이유로 인기가 더욱 높아지고 있습니다.
- 이벤트 기반 아키텍처의 핵심 계층인 메시지 큐와 이벤트 스트리밍 플랫폼은 클라우드 환경에서 더 쉽게 설정하고 관리 가능
- 실시간 분석을 직접 통합하는 어플리케이션인 데이터 앱의 증가
핵심적으로, 이벤트 기반 아키텍처는 이벤트가 어플리케이션 작업을 트리거하고 실시간에 가까운 분석을 제공할 수 있습니다.
또한, 데이터 수집과 변환 단계에서도 원천 시스템에서 메시지 전달을 위해 사용했던 것과 같은 이벤트 스트리밍 플랫폼을 사용하여 실시간 분석을 위한 데이터를 처리할 수 있다는 점이 주요합니다.
메시지 큐와 스트리밍 플랫폼
이벤트 기반 아키텍처와 관련하여 메시지 큐와 스트리밍 플랫폼이라는 용어가 있는데, 혼용되는 경우가 많습니다.
메시지 & 메시지 큐
먼저, 메시지는 이벤트 기반 시스템에서 불연속적이고 단일한 신호의 일종으로, 둘 이상의 시스템 간에 전달되는 원시 데이터입니다.
메시지 큐는 게시 및 구독 모델을 사용하여 개별 시스템 간에 데이터를 비동기적으로 전송하는 메커니즘입니다.
기본적으로, 데이터는 메시지 큐에 게시되어 1명 이상의 구독자에게 전달되고, 메시지가 수신되면 큐에서 삭제됩니다.
메시지 큐를 사용하면 어플리케이션과 시스템을 서로 분리할 수 있어, 보통 MSA 환경에서 많이 사용됩니다.
메시지 큐는 메시지를 버퍼링해 일시적인 부하 급증을 처리하고, 복제 기능을 갖춘 분산 아키텍처를 통해 메시지를 내구성 있게 보존합니다. 메시지 큐에서는 메시지 순서 지정, 전달 빈도에 대한 개념이 중요합니다.
메시지 순서 지정
메시지가 생성, 전송, 수신되는 순서는 다운스트림 사용자에게 큰 영향을 미칠 수 있는데, 사실 분산 메시지 큐의 순서는 까다로운 문제입니다.
메시지 큐는 종종 모호한 순서와 선입선출 (FIFO) 개념을 적용합니다. 당연히 엄격하게 FIFO가 적용되면 먼저 들어온 메시지가 후에 들어온 메시지보다 먼저 수신될테지만, 고도로 분산된 시스템에서 잘못된 순서로 게시되거나 수신될 수 있습니다.
당연한 말이겠지만, 위 문제는메시지 큐 기술이 순서를 보증해줘야만 해결해 줄 수 있다. (ex: AWS SQS 표준 큐의 오버헤드 관리)
전달 빈도
메시지는 정확히 한번 발송되면 사용자가 메시지를 확인한 뒤 메시지는 사라지며 다시 전달되지 않고, 적어도 한번 송신된 메시지는 여러 명의 유저 또는 같은 유저가 2회 이상 소비할 수 있습니다.
따라서, 사용자가 메시지를 완전히 처리했지만, 처리를 확인하기 전에 실패할 때에 대한 대응을 적절히 할 수 있을 것입니다.
이상적으로는 시스템이 멱등성 상태여야 하고, 그러한 상태라면 메시지를 여러 번 처리한 결과와 한번 처리한 결과는 같을 것입니다.
스트림 & 스트리밍 플랫폼
이벤트는 ‘일반적으로 어떤 상태의 변화와 같은 무언가가 발생한 것’이고 단일 이벤트는
key,value,timestamp와 같은 특성을 포함합니다.
스트림은 이벤트 레코드의 추가 전용 로그입니다. 이벤트가 발생하면 순서대로 누적되며, timestamp 또는 id로 이벤트 순서를 정렬할 수 있고, 여러 이벤트에 걸쳐 무슨 일이 일어났는지를 살펴볼 때 스트림을 사용할 수 있습니다.
메시지와 스트림은 pub → sub구조로 메시지를 전달한다는 점에서 유사하지만, 가장 큰 차이는 메시지 큐가 주로 특정 전달을 보장하는 메시지 라우팅에 사용된다는 것이다. 이벤트 스트리밍 플랫폼은 정렬된 레코드 로그에서 데이터를 수집하고 처리하는데 사용됩니다.
스트림의 추가 전용 특성으로 인해 레코드는 장기적인 보존 기간에 걸쳐 유지되므로, 여러 레코드의 집계 또는 스트림 내 특정 시점으로 rollback 기능과 같은 레코드의 복잡한 프로세스를 실행할 수 있습니다.
스트림을 처리하는 시스템은 메시지를 처리할 수 있으며, 스트리밍 플랫폼은 메시지 전달에 자주 사용됩니다.
또한, 위에서 언급했다시피 메시지 분석을 수행할 때는 메시지를 스트림에 축적하고, 나중에 특정 값에 대한 추세와 통계를 확인할 수 있습니다.
이제부터는, 이벤트 스트리밍 플랫폼에서 몇 가지 중요한 특성에 대해 설명하려고 합니다. Kafka를 포함해서 거의 모든 실시간 처리 프레임워크에서도 동일한 특성과 개념이 통용됩니다.
토픽 (Topic)
스트리밍 플랫폼에서 생산자는 관련 이벤트 모음인 토픽에 이벤트를 스트리밍합니다.
사실, 토픽을 여러 개 두거나 하나의 토픽에 여러 생산자를 할당하거나 하는 제한은 없고 보통 개발자가 환경에 맞게 설정하면 됩니다. 나의 경우로는, 암호화폐 거래소 별로 비트코인의 시장가를 포함한 여러 정보를 Kafka를 이용하여 실시간 처리하는 프로젝트를 진행하였는데 (엄밀히 말하면 마이크로 배치ㅎ), 거래소 별로 토픽을 할당하였다.
‘견고한 데이터 엔지니어링’ 책에서는 토픽 개념을 설명하기 위해서 일종의 주문처리 시스템을 가정하고, web orders라는 토픽, marketing과 fulfillment(주문처리)라는 생산자를 설정합니다.
fulfillment 구독자 (sub)은 이벤트를 사용해 주문 처리 프로세스를 트리거하고, marketing은 실시간 분석을 실행하거나 마케팅 캠페인을 조정하기 위해 ML 모델을 학습하고 실행할 것입니다. 글 말미에 추가로 설명하겠지만, 현업에서 위와 같은 상황이라면 보통 web orders 토픽 생산자를 Kafka, marketing을 processing하는 역할로 Spark Streaming로 처리하는 사례가 많은 것 같다.
스트림 파티션 (Stream Partition)
스트림 파티션은 스트림을 여러 스트림으로 분할(partition)한 것입니다.
메시지는 파티션 키에 따라 파티션 간에 분산되고, 파티션 키가 같은 메시지는 항상 같은 파티션에 저장됩니다.
일종의 MongoDB의 해쉬 인덱스나 해쉬 테이블처럼, 함께 처리해야 할 메시지끼리 동일한 파티션 키를 설정하여 분산시킨다고 생각하면 됩니다.
그러나, 우리는 이때 자연스럽게 특정 파티션에 메시지가 몰리는 상황이 아마 떠오를 것입니다. 이것을 hotspotting현상 이라고 합니다. 파티션 하나에 전달되는 메시지의 수가 불균형한 현상인데, 파티션 키를 적절하게 조절하며 해당 현상을 방지해야할 것이다.
내결함성과 복원성
이벤트 스트리밍 플랫폼은 일반적으로 다양한 노드에 스트림이 저장되는 분산형 시스템입니다. 따라서, 노드가 다운되면 다른 노드가 해당 노드를 대체해 스트림에 계속 접근 할 수 있는데, ‘견고한 데이터 엔지니어링’ 책에서는 이러한 특성을 내결함성과 복원성이라고 칭합니다. 이러한 특성 때문에, 이벤트 스트리밍 플랫폼은 이벤트 데이터를 안정적으로 생성, 저장 및 수집할 수 있는 시스템이 필요할 때 좋은 선택이 될 수 있습니다.
스트리밍 스토리지
최초의 실시간 쿼리 엔진은 어떻게 보면 OLTP기반의 트랜잭션 데이터베이스라고 볼 수 있다. 하지만, 대량에 데이터에 걸쳐 실행되는 분석 쿼리의 경우 확장 및 잠금의 제한으로 대용량에 적합한 쿼리를 실행시키기 어렵습니다.
기본적으로 스트리밍 데이터는 배치성 데이터와 스토리지 요구 사항이 다릅니다.
(배치 데이터에 대한 스토리지 개념은 DW/DL, HDFS, Spark, iceberg에 대한 내용과 결합하여 다른 포스팅을 통해 소개드리려고 합니다 🙂)
메시지 큐의 경우, 저장된 데이터는 일시적이며 일정기간이 지나면 사라질 것으로 예상되지만, Kafka와 같이 분산되고 확장 가능한 스트리밍 프레임워크는 매우 오랜 기간 동안 스트리밍 데이터를 보존할 수 있습니다.
Kafka는 자주 접근하지 않는 오래된 메시지를 객체 스토리지에 푸쉬해 무기한 데이터 보존을 지원하는데, 이러한 기능은 AWS Kinesis나 GCP Pub/Sub도 지원한다.
위와 같은 데이터 스토리지 특성은 리플레이 개념과 연관되어 있습니다.
리플레이
리플레이는 스트리밍 스토리지 시스템의 표준 데이터 검색 메커니즘입니다.
리플레이를 사용하면 스트리밍 시스템에 저장된 과거 데이터의 범위를 반환할 수 있기 때문에, 시간범위에 걸쳐 배치 쿼리를 실행하거나 스트리밍 파이프라인에서 데이터를 재처리하는 데 사용할 수 있습니다.
Kafka와 AWS Kinesis나 GCP Pub/Sub은 모두 이벤트 보존 및 리플레이를 지원하지만, RabbitMQ 같은 경우에는 일반적으로 모든 사용자가 메시지를 소비한 후 메시지를 삭제합니다.
Stream-to-Batch 스토리지 아키텍처
Stream-to-Batch 스토리지 아키텍처는 람다 아키텍처와 유사점이 있지만, 해당 아키텍처는 기본적으로 스트리밍 스토리지 시스템의 토픽을 통과하는 데이터는 여러 소비자에게 기록되는 형태입니다.
이러한 소비자 중 일부는 스트림에 대한 통계를 생성하는 실시간 처리 시스템일 것입니다.
배치 데이터의 흐름은 아래와 같을 것입니다.
배치 스토리지 사용자는 장기 보전 및 배치 쿼리를 위해 데이터를 쓸 것이고 배치 소비자는 시간이나 배치의 크기에 대한 설정 가능한 트리거에 근거해 S3 객체를 생성할 수 있는 AWS Kinesis Firehose와 같은 시스템이 될 수 있습니다.
BigQuery와 같은 시스템은 스트리밍 데이터를 스트리밍 버퍼로 수집합니다. 이 스트리밍 버퍼는 자동으로 컬럼형 객체 스토리지로 다시 초기화 될 것이고, 쿼리 엔진은 스트리밍 버퍼와 객체 데이터 모두에 대한 원활한 쿼리를 지원해 사용자에게 거의 실시간에 가까운 최신 테이블 뷰를 제공할 수 있습니다.
스트리밍 데이터 처리 시 고려해야 할 사항
메시지와 스트림은 늘 유동적
스트리밍 데이터에 대한 수집은 데이터의 게시, 소비, 재게시, 재소비와 함께 비선형적일 수 있습니다. 따라서, data flow를 충분히 고려하여 실시간 데이터 파이프라인을 구성해야합니다.
또한, 대부분의 데이터의 형태가 JSON과 같은 반정형 구조일 확률이 높으므로, 페이로드의 스키마가 즉흥적으로 변경될 수 있습니다. 생산자 쪽에서 새로운 필드를 도입한 구조의 데이터를 송신하면, 대상이 되는 DW나 처리 파이프라인이 인식하지 못하는 상황은 좋지 않기 때문에 유연한 스키마를 유지하는 것이 중요합니다.
추가로, 후에 설명할 CDC 시스템의 경우에도 필드를 다른 타입으로 (예: 국제표준화기구의 날짜/시간 datetime형식 대신 문자열로) 리캐스팅하는 이슈가 존재할 수 있다.
처리량에 대한 모니터링
메시지와 이벤트는 가능한 짧은 지연시간 (latency)를 통해 흐르게 해야 합니다. 즉, 적절한 파티션이나 샤드에 대한 대폭과 처리량을 프로비저닝 할 줄 알아야 합니다.
그렇기에, 이벤트 처리에 충분한 메모리, 디스크 및 CPU 자원을 제공하고, 실시간 파이프라인을 관리할 때는 자동 계산 기능을 사용해 트래픽의 급상승에 대처하고 부하 감소에 따른 비용도 절감해야 합니다. 때문에 스트리밍 플랫폼 관리에는 배치 플랫폼보다 오버헤드가 발생할 여지가 많습니다.
마이크로 배치 vs 진짜 Real-time
요즘말로 하면 ‘성능이 좋은 서버에서 실행되는 REST API는 소켓 통신과 구별할 수 없다’ 이런 느낌일까?
사실 우리가 ‘실시간’ 이라고 칭했던 것들이 대부분 ‘마이크로 배치’ 형태였을 가능성이 높습니다.
마이크로 배치는 배치 지향 프레임워크를 스트리밍 상황에 적용하는 방법으로, 2분 간격에서 1초 간격까지 실행할 수 있습니다. Spark Streaming과 같은 것이 대표적인 마이크로 배치 프레임워크라고 볼 수 있는데, 높은 배치 빈도로 자원을 적절히 할당하면 실시간과 유사한 성능을 발휘할 수 있습니다.
아래 사진은 DataFrame을 기반으로 스트리밍 처리하는 Structured Streaming의 예시입니다.
진정한 Real-time을 구현하는 스트리밍 시스템인 Flink Streaming은 하나의 이벤트를 처리하도록 설계되었습니다. (물론 exactly once 전달은 Spark Streaming도 동일하게 적용되기는 한다)
그렇기에, 오베헤드가 상당할 것으로 쉽게 예상할 수 있습니다.
그러나, Flink Streaming의 경우에도 개별 이벤트에 데이터를 추가하는 기본적인 강화 프로세스에서는 지연시간이 짧은 이벤트를 한 번에 하나씩 전달할 수 있기 때문에 역설적이게도 여전히 많은 배치 프로세스가 발생합니다.
그래서 사실 당연히 정답이 없을 뿐더러, 개인적인 생각으로는 두 기술을 엄격하게 구별시키는 것도 큰 의미는 없을 것 같습니다.
(여담으로, 마이크로 배치라는 용어 자체가 경쟁기술을 배제하기 위해 사용되기도 하였다고 한다.)
결론적으로, 각자의 환경에 맞게 도메인 지식이 어느정도 받쳐주는지를 고려하면서 시스템의 요구사항을 적절하게 해소하면 된다고 생각한다 :)
변경 데이터 캡처 (Changed Data Capture)
사실, 스트림에는 이벤트 스트림과 CDC라는 두 가지 주요 유형이 존재한다.
CDC는 데이터베이스에서 발생하는 각 변경 이벤트(예: CRUD)를 추출하는 방법으로, DB 간에 거의 실시간으로 복제하거나 다운스트림 처리를 위한 이벤트 스트림을 생성하는 데 자주 사용됩니다.
흔히, 요즘 데이터엔지니어링 분야에서 많이 언급되는 트렌드인 Zero-ETL을 구축한다고 하면, CDC가 기술적 배경이 될 확률이 높습니다.
CDC는 DB의 종류에 따라 다르게 처리됩니다.
RDBMS의 경우는 스트림을 생성하기 위해 처리될 수 있는 이벤트 로그를 종종 생성해 DB 서버에 직접 저장하고, 많은 클라우드NoSQL의 경우는 로그 또는 이벤트 스트림을 목표로 하는 스토리지 위치로 전송할 수 있습니다.
많은 CDC의 형태가 있지만, 스트리밍 데이터의 관점에서 볼 때는 연속 CDC 개념을 살펴보아야 합니다.
연속 CDC
연속 CDC는 모든 테이블 이력을 캡처해 실시간 데이터베이스 복제 또는 실시간 스트리밍 분석을 위한 거의 실시간 데이터 수집을 지원합니다.
일반적으로 연속 CDC는 정기적인 쿼리를 실행해 테이블 변경사항을 일괄적으로 가져오는 것이 아니라, 데이터베이스에 대한 각 쓰기를 이벤트로 처리합니다.
OLTP기반의 RDBMS를 대상으로 연속 CDC 이벤트 스트림을 캡쳐하기 위해 사용하는 것은 보통 로그 기반 CDC 입니다.
출처: https://www.striim.com/blog/log-based-change-data-capture/
데이터베이스 이진 로그는 데이터베이스의 모든 변경 사항을 순차적으로 기록하기 때문에, CDC 도구는 이 로그를 읽고 이벤트 형식으로 Debezium과 같은 플랫폼을 타깃으로 전송하게 됩니다. (여기서 말하는 이진 로그는 우리가 MySQL에서 replication을 진행할 때 사용하는 바이너리 로그 기반 복제의 이진로그와 동일한 개념입니다)
이제 기본적인 스트리밍 데이터에 대한 이해가 끝났으니, 이벤트 스트리밍 플랫폼으로 가장 많은 사랑을 받고 있는 Apache Kafka에 대해 본격적으로 알아보자.
Why Kafka?
보통 파이프라인의 성능은 두 가지로 결정됩니다. 바로 latency와 처리량 입니다.
아무래도 스트리밍 데이터를 처리하는 프레임워크는 그 성격 상 latency에 치중될 수 밖에 없습니다.
그러나, Kafka는 디스크 기반의 로깅 메커니즘을 통해 처리량 또한 준수한 수준을 보입니다.
특히, Kafka 는 강력한 데이터 복제를 브로커를 통해 지원합니다.
브로커는 Kafka 클러스터를 구성하는 기본 단위입니다. Kafka 에서는 데이터를 여러 브로커에 복제하여 저장하여, 어떤 브로커에 문제가 발생해도 데이터 손실 없이 처리를 계속할 수 있음을 의미하며, 실시간 시스템에서는 이러한 내구성이 매우 중요한 요소로 작용합니다.
추가로, 분산 시스템으로 설계되어 있어 데이터를 여러 서버(브로커)에 걸쳐 저장하고 처리할 수 있기에, 단일 노드의 성능 한계를 넘어서는 확장성과 높은 처리량을 가능하게 합니다.
이외에도, Kafka는 다양한 프로그래밍 언어 및 프레임워크와의 호환성, 그리고 이미 형성되어 있는 대규모 커뮤니티 지원을 통해 많은 기업들이 Kafka를 채용하여 비즈니스 데이터를 효율적으로 관리하고 있습니다.
Kafka Architecture
Kafka config: Topic, Partition, Replica, Leader, Follower…. etc
토픽과 파티션은 위에서 이미 언급했지만, 조금 더 상세한 이해를 위해 구체적으로 한번 더 짚고 넘어가겠다.
토픽 (Topic)
토픽은 데이터의 카테고리나 분류를 나타내는 단위입니다.
예를 들어, "user_signups" 또는 "order_transactions"와 같은 토픽을 만들 수 있습니다. 각 토픽은 하나 이상의 파티션을 가질 수 있습니다.
파티션 (Partition)
파티션은 토픽의 데이터를 분할하는 단위입니다.
토픽의 데이터가 여러 파티션에 나누어 저장되어 사용되기 때문에, 병렬 처리를 통해 높은 처리량을 달성할 수 있습니다. 처음, 해당 개념을 접했을 때 혼자 아래와 같은 예시를 만들어 이해하려고 애썼던 기억이 있다.
예를 들어, "user_signups"라는 토픽이 3개의 파티션으로 구성되어 있다면:
- 파티션 1: 사용자 가입 데이터의 1/3
- 파티션 2: 사용자 가입 데이터의 1/3
- 파티션 3: 사용자 가입 데이터의 1/3
이렇게 각 파티션은 토픽의 전체 데이터 중 일부를 독립적으로 저장합니다.
프로듀서가 토픽에 메시지를 쓸 때, Kafka는 해당 메시지를 특정 파티션에 할당합니다. 이 할당은 여러 가지 방법(예: 라운드 로빈, 키 해싱 등)으로 수행될 수 있습니다. 따라서, 기본적으로 토픽의 모든 데이터를 조회하려면 모든 파티션에서 데이터를 읽어와야 합니다.
단, 각 파티션 내에서의 메시지 순서는 유지되지만, 토픽 전체의 파티션 간 메시지 순서는 보장되지 않을 수 있습니다.
복제본 (Replica)
복제본은 파티션의 복사본으로, 데이터의 내구성과 고가용성을 보장하기 위해 사용됩니다.
위에서 언급했다시피, 만약 한 브로커가 실패하더라도 해당 브로커에 저장된 파티션의 복제본이 다른 브로커에 존재하기 때문에 데이터 손실을 방지할 수 있습니다.
Segment
Segment는 브로커의 로컬 스토리지에 저장되는 파티션의 물리적인 저장 단위입니다.
- 파일 기반 저장: 각 세그먼트는 실제로 두 가지 주요 파일로 구성됩니다. 하나는 실제 메시지를 저장하는
.log파일, 그리고 메시지의 위치를 빠르게 찾기 위한.index파일입니다.- Rolling: 세그먼트는 설정된 크기나 기간에 도달하면 "roll" 되며, 새로운 세그먼트 파일이 생성됩니다. 이것은 오래된 데이터를 효율적으로 삭제하거나 관리할 수 있게 해주는 장점이 있습니다.
- 데이터 삭제 및 보존: 오래된 데이터를 삭제할 때,
Kafka는 전체 세그먼트 파일을 삭제함으로써 효율성을 유지합니다. 데이터 보존 정책(retention policy)에 따라, 메시지가 보존되는 시간이나 세그먼트의 크기에 도달하면 해당 세그먼트는 삭제될 수 있습니다.- 효율적인 읽기 및 쓰기: 세그먼트 구조는
Kafka가 대량의 데이터를 빠르게 읽고 쓰는 데 있어 효율적입니다. 특히, 순차적인 디스크 I/O 작업은 랜덤 액세스보다 훨씬 빠르기 때문에 세그먼트는 이러한 순차적인 접근의 이점을 활용합니다.
각 파티션은 리더(leader)와 하나 이상의 팔로워(follower)로 구성
- 쓰기 작업: 프로듀서가 데이터를 쓰려고 할 때, 이 작업은 해당 파티션의 리더에게 전달됩니다. 오직 리더만이 해당 파티션에 데이터를 쓸 수 있습니다.
- 팔로워 동기화: 리더가 데이터를 받고 기록한 후, 이 데이터는 팔로워들에게 복제됩니다. 팔로워는 리더로부터 데이터를 주기적으로 가져와서 자신의 로그에 동기화합니다. 이렇게 해서, 만약 리더가 실패하면, 팔로워 중 하나가 새로운 리더로 승격될 수 있으며, 데이터 손실 없이 서비스를 계속 제공할 수 있습니다.
- 읽기 작업: 컨슈머가 데이터를 읽을 때 기본적으로 리더에서 데이터를 읽습니다. 그러나
Kafka설정에 따라, 컨슈머가 팔로워 브로커로부터 직접 데이터를 읽는 것도 가능하며, 이를 통해 읽기 처리량을 분산시킬 수 있습니다.
참고문헌
- 데이터 스트리밍: 장점, 예시 및 사용 사례 | KR
- 견고한 데이터 엔지니어링 (written by Joe Reis & Matt Housley)
- Apache Kafka 공식문서
- 데이터 엔지니어링 데브코스 lecture note (created by 한기용)
