AWS 통합과 메시징: SQS, SNS, Kinesis, Active MQ

통합과 메시징

미들웨어로 합동 작업을 하는 방법들

• 애플리케이션 커뮤니케이션(애플리케이션끼리 정보와 데이터를 주고받는 것)
• 직접적으로 소통하느냐에 따라 나눠진다
• 동기 커뮤니케이션
  • 다른 커뮤니케이션과 직접적으로 연결됨
• 비동기 혹은 이벤트 기반 유형
  • 대기열등으로 불리는 미들웨어가 애플리케이션을 연결

SQS - Queue

• SQS는 간단한 메시지를 포함한 대기열
• Producer가 SQS 대기열로 메시지를 전송 ( 메시지는 어떤 것도 상관없음 )
• 수신해야하는 대상을 Consumer ( 대기열에 자신이 처리할 메시지기 있는지 확인하고 메시지를 가져온다)
• SQS는 생산자와 소비자 사이를 분리하는 버퍼 역할

SQS - Standard Queue

• 애플리케이션을 분리하는데 사용 → 시험에 출제되는 단어

특징

• 무제한 처리량을 얻을 수 있다.
  • 초당 원하는 메시지를 보낼 수 있고 큐에 메시지 제한 또한 없다
• 메시지는 기본 4일 정도 보존되며 최대 14일이다
  • 컨슈머가 처리하지 않으면 소실됨
• 지연시간이 짧아 메시지를 보내거나 읽을 때 10밀리초 이내로 빠르게 응답받는다
• SQS 메시지는 256KB 미만이어야 한다
• 중복 메시지가 있을 수 있다
• out of order messages ( 품절 메시지 )

SQS - Producing Messages (생산자 메시지)

• SDK를 통해 SQS에 메시지를 보낸다
  • SendMessage
• 컨슈머가 처리하고 삭제할 때까지 SQS에 유지된다
• 무제한으로 보낼 수 있고 사용자 정보같은 것들을 보내 컨슈머에게 처리를 요청

SQS - Consuming Messages

• 컨슈머는 일종의 애플리케이션이며 AWS 가성 서버에서 실행되거나 온프레미스 서버에서 실행
  • 람다, EC2 등등
• 소비자가 대기열에 자신의 앞으로 온 메시지가 있는지를 먼저 물어본다
  • 최대 10개를 한번에 받을 수 있다
• 요청 작업을 처리하고 DeleteMessage API로 대기열에서 삭제한다

Multiple EC2 인스턴스 소비자

• 여러 개의 소비자가 있을 수 있다
• 각 컨슈머는 poll을 통해 메시지를 받고 처리속도가 충분하지 않으면 다른 컨슈머로 보내진다
  • 일단 한번은 컨슈머에게 보내기 때문에 적어도 한번 전송된다
• 이것이 최선의 노력으로 메시지 순서 지정 (Best-effort message ordering)
• 이후 처리가 완료되면 삭제해야만 다른 컨슈머가 처리하지 않는다
• 처리량을 늘려야한다면 수평 확장을 수행해서 개선할 수 있다

오토스케일링 그룹과 SQS

• 컨슈머가 ASG내부에서 인스턴스를 실행하고 메시지를 폴링한다
• ASG로 확장하기 위해 지표가 있어야하는데 이럴 때 사용하는 지표가 메시지의 개수이다
  • CloudWatch Metric - Queue Length - ApproximateNumberOfMessages
• 이후 CloudWatch Alarm을 알려 요청을 처리
• 일반적인 처리 방식이며 자주 사용된다

SQS to decouple between application tiers

SQS는 애플리케이션간 분리할 수있도록 해준다

파일 처리 요청과 실제 파일 처리를 분리하여 작업을 분할한다. 이후 독립적인 확장이 가능

메시지를 보낼 떄 파일을 올려 백엔드 서버에서 처리하고 버킷으로 저장시키는 방식

SQS - Security

• HTTPS API를 통한 전송 중 암호화
• KMS키 활용한 메시지 암호화
• 클라이언트 측 암호화도 가능
  • 클라이언트에서 자체적으로 암호화가 필요

Access control

• SQS API에 대한 엑세스 규제

SQS Access Policies

• 교차 계정 엑세스
• 다른 서비스(SNS, S3…)가 SQS 대기열에 쓰일 수 있도록 허용가능

SQS - Message Visibility Timeout

• 컨슈머가 메시지를 폴링하면 다른 소비자들에게 해당 메시지는 보이지 않는다
• 30초동안 메시지가 처리되어야한다 (Visibility Timeout)
  • 시간이 지나기전에 메시지 수신요청에서 조회되지않는다
  • 시간이 초과되고 메시지가 삭제되지 않으면 다시 대기열에 넣는다
  • 이후 또다른 메시지를 받게 됨

• 컨슈머가 메시지를 처리하고 있음에도 시간 내에 처리하지 않으면 메시지가 두 번 처리될 수 있다.
• ChangeMessageVisibility API를 통해 시간을 조정해야한다
• 매우 높은 값을 기본값으로 설정하면 컨슈머가 크래쉬됐을 때 다시 처리되는데 오래 걸림
• 매우 낮은 값으로 설정하면 하나의 메시지가 여러 번씩 처리된다

시나리오가 자주 나오니 알고있는게 중요

SQS - Long Polling

• 컨슈머가 큐에 메시지를 요청하는데 큐에 아무것도 없다면 대기하며 기다릴 수 있다
• 지연시간을 줄이고 SQS로 보내는 API 호출 숫자를 줄이기 위해서이다
• 롱폴링 중인 컨슈머에 짧은 지연시간으로 메시지를 보낼 수 있다
• API 호출 숫자를 줄이면서 효율성과 대기 시간을 증가시킴
• 1~20초로 설정할 수 있다

설정

• 큐레벨에서 구성하여 폴링하는 컨슈머에게 롱폴링을 활성화 설정
• WaitTimeSeconds을통해 소비자가 스스로 롱폴링을 하도록 선택

중요한건 API 호출 수 최적화와 지연시간을 줄이는 것이다

SQS - FIFO Queue

• 첫 번째 도착한 메시지가 첫 번째로 처리될 수 있도록 스탠다드 큐보다 순차처리를 훨씬 보장
• 순서를 확실히 보장하기 때문에 처리량에는 제한이 있다
• 묶음이 아닐경우 초당 300개 묶음일 경우 초당 3,000개 처리함
  • 처리량에 제한을 걸 수 있다
• FIFO 큐의 기능으로 중복없이 정확히 한번 보낼 수 있다 → deduplication ID
• 순차 처리를 보장

SQS와 Auto Scaling Group (ASG)

방법과 사용 패턴

• cloudwatch의 지표인 큐 길이를 보고 알람을 지정하여 확장을 관리할 수 있다
  • 지표를 넘으면 경보를 날려 오토 스케일링 그룹에 확장을 요청 → 확장 축소 모두 가능

사용 패턴

매우 큰 행사 중일 때 고객들의 주문이 여러 DB에 저장될 수 있다.

트랜잭션 내역은 상당히 많아지고 모종의 이유로 트랜잭션이 유실될 수 있다.

해결 방법으로는 쓰기 대상 db에서 SQS를 버퍼로 사용할 수 있다 → 매우 자주나오는 패턴

무한히 확장 가능한 SQS 큐에 트랜잭션을 쓴다 → 처치량 문제 해결

모든 요청이 SQS로 가고 이후 백엔드 그룹이 폴링해서 DB로 넣는 작업을 거침 → 이후 메시지 삭제

이 패턴은 클라이언트에게 따로 데이터베이스에 삽입됐다는 알림이 필요 없을때 사용한다

그렇다고 해도 SQS 대기열에 write 작업이 발생했다는 것만으로도 DB 데이터 삽입이 일어났다고 볼 수 있기 때문에 큰 문제는 없다

SQS to decouple between application tiers

DB 삽입과 애플리케이션간 작업 분리에 활용된다고 볼 수 있다

db가 애플리케이션에게 모든 요청을 전달받고 응답을 재전송하는 대신

모두 분리하여 애플리케이션이 SQS 대기열로 전송하고 백엔드 처리 작업을 따로 구성하여 이후 메시지를 전달받아 처리하며 필요에 따라 스케일링하는 방식이 SQS 애플리케이션 티어간 분리

SQS를 사용하는 문제는 훨씬 더 자주 등장하기 때문에 숙지해야함

애플리케이션 분리 , 급격히 증가한 로드 혹은 시간초과 등의 문제에서 신속한 스케일링이 필요한 경우 SQS를 사용한다

Amazon SNS

메시지하나를 여러 수신자에게 보낼 때 직접적으로 연결했다면 수신 서비스를 하나 생성할 때마다 통합과 관리가 필요하다.

이를해결하기 위해 Publish/Subscribe (Pub/Sub)방식을 사용한다

• 메시지를 주제로 게시
• 많은 구독자들은 SNS 토픽에 따라 메시지를 수신하고 보관

특징

• SNS에서 이벤트 생산자는 한 SNS 토픽에만 메시지를 보낸다
• 수신자 또는 구독자는 해당 토픽와 관련된 메시지를 받는 역할이고 생성에 제한이 없다
• 하나의 SNS 토픽 구독자는 해당 토픽으로 전송된 모든 메시지를 받으며 메시지 필터링도 있다
• SNS에서 구독자에게 게시할 수 있는 것들은 다음과 같다

SNS는 많은 AWS 서비스와 통합가능

• SNS는 다양한 AWS 서비스에서 데이터를 받을 수 있다.
• SNS로 직접 알람을 보내는 것들
• AWS에서 알림이 발생하면 여러 서비스들이 지정된 SNS 토픽으로 알림 전송

SNS 게시방법(Publish)

• SDK 토픽 게시를 사용
  • 토픽을 만들고 여러개의 구독을 만든 뒤 토픽을 공개하면 된다
  • 해당하는 모든 구독자들이 토픽 메시지를 받게됨
• 직접 게시(앱 전용)
  • 플랫폼 애플리케이션을 만든 다음
  • 플랫폼 엔드포인트를 만들고
  • 플랫폼 엔드포인트에 게시
  • Google, GCM, Apple APNS, Amazon ADM 등이 수신 가능 대상

Security

SQS와 동일

• HTTPS, KMS keys, 클라이언트측 암호화

Access Controls

• IAM 정책을 통한 SNS API 컨트롤

SNS Access Policies

S3 버킷 정책과 유사

• SNS 주제에 교차 계정 엑세스 권한
• s3같은 서비스가 sns 토픽에 글을 작성할 수 있도록 허가

SNS + SQS: Fan Out 패턴

하나의 메시지를 여러 SQS 대기열로 보내고 싶다면?

애플리케이션에서 개별적으로 보낸다면 많은 문제가 발생할 수 있다

따라서 팬아웃패턴을 사용해서 원하는 만큼의 SQS 대기열이 SNS 주제를 구독하도록 한다

완전히 분리된 모델로 만들며 애플리케이션 문제로 인한 데이터 손실도 되지 않을 것

• SQS로 작업을 다시 시도할 수 있고 데이터 지속성, 지연성 처리도 수행 가능하다
• 더 많은 SQS 대기열 추가 가능
• SQS 엑세스 정책에서 SNS 주제가 SQS 큐에 메시지를 작성할 수 있도록 허용해야한다
• 리전간 전달 또한 가능

Application: S3 Events to multiple queues

이벤트 세 개를 여러 대기열에 넣는 경우

S3 이벤트 규칙에 제한 조건이 있다.

• 객체 생성과 같은 이벤트 유형과 /images같은 접두사의 조합이 같은 것이 있다면 s3 이벤트 규칙은 한가지만 가질 수 있다

팬아웃 패턴 덕분에 여러 목적지로 도달 가능

Application: SNS to Amazon S3 through Kinesis Data Firehose

Kinesis Data Firehose를 통해 SNS에서 S3로 직접 데이터 전송 가능

• SNS를 KDF에 직접 연결하여 구매 서비스에서 데이터를 SNS 주제로 전송할 수 있다
• 이후 Kinesis Data Firehose에서 해당 정보를 수신하고 해당 KDF에서 S3 버킷이나 KDF 어디로든 보낼 수 있다
• 아래와 같은 방식으로 SNS 토픽 메시지를 계속 이어가도록 설정할 수 있다

SNS - FIFO Topic

• SNS에는 토픽의 메시지 순서를 지정하는 FIFO 기능이 있다.
• SQS FIFO와 비슷하게 그룹ID에 따라 순서를 매겨 전송
• ID를 활용하여 중복을 제거하거나 내용을 비교하여 중복 데이터를 제거
• FIFO SNS 토픽의 구독자로 SQS FIFO 큐만 설정 가능하다
• 제한된 처리량을 갖는다

필요한 이유 - SNS FIFO + SQS FIFO: Fan Out

SNS FIFO의 팬아웃을 수행하려면 순서, 중복 제거가 필요하기 때문에 SQS FIFO를 활용하여야 한다

SNS - Message Filtering

• SNS 토픽을 구독하면서, 토픽에서 전송되는 메시지를 필터링하는데 JSON 정책이 사용된다
• 어떤 필터링도 없다면 모든 메시지를 받는다
• 트랜잭션을 처리하기 위해 새로운 데이터가 들어오면 특정 카테고리 데이터만 받을 수 있다

SNS 실습

오직 SQS FIFO 대기열만 FIFO SNS 주제를 구독할 수 있다(제한사항 주의)

네이밍이 .fifo로 끝나야함

Kinesis

Kinesis는 자주 쓰이는 만큼 중요한 파트임

• 실시간 스트리밍 데이터를 손쉽게 수집하고 처리하여 분석까지 할 수 있다
  • 애플리케이션 로그, 측정, 웹사이트 클릭 스트림, IoT 원격 측정 데이터
• 데이터가 빠르게 실시간으로 생성되는 것을 모두 실시간 데이터 스트림으로 간주

Kinesis Data Stream

• 시스템에서 큰 규모의 데이터 흐름을 다루는 서비스
• 여러 개의 샤드로 구성되며 사전에 프로비저닝 해야한다 (시작할 때 결정해야함)
• 데이터는 모든 샤드에 분배된다. 이후 데이터 수집률이나 소비율 측면에서 스트림의 용량 결정
• SDK에 의존하여 Kinesis Data Stream에 레코드를 전달
  • 파티션 키와 데이터 블롭으로 구성된다
  • 키는 샤드를 결정하는데 사용 블롭은 값 자체
  • 샤드당 최대 1MB/sec or 1000msg/sec를 전송할 수 있다
• 파티션키, 시퀀스넘버,데이터블롭을 포함한 레코드를 샤드당 2MB/sec로 모든 컨슈머 혹은 개별 컨슈머에게 전달

정리하자면 프로시저가 데이터를 레코드 단위로 Kinesis로 전달하고 데이터는 샤드에 머물면서 여러 소비자에게 읽힌다

특징

• 보존 기간은 1~365일하며 데이터를 재가공하거나 재확인 가능
• 키네시스로 들어오면 삭제 불가능 → 불변성
• 데이터 스트림으로 메시지 전송시 파티션키가 추가되고 파티션 키가 같은 메시지들은 같은 샤드로 들어가 키를 기반으로 데이터 정렬 가능
• 프로시저는 SDK, Kinesis Producer Library (KPL), Kinesis Agent를 통한 데이터 전송 가능
• 컨슈머는 Kinesis Client Library (KCL), SDK로 직접 개발 or Lambda같이 관리형 서비스 이용 가능

Capacity Modes

• 프로비저닝 모드
  • 프로비저닝할 샤드 수를 정하고 API 활용하거나 수동으로 스케일을 조정
  • 각 샤드는 초당 1MB or 1000msg 처리
  • 출력의 경우 2MB
  • 샤드를 프로비저닝 할 때마다 시간당 비용이 부과된다
• 온디맨드 모드 → 사전에 사용량 예측 불가
  • 시간에 따라 언제든 용량이 조정된다
  • 초당 4MB or 4천 개의 레코드를 처리하지만 30일동안 관측한 최대 처리량에 기반하여 자동으로 조정
  • 시간당 스트림별로 송수신 데이터(GB)양에 따라 비용이 부과된다

Security

• IAM 정책을 사용하여 샤드 생성하거나 접근 권한 제어
• HTTPS 전송 중 데이터 암호화, 미사용 데이터는 KMS로 암호하
• 클라이언트 측 암호/복호화도 가능하지만 어렵다
• VPC 엔드포인트 사용 가능
• CloudTrail을 활용한 모니터링 가능

Kinesis Data Firehose

• 생산자에서 데이터를 가져올 수 있는 서비스
• Batch로 수신처에 쓸 수 있다 + 별도의 코드 없이 사용 가능 (AWS 수신처는 알고있어야함)
  • 아마존 S3, Redshift, ElasticSearch
  • 서드파티로 전송가능
  • 커스텀 수신처로도 전송 가능
• 모든 데이터를 백업으로 S3로 보내거나 수신처에 쓰이지 못한 데이터를 실패 S3 버킷으로 보낼 수 있다

특징

• 완전 관리형 서비스로 오토 스케일링 + 서버리스 서비스이다
  • Redshift, S3 , ElasticSearch같은 수신처로 데이터 전송 가능
  • 서드파티: NoSQL
  • 커스텀 : HTTP 엔드포인트
• Firehose를 통과하는 데이터만 비용을 지불하면 된다
• 거의 실시간 → 배치 작업을 염두(실시간에 가까움)
• 데이터 형식,전환,변환,압축 지원
• 모든 데이터를 S3 버킷에 보낼 수 있다

Kinesis Data Streams vs Firehose 차이

Kinesis와 SQS FIFO에서 데이터 정렬

Kinesis와 SQS FIFO는 같은 것처럼 보이지만 분명히 다르다

Kinesis 데이터 정렬 예시

트럭의 위치 정보 데이터를 토대로 이동 경로를 추적 및 예상하고자 할 때 GPS 데이터를 어떤 형식으로 전송해야할까?

트럭의 ID를 파티션키로 활용하여 전송한다 → 해싱해서 샤드로 들어간다 → 트럭의 ID는 항상 같기 때문에 해싱된 결과로 같은 샤드로 데이터를 전송한다.

연결된다고보면 쉽다

항상 같은 샤드로 같은 트럭의 정보가 들어가기 때문에 샤드 레벨에서 데이터를 분석하면 파티션 키를 따라 개별 트럭을 구분하여 정렬된 데이터를 얻을 수 있다

SQS 데이터 정렬

• standard에는 정렬이 없지만 FIFO Group ID를 통해 구분할 수 있다
  • 만약 그룹 ID를 설정하지 않고 FIFO를 사용하면 보내진 순서에 따르며 동시에 하나의 소비자만 존재한다
• 트럭의 예시에서 모든 트럭이 FIFO Queue로 데이터를 보내더라도 소비자는 하나로 처리한다

• 소비자 숫자를 스케일하고 서로 연관된 그룹으로 보내려고 한다면 Group ID 사용
  • 파티션키와 개념이 비슷
• 그룹 ID가 많아질 수록 소비자 또한 많아진다

Kinesis vs SQS ordering

100대의 트럭, 5개의 Kinesis 샤드와 1개의 SQS FIFO가 있을 때

Kinesis Data Streams

• 평균 값 = 샤드 당 20대의 트럭
• 샤드에 순서대로 정렬된다
• 최대 소비자 개수는 5개 → 샤드가 5개이기 때문이며 샤드마다 하나의 소비자가 필요
• 초당 최대 5MB의 데이터 수신가능

SQS FIFO

• 대기열은 딱 하나 뿐이다
• 100대의 트럭에 상응하는 그룹 ID를 100개 생성한다
• 소비자도 최대 100개가 가능
• 초당 300 메시지, 배치에 따라 3,000개

케이스에 따라 적합한 모델은 달라지며 그룹 ID에 따라 동적인 소비자 수를 원할 때 SQS FIFO는 유용

많은 데이터를 전송하고 데이터 스트림에 샤드당 데이터를 정렬할 때 Kinesis를 사용한다

SQS vs SNS vs Kinesis

SQS SNS Kinesis 차이점을 꼭 알아두자

SQS

• 소비자가 SQS 대기열에서 pull해서 가져옴
• 데이터를 처리한 후 소비자가 대기열에서 삭제해야 한다
• 작업자나 소비자 수는 제한이 없다 함께 소비하고 대기열에서 삭제
• 완전 관리형 서비스로 프로비저닝 필요 없다
• 순서 보장 FIFO 활성화
• 메시지에 지연 기능이 있어 일정 시간 뒤 대기열에 올라갈 수 있다

SNS

• 게시/구독 모델로 다수의 구독자에게 데이터를 푸시하면 메시지의 복사본을 받게 된다
• SNS 주제별로 1,250만명의 구독자 가능
• 한번 SNS에 전송되면 유지되지 않아 제대로 전달되지 않으면 데이터 손실이 발생한다
• 최대 10만개의 주제로 확장 가능
• 프로비저닝이 필요없다
• 팬아웃 아키텍쳐와 결합하면 SNS와 SQS를 결합하거나 SQS FIFO와 SNS FIFO 토픽을 결합 가능

Kinesis

• 스탠다드 → 소비자가 데이터를 pull한다
  • 샤드당 2MB
• Enhanced-fan out → 소비자에게 데이터를 push한다
  • 샤드 하나에 연결된 소비자당 2MB/s
  • 처리량이 훨씬 높아 더 많은 애플리케이션에서 읽기가 가능하다
• 데이터를 다시 재생할 수 있다
• 실시간 빅데이터 분석, ETL
• Kinesis 데이터 스트림마다 원하는 샤드 양을 지정해야 한다
  • 직접 확장해서 데이터가 언제 만료될지 정한다 (1~365)
• 프로비저닝과 온디맨드 모드가 있다
  • 샤드를 미리 정하거나 데이터 스트림에 따라 관리된다

Amazon MQ

• 온프레미스에서 기존 애플리케이션을 실행하는 경우 개방형 프로토콜인 MQTT, AMQP, STOMP, WSS Openwire 등을 사용하면 된다.
• 애플리케이션을 클라우도로 마이그레이션하는 경우 SQS, SNS 프로토콜 혹은 API를 사용하기 위해 애플리케이션을 다시 구축하지 않고 기존에 프로토콜을 사용하고 싶은 경우 MQ를 사용
• RabbitMQ와 ActiveMQ 두 가지 기술을 위한 관리형 메시지 브로커 서비스
  • 온프레미스 기술로 개방형 프로토콜 엑세스를 제공
• MQ를 이요하면 해당 브로커의 관리형 버전을 클라우드에서 사용 가능
• SQS 혹은 SNS처럼 확장성이 크지 않다
• MQ는 서버에서 실행되기 때문에 장애 조치를 위해 Multi-AZ에서 실행 가능
• SQS, SNS처럼 보이는 기능을 제공한다

EFS를 통해 장애가 발생해도 데이터가 저장된다