4. kafka 구조

1. 카프카 구조의 특징

1.1 분산 시스템

 분산 시스템이란 같은 역할을 하는 여러 대의 서버로 이뤄진 서버 그룹을 분산 시스템이라고 하며, 분산 시스템의 장점은 아래와 같습니다.

• 단일 시스템보다 더 높은 성능을 낼 수 있다
• 운영중인 서버에 장애가 발생하면 같은 그룹의 다른 서버가 일을 대신 처리할 수 있다.
• 시스템 확장이 용이하다.

1.2 페이지 캐시

 OS는 물리적 메모리에 애플리케이션이 사용하는 부분을 할당하고 남은 잔여 메모리 일부를 페이지 캐시로 유지해 OS의 전체적인 성능 향상을 높이게 됩니다. 카프카는 이러한 특징을 이용해 빠른 액세스를 하기 위해 OS의 페이지 캐시를 이용하도록 디자인 되었습니다.

1.3 배치 전송 처리

 서버와 클라이언트 사이 또는 서버 내부적으로 데이터를 주고받는 과정에서 I/O가 발생하는데, 카프카는 이를 최소화 하기 위해 배치 작업으로 처리합니다.

 

2. 카프카 데이터 모델

2.1 토픽

 토픽은 말 그대로 '제목'을 의미한다. 즉, consumer들이 자신이 구독하고싶은 topic을 구독하면, 구독한 topic에 데이터가 들어올 때마다, broker가 consumer에게 데이터를 전달해준다. 마치, 신문을 구독하면 신문사에서 구독자에게 매일매일 신문을 보내주는 것처럼 말이다.

2.2 파티션

topic과 partition

파티션이란 토픽을 분할한 것을 말한다. 왜 하나의 토픽을 파티셔닝 할까요? 프로듀서에서 카프카로 메세지를 보내는 시간 때문에 그렇습니다. 만약에 토픽을 파티션 단위로 나누지 않으면, producer가 n개의 메세지를 카프카에게 보낼때, 순서대로 한개씩 n번을 보내야하는 문제가 있습니다. 그래서 kafka는 이 문제를 해결하기 위해 토픽 안에 n개의 파티션을 두어서 producer가 n개의 메세지를 카프카에 한 번에 전송할 수 있도록 하여 성능 개선을 기대할 수 있습니다. 이론상으로 순차적으로 메세지를 보내면 n초의 시간이 걸릴 것을 파티션을통해 1초로 해결할 수 있게됩니다. 

 

 추가로, 카프카의 빠른 전송을 위해서는 토픽의 파티션을 늘려주어야 하며, 그 수만큼 프로듀서 수도 늘려야 제대로 된 효과를 볼 수 있습니다.

 

(참고) 2.2.1 무조건 파티션을 늘리는게 좋을까?

• 장애 복구 시간 증가
   예를들어 브로커에 총 1000개의 파티션이 있고 2개의 리플리케이션이 있는 브로커가 갑자기 종료되면, 일시적으로 이 브로커에 있는 1000개의 파티션은 사용할 수 없게 됩니다. 파티션의 리더를 다른 브로커가 있는 곳으로 이동시켜야 사용할 수 있습니다. 만약 컨트롤러가 각 파티션별로 새로운 리더를 선출하는 데 5밀리초의 시간이 소요된다고 가정하면, 1000개의 모든 파티션에 대해 새로운 리더를 선출하는 데는 총 5초가 소요되며, 일부 파티션의 경우 장애 시간은 5초 이상이어질 수도 있습니다.

(참고) 2.2.2 적절한 파티션 수 찾기

• 목표처리량 선정
  프로듀서에서 초당 몇 개의 메세지를 보낼 수 있는지와 1개의 파티션이 몇개의 메세지를 받을 수 있는지를 계산하여 프로듀서에서 보내는 메세지를 topic에서 1초안에 처리하려면 몇개의 파티션이 필요한지를 결정하는 방법입니다. 참고로, 카프카에서 파티션 수의 증가는 필요한 경우 아무때나 변경이 가능하지만, 반대로 파티션의 수를 줄이는 방법은 제공하지 않습니다.

2.3 오프셋과 메시지 순서

 카프카에서는 각 파티션마다 메시지가 저장되는 위치를 오프셋(offset)이라 부르며, 오프셋은 파티션 내에서 유일하고 순차적으로 증가하는 숫자형태로 되어있습니다. 

 

3. 고가용성과 리플리케이션

 카프카는 가용성을 보장하기 위해 replication 기능을 제공합니다. 이 기능은 가용성을 위해 여러 브로커를 띄웠을 때, 카프카의 replication은 토픽 자체를 복제하는 것이 아니라 토픽 내부의 파티션을 리플리케이션 합니다.

3.1 리플리케이션 팩터와 리더, 팔로워의 역할

leader and follower

 리더와 팔로워는 각자 역할이 나뉘어 있는데 가장 중요한 핵심은 모든 읽기와 쓰기가 리더를 통해서만 일어납니다. 즉 팔로워는 리더의 데이터를 그대로 리플리케이션만 하고 읽기와 쓰기에는 관여하지 않습니다. 리더와 팔로워는 저장된 데이터의 순서도 일치하고 동일한 오프셋과 메시지들을 갖게 됩니다. 다만, 여기서 헷갈리면 안되는게, 하나의 브로커에 모든 리더가 속해있는게 아니라는 점입니다. 위의 그림을 보면 알 수 있듯이 각각의 리더는 서로 다른 브로커에 위치할 수 있습니다.

 

 만일 리더가 속한 브로커가 다운되어 리더가 메세지 요청에 대해 응답할 수 없는 상태가 된다면, 다른 브로커에 있는 follower가 자동적으로 리더로 선출되어 프로듀서의 요청들을 처리할 수 있게 됩니다.

 

3.2 리더와 팔로워의 관리

ISR

 만일 팔로워에 문제가 있어 리더로부터 데이터를 가져오지 못하면서 정합성이 맞지 않는 경우에는 어떻게 될까요? 그리고 이 상태에서 리더까지 다운되면 데이터 정합성이 맞지 않아서 큰 문제가 발생할 수 있습니다. 카프카는 이 문제를 방지하고자 ISR(In Sync Replica)이라는 개념을 도입했습니다.

 

 ISR은 한 마디로 리플리케이션 되고 있는 리플리케이션 그룹입니다. ISR에는 중요한 규칙이 하나 있는데, ISR에 속해있는 구성원만이 리더의 자격을 가질 수 있습니다.

 

 위의 그림 2번을 보면 3개의 토픽이 하나로 묶여있는데, 만일 저기서 '토픽 팔로워2'가 장애가 생긴다면, 3번 그림과 같이 됩니다. 그리고 3번 그림에서 토픽 리더가 죽게되면, 자연적으로 토픽 팔로워1이 리더로 승격되게 됩니다.

 

4. 주키퍼 지노드의 역할

 주키퍼의 지노드 리스트 중에 알아둬야할 지노드들이 있습니다. 아래의 지노드들을 통해 카프카에 문제가 발생했을 때, 상태정보 등을 확인할 수 있습니다.

• controller
  파티션의 리더 변경에 관여

• brokers
  토픽의 파티션 수, ISR 구성 정보, 리더 정보 등을 확인

•  consumers
  offset 정보 저장

• config
  토픽의 상세 설정 정보 확인

 

참고 - 카프카, 데이터 플랫폼의 최강자 - 고승범, 공용준 지음, 책만