AWS Section 19-1. AWS 통합 및 메시징 : SQS, SNS 및 Kinesis

어플리케이션 여러 개를 배포할 때, 서로 간의 커뮤니케이션을 하는 방식을 고려하는 것이 중요하다.

여기에는 동기 및 비동기 통신 방식이 있는데, 각각의 방식은 특정 상황에 따라 적합하게 선택될 수 있다.

 

1. 동기(Synchronous) 통신 방식

• 동기 통신 방식은 애플리케이션 간 직접 연결을 통해 이루어진다.
• 구매 서비스가 배송 서비스와 직접 소통하는 경우가 이에 해당한다.
• 이 방식에서는 요청-응답 흐름이 있어, 요청이 완료되기 전까지 호출한 애플리케이션은 대기해야 한다. 따라서 실시간 데이터 교환이 필요한 경우에 적합하지만, 서비스가 긴밀하게 연결되므로 결합도가 높아져 유지보수가 어려울 수 있다.

 

2. 비동기(Asynchronous) / 이벤트 기반 통신 방식

• 비동기 통신은 중간 미들웨어를 통해 이루어진다.
• 여기서 애플리케이션들은 서로 직접적으로 연결되지 않으며, 메시지 대기열을 통해 메시지를 주고받는다.
• 예를 들어, 구매 서비스가 메시지를 'queue'에 전달하면, 배송 서비스는 해당 대기열에서 메시지를 가져와 처리할 수 있다. 이러한 방식은 독립적인 확장이 가능하며, 지연을 허용할 수 있는 애플리케이션 간에 이상적이다.
• 비동기 통신의 한 예로 Amazon SQS를 들 수 있다.
  • SQS는 메시지 대기열을 통해 애플리케이션 간의 분리를 지원하고, 스케일링 및 결합도 감소에 유용하다.
  • 대기열에는 메시지를 생산자가 보내고, 소비자가 polling을 통해 해당 메시지를 가져가게 된다.
  • SQS에서는 여러 소비자가 메시지를 처리하며, 처리가 끝나면 DeleteMessage API로 메시지를 대기열에서 삭제해 중복 처리를 방지한다.

 

AWS 서비스 활용

• SQS (Simple Queue Service
  • 대기열을 통해 애플리케이션을 분리하고 비동기 커뮤니케이션을 가능하게 한다.
• SNS (Simple Notification Service)
  • pub/sub 모델을 통해 메시지를 여러 구독자에게 전송하는 방식이다.
• Kinesis
  • 실시간 스트리밍과 대용량 데이터를 처리하는 데 사용된다.

확장성

• 이 세 가지 서비스(SQS, SNS, Kinesis)를 사용하면 애플리케이션을 독립적으로 확장할 수 있으며, 큰 트래픽 변화에도 잘 대응할 수 있다.

 

Amazon SQS

• SQS의 핵심은 대기열. AWS에서 제공하는 간단한 대기열 서비스로, 메시지를 대기열에 저장하고, 그 메시지를 처리할 애플리케이션을 분리하는 버퍼 역할을 한다.
• '생산자'는 메시지를 SQS 대기열에 전송하며, 소비자는 대기열에서 메시지를 폴링(polling)하여 처리한다.

• 메시지를 대기열에 넣은 후, '소비자'는 주기적으로 대기열에서 메시지를 확인하고 처리한다. 메시지를 처리한 후에는 대기열에서 해당 메시지를 삭제한다.
• SQS는 동시에 여러 생산자와 소비자를 지원하며, 생산자와 소비자를 분리함으로써 애플리케이션의 독립성을 유지하고 확장성을 향상시킨다.

 

SQS의 주요 특징

• 무제한 처리량: 초당 무한한 양의 메시지를 대기열에 보내거나 수신할 수 있다.
• 메시지 보존 기간: 기본적으로 메시지는 4일 동안 대기열에 남아있고, 최대 14일까지 설정할 수 있다. 이 기간 내에 메시지를 처리하지 않으면 삭제된다.
• 짧은 지연 시간: 메시지를 전송하거나 받을 때 10밀리초 이내에 응답을 받는다.
• 메시지 크기 제한: 한 메시지당 최대 256KB까지만 허용된다.
• 중복 전송: SQS는 적어도 한 번은 메시지를 전달하는 방식을 사용하기 때문에 중복 메시지가 발생할 수 있다.

 

SQS - Standard Queue

• AWS 에서 제공하는 가장 오래된 서비스이다..
• 완전관리형 서비스이며, 애플리케이션을 분리하는데 사용된다.
• 무제한 처리량을 얻을 수 있다.
• 원하는 만큼의 메시지를 큐로 보낼 수 있다.
• 처리량에 제한이 없고 대기열에 있는 메시지 수에도 제한이 없다.
• 각 메시지는 수명이 짧다.
  • 기본값으로 4일에서 14일까지 남아있다.
  • 그동안 처리되지 않으면 소실된다.
• 지연 시간이 짧아서 SQS는 메시지를 보내거나 SQS에서 메시지를 게시 및 수신 시 10ms초 이내로 빠르게 응답을 받는다.
• SQS로 보내는 메시지는 개당 최대 256kb까지 가능하다.
• 메세지는 중복이 있을 수 있다
• 순서에 맞지 않는 메시지가 존재할 수도 있다.

 

SQS - 메시지 전송자 ( Producing Messages )

• 최대 256kb의 메시지가 SQS로 전송된다.
• 전송자는 SDK 키트를 사용하여 SQS로 메시지를 보낸다. ( SQS에 메시지를 보내는 API  : sendMessage API)
• 수신자가 메시지를 읽고 삭제할 때까지 SQS 대기열에 유지된다. (4일 ~ 14일)
• 주문 프로세스를 예시로 들 수 있는데 주문이 발생했을 때, order id, customer id, 주소 등등의 정보를 SQS로 보낸다 => 이후 수신자가 정보를 받고 처리한다.

 

SQS - 메시지 수신자 ( Consuming Messages )

• Ec2, 온프레미스, Lambda 등에서 실행될 수 있다.
• 만약 SQS에 대기 중인 메시지가 있다면, 대기중인 메시지가 있다는 응답을 받는다.
• 소비자는 한 번에 최대 10개의 메시지를 받을 수 있다. 

• 만일 소비자에 의해 충분히 빠르게 처리되지 않는다면, 다른 소비자가 수신하게 된다. 
  • >> 적어도 한 번은 전송이 된다
• 소비자가 메시지를 처리하면 반드시 DeleteMessage API로 대기열에서 삭제해야 한다.
  그렇지 않다면 다른 소비자에게 메시지가 전송될 수도 있다.
• SQS 대기열에 너무 많은 메시지가 있어 처리량을 늘려야 한다면,
  소비자를 추가하고 수평 확장을 수행해서 처리량을 개선해야 한다.

 

SQS with ASG

ASG는 SQS를 사용하는 완벽한 사례로 적용된다.

• 소비자가 ASG 내부에서 EC2 인스턴스를 실행하고 SQS에서 메시지를 풀링한다.
• 대기열의 길이는 CloudWatch Metric - Queue Length에서
  ApproximateNumberOfMessages를 통해 알 수 있다.
  • 알림을 설정할 수 있다,
  • 대기열의 길이가 특정 수준을 넘어가면, 알림을 보내 ASG 용량을 증가시킬 수 있다.

 

SQS  to decouple between application tiers (계층간 분리를 위한 SQS)

• SQS는 어플리케이션 계층 간에 분리를 위해서 사용된다.

• 비디오를 처리 예시
  • 프론트에서 요청을 받고 비디오를 처리한 후 S3 버킷에 삽입한다.
  • 처리 시간이 오래 걸릴 수 있고, 프론트에서 이를 처리하려면 웹사이트 속도가 느려질 수 있다.
  • 애플리케이션을 분리해서 실제 파일 처리를 다른 애플리케이션에 수행하도록 한다.
    • 비디오 처리 요청이 들어올 때 SQS 대기열로 메시지를 전송하고, 백엔드에서 큐에 들어있는 메시지를 수신해 S3에 삽입하면 웹사이트 속도 지연 문제가 없을 것이다.

 

SQS - Security

• HTTPS 프로토콜을 사용하여 메시지를 보내고 생성하면서 In-flight 암호화를 실시한다. (전송 중 암호화)
• KMS 키를 사용하여 대기 상황에서 미사용 암호화를 할 수 있다.
• 클라이언트 측 암호화를 할 수도 있다. (SQS에서 지원 X)
  • 클라이언트가 암호화 및 암호 해독을 수행 가능해야 할 수 있다.
• Access Controls를 위해 IAM 정책을 사용해 SQS API를 제한할 수 있다. 

• SQS 액세스 정책(similar to S3 bucket policies)
  • SQS 대기열에 대한 교차 계정 액세스를 수행하려는 경우
  • SNS 같은 다른 서비스가 SQS 대기열에 S3 이벤트 같은 것을 쓸 수 있도록 허용하려는 경우에 유용하다.

 

SQS - queue Access Policy

1. SQS queue 액세스 정책은 S3 버킷 정책과 굉장히 유사하다.
2. 1. Cross Account Access:
   • 어떤 계정에 SQS가 있고 다른 계정의 EC2가 그 대기열에 액세스해야 한다고 가정해보자.
   • 다른 계정의 큐에서 메시지를 가져오기 위해서는  대기열 액세스 정책을 생성하고, 첫 번째 계정의 SQS 대기열에 첨부를 해야한다.
   • 정책은 아래와 같ㅌ다.

적용 대상에 EC2 인스턴스가 있는 다른 계정을 포함

 

 

• 2. publish S3 Event Notifications To SQS queue
  • S3의 이벤트 알림을 큐에 넣는 것
  • SQS 대기열에 자동으로 메세지를 보낸다. 
    
    • 마찬가지로 SQS 대기열은 S3 버킷이 메시지를 보낼 수 있는 권한을 설정해야 한다.

 

 

 

SQS - Message Visibility Timeout

• 기능: 소비자가 메시지를 가져가면 해당 메시지는 일정 시간 동안 다른 소비자에게 보이지 않는다.
• 기본 설정: 기본 가시성 타임아웃은 30초이며, 이 시간이 지나면 메시지가 다시 큐에 나타난다.
• API: ChangeMessageVisibility API를 통해 소비자가 더 많은 시간이 필요할 경우 타임아웃 시간을 연장 가능하다.
• 주의사항: 타임아웃이 너무 길면 오류 발생 시 재처리에 시간이 걸리고, 너무 짧으면 중복 처리 가능성 증가한다.

 

 

SQS - 실패 메시지 대기열 (Dead Letter Queue, DLQ)

• 정해진 횟수 내에 메시지가 처리되지 않으면 DLQ로 이동하여 무한 재시도를 방지한다.
• 최대 수신 임계값을 설정하여 횟수 초과 시 DLQ로 메시지 이동한다.
• 문제가 반복되는 메시지를 격리하여 디버깅에 활용 가능하다.
• FIFO 큐는 DLQ도 FIFO, 표준 큐는 DLQ도 표준 큐여야 한다.
•  메시지의 문제를 파악할 수 있도록 14일 정도의 보관 기간 설정 권장한다.

 

SQS DLQ - Redrive to Source

• DLQ에 있는 실패 메시지를 원본 큐로 재전송하여 문제를 해결 후 재처리 가능하다.
• 오류를 수정한 후, DLQ 메시지를 원래 큐로 이동시켜 다시 소비자에게 할당한다.

 

 

 

SQS - Delay Queue (지연 대기열)

• 메시지가 대기열에 들어간 후 소비자가 바로 볼 수 없도록 지연시키는 기능이다.
• 기본 지연 시간: 0초 (즉시 표시), 최대 15분까지 설정 가능하다.
• 설정 방법
  • 전체 대기열에 적용하려면 큐 단위에서 지연 시간 설정.
  • 개별 메시지마다 지연 시간을 다르게 설정하려면 DelaySeconds 파라미터를 사용하여 지정 가능.

 

SQS - Long Polling (롱 폴링)

• 대기열이 비어있을 때 소비자가 메시지 요청 시 일정 시간 동안 기다리게 하는 기능이다.
• API 호출 수를 줄여 비용 절감 및 CPU 연산 절약하는 것이 목적이다.
• 1~20초 사이로 설정 가능, 보통 20초를 권장한다.
• 설정 방법
  • 대기열 레벨에서 활성화 가능하다.
  • 또는, API 호출 시 WaitTimeSeconds 파라미터를 통해 개별 요청에서 설정 가능하다.

 

 

SQS Extended Client (확장 클라이언트)

• SQS의 최대 메시지 크기 제한(256KB)을 넘어 대용량 메시지를 처리할 수 있도록 Amazon S3와 연계하여 사용한다.
• 작동 원리
  • 대용량 메시지를 S3에 저장하고, SQS에는 S3 버킷의 위치 정보(메타데이터)를 저장한다.
  • 소비자가 SQS Extended Client 라이브러리를 사용하여 SQS로부터 메타데이터를 수신 후 S3에서 대용량 데이터를 가져와 처리한다.
• 비디오 파일 등 대용량 데이터를 처리할 때 유용하다

 

 

필수 API

1. CreateQueue(MessageRetentionPeriod): 대기열을 생성하며, 메시지 보관 기간을 설정.
2. DeleteQueue: 대기열 및 해당 대기열의 모든 메시지를 삭제.
3. PurgeQueue: 대기열 내 모든 메시지를 삭제.
4. SendMessage(DelaySeconds): 메시지를 대기열로 전송하며, 개별 메시지 지연 시간을 설정 가능.
5. ReceiveMessage: 메시지를 폴링하여 수신.
6. DeleteMessage: 개별 메시지를 삭제.
7. MaxNumberOfMessages: 한 번에 수신할 최대 메시지 수 (기본값 1, 최대 10).
8. ReceiveMessageWaitTimeSeconds: 롱 폴링 대기 시간을 설정.
9. ChangeMessageVisibility: 가시성 타임아웃을 연장.

Tip: SendMessage, DeleteMessage, ChangeMessageVisibility API를 묶어 사용하여 API 호출 수를 줄여 비용 절감 효과를 얻을 수 있다.

 

 

SQS - FIFO Queue

• FIFO는 선입선출(FIFO: First-In-First-Out) 방식을 보장하는 큐로, 먼저 들어간 메시지가 먼저 처리된다. 이는 순서가 보장되는 구조로, 표준 대기열보다 더욱 엄격하게 메시지 순서를 유지한다.
• 처리량 제한: FIFO 큐는 순서를 보장하기 위해 처리량이 제한된다.
  • 배치 처리 없이는 초당 300개의 메시지를 처리하고,
  • 배치 처리 시에는 초당 최대 3000개의 메시지를 처리할 수 있다.
• 중복 제거 기능: FIFO 큐는 메시지를 정확히 한 번만 보내도록 중복 제거 기능을 제공하여, 동일한 메시지가 여러 번 처리되지 않도록 한다. 순서를 보장하고 중복을 피해야 할 때는 FIFO 큐를 사용한다.

 

SQS FIFO - Deduplication (중복 제거)

• 중복 제거는 메시지가 5분 내에 동일하게 재전송될 경우 적용된다. 동일한 메시지가 5분 이내에 다시 전송되면 두 번째 메시지는 거부된다.
• 중복 제거 방법:
  1. 내용 기반 중복 제거: SQS는 메시지 본문을 SHA-256 알고리즘으로 해시하여 동일한 메시지 내용의 중복을 방지한다. 동일한 메시지 본문이 전송되면 해시 값이 같아지므로 중복 메시지가 제거된다.
  2. Deduplication ID 사용: 메시지를 전송할 때 고유한 중복 제거 ID를 직접 지정할 수 있다. 동일한 Deduplication ID를 가진 메시지가 두 번 전송될 경우, 두 번째 메시지는 자동으로 거부된다.

 

SQS FIFO - Message Grouping (메시지 그룹화)

• MessageGroupID:
  • SQS FIFO 큐로 메시지를 전송할 때 MessageGroupID를 동일하게 설정하면, 해당 그룹의 메시지는 오직 한 명의 소비자에게만 순서대로 전달된다. 이는 메시지 순서를 보장해야 할 때 유용하다.
• 그룹별 정렬
  •  여러 메시지 그룹 ID를 사용하면 그룹별로 병렬 처리가 가능하다. 각 그룹 ID에 속한 메시지는 해당 그룹 내에서 순서대로 정렬되며, 서로 다른 그룹 ID는 별개의 소비자에게 처리된다.
• 동일한 MessageGroupID를 가진 메시지는 내부에서 순서가 정렬된 채로 해당 그룹 내에서 순차적으로 처리된다.

 

Amazon SNS

• Amazon SNS는 Pub/Sub (게시/구독) 패턴을 사용하여 메시지 하나를 여러 수신자에게 동시에 전달하는 서비스를 제공한다.
• 이를 통해 SNS 주제(Topic)에 메시지를 게시하면, 해당 주제를 구독한 모든 수신자가 메시지를 받을 수 있다.
• 예를 들어 구매 시 SNS를 통해 알림 메시지를 전송하면, 구독한 다양한 서비스(이메일 알림, 배송 서비스 등)와 SQS 대기열에 동일한 메시지를 전달할 수 있다.
• 주제별 최대 1,250만 구독자가 가능하며, 계정당 최대 10만 개의 주제를 생성할 수 있다.

 

SNS에서 다양한 AWS 서비스들에서 메시지를 수신하기도 한다.

 

SNS 게시 방법

1. SDK를 통한 게시: AWS SDK를 사용해 주제에 메시지를 게시한다.
   • 주제와 구독자를 생성하고, 주제에 메시지를 게시한다.
   • 구독자는 해당 주제의 모든 메시지를 수신한다.
2. Direct Publish (모바일 앱 전용) : 모바일 앱 SDK를 통해 플랫폼 애플리케이션을 생성하고, 엔드포인트에 직접 메시지를 전송한다.
   • 지원 플랫폼: Google GCM, Apple APNS 등.
3. 다양한 서비스와의 통합
   • 이메일, SMS, HTTPS 엔드포인트, SQS 대기열, AWS Lambda 함수, Kinesis Data Firehose를 통해 S3 또는 Redshift로 메시지를 전송 가능하다.

 

SNS - 보안

• 암호화
  • 전송 중: HTTPS API를 사용하여 전송 데이터 암호화.
  • 저장 중: KMS(Key Management Service)를 통해 데이터 암호화.
  • 클라이언트 측 암호화: 클라이언트가 직접 암호화와 복호화를 수행할 수 있다.
• 액세스 제어
  • IAM 정책으로 SNS API 접근을 제어한다.
  • SNS 액세스 정책: S3 버킷 정책과 유사하게 설정 가능. 이를 통해 SNS 주제에 대한 교차 계정 접근 및 다른 서비스에서의 메시지 게시 권한 부여가 가능하다.

 

 

SNS + SQS: Fan Out 패턴

• SNS의 메시지를 여러 SQS 대기열에 동시에 전송하는 방식이다.
• 장점
  • 애플리케이션에 부담을 주지 않고 메시지를 모든 구독자에게 분배할 수 있으며, 데이터 지속성, 지연 처리, 작업 재시도 등 SQS의 특성을 함께 사용할 수 있다.
• 활용
  • SNS 주제에 메시지를 게시하고, 여러 SQS 대기열을 구독자로 추가하여 수신자가 늘어나도 SNS가 모든 전송을 처리하므로 애플리케이션 부하를 줄일 수 있다.
• 권한 설정
  • SQS 대기열이 SNS로부터 메시지를 수신할 수 있도록 액세스 정책을 명확히 설정해야 한다.

 

SNS to Amazon S3 through Kinesis Data Firehose

• SNS는 Kinesis Data Firehose(KDF)와 통합되어 있어, SNS에서 KDF로 메시지를 전송하고 KDF가 데이터를 S3 또는 Redshift 등 다양한 저장소에 저장할 수 있다.
• SNS 메시지를 여러 목적지에 안전하게 전송하는 데 사용되며, 데이터 저장 범위를 확장할 수 있다.

 

 

SNS - FIFO Topic

• SNS는 메시지를 선입선출 방식으로 전달하는 FIFO 주제를 지원한다.
• SQS FIFO 대기열과의 결합
  • 구독자가 SQS FIFO 대기열일 경우, 메시지 그룹 ID와 중복 제거 기능을 활용하여 메시지를 순서대로 안전하게 전송할 수 있다.
• Fan Out + FIFO 전략
  • 정렬된 메시지를 다수의 SQS FIFO 구독자에게 보내며, 중복 방지 및 순서를 보장한다.

 

SNS - Message Filtering (메시지 필터링)

• SNS 주제 구독자에게 전송할 메시지를 필터링하는 JSON 정책을 설정할 수 있다.
• 필터링 조건이 없을 경우 모든 메시지를 수신하며, 필터링을 설정하여 특정 조건을 만족하는 메시지만 수신할 수 있다.
• 구독자마다 다른 필터링 조건을 설정할 수 있어, 구독자의 목적에 맞는 메시지만 전달 가능하다.
  • 예를 들어, 상태(state) 필드로 필터링하여 특정 상태의 메시지만 전달하는 방식으로 설정할 수 있다.