Kafka 신입 시스템 설계 면접
새 면접Q. 전자상거래 서비스에서 주문이 발생하면 재고 시스템, 결제 시스템, 배송 시스템에 모두 알림을 보내야 합니다. Kafka를 사용한다면 어떤 구조로 설계하시겠습니까?
하나의 이벤트를 여러 시스템이 독립적으로 구독하는 방식을 생각해보세요.
주문 서비스가 'order-created'라는 토픽에 주문 이벤트를 발행하도록 설계하겠습니다. 재고, 결제, 배송 시스템은 각각 독립적인 컨슈머 그룹으로 해당 토픽을 구독합니다. 이렇게 하면 각 시스템이 서로 영향을 주지 않고 독립적으로 메시지를 처리할 수 있습니다. 한 시스템이 장애가 발생해도 다른 시스템은 정상 작동하며, 새로운 시스템 추가 시 기존 시스템 수정 없이 토픽만 구독하면 됩니다. 이는 느슨한 결합(loose coupling)을 통해 확장성과 유지보수성을 높이는 이벤트 기반 아키텍처입니다.
- • 단일 토픽에 이벤트 발행
- • 각 시스템이 독립적인 컨슈머 그룹으로 구독
- • 느슨한 결합을 통한 확장성 확보
MSA 환경에서 서비스 간 비동기 통신을 구현할 때 사용됩니다.
만약 재고 시스템이 일시적으로 다운되었다가 복구된다면, 그동안 발생한 주문 이벤트는 어떻게 처리될까요?
Q. 사용자 활동 로그를 수집하는 시스템에서 트래픽이 급증할 것으로 예상됩니다. Kafka 토픽의 파티션 수를 결정할 때 어떤 요소들을 고려해야 하나요?
처리량, 병렬성, 그리고 메시지 순서 보장 사이의 관계를 생각해보세요.
파티션 수는 예상 처리량과 컨슈머의 병렬 처리 능력을 고려해 결정해야 합니다. 파티션 수만큼 컨슈머를 병렬로 실행할 수 있으므로, 높은 처리량이 필요하면 파티션을 많이 만들어야 합니다. 하지만 파티션이 많을수록 브로커의 메타데이터 관리 부담이 증가하고, 리밸런싱 시간도 길어집니다. 또한 같은 키를 가진 메시지는 같은 파티션으로 가므로, 특정 사용자의 이벤트 순서를 보장해야 한다면 사용자 ID를 키로 사용하는 전략이 필요합니다. 일반적으로 예상 최대 컨슈머 수와 처리량을 기준으로 파티션 수를 설정하되, 나중에 증가는 가능하지만 감소는 어려우므로 신중하게 결정해야 합니다.
- • 처리량과 병렬성을 위해 충분한 파티션 확보
- • 파티션 수 증가에 따른 관리 오버헤드 고려
- • 메시지 순서 보장이 필요한 경우 키 기반 파티셔닝 전략 수립
대규모 로그 수집 시스템이나 실시간 분석 파이프라인 설계 시 필수적으로 고려해야 합니다.
파티션을 나중에 늘리면 기존 메시지의 파티션 분배에 어떤 영향이 있을까요?
Q. Kafka에서 메시지를 발행하는 프로듀서를 설계할 때, 메시지 전송 실패를 처리하기 위해 어떤 설정과 전략을 사용할 수 있나요?
재시도 정책과 전송 보장 수준(acks)을 고려해보세요.
프로듀서의 acks 설정을 통해 메시지 전송 보장 수준을 결정할 수 있습니다. acks=0은 응답을 기다리지 않아 빠르지만 유실 가능성이 있고, acks=1은 리더 파티션만 확인하며, acks=all은 모든 복제본이 받았는지 확인해 가장 안전합니다. retries 설정으로 전송 실패 시 자동 재시도 횟수를 지정할 수 있으며, retry.backoff.ms로 재시도 간격을 조절합니다. 중요한 데이터라면 acks=all과 적절한 재시도 설정을 사용하고, 애플리케이션 레벨에서도 전송 실패를 로깅하거나 별도 처리하는 방어 로직을 추가해야 합니다.
- • acks 설정으로 전송 보장 수준 결정
- • retries와 retry.backoff.ms로 재시도 정책 설정
- • 데이터 중요도에 따른 적절한 설정 조합 선택
금융 거래나 주문 처리 같은 데이터 유실이 허용되지 않는 시스템에서 필수적입니다.
acks=all을 사용하면 성능에 어떤 영향이 있고, 이를 완화하기 위한 방법은 무엇일까요?
Q. 실시간 알림 서비스를 Kafka 컨슈머로 구현할 때, 메시지 처리 중 오류가 발생하면 어떻게 처리해야 할까요? 오프셋 커밋 전략과 함께 설명해주세요.
메시지 처리 성공 여부와 오프셋 커밋 시점의 관계를 고려해보세요.
메시지 처리가 완전히 성공한 후에만 오프셋을 커밋하는 전략이 안전합니다. enable.auto.commit을 false로 설정하고 수동으로 커밋을 제어해야 합니다. 처리 중 오류 발생 시, 재시도 로직을 구현하되 무한 재시도를 방지하기 위해 최대 재시도 횟수를 제한합니다. 재시도 후에도 실패하는 메시지는 DLQ(Dead Letter Queue)라는 별도 토픽으로 보내서 나중에 분석하고 처리할 수 있도록 합니다. 이렇게 하면 한 메시지의 오류가 전체 파이프라인을 막지 않으면서도 데이터 유실을 방지할 수 있습니다. 처리 완료된 메시지만 오프셋을 커밋하므로 컨슈머 재시작 시 미처리 메시지부터 다시 읽을 수 있습니다.
- • 수동 오프셋 커밋으로 처리 성공 후에만 커밋
- • 재시도 로직과 최대 재시도 횟수 제한
- • DLQ 패턴으로 반복 실패 메시지 별도 처리
결제 알림, 이메일 발송 등 처리 실패를 추적하고 재처리해야 하는 시스템에서 사용됩니다.
DLQ에 쌓인 메시지들은 실무에서 어떻게 처리하나요?
Q. 여러 마이크로서비스가 사용자 정보 변경 이벤트를 필요로 합니다. 각 서비스가 필요로 하는 정보가 다를 때, 토픽을 어떻게 설계하는 것이 좋을까요?
단일 토픽 vs 다중 토픽, 그리고 메시지에 포함될 데이터의 범위를 고려해보세요.
기본적으로 'user-updated'라는 단일 토픽에 전체 사용자 정보를 포함한 이벤트를 발행하는 것이 좋습니다. 각 컨슈머는 필요한 필드만 선택적으로 사용하면 되므로 시스템이 단순해집니다. 메시지에는 이벤트 타입, 타임스탬프, 변경된 필드 정보를 포함시켜 컨슈머가 필요한 변경사항만 필터링할 수 있게 합니다. 다만 민감한 개인정보가 포함된 경우, 접근 권한에 따라 'user-profile-updated', 'user-payment-info-updated' 같이 토픽을 분리할 수 있습니다. 메시지 스키마는 Avro나 Protobuf 같은 스키마 레지스트리를 사용해 하위 호환성을 유지하면서 진화시킬 수 있도록 설계합니다.
- • 기본적으로 단일 토픽에 전체 정보 포함
- • 보안이나 도메인 경계가 명확한 경우 토픽 분리
- • 스키마 레지스트리로 메시지 구조 관리 및 호환성 유지
사용자 프로필 동기화, CQRS 패턴 구현, 데이터 변경 이력 추적 등에 활용됩니다.
스키마 레지스트리를 사용하면 어떤 장점이 있나요?
Q. 대용량 로그 데이터를 Kafka로 수집하는데, 같은 데이터를 실시간 모니터링과 배치 분석 두 가지 목적으로 사용해야 합니다. 각각 다른 처리 속도와 보관 정책이 필요할 때 어떻게 설계하시겠습니까?
컨슈머 그룹의 독립성과 토픽의 보관 정책을 함께 고려해보세요.
단일 토픽에 로그를 발행하고, 실시간 모니터링과 배치 분석을 각각 독립적인 컨슈머 그룹으로 구독하도록 설계합니다. 실시간 모니터링 컨슈머는 최신 데이터만 빠르게 처리하고, 배치 분석 컨슈머는 자신의 속도로 모든 데이터를 처리합니다. 토픽의 retention 설정은 배치 분석에 필요한 기간(예: 7일)으로 설정하여 충분한 데이터를 보관합니다. 만약 장기 보관이 필요하다면 Kafka Connect를 사용해 S3나 HDFS 같은 저장소로 데이터를 자동 전송하는 파이프라인을 추가합니다. 실시간 모니터링이 지연되더라도 배치 분석에 영향을 주지 않고, 각 컨슈머 그룹이 독립적으로 오프셋을 관리하므로 서로 간섭하지 않습니다.
- • 독립적인 컨슈머 그룹으로 다른 속도의 처리 구현
- • 토픽 retention 설정으로 필요 기간만큼 데이터 보관
- • 장기 보관은 Kafka Connect로 외부 스토리지 연계
로그 분석 플랫폼에서 실시간 대시보드와 일별 리포트를 동시에 제공할 때 사용됩니다.
실시간 컨슈머가 장애로 며칠간 중단되었다가 복구되면 어떻게 해야 할까요?
Q. Kafka 컨슈머가 외부 API를 호출해 데이터를 보강(enrichment)하는 시스템에서, API 호출을 줄이기 위한 캐싱 전략을 어떻게 설계하시겠습니까?
자주 조회되는 데이터의 특성과 캐시 갱신 방법을 생각해보세요.
컨슈머 애플리케이션 내부에 로컬 캐시(예: Caffeine, Guava Cache)를 구현하여 최근 조회한 데이터를 메모리에 보관합니다. TTL(Time To Live)을 설정해 일정 시간 후 자동으로 만료되도록 하고, LRU 정책으로 메모리를 효율적으로 관리합니다. 만약 여러 컨슈머 인스턴스가 있다면 Redis 같은 분산 캐시를 사용해 캐시를 공유할 수 있습니다. 참조 데이터가 변경되는 경우를 대비해, 별도의 Kafka 토픽으로 캐시 무효화 이벤트를 발행하고 컨슈머가 이를 구독해 캐시를 갱신하는 방식도 고려할 수 있습니다. 캐시 히트율을 모니터링하여 TTL과 캐시 크기를 최적화해야 합니다.
- • 로컬 캐시로 반복 API 호출 최소화
- • 분산 환경에서는 Redis 등 분산 캐시 활용
- • 캐시 무효화 이벤트로 데이터 일관성 유지
주문 데이터에 상품 정보를 결합하거나, 사용자 이벤트에 프로필 정보를 추가하는 스트림 처리에서 사용됩니다.
캐시와 실제 데이터 간 불일치가 발생하면 어떤 문제가 생기고, 어떻게 완화할 수 있을까요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!