AWS Certified Solutions Architect Associate [12] AWS Integration & Messaging

Overview

트래픽이 갑자기 급증하거나 아무것도 예측할 수 없을 때
일반적으로 애플리케이션을 분리하고 분리 계층(decouple)을 확장하는 것이 좋습니다.

• 대기열 모델
  • SQS
• pub/sub 모델
  • SNS
• 실시간 스트리밍 및 대용량 데이터
  • Kinesis

---

SQS

SQS

SQS - 표준(Standard) 대기열

• 가장 오래됨
• 애플리케이션 분리하는데 사용되는 완전 관리형 서비스입니다.
  
  
• 속성 :
  • 무제한 처리량
    • 즉 초당 원하는 만큼 메시지를 보낼 수 있고 대기열에도 원하는 만큼 메시지를 포함시킬 수 있습니다.
  • 메시지는 수명이 짧습니다.
    • 기본값 4일, 최대 14일
  • 지연 시간이 짧습니다.
    • SQS는 메시지를 보내거나 SQS에서 메시지를 읽을 때마다 게시 및 수신 시 10밀리초 이내로 매우 빠르게 응답을 받게 됩니다.
  • SQS의 메시지는 작아야 합니다.
    * 전송된 메시지당 256KB 미만이어야 합니다.
    
    
• 중복 메시지가 있을 수 있습니다.
• 최선의 오더라는 뜻으로 품절 메시지를 보낼 수도 있습니다.

---

SQS - 메시지 생산자

• 생산자는 SDK 소프트웨어 개발 키트를 사용하여 SQS에 메시지를 보낼 겁니다.
  • SendMessage API 사용합니다.
• 소비자가 해당 메시지를 읽고 삭제할 때까지 SQS 대기열에 유지됩니다.

EX)

패킷과 같은 오더를 처리한 다음 센터로 배송하려고 합니다.

• Order Id
• Customer Id
• 원하는 속성등의 일부 정보
  가 포함된 메시지를 SQS 대기열에 보냅니다.

• 표준 SQS는 무제한 처리량을 자랑합니다.

---

SQS - 메시지 소비자

• 소비자는 일부 코드로 작성해야 하는 애플리케이션이고
  이러한 애플리케이션은 EC2 인스턴스에서 실행될 수 있습니다.
• AWS Lambda의 람다 함수에서 실행할 수도 있습니다.
• 대기열에는 소비자가가 있고 소비자는 SQS 메시지를 폴링합니다.
  • 소비자는 아마 한 번에 최대 10개의 메세지를 받을 겁니다.
• 여러분의 코드인 소비자는 이 메시지들을 처리할 책임이 있습니다.
• 이후 소비자가 이 메시지들을 DeleteMessage API로 대기열에서 삭제합니다.

---

다중 EC2 인스턴스 소비자

• SQS 대기열은 메세지를 동시에 수신하고 처리할 소비자를 여러 개 가질 수 있습니다.
• 적어도 한번은 전송이 됩니다.
• 최선의 노력으로 메시지 순서 지정을 하는 이유입니다.
• 소비자가 메시지를 처리하면 메시지를 삭제해야 합니다.
• SQS 대기열에서
  더 많은 메시지가 있어서 처리량을 늘려야 하면
  소비자를 추가하고 수평 확장을 수행해서 처리량을 개선할 수 있습니다.

---

SQS - ASG (Auto Scaling Group)

---

SQS - 애플리케이션 계층 간에 분리

---

SQS 보안

• 암호화

  • HTTPS API를 사용하여 전송 중 암호화를 합니다.
  • KMS 키를 사용하여 미사용 암호화를 얻습니다.
  • 클라이언트가 자체적으로 암호화 및 암호 해독을 수행하는 클라이언트 측 암호화를 합니다.

• 액세스 제어

  • SQS API에 대한 액세스를 규제할 수 있습니다.

• SQS 액세스 정책

  • S3 버킷 정책과 유사합니다.
  • SQS 대기열에 대한 교차 계정 액세스를 수행하려는 경우
  • NS 혹은 Amazon S3 같은 다른 서비스가 SQS 대기열에 S3 이벤트 같은 것을 쓸 수 있도록 허용

---

SQS 대기열 액세스 정책

• 교차 계정 액세스
• S3 버킷이 있으면 이것이 이벤트 알림을 SQS 대기열에 게시

---

SQS - 메시지 가시성 시간 초과

• 소비자가 메시지를 폴링하면 그 메세지는 다른 소비자들에게 보이지 않게 됩니다.
• 기본값으로 메시지 가시성 시간 초과는 30초입니다.
• 그 말은 이 30초 동안 메시지가 처리되어야 한다는 거죠 그렇죠?
• 가시성 시간 초과 기간 내에서는 그 메시지는 다른 소비자들에게 보이지 않습니다.
• 가시성 시간 초과가 경과되고 메시지가 삭제되지 않았다면 메시지는 대기열에 다시 넣습니다.

• 가시성 시간 초과 기간 내에 메시지를 처리하지 않으면 메시지가 두 번 처리될 수도 있다는 것을 알 수 있습니다.

• 소비자가 메시지를 처리하는 데 시간이 더 필요하다는 것을 알고 있고
  해당 메시지를 두 번 처리하고 싶지 않다면
  소비자는 ChangeMessageVisibility API를 호출하여 SQS에 알려야 합니다.

  • ChangeMessageVisibility
    • 메시지를 처리하지 않아 가시성 시간 초과 기간을 벗어날 때 사용합니다.

• 기본값으로 매우 높은 값 예를 들어 시간으로 설정하면
  소비자가 충돌했을 때 이 메시지가 다시 나타날 때까지
  즉 SQS 대기열에 보이기까지 몇 시간이 걸립니다.

• 몇 초와 같이 매우 낮은 값으로 설정하면
  소비자가 어떤 이유로든 해당 메시지를
  처리할 시간이 충분하지 않으면 다른 소비자가 메시지를 여러 번 읽을 것이며
  중복 처리될 수 있습니다.

---

SQS - Dead Letter Queue

• 소비자가 가시성 시간 초과 내에 메시지를 처리하지 못하는 상태
  그러면 메시지가 자동으로 대기열로 돌아갑니다.
• 메시지를 얼마나 많이 돌아가게 할 수 있는 임계값을 설정할 수 있습니다.
• 최대 수신 임곗값을 초과하면, 메시지는 DLQ로 갑니다.
  
  
• Dead Letter Queue가 존재하는 이유?
  • 디버깅 시 유용하기 때문입니다.
• 데드 레터 대기열에 있고
  SQS 대기열이기 때문에 메시지 보관 기간에 제한이 있어서 일정 시점에서 만료됩니다.
  • 따라서 데드 레터 대기열에 14일 정도의 높은 보존 기간을 설정하는 것이 좋습니다.

---

SQS DLQ - 소스로 리드라이브

• 데드 레터 대기열 관리를 위한 기능
• 데드 레터 대기열 메시지를 사용해 무엇이 잘못되었는지 이해하는 데 도움이 되는 기능입니다.
• 메시지가 처리되지 않은 이유를 파악한 후 소비자 코드를 수정하고 메시지가 올바르게 나오는 경우,
  데드 레터 대기열에서 소스 SQS 대기열로 해당 메시지를 리드라이브합니다.

---

Delay Queue

• 대기열 지연은 소비자들이 즉각적으로 보지 못하도록 메시지를 지연시키는 것입니다.
• 15분까지 지연시킬 수 있습니다.
• 지연 파라미터의 기본값은 0초입니다.
• 매번 메시지를 보낼 때마다
  DelaySeconds 파라미터를 사용하여
  메시지별 지연 시간을 지정할 수도 있습니다.

---

Long Polling

• 예를 들어 소비자가 대기열에 메시지를 요청하는데
  대기열에 아무것도 없다면 메시지 도착을 기다리면 됩니다
  이것을 롱 폴링이라고 합니다.
• 이유 두 가지 :
  • 첫 번째는 지연 시간을 줄이기 위해서.
  • 두 번째는 SQS로 보내는 API 호출 숫자를 줄이기 위해서.
• **롱 폴링은 애플리케이션의 효율성과 대기 시간을 증가시키면서 SQS로의 API 호출 수를 감소시킵니다.
• 1초부터 20초 사이로 구성이 가능합니다.
• 구성 방법 :
  • 대기열 레벨에서 구성하여 폴링하는 아무 소비자로부터 롱 폴링을 활성화하는 방법
  • WaitTimeSeconds를 지정함으로 소비자가 스스로 롱 폴링을 하도록 선택

SQS 대기열에 대한 API 호출 수를 최적화하고
지연 시간을 줄이는 법을 묻는다면 롱 폴링을 떠올리세요

---

SQS를 통한 요청-응답 시스템

• 이 패턴을 실행하기 위해서
  • SQS Temporary Queue Client 즉, SQS 임시 대기열 클라이언트가 답입니다.
  • 이는 AWS에서 직접 생성한 사용 가능 클라이언트이고 또 Java 클라이언트입니다.
• 실제 SQS 대기열을 만들고 없애는 대신
  가상의 대기열을 활용하니까 비용 면에서도 더 효율적이죠.

---

SQS FIFO 대기열

• FIFO
  • 선입선출
  • 표준 대기열 보다 더 확실히 순서가 보장되는 것입니다.
• 소비자가 SQS FIFO 대기열로부터 메시지를 불러올 때 정확히 동일한 순서로 메시지를 받게 해 줍니다.
• 제한된 처리량
  • 묶음이 아닐 경우에는 초당 300개의 메시지
  • 메시지를 묶음으로 보낼 경우의 처리량은 초당 3000개
• SQS FIFO 대기열의 기능으로 인해 정확히 한번만 보낼 수 있게 해 줍니다.
• 분리가 발생하거나 메시지의 순서를 유지할 필요가 있을 때 FIFO 대기열을 확인해야 합니다.

---

Amazon SNS

• 메시지 하나를 여러 수신자에게 보낸다고 가정해 봅시다.

Amazon SNS

• "이벤트 생산자"는 한 SNS 주제에만 메시지를 보냅니다.
• "이벤트 수신자" 또는 구독자는 해당 주제와 관련한 SNS 알림을 받으려는 사람입니다.
• SNS 주제 구독자는 해당 주제로 전송된 메시지를 모두 받게 됩니다.
• 주제별로 최대 1,200만 이상의 구독자까지 가능합니다.
• 계정당 가질 수 있는 주제 수는 최대 10만 개이고 늘릴 수도 있습니다.

---

SNS 게시 방법

• SDK 주제 게시를 통해
  • 주제를 만듭니다.
  • 여러 개의 구독을 만듭니다.
  • 주제를 게시합니다.
• 모바일 앱 SDK 전용 직접 게시 방법
  • 플랫폼 애플리케이션을 만든 다음
  • 플랫폼 엔드 포인트를 만들고
  • 플랫폼 엔드 포인트에 게시하면 됩니다.
  • Google, GCM, Apple APNS 또는 Amazon ADM 구독자

---

SNS - 보안

Amazon SNS는 SQS와 동일합니다

• 암호화

  • HTTPS API를 사용하여 전송 중 암호화를 합니다.
  • KMS 키를 사용하여 미사용 암호화를 얻습니다.
  • 클라이언트가 자체적으로 암호화 및 암호 해독을 수행하는 클라이언트 측 암호화를 합니다.

• 액세스 제어

  • SQS API에 대한 액세스를 규제할 수 있습니다.

• SQS 액세스 정책

  • S3 버킷 정책과 유사합니다.
  • SQS 대기열에 대한 교차 계정 액세스를 수행하려는 경우
  • NS 혹은 Amazon S3 같은 다른 서비스가 SQS 대기열에 S3 이벤트 같은 것을 쓸 수 있도록 허용

---

SNS + SQS: Fan Out

• SNS 주제에 한 번만 푸시해도
  원하는 만큼의 SNS 주제의 여러 SQS 대기열을 구독할 수 있습니다.
• 완전 계층 분리되며, 데이터 손실은 없습니다.
• SQS를 통해 데이터 지속성, 지연 처리 작업 재시도가 가능하며
  팬아웃 패턴으로 더 많은 SQS 대기열을 SNS 주제에 구독시킬 수 있습니다.
• SQS 대기열 접근 정책을 통해 SNS 주제를 SQS 대기열에 메시지를 전송하도록 허용해야 합니다.

---

Kinesis

• Kinesis는 실시간으로 데이터를 수집, 처리 분석, 스트리밍하는 역할을 하며
  실시간으로 생성된 데이터를 분석 또는 처리하기 위해 앱으로 보내고자 할 때 사용합니다.
• 앱 로그, 지표, 웹사이트 클릭스트림 IoT 텔레메트리 데이터 등이 해당합니다.
• 컴포넌트 :
  • Kinesis Data Streams
    *데이터 스트림을 캡처, 처리, 저장
  • Kinesis Data Firehose
    • AWS 데이터 스토어에 데이터 스트림을 저장
  • Kinesis Data Analytics
    • SQL이나 Apache Flink로 데이터 스트림을 분석
  • Kinesis Video Streams
    • 비디오 스트림을 캡처, 처리, 저장하는 역할

  ---

  Kinesis Data Streams

• 보존 기간은 1일부터 365일까지
• 데이터를 재처리하거나 재생할 수 있습니다.
• 저장된 데이터는 삭제가 불가능합니다. (불변성)
• 같은 파티션에 공유된 데이터는 같은 샤드를 통해 전송되어 키 기반 정렬이 가능합니다.
• 생산자
  • SDK, KPL, Kinesis 에이전트를 사용할 수 있습니다.
• 소비자
  • KCL, SDK를 직접 만듬
  • AWS Lambda, Kinesis Data Firehose Kinesis Data Analytics 같은 관리된 소비자
    
    
• 용량 모드 :
  • 프로비저닝된 용량 모드
    • 프로비저닝할 샤드 수를 정하고 직접 또는 API를 통해 조정합니다.
  • 온디맨드 모드
    • 용량을 프로비저닝하거나 관리할 필요가 없습니다.
    • 기본적으로는 초당 4 MB 또는 4,000개의 레코드를 처리합니다.
    • 용량은 자동으로 최근 30일 간 최대 사용량에 따라 조정됩니다.
    • 시간 단위로 스트림당 데이터량(GB)에 따라 비용이 부과됩니다.

  ---

  Kinesis Data Firehose

• 목적지까지 전송되는 데이터를 저장하는 것입니다.
• 거의 실시간 서비스라 할 수 있습니다.
• 별도로 관리할 필요가 없고 자동으로 확장되며 서버가 없습니다.
  • AWS의 Redshift, Amazon S3, and Elasticsearch
• 타사 파트너와 사용자 지정 HTTP 엔드 포인트가 있습니다.
• 비용은 Firehose에서 처리한 데이터에만 부과됩니다.
• 거의 실시간에 가깝게 처리됩니다.
• 지연 시간은 최소 60초로 지정되어 있어 배치를 채울 만큼 충분한 처리량이 없거나
  최소 용량인 32 MB에 미달하는 경우 그대로 전송되고
  배치의 크기를 조정할 수는 있지만 32 MB 미만으로는 설정할 수 없습니다.
• 여러 형태의 데이터 포맷과 변환 압축을 지원하고
  앞서 설명한 Lambda를 통한 사용자 지정 데이터 변환도 지원합니다.
• 처리에 실패하거나 처리된 모든 데이터를 S3 백업 버킷에 보낼 수도 있습니다.

---

Kinesis Data Streams vs Firehose

• Kinesis Data Streams
  • 대규모로 데이터를 수집하는 스트리밍 서비스
  • 사용자 지정 코드를 작성해 데이터 전송과 소비에 사용할 수 있습니다.
  • 실시간 처리 (0 ~ 200 ms)
  • 스케일링 관리 (샤드 추가/분할/통합)
  • 1-365일간 보존되며 따라서 재생 기능을 지원합니다.
• Kinesis Data Firehose
  • S3 Redshift, Elasticsearch 타사, HTTP로 전송하는 것이 목적입니다.
  • 완전 관리형 서비스
  • 데이터는 버퍼에서 배치로 쓰이기 때문에 거의 실시간으로 작동합니다.
  • 확장은 자동으로 이루어집니다.
  • 데이터 저장소가 없습니다.
  • 데이터를 재생할 수 없습니다.

---

Kinesis Data Analytics

• 완전 관리형 모델
• 프로비저닝할 서버가 없습니다.
• 자동으로 확장됩니다.
• 실시간 분석이 목적입니다.
• 비용은 처리된 만큼 부과되므로, 실제 사용량에 기반하며 실시간 쿼리를 통해 스트리밍을 생성할 수 있습니다.
• 사용 :
  • 시계열 분석, 실시간 대시보드, 실시간 지표

---

Kinesis vs SQS ordering

트럭은 100대가 있고 Kinesis 샤드가 5개 SQS FIFO 대기열이 1개라고 가정,

• Kinesis Data Streams
  • 평균적으로 가지는 값은 샤드당 트럭 20대
  • 트럭 데이터는 각 샤드에 순서대로 정렬됩니다.
  • 동시에 가질 수 있는 최대 소비자 개수는 5개뿐입니다.
  • 샤드가 5개인 경우에 초당 최대 5MB의 데이터를 수신할 수 있으며 꽤 많은 편입니다.
• SQS FIFO
  • SQS FIFO 대기열이 하나
  • 각 트럭 ID에 상응하는 그룹 ID를 100개 생성합니다.
  • 소비자도 최대 100개가 될 수 있습니다.
  • 규모를 보면 SQS FIFO에서 최대 초당 300, 혹은 배치를 사용하면 3,000개의 메시지를 가집니다.

---

SQS vs SNS vs Kinesis

• SQS
  • 메시지를 요청해서 데이터를 가져오는(pull) 모델
  • 데이터를 처리 후에 소비자가 대기열에서 삭제하서 다른 소비자가 읽을 수 없게 합니다.
  • 작업자나 소비자 수가 제한이 없습니다.
  • 관리된 서비스이므로 처리량을 프로비저닝할 필요가 없습니다.
  • 순서를 보장하려면 FIFO 대기열을 활성화합니다.
  • 각 메시지에 지연 기능이 있습니다.
• SNS
  • 다수의 구독자에게 데이터를 푸시하면 메시지의 복사본을 받게됩니다.
  • SNS 주제별로 1,250만 명의 구독자까지 가능합니다.
  • 데이터가 한 번 SNS에 전송되면 지속되지 않습니다.
    • 제대로 전달되지 않는다면 데이터를 잃을 가능성이 있습니다.
  • 게시-구독 모델은 최대 10만 개의 주제로 확장 가능합니다.
  • 처리량을 프로비저닝하지 않아도 됩니다.
  • 팬아웃 아키텍처 패턴을 이용하면 SQS와 결합할 수 있습니다.
    • SNS FIFO 주제를 SQS FIFO 대기열과 결합할 수 있죠.
• Kinesis
  • 표준모드
    • 소비자가 Kinesis로부터 데이터를 가져옵니다.(pull)
    • 샤드당 2 MB/s의 속도를 지원해요
  • 향상된 팬아웃 유형의 소비 메커니즘
    • 샤드 하나에 소비자당 2 MB/s의 속도가 나옵니다.
  • 데이터를 다시 재생할 수 있어요.
    • Kinesis 데이터 스트림에서는 데이터가 지속되기 때문에
    • 실시간 빅 데이터 분석, ETL 등에 활용됩니다.
  • 샤드 레벨에서 정할 수 있습니다.
  • 1에서 365일까지 데이터를 보존할 수 있습니다.
  • 프로비저닝 용량 모드
    • Kinesis 데이터 스트림으로부터 원하는 샤드 양을 미리 지정합니다.
  • 온 디맨드 용량 모드
    • 샤드 수가 Kinesis 데이터 스트림에 따라 자동으로 조정됩니다.

---

Amazon MQ

애플리케이션을 마이그레이션할 때
전부 재설계를 하는 대신
메시지 대기열을 클라우드로 그냥 옮기고 싶을 수 있습니다.

Amazon MQ를 사용합니다.

• Amazon MQ는 클라우드에서 Apache ActiveMQ를 관리합니다.
• SQS나 SNS 만큼 확장되진 않는데 프로비저닝되기 때문입니다.
• 전용 머신에서 실행됩니다.
• 장애 조치에 대해 고가용성을 설정할 수 있습니다.
• SQS처럼 대기열 기능도 있습니다.
• SNS처럼 주제 기능도 있습니다.

재설계하지 않고
온프레미스에서 클라우드로 애플리케이션을 마이그레이션할 때
그 애플리케이션이 MQTT나 MQP 같은 표준 프로토콜을 사용한다면
Amazon MQ를 사용해야 한다는 것입니다

---

Amazon MQ - 고가용성

---

From
AWS Certified Solutions Architect Associate 시험합격!