🐾 메시징 소개
미들웨어로 다른 서비스간 합동 작업 및 커뮤니케이션을 하는 역할입니다.
일단 두가지로 나뉘어 집니다.
1. 동기 커뮤니케이션
직접 연결이 되는 방식으로 온라인 쇼핑과 같이
물건이 판매가 되면, 배송 서비스에 연락해야 하는 경우에 사용이 됩니다.
2. 비동기 커뮤니케이션
구매 서비스가 누군가 물건을 구매했으니 특정 저장소에 값을 추가 합니다.
그후 배송 서비스가 저장소를 조회함으로써 동작을 합니다.
이러한 예시를 보면 동기가 더 좋아보이지만 갑자기 트래픽이 증가되었을떄에는 동기 커뮤니케이션은 좋은 선택지가 아닐 수 있습니다.
- 에러가 발생하기 쉽기 떄문입니다.🐾 SQS 대기열
간단한 대기 서비스 입니다.
SQS 대기열에 메시지를 보내는 주체를 생산자 라고 하며 생산자는 여러명 일 수 있으며 여러개의 메시지를 대기열에 보내게 됩니다.
메시지는 무엇이든 상관이 없습니다.
- 예를들면 오더를 처리해라!!, 아니면 비디오를 처리해라!!! 라고도 구성이 가능합니다.
생성한 몬든 메시지는 대기열에 포함이 되고
이후 대기열에서는 메시지를 처리하고 수신해야 하는 대상 = 소비자 에게 전송합니다.
- 이를 소비자가 폴링한다고 합니다.
🔥 Amazon SQS = 표준 대기열
SQS에서 가장 오래된 서비스로 첫 번쨰 서비스입니다.
완전 관리형이며, 애플리케이션을 분리하는데에 사용합니다.
무제한 처리량을 얻을 수 있습니다.
- 즉 초당 원하는 만큼 메시지를 보낼 수 있으며, 대기열의 메시지 수에도 제한이 없습니다.
대신 메시지는 기본값으로 4일동안 대기열에 남아 있을 수 있고 수정을 한다면 14일 까지 가능합니다.
전송된 메시지는 256KB미만이어야 하는 조건이 있으며 중복 메시지가 존재 가능합니다.
HTTPS 보안을 사용하며 KMS키를 사용하요 암호화를 얻습니다.
- 원한다면 클라이언트 측 암호화도 가능합니다.
액세스 제어를 위해 IAM정책이 필요하며, S3 버킷 정책과 유사한 SQS 액세스 정책도 있습니다.
🔥 대기열 액세스 정책
S3 버킷과 유사하며, JSON IAM정책을 직접 추가 할 수 있습니다.
사용사례에는 두가지가 있습니다.
1. 교차 계정 액세스를 허용
A계정에 대기열이 있고, B계정이 액세스 해야 한다고 했을떄
B계정 즉 EC2가 대기열에 잇는 메시지를 가져오려면 대기열에 정책을 생성해 주어야 합니다.
- B계정의 접근을 허용하라고
2. S3 버킷 활용
S3버킷에 객체를 업로드하면 SQS 대기열에 자동으로 메시지를 보냅니다.
- SQS대기열이 S3버킷에 메시지를 작성할 수 있는 권한을 주어야 합니다.🔥 메시지 가시성 시간 초과
일반적으로 소비자가 메시지를 폴링하면 그 메시지는 다른 소비자들에게 보이지 않게 됩니다.
소비자가 폴링을 하면 대기열에서 메시지가 반환이 되고, 이제 가시성 시간 초과가 시작됩니다.
기본적으로 30초이기 떄문에 30초 안에 미시지가 처리가 되어야 합니다.
이 30초 동안에는 다른 소비자가 동일한 메시지를 요청해도 메시지가 요청되지 않습니다.
하지만 만약 30초내에 처리가 안된다면 해당 메시지는 다시 대기열에 들어가게 됩니다.
- 이후 앞서 말한 과정이 반복됩니다.
하지만 만약 소비자가 메시지를 적극적으로 처리하고 있지만 처리가 안되는 것이라면 시간이 더 필요한 것이고 이는 API를 호출하여 SQS에 알려야 합니다.
🔥 데드 레터 대기열(DLQ)
만약 소비자가 메시지를 읽지 못하였다면 다시 대기열로 돌아가 다른 소비자가 읽게 됩니다.
하지만 그 소비자도 읽지를 못하면 다시 대기열로 돌아가며 이러한 상황이 반복됩니다.
그러면 계속해서 메시지가 대기열에 남아있게 되게 됩니다.
이러한 문제를 해결하기 위해서는 임계값을 설정해야 합니다.
물론 실패 루프가 큰 문제를 야기 할 수 있지만 최대 임계값을 설정할 수 잇다는 장점도 있습니다.
- 이렇게 임계값을 넘어가는 메시지는 데드 레터 대기열(DLQ)에 보내집니다.
마찬가지로 DLQ또한 보관 기간에 제한이 있기 떄문에 높은 보존 기간을 설정하는 것이 좋습니다.
- 디버깅을 위해서 사용합니다.
🔥 대기열 지연
소비자들이 즉각적으로 보지 못하도록 메시지를 지연시키는 것입니다.
15분까지 가능하며 기본값은 0초 입니다.
메시지별 지연 시간설정이 가능하다는 특징이 있습니다.
🔥 SQS 몇 가지 기본 개념
- 롱 폴링
소비자가 SQS로부터 메시지를 요청할 떄 만약 대기열이 비어 있다면 도착할 떄까지 기다리는 것을 말합니다.
이후 메시지가 생겨나게 되면 소비자가 메시지를 수신합니다.
사용하는 이유는 계속해서 API를 호출하기보다 한번 호출후 대기하는 방식이기 떄문에 효율성이 증가하며, 지연시간또한 줄어듭니다.
- 그러기 떄문에 기본적으로 깔고 들어가는 옵션입니다.
- SQS Extended Client
대용량의 메시지를 보낼떄 사용합니다.
기본 개념은 S3버킷을 대용량데이터를 담는 리포지토리로 사용하는 겁니다.
즉 S3에 업로드를 하고, SQS는 해당 S3를 포인팅하는 메타데이터를 올리기만 하면 됩니다.
- 즉 S3에 있는 데이터를 가르키는 겁니다.
🔥 SQS FIFO
선입선출로 동작을 하는 SQS로 대기열에 먼저 도착한 메시지가 대기열을 떠날떄에도 첫 번쨰가 되는 대기열 입니다.
- 일반적인 큐 구조입니다.
즉 대기열 내의 순서가 정렬이 된다는 의미이기 떄문에 표준 대기열보다 더 확실한 순수가 보장이 됩니다.
순서를 보장하는 대신 제한된 처리량을 가지게 되지만 중복을 제거해 주는 기능이 추가가 됩니다.
중복 제거
FIFO는 중복을 제거해 주는 기능을 가지고 있고 중복 제거가 적용되는 간격은 5분 입니다.
즉 5분 간격 이내에 동일한 메시지를 두 번 발송할 경우 두 번쨰 메시지는 거부 됩니다.
중복 제거에는 두가지 방법이 있습니다.
1. 내용 기반 중복제거
메시지의 내용을 SHA-256방식으로 해시화 하여 동일한 메시지 인지를 확인합니다.
2. 중복 제거 ID를 명시
동일한 중복제거 ID가 반복되면 메시지를 거부 합니다.메시지 그룹화
FIFO대기열로 메시지를 보낼 떄 의무적으로 입력해야 하는 파라미터인 메시지 그룹 ID를 동일하게 설정할 경우
해당 ID에 대해서는 한명의 소비자만이 활용 가능합니다.
그 후 그 한명의 소비자를 위해 모든 메시지들이 순서대로 정렬이 됩니다.
그러나 만약 서브셋 레벨에서 정렬할 피룡가 있다면 메시지 그룹 ID로 다른 값을 정해야 합니다.
🐾 Amazon SNS
메시지 하나를 여러 수신자들에게 보낸다고 가정을 하면, 수신 서비스를 새로 추가할 떄마다 통합을 생성하고 작성해야 하기 떄문에 번거롭습니다.
이 대신 Pub/Sub 즉 게시/구독이라는 것을 사용할 수 있는데 이를 통해서 구매 서비스가 메시지를 SNS주제로 전송 가능합니다.
즉 특정 주제로 메시지를 날리는 겁니다.
특정 주제에 대해서 리스닝을 하는 소비자들이 있을 것이고 주제가 업데이트 될떄마다 필터를 거쳐 메시지를 가져갑니다.
🐾 Fan Out Pattern
SNS와 SQS에 적용 가능한 패턴이빈다.
만약 SQS 대기열에 메시지를 전송하려 할 떄 모든 SQS 대기열에 메시지를 개별적으로 보내면 분제가 발생할 수 있습니다.
- 앱이 종료되거나, 전송이 실패하거나 등등
이럴떄에 팬 아웃 패턴을 활용하여 SNS 주제에 한 번만 푸시해ㅗ, 원하는 만큼의 SNS 주제의 여러 SQS 대기열을 활용 가능합니다.
이떄 SQS는 소비자가 되며 그들 모두 SNS에 전송된 메시지를 받게 됩니다.
이후 SQS와 연결된 소비자들이 데이터를 풀링 해가는 방식으로 동작합니다.
🐾 Kinesis 개요
스트리밍 데이터를 실시간으로 수집, 처리 분석하도록 도와줍니다.
- 단순히 데이터가 빠르게 실시간으로 생성되기만 해도 분석이 가능합니다.
여기에는 4가지의 서비스가 있습니다.
1. Kinesis Data Streams
데이터 스트림을 입력, 처리하고 저장합니다.
2. Kinesis Data Firehose
데이터 스트림을 AWS 내부 또는 외부의 데이터 스트오러 로드 합니다.
3. Kinesis Data Analytics
SQL언어를 통해서 분석하기 위해서 사용을 합니다.
4. Kinesis Video Streams
비디오 스트림을 입력, 처리, 저장 합니다.🔥 Kinesis Data Streams
시스템에 빅 데이터를 스트리망하는 방법입니다.
번호가 매겨진 여러 샤드로 구성이 되며 사전에 프로비저닝 되어있어야 합니다.
생산자는 어떠한 방법으로 데이터를 보냅니다.
- 방법에는 너무 여러개가 있습니다.
- 애플리케이션, 클라이언트 등등
이떄 SDK를 활용하여 레코드를 생성을 하는데 레코드는 파티션 키와 데이터 블롭을 생성합니다.
이떄 파티션 키는 레코드가 어느 샤드로 이동할지를 정의하며, 블롭은 데이터 자체를 의미합니다.
- 쉽게 말해 key, value값으로 저장됩니다.
이후 소비자가 레코드를 수신할 떄에는 파티션 키와 함께 어떤 샤드에 있었는지를 알려주는 시퀀스, 블롭까지 받게 됩니다.
속성
기본적으로 1~365일 중 선택하여 보유기간을 설정 할 수 있으며 이미 삽입된 데이터는 삭제가 불가능하며 이를 불변성이라고 합니다.
또한 데이터를 보내면 파티션 키가 담기게 되는데 같은 키를 공유하는 메시지는 동일한 샤드로 이동해 키 기반 순서를 제공합니다.
용량
두개의 모드가 있고 첫번쨰는 기록 용량 모드 입니다.
프로비저닝 모드라고도 하며, 몇 개의 샤드 프로비저닝을 선택한 후 수동 혹은 API를 사용해 확장하는 방식입니다.
시간당 샤드 프로비저닝에 따른 비용이 있습니다.
두번째는 온디맨드 모드입니다.
프로비저닝 하거나 관리할 필요가 없는 모드로 수요에 맞춰서 자동으로 조정됩니다.
- 지난 30일간의 처리량에 기반해 오토 스케일링이 수행됩니다.
이 모드에서는 시간당 입출력양에 따라 비용이 부과가 됩니다.
미리 용량이 예측이 되지 않는다면 온디맨드, 아니라면 프로비저닝을 선택합니다.
보안
리전 내에서만 배포가 되며 IAM 사용이 가능합니다.
HTTPS 암호화도 있으며, KMS도 지원합니다.
🔥 Kinesis 생산자
생산자는 데이터를 스트림에 보냅니다.
샤드 내 파티션 키마다 고유하며 파티션 키는 레코드를 스트림에 넣을떄 반드시 포함되어야 합니다.
- 블랍도 물론 존재합니다.
쓰기 같은 경우에는 초당 1MB를 지원하며, PutRecord라는 API를 전송합니다.
장치마다 아이디는 고유합니다.
예를들어 A,B라는 장치가 있고, x,y,z라는 샤드가 있다면
A에서 보내는 11111 이라는 ID는 계속해서 11111이라는 아이디를 가지면 x에게만 정송을 할 것이고
B에서는 22222라는 ID로 계속해서 y에서 전송을 하게 될 것입니다.
이러한 값은 해시함수를 거친후에 샤드로 전송이 됩니다.
이떄 중요한 점은 핫 파티션을 주의해야 합니다.
핫 파티션은 일부 샤드가 다른 샤드에 과하게 많은 처리량을 받고 있을떄 발생을 하며 이럴떄에는 약 3가지 정도로 해결이 가능합니다.
1. 매우 잘 부분산된 파티션 키를 활용
2. 기하급수적인 백오프를 구현
3. 샤드를 스케일링 🔥 Kinesis 소비자
소비자는 스트림으로부터 데이터를 가져오는 역할을 합니다.
GetRecords라는 API를 호출하며 샤드당 1초당 2MB를 공유합니다.
default모드는 이러한 공유 속도를 공유합니다.
예를들면 하나의 샤트에 x,y,z가 데이터를 가져오면 각각의 x,y,z는 666KB의 속도로 데이터를 가져 오게 되는 것입니다.
이러한 문제점을 해결하기 위해 팬아웃이 생겨나게 되었습니다.
팬아웃은 방금과 같은 상황에서도 모두 동일하게 2MB를 제공하는 서비스 이지만 더 많은 비용이 부과된다는 단점이 있습니다.
🐾 KCL
클라이언트 라이브러리를 의미합니다.
각 샤드는 KCL인스턴스에 의해서만 읽힙니다.
- 4개의 샤드가 있다면 KCL인스턴스 또한 4개가 있습니다.
읽은 시점에 DynamoDB에 기록을 하는 방식으로 동작을 하기 떄문에 만약 애플리케이션이 정지하면 체크포인트가 있는 위치에서 다시 읽는 것을 재개 합니다.
🐾 Kinesis 스케일링
샤드 분할과 샤드 병합으로 이야기 할 수 있습니다.
샤드 분할을 말 그대로 샤드를 분할하는 방법입니다.
예를들어 A에 너무 많은 처리량이 주어질떄 A를 a,a'로 나누는 방식으로 동작합니다.
- 하지만 이로인해 비용이 늘어납니다.
반대로 샤드 병합은 비용 절감을 위해서 사용 됩니다.
