[SAA] Integration

Integration / Messaging 

• 여러 애플리케이션을 배포할 때 서로 통신에 비동기를 사용하는 경우
• 부하 분산, 장애 전파 방지를 위해 사용
• 결합도가 낮음.

---

SQS

• 큐잉 모델 기반
• 완전 관리형
• 서비스 간 결합도 낮춤
• 메시지의 양과 처리량에 제한 없음
• [0, 14]일까지 메시지 보관
• 메시지 크기의 상한은 256KB
• 보통 id만 넘기고 그 id를 받고 쿼리 조회하는 용도로 사용. (메시지 크기 절약)
• 메시지 중복 가능
• 순서 보장 X

메시지 발행

• SDK(SendMessage API)를 사용해서 SQS에 메시지 발행
• SQS는 customer가 삭제하기 전까지 유지된다.
• scaling이 알아서 일어나기 때문에 제한 없이 요청 받을 수 있다.

메시지 소비(폴링)

• 소비자(consumer): ec2, 서버, 람다 등 뭐든 가능
• 한 번에 최대 10개의 메시지 가져올 수 있음
• 처리가 완료되면 DeleteMessage API 사용 (안하면 메시지 중복 발생)
• 물론 메시지 중복 방지를 위한 방어 루틴이 들어 있긴 함

여러 소비자의 메시지 소비

• 여러 소비자들은 메시지를 병렬적으로 받고 처리
• 최소 1회 이상 전달 보장.
• 동시에 메시지를 가져간 경우가 중복 처리되는 경우
• 가장 low latency의 소비자에게 넘겨서 최선의 메시지 전달
• 소비자는 메시지를 처리하고 삭제 (하지 않으면 중복 처리가 된다.)
• 메시지 처리량을 늘리기 위해 소비자 그룹을 수평적으로 확장 가능 (scale out)
• 수평적 확장에는 Kubernetes, ASG 등이 사용된다.

메시지 가시성 시간 제한

• 특정 소비자가 메시지를 가져간 경우, 메시지는 다른 소비자에게 보이지 않게 한다. 처리하고 난 후에 처리 다 하고 삭제
• 기본값 30초. 그러니까 메시지 처리를 30초 안에 끝내기
• 시간 제한이 끝나면 다시 보여진다.
• 시간 제한 내에 처리가 되지 않으면 다른 소비자가 다시 메시지를 가져갈 수 있다.
• 만약 더 걸릴 거 같으면 ChangeMessageVisibility API로 길게 유지 가능.
• 너무 길게 설정되어 있으면 실패 후속 처리가 늦어질 수 있다.
• 너무 짧으면 2회 이상 중복 처리 가능 

롱 폴링

• 기본적인 폴링은 메시지가 없으면 그냥 돌아온다. 이때 소켓 연결을 열고 닫는 오버헤드 발생
• 롱 폴링을 사용하면 메시지가 없을 떄 일단 1~20초 대기하고 요청이 오면 가져감. 안 오면 그냥 폴링이랑 똑같음.
• 요청 수가 빈번한 경우일 수록 롱 폴링의 효율성이 올라가겠지. (20초에 한번꼴)
• WaitTimeSeconds API, Queue 설정으로 설정가능

FIFO Queue

• 선입선출큐
• 최대 초당 300건, 배치를 사용하면 3000건 보냄
• 정확하게 1회 처리, 순차적으로 처리한다.

---

SQS 보안

• HTTPS API를 사용하여 전송 중 암호화
• 종단 암호화는 KMS를 사용
• 원한다면 클라이언트 사이드 암호화 가능
• SQS API의 접근 제어는 IAM으로
• SQS 접근 정책은 계정 단위로 접근할 때 유용. (S3 버킷 정책과 유사)
• 다른 서비스에서 SQS에 큐 메시지를 발행할 때 유용

---

SNS

• Pub / Sub 모델 (보내면 대충 구독자들이 가져감.)
• 발행자가 SNS 토픽에 메시지를 전달하면, 구독자 서비스들이 모두 가져갈 수 있는 구조
• 메시지 필터가능
• 토픽 수는 10만개 제한
• 토픽당 최대 1250만 개의 구독자 생성 가능
• 이벤트 발행자는 SNS 토픽에 메시지 전달만
• SNS가 직접 메시지를 발행할 수도 있다. (모바일 앱 전용으로 보임)
• 다른 서비스로 메시지를 전달할 때는 Kinesis Data Firehose를 사용할 수 있다.

메시지 발행

• 토픽 발행
  • SDK를 사용해서 발행 가능
  • 토픽 생성
  • 구독 생성
  • 메시지를 토픽에 발행
• 직접 발행
  • 모바일 SDK 사용
  • 플랫폼 앱 생성
  • 플랫폼 엔드 포인트 생성
  • 엔드 포인트에 직접 발행
  • GCM, APNS, ADM 등과 사용 가능

FIFO 토픽

• FIFO SQS와 유사하지만, 토픽 단위로 Message Group ID를 사용해서 순서를 정렬한다.
• 같은 그룹 내의 메시지는 또 순서대로 정렬 (같은 그룹 아니면 안됨)
• 순서를 보장해주지.
• Deduplication ID 혹은 Content Based Deduplication을 이용해서 중복 제거 가능
• SQS, FIFO SQS를 구독자로 설정 가능
• 제한된 부하 가짐

메시지 필터링

• 같은 토픽을 구독하더라도 메시지를 안 받아야 하는 경우가 있을 수 있다.
• JSON 정책을 기반으로 메시지 필터링 (Filter policy)
• 구독자는 필터링 정책이 없다면 모든 메시지를 수신한다. 
• 마찬가지로 제한된 부하를 갖는다. (성능과 정확도를 trade off)

---

보안

• 전송간 암호화는 HTTPS API
• 종단 암호화는 KMS
• 클라이언트도 클라이언트 사이드에서 암복호화 진행 가능
• IAM 정책으로 접근 제한
• 접근 정책은 계정 단위 접근에 유용 (S3와 유사)
• 접근 정책은 다른 서비스가 토픽에 대한 접근을 할 때도 유용

---

Fan-Out

• SNS에 푸시된 메시지를 SQS가 구독자가 되어 가져가는 것
• 데이터 손실이 없고 완전히 서비스 간 결합도를 낮출 수 있음.
• SQS가 데이터 영속성, 지연처리, 재시도 지원해줌. (정확도를 높여준다.)
• SQS가 SNS의 데이터를 받을 수 있게 접근 정책 설정 필수
• 다른 리전의 SQS에서도 사용 가능
• SQS 구독자를 계속 추가 가능
• ex. 동일한 S3의 이벤트(+prefix)를 여기저기에 뿌려줄 수 있다.

FIFO Fan-Out

• Fan-Out 구조
• 순서대로 정렬
• 중복 방지가 필요한 경우,
• FIFO SQS + FIFO SNS를 이용해 팬아웃 구성

---

Kinesis

• 스트리밍 서비스 구현을 위해 사용
• (준)실시간으로 스트리밍되는 데이터를 수집, 처리, 분석하는 서비스
• 실시간 데이터를 처리할 때 사용
• Kinesis Data Stream: 데이터 스트림을 수집, 처리, 저장
• Kinesis Data Firehose: 데이터를 AWS Data 저장소로 전달
• Kinesis Data Analytics: SQL 혹은 아파치 Link 등을 이용해 데이터를 분석할 때 사용
• Kinesis Video Streams: 영상 스트림을 수집, 처리, 저장

Kinesis Data Streams

• [1,365]일까지 데이터 유지
• 데이터 재처리 기능 내장
• 무결성 보장 (한번 들어오면 유지 기간동안 삭제될 수 없다.)
• 정렬 보장 (같은 파티션에 들어온 데이터는 같은 샤드에 들어감.)
• SDK, Kinesis Producer Library(KPL), Kinesis Agent 등을 통해 발행(produce) 가능
• Kinesis Client Library(KCL), SDK 등으로 소비자 구성
• Lambda, Firehose, Data Analytics 등은 관리형으로 제공되는 소비자. (SQS와 Lambda 같은 구성이라 연결만 하면 됨)
• 용량에 따라 Provisioned Mode, On-demand모드로 나뉜다.
• Provisioned Mode
  • 프로비저닝되는 샤드의 수와 용량을 API로 직접 설정
  • 각 샤드는 1MB/s로 수신, 2MB/s로 송신(Consumer의 합이 2MB/s이므로 느릴 수 있음)
  • 시간 당 프로비저닝된 샤드 별로 비용 청구
• On-demand Mode
  • 용량을 별도로 프로비저닝 및 관리할 필요 없음.
  • 기본 용량이 프로비저닝됨 (4MB/s 또는 초당 4000 record)
  • 최근 30일간의 피크를 기반으로 자동 스케일링
  • 시간 당 스트리밍과 GB 당 데이터 in / out으로 비용 지불 (사용한 만큼)

데이터 정렬

• 데이터 발행자가 여러개인 경우, 특정 발행자의 데이터 순서를 보장할 수 있다.
• Partition Key를 이용해서 순서 지정 가능
• Partition Key가 같으면 항상 동일한 샤드에 전송됨
• Consumer는 샤드에서 순차적으로 데이터를 뽑아가므로 순서 보장 가능.
• 샤드끼리는 병렬, 샤드에서는 직렬이니까 이를 잘 이용하는 것.

Kinesis Data Streams 처리 과정

• Producer(EC2, Client, SDK 등)가 Kinesis Data Streams에게 Record 전송
• Record는 Partition Key와 Data blob으로 구성
• Data blob은 최대 1MB 용량
• Record는 샤드로 구성돼서 쓰여지기 때문에 Kinesis가 병렬로 데이터 처리
• 하나의 샤드 당 최대 1MB/s 혹은 1000/s의 속도로 전송
• Kinesis가 데이터를 적절히 처리해서 Consumer에게 Record 전송
• Record는 Partition Key와 Data blob, Sequence No로 이뤄짐
• 마찬가지로 Record는 샤드로 구성돼서 보내지기 때문에 병렬적으로 Consumer(Lambda, SDK, Firehose 등)에게 제공 가능
• 하나의 샤드 당 최대 2MB/s로 보낼 수 있음. (Consumer 총합 2MB/s임. 쓰기가 1MB/s인데 읽기가 2MB/s라고 이상하게 생각말자.)

Kinesis Data Firehose

• 완전관리형 서비스
• 자동 스케일링
• 서버리스로 구동
• AWS 서비스, 3rd party 시스템, HTTP endpoint로 데이터 전송 가능
• 사용하는 데이터 용량만큼 비용 청구
• 배치 작업이므로 준실시간 서비스다. (버퍼 시간)
• 최소 1MB/s 데이터를 전송
• 다양한 데이터 포맷, 변환, 압축을 지원 (람다를 사용해서 데이터 변환도 가능)
• 자체적으로 데이터를 저장하는 기능이 없음

Kinesis Data Firehose 처리 과정

• 여러 데이터 스트림들이 Firehose로 전송됨
• 마찬가지로 kinesis에서 읽는 Record의 상한은 1MB다.
• Firehose는 람다로 전송해서 데이터를 변환하거나
• Batch를 통해서(버퍼로 묶어서) Datadog과 같은 APM 등 서드파티 파트너로 보낼 수도 있고
• S3와 같은 저장소, Redshift OpenSearch와 같은 데이터 분석
• 혹은 자체적 애플리케이션의 HTTP Endpoint로 전달 가능
• 전체 데이터 혹은 실패 데이터만 S3에 백업할 수도 있다.

---

보안

• IAM 정책을 기반으로 접근 제어
• 전송간 암호화 HTTPS
• 종단 암호화 KMS
• CSE 적용 가능
• VPC Endpoint를 사용해서 VPC 간 통신 가능
• CloudTrail로 모니터링 가능

---

Amazon MQ

• SQS, SNS는 클라우드 기반의 서비스라서 AWS 제공 프토콜을 사용함.
• 온프레미스 환경에서는 MQTT, AMQP, STOMP, Openwire, WSS 등의 프로토콜을 사용함.
• 하이브리드 클라우드나 마이그레이션 상황인 경우, 코드의 SDK를 뜯어내서 SQS, SNS로 바꾸는 것은 불가능
• RabbitMQ, Active MQ를 지원해서 쓸 수 있게 함.
• SQS, SNS에 비해 확장성이 낮음
• 멀티 AZ 구성 가능
• 토픽(Pub/Sub구조), Queue 구조 모두 지원

---

추가

완전 관리형 서비스들이 자체적인 접근 제한을 갖고 있는 경우가 많다.

APM은 모니터링 도구