카프카는 분산 이벤트 스트리밍 플랫폼으로써 대량의 이벤트에 대해 높은 처리량을 제공해주는 것으로 유명해서 많은 기업에서 도입한 솔루션입니다. 그렇다면 카프카는 내부적으로 어떤 구조를 사용하기에 이렇게 높은 처리량을 소화할 수 있는걸까요? 오늘은 그 방법에 대해 살펴보고자 합니다.순차 I/O 사용한 성능 최적화일반적으로 디스크 I/O는 메모리 I/O 보다 엄청나게 느리다고 알려져 있다. 하지만 정확히는 디스크 랜덤 I/O의 속도가 매우 느린 것이다. 순차 I/O를 사용할 경우 RAID로 구성된 현대적 디스크에서 수백 MB/sec 수준의 읽기/쓰기 성능을 달성할 수 있다.  위의 표를 보면 디스크 순차 I/O의 경우 오히려 메모리 랜덤 I/O 보다 더 높은 성능을 보여주는걸 알 수 있다. 특히 순차 읽기 &..

카프카는 분산 이벤트 스트리밍 플랫폼으로써 실시간으로 대량의 이벤트를 처리합니다. 이때 이벤트는 모두 디스크에 저장되서 토픽을 구독하는 모든 컨슈머가 이벤트를 소비할 수 있는 일대다 모델을 가지고 있는데, 그렇다면 카프카는 이 실시간으로 축적되는 이벤트를 어떻게 디스크에서 관리하고 있는지 궁금해졌습니다. 이번 포스팅에서는 카프카가 디스크에서 데이터를 관리하는 방식에 대해 알아보고자 합니다.카프카 파티션 구조 분석카프카에서 메세지를 저장하고 소비하는 기본 단위는 파티션이다. 이 파티션이 내부적으로 메세지를 어떻게 관리하고 있는지 브로커 내부로 접속해서 한번 살펴보자.  test-topic-0은 test-topic이라는 토픽에서 첫번째 파티션을 말한다. 브로커 내에서 파티션은 이렇게 디렉토리로 관리된다. 폴..

이번 포스팅에서는 카프카의 멀티 브로커에서 사용되는 ISR(In Sync Replica)라는 개념에 대해서 알아보고자 합니다. ISR은 카프카가 메세지 유실 없이 가용성을 보장하기 위한 중요한 개념입니다. 또한 ISR 관련 설정에 따라 프로듀서가 메세지를 브로커에 정상적으로 전송하지 못할 수도 있기 때문에 잘 알아두는게 중요합니다.주키퍼를 사용한 카프카 클러스터 관리ISR에 대해 알아보기 전에 카프카가 어떻게 멀티 브로커 환경을 구축하는지 살펴보고자 한다. 카프카는 멀티 브로커의 메타데이터 관리를 위해 주키퍼라는 외부 컴포넌트를 사용한다.주키퍼주키퍼는 분산 시스템에서 시스템 간의 정보 공유, 상태 체크, 서버 들 간의 동기화를 위한 락 등의 역할을 하는 분산 코디네이션 서비스이다.주키퍼는 상태 정보들을 ..

카프카는 처리량 조절을 위해 컨슈머 어플리케이션 개수를 유동적으로 조절할 수 있다. 이때 컨슈머 개수가 변동될때마다 각각의 컨슈머가 할당받는 파티션도 변경되는데, 이를 컨슈머 리밸런싱이라고 한다. 이번 글에서는 컨슈머 리밸런싱에 대해서 알아보고자 한다.컨슈머 리밸런싱이 발생하는 경우우선 어떤 경우에 리밸런싱이 발생하는지 알아보자. 크게 2가지 경우에 리밸런싱이 발생한다.Consumer Group에 컨슈머가 추가/삭제 되는 경우브로커에 파티션이 추가되는 경우만약 리밸런싱이 필요한 상황이 발생하면 브로커의 GroupCoordinator가 Consumer Group의 리더 컨슈머에게 리밸런싱 명령을 내린다. 이때 리밸런싱이 발생하는 동안에는 일시적으로 STW(Stop The World)가 발생하는데, 카프카 ..

이번 포스팅에서는 카프카 프로듀서가 분산 환경에서 어떻게 신뢰성 있는 데이터 전송을 보장하는지 알아보고자 합니다. 프로듀서 중복 전송 이슈카프카는 분산시스템이기 때문에 얼마든지 네트워크 이슈로 인한 예외 상황이 발생할 수 있다. 데이터 중복 전송이 발생할 수 있는 하나의 케이스를 살펴보자.위의 그림과 같이 카프카 프로듀서는 브로커로 메세지를 전송한 뒤, 브로커가 메세지 저장 후 되돌려주는 ACK를 통해 데이터 정상 전송 여부를 판별한다. 만약 브로커에서 데이터 저장에 실패해서ACK가 돌아오지 않는다면 프로듀서는 일정 시간을 기다리다가 내부적으로 메세지를 재전송한다.이때 만약 브로커에는 데이터가 정상적으로 저장되고 ACK까지 정상적으로 반환했는데, ACK가 프로듀서에게 가는 도중에 네트워크 이슈로 인해 유..

이번 포스팅에서는 카프카의 트랜잭션에 대해 알아보고자 합니다. 저희가 흔히 사용하는 DB 트랜잭션의 경우 여러 DB 작업을 하나의 원자적 단위로 묶어주는 역할을 합니다. 카프카를 사용할때도 여러 이벤트 발행 작업이 하나의 원자적인 단위로 묶일 필요가 있는데, 이때 카프카 트랜잭션을 사용 가능합니다.카프카 작업 간의 트랜잭션을 통한 원자성 보장문제가 될 수 있는 상황카프카 트랜잭션이 사용될 수 있는 케이스를 학습해보자. Kafka Confluent 사이트에 좋은 예시가 있어서 참고해서 진행해보겠다. A가 B에게 송금하는 플로우를 고려해보자. 송금을 진행하는 어플리케이션에는 송금 이벤트를 컨슈밍하는 컨슈머와 A와 B의 계좌 상태를 업데이트 하는 프로듀서가 있다.  이때 만약 A에게 계좌 금액을 더하는 프로듀..

카프카의 프로듀서를 학습하는 과정에서 내부 동작 흐름을 디버깅 해본 기록을 남기고자 합니다.해당 글에서 다루고자 하는 카프카 프로듀서의 구조이번 글에서 다루고자 하는 부분을 먼저 거시적으로 살펴보고 가자. 카프카 프로듀서에서 생성된 메세지는 Serializer와 Partitioner를 거쳐 RecordAccumulator에 batch 단위로 적재된다.Serializer카프카 프로듀서는 브로커로 메세지를 전송할때 Byte 배열 형태로 직렬화 해서 네트워크를 통해 전송한다. 따라서 프로듀서의 send() 메서드를 호출하면 가장 먼저 수행되는 작업은 메세지 Key와 Value의 직렬화 작업이다. 다음은 KafkaProducer.send()를 호출했을때 내부적으로 호출되는 doSend() 메서드다.  코드 상에..

프로젝트에 레디스 pub/sub을 적용하면서 내부 구현 방식과 다른 기술과의 차이점이 궁금해졌다. 먼저 내부가 어떻게 생겼는지 파악한 뒤에 구조는 다르지만 비슷한 기능을 제공하는 카프카와 비교 분석을 진행해보자.Redis pub/sub의 내부 동작 원리레디스가 내부적으로 pub/sub을 어떻게 구현했는지 살펴보자.  레디스 pub/sub 내에는 pubsub_channel이라는 딕셔너리 타입의 변수가 존재한다. 해당 딕셔너리 안에 Channel과 구독자 정보를 보관한다. 딕셔너리의 Key는 Channel이고 Value는 구독자를 보관하는 LinkedList가 들어간다. 만약 채널에 구독자가 추가되면 채널과 매핑된 연결 리스트에 구독자 정보를 추가한다. 발행자가 메세지를 Channel에 보내면 딕셔너리에서 ..