카프카의 탄생 카프카 도입 전의 단점을 파악하여 카프카가 왜 탄생했는지에 대해서 알아봅시다. 카프카 도입 전 1) 일반적으로 데이터를 생성하는 '소스 애플리케이션'과 생성된 데이터가 적재되는 '타깃 애플리케이션'은 연결되어있습니다. 그림을 보면 end-to-end 연결 방식으로 여러 애플리케이션이 서로 데이터를 주고받습니다. 만약, 작게 시작했던 서비스가 점점 커지면서 위 그림처럼 복잡해진다면 앞으로 어떻게 확장을 해나가야 할까요? 각 애플리케이션의 의존도가 높아지면서 확장은 어려워지고 장애 발생 가능성은 커지게되어 서비스 관리가 힘들어집니다. 2) 한 쪽의 서비스에 장애가 발생한다면, 그와 연결된 서비스에 모두 영향을 미칩니다. N:1 또는 1:N 구조를 가지고있기 때문에 한 서비스에 장애가 발생한다면..
스프링 카프카 컨슈머 스프링 카프카의 컨슈머는 기존 컨슈머를 2개의 타입으로 나누고 커밋을 7가지로 나누어 세분화했다. 리스너의 종류에 따라 한번 호출하는 메서드에서 처리하는 레코드의 개수가 달라진다. 타입 레코드 리스너 (MessageListener) - 단 1개의 레코드를 처리한다. - 스프링 카프카 컨슈머의 기본 리스너이다. 배치 리스너 (BatchMessageListener) - 기존 카프카 클라이언트 라이브러리의 poll() ㅔㅁ서드로 리턴받은 CnsumerRecords처럼 한번에 여러개 레코드들을 처리한다. 그 외 매뉴얼 커밋을 사용할 경우 Acknowledging 붙은 리스너를 사용하고, KafkaConsumer 인스턴스에 직접 접근하여 컨트롤하고 싶다면 ConsumerAware가 붙은 리스..
스프링 카프카 프로듀서 '카프카 템플릿(Kafka Template)' 이라고 불리는 클래스를 사용하여 데이터를 전송할 수 있다. 카프카 템플릿은 프로듀서 팩토리(ProducerFactory) 클래스를 통해 생성할 수 있다. 카프카 템플릿을 사용하는 방법은 두가지다. 1) 스프링 카프카에서 제공하는 기본 카프카 템플릿을 사용한다. build.gradle dependencies { ... implementation 'org.springframework.kafka:spring-kafka' testImplementation 'org.springframework.kafka:spring-kafka-test' } application.yml spring: kafka: producer: bootstrap-servers..
중단 배포 컨슈머 애플리케이션을 완전히 종료한 이후에 개선된 코드를 가진 애플리케이션을 배포하는 방식이다. 이 방법은 한정된 서버 자원을 운영하는 기업에 적합하다. 중단 배포는 기존 애플리케이션을 완전히 종료한 이후 신규 애플리케이션을 배포, 실행하여 버전을 올리는 방식이다. 컨슈머 애플리케이션이 완전히 종료된 이후에 신규 애플리케이션이 배포된다는 점이 중요하다. 기존 컨슈머 애플리케이션이 종료되면 더는 토픽의 데이터를 가져갈 수 없어서 컨슈머 랙이 늘어난다. 이는 지연이 발생한다는 뜻이다. 중단 배포를 사용할 경우의 장점 새로운 로직이 적용된 신규 애플리케이션의 실행 전후를 명확하게 특정 오프셋 지점으로 나눌 수 있다. 배포 시점의 오프셋을 로깅 컨슈머 랙과 파티션별 오프셋을 기록하는 버로우 사용 이러..
컨슈머 랙(LAG) 토픽의 최신 오프셋(LOG-END-OFFSET)과 컨슈머 오프셋(CURRENT-OFFSET) 간의 차이다. 프로듀서는 계속해서 새로운 데이터를 파티션에 저장하고 컨슈머는 자신이 처리할 수 있는 만큼 데이터를 가져간다. 컨슈머 랙은 컨슈머가 정상 동작하는지 여부를 확인할 수 있기 때문에 컨슈머 애플리케이션을 운영한다면 필수적으로 모니터링해야한다. 컨슈머 랙을 모니터링하는 것은 카프카를 통한 데이터 파이프라인을 운영하는 데에 핵심적인 역할을 한다. 컨슈머 랙을 모니터링함으로써 컨슈머의 장애를 확인할 수 있고 파티션의 개수를 정하는 데에 참고할 수 있기 때문이다. 컨슈머 랙은 컨슈머 그룹과 토픽, 파티션별로 생성된다. * 예시 1개의 토픽에 3개의 파티션이 있고, 1개의 컨슈머 그룹이 토픽..
멀티 스레드 컨슈머 카프카는 처리량을 늘리기 위해 파티션과 컨슈머 개수를 늘려서 운영할 수 있다. 파티션을 여러개로 운영하는 경우 데이터를 병렬처리하기 위해서 파티션 개수와 컨슈머 개수를 동일하게 맞추는 것이 가장 좋은 방법이다. 토픽의 파티션은 1개 이상으로 이루어져 있으며 1개의 파티션은 1개의 컨슈머가 할당되어 데이터를 처리할 수 있다. 파티션 개수가 n개라면 동일 컨슈머 그룹으로 묶인 컨슈머 스레드를 최대 n개 운영할 수 있다. 그러므로 n개의 스레드를 가진 1개의 프로세스를 운영하거나 1개의 스레드를 가진 프로세스를 n개 운영하는 방법도 있다. 카프카에서 공식적으로 지원하는 라이브러리인 자바는 멀티 스레드를 지원한다. 멀티 스레드로 동작하는 멀티 컨슈머 스레드를 개발, 적용할 수 있다. 고려해야..
멱등성 여러번 연산을 수행하더라도 동일한 결과를 나타내는 것을 뜻한다. 멱등성 프로듀서는 동일한 데이터를 여러번 전송하더라도 카프카 클러스터에 단 한번만 저장됨을 의미한다. 기본 프로듀서의 동작 방식은 적어도 한번 전달(at least once delivery)을 지원한다. 적어도 한번 전달이란, 프로듀서가 클러스터에 데이터를 전송하여 저장할 때 적어도 한번 이상 데이터를 적재할 수 있고 데이터가 유실되지 않음을 뜻한다. 두번 이상 적재되어 중복이 발생할 가능성은 있다. 멱등성 프로듀서 멱등성 프로듀서는 기본 프로듀서와 달리 데이터를 브로커로 전달할때 프로듀서 PID(Producer unique ID)와 시퀀스 넘버(sequence number)를 함께 전달한다. 그러면 브로커는 프로듀서의 PID와 시퀀..
acks 옵션 카프카 프로듀서의 acks옵션은 0, 1, all(또는 -1) 값을 가질 수 있다. 이에 대해서 우리는 이전 포스팅에서 간단히 살펴봤었다. https://devfunny.tistory.com/747 [아파치 카프카 어플리케이션 프로그래밍] 5. 프로듀서의 중요 개념과 옵션값 프로듀서 프로듀서는 카프카 브로커로 데이터를 전송할때 내부적으로 파티셔녀, 배치 생성 단계를 거친다. 전송하고자 하는 데이터는 ProducerRecord 인스턴스를 생성하여 설정한다. 필수 파라미터 devfunny.tistory.com value 설명 0 default 프로듀서가 전송한 즉시 브로커에 데이터 저장 여부와 상관 없이 성공으로 판단한다. 1 리더 파티션에 데이터가 저장되면 전송 성공으로 판단한다. -1 or..
ISR (In-Sync-Replicas) 리더 파티션과 팔로워 파티션이 모두 싱크가 된 상태를 뜻한다. 복제 개수가 2인 토픽을 가정해보자. 리터 파티션 1개와 팔로워 파티션 1개가 존재할 것이다. 리더 파티션에 0부터 3의 오프셋이 있다고 가정할때, 팔로워 파티션에 동기화가 완료되려면 0부터 3까지 오프셋이 존재해야한다. 동기화가 완료됐다는 의미는 리더 파티션의 모든 데이터가 팔로워 파티션에 복제된 상태를 말하기 때문이다. 리더 파티션과 팔로워 파티션이 동기화된 상태에서는 리더 또는 팔로워 파티션이 위치하는 브로커에 장애가 발생하더라도 데이터를 안전하게 사용할 수 있다. 팔로워 파티션이 리더 파티션으로부터 데이터를 복제하는 데에 시간이 걸린다. 프로듀서가 특정 파티션에 데이터를 저장하는 작업은 리더 파..
토픽 정리 정책(cleanup.policy) 토픽의 데이터는 시간 또는 용량에 따라 삭제 규칙을 적용할 수 있다. 또한 삭제를 원치 않는다면 카프카 클러스터가 살아있는한 토픽의 데이터를 삭제하지 않도록 설정할 수 있다. 데이터가 삭제되지 않고 남아있으면 추후에 데이터가 필요할때 오프셋을 지정해서 일주일, 한달 이상 지난 데이터를 다시 가져올 수 있다. 데이터를 더는 사용하지 않을 경우에는 cleanup.policy 옵션을 사용해서 데이터를 삭제할 수 있다. 옵션은 2가지다. 1) delete : 데이터의 완전 삭제 2) compact : 동일한 메시지 키의 가장 오래된 데이터를 삭제 토픽 삭제 정책(delete policy) 토픽을 운영하면 일반적으로 대부분의 토픽의 cleanup.policy를 dele..
들어가기전 토픽과 파티션의 기본개념 포스팅 바로가기 https://devfunny.tistory.com/380 카프카의 토픽과 파티션, 오프셋 토픽 카프카에서는 프로듀서가 전달하는 메시지를 '토픽'에 저장하고, 컨슈머가 해당 '토픽'에서 메시지를 가져온다고 하였다. 메시지의 저장소 역할을 하는 토픽은 데이터베이스의 '테이블'의 devfunny.tistory.com 토픽 카프카의 시작과 끝이다. 카프카를 사용하는 것은 토픽을 만들면서 시작하고, 토픽을 삭제하면 데이터는 삭제되고 파이프라인은 중단된다. 데이터의 생명주기 한가운데에 토픽이 있다. 적정 파티션 개수 토픽 생성시 파티션 개수 고려사항 - 데이터 처리량 - 메시지 키 사용 여부 - 브로커, 컨슈머 영향도 파티션의 개수가 많아질수록 1:1 매핑되는 ..
카프카의 AdminClient 제공 실제 운영환경에서는 프로듀서와 컨슈머를 통해 데이터를 주고받는것 만큼 카프카에 설정된 내부 옵션을 설정하고 확인하는것이 중요하다. 내부 옵션을 확인하는 가장 확실한 방법은 브로커 중 한대에 접속하여 카프카 브로커 옵션을 확인하는 것이다. 이는 매우 번거롭다. 카프카 클라이언트에서는 내부 옵션들을 설정하거나 조회하기 위해 AdminClient 클래스를 제공한다. 이 클래스를 활용하면 클러스터의 옵션과 관련된 부분을 자동화할 수 있다. 활용예시 카프카 컨슈머를 멀티 스레드로 생성할때, 구독하는 파티션 개수만큼 스레드를 생성하고 싶을때, 스레드 생성 전에 해당 토픽의 파티션 개수를 어드민 API를 통해 가져올 수 있다. AdminClient 클래스로 구현한 웹 대시보드를 통..