SQS
- 소비자가 SQS 대기열에서부터 요청 메시지를 보내고 데이터를 끌어옵니다.
- 데이터가 처리된 이후에 소비자는 대기열에서 해당 데이터를 삭제하여 다른 소비자가 다시는 읽을 수 없게 해야 합니다.
- 원하는 만큼의 작업자 즉 소비자를 가질 수 있고 대기열에서 모든 메시지를 소비하고 삭제하도록 모든 작업자가 함께 작업합니다.
- 관리형 서비스이므로 미리 처리량을 프로비저닝할 필요 없고 방대한 수의 메시지를 빠르게 스케일링할 수 있습니다.
- 메시지 순서를 보장하려면 FIFO 대기열이라고 하는 선입 선출 방식을 사용해야 합니다.
- 또한 개별 메시지 지연 능력이 있어서 특정 시간 후에 메시지를 확인하도록 할 수 있습니다. 예를 들어 30초 후에 대기열의 소비자가 메시지를 확인하도록 할 수도 있습니다.
SQS Request-Response Systems
Requesters는 여러 생산자가 될 수도 있으며 이들이 모든 요청을 요청 대기열로 보냅니다. 이렇게 해서 Requesters와 Responders를 분리합니다. 그리고 중간에서 SQS를 이용하는 방식으로 요청 및 응답의 양을 스케일링할 수 있습니다. Responders가 있는 곳은 Auto Scaling Group으로 SQS 대기열에서 실행 중인 애플리케이션이 됩니다. 그리고 Requesters에 응답하는데 요청 받은 대기열을 사용하는 것이 아니라 또 다른 대기열에 응답을 넣는 방법을 사용합니다. 여기서 핵심은 Requesters가 메시지를 SQS 대기열에 보낼 때 상호 관련 ID를 함께 보내는데 그 ID는 요청 번호와 요청의 내용 및 응답할 대기열을 나타냅니다. 즉 이 메시지를 받으면 "응답 대기열 1로 응답하세요"와 같은 뜻이 됩니다. 그럼 이제 Responders는 요청 대기열을 읽고 해당 요청을 처리해서 응답을 생성합니다. 응답을 생성하려는데 대기열이 존재하지 않으면 응답 대기열1이라는 대기열을 만듭니다. 그리고 그 대기열로 응답을 보내면서 이전의 상호 관련 ID를 함께 전송합니다. 이렇게 하면 Requesters는 각각 어떤 응답이 어떤 요청에 대응하는지 알 수 있고 응답 페이로드도 이해할 수 있게 됩니다.이 아키텍처에서 중요한 것은 중간에 확장 가능한 백엔드(응답 대기열, Queue)가 있어서 수많은 다양한 요청과 수많은 다양한 응답을 전송할 수 있게 해주면서도 대상 시스템에 과부하를 주지 않는다는 점입니다.
시험에서 요청 응답 시스템을 어떻게 시행하는지 묻는다면 SQS Temporary Queue Client 즉, SQS 임시 대기열 클라이언트가 답이 됩니다. 이는 AWS에서 직접 생성한 사용 가능한 클라이언트이고 동시에 Java 클라이언트입니다. 이 클라이언트를 사용함으로써 이 패턴의 시행 세부 사항을 걱정할 필요가 없게 됩니다.
SNS
- Pub/SUb 모델이라고 하며 여러 구독자에 데이터를 푸시하면 보내는 메시지 사본을 모두가 수신할 수 있습니다.
- SNS 토픽 당 최대 구독자는 12,500,000명이고 데이터가 SNS로 보내진 후에는 더 이상 지속되지 않습니다. 다시 말해, 데이터가 전달되지 않는 경우 손실될 가능성이 있습니다. 토픽은 100,000개로 제한됩니다. 처리량을 프로비저닝할 필요 없고 SQS와 결합하는 것도 가능하며 팬 아웃 아키텍처 패턴을 사용해 SNS를 SQS와 결합할 수 있습니다.
- SNS FIFO 토픽을 SQS FIFO 대기열이 있는 SNS와 결합할 수 있습니다.
SNS + SQS: Fan out
예를 들어, 구매 서비스가 두 개의 SQS 대기열로 메시지를 보내고 싶은데 직접 보내느 대신에 하나의 메시지를 SNS 주제로 전송하고 대기열들은 SNS 주제의 구독자가 됩니다. 그렇게 함으로써, 사기 탐지 서비스와 선적 서비스가 각각의 SQS 대기열로부터 모든 메시지를 읽을 수 있는 것입니다. 팬아웃 패턴은 완전히 분리된 모델이고 데이터 손실이 전혀 없으며 장시간에 걸쳐 더 많은 SQS 대기열을 SNS 주제의 구독자로 추가할 수 있습니다.
Kinesis
Kinesis Data Streams
- 데이터 스트림으로 스트리밍 데이터를 수집합니다.
Kinesis Data Firehose
- 데이터 전송 스트림으로 스트리밍 데이터를 처리 및 전송합니다.
- Source:
Kinesis Data Streams,Direct PUT- Destination:
Amazon OpenSearch Service,Redshift,S3,HTTP Endpoint- 3rd party Destination: Coralogix, Datadog, Dynatrace, Honeycomb, LogicMonitor, MongoDB Cloud, New Relice, Splunk, Sumo Logic
Kinesis Data Analytics
- 데이터 분석 애플리케이션을 사용하여 스트리밍 데이터를 분석합니다.
소비 매커니즘의 향상된 팬아웃의 경우 Kinesis가 소비자에 데이터를 푸시할 수 있으므로 각 소비자 샤드당 1초에 2MB를 얻습니다. 다시 말해 처리량이 후러씬 늘어나고 Kinesis 스트림에서 읽을 수 있는 애플리케이션의 양도 늘어납니다.
Kinesis 데이터 스트림 안에 데이터가 지속되니 다시 재생할 수도 있습니다. 따라서 Kinesis는 실시간 빅데이터, 분석, ETL에 사용됩니다.
샤드 레벨에서 순서가 지정되므로 미리 Kinesis 데이터 스트림당 필요한 샤드를 지정해야 합니다. 그러므로 직접 샤드를 스케일링해야 합니다.
데이터는 X일 후에 만료되는데 기록 시점에서 데이터 보존 중 1일과 365일 사이에 해당합니다. 또한 처리량을 프로비저닝해야 하며 Kinesis는 샤드로 구성되어 있어 처리량이 많아질수록 더 많은 샤드를 필요로 합니다. 즉 처리량을 늘리려면 샤드를 추가해야 하며 여기서는 오토 스케일링을 사용할 수 없습니다.
Amazon MQ
온프레미스에서 클라우드로 SQS나 SNS를 사용하는 애플리케이션을 마이그레이션할 때 전부 재설계를 하는 대신 메시지 대기열을 클라우드로 그냥 옮기고 싶을 수 있습니다. 그러기 위해 Amazon MQ를 사용합니다. Amazon MQ는 클라우드에서 Apache ActiveMQ를 관리합니다. 온프레미스에서 클라우드로 애플리케이션을 마이그레이션할 때 그 애플리케이션이 MQTT나 MQP 같은 표준 프로토콜을 사용한다면 Amazon MQ를 사용해야 합니다.
- 일년 중 최대 세일 기간인 블랙 프라이데이를 준비하고 있는 전자 상거래 웹사이트가 있습니다. 트래픽은 100배가 증가할 것으로 예상됩니다. 이 웹사이트는 이미 SQS 표준 대기열을 사용하고 있습니다. SQS 대기열은 어떻게 준비해야 할까요 ?
- A. AWS 지원 센터에 연락해 SQS 표준 대기열을 준비해줄 것을 요청
- B. SQS 대기열에 오토 스케일링 활성화
- C. SQS 대기열 용량 늘리기
D. SQS이 자동으로 스케일링해줄 것이므로 아무 조치도 취하지 않음
- SQS 메시지가 SQS 대기열에 게시된 지 5분이 지난 후에만 소비자들에 의해 처리되도록 하기 위해서는 어떻게 해야 할까요 ?
A. DelaySeconds 파라미터 늘리기- B. 가시성 시간초과 변경
- C. 롱 폴링 활성화
- D. Amazon SQS Extended Client 사용
✅ SQS 가시성 시간초과는 Amazon SQS가 다른 소비자들의 메시지 재수신 및 재처리를 막는 기간이며 가시성 시간초과는 대기열에서 소모된 메시지만을 감춤 처리합니다. (기본: 30초, 최소: 0초, 최대: 12시간)
✅ SQS 대기열 지연은 Amazon SQS가 소비자들에게 새로운 SQS 메시지가 보이지 않도록 유지하는 기간입니다. SQS 대기열 지연은 대기열로 처음 추가된 메시지를 감춤 처리합니다. (기본: 0분, 최대 15분)
- 소비자들이 한 번에 10개의 메시지를 폴링하고 1분 내로 이에 대한 처리를 완료하는 SQS 대기열이 있습니다. 잠시 후, 여러분은 동일한 SQS 메시지를 다른 소비자들도 수신하여 메시지가 한 번 이상 처리되었음을 알게 되었습니다. 이 문제를 해결하기 위해서는 어떻게 해야 할까요 ?
- A. 롱 폴링 활성화
- B. 메시지 생성 시 메시지에 DelaySeconds 파라미터 추가
C. 가시성 시간 초과 늘리기- D. 가시성 시간 초과 줄이기
✅ SQS 가시성 시간 초과는 Amazon SQS가 다른 소비자들의 메시지 재수신 및 재처리를 막는 기간입니다. 가시성 시간초과는 대기열에서 소모된 메시지만을 감춤 처리합니다. 가시성 시간초과를 증가시키면 소비자들이 더 오랜 시간 동안 메시지를 처리할 수 있게 해주며, 메시지의 중복 읽기를 방지합니다. (기본: 30초, 최소: 0초, 최대: 12시간)
- SQS 표준 대기열에서 메시지를 처리하던, 오토 스케일링 그룹의 관리 하에 있는 EC2 인스턴스 플릿(소비자)이 있습니다. 최근 많은 메시지들이 두 번 처리되었다는 점을 발견해 조사를 해본 결과, 이 메시지들을 성공적으로 처리할 수 없음을 알게 되었습니다. 이러한 메시지 실패의 원인은 어떻게 해결(디버깅)해야 할까요 ?
- A. SQS 표준 대기열
B. SQS 데드 레터 대기열- C. SQS 대기열 지연
- D. SQS FIFO 대기열
✅ SQS 데드 레터 대기열은 다른 SQS 대기열(소스 대기열)들이 처리(소비)될 수 없는 메시지를 보낼 수 있는 곳입니다. 이를 통해 문제가 되는 메시지들을 분리하여 처리가 실패한 이유를 디버깅할 수 있으므로, 디버깅에 유용합니다.
- 다음 중 어떤 SQS 대기열 유형을 사용해야 메시지가 순차적으로, 단 한 번만 처리될까요 ?
- A. SQS 표준 대기열
- B. SQS 데드 레터 대기열
- C. SQS 대기열 지연
D. SQS FIFO 대기열
✅ SQS FIFO(First-In-First-Out) 대기열은 SQS 표준 대기열의 모든 기능을 가지고 있으며, 다음과 같은 두 기능이 추가됩니다. 첫 번째, 어떤 메시지를 보내고 수신했는지에 대한 오더가 엄격하게 보존됩니다. 메시지는 한 번만 전송되며, 소비자가 해당 메시지를 처리하고 삭제할 때까지 사용할 수 있습니다. 두 번째, 복제된 메시지는 대기열에 들어오지 않습니다.
- 3개의 서로 다른 애플리케이션으로 동일한 메시지를 보내려 합니다. 3개의 애플리케이션 모두 SQS를 사용하고 있습니다. 이를 위해 어떤 접근법을 선택하는 것이 가장 적절할까요 ?
- A. SQS 복제 기능을 사용
B. SNS + SQS 팬아웃 패턴을 사용- C. 3개의 SQS 대기열에 개별적으로 메시지 전송하기
✅ 흔히 사용되는 패턴으로, 단 하나의 메시지를 SNS 주제로 전송한 뒤, 다수의 SQS 대기열로 팬 아웃합니다. 이 방식에는 다음의 기능이 포함되어 있습니다. 1. 데이터 손실이 없으며, 향후 더 많은 SQS 대기열(더 많은 애플리케이션)을 추가할 수 있습니다.
- 한 Kinesis Data Streams에 6개의 샤드가 프로비저닝되어 있습니다. 이 데이터 스트림은 보통 5MB/초의 속도로 데이터를 수신하며, 8MB/초의 속도로 데이터를 전송합니다. 이따금 트래픽이 2배까지 증가하여 ProvisionedThroughputExceedException 예외 처리가 발생합니다. 이 문제를 해결하려면 어떻게 해야 할까요 ?
A. 더 많은 샤드 추가- B. Kinesis 복제 활성화
- C. SQS를 Kinesis의 버퍼로 사용
✅ Kinesis Data Streams의 용량 제한은 데이터 스트림 내에 있는 샤드의 수에 의해 결정됩니다. 이러한 제한은 데이터 처리량, 혹은 읽기 데이터 호출에 의해 초과될 수 있습니다. 각 샤드는 1MB/초 만큼의 들어오는 데이터와 2MB/초 만큼의 나가는 데이터를 허용합니다. 충분한 용량을 제공하려면 데이터 스트림의 샤드 수를 증가시켜야 합니다.
- 한 웹사이트 내에서 사용자들이 클릭하는 순서, 사용자들이 보내는 시간 및 탐색이 어디에서 시작되고 어떻게 종료되는지 등의 클릭스트림 데이터를 분석하고자 합니다. Amazon Kinesis를 사용하기로 했고, 웹사이트가 이러한 클릭스트림 데이터를 Kinesis Data Stream로 전송하도록 구성한 상태입니다. Kinesis Data Stream으로 전송된 데이터를 확인하던 중, 데이터가 순서대로 정렬되어 있지 않으며 한 개별 사용자로부터 온 데이터가 여러 샤드에 분산되어 있다는 것을 알게 되었습니다. 이 경우, 어떻게 문제를 해결해야 할까요 ?
- A. 샤드가 너무 많으므로 오직 1개의 샤드만 사용해야 함.
- B. 다수의 소비자를 사용해서는 안되므로, 오직 하나만을 사용하면 데이터가 재정렬될 것
C. Kinesis로 보내지는 각 레코드에 사용자의 신원을 나타내는 파티션 키를 추가해야 함
✅ Kinesis Data Streams는 각 데이터 레코드에 연결된 파티션 키를 사용해 주어진 데이터 레코드가 어느 샤드에 속하는지 판단합니다. 각 사용자의 신원을 파티션 키로 사용할 경우, 각 유저에 대한 데이터가 정렬되어 동일한 샤드로 보낼 수 있습니다.
- 데이터 스트림에 대한 실시간 분석을 수행하려는 경우, 다음 AWS 서비스 중 어느 것이 가장 적절할까요 ?
- A. Amazon SQS
- B. Amazon SNS
C. Amazon Kinesis Data Analytics- D. Amazon Kinesis Data Firehose
✅ Kinesis Data Analytics를 사용하려면 Kinesis Data Streams를 기반 데이터 소스로 사용해야 합니다.
- 대량의 실시간 데이터를 생성하는 애플리케이션을 실행 중이며, 이 데이터를 S3와 Redshift로 로딩하려 합니다. 또한 이 데이터들은 목적지에 도달하기 전에 변환되어야 합니다. 이를 위해, 선택할 수 있는 가장 적절한 아키텍처는 무엇인가요 ?
- A. SQS + AWS Lambda
- B. SNS + HTTP Endpoint
C. Kinesis Data Streams + Kinesis Data Firehose
✅ Kinesis Data Streams와 Kinesis Data Firehose 조합은 실시간 데이터를 S3와 Redshift로 로딩하기 위한 완벽한 기법 조합입니다. Kinesis Data Firehose는 AWS Lambda를 사용하는 커스텀 데이터 변환을 지원하기도 합니다.
- 다음 중 AWS SNS를 지원하지 않는 구독자를 고르세요.
A. Amazon Kinesis- B. Amazon SQS
- C. HTTP(S) Endpoint
- D. AWS Lambda
✅ Amazon SNS가 메시지를 게시할 수 있는 엔드 포인트는 다음과 같습니다. (HTTP(S), SQS, Lambda, 모바일 푸시, 이메일, SMS)
- 다음 중 사용자들에게 이메일 알림을 보내려 할 때 도움이 되는 AWS 서비스는 무엇인가요 ?
- A. AWS Lambda를 갖는 Amazon SQS
B. Amazon SNS- C. Amazon Kinesis
- 여러 마이크로 서비스 애플리케이션을 온프레미스로 실행 중이며, 이들은 MQTT 프로토콜을 지원하는 메시지 브로커를 사용해 통신하고 있습니다. 애플리케이션을 새로 엔지니어링하거나 코드를 수정하는 작업 없이, 이 애플리케이션들을 AWS로 이전시키려 합니다. MQTT 프로토콜을 지원하는 관리 메시지 브로커를 활용하기 위해서는 다음 중 어떤 AWS 서비스를 사용해야 할까요 ?
- A. Amazon SQS
- B. Amazon SNS
- C. Amazon Kinesis
D. Amazon MQ
✅ Amazon MQ는 JMS, NMS와 같은 업계 표준 API를 지원하며 AMQP, STOMP, MQTT 및 WebSocket 등을 비롯한 메시징 프로토콜을 지원합니다.
