CQRS 도입기 - 2 Apache Kafka

정훈·2023년 4월 29일
0

CQRS

목록 보기
2/8

Apache Kafka

Apache Kafka 란

kafka는 데이터를 공유하는 이벤트 스트리밍 이다.

이벤트 스트리밍은 데이터베이스,센서,모바일장치,어플리케이션 같은 이벤트 소스에서 이벤트 스트림의 형태로 데이터를 실시간으로 데이터를 여러 사용자에게 전달하게하고, 빠르고 안정적이게 처리할수있도록 개발된 분산 메시징 플랫폼이다.

Apache Kafka 아키텍쳐

아파치카프카의 주 구성요소는 producer, consumer, consumer group,topic,cluster,partition

간단하게 아파치 카프카는 pub/sub 으로 이루어져있으며,
아파치카프카는 pub/sub가 장애가 발생할때도 의존성이 없어서 안정적으로 데이터 처리가 가능하다.
메세지(토픽)를/을 받고싶어하는 구독자로부터 메세지를 읽어받을수있으며 대용량 로그처리에 특화되어있어, 파일을 저장하고 관리하는데있어서 탁월하다.

아파치 카프카는 크게 producer(pub) ,consumer(sub),topic 이 된다

프로듀서가 메세지를 발행하여 topic을(메세지) 받고싶어하는 consumber에게 메세지를 읽을수가 있다. 이러한 메세지는 카프카클러스터에서 관리하게 되고 카프카클러스터안에 broker 를 두어서 데이터유실을 대비하며, 그 특징엔 topic과 partition이 있다

cluster

  • 클러스터는 여러개의 브로커를 가진다.
  • 토픽을 생성하게될 때 모든 카프카 브로커에 생성이된다.
  • 파티션은 여러 브로커에 걸쳐서 생성이 됨 .

zookeeper

주키퍼는 분산 어플리케이션을 위한 코디네이션 시스템이다.

카프카는 자체적으로 클러스터링 기능을 지원하고있다고합니다 . 자체 내에 코디네이션 시스템 디자인이 탑재되어 또한 consumer와 통신을 하고 설정관리 클러스터 관리 리더 관리 락 동기화 등을 목적으로 사용된다.

producer

  • 파티션 내부의 로 데이터를 전송 할 수 있다 push.
  • 파티션을 통해 브로커 간 데이터를 직렬화 또는 압축을 한다.

consumer

  • 파티션 내부에 있는 데이터를 구독하여 데이터를 읽는다 consumer는 consumer group 에 속하며 , 특정 consumer group 내의 consumer는 구독하는 각 주제의 파티션을 읽을수있고, 컨슈머는 하나의 컨슈머당 하나의 파티션이 원칙이며, 컨슈머가 데이터를 가져가도 데이터는 삭제되지않는다 . 가져올때마다 offset값을 커밋하기때문에 에러가 어디서 발생하고 어디까지 데이터를 가져왔는지 쉽게확인이가능하며 장애가 발생하게될경우 프로그램을 재가동 시킬 수 있다 .

consumer group

컨슈머 그룹은 개별로 컨슈머 객체들을 하나로 묶는 논리적인 그룹단위다.

컨슈머 그룹은 하나의 topic에대한 책임을 갖고있는데, 그룹내 컨슈머가 죽어버리게된다면 그 컨슈머가 맡고있던 파티션이 어디로 갈 상황이 없게되버리는것이다. 이러한 상황을 Rebalanace 된 상황이라고한다. 이러면서 다른 컨슈머가 이전에 죽어버린 컨슈머가 맡았던 파티션을 가지게되면서 이어서 진행이된다. down되기전, offset위치를 알고있다면 그 다음부턴 문제가없을것이다.

topic

  • 토픽은 카프카의 메세지 데이터를 구분하기 위해 사용되는 단위이다.또한 key(키),value(값) 형태로 구성된다.
  • 토픽에는 한개이상의 파티션이 존재한다.
  • 1개의 topic안에는 1개이상의 partition을 갖으며 여러개의 partition으로 나눌수있다

로그 세그먼트

  • topic(데이터)가 실제 저장되는 곳이며 파티션에서 확장된 개념이다. 메세지는 브로커의 로컬디스크에 저장되는 파일 을 말하고, 저장될때 key,value로 저장이되는데 상세적으로는 key,offset,size에 대한 정보도 함께저장된다 .

partition


위의 사진과 같이 토픽은 여러개의 파티션을 나누어 사용하게될수있다 . 하나의 파티션에는 순차적으로 append가 될텐데 이때 파티션을두어서 분산저장을 하는것이다.
이렇게 될 경우 분산으로 저장이 되어, 시간이 많이 절약되고, 속도또한 빠를것이라고생각이든다. 하지만 항상 좋다고 하진않는다고한다. 한번 늘린 파티션은 줄일 수 없다고 하여 파티션 늘리는건 충분히 고려해야한다고한다.

특징

  • 파티션에는 원본 파티션을 리더라고 칭하고 replication이 된 파티션을 팔로우라고 부르고있다. (리더만 읽기,쓰기를 할수있다. )
  • 하나의 토픽이 여러개로 나눠병렬로 처리할수있다.
  • 파티션은 토픽에 속한 레코드를 실제 저장소에 저장하는 가장 단위다.
  • 파티션은 데이터를 더 많이 더 빨리 보내고 처리할수있는것으로 만들어졌다
  • 파티션의 모든 기록들은 offset방식으로 id를 부여받고, Immutable(불변)속성을 갖는다 .
  • 토픽안에 파티션을 나누어 그 수대로 데이터를 분산처리한다.
  • 카프카 옵션중에 replica옵션이 있는데 이 수 만큼 파티션이 각 서버들에게 복제된다.

replication

카프카의 클러스터가 장애가 발생해도 안정적인 서비스를 제공하기위해 데이터 유실 및 유연성을 제공한다.

리플리카는 파티션의 복제본을 의미하며, 파티션의 복제본은 각 브로커에 생긴다 .

또한 카프카는 파티션에대해서 리더와 팔로워를 구성하면서 프로듀서와 컨슈머는 리더를 통해서만 메세지를 처리하고 팔로워 리더로부터 데이터를 복제해둔다. 이렇게함으로써 장애가 발생했을때 계속 이어서 다른 팔로워가 리더가되고 메세지를 처리할수있게된다 .

하지만 팔로워가 문제가 발생했을경우 즉 ,데이터가 제대로 복제가 안되었더라면 리더가 문제가 생겼을때 정합성문제가 생긴다. 이러한 문제를 막기위해 ISR 이라는 개념이 kafka에 존재한다 .

ISR

ISR은 약자로 In Sync Replica 이며 기본적으로 리더파티션, 팔로워 파티션이 싱크가 된 상태를 말한다.

ISR은 ISR에 속해있는 구성원만 리더의 자격을 갖는다.

ISR에서부터 리더가 역할을 못하게될경우 그 다음 팔로워가 리더로 선정이 되는데 ISR그룹의 리더는 팔로워가 주기적으로 데이터를 갖고있는지 계속 확인을하며 설정된 주기 만큼 요청(ack)이 오지않는다면 리더는 해당 팔로워 로부터 신호를 감지하게되는데 그 팔로워는 자신이 죽을경우 더 제 역할을 분명하게 하지못하는걸 판단하여 해당 팔로우를 추방시키며 추방당하게되면서 리더 자격도 박탈당하게된다.

ack

ack은 전송된 메세지의 수신을 나타내기위한 프로세스 간에 신호이다.

acks=0

  • ack 값이 0 일경우 브로커의 ack을 기다리지 않으며, 데이터가 유실되었을지 모른다. 이를 통해 레코드를 보내려고하지않고, 더 짧은대기시간과 더 높은 처리량을 제공함.

acks=1

  • acks값이 1일 경우 리더가 레코드를(데이터) 를 받은후 리더는 기록을 로그에 다 기록하며,리더의 수신만을 기다리고 이후 모든 팔로워 들을 확인하지않는다.

acks= all

  • all로 설정하게될경우 동기화중인 리더 및 팔로워들로부터 메세지를 잘 받은지 ack 으로 기다린다.최소 하나의 팔로워가있을경우 손실되지않는다 .

Reference

0개의 댓글