Decoupling
어플리케이션을 여러 개 배포하게 되면 그들은 서로간 통신을 할 수밖에 없다.
이 경우, 통신은 두 가지로 나뉜다.
- 동기 커뮤니케이션
- 이 경우 한쪽 인스턴스가 과중해지거나 장애가 생긴 경우 문제가 생긴다.
- 비동기 커뮤니케이션
- 어플리케이션을 디커플링 하는 비동기 방법으로 다음 세 가지가 제공된다.
- using SQS : queue model
- using SNS : pub/sub model
- using Kienesis : real-time streaming model
Amazon SQS
SQS 는 메시지 대기열 서비스이다.
하나일 수도, 더 많을 수도 있는 생산자들이 큐로 메시지를 보내게 된다.
동일하게 하나, 혹은 다수의 소비자가 큐에서 메시지가 있는지 폴링하고 적절한 메시지를 가져와서 처리한다.
SDK 의 SendMessage API 를 이용하여 SQS 에 메시지를 보낸다.
소비자는 EC2 인스턴스가 될수도, 온프레미스 서버나 AWS Lambda가 될 수도 있다.
ASG와 같이 운영하는 경우가 많으며, 메시지 큐의 길이에 따라 오토 스케일링을 수행하는 것 또한 가능하다.
Standard Queue
가장 오래된, 완전 관리형 서비스이다.
- 무제한의 처리용량을 가질 수 있다
- 각 메시지는 수명이 짧다 : 4일의 기본값과 14일의 최댓값을 가진다.
- 낮은 지연시간을 가진다 ( < 10ms )
- 메시지마다 256KB 미만이어야 한다는 용량 제한을 가진다.
- 메시지가 중복되는 경우가 있으므로 이에 대한 처리가 필요하다.
Security
HTTPS API 를 이용하여 In-flight 보안을 이룬다.
저장 중인 데이터는 KMS key 를 이용하여 암호화한다.
직접 암호화/복호화를 어플리케이션단에서 수행할 수도 있다.
Access Control 은 IAM 정책을 통해 SQS API 권한 제어로 가능하다.
SQS Access Policies 를 이용하면 SQS 큐에 정책을 줄 수 있다.
Access Policy
교차 계정 액세스를 허용하기 위해서는 Access Policy를 SQS 에 부여해야 한다.
S3 버킷 이벤트에서 SQS 큐에 메시지를 전송하려는 경우에도 SQS 에 Access Policy 를 부여함으로서 이룰 수 있다.
Message Visibility Timeout
소비자가 메시지를 폴링하면 그 메시지는 다른 소비자에게 보이지 않게 된다.
이는 기본 30초의 시간을 가진다. (이는 메시지 처리 제한 시간을 의미하기도 한다)
즉, 메시지 timeout 시간 내에 처리하지 않으면, 해당 메시지는 두 번 이상 불리게 된다.
이 timeout 시간은 API 호출을 통해 조절될 수 있다.
Dead Letter Queue
소비자가 visibility timeout 내에 처리를 못하는 상황이 반복되면, 이 메시지는 Dead Letter Queue 로 이동된다.
dead letter message 는 메시지 분석 및 문제 해결 후 Redrive to Source 기능을 이용하여 소스 SQS로 리드라이브 할 수 있다.
Queue 지연
소비자들이 즉각적으로 큐를 보지 못하도록 메시지를 최대 15분까지 지연시키는 것이다.
큐 레벨에서 이를 설정하거나, 메시지 생성시 메시지별로 이를 지정할 수 있다.
Long Polling
소비자가 대기열에 메시지를 요청했는데 대기열에 아무것도 없다면 롱 폴링을 통해 대기하여 메시지를 가져올 수 있다.
- 지연 시간을 줄이는 목적이 있다.
- API call 을 줄이는 목적이 있다.
FIFO Queue
First In First Out Queue 로서, 이는 표준 대기열보다 더 확실히 순서가 보장된다.
Amazon SNS
Simple Notification Service 로서, 이는 메시지를 다양한 대상에 보내고 싶을 때 사용되는 발행자 / 구독자 형식의 서비스이다.
발행자는 다양한 AWS 서비스가 될 수 있다.
구독자는 수많은 유저나, 또다른 AWS 서비스가 될 수 있다.
Security
HTTPS API 를 이용하여 In-flight 보안을 이룬다.
저장 중인 데이터는 KMS key 를 이용하여 암호화한다.
직접 암호화/복호화를 어플리케이션단에서 수행할 수도 있다.
Access Control 은 IAM 정책을 통해 SNS API 권한 제어로 가능하다.
SQS Access Policies 를 이용하면 SNS 메시징에 정책을 줄 수 있다.
FIFO Topic
SNS 또한 First In First Out 기능이 있어 주제 내의 메시지에 순서를 지정하여 순서를 명확히 할 수 있다.
이 때 이러한 메시지는 SQS FIFO 에만 보낼 수 있다.
Fan Out Pattern
AWS 서비스가 다양한 SQS 에 직접적으로 메시지를 보내게 하는 방식보다,
SNS 에 한 번 푸시하면 SNS가 구독하는 SQS에 메시지를 보내는 형식을 쓰는 것이 좋다.
이는 완전히 분리된 모델이므로 데이터 손실이 발생하지 않는다.
SQS를 통해 데이터 지속성, 지연 처리, 작업 재시도가 가능하다.
또한 이 패턴을 이용하면 더 많은 SQS 대기열을 SNS 주제에 구독시킬 수 있다.
SNS 에서 SQS 로 메시지 전송 시 JSON 을 검사하는 filter 를 추가하여 메시지 필터링 사용이 가능하다.
Kienesis
Kienesis 는 실시간으로 데이터를 수집, 처리, 분석, 스트리밍하는 역할을 하며,
실시간으로 생성된 데이터를 분석 또는 처리하기 위해 앱으로 보내고자 할 때 사용한다.
Kienesis Data Streams
데이터 스트림을 캡쳐, 처리, 저장한다.
데이터의 보존 기간은 1일부터 365일까지이다.
저장된 데이터는 삭제가 불가능하다.
같은 파티션 키를 가지면 같은 샤드로 향하게 된다.
- Provisioned mode
- 프로비저닝할 샤드 수를 정하고 API 를 통해 조절한다.
- 샤드는 각각 1MB/s IN , 2MB/s OUT 을 처리한다.
- 시간당 샤드 비용이 부과된다.
- On-demand mode
- 용량을 프로비저닝하거나 관리할 필요가 없다.
- 4MB/s 의 기본 제한을 가지지만 이는 자동으로 최근 30일간 사용량에 따라 늘어나게 된다.
- 시간당 스트림 비용이 부과된다.
Kienesis Data Firehose
AWS 데이터 저장소에 데이터 스트림을 저장하는, 목적지까지 전송되는 데이터를 저장하는 서비스이다.
데이터 전송 속도는 최대 1MB/s 이다.
레코드를 중간에 변형할 때는 Lambda 기능을 통하면 가능하다.
이후 데이터 Batch write 를 통해 목적지로 스트림을 쓰게 된다.
목적지는 S3, Amazon Redshift, Amazon ElastiSearch 등이 될 수 있다.
Kienesis Data Analytics
SQL 이나 Apache Flink 로 데이터 스트림을 분석한다.
스트림에 SQL 코드를 적용하려면 소스에서 우선 데이터를 불러와야 한다.
이 때 소스는 Kienesis Data Streams 나 Data Firehose 가 될 수 있다.
이는 실시간 분석, 리얼타임 대시보드, 리얼타임 지표 등에 사용될 수 있다.
Kienesis Video Streams
비디오 스트림을 캡쳐, 처리, 저장한다.
Amazon MQ
메시지 대기열을 시장 표준에 맞추어 제공해주는 AWS 서비스이다.
SQS SNS에 맞추어 어플리케이션을 재설계하는 대신, MQ를 사용하면 된다.
이는 프로비저닝되기에, 자유롭게 확장되지는 않는다.
'공부한 이야기 > 클라우드' 카테고리의 다른 글
AWS SAA - Storages (0) | 2022.08.02 |
---|---|
AWS SAA - Route 53 (0) | 2022.08.02 |
AWS SAA - Containers (0) | 2022.08.02 |
AWS SAA - CloudFront & Global Accelerator (0) | 2022.08.02 |
AWS SAA - Access (0) | 2022.08.02 |