개발자 던킨

아파치 카프카란 무엇인가?

한마디로 말 하자면 Data inMotion platform이라고 말할수 있습니다. 

즉, 움직이는 데이터를 처리하는 플랫폼이라고 하면서 또 다른 말로 하자면 Event Streaming Platform 이라고 합니다.

실시간으로 흐르는 이벤트를 받아서 데이터가 필요한곳으로 데이터를 전송해주는것!

Event는 비지니스 상에서 흐르는 모든 일들을 (Data)을 의미합니다.

예시로는

• 우리가 웹 상에서 클릭
• 송금
• 청구서 발행
• 위치정보
• 택시 GPS, 배달 기사분들의 실시간 위치
• 센서의 온도/압력 데이터

이러한 Event의 특징은 BigData의 특징을 가지고있습니다.

• 비지니스 모든 영역에서 광범위하게 발생
• 대용량의 데이터가 발생

끝임없이 데이터가 들어오기 때문에 event stream 이라고 부르고있습니다.

LinkedIn 회사는 세계적인 구인구직 회사입니다. 

• 하루 4.5조 개 이상의 이벤트 스트림 처리
• 하루 3000억개의 사용자 관련 이벤트 스트림 처리

LinkenIn 내의 요구사항 중 이렇게 많은 사람들의 정보가 왔다갔다 하는데 무슨일이 일어나는지에 대해서 실시간의 정보를 알고싶었습니다.

그 당시 사용했던 MQ 로 처리가 불가능했습니다. 그래서 링크드인 개발자가 이벤트 스트림 처리를 위해 개발한것이 Apache Kafka입니다.

카프카는 LinkendIn 회사에서 개발을 시작해서 Apache Kafka를 오픈소스화 하면서 2011년부터 커뮤니티에서 발전을 하였습니다.

LinkedIn 회사의 개발자인 Jay Kreps, Neha Narkhede, Jun Rao 분들에 의해서 개발이 되었고 

<추후에 Confluent 회사를 설립해서 카프카의 발전을 지속적으로 해옴>

왜 카프카 라고 지었을까?

- Jay Kreps가 명명

 - Kafka는 쓰기(Write) 에 최적화된 시스템이기 때문에, 작가(Writer)의 이름을 사용하는 것이 의미가 있다고 생각했고, 대학에서 문학 수업을 많이 들었으며 그가 좋아했던 Franz Kafka의 작가의 이름에서 따왔습니다.

Apache Kafka 에 3가지 주요 특징

1. 이벤트 스트림을 안전하게 전송 (Pub & Sub)

2. 이벤트 스트림을 디스크에 저장(Write to Disk) - 기존 아파치 카프카 이전 솔루션과 아파치 카프카 구분하는것 큰 특징은 대용량 데이터를 디스크에 writing 하면서 대용량 데이터를 전송하는데 엄청난 처리량을 제공

3. 대용량의 처리가 가능하기에 이벤트 스트림을 분석 및 처리가 가능해졌습니다.

얼마나 많은 회사들이 사용하고 있을까?

Fortune 100기업 중 80% 이상이 사용하고 있습니다.

국내의 기업들은 최소 102개의 기업에서 사용중에 있습니다.

아파치 카프카의 사용사례는?

Event(메시지/데이터)가 사용되는 모든곳에 사용이 가능

• Message System(중간 매개체)
• IoT 디바이스로부터 데이터 수집
• App에서 발생하는 로그 수집도 가능
• 이상거래탐지/중복거래 
  • 사기 방지 목적으로도 가능합니다.(한국은 2014년 이후로부터 모든 금융거래에 FDS(Fraud Defence System)을 의무 도입해야되면서 실시간 탐지시스템 솔루션이 많이 생겨났습니다.)
• DB 동기화(MSA 기반의 분리된 DB간 동기화)
  • 서비스를 많이 쪼개놓으면서 db또한 쪼개놓아서 많이 쓰이면서 나눠진 데이터를 동기화 해야되는 경우 
  • 고객정보 같은 경우 A 서비스와 B 서비스를 join 해야되는 경우 원장 테이블을 다른 테이블에 복제해서 사용할때 사용합니다.
• 실시간 ETL (Extract, Transform, Load)
  • ETL 프로세스는 데이터 분석, 비즈니스 인텔리전스(BI) 및 보고서를 위해 데이터를 통합하는 데 필수적입니다. 이 과정을 통해 기업은 여러 출처의 데이터를 하나의 시스템에서 관리하고 분석할 수 있습니다.

대표적 사례들

Why Apache Kafka?

다른 유명한 Rabbit MQ 혹은 apache Storm(twitter 개발) 이 있는데 아파치 카프카를 사용할까?

링크드인의 데이터 처리방법

예전에 벤치마킹을 했을때 기존의 MQ 와 같은 성능 보다 월등하게 데이터를 처리하는것을 보았습니다.

그래프가 높으면 높을수록 더 좋은 성능을 나타내고 오른쪽은 낮을수록 좋다는것을 나타내는 지표입니다.

MQ와 비교했을때 큰 차이를 나타냅니다. 30k와 200k의 차이점 그리고 95%의 데이터를 5milisecond에 처리합니다.

카프카 벤치마킹

벤치마킹 2

카프카의 짧은 스토리와 왜 많은 기업들이 카프카를 선택했는지에 대해서 짧게 알아보았습니다.

그렇다면, 이제 간단하게 카프카의 기능들에 대해서 알아보도록 하겠습니다.

기본기

★ Producer

메시지를 주제(topic)에 게시하는 클라이언트는 프로듀서라고 합니다. 프로듀서는 특정 파티션에 메시지를 기록합니다. 이는 메시지 키와 파티셔너를 사용하여 키의 해시를 생성하고 이를 특정 파티션에 매핑함으로써 이루어집니다. 기본적으로 프로듀서는 메시지를 모든 주제의 파티션에 고르게 분배합니다. 그러나 경우에 따라 프로듀서는 특정 파티션으로 메시지를 직접 보낼 수 있습니다. 이는 메시지 키에 특정 파티션 스킴을 적용하여 달성됩니다.

★ Consumer

소비자는 구독한 주제에서 메시지를 끌어와 읽습니다. 소비자는 파티션에 기록된 순서대로 메시지를 읽습니다. 소비자는 메시지 오프셋을 사용하여 자신의 소비를 추적합니다. 소비자가 특정 메시지 오프셋을 확인하면, 이는 소비자가 해당 파티션에서 그 오프셋 이전의 모든 메시지를 수신했음을 의미합니다.

소비자는 소비자 그룹의 일원으로 작동하며, 하나 이상의 소비자가 함께 주제를 소비합니다. 이 그룹은 각 파티션에 대해 하나의 소비자만 책임지도록 설계되었습니다. 예를 들어, 다음 그림에서는 네 개의 파티션(p0, p1, p2, p3)과 세 개의 소비자(c0, c1, c2)를 가진 메시지 주제가 있습니다. 가능한 파티션-소비자 매핑은 다음과 같습니다: c0는 p0, c1은 p1과 p2, c2는 p3입니다.

이 둘의 특징 : 

Producer 와 Consumer는 서로 알지 못하며, Producer와 Consumer는 각각 고유의 속도로 Commit Log에 Write및 Read를 수행합니다.

다른 Consumer Group 에 속한 Consumer들은 서로 관련이 없으며, Commit Log에 있는 Event(Message)를 동시에 다른 위치에서Read 할수 있습니다.

여기서! Commit Log는 무엇인가?

Commit Log : 추가만 가능하고 변경이 불가능한 데이터 structure, 데이터(event)는 항상 로그 끝에 추가 되고 변경되지 않습니다.

Offset : Commit Log에서 Event의 위치 122번째 의 offset을 볼수 있습니다. 

카프카도 commit Log 라고 하는 개념으로 만들어져있습니다. 

Producer 가 Write하는 LOG-END-OFFSET과 Consumer Group의 Consumer가 Read 하고 처리한 후에 Commit한 CURRENT-OFFSET과 차이(Consumer Lag)가 발생 할 수 있습니다.

★ Topic

• 카프카 안에서 메시지가 저장되는 장소, 논리적 표현
• Partition : Commit Log, 하나의 Topic은 하나의 파티션으로 구성, 병렬처리(Throughput 향상)를 위해서 다수의 partition 사용 
• segment : 메시지(데이터) 물리파일 - 저장되는 실제 물리 File , segment file이 지정된 크기보다 크거나 지정된 기간보다 오래되면 새 파일이 열리고 메시지는 새 파일에 추가됨

실제 Physical view를 보게 되면 

Topic 생성시 Partition 개수를 지정하고, 각 partition은 broker들에 분산되며 Segement File들로 구성되게 됩니다.

파일을 Rolling 하여 분리/생성합니다.

Rolling Strategy :  log.segment.bytes(default 1 GB), log.roll.hours(default 168 hours) 

용량을 정하거나 시간을 가지고 파일을 시간에 맞춰 분리 시키면서 롤링하는것이 카프카의 구조입니다.

★ broker

게시된 메시지는 브로커라고 불리는 일련의 서버에 저장됩니다. 브로커는 프로듀서로부터 메시지를 수신하고, 오프셋을 할당한 후 이를 디스크에 기록합니다. 또한 소비자의 메시지 가져오기 요청에 응답하여 서비스를 제공합니다.

★ cluster

카프카 브로커는 클러스터의 일원으로 작동합니다. 클러스터 내에서 한 브로커는 클러스터 컨트롤러 역할을 하며, 이 컨트롤러는 관리 작업을 담당합니다.

카프카에서는 복제를 통해 파티션 내의 메시지에 대한 중복성을 제공합니다. 따라서 브로커가 실패할 경우, 팔로워 중 하나가 리더십을 맡을 수 있습니다. 모든 프로듀서는 메시지를 게시하기 위해 리더에 연결해야 하지만, 소비자는 리더 또는 팔로워 중 하나에서 메시지를 가져올 수 있습니다.

클러스터 내에는 파티션을 소유한 단일 브로커가 있습니다. 이 브로커를 파티션의 리더라고 합니다. 복제된 파티션은 추가 브로커에 할당되며, 이들은 파티션의 팔로워라고 불립니다.

여기까지 기본적인 카프카의 간단한 기능을 알아보았습니다.

* 출저 :

https://kafka.apache.org

https://developer.confluent.io/learn/kafka-performance/

안녕하세요, 카프카에 관련된 글을 적기 위해서 고민을 하던차에 미국의 대기업 중 하나인 월마트의 카프카 사용에 대한 좋은 글을 읽게 되어서 먼저 공유를 하고 점차적으로 글을 공유하려고합니다.

먼저 카프카에 대해서 어느정도 알고 있다면 큰 어려움 없이 읽을수 있을거같습니다.

요약

Walmart는 여러 클라우드(퍼블릭 및 프라이빗)에 걸쳐 25,000명 이상의 Kafka 소비자와 함께 Apache Kafka를 배포하고 있습니다. 데이터 이동, 이벤트 기반 마이크로서비스, 스트리밍 분석 등 비즈니스에 중요한 사용 사례를 지원합니다. 이러한 사용 사례는 99.99의 가용성을 요구하며 갑작스러운 트래픽 급증으로 인해 발생하는 백로그를 신속하게 처리해야 합니다. Walmart 규모에서는 여러 언어로 작성된 다양한 Kafka 소비자 애플리케이션을 보유하고 있습니다. 이러한 다양성과 안정성 요구 사항이 결합되어 소비자 애플리케이션은 고가용성 SLO를 보장하기 위해 모범 사례를 채택해야 합니다. 카프카 소비자 리밸런싱으로 인한 높은 소비자 지연은 카프카 소비자를 대규모로 운영할 때 가장 흔한 문제입니다. 이 글에서는 저렴한 비용과 탄력성으로 하루에 수조 개의 메시지를 안정적으로 처리하는 Apache Kafka 메시지의 안정적 처리 방법을 중점적으로 설명합니다.

소비자 리밸런싱

Kafka의 프로덕션 배포에서 자주 발생하는 문제는 소비자 리밸런싱과 관련이 있습니다. 카프카 리밸런싱은 각 소비자가 거의 동일한 수의 파티션을 처리하도록 하기 위해 카프카가 소비자 간에 파티션을 재분배하는 프로세스입니다. 이를 통해 데이터 처리가 소비자 간에 균등하게 분산되고 각 소비자가 최대한 효율적으로 데이터를 처리하도록 보장합니다. Kafka 애플리케이션은 컨테이너 또는 VM(가상 머신이라고도 함)에서 실행됩니다. 이 글에서는 현재 업계에서 널리 사용되고 있는 컨테이너에 초점을 맞춥니다. 컨테이너 이미지로 구축된 Kafka 소비자 애플리케이션은 Kubernetes를 기반으로 구축된 엔터프라이즈급 멀티클라우드 컨테이너 오케스트레이션 프레임워크인 WCNP(Walmart Cloud Native Platform)에서 실행됩니다. 따라서 다음과 같은 다양한 원인으로 인해 소비자 리밸런싱이 트리거될 수 있습니다:

소비자 그룹을 떠나는 소비자 파드: 이는 K8 배포 또는 롤링 재시작 또는 자동/수동 스케일-인으로 인해 발생할 수 있다.
소비자 그룹에 진입하는 소비자 파드: 이는 K8 배포 또는 롤링 재시작 또는 자동/수동 스케일아웃으로 인해 발생할 수 있다.
소비자가 실패한 것으로 판단하는 Kafka 브로커(예: 브로커가 세션.timeout.ms 내에서 소비자로부터 하트비트를 수신하지 못한 경우): JVM이 종료되거나 장기간 가비지 수집이 일시 중지되는 경우 트리거됩니다.
소비자가 멈췄다고 판단하는 경우(예: 소비자가 소비할 다음 레코드 배치를 폴링하는 데 max.poll.interval.ms보다 더 오래 걸리는 경우) Kafka 브로커가 트리거됩니다: 이전에 폴링된 레코드의 처리가 이 간격을 초과하면 트리거됩니다.

소비자 리밸런싱은 계획된 유지보수(예: 코드 릴리즈), 표준 운영 관행(예: 최소 포드/최대 포드 설정 수동 변경), 자동 자가 복구(예: 포드 충돌, 자동 확장) 모두에서 복원력을 달성하지만 지연 시간에는 부정적인 영향을 미칩니다. 오늘날 커머스의 거의 실시간에 가까운 특성을 고려할 때, 많은 Kafka 사용 사례에는 엄격한 전송 SLA가 적용됩니다. 이러한 애플리케이션은 프로덕션에서 빈번하고 예측할 수 없는 재조정으로 인해 지속적인 지연 경보로 인해 어려움을 겪었습니다.

현재로서는 카프카에서 리밸런싱을 피하도록 소비자를 구성하는 깔끔한 방법이 없습니다. 커뮤니티에서 정적 소비자 멤버십과 협업을 통한 점진적 리밸런싱을 제공하지만, 이러한 접근 방식에는 나름의 어려움이 따릅니다.

포이즌 필

HOL(헤드 오브 라인) 차단은 네트워킹 및 메시징 시스템에서 발생할 수 있는 성능 제한 현상입니다. Kafka 소비자가 성공적으로 처리될 수 없는 메시지를 접할 때 발생합니다. 메시지 처리 결과 Kafka 소비자 스레드에 잡히지 않은 예외가 발생하면 소비자는 브로커의 다음 폴링에서 동일한 메시지 배치를 다시 소비하게 되며, “포이즌 필” 메시지가 포함된 동일한 배치가 동일한 예외를 발생시킬 것으로 예상됩니다. 이 루프는 문제가 있는 메시지를 건너뛰거나 올바르게 처리하는 코드 수정이 Kafka 소비자 애플리케이션에 배포되거나 소비자 오프셋을 변경하여 문제가 있는 메시지를 건너뛸 때까지 무기한 계속됩니다. 이 포이즌 필 문제는 분할된 데이터 스트림의 순서 내 처리와 관련된 또 다른 문제입니다. 아파치 카프카는 포이즌 필 메시지를 자동으로 처리하지 않습니다.

비용

토픽의 파티션과 이를 읽는 소비자 스레드 사이에는 강력한 결합이 있습니다. 토픽의 최대 소비자 수는 해당 토픽의 파티션 수를 초과할 수 없습니다. 소비자가 토픽 흐름을 따라갈 수 없는 경우(즉, 지속적으로 낮은 소비자 지연을 유지하는 경우) 모든 파티션이 전용 소비자 스레드에 할당될 때까지만 소비자를 더 추가하는 것이 도움이 됩니다. 이 시점에서는 최대 소비자 수를 늘리기 위해 파티션 수를 늘려야 합니다. 좋은 아이디어처럼 들릴 수 있지만, 브로커 노드를 다음으로 큰 크기(4000개의 파티션/브로커)까지 수직 확장하기 전에 브로커에 추가할 수 있는 파티션의 수에 대한 일반적인 규칙이 있습니다.) 보시다시피, 소비자 지연이 증가하면 브로커 자체에 충분한 물리적 리소스(예: 메모리, CPU, 스토리지)가 있음에도 불구하고 파티션이 증가하고 잠재적으로 더 큰 규모의 브로커로 확장해야 하는 문제가 발생합니다. 파티션과 소비자 간의 이러한 강력한 결합은 카프카의 트래픽 증가에도 불구하고 낮은 지연 시간을 유지하고자 하는 많은 엔지니어들의 오랜 골칫거리였습니다.

Kafka 파티션 확장성

수천 개의 파이프라인이 있는 경우, 파티션 수를 늘리면 생산자, 소비자, 플랫폼 팀 간의 조정이 필요하고 가동 중단 시간이 짧아지기 때문에 운영상 부담이 됩니다. 갑작스러운 트래픽 급증과 대규모 백로그 소진은 모두 파티션과 소비자 포드의 증가를 필요로 합니다.

솔루션

위의 몇 가지 문제(예: 카프카 소비자 리밸런싱)를 해결하기 위해, 카프카 커뮤니티는 다음과 같은 카프카 개선 제안을 제안했습니다: KIP-932: Kafka용 대기열.

메시징 프록시 서비스(MPS)는 사용 가능한 다른 경로입니다. MPS는 HTTP를 통해 메시지를 소비자가 대기하는 REST 엔드포인트로 프록시하여 파티션의 제약으로부터 Kafka 소비를 분리합니다. MPS 접근 방식을 통해 Kafka 소비는 더 이상 리밸런싱으로 인한 문제를 겪지 않으며, 더 적은 수의 파티션으로 더 많은 처리량을 처리할 수 있습니다.

MPS 접근 방식의 또 다른 이점은 애플리케이션 팀이 더 이상 Kafka 소비자 클라이언트를 사용할 필요가 없다는 것입니다. 따라서 모든 Kafka 팀은 애플리케이션 팀을 쫓아다니며 Kafka 클라이언트 라이브러리를 업그레이드할 필요가 없습니다.

디자인

MPS Kafka 소비자는 두 개의 독립적인 스레드 그룹, 즉 Kafka message_reader 스레드(즉, 1개 스레드 그룹)와 message_processing_writer 스레드로 구성됩니다. 이러한 스레드 그룹은 표준 버퍼링 패턴(pendingQueue)으로 구분됩니다. 리더 스레드는 (폴링 중에) 바운드 버퍼에 쓰고, 쓰기 스레드는 이 버퍼에서 읽습니다.

또한 바운드 버퍼는 읽기 및 쓰기 스레드의 속도를 제어할 수 있습니다. pendingQueue가 최대 버퍼 크기에 도달하면 message_reader 스레드가 소비자를 일시 중지합니다.

이렇게 리더 스레드와 쓰기 스레드를 분리하면 리더 스레드가 매우 가벼워지고 max.poll.interval.ms

를 초과하여 재밸런싱 작업이 트리거되지 않습니다. 이제 작성자 스레드는 메시지를 처리하는 데 필요한 시간을 확보할 수 있습니다. 다음 다이어그램은 구성 요소와 디자인에 대한 그림 보기를 제공합니다.

위의 아키텍처는 다음과 같은 주요 구성 요소로 이루어져 있습니다:

리더 스레드

리더 스레드의 역할은 인바운드 토픽을 진행하면서 PendingQueue가 가득 차면 역압박을 가하는 것입니다.

순서 이터레이터

순서 이터레이터는 키가 지정된 메시지가 순서대로 처리되도록 보장합니다. 이 반복기는 pendingQueue에 있는 모든 메시지를 반복하고 동일한 키를 가진 메시지가 이미 전송 중인 경우 메시지를 남겨둡니다(즉, 일시적으로 건너뜁니다). 건너뛴 메시지는 동일한 키를 가진 이전 메시지가 처리되면 후속 폴링 호출에서 처리됩니다. MPS는 키당 1개의 메시지만 전송되도록 함으로써 키별 순서대로 전달되도록 보장합니다.

작성자 스레드

작성자 스레드는 병렬 처리를 통해 더 많은 처리량을 제공하는 풀의 일부입니다. 재시도가 모두 소진되거나 재시도할 수 없는 HTTP 응답 코드가 수신되는 경우 REST 엔드포인트에 데이터를 안정적으로 쓰고 메시지를 DLQ하는 것이 이 스레드가 하는 일입니다.

Deal Letter Queue(DLQ)

DLQ 토픽은 모든 Kafka 클러스터에서 생성할 수 있습니다. message_processing_writer 스레드는 처음에 기하급수적으로 백오프하면서 정해진 횟수만큼 메시지를 재시도합니다. 실패하면 메시지는 DLQ 토픽에 저장됩니다. 애플리케이션은 나중에 이러한 메시지를 처리하거나 삭제할 수 있습니다. 소비자 서비스에 중단(예: 시간 초과)이 발생하거나 소비자 서비스에 포이즌 필(예: 500 HTTP 응답)이 발생하는 경우 이 대기열에 메시지를 배치할 수 있습니다.

Comsumer Service

소비자 서비스는 애플리케이션이 메시지를 처리하기 위한 상태 비저장 REST 서비스입니다. 이 서비스에는 원래 Kafka 소비자 애플리케이션에서 사용할 수 있었던 처리의 일부였던 비즈니스 로직이 포함되어 있습니다. 이 새로운 모델을 사용하면 Kafka 소비(MPS)를 메시지 처리(소비자 서비스)에서 분리할 수 있습니다. 아래에서 모든 소비자 서비스에서 구현해야 하는 REST API 사양을 확인할 수 있습니다:

Kafka 오프셋 커밋 스레드

Kafka 오프셋 커밋은 별도의 스레드(즉, offset_commit 스레드)로 구현됩니다. 이 스레드는 일정한 간격(예: 1분)으로 깨어나서 쓰기 스레드가 성공적으로 처리한 가장 최근의 연속된 오프셋을 커밋합니다.

위 그림에서, offset_commit 스레드는 파티션 0과 1에 대해 각각 오프셋 124와 150을 커밋합니다.

구현 세부 정보
MPS는 카프카 커넥트에서 싱크 커넥터로 구현되었습니다. Kafka Connect 프레임워크는 다음과 같은 여러 가지 이유로 적합합니다:

멀티테넌시: 여러 개의 커넥터를 단일 Kafka Connect 클러스터에 배포할 수 있습니다.
DLQ 처리: Kafka Connect는 이미 DLQ 처리를 위한 기본 프레임워크를 제공합니다.
커밋 흐름: Kafka Connect는 커밋을 위한 편리한 방법을 제공합니다.
기본 제공 NFR(비기능 요구 사항): Kafka Connect는 많은 비기능적 기능(예: 확장성, 안정성)을 제공합니다.

결론

MPS는 리더 스레드가 할당된 시간인 max.poll.interval.ms 5분 이내에 폴링 목록의 모든 메시지를 pendingQueue에 넣도록 보장하기 때문에 다운스트림 시스템의 속도 저하로 인한 리밸런싱을 제거했습니다. 우리가 보는 유일한 리밸런싱은 Kubernetes POD 재시작과 극히 드물게 발생하는 Kafka 클러스터와 MPS 간의 네트워크 속도 저하로 인한 것입니다. 그러나 소규모 소비자 그룹에서는 이러한 주기의 지속 시간이 무시할 수 있을 정도로 짧으며 처리 SLA(서비스 수준 계약)를 초과하지 않습니다. MPS 서비스와 Kafka 클러스터는 동일한 클라우드와 지역에서 호스팅되어야 두 서비스 간의 네트워크 관련 문제를 줄일 수 있습니다.

애플리케이션이 포이즌 필을 감지하고 반환 코드 600 및 700을 통해 MPS에 알리는 포이즌 필의 협력적 처리는 계획대로 작동합니다.

이 솔루션의 비용 이점은 두 가지 영역에서 실현됩니다. 첫째, 상태 비저장 소비자 서비스는 Kubernetes 환경에서 빠르게 확장할 수 있으며 명절이나 캠페인 이벤트를 위해 미리 확장할 필요가 없습니다. 둘째, Kafka 클러스터 크기는 더 이상 파티션 크기에 의존하지 않으며, 파티션당 약 5~10MB로 처리량에 맞게 실제로 확장할 수 있습니다.

매년 연말연시에 Kafka 클러스터를 확장하면서 발생하는 사이트 관련 문제와 Kafka 파이프라인의 운영 요청을 재조정하는 데 있어 큰 개선이 있었습니다.

상태 비저장 소비자 서비스는 메시지 버스트를 처리하기 위해 Kubernetes 환경에서 쉽게 자동 확장되기 때문에 트래픽이 갑자기 급증해도 더 이상 Kafka 파티션을 확장할 필요가 없습니다.