메시징 시스템 면접 퀴즈

보내는 쪽과 받는 쪽을 비동기로 떼어놓아 결합도를 낮춥니다. 상대가 느리거나 잠시 죽어도 요청이 큐에 남습니다.

메시지 큐 기초

왜 메시지 큐가 필요한가?

• 비동기 처리: 이메일 발송, 알림 등 즉시 응답 불필요한 작업
• 디커플링: 서비스 간 직접 의존 제거
• 버퍼링: 트래픽 급증 시 요청을 큐에 저장 후 처리

주요 메시지 브로커

큐를 넣으면 새로 생기는 것

받는 쪽과 보내는 쪽을 떼어 놓는 대신 네 가지를 감수합니다.

같은 메시지를 두 번 받을 수 있습니다. 대부분의 큐는 적어도 한 번 전달을 약속하고 정확히 한 번은 약속하지 않습니다. 넘긴 뒤 확인이 유실되면 다시 보냅니다. 그래서 받는 쪽이 두 번 처리해도 결과가 같도록 만들어야 합니다.

순서가 보장되지 않습니다. 나눠서 처리하는 순간 도착 순서가 보낸 순서와 달라집니다. 순서가 필요하면 같은 대상의 메시지를 한 줄로 모아야 하고, 그러면 그 줄만큼만 병렬이 됩니다.

실패한 메시지가 갈 곳이 필요합니다. 계속 실패하는 하나가 줄 앞을 막으면 뒤가 전부 멈춥니다. 정해진 횟수를 넘기면 따로 빼 두고, 그 자리를 사람이 봐야 합니다.

큐 자체가 장애 지점이 됩니다. 큐가 죽으면 보내는 쪽이 무엇을 해야 하는지 정해 두어야 합니다. 요청을 거절할지, 일단 받아 두고 나중에 넣을지의 선택입니다.

언제 넣지 않는가

두 번째가 가장 흔한 오해입니다. 평균 유입이 처리 속도를 넘으면 큐 길이는 무한히 자랍니다. 큐를 크게 잡는 것은 시간을 버는 것이고 문제를 없애는 것이 아닙니다.

실무 포인트

• At-least-once vs Exactly-once: 대부분 At-least-once → 멱등성 보장 필요
• 메시지 순서 보장이 필요한가? → Kafka 파티션 키 활용
• DLQ(Dead Letter Queue)로 실패 메시지 관리

무엇을 했다는 이벤트를 발행하고 관심 있는 쪽이 받아 처리합니다. 결합도가 낮아지지만 전체 흐름이 코드 한 곳에 안 보여 추적이 어려워집니다.

이벤트 기반 아키텍처

핵심 개념

• 이벤트 발행(Publish): 서비스가 상태 변경 시 이벤트 발행
• 이벤트 구독(Subscribe): 관심 있는 서비스가 이벤트 수신
• 서비스 간 직접 호출 없이 느슨한 결합 유지

패턴

무엇이 어려워지는가

결합도가 낮아지는 대신 세 가지가 어려워집니다. 도입하기 전에 이것을 감수할 수 있는지 봅니다.

전체 흐름이 코드 한 곳에 없습니다. 주문 뒤에 무엇이 일어나는지 알려면 그 이벤트를 받는 쪽을 다 찾아야 합니다. 직접 호출이면 함수를 따라가면 보입니다. 그래서 이벤트를 쓰면 누가 무엇을 받는지 적어 두는 문서나 추적 도구가 필수가 됩니다.

순서가 보장되지 않습니다. 주문됨과 결제됨이 순서대로 발행돼도 받는 쪽에 도착하는 순서는 다를 수 있습니다. 순서가 중요하면 같은 대상의 이벤트를 한 줄로 모으거나, 받는 쪽이 순서와 무관하게 같은 결과를 내도록 만들어야 합니다.

이벤트가 계약입니다. 필드 하나를 지우면 그것을 읽던 모든 쪽이 깨집니다. 그런데 누가 읽는지 발행하는 쪽은 모릅니다. 그래서 필드를 더하는 것은 값싸고 지우거나 뜻을 바꾸는 것은 비쌉니다. 지울 때는 안 쓰는 것을 확인한 뒤 지웁니다.

언제 쓰지 않는가

서비스가 둘인데 이벤트를 쓰는 것은 대개 이릅니다. 결합도를 낮춰 얻는 이득보다 흐름이 안 보이는 비용이 큽니다.

실무 포인트

• 주문 → 결제 → 배송: 각 단계를 이벤트로 연결
• 이벤트 유실 방지: Outbox 패턴 (DB+이벤트 원자적 저장)
• 디버깅 어려움 → 이벤트 추적(Tracing) 도구 필수

메시지 전달 보장

세 가지 수준

• at-most-once: 보내고 잊는다. ack가 없어도 재전송하지 않음 → 유실 가능, 중복 없음
• at-least-once: ack를 못 받으면 재전송 → 유실 없음, 중복 가능. 실무 기본값
• exactly-once: 정확히 한 번. 조건이 붙는 제한적 보장이다

커밋 순서가 등급을 결정한다

exactly-once의 흔한 오해

• Kafka의 exactly-once는 트랜잭션으로 읽기-처리-쓰기가 Kafka 안에서 끝날 때 성립한다
• 컨슈머가 외부 DB나 결제 API를 호출하는 순간 브로커의 보장은 거기서 끊긴다
• 종단간 한 번은 결국 소비자 멱등성으로 만든다

어느 등급을 골라야 하나

등급은 취향이 아니라 그 일의 성격에서 나옵니다.

둘째가 실무의 기본값입니다. 정확히 한 번을 시스템에서 얻으려 하지 말고, 받는 쪽에서 같은 것을 두 번 처리하지 않게 만드는 쪽이 훨씬 쉽습니다.

무엇을 기준으로 같다고 보나

걸러내려면 같음의 기준이 있어야 합니다.

보내는 쪽이 만든 번호를 메시지에 담는다
받는 쪽이 그 번호를 저장하고, 있으면 건너뛴다
저장한 번호는 언제 지울지 정해 둔다

셋째가 빠지면 그 표가 무한히 커집니다. 재시도가 일어나는 기간보다 넉넉하게 두고 그 뒤는 지웁니다. 며칠이면 대개 충분합니다.

실무 포인트

• 기본 선택은 at-least-once + 멱등 소비자. exactly-once를 옵션으로 켜는 문제가 아니다
• 유실이 허용되는 지표와 클릭 로그 수집은 at-most-once로 비용을 줄인다
• ack 타임아웃이 실제 처리 시간보다 짧으면 정상 처리 중에도 중복이 폭증한다