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

http://www.yes24.com/Product/Goods/104410708

해당 책을 공부하며 정리한 내용입니다.

실전 카프카 개발부터 운영까지 - YES24

 

카프카 리플리케이션 동작 방식

---

• 리더는 리플리케이션 중 하나가 선정되며, 모든 읽기와 쓰기는 해당 리더를 통해서만 가능합니다.
  • 프로듀서는 모든 리플리케이션에 메시지를 보내는 것이 아니라 리더에게만 메시지를 전송한다.
  • 컨슈머도 역시 오직 리더로부터 메시지를 가져옵니다.
• 컨슈머는 지속적으로 파티션의 리더가 새로운 메시지를 받았는지 확인하고, 새로운 메시지가 있다면 해당 메시지를 리더로부터 복제합니다.
  • 또한 리더에 문제가 발생하는 경우를 대비해 언제든지 새로운 리더가 될 준비를 합니다.

복제 유지와 커밋

• 리더와 팔로워는 ISR (InSyncReplica)라는 논리적인 그룹으로 묶여 있음.
  • 해당 ISR 그룹 안에 속한 팔로워들만이 새로운 리더의 자격을 가질 수 있음.
  • ISR 내의 팔로워들은 리더와의 데이터 일치를 유지하기 위해 지속적으로 리더의 데이터를 따라가게 되고, 리더는 ISR 내 모든 팔로워가 메시지를 받을 때까지 기다린다.
  • 만약 네트워크 오류, 브로커 장애 등 여러 이유로 리더로부터 리플리케이션하지 못하는 경우, ISR 그룹에서 제외된다.
  • 파티션의 리더는 팔로워들이 뒤처지지 않고 리플리케이션 동작을 잘하고 있는지 감시하며, 잘 따라잡고 있는 팔로워들만이 ISR 그룹에 속하게 된다.
    • 리더는 읽고 쓰는 동작은 물론, 팔로워가 리플리케이션 동작을 잘 수행하고 있는지도 판단.
    • 만약 팔로워가 특정 주기의 시간만큼 복제 요청을 하지 않는다면, 리더는 해당 팔로워가 리플리케이션 동작에 문제가 발생했다고 판단해 ISR 그룹에서 추방한다. (새로운 리더가 될 자격을 박탈당함)
  • ISR 내에서 모든 팔로워의 복제가 완료되면, 리더는 내부적으로 커밋되었다는 표시를 하게 된다. (마지막 커밋 오프셋 위치는 하이워터마크라고 부름)
    • 즉 커밋되었다는 것은 모든 리플리케이션이 전부 메시지를 저장했음을 의미한다.
    • 메시지 불일치 현상을 방지하기 위해 (메시지의 일관성을 유지하기 위해) 커밋된 메시지만 컨슈머가 읽어갈 수 있도록 구현되어 있다.
    • 커밋된 위치는 브로커의 디스크에 replication-offset-checkpoint라는 파일에 마지막 커밋 오프셋 위치를 저장한다.

    will-test01 0 1
    
    will-test01: 토픽 이름
    0: 파티션 번호
    1: 오프셋 위치
    

리더와 팔로워의 리플리케이션 동작

• 리더가 리플리케이션 동작을 위해 팔로워들과 많은 통신을 주고받거나 리플리케이션 동작에 많은 관여를 한다면, 리더의 성능은 떨어지고 카프카의 장점인 빠른 성능을 내기도 어렵게 된다.
  • 카프카는 리더와 팔로워 간의 리플리케이션 동작을 처리할 때 서로의 통신을 최소화할 수 있도록 설계함으로써 리더의 부하를 줄였다.
  • 카프카는 리더와 팔로워 사이에 ACK 통신을 제거함으로써 리플리케이션 동작의 성능을 높였다. (다른 여러 메시징 시스템들은 리플리케이션 동작에서 리더와 팔로워가 메시지를 잘 받았는지 확인하는 ACK 통신을 수행하는 반면)
  • 카프카에서 리플리케이션 동작 방식은 리더가 푸시하는 방식이 아니라 팔로워들이 풀 하는 방식으로 동작한다. (리플리케이션 동작에서 리더의 부하를 줄여주기 위해 채택되었다)

컨트롤러

---

• 컨트롤러는 리더 선출을 맡고 있음.
• 카프카 클러스터 중 하나의 브로커가 컨트롤러 역할을 수행, 파티션의 ISR 리스트 중에서 리더를 선출.
  • 리더를 선출하기 위한 ISR 리스트 정보는 가용성 보장을 위해 주키퍼에 저장되어 있음.
• 컨트롤러는 브로커가 실패하는 것을 모니터링하고 있으며, 브로커의 실패가 감지되면 즉시 ISR 리스트 중 하나를 새로운 파티션 리더로 선출한다.
  • 추가로 새로운 리더의 정보를 주키퍼에 기록하고, 변경된 정보를 모든 브로커에 전달한다.

로그 (로그 세그먼트)

---

• 카프카의 토픽으로 들어오는 메시지는 세그먼트라는 파일에 순차적으로 저장된다.
• 로그 세그먼트에는 메시지의 내용 + 메시지의 키, 오프셋 ,메시지 크기와 같은 정보가 함께 저장되며, 브로커의 로컬 디스크에 보관된다.
• 하나의 로그 세그먼트 크기가 너무 커져버리면 파일을 관리하기 어렵기 때문에, 로그 세그먼트의 최대 크기는 1GB가 기본값으로 설정되어 있다.
  • 로그 세그먼트가 1GB보다 커지는 경우 기본적으로 롤링 전략을 사용한다. (1GB보다 커진 해당 세그먼트 파일을 클로즈하고 새로운 로그 세그먼트를 생성하는 방식)
• 1GB 크기의 로그 세그먼트 파일이 무한히 늘어날 경우를 대비해 로그 세그먼트에 대한 관리 계획을 수립해둬야 한다.
• 로그 세그먼트를 관리하는 방법은 크게 로그 세그먼트 삭제와 컴팩션으로 구분할 수 있음.

로그 세그먼트 삭제

• 해당 옵션은 server.properties에서 log.cleanup.policy가 delete로 명시되어야 한다. (Default 옵션)
• 토픽마다 보관 주기를 조정해서, 얼마만큼의 기간 동안 카프카에 로그를 저장할지를 결정하고 관리할 수 있음.
  • server.properties에 보관시간 기준으로 삭제하는 retention.ms옵션을 설정할 수 있음. (기본값은 7일로, 모든 세그먼트 파일은 7일이 지남과 동시에 전부 삭제된다)
  • 다른 방식은 server.properties에 retention.bytes옵션을 사용하면, 지정된 크기를 기준으로 로그 세그먼트를 삭제할 수도 있다.

로그 세그먼트 컴팩션

• 로그를 삭제하지 않고 컴팩션하여 보관하는 로그 세그먼트 관리 정책
• cleanup.policy=compact(토픽의 옵션으로 적용) log.cleanup.policy=compact(브로커의 설정 파일에 적용)
• 기본적으로 로컬 디스크에 저장되어 있는 세그먼트를 대상으로 실행되며, 현재 활성화된 세그먼트는 제외하고 나머지 세그먼트들을 대상으로 컴팩션이 실행된다.
• 로그 컴팩션 기능을 이용하는 대표적인 예시로 __consumer_offset 토픽을 들 수 있다. (컨슈머 그룹의 정보를 저장하는 토픽으로 해당 컨슈머 그룹이 어디까지 읽었는지를 나타내는 오프셋 커밋 정보가 포함되어 있다.)이런 식으로 저장될 때, 로그 컴팩션 동작이 일어나면 다음과 같이 마지막 데이터인 3만 남게된 다.
  • 컨슈머 그룹은 항상 마지막으로 커밋된 오프셋 정보가 중요하므로, 과거에 커밋된 정보들은 삭제돼도 무방하다.
• CG01 (컨슈머 그룹) T01(토픽명): 3 (오프셋 커밋 정보)
• CG01 (컨슈머 그룹) T01(토픽명): 1 (오프셋 커밋 정보) CG01 (컨슈머 그룹) T01(토픽명): 2 (오프셋 커밋 정보) CG01 (컨슈머 그룹) T01(토픽명): 3 (오프셋 커밋 정보)
• 이런식으로 로그 컴팩션은 메시지 키값을 기준으로 과거 정보는 중요하지 않고 가장 마지막 값이 필요한 경우에 사용한다.
• 로그 컴팩션을 사용하면 빠른 장애 복구가 가능한데, 장애 복구 시 전체 로그를 복구하지 않고, 메시지의 키를 기준으로 최신의 상태만 복구하기 때문이다.