카프카의 내부 동작 원리(리플리케이션,리더, 팔로워, 리더에포크, 컨트롤러,로그)

카프카 리플리케이션

리플리케이션 동작 개요

리더와 팔로워

복제 유지와 커밋

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

리더에포크와 복구

컨트롤러

컨트롤러의 중요성

컨트롤러의 리더 선출 과정

로그(세그먼트)

로그 세그먼트 삭제

로그 세그먼트 컴팩션

카프카 리플리케이션

• 고가용성 분산 스트리밍 플랫폼인 카프카는 무수히 많은 데이터 파이프라인중에 정중앙에 위치하는 메인 허브 역할을 합니다.

• 메인 허브 역할을 하는 카프카가 다운되거나 문제가 발생할 경우 정상적으로 동작하지 못한다면 심각한 문제가 발생하게 됩니다.

• 이러한 문제점을 해결할 수 있도록 카프카는 초기 설계 때부터 일시적으로 브로커에서 장애가 발생해도 안정적으로 운영될 수 있도록 리플리케이션을 수행하게 됩니다.

• 이번글에서는 리플리케이션에 대해 살펴보며 추가적으로 리더, 팔로워의 역할과 복구 방식들에 살펴보도록 하겠습니다.

리플리케이션 동작 개요

• 카프카에서 리플리케이션 동작을 수행하기 위해서는 토픽 생성시 필숫값으로 replication factor라는 옵션을 설정해야합니다.

/usr/local/kafka/bin/kafka-topics.sh --bootstrap-server peter-kafka-1.foo.bar:9002 --create --topic peter-test01 --partitions 1 --repication-factor 3

• 위 명령어를 실행하게 되면 토픽이 생성되게 되는데 이때 내부적으로 하나의 브로커에 리더 브로커가 설정되게 되고 나머지 리플리케이션들은 나머지 브로커에 할당되게됩니다.

• 주의해야할점은 실제로 리플리케이션되는것은 토픽이 아니라 토픽을 구성하는 파티션이라는점입니다.

• 이렇게 리플리케이션된 상태에서는 peter-test01 토픽으로 메시지를 보내게 되면 리플리케이션되고 있는 브로커에서도 메시지를 수신받게 됩니다.

• 이를 통해 메인 브로커가 다운되더라도 리플리케이션되고 있는 브로커가 메인 허브로서의 역할을 수행한다는것을 알 수 있습니다.

리더와 팔로워

• 카프카는 내부적으로 동일한 리플리케이션들에 대해서 리더와 팔로워로 구분하여 각자의 역할을 분담시킵니다.

• 리더는 리플리케이션중 하나가 선정되며, 모든 읽기와 쓰기는 리더를 통해서만 수행되어집니다.
  • 여기서 개념적으로 혼동하면 안되는게 토픽을 리플리케이션하는것이 아닌 파티션을 리플리케이션한다는것을 기억해야합니다.

• 즉, 프로듀서는 모든 리플리케이션에 메시지를 보내는것이 아니라 리더에게만 메시지를 전송하게 됩니다.

• 컨슈머도 오직 리더에게만 메시지를 가져옵니다.

• 리더 파티션의 팔로워들 또한 리더 파티션에게서 데이터를 가져오게 됩니다. 즉, 팔로워는 파티션의 리더가 새로운 메시지를 받았는지 확인하고 새로운 메시지가 있다면 해당 메시지를 리더 파티션으로부터 복제합니다.

• 이를통해 언제나 리더 파티션을 담당하는 브로커가 다운되더라도 리플리케이션 하고 있는 브로커의 팔로워 파티션들이 대체할 수 있도록 준비를 하게 됩니다

• 확실한 이해를 통해 브로커에 장애가 발생할 경우 리플리케이션을 하는 경우와 안한 경우의 차이를 비교해보도록 하겠습니다.
  1. 브로커가 test-broker-A, test-broker-B, test-broker-C 3개라고 가정할 경우 test-topic1을 생성할때 리플리케이션의 개수를 2로 설정한다면 test-broker-A에 리더 파티션이 설정될 것이고 팔로워 파티션은 test-broker-B에 존재할것입니다. 결과적으로 test-broker-A와 test-broker-B에서 레플리케이션이 진행되게 됩니다.
  2. 다음으로 test-topic2를 생성하고 test-broker-C에 파티션을 할당하며 레플리케이션은 진행하지 않는다고 가정하겠습니다.
  3. 위와 같은 상황에서 test-broker-C가 다운되었을 경우에는 카프카가 메인허브로서의 역할을 정상적으로 수행하지 못하게 됩니다. 반면에 test-broker-A가 다운되었을 경우에는 test-boker-B가 메인 허브로서의 역할을 정상적으로 수행하게 됩니다.

복제 유지와 커밋

• 이전 목차에서 리더와 팔로워에 대해서 설명하였습니다. 이번 목차에서는 리더와 팔로워의 동작에 대해서 자세히 살펴보도록 하겠습니다.

• 리더와 팔로워는 ISR(InSyncReplica)라는 논리적인 그룹으로 묶여 있습니다. 리더와 팔로워를 별도의 그룹으로 나누는 이유는 기본적으로 해당 브로커의 그룹 안에 속한 팔로워들만이 새로운 리더의 자격을 가질수 있기 때문입니다.

• 항상 팔로워들이 리더들의 메시지를 업데이트할 수는 없습니다. 네트워크 오류, 브로커의 장애 등 여러 이유가 존재하기 때문입니다. 이렇게 팔로워의 내용을 정상적으로 업데이트하지 못한 팔로워는 ISR 그룹에서 제외되게 됩니다.

• 따라서 파티션의 리더는 팔로워들이 메시지를 손실하지 않고 리플리케이션 동작을 수행하고 있는지 감시합니다.

• ISR 내에서 모든 팔로워가 메시지 복제를 완료하게되면, 리더는 내부적으로 커밋되었다는 표시를 하게 됩니다. 이때 마지막 커밋 오프셋 위치를 하이워터마크(high water mark)라고 부르게 됩니다. 즉 커밋되었다는 것은 리플리케이션 팩터 수의 모든 리플리케이션이 전부 메시지를 저장했다는것을 의미합니다.

• 컨슈머는 메시지를 읽어갈때 커밋된 메시지만 읽을 수 있으며 브로커들간의 레플리케이션 과정에서 동기화된 메시지만을 컨슈머가 받도록 일관성을 유지합니다.

💡

커밋된 메시지의 오프셋 위치는 로컬 디스크의 replication-offset-checkpoint라는 파일에 저장합니다!

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

• 현재까지 내용을 정리하면 리더는 프로듀에서게 메시지를 받는 역할을 수행하며 팔로워들간의 데이터를 동기화 역할, 동기화 감시 등 많은 작업을 수행한다는것을 알 수 있었습니다.

• 이렇게 바쁜 리더가 리플리케이션 동작을 위해 팔로워들과 많은 통신을 주고받거나 리플리케이션 동작에 많은 관여를 한다면 결과적으로 리더의 성능은 떨어지고 카프카의 장점인 빠른 성능을 내기도 어려울 것입니다.

• 카프카는 리더와 팔로워 간의 리플리케이션 동작을 처리할 때 서로의 통신을 최소할 수 있도록 설계하여 리더의 부담을 줄였습니다.

• 위 그림은 1개의 토픽(peter-test01-0)을 생성하고 리플리케이션 factor를 3으로 설정한 경우입니다.

• 현지 리더만이 0번 오프셋에 “Message1”이라는 메시지를 갖고 있는 상태입니다.

• 프로듀서가 peter-test01 토픽으로 “Message1”이라는 메시지를 전송했으며 리더만 메시지를 저장하고 나머지 팔로워들은 아직 리더에게 저장된 메시지를 리플리케이션하기전 상태입니다.

• 위 그림은 팔로워들이 리더에게 0번 오프셋 메시지를 가져오기위한 fetch 요청을 날린후 “Message1”이 있다는 사실을 인지하고 “Message1” 메시지를 리플리케이션하는 과정입니다. 현재 상태에서 리더는 모든 팔로워가 0번 오프셋 메시지를 리플리케이션하기 위한 요청을 보냈다는 사실을 알고 있습니다. 하지만 요청이 성공했는지에 대한 여부는 리더는 모릅니다.

• 이 부분에 대해서 RabbitMQ와 차이점이 존재합니다. RabbitMQ의 트랜잭션 모드에서는 모든 미러(Mirror, 카프카에서 팔로워에 해당)가 메시지를 받았는지에 대한 ACK를 리더에게 리턴하므로 리더는 미러들이 메시지를 받았는지에 대한 여부를 알 수 있습니다. 하지만 카프카는 리더와 팔로워 사이에서 ACK를 주고 받는 통신이 존재하지 않습니다. 카프카는 이러한 ACK 통신을 제거하여 리플리케이션 동작의 성능을 향상시켰습니다.

• 카프카에서 ACK 없이도 팔로워의 메시지 수신 여부를 알 수 있는 방법은 하이워터마크입니다. 아래는 하이워터마크를 활용한 ACK없이 리더가 팔로워의 레플리케이션 성공여부를 확인하는 방법의 예시입니다.

• 위 그림을 보면 “Message2”가 새롭게 리더에게 요청된것을 알 수 있습니다.

• 메시지를 받기전 리더의 오프셋은 0이었으나 새로운 메시지를 받게 되어 오프셋이 1로 변합니다.

• 이때 팔로워는 리더의 1번 오프셋 위치의 새롭게 들어온 메시지 정보를 리플리케이션 할 수 있도록 자신의 현제 오프셋과 함께 요청합니다. 이때 리더는 자신의 하이워터마크와 팔로워의 요청 오프셋 값이 다르다면 리더는 팔로워의 동기화에 문제가 있다고 판단하게 됩니다.

• 문제가 없다면 리더는 1번 오프셋 메시지를 팔로워에게 응답하고 현재 0번 오프셋 메시지가 커밋되었다는 내용도 함께 전달합니다.

• 이를 통해 ACK 없이도 리더는 팔로워들의 레플리케이션 메시지에 대한 성공여부를 알수 있게 됩니다.

• 팔로워는 리더의 새로운 메시지를 수신 받은 이후 0번 오프셋 메시지가 커밋되었다는 사실을 인지하게 되고, 리더와 동일하게 커밋을 표시합니다. 이후 1번 오프셋 메시진이 “Message2”를 리플리케이션합니다.

• 지금까지의 과정을 반복하면서 동일한 파티션 내에서 리더와 팔로워 간 메시지의 최신 상태를 유지합니다.

💡

지금까지 핵심은 카프카는 다른 메시지 시스템과 다르게 레플리케이션이 실행될 때 리더워 팔로워간의 동기화 작업에서 메시지를 받았는지 확인하는 ACK 통신이 없다는것입니다. 이러한 점이 타 메시지 시스템보다 빠를수 있는 이유입니다.

💡

카프카에서 리플리케이션 동작시 리더와 팔로워 관계는 팔로워가 리더를 Pull하는 방식으로 동작합니다. Pull 방식을 채택한 이유도 ACK 없이 통신할 수 있도록하여 리더의 부담을 줄이기 위해서입니다.

리더에포크와 복구

• 리더에포크는 카프카의 파티션들이 복구 동작을 할 때 메시지의 일관성을 유지하기 위한 용도로 이용됩니다.

• 리더에포크는 기존 리더가 다운되고 팔로워가 새로운 리더로 변경되었을 때 새로운 리더가 팔로워였을때의 하이워터마크를 반환하여 복구하는 방식을 의미합니다. 즉, 리더에포크는 복구 동작 시 하이워터마크를 대체하는 수단으로 활용됩니다.

• 리더에포크를 사용 안하게 되면 크게 2가지 문제점이 존재하는데 첫 번째로 리더의 새로운 메시지를 팔로워가 레플리케이션 하기 직전에 다운되었을때 문제가 발생하게되고 두 번째로 리더를 복구하는 시점에 문제가 발생하게 됩니다.

• 이러한 리더에포크의 존재가 왜 필요한지를 알기 위해 리더에포크 없이 브로커를 다운시키고 카프카의 파티션을 복구하는 과정에서 발생하는 문제들을 알아보겠습니다.

• 위 그림은 파티션 수는1, 리플리케이션 factor 수는2로 가정한 상태에서 아래의 과정이 수행된 상태입니다.
  • 리더는 프로듀서로부터 “Message1” 메시지를 받았고, 오프셋0의 위치에 저장을 한 상태입니다 이때 팔로워는 리더의 오프셋0의 위치에 있는 메시지를 pull 합니다.
  • 이후 리더는 하이워터마크를 1로 증가시킵니다.
  • 리더는 프로듀로부터 다음 메시지인 “Message2”를 받은 뒤 오프셋1에 저장을 하였고 팔로워는 다음 메시지인 “Message2”에 대해 리더에게 pull 요청을 한 상태입니다.
  • 리더로부터온 응답값에 리더의 하이워터마크값이 변화된것을 감지하고 자신의 하워터마크도 1로 올립니다.
  • 팔로워는 오프셋1의 “Message2” 메시지를 리더로부터 리플리케이션합니다.
  • 팔로워는 오프셋2 에 대해 요청을 리더에게 보내고 요청을 받은 리더는 하이워터마크를 2로 올립니다.
  • 팔로워는 2번 오프셋인 “Message2” 메시지까지 리플리케이션을 완료했지만, 아직 리더로부터 하이워터마크를 2로 올리라고 전달받지 못한 상태입니다.
  • 이때 예상 하지 못한 장애로 팔로워가 다운됩니다.

  

• 먼저 리더가 다운되어 팔로워가 뉴리더로 승급되는 시점의 문제를 확인해보겠습니다.

• 위는 장애가 발생한 팔로워가 종료된후 장애 처리가 완료된 상태의 그림을 의미합니다.

• 장애에서 복귀된 팔로워는 카프카 프로세스가 시작되면서 내부적으로 아래와 같이 복구 동작을 수행하게 됩니다.
  • 팔로워는 자신이 갖고 있는 메시지들 중에서 자신의 하이워터마크 수치 보다 큰 오프셋 값에 위치한 메시지들을 신뢰할 수 없느 메시지로 판단하고 삭제합니다. 이로 인해 팔로워의 “Message2”는 삭제되게 됩니다.
  • 팔로워는 리더에게 오프셋1의 새로운 메시지에 대한 pull 요청을 보냅니다.
  • 이때 리더였던 브로커가 장애로 인해 다운되고 팔로워가 새로운 리더로 승격됩니다.

팔로워가 새로운 리더로 승격한 후의 상태(리더가 다운되었을때 발생하는 문제)

• 위 그림은 팔로워가 새로운 리터(뉴리더)로 승격된 후의 상태입니다.

• 여기서 문제가 발생하게 됩니다. 기존의 리더는 오프셋1의 “Message2”를 갖고 있었지만 뉴리더에는 “Message2”가 존재하지 않습니다.

• 리더와 팔로워간의 레플리케이션을 진행했음해도 불구하고 메시지가 손실되는 현상이 발생하게 되는 문제가 발생한것입니다.

• 이번에는 리더에포크를 사용해서 복구를 진행하도록 해보겠습니다.

• 앞에 하이워터마크를 사용하는 복구작업 방식은 뉴리더에서 하이워터마크보다 높은 메시지를 삭제하였습니다. 하지만 리더에포크를 사용하는 경우에는 하이워터마크보다 앞에 있는 메시지를 무조건 삭제하는것이 아니라 리더에게 리더에포크 요청을 보냅니다.
  • 팔로워는 복구 동작을 하면서 리더에게 리더에포크 요청을 보냅니다.
  • 요청을 받은 리더는 리더에포크 응답으로 오프셋1의 “Message2”까지 받았다고 팔로워에게 응답합니다.

  

  • 팔로워는 자신의 하이워터마크보다 높은 오프셋1의 “Message2”를 삭제하지 않고 리더의 응답 하이워터마크 값 2까지 상향 조정합니다.
  • 이후 리더를 다운시켜도 뉴리더에는 메시지 손실이 없는것을 확인할 수 있습니다.

• 다음으로는 복구하는 시점에 발생하는 문제를 확인해보겠습니다.

• 복구 시점 문제 예시의 초기 상태는 위 그림처럼 리더만 오프셋1까지 저장하고 팔로워는 아직 오프셋1의 리플리케이션을 완성하지 못한 상태입니다.

리더 다운 후 팔로워의 리더 승격 및 하이워터마크 값 상승

• 이때 리더가 다운되고 팔로워가 뉴리더로 승격된 후 프로듀서가 위와 같이 “Message3”을 뉴리더에게 전달하고 하이워터마크 값을 2까지 상승시켰습니다.

  

• 구리더(팔로워) 브로커의 장애를 복구합니다.

• 뉴리더가 생겼으므로 기존의 리더는 팔로워가 됩니다.

• 이때 뉴리더와 메시지 정합성 확인을 위해 구리더(팔로워)는 자신의 하이워터마크를 비교해보니 리더의 하이워터마크와 일치하므로 브로커는 자신이 갖고 있던 메시지(”Message2”)를 삭제하지 않습니다. 이때 메시지의 정합성이 깨지는 문제가 발생하게됩니다.

• 리더에 포크를 사용해서 문제를 해결하게 되면 아래와 같이 해결하게 됩니다.
  1. 먼저 구리더(팔로워)가 뉴리더에게 리더에포크를 요청합니다. 이때 뉴리더의 팔로워였을때을 하이워터마크를 요청하게 됩니다.
  2. 뉴리더는 0번 오프셋까지 일치하다고 응답합니다.
  3. 팔로워는 메시지 일관성을 위해 로컬 파일에서 1번 오프셋인 “Message2”를 삭제합니다.
  4. 이후 팔로워의 역할을 수행하기위해 뉴리더의 1번 오프셋인 “Message3”을 리플리케이션 합니다.

• 이를 통해 복구 시점에도 리더에포크를 사용하게되면 메시지의 정합성을 유지할 수 있다는것을 알게되었습다.

컨트롤러

• 컨트롤러는 파티션중 어떤 파티션을 리더로 선출할지 결정하는 역할을 의미합니다.

• 컨트롤러의 역할을 수행하는 대상은 카프카 클러스터의 브로커 중 하나로 결정합니다.

• 컨트롤러 역할을 수행하는 브로커는 리더를 지속적으로 감시하며 임무를 수행하는지 확인합니다. 만약 장애 또는 브로커의 실패로 인해 리더가 리더로서의 역할을 수행하고 있지 않다면 ISR 리스트 중 하나를 새로운 파티션 리더로 선출합니다.(질문: 컨트롤러 역할하는 브로커가 다운되면?)

• 이후 새로운 리더의 정보를 주키퍼에 기록하고 변경된 정보를 모든 브로커에게 전달합니다.

컨트롤러의 중요성

• 파티션의 리더가 다운되게 되면 카프카의 클라이언트인 프로듀서와 컨슈머는 파티션으로 읽기 쓰기 작업이 불가능합니다.

• 이런 상태에서 카프카 클라이언트는 모든 읽기/쓰기 작업을 하지 못하게 되고 클라이언트에 설정되어 있는 숫자만큼 재시도하게 됩니다.

• 이때 클라이언트가 재시도하는 시간 내에 컨트롤러의 리더 선출 작업이 빠르게 이뤄져야만 카프카 클라이언트가 전송하는 메시지 손실이 발생하지 않습니다.

• 아래에서 부터는 리더 선출 과정이 어떻게 진행되는지 살펴보겠습니다.

컨트롤러의 리더 선출 과정

토픽 이름	peter-test02
파티션수	1(0번 파티션)
리플리케이션 팩터 수	2
브로커 배치	1, 3번 브로커
현재 리더 위치	1번 브로커

• 위의 표는 리더 선출 과정을 설명하기 위한 토픽의 정보입니다.

• 먼저 장애 상황을 연출하기 위해 0번 파티션의 리더가 있는 1번 브로커를 강제로 종료하고 새로운 파티션의 리더가 선출되도록 진행해보겠습니다.
  1. 파티션 0번의 리더가 있는 1번 브로커가 다운됩니다.
  2. 주키퍼는 1번 브로커와 연결이 끊어진 후, 0번 파티션의 ISR에 변화가 생긴것을 감지합니다.
  3. 컨트롤러는 주기퍼 워치를 통해 0번 파티션에 변화가 생긴것을 감지하고 해당 파티션 ISR 중 3번을 새로운 리더로 선출합니다.
  4. 컨트롤러는 0번 파티션의 새로운 리더가 3이라는 정보를 주키퍼에 기록합니다.
  5. 새롭게 갱신된 정보는 현재 활성화 중인 모든 브로커에게 전파 됩니다.

💡

카프카 1.0.0 버전에서는 카프카의 리더 선출 작업에서는 많은 소모 시간이 발생하여 문제가 있었습니다. 이런 문제를 해결하기 위해 카프카 2.8.0에서는 주키퍼의 일부 API 통신 방식을 동기에서 비동기로 변경하고 불필요한 로깅 작업을 없애서 시간을 단축시켰습니다.

• 이전에는 장애로 인한 갑작스런 서버 다운이 되었을 경우의 컨트롤러의 리더 선출과정이었다면 이번에는 Graceful(자연스럽게,우아한)하게 서버 다운하는 경우의 리더 선출 과정에 대해 설명하도록 해보겠습니다.

  

1. 관리자가 브로커 종료 명령어를 실행하기 위해 SIG_TERM(정상종료) 신호를 브로커에게 전달합니다.

2. SIG_TERM 신호를 받은 브로커는 컨트롤러에게 자신이 SIG_TERM 신호를 받았다고 알립니다.

3. 컨트롤러는 리더 선출 작업을 진행하고, 해당 정보를 주키퍼에 기록합니다.

4. 컨트롤러는 새로운 리더 정보를 다른 브로커들에게 전송합니다.

5. 컨트롤러는 종료 요청을 보낸 브로커에게 정상 종료한다는 응답을 보냅니다.

6. 응답을 받은 브로커는 캐시에 있는 내용을 디스크에 저장하고 종료합니다.

• Graceful한 서버 다운과 장애로 인한 다운되는 2가지 모두 컨트롤러는 리더를 새로 선출하지만 다운타임 측면에서 차이점이 존재합니다.

• Graceful한 서버 다운의 경우에는 다운시키려는 브로커의 리더로 할당된 전체 파티션에 리더 선출 작업을 진행하여 내부적으로 파티션들의 다운타임을 최소화할 수 있습니다.

• Graceful한 서버 다운의 경우에도 다운타임은 존재하지만 리더 선출 작업시에도 리더 파티션이 활성화된 상태에서 컨트롤러는 ISR 그룹의 리더 파티션을 제외한 하나의 파티션마다 리더를 선출하게 되므로 결과적으로 각 파티션들의 타운타임을 최소화 할 수 있습니다.

• 반대로 장애로 인한 리더 산출 작업의 경우에는 이미 파티션의 리더가 종료된 상태이고 파티션들의 다운타임은 새로운 리더가 선출될 때까지 지속되어 상대적으로 Graceful한 다운의 다운타임보다 오래 다운타임이 발생하게 됩니다.

• 이로 인해 ISR 그룹의 첫 번째 파티션은 다운타임이 길지 않겠지만 마지막 파티션의 다운타임은 오랜 시간이 걸리게 됩니다.

• 그뿐 아니라, Graceful한 다운인 경우에 브로커는 자신의 모든 로그를 디스크에 동기화 한 후 종료하여 브로커가 재시작할 때 로그 복구 시간 측면에서도 짧습니다.

• 제어된 종료를 사용하기 위해서는 server.properties에 아래와 같은 설정을 추가해야합니다.

controlled.shutdown.enable = true

로그(세그먼트)

• 카프카에서 발생하는 로그의 정보, key, value, offset, 크기 등이 Segment라는 파일에 저장되게 됩니다.

• 이때 로그가 지속적으로 저장 되기때문에 무한히 파일의 크기가 증가되는것을 대비해 기본값(1GB)으로 설정한 크기보다 커지면 파일을 close하고 새로운 Segment 파일을 생성하는 방식으로 저장합니다. 이러한 파일 저장 방식을 롤링(Rolling)이라고 호칭합니다.

• 그러나 위와 같은 방식은 Segment 파일이 무한히 발생할 수 있다는 문제점이 존재합니다. 이러한 문제점을 해결하기 위해 카프카에서는 로그 세그먼트 삭제, 로그 세그먼트 컴팩션이라는 2가지 방법을 제공합니다.

로그 세그먼트 삭제

• 로그 세그먼트 삭제는 카프카의 기본값으로 적용되는 옵션입니다.

• 기본 설정값은 7일이며 설정한 날짜를 기준으로 세그먼트 파일을 삭제하는 방식으로 운영되는 방식입니다.

로그 세그먼트 컴팩션

• 로그 세그먼트 컴팩션은 로그 세그먼트 삭제와 다르게 로그를 삭제하지 않고 컴팩션(Compaction)하여 보관할 수 있는 방식입니다.

• 로그 컴팩션은 기본적으로 로컬 디스크에 저장되어 있는 세그먼트를 대상으로 실행되는데, 이때 현재 활성화된 세그먼트는 제외한 세그먼트들을 대상으로 컴팩션이 실행됩니다.

• 또한 효율적인 로그 컴팩션을 위해 Key와 Value 형태로 저장되게 되며 로그 컴팩션 발생 설정 기준이 충족될 경우 같은 Key값을 기준으로 마지막 Value값이 저장되는 형태로 진행됩니다. 아래는 로그 컴팩션 발생 예시입니다.

• 먼저 프로듀서가 Key와 Value를 전송합니다.

• 오프셋 0번 위치에 로그를 적재합니다.

• 이후 순서대로 메시지를 쌓다가 오프셋이 10번 위치까지 쌓였을때 로그컴팩션이 발생되게 됩니다.

• K1의 마지막 값은 오프셋 3에 위치한게 마지막 값이므로 K1은 Value가 4인 경우만 저장합니다.

• K3의 마지막 값은 오프셋 7에 위치한게 마지막 값이므로 k3은 Value가 5인 경우만 저장합니다.

• 이런 방식으로 각 키의 마지막 값만 저장합니다.

• 이러한 로그 컴팩션의 장점은 빠른 장애 복구에 있습니다. 장애 복구시 전체 로그를 복구하지 않고, 메시지의 키를 기준으로 최신의 상태만 복구하기 때문입니다.

• 하지만 이와 같은 로그 컴팩션은 적용하고자 하는 도메인과 적합한지 검토후 적용해야합니다. 예를 들어 배송 서비스는 로그 컴팩션에 적용하기에 적합합니다. 고객에게 배송 준비 → 배송 중 → 배송완료라는 Value를 저장해야 한다면 마지막 배송완료라는 Value만 저장하면 되기 때문입니다. 그러나 환자의 질병을 기록하는 도메인이라면 로그컴팩션을 적용하기에 적합하지 않습니다. 이처럼 적용하고자 하는 도메인에 적합한지 검토하여 적용해야합니다.

💡

카프카에서 로그 컴팩션 기능을 사용하는 대표적인 예제는 _consumer_offset 토픽입니다. consumer_offset 토픽은 카프카의 내부 토픽으로, 컨슈머 그룹의 정보를 저장하는 토픽입니다. 컨슈머 그룹의 중요한 정보는 해당 컨슈머 그룹이 어디까지 읽었는지를 나타내는 오프셋 커밋 정보인데, consumer_offset에 Key(컨슈머 그룹명, 토픽명)와 Value(오프셋 커밋 정보) 형태로 메시지를 저장하고 있습니다.

• 마지막으로 로그 컴팩션을 발생시키기 위한 기준을 설정하기 옵션들입니다.

옵션 이름	옵션값	적용 범위	설명
cleanup.policy	compact	토픽의 옵션으로 적용	토픽 레벨에서 로그 컴팩션을 설정 할 때 적용하는 옵션입니다.
log.cleanup.policy	compact	브로커의 설정 파일에 적용	브로커 레벨에서 로그 컴팩션을 설정할 때 적용하는 옵션입니다.
log.cleaner.min.compaction.lag.ms	0	브로커의 설정 파일에 적용	메시지가 기록된 후 컴팩션하기 전 경과되어야 할 취소 시간을 지정합니다. 만약 이 옵션을 설정하지 않으면, 마지막 세그먼트를 제외하고 모든 세그먼트를 컴팩션할 수 있습니다.
log.cleaner.max.compaction.lag.ms	9223372036854775807	브로커의 설정 파일에 적용	메시지가 기록된 후 컴팩션하기 전 경과되어야 할 최대 시간을 지정합니다.
log.cleaner.min.cleanable.ratio	0.5	브로커의 설정 파일에 적용	로그에서 압축이 되지 않은 부분을 더티(dirty)라고 표현합니다. ‘전체 로그’ 대비 ‘더티’의 비율이 50%가 넘으면 로그 컴팩션이 실행됩니다.