카프카란?
아파치사에서 개발한 대용량 메시지 처리를 위한 오픈소스
기존에는 end to end 연결 방식의 아키텍처를 사용했음.
- 데이터 연동의 복잡성 증가
- 각기 다른 데이터 파이프라인 연결 구조
- 확장에 엄청난 노력필요..
- 모든 시스템으로 데이터를 전송, 실시간 처리도 가능
- 데이터가 갑자기 많아지더라도 확장에 용이한 시스템이 필요함
위의 단점으로 인하여 Kafka가 등장.
카프카가 중앙에서 모든 메시지를 처리하는 구조
- 프로듀서 / 컨슈머 분리
- 메시지 데이터를 여러 컨슈머에게 허용(어떤 데이터가 카프카에 들어간 이후로 여러번 사용가능하도록)
- 높은 처리량을 위한 메시지 최적화
- 스케일 아웃가능(무중단)
브로커(broker)
카프카는 크게 메지지를 발행하는 프로듀서, 소비하는 컨슈머, 그리고 그 사이에서 메시지를 저장 전달하는 브로커로 구성된다. 일반적으로 카프카 = 브로커 = 서버 라고 이해해도 무방. 3대이상의 브로커로 구성한다는뜻은 카프카를 3대 설치한다는 것과 동일.
- 3대 이상의 브로커로 클러스터 구성 ( 홀수로 구성해야 컨트롤러를 선정하기편함)
- 주키퍼와 연동(~2.5.0버전)
- n개 브로커 중 1대는 컨트롤러 기능 수행
- 컨트롤러 : 각 브로커에게 담당파티션 할당 수행. 다른 브로커들이 정상 동작하는지 모니터링관리. 누가 컨트롤러인지는 주키퍼에 저장. (파티션1의 리더는 브로커1이 맡고, 브로커2,3번은 복제.. 파티션2의 리더는 브로커2가 맡고 1,3은 복제..)
주키퍼(zookeeper)
브로커의 설정정보 및 메타정보를 저장해주는 역할. 브로커는 주키퍼없이 단독으로 동작할수없다. 브로커들중에 컨트롤러 브로커를 선출해주며 컨트롤러 브로커가 죽었을때 다른 브로커 중에 새로운 컨트롤러 선출시킨다.
주키퍼는 디렉터리 형태로 데이터를 저장, 관리한다. 그리고 카프카의 메타 정보는 클러스터 구성할 때, 주키퍼 연결 설정(zookeeper.connect)에서 지정된 디렉토리 하위에 저장. 따라서 동일한 카프카 클러스터는 주키퍼 연결 설정에서 동일한 디렉토리 경로를 가지며, 하나의 주키퍼 클러스터에 여러 카프카 클러스터가 동시에 구성될 수 있다. (하위에 디렉토리에 저장하면 되니까)
토픽(topic)
메시지의 논리적인 분류단위. 이 토픽을 기준으로 메시지를 발행, 구독한다. JSON & 객체 & 문자열 등 어떠한 값이라도 가능. 이렇게 다양한 값을 지원하는것은 데이터전체가 kafka내부에 byte형태로 저장될 수 있도록 직렬화/역직렬화 사용되기때문.
파티션(partition)
메시지를 담고있는 물리적인 구분단위. 토픽별로 파티션을 여러개 두는 이유는 분산처리의 장점을 활용하기위함이다. 1개밖에없다면 1개의 파티션이 모든 발행 구독을 처리해야하므로..
- 토픽안에 파티션은 1개이상 반드시 존재해야함
- 각 파티션마다 고유한 오프셋을 가짐
- 메시지 처리순서는 파티션별로 유지관리됨. (즉, 파티션이 여러개인경우 순서를 보장할 수 없다)
- 토픽의 파티션은 늘리는것은 가능하지만 줄일 수 는 없다.
각 파티션은 1개의 리더 파티션 & 다수의 팔로워 파티션으로 구성된다. 파티션의 발행 구독을 담당하는 것은 리더뿐이며, 팔로워는 리더의 메시지를 그대로 복제하여 가지고있기만 한다. 팔로워의 존재목적은 피치못한 상황으로 리더파티션이 장애가 발생했을때, 리더자리로 선출되기위한 예비용이다. 다만, 이 시점에서 리더의 모든 메시지를 완벽하게 가지고있는 팔로워만이 리더자리에 올랐을때 데이터 유실이 없게된다. 이러한 팔로워를 ISR라고 한다.
1개의 토픽은 여러개의 파티션을 가지는데, 각각의 파티션 마다 리더&팔로워 파티션을 가지고 있다.
브로커 3대로 구성되어있는 카프카에 파티션 3개로 토픽을 만들면 각각 균등하게 브로커1=파티션1로 분배된다.
만약 브로커에 장애가 발생하면, 해당파티션은 사용할 수 없게된다. 이런 이슈를 방지하기위해 다른 브로커에 데이터를 복제해놓음. 브로커 개수 이상으로 --replication-factor를 지정할 수 없다.
${KAFKA_HOME}/bin/kafka-topics.sh --create --zookeeper localhost:2181 --topic kafka_name --replication-factor 3 --partitions 3
리더 파티션1의 offset이 0~100까지 있는데,
팔로워 파티션이 0~90까지밖에 복제를 못했다면 ISR상태가 아님
unclean.leader는 기본적으로 = false상태 (ISR인 팔로워 파티션에게서 리더를 선출하라). 이상태에서 장애가 나면 리더를 선출하지않고 복구될때까지 기다림.
하지만 true라면 ISR이 아닌 팔로워 파티션에서 리더를 선출하므로 진행은되지만 90~100까지의 데이터는 유실됨.
카프카 클러스터는 서버 장애에 대한 로직이 많다.
일부서버가 중단되더라도 데이터가 유실되면 안됨. → 복제를 통하여 데이터 유실을 방지함
카프카는 이러한 안정성을 목적으로 설계된 오픈소스이기 때문이다.
카프카 생태계
- kafka client: 현재까지 언급된 카프카 컨슈머, 프로듀서는 kafka client를 의미함.
- kafka streams: kafa streams 은 일단 안씀
- kafka connect코드 없이 configuration으로 데이터를 이동시키는것이 목적
- 많은경우 카프카 클라이언트로, 카프카로 데이터를 넣는 코드를 직접 작성할수도있지만, kafka connect를 통해 데이터를 im/export할수도있음.
- kafka mirror maker: 특정 카프카 클러스터에서 다른 카프카 클러스터로 토픽 및 레코드를 복제하는 툴
프로듀서(Producer) & 컨슈머(Consumer)
프로듀서는 레코드를 생성(발행)하여 브로커로 전송하는 역할.
컨슈머는 발행된 레코드 브로커로부터 가져오는(구독) 역할.
- 전송된 레코드는 파티션에 신규 오프셋과 함께 기록됨
- 컨슈머는 브로커로부터 레코드를 요청하여 가져감(Polling)
각각 다른 컨슈머들은 동일한데이터를 여러번 가지고갈수있음. 단, 1개의 파티션은 컨슈머그룹당 1개의 컨슈머만 접근이 가능하다.
리벨런스 : 컨슈머가 장애가 발생하여 정상컨슈머에게 업무를 돌리는 과정
파티션이 많다고 좋은것이 아닌이유가 여기서 나타남. 파티션이 많을수록 리밸런스할때 오래걸림.
또한 파티션개수는 한번 설정되면 늘릴 수 는 있어도, 줄이는것은 불가능하기때문에 신중해야함.
컨슈머그룹
목적에 따라서 컨슈머들을 그룹화할 수 있음. 1개 토픽은 여러 컨슈머 그룹에 할당 가능.
컨슈머 그룹들간의 간섭이 없으며 장애시의 영향이 없음.
컨슈머A와 컨슈머B는 다른 컨슈머임. 컨슈머 A가 파티션0을 9까지 읽었다고해서 B에게 영향을 주지않음.
다음장에는 카프카를 설치할때의 config옵션과 sh 사용법, 그리고 자바로 컨트롤러&프로듀서를 작성하는 법을 다뤄본다.
참고 : https://always-kimkim.tistory.com/entry/kafka101-broker
'IT > 오픈소스' 카테고리의 다른 글
| JPA - 기본 개념 (1) | 2024.01.30 |
|---|---|
| 카프카(Kafka) - 활용정리 (0) | 2023.09.12 |
| Docker란? (1) | 2023.03.26 |
| 네티(Netty) 기본정리2 (0) | 2022.02.22 |
| 네티(Netty) 기본정리 (0) | 2022.02.06 |
댓글