[AWS] SQS(Simple Queue Service)

AWS SQS

AWS SQS (Amazon Simple Queue Service)는 분산 메시지 대기열 서비스로, 애플리케이션 구성 요소 간의 통신을 비동기적으로 지원합니다. 이를 통해 시스템의 확장성, 내결함성, 성능을 향상시킬 수 있습니다. AWS SQS는 관리형 서비스로, 메시징 인프라의 운영 및 유지보수에 대한 부담을 덜어줍니다.

AWS SQS의 기본 개념

1. 메시지

메시지는 SQS 큐에 저장되는 데이터입니다. 메시지는 본문(body)과 메타데이터(속성)로 구성됩니다. 본문은 애플리케이션 간에 전송되는 실제 데이터이며, 속성은 메시지에 대한 추가 정보를 포함합니다.

2. 큐

큐는 메시지를 저장하고, 메시지를 전송자와 수신자 사이에서 일시적으로 보관하는 공간입니다. SQS에는 두 가지 유형의 큐가 있습니다.

• 표준 큐 (Standard Queue): 높은 처리량을 지원하며, 최소한 한 번의 전달(at-least-once delivery)을 보장하지만, 메시지의 순서가 보장되지 않습니다. 메시지 중복이 발생할 수 있습니다.
• FIFO 큐 (First-In-First-Out Queue): 메시지의 순서가 보장되며, 정확히 한 번 전달(exactly-once processing)을 보장합니다. 중복이 허용되지 않습니다.

3. 메시지 전송 및 수신

• 메시지 전송: 프로듀서(전송자)는 메시지를 SQS 큐에 보냅니다. 메시지는 큐에 일시적으로 저장됩니다.
• 메시지 수신: 컨슈머(수신자)는 메시지를 큐에서 가져와 처리합니다. 메시지를 가져오면 해당 메시지는 다른 컨슈머가 접근하지 못하도록 비가시성 시간(visibility timeout) 동안 숨겨집니다.

4. 비가시성 시간 (Visibility Timeout)

메시지를 수신한 후 컨슈머가 메시지를 처리할 시간을 제공합니다. 비가시성 시간 동안 메시지는 다른 컨슈머에게 보이지 않습니다. 메시지가 비가시성 시간 내에 처리되지 않으면, 메시지는 다시 큐에 나타나고 다른 컨슈머가 이를 가져갈 수 있습니다.

5. 메시지 재시도 및 삭제

• 메시지 재시도: 컨슈머가 메시지를 성공적으로 처리하지 못한 경우, 비가시성 시간이 만료되면 메시지가 다시 큐에 나타나고 다른 컨슈머가 이를 처리할 수 있습니다.
• 메시지 삭제: 컨슈머가 메시지를 성공적으로 처리하면, 큐에서 메시지를 삭제합니다.

6. Dead-Letter Queue (DLQ)

DLQ는 특정 조건(예: 최대 재시도 횟수 초과)에서 실패한 메시지를 저장하는 큐입니다. 

이를 통해 문제를 분석하고, 수동으로 메시지를 처리할 수 있습니다.

AWS SQS의 장점

• 확장성: 자동으로 확장되어 대규모 메시지 처리량을 지원합니다.
• 내결함성: 메시지가 여러 가용 영역에 복제되어 높은 가용성을 보장합니다.
• 관리형 서비스: AWS에서 인프라를 관리하므로, 사용자는 애플리케이션 로직에 집중할 수 있습니다.
• 유연성: 비동기 메시징을 통해 시스템 구성 요소 간의 느슨한 결합을 유지할 수 있습니다.
• 비용 효율성: 사용한 만큼 지불하는 요금제로, 초기 비용 없이 쉽게 시작할 수 있습니다.

SQS DLQ

메시지가 일정 횟수 이상 처리되지 못했을 때 이를 별도의 큐로 이동시켜 추후에 분석하거나 수동으로 처리할 수 있도록 하는 기능

메시지가 소비자에 의해 처리되지 못하고 일정 횟수 이상 재시도된 경우, DLQ로 이동

Redrive Policy는 DLQ와 연계된 정책으로, 메시지가 몇 번의 재시도 후 DLQ로 이동할지를 결정

메시지 재시도 주기 (Visibility Timeout)

Visibility Timeout은 메시지를 소비자가 수신한 후 일정 시간 동안 다른 소비자에게 보이지 않도록 하는 기능

메시지가 이 Visibility Timeout 기간 동안 삭제되지 않으면, 그 기간이 지나면 다시 큐에 나타나게 됩니다.

이 시간이 지나면 SQS는 다른 소비자가 메시지를 다시 가져갈 수 있게 합니다. 

이 과정을 통해 메시지 재시도 주기가 결정됩니다.

기본적으로 Visibility Timeout의 기본 값은 30초이며, 최대 12시간까지 설정 가능

Point-to-point 채널

Point-to-Point 모델은 일반적으로 다음과 같은 특징을 가집니다:

• 한 개의 Producer와 한 개의 Consumer가 존재합니다.
• 메시지가 큐를 통해 전달되며, 메시지는 한 번 소비되면 큐에서 제거됩니다.
• 동일한 메시지를 오직 하나의 Consumer만 처리합니다.

AWS SQS는 이러한 Point-to-Point 메시징 모델의 전형적인 예입니다

• Producer가 SQS 큐에 메시지를 보냅니다.
• Consumer가 큐에 접근하여 메시지를 가져가고 처리합니다.
• 메시지가 처리된 후 큐에서 삭제되며, 다른 소비자는 동일한 메시지를 처리할 수 없습니다.
• 따라서 AWS SQS는 기본적으로 하나의 메시지를 하나의 소비자만 처리하는 방식으로 동작하며, 
• 이것은 Point-to-Point 패턴과 일치합니다.

다중 소비자 시나리오

만약 여러 개의 소비자가 존재하는 경우에도, SQS 큐는 동일한 메시지를 여러 소비자에게 보내지 않습니다. 

소비자가 메시지를 가져가고 처리하는 동안, 해당 메시지는 다른 소비자에게 보이지 않습니다. 

이는 SQS가 경쟁 소비자 모델로 동작하기 때문입니다:
여러 소비자가 있더라도 경쟁적으로 큐에서 메시지를 가져가 처리합니다.

메시지를 가장 먼저 가져간 소비자가 이를 처리하고 삭제하면, 다른 소비자들은 해당 메시지를 처리할 수 없습니다.

FIFO 대기열의 특성

메시지 순서 보장: FIFO 큐는 First-In-First-Out으로 메시지를 처리하므로 메시지가 전송된 순서대로 소비됩니다. 

이로 인해, Delete 메시지가 먼저 전송되면, 그 후에 전송된 Insert 메시지는 항상 그 다음에 처리됩니다.

 

중복 방지: FIFO 큐는 중복 제거(deduplication) 기능을 제공합니다. 동일한 메시지가 여러 번 전송되더라도 중복 메시지는 제거되므로, 메시지 순서만 적절히 관리되면 중복 문제를 피할 수 있습니다.

메시지 그룹: FIFO 큐에서 메시지는 메시지 그룹(Message Group ID)으로 구분됩니다. 동일한 메시지 그룹 내에서는 순서가 보장되지만, 다른 메시지 그룹 간에는 순서가 독립적으로 처리됩니다. 메시지 그룹을 적절히 관리하면 동일한 개체에 대한 Delete와 Insert 요청의 순서가 유지됩니다.

Delete 후 Insert의 이슈 가능성

이슈가 없으려면 메시지 순서가 보장되고 중복 메시지 처리가 잘 되어야 합니다. 그러나 다음과 같은 경우 이슈가 발생할 가능성이 있습니다:

동일한 메시지 그룹 내에서 처리해야 함: Delete와 Insert 메시지가 동일한 메시지 그룹 ID로 전송되어야만 순서가 보장됩니다. 서로 다른 메시지 그룹으로 전송되면 순서가 보장되지 않으므로 Delete 메시지가 먼저 처리된다는 보장이 없어질 수 있습니다.

비동기 처리: SQS는 비동기 처리 시스템이므로, Delete 메시지가 성공적으로 처리되지 못한 상태에서 Insert 메시지가 처리되는 경우 데이터 일관성 문제가 발생할 수 있습니다. 따라서 비동기 처리의 특성을 고려하여 idempotent(멱등성) 처리가 필요할 수 있습니다.

네트워크 및 시스템 장애: 네트워크 장애나 시스템 오류로 인해 메시지가 처리되지 않거나 지연될 경우, FIFO 대기열의 특성에 따라 순서 보장은 되지만 장애가 복구될 때까지 Insert 메시지가 지연될 수 있습니다.

 

FIFO 큐의 순서 보장: 메시지들은 Message Group ID 내에서 순서대로 처리됩니다. 예를 들어, Delete 메시지가 먼저 전송되고 그 뒤에 Insert 메시지가 전송되었다면, Insert 메시지는 반드시 Delete 메시지 뒤에 처리됩니다.

메시지의 개별 성공 여부는 상관없음: SQS는 메시지 처리에 있어 각 메시지를 개별적으로 처리합니다. 만약 Delete 메시지가 실패(예: 소비자가 제대로 처리하지 못하거나 Visibility Timeout이 만료된 경우)하더라도 Insert 메시지는 여전히 순서가 도래하면 처리될 수 있습니다. FIFO 큐는 메시지의 처리 순서를 보장하지만, 이전 메시지의 성공 여부에 따른 다음 메시지의 대기는 자동으로 이루어지지 않습니다.

메시지 그룹(Message Group)

Message Group ID: FIFO Queue에서는 메시지를 보낼 때 Message Group ID를 지정할 수 있습니다. 이 ID는 같은 그룹에 속하는 메시지들이 순차적으로 처리되도록 보장해 줍니다.

동일 그룹 내 메시지 순서 보장: 동일한 Message Group ID를 가진 메시지는 큐에 저장된 순서대로 소비됩니다. 예를 들어, 특정 작업과 관련된 여러 메시지가 순서대로 처리되어야 할 때 Message Group ID를 동일하게 설정해주면, 이 메시지들이 전송된 순서대로 처리됩니다.

독립적 메시지 그룹: 서로 다른 Message Group ID를 가진 메시지는 독립적으로 병렬 처리될 수 있습니다. 이는 SQS의 확장성과 병렬 처리 성능을 높이는 데 도움이 됩니다. 예를 들어, Message Group ID가 다른 메시지 그룹들은 동시에 여러 소비자(consumer)에 의해 처리될 수 있습니다.

AWS SQS와 EDA

AWS SQS는 메시지 큐 서비스로, 이벤트 기반 아키텍처를 구현하는 데 매우 유용합니다. 

SQS를 사용하면 이벤트를 큐에 넣고, 다양한 소비자들이 이를 비동기적으로 처리할 수 있습니다.

SQS를 이용한 EDA 구성 예시

• 이벤트 생성: 다양한 서비스가 이벤트를 생성하고, 이를 SQS 큐에 메시지로 전송합니다.
• 이벤트 큐잉: SQS는 이벤트 메시지를 큐에 저장합니다. 큐는 메시지를 안전하게 저장하고, 처리할 수 있는 상태로 유지합니다.
• 이벤트 처리: 하나 이상의 이벤트 소비자(서버 또는 서비스)가 SQS 큐를 폴링하여 이벤트 메시지를 가져오고 처리합니다.

예시: 주문 처리 시스템

• 주문 생성 서비스: 고객이 주문을 생성하면, 주문 생성 서비스는 새로운 주문 이벤트를 SQS 큐에 메시지로 전송합니다.
• 주문 처리 서비스: 주문 처리 서비스는 SQS 큐를 폴링하여 새로운 주문 메시지를 가져오고, 이를 처리하여 데이터베이스에 저장하거나, 재고 시스템을 업데이트합니다.
• 알림 서비스: 주문이 처리되면 알림 서비스가 SQS 큐에서 처리 완료 이벤트를 가져와, 고객에게 이메일이나 SMS로 알림을 보냅니다.

Apache Kafka 와 AWS SQS

Apache Kafka와 AWS SQS는 모두 메시징 시스템이지만, 각각의 특성과 용도는 다릅니다. 

두 시스템 간의 주요 차이점을 이해하면 특정 사용 사례에 적합한 솔루션을 선택하는 데 도움이 됩니다.

 

특성	Apache Kafka	AWS SQS
아키텍처	분산 클러스터	관리형 서비스, 단일 큐
메시지 저장	로그 기반 저장, 오프셋 관리	큐 기반, 단순 메시지 저장
처리량	매우 높은 처리량	높은 처리량, 그러나 Kafka보다는 낮음
메시지 소비 모델	여러 소비자가 독립적으로 소비	하나의 메시지는 하나의 소비자가 처리
순서 보장	기본적으로 순서 보장	FIFO 큐를 사용해야 순서 보장
유지 기간	지정된 기간 동안 유지	기본적으로 14일 동안 유지
운영 관리	직접 관리 필요	AWS에서 완전 관리
사용 사례	실시간 스트리밍, 데이터 통합	비동기 작업 처리, 일시적 메시징

Apache Kafka

Apache Kafka는 스트리밍 데이터 처리와 분산 메시징을 위해 설계된 오픈 소스 플랫폼입니다.

주요 특징

• 분산 아키텍처: Kafka는 분산 시스템으로, 여러 노드로 구성된 클러스터에서 작동합니다. 이는 높은 확장성과 내결함성을 제공합니다.
• 로그 기반 저장: 메시지를 로그로 저장하며, 각 메시지는 오프셋을 가집니다. 소비자는 특정 오프셋에서 메시지 소비를 시작할 수 있습니다.
• 높은 처리량: 대량의 데이터를 고속으로 처리할 수 있으며, 실시간 데이터 스트리밍에 적합합니다.
• 내결함성: 데이터를 복제하여 고가용성을 보장합니다. 클러스터의 일부 노드가 실패해도 데이터 손실 없이 계속 작동할 수 있습니다.
• 다양한 소비자 모델: 여러 소비자가 독립적으로 메시지를 소비할 수 있으며, 동일한 메시지를 여러 번 처리할 수 있습니다.
• 상태 유지: 메시지는 특정 시간 동안 또는 특정 용량까지 유지되며, 소비자는 필요에 따라 메시지를 다시 읽을 수 있습니다.

사용 사례

• 실시간 데이터 처리: 실시간 로그 분석, 이벤트 스트리밍, 실시간 대시보드 업데이트 등.
• 데이터 통합: 다양한 시스템 간의 데이터 통합과 파이프라인 구축.
• 메시지 리플레이: 과거 데이터를 다시 읽어 재처리하는 기능이 필요한 경우.

Kafka pub-sub 모델에서의 메시지 처리

Kafka의 pub-sub 모델에서는 토픽을 구독하는 여러 consumer 그룹이 있을 수 있으며, 

각 그룹이 동일한 토픽의 메시지를 처리할 수 있습니다. 

이를 통해 여러 개의 consumer 그룹이 동일한 메시지를 중복해서 처리할 수 있게 됩니다.

 

하나의 토픽에 게시된 메시지는 여러 consumer 그룹이 구독할 수 있습니다.

각 consumer 그룹은 독립적으로 메시지를 처리합니다. 

따라서 하나의 그룹이 메시지를 처리해도 다른 그룹은 여전히 동일한 메시지를 처리할 수 있습니다.

Kafka의 이러한 구조는 동일한 메시지가 여러 서비스 또는 프로세스에서 동시에 사용되어야 하는 경우에 매우 유용

예를 들어, 하나의 토픽을 통해 데이터 분석, 로깅, 실시간 알림 등 다양한 처리가 동시에 가능

AWS SQS

AWS SQS는 Amazon Web Services에서 제공하는 완전 관리형 메시지 큐 서비스입니다.

주요 특징

• 단순 큐 모델: 메시지를 큐에 넣고 소비자가 이를 읽어가는 단순한 큐 모델을 사용합니다.
• 관리형 서비스: AWS에서 관리하므로, 인프라 관리나 유지보수가 필요 없습니다.
• 확장성: 자동으로 확장되며, 대량의 메시지를 처리할 수 있습니다.
• 내결함성: 메시지가 여러 가용 영역에 복제되어 높은 내결함성을 제공합니다.
• 메시지 중복: 메시지의 중복 수신이 발생할 수 있으므로, 애플리케이션 레벨에서 멱등성 처리가 필요합니다.
• 메시지 순서 보장: FIFO 큐를 사용하면 메시지 순서가 보장됩니다. 표준 큐에서는 순서가 보장되지 않습니다.
• 비용: 사용한 만큼 지불하는 요금제로, 초기 비용 없이 쉽게 시작할 수 있습니다.

사용 사례

• 비동기 작업 처리: 비동기 작업 큐잉, 백그라운드 작업 처리 등.
• 분산 시스템 통합: 다양한 시스템 간의 느슨한 결합을 통한 통합.
• 일시적 메시징: 메시지를 짧은 기간 동안 저장하고 처리하는 경우.

Batch 와 AWS SQS

AWS SQS를 사용하는 경우

장점

1. 확장성: SQS는 자동으로 확장할 수 있으며, 대량의 메시지를 처리할 수 있습니다. 대규모 데이터를 여러 소비자(서버)에게 분산 처리할 수 있습니다.
2. 내결함성: 메시지가 SQS 큐에 안전하게 저장되므로, 소비자가 일시적으로 다운되거나 문제가 발생해도 메시지는 손실되지 않습니다.
3. 비동기 처리: SQS는 비동기적으로 메시지를 처리하여 시스템의 다른 작업과 병렬로 수행할 수 있습니다.
4. 탄력성: 수요에 따라 소비자 인스턴스를 추가하거나 제거하여 동적으로 대처할 수 있습니다.

단점

1. 복잡성: 메시지 큐 시스템을 설계하고 구현하는 것은 다소 복잡할 수 있으며, 추가적인 코드 작성과 유지 관리가 필요합니다.
2. 지연: 메시지가 큐를 통해 전송되기 때문에 약간의 지연이 발생할 수 있습니다. 실시간 처리보다는 약간 느릴 수 있습니다.
3. 멱등성: 메시지 중복 처리 가능성에 대비해 멱등성을 보장하는 로직을 추가해야 합니다.

언제 AWS SQS를 사용하는 것이 좋을까?

1. 실시간 또는 준실시간 데이터 처리: 데이터를 실시간으로 처리해야 하거나, 거의 실시간으로 처리해야 하는 경우.
2. 고가용성 및 내결함성: 시스템이 중단 없이 데이터를 처리해야 하는 경우.
3. 탄력적 확장성 필요: 데이터 처리량이 변동이 심하거나, 처리량이 급격히 증가할 수 있는 경우.

배치 처리(Batch Processing)를 사용하는 경우

장점

1. 단순성: 배치 처리는 일반적으로 한 번에 많은 데이터를 처리하는데 적합하며, 단순한 스크립트나 프로그램으로 구현할 수 있습니다.
2. 일관성: 모든 데이터를 한 번에 처리하므로 데이터 일관성을 유지하기 쉽습니다.
3. 성능: 대량 데이터를 한꺼번에 처리하기 때문에, 최적화된 SQL 쿼리나 데이터베이스 작업을 통해 빠르게 처리할 수 있습니다.

단점

1. 확장성 부족: 배치 작업은 단일 서버에서 실행되는 경우가 많으며, 확장성이 제한적일 수 있습니다.
2. 비동기 처리 부족: 배치 작업은 보통 일정한 시간에 실행되므로, 실시간 데이터 처리에는 적합하지 않습니다.
3. 장애 시 복구 어려움: 배치 작업이 중간에 실패하면 전체 작업을 다시 시작해야 할 수 있습니다.

언제 배치 처리를 사용하는 것이 좋을까?

1. 데이터 일괄 처리: 하루에 한 번, 주간, 월간 등의 주기로 대량의 데이터를 처리해야 하는 경우.
2. 데이터 일관성 유지: 처리 중 데이터 일관성을 유지해야 하거나, 한꺼번에 모든 데이터를 업데이트해야 하는 경우.
3. 단순성: 처리 로직이 복잡하지 않고, 단순한 일괄 작업으로 해결할 수 있는 경우.

 

 

 

https://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html

https://aws.amazon.com/ko/blogs/korea/getting-started-with-spring-boot-on-aws/