백엔드 면접 질문 - 카프카

카프카와 관련해서 받은 면접 질문을 정리한 포스팅입니다.

제가 경험한 면접 질문에 대한 대답을 정리하다보니 저만의 대답 방식으로 인해 간결할 수 있는 점 양해바랍니다.

Kafka의 장점(특징)

(출처)

프로듀서와 컨슈머의 분리하고, 하나의 토픽에 여러 프로듀서와 여러 컨슈머들이 접근 가능합니다.

또한 메시지를 디스크에 영속적으로 저장하여 유실을 방지할 수 있고, 높은 처리량을 자랑하는 걸로 알고 있습니다.

---

프로듀서와 컨슈머의 분리

각자 역할이 완벽하게 분리되면서, 어느 한쪽 시스템에서 문제가 발생하더라도 연쇄작용이 발생할 확률이 낮아집니다.

멀티 프로듀서와 멀티 컨슈머

하나의 토픽에 여러 프로듀서 또는 여러 컨슈머들이 접근 가능한 구조입니다.

메시지를 디스크에 영속적으로 저장

이는 메시지 유실을 방지하고, 메시지를 안전하게 보호할 수 있도록 합니다.

카프카는 초당 수백만 개의 메시지를 처리할 수 있는 정도의 높은 처리량을 자랑합니다.

Kafka를 사용한 이유

창고 관리 서비스인 WMS 서비스를 새로 런칭하면서 Kafka를 메시지 큐로 사용하기 위해 도입했습니다.

기존 서비스에서 결제완료된 주문을 WMS 서비스에서는 출고 도메인으로 다루게 됩니다.

이 때, 기존 서비스에 kafka producer를 두어 출고를 생성하는 topic으로 메시지를 보내게 되고, wms에서는 그 topic에서 메시지를 가져와 컨슘하여 출고를 생성하게 됩니다.

이 뿐만 아니라, 기존 서비스에서 주문을 취소하는 경우나, 출고가 완료되어 주문에 배송 상태를 변경해주는 행위 또한 kafka를 사용했습니다.

kafka를 통해 두 시스템간의 결합도를 낮추고, 일관성을 유지할 수 있었습니다.

토픽을 파티셔닝하는 이유

빠른 전송을 위해서 프로듀서의 수 뿐만 아니라 토픽의 파티션을 늘려줘야 합니다.

왜냐하면 메시징 큐 시스템의 제약 조건인 메시지의 순서가 보장되어야 하기 때문입니다.

하지만 무작정 파티션의 수를 늘리는 건 위험합니다.

첫 번째로, 파티션의 수가 많을 수록 파일 핸들 수 역시 많아지기 때문에 리소스를 낭비할 수 있습니다.

두 번째로, 브로커가 갑자기 종료되었을 때, 파티션별로 새로운 리더를 선출해야 하는데, 이에 대한 시간이 파티션의 수만큼 증가하게 됩니다.

그렇기 때문에 파티션의 수를 무작정 늘리는 건 좋지만은 않습니다.

모든 브로커가 다운된다면?

카프카에서는 이러한 상황에서 두 가지 선택을 합니다.

첫 번째는 마지막 리더가 살아나기를 기다리는 방법

두 번째는 ISR에서 추방되었지만 먼저 살아나면 자동으로 리더로 만드는 방법

두 가지 장단점이 있는데, 마지막 리더가 살아나기를 기다리는 방법은 마지막 리더가 정상화될 때까지 전체 카프카 클러스터의 장애가 길어지는 단점이 있지만, 메시지 유실을 막을 수 있는 장점이 있습니다.

ISR에서 추방된 브로커를 리더로 만드는 방법은 서비스 장애가 짧은 장점이 있는 반면에, 추방된 사이 받아왔던 메시지가 유실될 수 있는 단점이 있습니다.

이 점을 숙지하고 환경에 맞게 설정을 변경해 운영하면 될 것 같습니다.

프로듀서가 메시지를 보냈을 때 리더와 팔로워에게 저장되는 과정

acks가 1일 때는 다음과 같이 동작합니다.

프로듀서가 토픽 A의 리더에게 메시지를 보냅니다.

토픽 A의 리더는 메시지를 받은 후 저장합니다.

그 다음 토픽 A의 리더는 프로듀서에게 메시지를 받았다고 acks를 보냅니다.

팔로워들은 리더를 주기적으로 바라보면서 리더에 새로운 메시지가 있는 것을 확인하고 저장합니다.

acks=1일 때 메시지가 유실되는 상황

메시지 손실의 문제가 발생하는 경우는 리더에 장애가 발생하는 순간입니다.

다만 리더에 장애가 발생한다고 100% 확률로 메시지가 손실되는 것은 아닙니다.

정확하게는 리더가 프로듀서에게 메시지를 받은 후 acks를 보낸 후 바로 장애가 났을 때입니다.

팔로워들은 리더를 주기적으로 바라봐야 하는데 리더가 없어진 상태입니다.

그렇게 되면 리더에 새로운 메시지가 있는지를 모르기 때문에 메시지를 가져올 수 없습니다.

이러한 메시지 유실을 막으려면 acks의 값을 -1이나 all로 설정해야 합니다.

min.insync.replicas의 값을 3이 아닌 2를 추천하는 이유

이 값이 3이면 리더와 팔로워 포함한 3곳에서 메시지를 받아야만 리더는 프로듀서에게 메시지를 잘 받았다는 acks 값을 보내게 됩니다.

카프카는 브로커가 하나가 다운되더라도 크리티컬한 장애 상황없이 서비스를 잘 처리할 수 있도록 구성되어 있는데, min.insync.replicas 값이 3이면 이 옵션을 충족시킬 수 없어서 에러가 발생하게 됩니다.

이러한 이유 때문에 2를 추천하고, 토픽의 리플리케이션 팩터는 3으로 설정하기를 권고하는 것입니다.

Kafka를 사용하면서 트러블 슈팅 경험

카프카 컨슈머에서 토픽을 중복해서 컨슘했던 경험을 소개했고, 컨슈머하는 로직에 중복 검사했는지에 대한 로직을 추가해줬습니다.

select으로 중복을 막으면 테이블 Lock이 걸리지 않냐는 질문

이 질문은 제대로 대답을 못했고, ON DUPLICATE KEY UPDATE를 추천해주셨습니다.

스프링 이벤트나 카프카 같이 이벤트 기반으로 처리 시 롤백하고 싶으면 어떻게 하는지?

1. 트랜잭션 관리 스프링 프레임워크에서는 이벤트를 발행하는 도중에 발생하는 예외를 처리하기 위해 트랜잭션 관리를 제공합니다. 트랜잭션을 사용하여 이벤트를 발행하고, 예외가 발생하면 트랜잭션 롤백을 수행할 수 있습니다.
2. 카프카의 보상 트랜잭션 카프카에서는 메시지를 보내는 동안 발생하는 예외를 처리하기 위해 보상 트랜잭션을 제공합니다. 이를 사용하면 메시지를 보내는 동안 예외가 발생하면 이전에 전송한 모든 메시지를 롤백할 수 있습니다.
3. 이벤트 로그 저장 이벤트 로그를 저장하는 방법을 사용하면, 이벤트를 처리하는 동안 예외가 발생하더라도 해당 이벤트를 재처리할 수 있습니다. 이를 통해 롤백을 수행할 수 있습니다.
4. 역순 이벤트 처리 이벤트를 처리하는 도중 예외가 발생하면, 해당 이벤트 이전에 발생한 모든 이벤트를 역순으로 처리하여 롤백할 수 있습니다. 이를 통해 이전 이벤트로부터 시스템 상태를 복구할 수 있습니다.

컨슈머의 동작 방식

Spring Kafka에서 컨슈머는 Kafka의 메시지를 가져와서 처리하는 역할을 합니다.

Spring Kafka의 컨슈머 동작 방식은 다음과 같습니다.

1. Kafka Topic 구독 컨슈머는 Kafka Topic을 구독하여 해당 Topic에서 메시지를 가져올 수 있습니다.
2. Polling 방식 메시지 가져오기 컨슈머는 일정한 주기로 Kafka Broker로부터 Polling하여 Topic에 있는 메시지를 가져옵니다.
3. 메시지 처리 컨슈머는 가져온 메시지를 처리합니다. 이때 메시지 처리 방식은 개발자가 정의합니다.
4. 커밋 메시지를 모두 처리한 후, 컨슈머는 Kafka Broker에 커밋을 요청합니다. 이때 커밋 방식은 개발자가 설정할 수 있습니다.
5. Offset 관리 컨슈머는 처리한 메시지의 Offset 정보를 관리합니다. 이 정보를 바탕으로, 컨슈머는 다음번 Polling시부터 이어서 처리할 메시지의 Offset을 계산하여 가져올 수 있습니다.
6. 에러 처리 컨슈머는 메시지 처리 중 에러가 발생하면, 해당 메시지를 재처리하거나, 다시 가져오도록 설정할 수 있습니다.
7. 스레드 풀 Spring Kafka는 메시지 처리를 병렬적으로 처리하기 위해 스레드 풀을 사용합니다. 스레드 풀의 크기는 개발자가 설정할 수 있습니다.

컨슈머 동작 방식은 Spring Kafka의 설정에 따라 달라질 수 있습니다. 하지만 대체로 위와 같은 방식으로 동작합니다.

카프카에서 예기치 못한 에러로 컨슈머에선 처리되고 카프카 서버로부터 호출이 안왔다면? 

만약 Kafka에서 컨슈머에게 메시지가 전송되었지만, 예기치 못한 에러로 인해 컨슈머에서 해당 메시지를 처리하지 못한 경우, Kafka는 해당 메시지를 처리하지 못한 상태로 유지합니다.

이 경우 Kafka는 해당 메시지를 다시 전송합니다.

반대로, Kafka에서 컨슈머에게 메시지가 전송되지 않은 경우, 일반적으로 다음과 같은 경우가 있습니다.

1. Kafka Broker 장애 Kafka Broker에 장애가 발생하여 컨슈머에게 메시지를 전송할 수 없는 경우가 있습니다.
2. 네트워크 장애 Kafka Broker와 컨슈머 간의 네트워크 장애로 메시지가 전송되지 않는 경우가 있습니다.
3. 컨슈머 구성 문제 컨슈머 구성에 문제가 있어 메시지를 받을 수 없는 경우가 있습니다.

위와 같은 경우, 일반적으로 Kafka에서는 메시지를 다시 전송하도록 구성할 수 있습니다.

이를 위해 컨슈머가 Kafka Broker에게 자신이 처리할 수 있는 메시지의 Offset 정보를 주기적으로 보고하면서, Broker는 이 정보를 바탕으로 다시 메시지를 전송합니다.

또한, Kafka에는 메시지 보존 기간을 설정할 수 있어, 일정 시간이 지난 메시지는 삭제되지만, 이를 수정하여 메시지를 보존할 수 있습니다.