개발 일지/Kafka7

• 

  [kafka] 컨슈머 파티션 할당 전략 개요 이전 포스팅에서는 컨슈머 코디네이터를 통해 리밸런싱 동작이 발생하는 것을 확인할 수 있었다. 하지만, 리밸런싱은 무거운 작업이기 때문에 자주 진행하는 것은 문제가 된다고 강조하였다. 이를 해결하기 위해 스태틱 멤버십 기능을 적용하여 일정 시간동안 리밸런싱을 동작하지 않도록 설정할 수 있는 것을 확인하였다. 이전에 학습했던 내용 중 프로듀서와 관련된 포스팅에서 파티셔너라는 기능을 살펴보면서 특정 파티션으로 전송하기 전 배치 작업을 진행하는 내용을 살펴본 적이 있다. 이와 유사하게 컨슈머의 동작에서도 대상 토픽의 어느 파티션으로부터 레코드(메시지)를 받아올지를 결정하는 메커니즘이 존재하는데 어떠한 매칭 전략이 있는지 이번 포스팅을 통해 알아보려고 한다. 즉, 이번 포스팅에서는 컨슈머 파티션 전략을 정리.. 개발 일지/Kafka 2023. 10. 31.

• 

  [Kafka] 컨슈머의 리밸런싱 개요 지금까지 카프카의 내부 원리부터 프로듀서가 어떻게 신뢰성있게 메시지를 전송하는지에 대해서 자세히 살펴보았다. 이번 포스팅은 드디어 컨슈머라는 주제를 가지고 내부적으로 어떻게 동작하는지 자세히 살펴보려고 한다. 이전에 "정확히 한 번 메시지 전송" 포스팅에서 트랜잭션 코디네이터가 해당 로직에서 필수적인 존재라는 것을 알아본 적이 있었다. 컨슈머와 관련돼서도 비슷한 코디네이터가 존재하는데 이에 대해서 알아보고 추가적으로, 리밸런싱이 무엇인지도 학습해보자. 컨슈머 오프셋 관리 컨슈머에서 중요하게 처리하는 부분은 오프셋 관리인데 컨슈머가 컨슘하고 있는 토픽에서 메시지를 어디까지 들고왔는지 기록을 하고 있어야한다. 이때 활용하는 것이 오프셋인데 만약, 컨슈머가 일시적으로 장애가 발생하거나 일시적으로 동작을 .. 개발 일지/Kafka 2023. 10. 25.

• 

  [Kafka] 프로듀서가 정확히 한 번만 전송하는 방식 개요 이전 포스팅을 보면 카프카에서 멱등성 옵션을 이용해 중복 없는 전송을 할 수 있다고 언급하였다. 다만, 여기서 유의해야하는 점은 중복 없는 전송 방식이 정확히 한 번만 전송한다는 의미가 아니다. 두 번을 전송하더라도 중복된 데이터를 삽입하지 않는 로직을 의미한 것이며, 정확히 한 번 전송은 트랜잭션과 같은 전체적인 프로세스 처리를 의미한다. 즉, 이번 포스팅에서는 정확히 한 번만 전송하는 로직은 어떻게 흘러가는지 알아보려고 한다. 이유 전체적인 프로세스를 관리하기 위해 카프카에서는 정확히 한 번 처리하는 별도의 프로세스가 존재하는데 이를 트랙잭션 API라고 부른다. 우리는 이 과정을 자세히 살펴보려고 하는데, 전송을 두 번 하더라도 중복 데이터를 처리하면 되는 것이 아닐까라는 의문이 생기기도 한다... 개발 일지/Kafka 2023. 10. 24.

• 

  [Kafka] 프로듀서의 내부 동작 원리 파헤치기 개요 이번 포스팅에서는 프로듀서가 어떻게 동작하는지 내부 원리를 알아보려고 한다. 기존에 필자가 알고있었던 프로듀서의 역할은 메시지를 발행하여 카프카에 전송하는 것인데, 그 안에서도 파티셔너라는 친구가 중간에 개입하면서 어떠한 토픽으로 보낼지 나침반 역할을 하게 된다. 또한, 해당 메시지들은 즉시 카프카로 전송하는 것이 아니라 내부적으로 어떠한 조건이 충족되었을 때 수행된다고 한다. 추가적으로 카프카에서 중복 데이터를 처리하는 방식도 존재한다고 한다. 이러한 부분들을 깊게 학습하고 동작 흐름을 자세히 살펴보고자 한다. 파티셔너 카프카의 토픽은 성능 향상을 위한 병렬 처리가 가능하도록 하기 위해 파티션으로 나뉘고, 최소 하나 또는 둘 이상의 파티션으로 구성된다. 그리고 프로듀서는 토픽으로 메시지를 보낼 때.. 개발 일지/Kafka 2023. 10. 23.

• 

  [Kafka] 내부 동작 원리 파헤치기(2) - 리더에포크 개요 이전 글에서는 리플리케이션의 동작 원리에 대해서 글을 작성하였고 예고한대로 이번글에서는 리더에포크가 무엇인지 알아보려고 한다. 추가적으로 컨트롤러, 세그먼트 로그 컴팩션에 대한 정리도 같이 진행한다. 리더에포크와 복구 리더에포크(LeaderEpoch)는 카프카의 파티션들의 복구 동작을 할 때 메시지의 일관성을 유지하기 위한 용도로 이용되는데 복구 동작 시 하이워터마크를 대체하는 수단으로 활용한다. *하이워터마크 : 마지막 커밋 오프셋 위치 이번 예제에서의 파티션 수는 1, 리플리케이션 팩터는 2라고 가정하며 장애가 발생하는 가정을 설명하려고 한다. 아래의 표는 동작과정을 나타내며 마지막 8번 문항에서 장애가 발생하니 그 전에 동작된 과정을 그림을 보면서 이해해보자. 1. 리더는 프로듀서로부터 mes.. 개발 일지/Kafka 2023. 10. 22.

• 

  [Kafka] 내부 동작 원리 파헤치기(1) - 리플리케이션 개요 카프카는 브로커의 장애에도 불구하고 연속적으로 안정적인 서비스를 제공하면서 데이터의 유실을 방지하며 유연성을 제공한다. 이전에 게시한 포스팅을 보면 과거 프로젝트를 진행하면서 아쉬웠던 부분들을 회고하며 가용성을 유지하는 환경으로 재구성하였다. 이때 REPLICATION FARTOR라는 옵션을 설정을 하면서 복제 파티션을 만들도록 했던 것을 알고 있을 것이다. 이번 포스팅은 그 원리에 대해서 파헤쳐보는 시간이다. 즉, 어떻게 리플리케이션 동작되는지 알아보고 지금의 답답함을 해소해보려고 한다. 리더와 팔로워 카프카는 내부적으로 모두 동일한 리플리케이션들을 리더와 팔로워로 구분하고, 각자의 역할을 분담시킨다. 여기서 알아야하는 것은 리플리케이션들 중 리더를 하나 정하고 모든 읽기와 쓰기는 그 리더를 통해.. 개발 일지/Kafka 2023. 10. 19.

• 

  [Kafka] 고가용성과 리플리케이션 & 스프링 부트 테스트 개요 프로젝트를 진행하면서 ELK-Stack을 활용하여 로그 수집을 진행하였고 추가적으로 kafka를 도입하면서 안정화된 시스템을 구축하였다. 하지만, 프로젝트의 제한된 날짜 때문에 카프카의 큰 장점을 못살렸던 것이 너무 아쉽게 느껴졌다. 예를들면, 필자가 구성한 카프카는 단일 브로커로 구성하였기 때문에 카프카의 고가용성이라는 장점을 못살린 아키텍처가 된 것이다. 프로젝트 시즌이 끝나고 좋아하는 코딩 문제만 풀다보니 아쉽게 마무리했던 과거 프로젝트의 기억이 주마등처럼 지나가면서 '아차!' 하는 느낌을 받았다. 이전에 작업하던 카프카 관련 내용들은 이미 사라진 서버에서의 고대 작업물이 되었고, 개인 노션 저장소에 백업을 해두긴 하였지만 각 서버마다 복잡하게 얽혀있는 환경 설정 등으로 같은 세팅으로 로컬에 .. 개발 일지/Kafka 2023. 8. 9.