Kafka 내부 메커니즘 - 2)요청처리

Kafka의 요청 처리

당연히 클라이언트가 요청하는 주체 일 것이고, 요청을 처리하는 주체는 Broker가 된다. 또 여기서 말하는 클라이언트는 아마 Producer, Consumer가 될 것이다.

Kafka는 TCP로 전송되는 이진 프로토콜을 갖고 있으며, 항상 요청을 수신한 순서대로 브로커가 처리하기 때문에 카프카가 메세지 큐처럼 동작이 가능하다.

 

그럼 Kafka가 갖고있는 프로토콜의 모양을 살펴보자

프로토콜 헤더 살펴보기

요청타입 ID	16bit, 정수형	요청 타입을 구분하는 값이 들어간다 ex. Produce하는 요청의 ID값은 1, Consumer하는 요청의 ID값는 2 (아마 Kafka 내부적으로 정의된 값이 있을 것이다. 위 예시는 정말로 예일 뿐)
요청 버전	16bit, 정수형	API 버전 값 (Client가 각각 다른 API 버전을 사용하더라도 브로커는 이들에 대한 호환성을 보장 해줘야 한다)
cID(correlation ID)	32bit, 정수형	각 요청에 대한 고유 식별값. 추후 문제가 발생시 많이 사용하며 응답과 에러 로그에도 사용됨,
Client ID	string, nullable	Client Application 식별 문자열. 사용자가 지정한 값이 들어감

더불어, 요청타입ID에 따라 헤더 항목이 추가될 수 있다(Produce 요청의 경우, 토픽 이름과 파티션ID 및 데이터 등이 포함됨)

※더 자세한 프로토콜 내용은 카프카 문서를 참고하기 바람

 

Broker의 요청 처리의 구성요소

먼저 구성 요소는 아래와 같다

Acceptor Thread	브로커는 자신이 리스닝하는 각 포트에 대해서 acceptor 스레드를 실행하고, Client와 Processor Thread와의 연결을 생성함
Processor(Network) Thread	Client 연결로 부터 요청을 받고, 그것을 Request Q에 넣고,Response Q에서 응답을 가져와 클라이언트에게 전송하는 일을 수행 함
Request Queue	여기에 쌓이는 요청 타입은 아래와 같다 - 쓰기 요청(Produce request) : 프로듀서가 전송. 브로커에게 쓰려는 메세지를 포함하고 있음 - 읽기 요청(Fetch request) : 컨슈머와 팔로어 리플리카가 브로커로부터 메세지를 읽을 때 요청함 - 메타데이터 요청(Metadata request) : 요청자가 관심을 갖는 토픽 내역을 포함하여 요청하면, 토픽에 존재하는 파티션들, 각 파티션의 리플리카, 리더 리플리카에 대한 정보를 응답으로 반환해줌
In/Output Thread	Request Q의 요청들을 처리하는 책임을 가짐
Response Queue

이들의 Flow는 아래와 같다(In/Output Thread는 생략되어 있음)

요청 처리 Cycle

요청 처리에 있어 알아야 할 점은, 카프카의 클라이언트들(Producer, Consumer, Follow Replica)이 쓰기 혹은 읽기 요청을 할 때는 메타데이터 정보를 이용해, 요청 관련 파티션의 리더를 포함하는 브로커에게 요청을 전송해야 한다. 그렇지 않은 경우 에러가 발생함(메타데이터를 요청에 대한 시간간격을 설정하는 매개변수는 metadata.max.age.ms 이 친구가 너무 길면, 새로운 정보를 갱신받지 못할 수 있음. 운영하면서 조절 필요함)