메시지 큐와 발행·구독의 차이: 누가 메시지를 받는가
페이지 정보
본문
메시지 큐와 발행·구독을 처음 공부하면 둘 다 메시지를 보내고 받는다는 점 때문에 비슷하게 느껴집니다. 차이를 이해하려면 서버 이름보다 누가 같은 메시지를 받아야 하는지 먼저 생각하는 편이 좋습니다.
하나의 일을 여러 작업자가 나눠 처리할 것인지, 하나의 사건을 여러 기능이 각각 알아야 하는지에 따라 구조가 달라집니다. 이 글은 두 패턴의 목적과 구독의 역할을 개념 수준에서 정리합니다.
AI 생성 삽화 · 작업 분담과 여러 기능으로의 전달을 표현한 개념 삽화이며 특정 제품의 구조도는 아닙니다.
핵심 정리
작업 분담은 한 일을 누가 맡을지에 초점을 두고 발행·구독은 같은 사건을 어떤 기능에 전달할지에 초점을 둡니다. 제품에서는 두 패턴을 함께 구성할 수도 있습니다.
1. 보내는 쪽과 처리하는 쪽을 분리합니다
메시징 구조에서는 생산자가 작업 요청이나 사건 정보를 보내고 소비자가 이를 받아 처리합니다. 중간 시스템은 두 쪽의 직접 연결을 줄이는 역할을 할 수 있습니다.
생산자가 메시지를 보냈다는 사실과 소비자의 업무 처리가 끝났다는 사실은 구분해야 합니다. 전송 성공 응답이 어떤 단계의 성공을 뜻하는지는 서비스 계약에 따라 확인합니다.
화면에 완료를 표시할 때도 이 차이가 중요합니다. 가상의 이미지 처리 서비스에서 사용자가 파일을 올렸다고 해보겠습니다.
업로드가 끝났지만 썸네일 생성은 아직 대기 중일 수 있습니다. 메시지를 맡겼다는 상태를 썸네일 완료라고 보여주면 사용자는 없는 결과를 찾게 됩니다.
따라서 업로드 완료, 처리 대기, 결과 준비 같은 상태를 업무에 맞게 나눌 수 있습니다. 이는 특정 메시징 제품의 기능 목록이 아니라 비동기 작업을 설명하는 예시입니다.
2. 작업 큐에서는 같은 일을 나누어 맡습니다
작업 큐 패턴은 여러 소비자가 대기 중인 일을 분담하도록 구성하는 데 쓰입니다. 썸네일 생성 작업이 많이 들어오면 여러 작업자가 서로 다른 파일을 맡는 상황을 생각할 수 있습니다.
이때 의도는 모든 작업자가 모든 파일을 각각 만드는 것이 아닙니다. 하나의 논리적 작업이 완료되도록 분담하는 것입니다.
다만 이 의도와 전달 보장이 정확히 한 번이라는 주장은 구분해야 합니다. Amazon SQS 표준 큐 문서는 최소 한 번 전달과 중복 전달 가능성, 순서가 달라질 가능성을 설명합니다.
따라서 작업 분담 구조를 그렸다고 중복 실행을 고려하지 않아도 되는 것은 아닙니다. 같은 메시지가 다시 왔을 때 결과를 중복 생성하지 않도록 소비자 처리 방식을 검토해야 합니다.
제품별 큐 유형과 설정에 따라 조건이 달라질 수 있으므로 '큐는 항상 순서대로 한 번만 처리한다'는 문장으로 외우지 않는 것이 좋습니다.
3. 발행·구독에서는 기능별 전달을 생각합니다
발행·구독 패턴에서는 생산자가 사건을 발행하고 관심 있는 기능들이 이를 받아 각자의 일을 수행하도록 구성합니다. 예를 들어 문서 등록 사건을 검색 색인 기능과 통계 기능이 각각 알아야 할 수 있습니다.
두 기능 중 하나만 사건을 받아서는 원하는 결과가 완성되지 않습니다. 이 경우 같은 사건을 기능별로 전달할 수 있는 구독 구조를 검토합니다.
작업 큐에서 같은 일을 분담하는 목적과 차이가 드러나는 부분입니다. Google Cloud Pub/Sub는 토픽과 구독을 통해 이런 구성을 설명합니다.
토픽에 연결된 구독을 기능별로 두고 각 구독의 소비자가 처리하게 만들 수 있습니다. 여기서 발행·구독이라는 패턴 이름과 특정 제품 이름은 같은 범위의 말이 아닙니다.
제품마다 구독 관리와 전달 조건이 다르므로 한 제품의 동작을 모든 메시징 시스템에 그대로 적용하지 않습니다. 목적을 먼저 정한 뒤 제품의 기능을 맞춰 읽어야 합니다.
4. 구독 하나에 작업자 여러 명을 붙일 수 있습니다
발행·구독과 작업 분담은 서로 완전히 배타적인 선택이 아닙니다. Google Cloud Pub/Sub에서는 하나의 구독을 여러 구독자 클라이언트가 공유해 작업을 나눌 수 있습니다.
기능별 구독을 나눈 뒤 각 기능 안에서 처리량을 늘리는 구성을 생각할 수 있는 것입니다. 같은 토픽에 연결됐다는 사실만으로 모든 실행 인스턴스가 모든 메시지를 각각 받는다고 이해하면 혼란이 생깁니다.
설명용으로 검색 구독에 작업자 두 개, 통계 구독에 작업자 한 개가 있다고 가정합니다. 문서 등록 사건은 두 기능에 각각 필요하지만 검색 작업자 둘은 검색 업무를 분담하는 관계입니다.
이때 그림에서 토픽, 구독, 실행 중인 작업자를 서로 다른 상자로 표시하면 의도가 분명해집니다. 실제 전달과 재전달은 서비스 보장에 따라 다룰 부분입니다.
작업자 수를 늘린 것과 업무 종류를 늘려 새 구독을 만든 것은 다른 변경입니다.
5. 수신 확인과 업무 완료 시점을 연결합니다
소비자가 메시지를 받았다는 것과 그 메시지에 따른 작업을 끝냈다는 것은 다릅니다. 수신 확인이나 삭제 처리를 언제 하는지는 장애 복구와 연결됩니다.
결과를 만들기 전에 완료 처리를 해버리면 그 뒤 실패했을 때 필요한 작업이 누락될 수 있습니다. 반대로 결과를 만든 뒤 확인 전달이 실패하면 같은 메시지가 다시 올 수 있습니다.
구체적인 확인 방식과 재전달 조건은 사용하는 제품 문서를 따라야 합니다. 학습용 시나리오에서는 메시지 수신, 결과 파일 저장, 완료 확인 전송을 세 단계로 적어봅니다.
각 단계 사이에서 프로세스가 멈췄다고 가정하고 다시 시작할 때 어떤 상태를 만날지 생각합니다. 이 과정에서 작업 식별자와 기존 결과 조회가 필요한 이유가 드러날 수 있습니다.
성공 경로만 그리는 것보다 실패 지점을 나누면 중복과 누락을 어디에서 다뤄야 하는지 설명하기 쉽습니다. 단순한 화살표 그림만으로 복구 정책까지 정해지지는 않습니다.
6. 순서와 재처리 요구는 별도 질문입니다
메시지를 저장하고 전달하는 기능이 있다고 모든 업무 순서가 자동으로 맞춰지는 것은 아닙니다. 같은 문서의 생성과 수정 사건이 있다면 소비자가 어느 버전을 처리하는지 고려해야 합니다.
순서 보장의 범위와 재전달 동작은 제품과 설정에 따라 확인합니다. 순서가 필요한 단위가 문서별인지 사용자별인지도 업무에서 정해야 합니다.
무조건 전체 메시지를 하나의 순서로 묶는 것이 요구에 맞는지는 별도 문제입니다. 실패한 메시지를 어떻게 다시 처리할지도 계획합니다.
항상 실패하는 입력을 계속 되돌리면 정상 작업과 함께 지연될 수 있습니다. 실패 원인과 시도 상태를 확인할 수 있는 기록을 두고 재처리 전에 입력이나 처리 코드가 바뀌었는지 검토합니다.
이 글에서는 특정 횟수나 대기 시간을 권장하지 않습니다. 운영자가 어떤 작업이 남았고 왜 끝나지 않았는지 알 수 있도록 상태를 나누는 것이 기본적인 설계 질문입니다.
7. 같은 사건을 누가 필요로 하는지 먼저 적습니다
작은 설계 연습으로 게시글 등록 후 썸네일 생성과 검색 반영이 필요한 서비스를 생각해봅니다. 첫 줄에는 등록 사건을 발행하는 쪽을 적고 다음 줄에는 그 사건이 필요한 두 기능을 적습니다.
각 기능이 모든 등록 사건을 받아야 한다면 전달 경로를 분리하는 구독 구성을 검토할 수 있습니다. 썸네일 작업이 많아 작업자를 늘리는 경우에는 그 기능 안에서 일을 분담하도록 생각합니다.
숫자 대신 역할을 먼저 적는 것이 핵심입니다. 이후 각 기능의 완료 기준과 실패 시 동작을 추가합니다.
검색 반영이 늦어져도 썸네일 완료 상태는 별도로 표시할 수 있는지, 같은 사건이 다시 오면 무엇을 확인할지 질문합니다. 실제 실행을 하지 않았다면 예상 구조라고 기록하고 처리량이나 지연 수치를 실측 결과처럼 붙이지 않습니다.
메시지 큐와 발행·구독을 구분하는 목적은 용어 시험에 답하는 데 그치지 않습니다. 하나의 일을 나누는 관계와 여러 기능에 같은 사실을 알리는 관계를 설계에서 명확히 표현하는 데 있습니다.
8. 자주 묻는 질문
Q1. 큐를 쓰면 메시지는 반드시 한 번만 처리되나요?
그렇게 일반화할 수 없습니다. 예를 들어 SQS 표준 큐는 중복 전달 가능성이 있으므로 제품의 전달 보장과 소비자의 중복 처리 방식을 함께 확인합니다.
Q2. 발행·구독에서는 모든 서버가 같은 메시지를 받나요?
구독 구조에 따라 달라집니다. 기능별 구독과 같은 구독을 공유하는 작업자 관계를 구분하고 사용하는 서비스의 전달 방식을 확인해야 합니다.
Q3. 메시지 발행 성공이면 작업도 완료된 것인가요?
발행과 업무 처리는 다른 단계입니다. 사용자에게 어떤 완료 상태를 보여줄지 정하고 소비자의 실제 처리 결과와 연결해야 합니다.
Q4. 큐와 발행·구독 중 무엇을 먼저 선택하나요?
같은 일을 분담할지 여러 기능이 같은 사건을 각각 받아야 할지부터 정합니다. 제품에서는 구독별 전달과 구독 내부의 작업 분담을 함께 구성할 수 있습니다.
참고 자료
- 이전글과적합과 과소적합 차이, 학습 결과를 두 곡선으로 이해하기 26.09.14
- 다음글임베딩과 코사인 유사도: 가까운 벡터가 뜻하는 것 26.09.13
댓글목록
등록된 댓글이 없습니다.