[실전 카프카 개발부터 운영까지] 4장. 카프카의 내부 동작 원리와 구현

[taewoo-kim123]

4장 카프카의 내부 동작 원리와 구현

이번장에서 배울 내용

• 리플리케이션 동작 : 내부 동작 원리와 구현에서 가장 중요한것 중 하나
• 리더와 팔로워의 역할
• 리더에포크와 복구동작
• 컨트롤러와 컨트롤러의 동작
• 로그와 로그컴팩션

4-1 카프카 리플리케이션

• 카프카는 수많은 데이터 파이프라인의 메인 허브역할을 수행
• 하드웨어 문제나, 점검으로 정상적인 동작을 한다면 전체적인 문제로 퍼질 수 있음
• 일시적인 하드웨어 이슈로 브로커 한두개에서 장애가 나더라도 안정적인 서비스가 운영될 수 있도록 구상됐음
• 이 안정성을 확보하기 위해 내부에서 리플리케이션 동작을 수행함

  4-1.1 리플리케이션 동작 개요

• 토픽 생성 당시replication factor 라는 옵션을 설정해야함

  /usr/local/kafka/bin/kafka-topics.sh --bootstrap-server kafka1:9092 
  --create --topic peter-test01 --partitions 1 --replication-factor 3

  (실습에서는 리플리케이션 팩터 옵션을 3으로 설정)

descrive로 방금 생성한 토픽을 출력

/usr/local/kafka/bin/kafka-topics.sh
--bootstrap-server peter-kafka01.foo.bar:9092 --topic peter--test01 --describe

1. peter-test01 토픽은 파티션 : 1, 리플리케이션 팩터 : 3
2. peter-test01 의 토픽의 파티션 0 에 대한 상세정보
   • 리더는 브로크 1을 나타내고, 리플ㄹ케이션들은 브로커 1,2,3에 있음
   • 뒤에있는 ISR은 동기화 되고있는 리플리케이션들이 브로커 1,2,3을 의미
3. peter-test01 토픽으로 test message1을 전송하고 세그먼트 파일의 내용을 확인하면 1,2,3 브로커가 동일한 메세지를 가지고 있음 세그먼트 파일의 내용 확인하는 명령어

   /usr/local/kafka/bin/kafka-dump-log.sh --print-data-log --files /data/kafka-logs/peter-test01-0/0000000000000000.log

1. 시작 오프셋 0
2. 메시지 카운트 1
3. 프로듀서를 통해 보넨 메시지가 test message1 이라는걸 알 수 있음
   • peter-kafka02,peter-kafka03 도 동일한 결과
   • N개의 리플리케이션이 있는경우 N-1 개의 브로커 장애가 발생해도 메세지 손실 없이 안정적으로 메세지 주고받기 가능. (일반적으로 3개를 권장한다고 함)

     4-1.2 리더와 팔로워

     

   • 파티션의 리더라는 부분은 리플리케이션중 하나가 선정되며, 모든 읽기와 쓰기는 그 리더를 통해서만 가능
   • 프로듀서는 모든 리플리케이션 리더에게만 메세지를 전송, 컨슈머는 리더로부터 메세지를 수신
   • 팔로워는 단순히 대기가 아니라 리더에 문제가 발생할 경우를 대비, 언제든지 리더가 될 준비를 함
   • 파티션 리더가 새로운 메세지를 받았는지 확인하고 새로운 메세지가 있다면 리더로부터 복제

4-1.3 복제유지와 커밋

• 리더와 팔로워는 ISR(InsyncReplica) 라는 논리적 그룹으로 묶여있음, 이 그룹에 속해있는 팔로워만 리더 자격을 가짐
• ISR 내 팔로워들은 리더와 데이터 일치를 유지하기 위해 지속적으로 리더 데이터를 따라가고, 리더는 팔로워들이 데이터 수신할때까지 기다림
• 근데 이때 장애가 일어나고, 데이터를 수신하지 못한 팔로워가 리더가 된다면 메시지 손실이 발생함
• 그래서 리더는 읽고 쓰는 동작 말고 팔로워가 리플리케이션 동작을 잘 수행하는지 판단도 함
• 팔로워가 특정 주기의 시간만큼 복제 요청을 하지 않는다면 리더는 해당 팔로워에 문제가 발생했다고 판단, ISR 그룹에서 추방
• 위에서 describe 명령어에서 존재했던 ISR 이 동기화 되고있는 그룹을 의미
• ISR 내애서 모든 팔로워의 복제가 완료되면 리더는 내부적으로 커밋을 표시 -> 커밋이 되었다라는건 모든 리플리케이션이 전부 메세지 복제를 했다는것을 의미
• 마지막 커밋 오프셋 위치를 하이워터마크 라고 부름
• 위 그림에서 커밋되지 않은 test message2는 못읽음

• 만약 읽게된다면 위의 그림과 같은 상황이 발생함
  1. 컨슈머 A가 파티션 리더로부터 test message1,test message2를 읽어감(test message2는 아직 복제 전)
  2. 이때 리더에 문제가 발생해서 test message2를 복제 못한 팔로워가 리더가 됨
  3. 새로운 컨슈머 B가 파티션 리더로부터 메세지를 읽는데 test message2가 없음
  4. 동일한 토픽의 파티션을 컨슘했음에도 메세지가 일치하지 않는 현상이 발생
     • 따라서 이런 현상을 방지하기 위해 커밋된 메세지만 컨슈머가 읽도록 구현됨

       커밋된 위치가 매우 중요함

• 커밋 위치를 어떻게 알까?
• 모든 브로커는 재시작될 때, 커밋된 메세지를 유지하기 위해 로컬디스크의 replication-offset-checkpoint라는 파일에 마지막 커밋 오프셋 위치를 저장함 (실습 생략...)

4-1.4 리더와 팔로워의 단계별 리플리케이션 동작

• 위 내용처럼 리더는 매우 바쁘게 동작함(읽고, 쓰고, 팔로워 동작 감시하고)
• 이렇게 바쁜 리더가 리플리케이션 동작을 위해 관여가 많아진다면 리더의 성능이 떨어지고, 카프카의 장점인 빠른 성능을 내기 힘듬

1. 리더만 0번 오프셋에 message1 이라는 메세지를 가지고 있음

2. 팔로워들이 리더에게 0범 오프셋 메세지를 가져오는 fetch 요청을 보낸 후, message1 을 인지하고, 리플리케이션 실행
3. 하지만 리더는 팔로워들이 0번 오프셋에 대한 리플리케이션 동작이 성공했는지 모름(RabitMQ는 Ack 통해 메세지 받았는지 알수있다고 함)

4. 리더가 1번 오프셋에 새로운 메세지 message2를 프로듀서로 받고 저장
5. 0번 오프셋에 대한 복제를 마친 팔로워들이 1번 오프셋 복제를 요청함
6. 팔로워들이 1번 오프셋 요청을 하면, 이 요청을 받은 리더는 팔로워들이 0번에 대한 복제가 성공했음을 인지하고, 0번 오프셋에 커밋을 하고, 하이워터마크를 증가
7. 팔로워가 0번 오프셋에 대한 복제를 성공하지 못했다면 팔로워는 0번에 대한 복제요청을 보냄
8. 리더는 팔로워들이 보내는 복제 요청을 보고 어디까지 성공했는지 인지 가능
9. 팔로워들로 부터 1번 오프셋 메세지에 대한 리플리케이션 요청을 받은 리더는 0번 오프셋 message1 메시지가 커밋되었다는 내용도 같이 전달

10. 리더의 응답을 받은 모든 팔로워들은 0번 오프셋 메세지가 커밋되었다는 사실을 인지하고, 리더와 동일하게 커밋함
11. 그리고 1번 오프셋 메세지인 message2를 복제함
12. 이 방법을 통해 파티션 내에서 리더와 팔로워 간 메세지의 최신 상태를 유지함

• 카프카는 RabbitMq 와 같이 ACK 통신하는 방식은 성능문제를 발생시킬 수 있음
• 카프카는 이걸 제거하고, 메세지 주고받는 기능에 집중
• ACK통신을 제거했음에도 팔로워와 리더간의 리플리케이션 동작이 매우 빠로고, 신뢰 가능.
• 리더의 푸쉬가 아니라 팔로워의 풀 방식이라 리더의 부하를 덜어줌

4-1.5 리더에포크와 복구

리더에포크

• 카프카의 파티션들이 복구할때 메세지를 일관성으로 유지하기 위한 용도로 이용됨
• 컨트롤러에 의해 관리되는 32비트의 숫자로 표기됨
• 리더에포크의 정보는 리플리케이션 프로토콜에 의해 전파되고, 새로운 리더가 변경된 후 변경된 리더에 대한 정보는 팔로워에게 전달됨
• 리더에포크는 복구 동작 시 하이웥마크를 대체하는 수단으로도 활용됨

리더에포크 사용하지 않은 경우

1. 리더가 message1수신, 0번에 저장, 팔로워는 0번 오프셋 가져오기 요청
2. 팔로워가 message1메세지를 복제하고
3. 리더는 하이워터마크를 1로 올림
4. 리더는 message2를 저장
5. 팔로워는 또 요청을 보내고, 응답으로 하이워터의 변화를 감지, 자기도 올림
6. 팔로워는 message2를 저장
7. 팔로워가 2번 오프셋에 대한 요청을 보내고, 리더는 message2가 복제되었음을 인지하고 하이워터마크를 2로 올림
8. 팔로워는 1번(책이 오타인듯??)에 대한 message2 복제를 완료했지만 아직 리더한테 하이워터마크 올리라는 내용은 전달 못받음
9. 팔로워가 다운됨
10. 팔로워는 자기가 가지고있는 메세지들중 자신의 워터마크보다 높은 메세지들은 신뢰할 수 없다고 생각함 그래서 message2를 삭제함
11. 팔로워는 리더로부터 1번 오프셋의 새로운 메세지 요청을 함
12. 근데 이순간 리더가 다운되면서 유일한 팔로워가 리더로 승격됨

• message2가 손실됨

리더에포크 사용하는 경우

• 팔로워가 장애에서 막 복구됐을때 하이워터마크보다 높은 메세지를 즉시 삭제하지 않고, 리더에게 리더에포크 요청을 보냄

1. 팔로워는 복구동작 하면서 리더에게 리더에포크 요청을 보냄
2. 요청받은 리더는 리더에포크의 응답으로 1번 오프셋의 message2까지 라고 팔로워한테 보냄
3. 팔로워는 자신의 하이워터마크보다 높은 1번 오프셋의 message2를 삭제하지 않고 리더의 응답을 확인한 후 message2 까지 자신의 하이워터마크로 상향조정
4. 이 이후 리더가 예상치 못한 장애로 다운되면서 팔로워가 새로운 리더로 승격되어도 message2는 삭제되지 않았고, 메세지 손실은 발생하지 않음

리더에포크 사용하지 않고, 리더와 팔로우 둘다 장애가 난 상황

1. 팔로워는 아직 message2를 받지 못한 상태
2. 이때 리더랑 팔로워 둘다 장애 발생

1. 팔로워가 먼저 복구됨
2. 리더가 없으므로 팔로워가 리더로 승격됨
3. 프로듀서로 부터 message3 를 받고 1번 오프셋에 저장함

1. 구 리더도 장애가 복구됨
2. 이미 리더가 존재하므로 복구된 브로커가 팔로워가 됨
3. 리더와 메세지 정합성을 위해 하이워터 비교를 하니 둘다 오프셋 1이라고해서, 메세지를 삭제하지 않음
4. 리더가 프로듀서로부터 message4를 받고 저장함
5. 팔로워는 message4를 복제준비함
   • 리더와 팔로워가 서로 가지고있는 메세지가 다름

리더에포크 사용하고, 리더와 팔로우 둘다 장애가 난 상황

1. 이전 상황과 동일하고, 구리더가 장애에서 복구됨
2. 이미 리더가 있어서 자신이 뉴팔로워가 됨
3. 뉴팔로워는 뉴리더한테 리더에포크 요청을 함
4. 뉴리더는 자신이 팔로워였을때 하이워터마크였던 0번 오프셋까지 유효하다고 응답함
5. 뉴팔로워는 메세지 일관성을 위해 1번 오프셋인 message2를 삭제함
6. 뉴팔로워는 뉴리더한테 1번오프셋인 message3 복제준비를 함
   • 리더와 팔로워가 서로 가지고있는 메세지가 같다

(실습 생략)

4-2 컨트롤러

• 리더선출을 맡고있음
• 카프카 클러스터중 하나의 브로커가 컨트롤러 역할을 함
• 파티션의 ISR 리스트 중에서 리더를 선출함
• ISR 리스트 정보를 주키퍼에 저장함
• 브로커가 실패하는것을 감시하고, 실패가 감지되면 ISR 리스트 중 새로운 파티션 리더로 선출함
• 선출된 리더 정보를 주키퍼에 기록하고, 변경된 정보를 모든 브로커에 전달함
• 파티션의 리더가 다운됐다라는것은 프로듀서나 컨슈머가 해당 파티션으로 읽기/쓰기가 불가해짐
• 클라이언트에 설정된 재시도만큼 재시도를 하게되는데, 빠르게 리더 선출작업이 이뤄져아한다

• 갑작스러운 종료과정

  1. 파티션0번의 리더가 있는 브로커 1번이 다운됨
  2. 주키퍼는 1번브로커와 연결이 끊어지고, 0번 파티션의 ISR에 변화가 생겼음을 감지
  3. 컨트롤러는 주키퍼 워치를 통해 0번파티션에 변화가 생긴걸 감지하고, ISR중 3번을 새로운 리더로 선출
  4. 0번 파티션의 새로운 리더가 3번이라는 정보를 주키퍼에 새로 저장
  5. 이걸 현재 활성화 상태인 모든 브로커에 전파(구 리더는 아직 죽은상태)

• 하나의 파티션에 대해 리더 선출은 0.2초만에 완료됨

• 근데 1만개면, 2000초가 걸림(분으로 환산하면 3분이 조금 넘는 시간)

• 카프카 1.1.0부터 리더선출 작업속도가 빨라졌음 (https://www.confluent.io/blog/apache-kafka-supports-200k-partitions-per-cluster/)

• 제어된 종료과정을 그림을 나타냄

  1. 관리자가 브로커 종료 명령어를 실행하고, SIG_TERM 신호가 브로커에 전달됨
  2. SIG_TERM 신호를 받은 브로커는 컨트롤러한테 알림
  3. 컨트롤러는 리더 선출 작업을 진행하고, 해당 정보를 주키퍼에 기록
  4. 새로운 리더 정보를 브로커들에게 전송
  5. 컨트롤러는 종료응답을 보낸 브로커에게 정상종료한다는 응답을 보냄
  6. 응답 받은 브로커는 캐시에 있는 내용을 디스크에 저장하고 종료함

• 제어된 종료과정과 갑작스러운 종료과정의 가장큰 차이는 다운타임임

• 카프카 내부적으로 파티션들의 다운타임을 최소화 할 수 있음

• 그 이유는 브로커가 종료되기 직전 컨트롤러가 해당 브로커가 리더선출 작업을 진행하기 때문임

• 제어된 종료더라도 일시적인 다운타임은 발생함

4-3 로그(로그 세그먼트)

• 카프카의 토픽으로 들어오는 메시지(레코드)는 세그먼트(로그 세그먼트)에 저장됨
• 로그 세그먼트에는 메시지만 저장되는게 아닌, 키,밸류,오프셋,메시지 크가와 같은 정보가 같이 저장되고, 로그세그먼트 파일들은 브로커의 로컬디스크에 저장
• 로그 세그먼트의 크기는 1GB를 기본으로 설정함 이것보다 커지면 롤링 전략을 이용
• 로그 세그먼트의 크기가 1GB에 도달하면 세그먼트 파일을 닫고, 새로운 로그세그먼트를 생성함
• 하지만 이 방법도 결국 로그 세그먼트 파일이 무한히 늘어나는 경우를 대비해 로그 세그먼트 삭제랑 컴펙션 기법이 존재함

4-3.1 로그 세그먼트 삭제

• 브로커 설정파일인 server.properties 에서 log.cleanup.policy를 delete로 설정해야함 (기본값으로 설정되어있음)
• 카프카 관리자는 토픽마다 보관주기를 조정해서 얼마만큼의 기간동안 카프카에 로그를 저장할지 결정하고 관리 가능
• default 값은 7일이므로 7일이 지나면 전부 삭제됨
• retention.byte라는 옵션을 통해 지정된 크기로도 로그 세그먼트를 삭제 가능

4-3.2 로그 세그먼트 컴팩션

• 로그를 삭제하지 않고 컴팩션 해서 보관함
• 로그컴팩션은 기본으로 로컬 디스크에 저장되어있는 세그먼트를 대상으로 실행됨.
• 현재 활성화된 세그먼트는 제외하고 나머지 세그먼트들을 대상으로 컴팩션이 실행됨
• 아무리 컴팩션이어도 무기한으로 보관하면 로그의 용량 감당이 안됨 그렇기때문에, 단순히 컴팩션해서 보관하는것보다 더 효율적인 방법으로 컴팩션을 함
• 카프카에서는 메세지(레코드)의 키값을 기준으로 마지막 데이터만 보관함

_consumer_offset

• 카프카의 내부 토픽으로, 컨슈머 그룹을 저장하는 토픽

• 컨슈머 그룹이 어디까지 읽었는지를 나타내는 오프셋 커밋 정보가 키(컨슈머 그룹명, 토픽명) 벨류(오프셋 커밋 정보) 형태로 메세지가 저장됨

• 로그컴팩션은 메세지의 키값을 기준으로 과거 정보는 중요하지 않고 가장 마지막 값 일 경우에 사용된다

• 예를 들어서 구매 상태 정보가 주문완료 -> 배송준비 -> 배송 중 -> 배송 완료 일때

• 구매한 사용자의 아이디(메세지의 키)를 기준으로 최종상태(메세지의 밸류)만 사용자에게 노출하면 되므로 카프카의 로그 컴팩션 기능을 활용할 수 있음

• value 는 필수지만, 키는 필수가 아니라 로그 컴팩션 기능을 사용하려면 키값을 필수값으로 전송해야함

• 위 이미지 보면 하나의 키값에 대해 벨류값들은 최신화 되어있는걸 확인 할 수있음

  장점

  빠른 장애 복구 : 로그를 전체 다 보지 않아도 되므로 복구시간을 줄일 수 있음

[kmg28801]

• 리플리케이션 대상은 토픽이 아니라 파티션이다. 중요한 사실은 실제로 리플리케이션되는 것은 토픽이 아니라 토픽을 구성하는 각각의 파티션들이라는 점입니다. (책 p.115)
• 프로듀서는 오직 리더에게만 메시지를 보낸다. 컨슈머도 오직 리더로부터만 메시지를 가져온다.