메시지 큐 (Kafka) 면접 질문

메시지 큐는 애플리케이션 간에 메시지를 주고받을 때 사용하는 비동기 통신 방식입니다. 쉽게 말해, 메시지를 보내는 쪽과 받는 쪽이 직접 통신하지 않고, 중간에 메시지 큐라는 '우체통'을 두어 메시지를 잠시 보관했다가 전달하는 방식입니다.

이러한 구조는 시스템 아키텍처에 여러 이점을 제공합니다. 가장 큰 장점은 애플리케이션 간의 결합도를 낮춰준다는 것입니다. 메시지를 보내는 쪽은 받는 쪽이 언제 메시지를 처리하는지 신경 쓰지 않고 메시지만 큐에 넣어두면 됩니다. 받는 쪽도 마찬가지로 큐에서 메시지를 꺼내 처리하기만 하면 됩니다.

또한, 시스템의 확장성을 향상시킵니다. 메시지 처리량이 많아지면 메시지 큐에 연결된 처리기(consumer)를 늘려 부하를 분산시킬 수 있습니다. 마지막으로, 메시지 큐는 메시지를 안전하게 보관하므로 시스템 장애 시에도 메시지 유실을 방지하여 신뢰성을 높여줍니다.

카프카는 대량의 데이터를 실시간으로 처리하고 전달하는 데 특화된 분산 스트리밍 플랫폼입니다. 주로 다음과 같은 특징을 가지고 있습니다.

• 높은 처리량: 대량의 메시지를 빠르게 처리할 수 있습니다.
• 확장성: 클러스터를 확장하여 더 많은 데이터를 처리할 수 있습니다.
• 내결함성: 일부 서버에 장애가 발생해도 시스템 전체는 안정적으로 운영됩니다. 데이터 복제를 통해 안정성을 확보합니다.
• 영속성: 메시지를 디스크에 저장하여 데이터 유실을 방지합니다.
• Pub-Sub 모델: 발행-구독 모델을 사용하여 다양한 애플리케이션 간에 데이터를 쉽게 공유할 수 있습니다.

이러한 특징 덕분에 카프카는 로그 수집, 이벤트 스트리밍, 데이터 파이프라인 구축 등 다양한 분야에서 활용되고 있습니다.

카프카에서 토픽은 메시지들을 논리적으로 묶는 역할을 합니다. 쉽게 말해, 메시지들을 종류별로 구분하는 '폴더'와 같은 개념이라고 생각하시면 됩니다. 예를 들어, '사용자 활동' 토픽, '결제 정보' 토픽처럼 특정 주제에 관련된 메시지들을 하나의 토픽으로 묶을 수 있습니다.

토픽은 데이터를 분류하고 관리하는 데 핵심적인 역할을 합니다. 프로듀서는 특정 토픽에 메시지를 발행하고, 컨슈머는 자신이 구독한 토픽에서 메시지를 가져옵니다. 각 토픽은 여러 개의 파티션으로 나뉘어 병렬 처리 성능을 높일 수 있고, 각 파티션 내에서는 메시지들이 순서대로 저장됩니다. 컨슈머는 오프셋을 통해 특정 위치부터 메시지를 읽을 수 있어, 데이터 처리의 유연성을 확보할 수 있습니다.

카프카 토픽의 파티션은 토픽을 여러 개의 작은 조각으로 나눈 것이라고 생각하시면 됩니다. 각 파티션은 순서대로 정렬된 메시지들의 로그 역할을 합니다.

파티션이 필요한 이유는 크게 두 가지입니다. 첫째, 병렬 처리 능력을 향상시켜 전체적인 처리량을 늘릴 수 있습니다. 여러 컨슈머가 각 파티션을 병렬적으로 처리할 수 있기 때문입니다. 둘째, 데이터를 분산 저장하여 확장성을 확보하고, 일부 파티션에 장애가 발생하더라도 다른 파티션은 정상적으로 동작하여 장애 내성을 높일 수 있습니다.

다만, 중요한 점은 특정 파티션 내에서는 메시지 순서가 보장되지만, 여러 파티션에 걸쳐서는 순서가 보장되지 않는다는 것입니다. 따라서 순서가 중요한 메시지는 동일한 파티션에 저장되도록 키를 잘 설정해야 합니다. 각 메시지는 파티션 내에서 고유한 오프셋을 가지며, 이 오프셋을 통해 메시지를 식별하고 순서를 관리합니다.

카프카에서 오프셋은 특정 파티션 내에서 메시지의 순서를 나타내는 고유한 ID입니다. 각 메시지는 파티션에 추가될 때마다 순차적으로 증가하는 오프셋 값을 할당받습니다.

컨슈머 입장에서 오프셋은 매우 중요합니다. 컨슈머는 특정 오프셋까지 메시지를 처리했다는 정보를 카프카에 '커밋'합니다. 이렇게 커밋된 오프셋은 컨슈머 그룹 내에서 해당 컨슈머가 어디까지 읽었는지 기록하는 역할을 합니다. 만약 컨슈머가 재시작되거나 다른 컨슈머가 해당 파티션을 할당받게 되면, 커밋된 오프셋부터 메시지를 다시 읽기 시작하여 메시지 처리의 연속성을 보장하고 중복 처리를 방지할 수 있습니다. 즉, 오프셋은 컨슈머가 메시지를 정확히 한 번만 처리하도록 돕는 핵심적인 요소입니다.

카프카에서 프로듀서와 컨슈머는 핵심적인 역할을 수행합니다.

프로듀서는 데이터를 카프카 클러스터로 보내는 역할을 합니다. 특정 토픽을 지정하여 메시지를 발행하고, 카프카 브로커는 이 메시지를 해당 토픽에 저장합니다. 프로듀서는 어떤 데이터를 어떤 토픽에 보낼지 결정하는 역할을 담당한다고 볼 수 있습니다.

반면 컨슈머는 카프카 클러스터로부터 데이터를 가져오는 역할을 합니다. 특정 토픽을 구독하여 해당 토픽에 저장된 메시지를 읽어 처리합니다. 컨슈머 그룹을 통해 여러 컨슈머가 하나의 토픽을 나누어 처리하여 병렬 처리도 가능합니다. 즉, 컨슈머는 필요한 데이터를 토픽에서 가져와 사용하는 역할을 합니다.

카프카 브로커는 카프카 클러스터를 구성하는 핵심 서버 노드입니다. 쉽게 말해, 메시지를 저장하고 관리하는 역할을 담당합니다.

프로듀서로부터 메시지를 받아서 토픽의 파티션에 저장하고, 컨슈머가 요청하면 해당 메시지를 전달해줍니다.

각 브로커는 여러 개의 파티션을 가질 수 있으며, 파티션은 데이터의 복제를 통해 고가용성을 보장합니다. 파티션에는 리더와 팔로워가 존재하는데, 리더는 읽기/쓰기 요청을 처리하고 팔로워는 리더의 데이터를 복제하여 장애 발생 시 리더 역할을 수행할 수 있도록 합니다.

따라서 브로커는 메시지 큐 시스템의 안정적인 운영과 데이터 유실 방지에 중요한 역할을 합니다.

Kafka에서 토픽을 여러 파티션으로 나누는 주된 이유는 병렬 처리 능력을 극대화하기 위해서입니다. 각 파티션은 독립적으로 처리될 수 있기 때문에, 여러 컨슈머가 동시에 메시지를 처리하여 전체 처리량을 향상시킬 수 있습니다.

또한, 파티셔닝은 데이터를 여러 브로커에 분산시켜 저장함으로써 데이터의 가용성과 내구성을 높입니다. 컨슈머 그룹을 확장할 때, 각 컨슈머가 특정 파티션을 담당하도록 설정하여 로드 밸런싱을 구현하고 시스템의 확장성을 확보할 수 있습니다. 즉, 더 많은 메시지를 더 빠르게 처리할 수 있도록 해줍니다.

Kafka에서 Consumer Group은 여러 컨슈머 인스턴스를 묶어 하나의 논리적인 컨슈머처럼 동작하게 하는 메커니즘입니다.

각 컨슈머 그룹은 토픽의 파티션을 나누어 소비합니다. 예를 들어, 토픽에 3개의 파티션이 있고 컨슈머 그룹에 3개의 컨슈머가 있다면, 각 컨슈머는 하나의 파티션을 전담하여 처리합니다. 이렇게 파티션을 분담하여 처리함으로써 메시지 소비의 병렬성을 높여 확장성을 확보할 수 있습니다.

만약 컨슈머 중 하나가 다운되면, 해당 컨슈머가 담당하던 파티션은 다른 컨슈머에게 자동으로 재할당됩니다. 이를 통해 장애 발생 시에도 메시지 소비가 중단되지 않고 지속적으로 이루어지도록 하여 고가용성을 확보합니다. 각 컨슈머는 자신이 소비한 메시지의 오프셋을 Kafka에 저장하여, 장애 복구 시 중복 소비 없이 이어서 소비할 수 있습니다.

Kafka에서 오프셋은 컨슈머가 특정 파티션에서 어디까지 메시지를 읽었는지 나타내는 숫자입니다. 각 파티션 내에서 메시지의 순서를 나타내는 고유한 ID라고 생각하시면 됩니다.

컨슈머 그룹 내에서는 오프셋 관리가 중요한데, 컨슈머 그룹은 __consumer_offsets라는 내부 토픽에 현재 처리한 오프셋을 주기적으로 커밋합니다. 이렇게 커밋된 오프셋을 통해 컨슈머가 재시작되거나 그룹에 새로운 컨슈머가 참여하더라도, 이전에 처리했던 메시지를 다시 처리하지 않고 마지막으로 커밋된 오프셋부터 이어서 메시지를 처리할 수 있습니다. 즉, 컨슈머 그룹은 이 __consumer_offsets 토픽을 통해 메시지 처리 상태를 관리합니다.

Kafka는 메시지의 내구성을 보장하기 위해 여러 메커니즘을 사용합니다.

가장 중요한 것은 **복제(Replication)**입니다. 각 토픽 파티션은 여러 브로커에 복제되어 저장됩니다. 이렇게 하면 하나의 브로커에 장애가 발생하더라도 다른 복제본에서 데이터를 가져올 수 있습니다.

두 번째는 ACKs 설정입니다. 프로듀서는 메시지를 브로커에 보내고 응답을 기다립니다. ACK 설정을 통해 얼마나 많은 브로커가 메시지를 받았는지 확인하고, 메시지 손실을 방지할 수 있습니다. acks=all 설정을 사용하면 모든 ISR(In-Sync Replicas)이 메시지를 받았을 때만 성공으로 간주됩니다.

세 번째는 최소 ISR 크기(min.insync.replicas) 설정입니다. 이 설정을 통해 데이터 손실 없이 메시지를 처리할 수 있는 최소한의 복제본 수를 지정할 수 있습니다.

마지막으로, Kafka는 메시지를 디스크에 순차적으로 기록하는 **로그 세그먼트(Log Segments)**를 사용하고, 주기적으로 디스크에 Flush하여 데이터 손실을 최소화합니다.

Kafka에서 ISR(In-Sync Replicas)은 리더 파티션과 거의 동일한 데이터를 가지고 있는 팔로워 복제본들의 집합을 의미합니다. 이들은 리더로부터 데이터를 꾸준히 복제하며, 지연 시간이 설정된 임계값 이내로 유지됩니다.

ISR은 데이터 손실 방지와 고가용성 유지에 핵심적인 역할을 합니다. 리더 파티션에 장애가 발생했을 때, ISR 내의 팔로워 중 하나가 새로운 리더로 선출됩니다. 이때, ISR에 속한 팔로워는 리더의 데이터를 거의 완벽하게 복제하고 있기 때문에 데이터 손실 없이 빠르게 리더 역할을 수행할 수 있습니다.

만약 ISR이 없다면, 모든 팔로워 중에서 리더를 선출해야 하고, 이 과정에서 데이터가 유실될 가능성이 높아집니다. ISR은 데이터 일관성을 보장하고, 장애 발생 시에도 서비스 중단을 최소화하여 고가용성을 유지하는 데 기여합니다.

면접관님, Kafka 프로듀서의 메시지 딜리버리 시맨틱스에 대해 설명드리겠습니다.

먼저 At-Most-Once는 메시지가 최대 한 번 전달되는 것을 보장합니다. 프로듀서가 메시지를 보내고 ACK를 받지 못하면 재시도하지 않습니다. 메시지 유실 가능성이 있지만, 중복은 발생하지 않습니다.

At-Least-Once는 최소 한 번 전달을 보장합니다. 프로듀서가 ACK를 받지 못하면 재시도합니다. 메시지 유실은 없지만, 중복 발생 가능성이 있습니다. Kafka의 기본 설정입니다.

Exactly-Once는 정확히 한 번 전달을 보장하며, 가장 강력한 시맨틱스입니다. 이를 위해 Kafka는 멱등성 프로듀서와 트랜잭션을 제공합니다. 멱등성 프로듀서는 동일한 메시지를 여러 번 보내더라도 브로커가 중복을 제거하여 정확히 한 번만 처리하도록 합니다. 트랜잭션은 여러 메시지를 하나의 원자적인 작업으로 묶어, 모두 성공하거나 모두 실패하도록 보장합니다.

Kafka의 로그 컴팩션은 특정 키에 대해 가장 최신 메시지만 유지하는 기능입니다. Kafka 토픽은 기본적으로 모든 메시지를 시간 순서대로 저장하지만, 로그 컴팩션을 활성화하면 동일한 키를 가진 이전 메시지는 삭제되고 최신 메시지만 남게 됩니다.

예를 들어, 사용자 프로필 정보를 Kafka 토픽에 저장한다고 가정해 봅시다. 사용자 A의 이름, 주소, 전화번호가 여러 번 변경될 수 있습니다. 로그 컴팩션을 사용하면 사용자 A의 최종 프로필 정보만 유지되므로, 불필요한 데이터 저장 공간을 줄이고 최신 정보만 빠르게 조회할 수 있습니다.

또 다른 예시는 데이터베이스 변경 이력(CDC)입니다. 데이터베이스의 특정 테이블에 대한 변경 사항을 Kafka로 스트리밍할 때, 로그 컴팩션을 사용하면 특정 레코드의 최종 상태만 유지할 수 있습니다. 이는 데이터베이스 복원이나 감사 목적으로 유용하게 사용될 수 있습니다. 로그 컴팩션은 토픽 설정에서 활성화할 수 있습니다.

Kafka Streams에서 상태 저장 처리는 데이터를 집계하거나 조인하는 등 상태를 유지해야 할 때 필수적입니다. 상태 저장소로는 주로 RocksDB가 사용되며, 이는 로컬 디스크에 상태를 저장합니다.

장애 복구는 Kafka Streams가 내부적으로 관리하는 changelog 토픽을 통해 이루어집니다. 애플리케이션이 중단되면, 마지막으로 커밋된 오프셋부터 changelog 토픽을 읽어 상태를 재구축합니다. 이를 위해 주기적인 체크포인팅(checkpointing)이 중요하며, 이는 상태 저장소의 스냅샷을 생성하고 해당 오프셋을 Kafka에 기록합니다.

RocksDB 성능 최적화를 위해선 로컬 디스크 I/O를 줄이는 것이 핵심입니다. 예를 들어, 쓰기 증폭(write amplification)을 줄이기 위해 memtable 크기를 조절하거나, read performance 향상을 위해 block cache를 적절히 설정할 수 있습니다. 또한, compaction 전략을 튜닝하여 디스크 공간 사용량과 읽기 성능 간의 균형을 맞추는 것도 중요합니다.

Exactly-once semantics를 보장하기 위해 Kafka Streams는 트랜잭션 API를 활용하며, 이는 상태 저장소 업데이트와 Kafka 커밋을 원자적으로 처리하여 데이터 중복이나 손실 없이 정확히 한 번만 처리되도록 합니다.

Kafka에서 End-to-End Exactly-Once Semantics를 달성하기 위해 프로듀서, 브로커, 컨슈머 각 단계별로 접근해야 합니다.

프로듀서 측면에서는 멱등성 프로듀서(Idempotent Producer)를 사용하여 동일한 메시지가 여러 번 전송되어도 브로커에서 중복 처리되지 않도록 합니다. 더 나아가 트랜잭션 프로듀서(Transactional Producer)를 사용하면 여러 토픽 또는 파티션에 걸쳐 원자적인 메시지 전송을 보장할 수 있습니다.

브로커는 프로듀서로부터 받은 메시지를 복제하고 내구성을 보장합니다. 트랜잭션 프로듀서의 경우, 브로커는 트랜잭션 상태를 관리하고 커밋 또는 롤백을 처리합니다.

컨슈머 측면에서는 메시지를 처리한 후 오프셋을 커밋하는 전략이 중요합니다. 메시지 처리와 오프셋 커밋을 원자적으로 묶기 위해 Kafka의 트랜잭션 API를 활용하거나, 외부 시스템과 연동 시 2PC(Two-Phase Commit)와 유사한 패턴을 적용하여 데이터 중복 및 유실을 방지합니다.

잠재적 이슈로는 네트워크 장애나 브로커 재시작 시 발생할 수 있는 데이터 불일치, 그리고 트랜잭션 프로토콜에서 발생할 수 있는 데드락 등이 있습니다. 이를 해결하기 위해 프로듀서의 재시도 로직 강화, 브로커의 트랜잭션 타임아웃 설정, 그리고 컨슈머의 적절한 오프셋 관리 전략이 필요합니다.

Kafka Connect 클러스터를 고가용성과 확장성 있게 운영하려면 분산 모드를 사용해야 합니다. 여러 워커 인스턴스를 실행하여 단일 실패 지점을 제거하고, 워커 재시작 시에도 작업을 이어갈 수 있도록 오프셋 관리가 중요합니다.

Source/Sink 커넥터 장애 시 데이터 유실 방지를 위해, 커넥터는 주기적으로 오프셋을 커밋해야 합니다. Kafka Connect는 이를 자동으로 관리하지만, 장애 발생 시에는 마지막으로 커밋된 오프셋부터 다시 시작하여 데이터 중복이나 누락을 최소화합니다.

추가적으로, 처리할 수 없는 메시지는 Dead Letter Queue(DLQ)로 보내어 데이터 유실을 방지하고, 이를 별도로 모니터링하여 문제를 해결합니다. 클러스터 상태, 커넥터 성능, 오프셋 커밋 상태 등을 지속적으로 모니터링하는 것도 필수적입니다. Kafka 토픽의 Replication Factor를 충분히 확보하여 Kafka 자체의 고가용성도 보장해야 합니다.

대규모 Kafka 클러스터에서 안정적인 성능을 유지하기 위해 브로커, 프로듀서, 컨슈머 각 계층별 튜닝이 중요합니다.

브로커에서는 num.io.threads와 num.network.threads를 늘려 디스크 I/O 및 네트워크 처리량을 높입니다. replica.fetch.max.bytes를 조정하여 복제 효율성을 개선하고, OS 캐시를 적극 활용하여 디스크 접근을 최소화하는 것이 좋습니다.

프로듀서에서는 batch.size와 linger.ms를 적절히 설정하여 배치 처리 효율을 높이고 네트워크 요청 수를 줄입니다. compression.type을 활용하여 전송 데이터 크기를 줄이는 것도 네트워크 부하 감소에 효과적입니다.

컨슈머에서는 fetch.min.bytes와 fetch.max.wait.ms를 조정하여 효율적인 데이터 소비를 유도합니다. 또한, max.poll.records를 통해 한 번에 처리하는 레코드 수를 조절하여 컨슈머의 처리 능력에 맞게 부하를 분산시키는 것이 중요합니다. acks 설정을 통해 데이터 내구성과 처리량 간의 균형을 맞추는 것도 고려해야 합니다.

Kafka 클러스터의 End-to-End 보안은 SSL/TLS, SASL, ACL을 조합하여 구현합니다.

SSL/TLS는 클라이언트와 브로커 간, 브로커 간 통신을 암호화하여 데이터 기밀성과 무결성을 보장합니다. 각 브로커와 클라이언트는 고유한 SSL 인증서를 발급받아 사용하며, server.properties에서 ssl.keystore.location, ssl.truststore.location 등을 설정합니다.

SASL은 사용자 인증을 담당합니다. Kerberos를 주로 사용하며, 클라이언트가 Kerberos 티켓을 제시하면 브로커가 이를 검증합니다. server.properties의 sasl.enabled, sasl.mechanism.inter.broker.protocol, sasl.mechanism.external 등을 설정합니다.

ACL은 인증된 사용자의 토픽, 그룹 등에 대한 접근 권한을 제어합니다. kafka-acls.sh 스크립트를 사용하여 특정 사용자에게 특정 토픽에 대한 읽기/쓰기 권한을 부여합니다.

보안 적용 시 SSL/TLS의 암호화 및 복호화, SASL의 인증 과정에서 CPU 오버헤드가 발생할 수 있습니다. 성능 최적화를 위해 하드웨어 가속 SSL/TLS 지원, Kerberos 대신 경량 SASL 메커니즘(SCRAM 등) 고려, 그리고 KRaft 모드에서 ACL 관리 효율성 증대를 고려할 수 있습니다. JMX나 Prometheus를 통해 보안 관련 지표를 모니터링하여 병목 지점을 파악하고 최적화합니다.

두 개 이상의 데이터센터에 걸쳐 Kafka 클러스터를 운영할 때 재해 복구(DR) 전략은 매우 중요합니다. MirrorMaker 2.0 또는 Confluent Replicator를 활용한 액티브-패시브 구성은 한쪽 데이터센터 장애 시 다른 쪽으로 장애 조치하는 방식입니다. 이때 토픽 리네이밍을 통해 원본과 복제본 토픽을 구분하고, 컨슈머 오프셋 동기화를 통해 데이터 유실 없이 소비를 재개하는 것이 핵심입니다.

액티브-액티브 구성은 양쪽 데이터센터 모두에서 데이터를 처리하지만, 데이터 일관성 유지가 더 복잡합니다. 양방향 복제 시 발생할 수 있는 데이터 충돌을 방지하기 위해 토픽별 쓰기 권한을 제한하거나, 고유 식별자를 사용하여 중복 데이터를 처리하는 전략이 필요합니다.

두 구성 모두에서 네트워크 지연은 복제 지연으로 이어질 수 있으며, 데이터센터 간 네트워크 분할(split-brain) 발생 시 데이터 불일치나 서비스 중단을 막기 위한 엄격한 리더십 선출 메커니즘과 장애 감지 및 복구 절차가 필수적입니다.

대규모 컨슈머 그룹에서 잦은 리밸런싱은 서비스 성능에 큰 영향을 줄 수 있습니다. 리밸런싱 동안에는 메시지 처리가 중단되고, 완료 후에는 컨슈머가 파티션을 다시 할당받아야 하므로 전체 처리 지연이 발생합니다. 심한 경우, 이미 처리된 메시지가 다른 컨슈머에게 재할당되어 중복 처리가 발생할 수도 있습니다.

이를 최소화하기 위해 몇 가지 전략을 고려할 수 있습니다. 먼저, max.poll.interval.ms를 적절히 조정해야 합니다. 컨슈머가 메시지 처리를 완료하는 데 충분한 시간을 확보하면서, 불필요하게 긴 시간 동안 하트비트를 보내지 않아 세션 타임아웃을 유발하지 않도록 설정해야 합니다. session.timeout.ms는 컨슈머가 그룹에서 이탈했다고 판단하는 기준 시간이므로, 네트워크 불안정성을 고려하여 너무 짧게 설정하지 않도록 주의해야 합니다. heartbeat.interval.ms는 session.timeout.ms보다 훨씬 짧게 설정하여 컨슈머가 활성 상태임을 꾸준히 알려야 합니다.

컨슈머 애플리케이션 로직 측면에서는 메시지 처리 시간을 최소화하는 것이 중요합니다. 불필요한 I/O 작업이나 복잡한 계산을 줄이고, 병렬 처리를 활용하여 전체 처리량을 늘릴 수 있습니다. 또한, 메시지 처리 실패 시 재시도 로직을 구현할 때, 데드 레터 큐(Dead Letter Queue, DLQ)를 활용하여 무한 루프를 방지하고, 문제 메시지를 격리하여 분석할 수 있도록 하는 것이 좋습니다.