애플리케이션 커뮤니케이션의 두 가지 패턴

1. 동기 커뮤니케이션: 애플리케이션끼리 직접적으로 연결된다. 물건 주문 서비스->배달 서비스와 같이 직접적으로 연결된 서비스

2. 비동기 혹은 이벤트 기반 유형: 대기열(Queue)등으로 불리는 미들웨어가 애플리케이션들을 연결한다. 구매서비스는 '누군가 물건을 구매했으니 이를 대기열에 포함시키겠다' 라고 하고 끝이다. 배송서비스는 대기열에 최근 구매 내역이 있는지를 확인하고 해당 요소를 반환받으면 배송서비스가 시작된다. 서로 직접적으로 소통하지 않는다.

어플리케이션 간의 동기화는 때때로 문제가 될 수 있다. 한 서비스가 다른 서비스를 압도하는 경우 운용이 정지되기 때문에 트래픽이 갑자기 급증하거나 아무것도 예측할 수 없을 때 일반적으로 애플리케이션을 분리하고 분리 계층을 확장하는 것이 좋다.

대기열 모델의 경우 SQS, pub/sub 모델의 경우 SNS, 실시간 스트리밍을 하고 대용량 데이터를 다룬다면 Kinesis로 분리 가능하다.

---

SQS(Simple Queue Service)

• SQS는 간단한 대기 서비스이다. SQS 대기열에는 메세지를 포함한다.
• SQS 대기열에 메시지를 보내는 주체를 생산자라고 한다. 생산자는 한 개 이상일 수 있다.
• 메시지를 처리하고 수신해야 하는 대상을 소비자라고 한다. 소비자는 대기열에서 소비자 앞으로 온 메시지가 있으면 메시지를 폴링해서 정보를 얻는다.
• 소비자는 메시지를 처리하고 대기열에서 그 메세지를 삭제한다.
• 완전 관리형 서비스이며 애플리케이션을 분리하는데 사용된다.
• 무제한 처리량으로 초당 원하는 만큼 메시지를 보낼 수 있다. 대기열에 있는 메시지 수에도 제한이 없다.
• 각 메시지는 기본값으로 4일 동안 대기열에 남아있고 최대 14일까지 있을 수 있다. 그 시간 내에 메시지를 처리하지 않으면 소실된다.
• 지연시간이 짧아 SQS는 메시지를 보내거나 SQS에서 메시지를 읽을 때마다 게시 및 수신 시 10밀리초 이내로 매우 빠르게 응답을 받게 된다.
• SQS의 메시지는 전송된 메시지당 256KB 미만이어야 한다.
• SQS가 매우 높은 가용성 및 내구성을 제공하기 위해 메시지를 여러 번 처리할 수 있다. 예를 들어, 네트워크 문제나 서버 문제로 인해 메시지가 두 번 전송될 수 있다.
• best effort ordering이라는 뜻으로 out of order 메시지를 보낼 수도 있다.

메시지 생산자와 소비자

👉🏻 생산자는 SDK (SendMessage API)를 사용하여 필요한 정보를 담아 메시지를 보낸다.

👉🏻 소비자는 EC2 인스턴스, 온프레미스 서버, AWS Lambda가 될 수 있다.

• 소비자는 SQS메시지를 폴링(poll 함수 호출)하여 소비자가 대기열에 자신의 앞으로 온 메시지가 있는지 묻는다.
• 소비자는 한 번에 최대 10개의 메세지를 받는다.
• SQS대기열에 메세지가 있으면 메시지를 처리한 다음 삭제한다.
• SQS 대기열은 메세지를 동시에 수신하고 처리할 소비자를 여러 개 가질 수 있다.
  예시) 3개의 EC2인스턴스가 소비자일 때, 소비자1에서 충분히 처리가 되지 않으면 다른 소비자가 수신하게 됨.

ASG에서 CloudWatch 지표중에 ApproximateNumberOfMessages(대기열의 길이) 지표로 알람을 만들어 대기열의 길이가 특정 수준을 넘어가면 오토스케일링하도록 설정할 수 있다.

예를 들어 비디오를 처리하는 애플리케이션이 있다고 하자. 프론트엔드에서 비디오를 처리하고 S3에 저장하면 웹사이트의 속도가 느려질 수 있다. 대신 애플리케이션을 분리해 파일 처리 요청과 실제 파일 처리가 서로 다른 애플리케이션에서 발생할 수 있도록 한다. 파일 처리 요청을 받을 때마다 SQS 대기열로 메시지를 전송하는 것이다.

SQS 보안

HTTPS API를 사용해 메시지를 보내고 생성함으로써 전송 중 암호화 가능
KMS키를 사용해 미사용 암호화를 얻고 원한다면 클라이언트 측 암호화를 할 수도 있다.
액세스 제어를 위해 IAM 정책은 SQS API에 대한 액세스를 규제할 수 있다.
S3버킷 정책과 유사한 SQS 액세스 정책도 있다. 다른 서비스가 SQS 대기열에 S3이벤트 같은 것을 쓸 수 있도록 허용하려는 경우에 유용하다.

SQS 실습

1. SQS콘솔 > Create queue

Standard큐와 FIFO큐를 선택할 수 있다.
Standard큐는 최소 한 번 전달, 메시지 순서가 유지되지 않음
FIFO큐는 선입선출 배달, 메시지 순서가 유지되며 정확히 한 번 처리한다.

• FIFO큐를 선택했을 시:
  꼭 이름 뒤에 .fifo를 붙여야 한다.
  Content-based deduplication라는 설정이 추가되며 이는 5분 이내의 시간 동안 동일한 메시지가 두 번 발송됐을 경우 중복을 방지하는 설정이다.

2. 액세스 정책 설정

누가 이 대기열에 액세스할 수 있는지 정의한다.

3. Send and recieve message 선택

메시지를 전송할 수 있고 메시지를 받을 수도 있다.
처음엔 메시지가 없고 메시지를 작성하면 Messages available에 1이라고 뜬다. Poll for messages를 클릭하면 메시지를 수신할 수 있다.
수신된 메시지ID를 누르면 메시지의 해시, 발신자, 메시지를 받은 횟수, 바이트로 된 사이즈 등의 메타데이터를 볼 수 있다.
적절한 시간 내에 메시지를 처리하지 않으면 30초가 지나 메시지는 다시 대기열로 돌아가 Message Count가 늘어난다.

• FIFO큐를 선택했을 시: Message Group ID를 사용하면, 하나의 그룹 내에서 순서를 보장할 수 있다.

큐 설정 변경하기

SQS > Queues > 원하는 큐 선택 > Edit을 누르면 모든 설정을 편집할 수 있다.

대기열에 있는 모든 메세지 삭제(정리)하기

SQS > Queues > 원하는 큐 선택 > Purge 클릭
이 방법은 개발할 때는 유용한데 프로덕션에서는 하면 안됨.

SQS 메시지 가시성 시간 초과(Message Visibility Timeout)

소비자가 ReceiveMessage 요청을 하면 대기열에서 메시지가 반환되고 가시성 시간 초과가 시작된다.
기본적으로 메시지 가시성 시간 초과는 30초다. 30초 안에 메시지가 처리되어야 한다.
30초 안에 메시지를 처리하면 동일한 혹은 다른 소비자가 메시지 요청 API를 호출해도 메시지가 반환되지 않는다.
가시성 시간 초과 기간 내에서는 그 메시지는 다른 소비자들에게 보이지 않는다.
가시성 시간 초과가 경과되고 메시지가 삭제되지 않으면 메시지는 대기열에 다시 들어간다.
그럼 다른 호출자가 ReceiveMessageAPI를 호출하면 이전의 메시지를 또 받게 된다.
소비자가 메시지를 처리하는 데 시간이 더 필요하면 ChangeMessageVisibility라는 API를 사용해 SQS에 시간이 더 필요하다고 알려 다른 호출자에게 메시지가 보이지 않도록 요청할 수 있다.

✨가시성 시간 초과는 애플리케이션에 합당한 값으로 설정하고 소비자가 그보다 더 시간이 필요하면 ChangeMessageVisibility API를 요청한다!

SQS 롱 풀링(Long polling)

소비자가 대기열에 메시지를 요청하는데 대기열에 아무것도 없다면 메시지 도착을 기다리게 된다. 이것을 롱 폴링이라고 한다.

• 롱 폴링을 하는 두가지 이유
  1) 지연시간 줄이기
  2) SQS로 보내는 API호출 숫자 줄이기

• 작동방식

1. 비어있는 SQS대기열이 있다.
2. 소비자가 대기열에 폴링한다. (최대 20초간 폴링. 이렇게 하는 이유는 만약 대기열이 비어있다면 좀 기다려도 좋다는 뜻.)
3. 메시지가 대기열에 도착했을 때 소비자가 여전히 롱 폴링 중이라면 자동적으로 그 메시지가 소비자에게 전송되어 짧은 지연시간으로 도착함.

롱 폴링은 1초~20초 내로 구성이 가능하다. 더 길어질수록 좋다.

• 롱 폴링을 구성하는 두가지 방법
  1) 대기열 레벨에서 구성하여 폴링하는 아무 소비자로부터 롱 폴링 활성화
  2) WaitTimeSeconds를 지정하여 소비자가 스스로 롱 폴링을 하도록 선택

SQS FIFO Queue

대기열에 도착한 순서대로 메시지를 내보낸다.
순서를 확실히 보장하기 때문에 이 SQS 대기열의 처리량에는 제한이 있다.
메시지를 묶음으로 보낸다면 처리량은 초당 3,000개이며 묶음이 아니라면 초당 300개의 메시지를 처리한다.
중복을 제거하도록 해주는 기능이 있어 정확히 한 번만 보낼 수 있게 한다.
메시지의 순서를 유지할 필요가 있을 때 FIFO 대기열을 사용하면 된다.
SQS로 너무 많은 메시지를 보내지 않도록 처리량 제한도 가능하다.

---

Amazon SNS(Simple Notification Service)

• 직접 통합(Direct integration)을 써서 메시지 하나를 여러 수신자에게 보낼 수 있다.
• 수신 서비스를 추가할 때마다 통합을 작성하기 번거로우므로 Pub/Sub(게시/구독)을 사용할 수 있다.
• 게시자는 SNS Topic에 게시하고 해당 주제(Topic)에는 많은 구독자들이 있어 주제로부터 메시지를 수신하고 보관할 수 있다.
• Amazon SNS에서 이벤트 생산자는 한 SNS 주제에만 메시지를 보낸다. 이벤트 수신자 또는 구독자는 해당 주제와 관련한 SNS 알림을 받으려는 사람이다.
• 주제별로 최대 1,200만 이상의 구독자까지 가능하다.
• 계정당 가질 수 있는 주제 수는 최대 10만개이다.(추후 변경될 수 있음)

📍 SNS에서 구독자에게 게시할 수 있는 것들
1. 이메일 보내기
2. SMS 및 모바일 알림 보내기
3. HTTP 또는 HTTPS 엔드포인트로 직접 데이터 보내기
4. 메시지를 SQS 대기열로 보내기
5. Lambda에 보내기
6. Firehose를 통해 데이터를 S3나 Redshift로 보내기

📍 SNS로 데이터를 보낼 수 있는 AWS 서비스들
1. CloudWatch 경보
2. Auto Scaling 그룹알림
3. CloudFormation State Changes Budgets
4. S3버킷 DMS
5. Lambda
6. DynamoDB RDS이벤트 등

• SDK를 사용해 토픽에 메시지를 게시할 수 있다.
• 모바일 앱 SDK 전용 직접 게시방법으로도 게시할 수 있다.
  수신 가능 대상은 Google, GCM, Apple APNS 또는 Amazon ADM 구독자이다.
• 기본적으로 전송중 암호화와 KMS키를 사용한 저장 데이터 암호화가 있고 클라이언트 측 암호화가 있다.
• 액세스 제어는 IAM 정책 중심이다. 모든 SNS API가 IAM정책으로 규제된다.

SNS+SQS : 팬아웃(Fan Out)패턴

다수의 SQS 대기열로 메시지를 보내려 할 때 모든 SQS 대기열에 개별적으로 전송하려고 하면 문제가 발생할 수 있다. 어플리케이션 충돌이 발생해 실패하거나 SQS대기열을 추가하게 될 수도 있다.

개념은 SNS 토픽으로 한 번 메시지를 전송하고 원하는 만큼 SQS 대기열을 SNS토픽에 구독시키는 것이다.

이는 완벽하게 분리된 모델이고 데이터 손실이 없다. SQS로 데이터 지속성, 지연 처리, 작업 재시도 등의 효과를 얻을 수 있다. 이 패턴으로 시간이 지날수록 SQS대기열을 구독자로 더 추가할 수 있다. 그러기 위해 SQS 대기열 접근 정책을 SNS 토픽이 대기열에 쓸 수 있도록 허용해둬야 한다.

한 리전의 SNS토픽이 다른 리전의 SQS 대기열에 메시지를 보내는 것이 가능하다.

📍 사용사례
S3 이벤트 규칙에는 제한이 있는데, 예를 들어 객체가 생성되고 객체의 접두사가 images/ 처럼 이벤트 형식이 조합될 경우 오직 한 개의 이벤트 규칙만 존재할 수 있다.
이때 여러 개의 대기열로 S3 이벤트 알림을 보내고 싶으면 SNS를 사용해 팬아웃 패턴을 적용할 수 있다.

Amazon SNS - FIFO Topic

토픽의 메시지에 순서를 부여한다.
생산자가 메시지를 1,2,3,4 순서로 메시지를 보내면 구독자는 SQS FIFO 대기열이 될 수밖에 없고(SQS 표준도 됨) 순서대로 메시지를 받는다.

SNS FIFO 개념은 SQS FIFO와 같은 기능을 갖는다는 것이다.

• 즉, 메시지 그룹 ID에 따라 메시지 정렬
• 중복된 ID나 콘텐츠에 대해 중복제거
• SQS FIFO 대기열과 같은 처리량

SNS - 메시지 필터링(Message Filterling)

• SNS 토픽 구독자들에게 전송할 메세지를 필터링하는 JSON 정책
• 만약 구독에 필터링 정책이 없다면 기본적으로 모든 메시지를 수신하게 된다.
• 예를 들어 주문 메시지(state 항목이 포함된)가 SNS 토픽으로 들어왔을 경우 구독중인 SQS 대기열에 발주된 주문만 필터링(state가 Placed인 메시지)하는 JSON필터링 정책을 적용하여 정책에 부합하는 메시지만 대기열로 전송 받을 수 있다.

SNS 실습

1. Simple Notification Service 콘솔 > Create topic > 토픽이름 입력하고 Next step

2. 토픽 타입 선택

FIFO와 Standard중 선택한다.
1) Standard : 최선의 메시지 정렬, 최소한 한번의 메시지 전달, 초당 게시 횟수 측면에서 최고의 처리량을 얻을 수 있음. 다양한 구독대상들(SQS, Lambda, HTTP, SMS, 이메일)
2) FIFO : 엄격히 메시지 순서 유지, 초당 300번까지 게시 가능한 처리량, SQS FIFO 대기열만 구독가능.
FIFO 선택할 경우 Topic명이 .fifo로 끝나야한다.

3. 나머지 설정 적용

토픽의 메시지를 암호화 할 수 있다.
Access policy을 통해 누가 SNS Topic으로 전송할 수 있는지를 정의한다.
나머지는 일단 두고 생성 완료한다.

4. 구독자 생성

토픽을 선택하고 Create subcription을 눌러 구독을 생성한다.
✨프로토콜을 선택해야 하는데 Kinesis Data Firehose, SQS, Lambda, Email, Email-JSON, HTTP, HTTPS, SMS 중에 선택한다.
그리고 엔드 포인트(이메일이면 이메일주소)를 입력한다.
Subscription filter policy를 설정해서 필터링된 메시지만 받게 할 수도 있다.
이메일 주소를 입력했다면 이메일로 온 메일을 통해 구독을 승인해줘야 한다.

5. 메시지 생성

토픽을 선택하고 오른쪽 상단의 Publish message를 선택해 메시지를 생성한다.

---

Kinesis

• 실시간 스트리밍 데이터를 손쉽게 수집하고 처리하여 분석이 가능하다

실시간 데이터

• 애플리케이션 로그
• 계측
• 웹 사이트 클릭 스트림
• IoT 원격 측정 데이터 등
  데이터가 빠르게 실시간으로 생성된다면 모두 실시간 데이터 스트림으로 간주한다.

Kinesis는 네 가지 서비스로 구성되어 있다.

• Kinesis Data Stream : 데이터 스트림을 수집하여 처리하고 저장한다.
  • 시스템에서 큰 규모의 데이터 흐름을 다루는 서비스
  • 여러 개의 샤드로 구성되어 번호가 매겨져 있다. 샤드의 숫자는 프로비저닝 해야 한다.
  • 데이터는 모든 샤드에 분배되고 샤드는 데이터 수집률이나 소비율 측면에서 스트림의 용량을 결정한다.
  • Kinesis Data Stream으로 데이터를 보내는 생산자는 애플리케이션, 데스크톱, 휴대전화와 같은 클라이언트일 수도 있고 낮은 수준에서 AWS SDK를 활용하거나 높은 수준에서Kinesis Producer Library(KPL)을 활용하기도 한다. Kinesis Agent를 활용해 스트리밍할 서버에서 애플리케이션 로그를 처리할 수도 있다. 이 모든 생산자는 SDK에 의존하며 레코드를 전달한다.

    레코드는 파티션 키와 최대 1MB 크기의 데이터 블롭으로 구성된다.
    파티션 키는 레코드가 이용할 샤드를 결정하는 데 사용되고 데이터 블롭은 값 자체를 의미한다.

  • 생산자는 데이터를 스트림으로 초당 1MB를 전송하거나 샤드당 1초에 천 개의 메시지를 전송할 수 있다. (6개의 샤드면 초당 6MB or 6000개 메시지 얻기 가능)
  • 소비자는 KCL에 의존하는 애플리케이션, Lambda, 다른 Kinesis 세가지 서비스 들이 가능하다. 소비자가 레코드를 받으면 거기엔 파티션 키, 샤드에서 레코드의 위치를 나타내는 시퀀스 번호, 데이터 자체를 의미하는 데이터 블롭이 있다.
  • 여러 소비 유형이 존재한다. 샤드당 초당 2MB의 처리량을 모든 소비자가 공유할 수 있고, 소비자마다 샤드당 1초에 2MB씩 받을 수도 있다.(팬아웃방식)
  • 보존 기간은 1일에서 365일 사이로 설정 가능
  • 데이터가 일단 Kinesis로 들어오면 삭제 불가능 (불변성)
  • 파티션 키가 같은 메시지들은 같은 샤드로 들어가게 되어 키를 기반으로 데이터 정렬이 가능
  • 소비자는 KCL이나 SDK를 써서 직접 데이터를 작성할 수 있고 나머지 Kinesis서비스를 활용할 수도 있다.
  • 두가지 용량 유형💸
    • 프로비저닝 유형: 프로비저닝할 샤드 수를 조정하고 API를 활용해 수동으로 조정한다. 샤드를 프로비저닝할 때마다 시간당 비용이 부과된다. 사전에 사용량 계획이 가능하면 프로비저닝이 낫다.
    • 온디맨드 유형 : 프로비저닝, 용량관리가 필요없다. 기본적으로 초당 4MB 또는 초당 4천 개의 레코드를 처리하지만, 지난 30일 동안 관측한 최대 처리량에 기반해 자동으로 조정된다. 시간당 스트림당 송수신 데이터양(GB 단위)에 따라 비용이 부과된다.
  • 보안:
    • 리전에 배포되고 IAM 정책을 사용해 샤드를 생성하거나 읽어들이는 접근 권한을 제어할 수 있다.
    • HTTPS로 전송 중 데이터 암호화가 가능하고 미사용 데이터는 CMS로 암호화할 수 있다. 클라이언트 측 암호화도 가능.
    • VPC엔드포인트를 이용하면 인터넷을 거치지 않고 프라이빗 서브넷의 인스턴스에서 손쉽게 접근 가능하다.
    • 모든 API 요청은 CloudTrail로 감시할 수 있다.
• Kinesis Data Firehose : 데이터 스트림을 AWS 내,외부의 데이터 저장소로 읽어 들인다.
  • 생산자로부터 데이터를 가져올 수 있는 매우 유용한 완전 관리형 서비스
  • Kinesis Data Streams에서 본 모든 생산자는 모두 Kinesis Data Firehose로 생성될 수 있다.
  • Kinesis Data Firehose는 소스에서 데이터를 가져온다. 보통 Kinesis Data Streams가 가장 일반적이며(CloudWatch, IoT Core, SDK로 앱에서 직접 전송 등의 방법도 가능하고 K.D.S의 생산자는 다 직접 Firehose로도 전송이 가능하다)
    Kinesis Data Firehoses는 데이터를 작성하는 방법을 알고 있기 때문에 코드를 작성하지 않고 데이터를 대상에 기록한다.
  • 수신처는 AWS 서비스 중 S3, Redshift, OpenSearch로 보낼 수 있고 파트너 수신처로는 Datadog, Splunk, Neq Relic, MongoDB로 데이터를 보낼 수 있다. 또는 HTTP 엔드포인트가 있는 자체 API가 있는 경우 사용자 지정 수신처로 데이터를 보낼 수 있다.
  • 자동 스케일링에 서버리스다.
  • 타사 파트너와 사용자 지정 수신처는 Firehose를 통과하는 데이터에 대해서만 비용을 지불한다.
  • 수신처까지 일괄적으로 데이터를 작성하기 때문에 거의 실시간으로 작동한다.
  • 버퍼링을 활성화하면 최대 900초까지 설정할 수 있고 버퍼 크기(최소 1MB)도 지정해야 한다.
  • 여러 데이터 형식과 전환, 변환, 압축을 지원한다. 필요한 경우 람다로 자체적인 데이터 변환을 쓸 수도 있다.
  • 실패한 모든 데이터나 백업을 S3버킷으로 보낼 수 있다.
  • 데이터 스토리지가 없으므로 Kinesis Data Firehose에서 데이터를 재생할 수 없다.
• Kinesis Data Analytics : SQL언어나 Apache Flink를 활용해 데이터 스트림을 분석한다.

• Kinesis Video Stream : 비디오 스트림을 수집하고 처리하여 저장한다.

Kinesis 실습

Kinesis Data Stream

1. Kinesis 콘솔 > Kinesis Data Streams 체크하고 Create data stream 선택

선택하기 전 과금 정보를 확인할 수도 있다.
샤드마다 시간당 부과되는 달러가 표시된다.
Data STream으로 PUT을 보내거나 데이터를 전송하는데 부과되는 비용도 볼 수 있다.

2. 데이터 스트림 용량 정하기

On-demand와 Provisioned 중에 고른다.
1) 온디맨드 모드에서는 용량을 걱정하지 않아도 알아서 조정해준다.
2) Provisioned에서는 제공 샤드를 설정해야 한다. 샤드 추정도구로 초당 얼만큼의 레코드를 보내는지, 레코드 크기, 소비자 몇명인지에 따라 추정가능하다.

선택을 하면 제공되는 쓰기 용량과 읽기 용량을 확인할 수 있다.
둘 다 프리티어는 없다.

생성을 완료한다.

3. Applications > Producers와 Consumers 확인

Producers : Kinesis Agent, AWS SDK, Amazon KPL 중 하나를 선택해 Kinesis Data Stream으로 데이터를 스트리밍할 수 있다. (CloudShell을 통해 SDK 사용 가능)

Consumers : Kinesis Data Analytics, Kinesis Data Firehose, Kinesis Client Library(KCL), 람다(Lambda) 등이 될 수 있다.

Configureation 탭에서 샤드 개수를 수정해 스트림을 조정할 수도 있다.

4. SDK로 데이터 스트림 전송하기

CloudShell에서 aws --version을 입력해 현재 버전에 맞는 명령어를 사용한다.
클라우드 쉘은 나의 IAM 자격 증명이 자동으로 구성되어 알아서 된다.

aws kinesis put-record \
    --stream-name my-kinesis-stream \
    --partition-key my-key \
    --data "SGVsbG8sIEtpbmVzaXMh"  # Base64 인코딩된 "Hello, Kinesis!"

스트림 이름과 데이터를 보내고자 하는 파티션 키, 데이터를 입력하여 전송한다.

--data "$(echo -n 'Hello, Kinesis!' | base64)"

Base64 인코딩 되지 않은 평문으로 보내려면 이런 식으로 보낸다.

5. 데이터 스트림 소비하기

aws kinesis get-shard-iterator \
    --stream-name my-kinesis-stream \
    --shard-id shardId-000000000000 \
    --shard-iterator-type TRIM_HORIZON

SDK를 통해 데이터를 읽어오려면 어떤 샤드에서 읽어오는지 ShardID를 정확히 명시해줘야 한다. (KCL을 사용한다면 라이브러리가 다 처리해준다.)
TRIM_HORIZON은 스트림의 맨 처음부터 읽을 것이라는 뜻이다. LATEST 타입을 선택하면 CLI 명령을 실행하는 순간부터 그 이후 보내지는 레코드만 읽어온다.

엔터를 치면 샤드 반복자(Shard Iterator)가 나온다. 샤드 반복자는 레코드를 소비하는데 다시 사용될 수 있다.

aws kinesis get-records --shard-iterator YOUR_ITERATOR_VALUE

여기에서 샤드 반복자(Shard Iterator)를 YOUR_ITERATOR_VALUE 위치에 입력해준다.
엔터를 누르면 여러 레코드가 나온다. 데이터는 base64로 인코딩 되어 나타난다.
그 다음 NextShardIterator에 있는 값을 사용해서 그 지점부터 다음에 소비할 수 있다.

Kinesis Data Firehose

1. Kinesis 콘솔 > Delivery streams > Create delivery stream 선택

2. Source를 선택한다.

데이터의 소스를 선택한다. Kinesis Data Streams가 가장 일반적이며 CloudWatch, IoT Core, SDK로 앱에서 직접 전송 등의 방법도 가능하다.

3. Destination을 선택한다.

데이터를 보낼 곳을 지정한다.

4. 나머지 설정을 진행한다.

전송 스트림 이름은 자동 입력된다.

레코드 변환 및 형식 섹션:
1) 람다를 선택해 람다로 레코드 변환, 필터, 압축해제, 형식 변환을 수행할 수도 있다.
2) Convert record format을 선택하면 데이터를 어디로 보내느냐에 따라 데이터 형식을 파켓이나 ORC로 변환할 수 있다.

Parquet(파켓) & ORC란?
대용량 데이터를 효율적으로 저장하고 분석하기 위한 컬럼 기반 저장 포맷
특히 Hadoop, Spark, AWS Athena, BigQuery 같은 빅데이터 처리 환경에서 많이 사용

전송지가 S3라면 데이터를 저장할 접두사와 에러를 출력할 접두사를 설정할 수도 있다.

버퍼 힌트 섹션에서 버퍼를 설정할 수 있다.
버퍼는 데이터를 대상에 전송하기 전에 쌓아두는 기능이다.
1) Buffer Size : 버퍼 사이즈만큼 데이터가 버퍼에 차기를 기다렸다가 다 차면 대상에 데이터를 전송한다.
데이터를 빨리 보내는 게 중요하면 버퍼 size를 작게 설정, 효율을 높이고 싶으면 크게 설정.
2) Buffer interval: 버퍼가 차지 않는다면 언제까지 기다렸다가 전송하는 지를 설정한다. 기간이 지나면 다 차지 않았어도 전송해버린다.

데이터 압축이나 레코드 암호화 설정도 필요에 따라 하면 된다.

고급설정에서는 권한 설정을 위해 IAM Role을 생성한다.

---

Kinesis와 SQS FIFO에서의 데이터 정렬

Kinesis

• 파티션 키를 사용해 샤드 레벨에서 데이터를 정렬한다.
• Kinesis가 파티션 키를 해시해서 어느 샤드로 보낼지 결정한다.

SQS FIFO

• SQS 표준 방식에는 순서가 없어서 FIFO의 그룹 ID를 사용하지 않으면 보내진 순서에 따라 메시지가 소비된다.
• 소비자는 하나만 존재한다. 만약 소비자 숫자를 스케일링하고 서로 연관된 메시지를 그룹화하려는 경우 그룹 ID를 사용할 수 있다.
• 그룹 ID를 사용하면 FIFO대기열은 FIFO내부에 두 개 그룹이 생기고 정의한 그룹마다 각각 소비자를 가질 수 있게 된다.
• FIFO큐의 대기열은 하나 뿐이다. 샤드 및 파티션을 정의할 필요 없이 하나만 있다.
• 각 소비자가 특정한 그룹 ID와 연결된다.

---

📌 SQS vs SNS vs Kinesis 비교표

특징	SQS (Simple Queue Service)	SNS (Simple Notification Service)	Kinesis Data Streams
주요 개념	메시지 큐 (Queue)	퍼블리시/구독 (Pub/Sub)	실시간 데이터 스트리밍
데이터 흐름	1:1 (Producer → Consumer)	1:N (Producer → 여러 Subscriber)	1:N (Producer → 여러 Consumer)
메시지 전달 방식	메시지 하나씩 전달 & 삭제	여러 구독자에게 동시에 전송	지속적인 데이터 스트림 처리
데이터 보관	소비 후 삭제 (최대 14일)	보관 X (즉시 전달)	보존 기간 내(최대 365일) 재처리 가능
사용 사례	비동기 작업 처리 (예: 주문 처리, 백그라운드 작업)	다중 시스템 알림 (예: 장애 감지, 이메일/SMS 알림)	실시간 로그 분석, IoT 데이터 수집
주요 특징	✔ FIFO 지원 가능 (순서 보장) ✔ 개별 메시지 처리	✔ 여러 프로토콜 지원 (Lambda, HTTP, SMS, Email 등)	✔ 실시간 대용량 데이터 처리 ✔ 데이터 재처리 가능
예제 사용처	EC2 → SQS → Lambda (비동기 처리)	CloudWatch → SNS → Email (알림 시스템)	IoT 센서 → Kinesis → 분석 (실시간 데이터 분석)

---

📌 간단 정리

• SQS → "큐 시스템": 하나의 메시지를 한 번만 처리 (비동기 작업)
• SNS → "알림 시스템": 여러 곳에 한 번에 메시지 전달 (Pub/Sub)
• Kinesis → "실시간 데이터 스트리밍": 데이터를 계속 받아서 분석 (로그/IoT 데이터 처리)

---

Amazon MQ

애플리케이션을 클라우드에 마이그레이션하는 경우에는 SQS, SNS 프로토콜 혹은 API를 사용하기 위해 애플리케이션을 다시 구축하고 싶지 않고 MQTT, AMQP 등과 같은 기존에 쓰던 프로토콜을 사용하고 싶을 수 있는데 이때 Amazon MQ를 쓰면 된다.

• RabbitMQ와 ActiveMQ 두 가지 기술을 위한 관리형 메시지 브로커 서비스
• 개방형 프로토콜 엑세스를 제공한다.
• SQS, SNS처럼 확장성이 크지 않다. 고가용성을 위해 장애 조치와 함께 다중 AZ설정을 할 수 있다.
• 대기열 기능과 Topic 기능을 단일 브로커의 일부로 제공한다.

Amazon MQ의 장애조치

특정 리전 내의 두 개의 AZ가 있다.
1번 AZ는 ACTIVE 상태이고 2번 AZ는 STANDBY상태이다.
두 AZ에 MQ Broker를 추가하고 백엔드에 Amazon EFS를 둔다.
두 MQ Broker가 같은 데이터를 가질 수 있기 때문에 장애조치가 올바르게 시행된다.