Messaging System

SQS (Simple Queue Service)

• SQS의 핵심은 자료구조 큐다. 큐는 메시지를 포함한다.
• 메시지를 담기 위해서 프로듀서가  SQS 대기열에 메시지를 전송해야 한다.
• 프로듀서는 한 개일 수도 그 이상일 수도 있다.
• 여러 프로듀서가 여러 개의 메시지를 SQS 대기열에 보내게 할 수 있다.
• 큐에서 메시지를 처리하고 수신해야 하는 대상을 컨슈머라고 한다.
• 소비자는 큐에서 메시지를 폴링하는데 이는 대기열에게 소비자 앞으로 온 메시지가 있는지를 물어보는 것이다.
• 만일 큐에 메시지가 있으면 소비자는 이 메시지를 폴링해서 정보를 얻는다.
• 그리고 그 메시지로 처리를 하고 큐에서 그 메시지를 삭제한다.
• 여러 컨슈머가 SQS 큐에서 메시지를 소비할 수 있도록 할 수도 있다.
• 큐는 프로듀서와 컨슈머 사이를 분리하는 버퍼 역할을 한다.
• 컨슈머가 큐에서 데이터를 pull 하는 것이 핵심이며 완전 관리형 서비스다.

Standard Queue

• 완전 관리형 서비스이며 애플리케이션을 분리하는 데 사용된다.
• 초당 원하는 만큼 메시지를 보낼 수 있고 큐에도 원하는 만큼 메시지를 포함시킬 수 있습니다
• 처리량에 제한이 없고 큐에 있는 메시지 수에도 제한이 없다. 각 메시지는 수명이 짧다.
• 메시지는 기본값으로 4일 동안 큐에 남아 있고 큐에 있을 수 있는 최대 시간은 14일이다.
• 즉 큐에 메시지를 보내자마자 컨슈머가 읽고 해당 보존 기간 내에 처리한 후 큐에서 삭제해야 한다. 그렇지 않으면 소실된다.
• 지연 시간이 짧아서 SQS는 메시지를 보내거나 SQS에서 메시지를 읽을 때마다 게시 및 수신 시 10밀리초 이내로 매우 빠르게 응답을 받게 된다.
• SQS의 메시지는 작아야 한다. 전송된 메시지당 256KB 미만이어야 한다.
• SQS는 대기열 서비스이므로 높은 처리량, 높은 볼륨 등이 있어서 중복 메시지가 있을 수 있습니다
• 최선의 오더라는 뜻으로 품절 메시지를 보낼 수도 있다.

Message Producer

• 프로듀서는 SDK를 사용해 메시지를 SQS로 전송한다.
• SQS에 메시지를 보내는 API를 SendMessage라고 한다.
• 메시지가 작성되면 프로듀서가 해당 메시지를 읽고 삭제할 때까지 SQS 큐에 유지된다.
• 메시지가 삭제됐다는 것은 메시지가 처리됐다는 뜻이다.
• 표준 SQS는 무제한 처리량을 보장한다.

Message Consumer

• 코드로 작성해야 하는 애플리케이션이다.
• 이러한 애플리케이션은 EC2 인스턴스 즉 AWS 상의 가상 서버에서 실행될 수 있다.
• 원하는 경우 자체 온프레미스 서버에서 실행할 수도 있고 AWS Lambda의 람다 함수에서 실행할 수도 있다.
• 큐에는 소비자가 있고 소비자는 SQS 메시지를 폴링한다.
• 소비자가 큐에 자신의 앞으로 온 메시지가 있는지를 묻는다.
• SQS 큐에 메세지가 있으면 '여기 너를 기다리는 메세지가 있어'라는 유효한 응답을 받는다.
• 컨슈머는 이 메시지들을 처리할 책임이 있으므로, 메시지들을 DeleteMessage API로 큐에서 삭제한다.
• 그러면 다른 소비자들이 이 메세지를 볼 수 없게 되고, 메시지 처리가 완료된다.

다수의 Ec2 인스턴스 컨슈머

• SQS 큐에서 더 많은 메시지가 있어서 처리량을 늘려야 하면 소비자를 추가하고 수평 확장을 수행해서 처리량을 개선할 수 있다.
• 이런 경우에는 ASG(Auto Scaling groups)와 더불어 SQS를 사용한다.
• 컨슈머가 ASG의 내부에서 EC2 인스턴스를 실행하고 SQS 큐에서 메시지를 폴링한다.
• ASG는 일종의 지표에 따라 확장되어야 하는데 우리가 사용할 수 있는 지표는 큐의 길이다.
• ApproximateNumberOfMessages라고 한다.
• 모든 SQS 큐에서 쓸 수 있는 CloudWatch 지표다.
• 알람을 설정할 수도 있는데 큐의 길이가 특정 수준을 넘어가면 CloudWatch Alarm을 설정하자.
• 이 알람은 오토 스케일링 그룹의 용량을 X만큼 증가시킨다. 그러면 더 많은 메시지가 SQS 큐에 있을 수 있다.
• 만일 웹사이트에 오더가 폭주했다거나 해서 오토 스케일링 그룹이 더 많은 EC2 인스턴스를 제공하면 메시지들을 더 높은 처리량으로 처리할 수 있다.

SQS는 애플리케이션 티어간의 분리를 위해 사용한다.

SQS Security

• 메시지를 보내고 생성함으로써 전송 중 암호화를 하고 KMS 키를 사용하여 미사용 암호화를 얻고 원한다면 클라이언트 측 암호화를 할 수도 있다.
• 이는 클라이언트가 자체적으로 암호화 및 암호 해독을 수행해야 함을 의미한다. SQS에서 기본적으로 지원하는 것은 아니다.
• 액세스 제어를 위해 IAM 정책은 SQS API에 대한 액세스를 규제할 수 있고 S3 버킷 정책과 유사한 SQS 액세스 정책도 있다.
• SQS 큐에 대한 교차 계정 액세스를 수행하려는 경우나 곧 배울 SNS 혹은 Amazon S3 같은 다른 서비스가 SQS 큐에 S3 이벤트 같은 것을 쓸 수 있도록 허용하려는 경우에 매우 유용하다.

메시지 가시성 시간 초과

• 소비자가 메시지를 폴링하면 그 메세지는 다른 소비자들에게 보이지 않게 된다. 예시를 들어보자.
• 컨슈머가 ReceiveMessage 요청을 하면, 큐에서 메시지가 반환된다.
• 이제 가시성 시간 초과가 시작된다.
• 기본값으로 메시지 가시성 시간 초과는 30초다.
• 그 말은 이 30초 동안 메시지가 처리되어야 한다는 것이다.
• 그러면 동일한 혹은 다른 컨슈머가 메시지 요청 API를 호출하면 메시지가 반환되지 않는다.
• 시간 초과 기간 내에 또 다른 요청이 들어와도 메시지가 반환되지 않는다.
• 즉 가시성 시간 초과 기간 내에서는 그 메시지는 다른 소비자들에게 보이지 않는다.
• 하지만 가시성 시간 초과가 경과되고 메시지가 삭제되지 않았다면 메시지는 큐에 다시 넣는다.
• 그러면 다른 컨슈머 또는 동일한 컨슈머가 또 ReceiveMessage API 호출을 하면 이전의 그 메시지를 또 받게 된다.
• 가시성 시간 초과 기간 내에 메시지를 처리하지 않으면 메시지가 두 번 처리될 수도 있다는 것을 알 수 있다.
• 만일 컨슈머가 메시지를 적극적으로 처리하고 있지만 메시지를 처리하는 데 시간이 더 필요하다는 것을 알고 있는데 메시지를 처리하지 않아 가시성 시간 초과 기간을 벗어날 때를 위해 ChangeMessageVisibility라는 API가 있다.
• 즉 컨슈머가 메시지를 처리하는 데 시간이 더 필요하다는 것을 알고 있고 해당 메시지를 두 번 처리하고 싶지 않다면 컨슈머는 ChangeMessageVisibility API를 호출하여 SQS에 알려야 한다.
• 가시성 시간 초과는 애플리케이션에 합당한 것으로 설정되어야 하고 컨슈머는 시간이 조금 더 필요하다는 것을 알면 ChangeMessageVisibility API를 호출하도록 프로그래밍해야 한다.
• 그러면 더 많은 시간을 확보하고 해당 가시성 시간 초과 기간을 늘릴 수 있다.

SQS Long polling

• 컨슈머가 큐에 메시지를 요청하는데 대기열에 아무것도 없다면 메시지 도착을 기다리면 된다. 이것을 롱 폴링이라고 합니다
• 첫 번째 장점은 지연 시간을 줄이기 위해서다.
• 두 번째 장점는 SQS로 보내는 API 호출 숫자를 줄이기 위해서다.
• 롱 폴링을 구성하는 방법엔 두 가지가 있다.
• 큐 레벨에서 구성하여 폴링하는 아무 컨슈머로부터 롱 폴링을 활성화하는 방법이 있다.
• WaitTimeSeconds를 지정함으로 컨슈머가 스스로 롱 폴링을 하도록 선택할 수도 있다.
• 만약 시험에서 SQS 큐에 대한 API 호출 수를 최적화하고 지연 시간을 줄이는 법을 묻는다면 롱 폴링을 떠올려야 한다.

SQS FIFO Queue

• FIFO == 선입선출
• 큐에 첫 번째로 도착한 메시지가 큐를 떠날 때도 첫 번째가 되도록 큐 내의 순서가 정렬된다는 의미다.
• 즉 표준 큐보다 순서가 더 확실히 보장되는 것이다.
• FIFO Queue는 순서를 확실히 보장하기 때문에 이 SQS 큐의 처리량에는 제한이 있다.
• 묶음이 아닐 경우에는 초당 300개의 메시지를 처리하고 메시지를 묶음으로 보낸다면 그 처리량은 초당 3,000개가 된다.
• 중복을 제거하도록 해주는 SQS FIFO 대기열의 기능으로 인해 정확히 한 번만 보낼 수 있게 해 준다.
• 우리는 메시지가 소비자에 의해 순서대로 처리된다는 것을 알고 있다.
• 따라서 분리가 발생하거나 메시지의 순서를 유지할 필요가 있을 때 FIFO 대기열을 사용하면 된다.
• SQS로 너무 많은 메시지를 보내지 않도록 처리량에 제한도 할 수 있다.

SQS With ASG

• SQS 큐와 ASG가 있을 때 ASG 내의 EC2 인스턴스가 메시지를 SQS 큐에서 폴한다.
• 이는 ASG를 자동으로 큐 크기에 따라 확장시키기 위함으로 CloudWatch 지표인 큐 길이를 보고 결정할 수 있다.
• ApproximateNumberOfMessages라고 하는 이 지표는 대기열에 몇 개의 메시지가 남아 있는지를 표시한다.
• 이를 기반으로 경보를 지정할 수 있는데 가령 이 지표가 1,000을 넘는 경우 1,000개의 메시지가 대기열에서 처리를 기다리고 있다는 뜻으로 처리에 지연이 발생하고 있음을 파악할 수 있다.
• 따라서 경보를 생성하여 1,000개의 메시지가 대기 중임을 경보를 통해 알리면 이 경보가 EC2 인스턴스가 충분하지 않음을 근거로 오토 스케일링 그룹에 확장 동작을 트리거한다.
• 이렇게 하면 ASG에 더 많은 EC2 인스턴스가 추가되며 확장이 이루어져 메시지가 훨씬 더 빨리 처리된다.
• 동시에 SQS 큐의 크기는 줄어들어 이에 대한 축소 또한 실행된다.
• 확장이나 축소 모두 가능한데 여기까지가 ASG과 SQS 대기열의 핵심이다.
• 분리나 급격히 증가한 로드 혹은 시간초과 등의 문제에서 신속한 스케일링이 필요한 경우에는 SQS 큐를 떠올려야 한다.

SNS (Simple Notification Service)

• 메시지 하나를 여러 수신자에게 보낸다고 가정하면 pub/sub 구조를 사용하는 것이 이상적이다.
• 메시지를 토픽으로 publish 한다.
• 토픽에는 많은 구독자가 있으며 각 구독자는 SNS 토픽에서 해당 메시지를 수신하고 이를 보관할 수 있다.
• SNS에서 "이벤트 프로듀서"는 한 SNS 토픽에만 메시지를 보낸다.
• SNS 토픽 구독자는 해당 토픽으로 전송된 메시지를 모두 받게 된다.
• 그리고 메시지를 필터링하는 기능을 사용하는 경우에도 메시지를 받을 수 있다.
• 토픽 별로 최대 1,200만 이상의 구독자까지 가능하다. (추후 변경 가능)
• 계정당 가질 수 있는 토픽 수는 최대 10만 개다. (추후 변경 가능)
• SNS에서 직접 이메일을 보낼 수도 있고 SMS 및 모바일 알림을 보낼 수도 있다.
• 또한 지정된 HTTP 또는 HTTPS 엔드 포인트로 직접 데이터를 보낼 수도 있다.
• SNS는 SQS와 같은 특정 AWS 서비스와 통합하여 메시지를 큐로 직접 보낼 수도 있고
• 메시지를 수신한 후 함수가 코드를 수행하도록 Lambda에 보내거나 Firehose를 통해 데이터를 Amazon S3나 Redshift로 보낼 수 있다.
• SNS는 다양한 AWS 서비스에서 데이터를 수신할 수 있다.
• CloudWatch 경보 Auto Scaling 그룹 알림, CloudFormation State Changes Budgets, S3 버킷, DMS, Lambda, DynamoDB RDS 이벤트 등이 있다.
• AWS에서 알림이 발생하면 이러한 서비스가 지정된 SNS 토픽으로 알림을 보낸다.
• 구독자에게 메시지를 push 하는 부분이 중요하다. 완전 관리형 서비스다.

How to Publish

• SDK Topic Publish를 사용해 SNS에 메시지를 게시할 수 있다.
• 먼저 토픽을 만든 다음 하나 또는 여러 개의 구독을 만들고 SNS 토픽에 게시하면 된다.
• 그럼 모든 구독자가 자동으로 해당 메시지를 받는다.
• 혹은 모바일 앱 SDK 전용 직접 게시 방법이 있다.
• 플랫폼 애플리케이션을 만든 다음 플랫폼 엔드 포인트를 만들고 플랫폼 엔드 포인트에 게시하면 된다.
• 수신 가능 대상은 Google, GCM, Apple APNS 또는 Amazon ADM 구독자다.
• 모두 모바일 애플리케이션으로 알림을 수신한다.

Security

• 기본적으로 전송 중 암호화와 KMS 키를 사용한 저장 데이터 암호화가 있고 클라이언트가 SNS에 암호화된 메시지를 보내려는 경우를 위한 클라이언트 측 암호화가 있다.
• 액세스 제어는 IAM 정책 중심이다.
• 모든 SNS API가 IAM 정책으로 규제되기 때문이다.
• S3 버킷 정책과 매우 유사한 SNS 액세스 정책을 정의할 수 있다.
• SNS 토픽에 교차 계정 액세스 권한을 갖거나 S3 이벤트와 같은 서비스가 SNS 토픽에 작성할 수 있도록 허용하려는 경우 유용하다.

SNS + SQS Fan Out

• SNS 토픽에 메시지를 전송한 후 다수의 SQS 큐가 이 SNS 토픽을 구독하게 해보자.
• 큐들은 구독자로서 SNS로 들어오는 모든 메시지를 받는다.
• 이는 완전히 분리된 모델이며 데이터도 손실되지 않는다.
• SQS로 작업을 다시 시도할 수 있을 뿐 아니라 데이터 지속성, 지연 처리도 수행할 수 있다.
• 게다가 이런 방식으로 SNS 토픽을 구독하도록 더 많은 SQS 큐를 추가할 수도 있다.
• 이를 위해서는 앞서 살펴봤듯이 SQS 액세스 정책에서 SNS 토픽이 SQS 큐에 쓰기 작업을 할 수 있도록 허용해야 한다.
• 리전 간 전달도 가능하다.
• 즉 보안상 가능하다면 한 리전의 SNS 토픽에서 다른 리전의 SQS 큐로 메시지를 보낼 수 있다.

usecase

• 만약 여러 큐에 동일한 S3 이벤트 알림을 보내고 싶다면 어떻게 할까?
• 이럴 때 팬아웃 패턴을 사용한다.
• 예를 들어 S3 객체를 생성하여 S3 버킷에 이벤트를 형성하고 이 이벤트를 SNS 토픽으로 전송한 후 팬아웃 패턴으로 많은 SQS 큐가 SNS 토픽을 구독하게 합니다
• 물론 다른 유형의 애플리케이션, 이메일, Lambda 함수 등도 구독할 수 있다.
• 이런 식으로 팬아웃 패턴 덕분에 Amazon S3에서 발생하는 이벤트의 메시지가 여러 다른 목적지에 도달할 수 있다.

FIFO Topic

• Amazon SNS에는 토픽의 메시지 순서를 지정하는 FIFO, 즉 선입 선출 기능이 있다.
• 여기에서 프로듀서가 메시지 1, 2, 3, 4를 보내고 구독자는 1, 2, 3, 4의 순서로 메시지를 수신하는 SQS FIFO 큐가 된다.
• 이 SNS FIFO는 SQS FIFO와 유사하다.
• 메시지 그룹 ID에 따라 순서를 매기고 중복 제거 ID를 활용하거나 내용을 비교하여 중복 데이터를 제거하며 SQS FIFO 큐를 FIFO SNS 토픽의 구독자로 설정한다.
• 처리량은 제한적이며 SQS FIFO 대기열과 동일하다. SQS FIFO 큐만 SNS FIFO 토픽을 읽어 들일 수 있기 때문이다.

SNS FIFO + SQS FIFO + Fan Out

• SQS FIFO를 활용하여 팬아웃을 수행하려면 팬아웃, 순서, 중복 제거가 필요하다.

Message Filtering

• 팬아웃 패턴과 관련한 SNS의 기능은 SNS에서 메시지 필터링을 할 수 있다는 것이다.
• SNS 토픽을 구독할 때 전송되는 메시지를 필터링하는 데 사용되는 JSON 정책이다.
• 토픽에 어떤 필터링 정책도 없다면 모든 메시지를 받아들이며 이것이 기본 동작이다.
• 필터링 정책과 SQS 큐도 만들 수 있고 아무 필터링 정책 없이 SNS 토픽에 있는 모든 메시지를 받는 SQS 큐도 만들 수 있다.

Kinesis

• Kinesis를 활용하면 실시간 스트리밍 데이터를 손쉽게 수집하고 처리하여 분석할 수 있다.
• 실시간 데이터에는 애플리케이션 로그, 계측, 웹 사이트 클릭 스트림, IoT 원격 측정 데이터 등 다양하다.
• 데이터가 빠르게 실시간으로 생성된다면 모두 실시간 데이터 스트림으로 간주할 수 있다.
• Kinesis는 네 가지 서비스로 구성되어 있다.
• Kinesis Data Stream에서는 데이터 스트림을 수집하여 처리하고 저장한다.
• Kinesis Data Firehose에서는 데이터 스트림을 AWS 내부나 외부의 데이터 저장소로 읽어 들인다.
• Kinesis Data Analytics에서는 SQL 언어나 Apache Flink를 활용하여 데이터 스트림을 분석한다.
• 시험에는 나오지 않지만 Kinesis Video Stream에서는 비디오 스트림을 수집하고 처리하여 저장한다.

Kinesis Data Stream

• 시스템에서 큰 규모의 데이터 흐름을 다루는 서비스다.
• Kinesis Data Stream은 여러 개의 샤드로 구성되어 있고 이 샤드는 1번, 2번에서 N번까지 번호가 매겨진다.
• 이건 사전에 우리가 프로비저닝해야 한다.
• 예를 들어 Kinesis Data Stream을 시작할 때 스트림을 여섯 개 샤드로 구성하겠다고 결정해야 한다는 의미다.
• 데이터는 모든 샤드에 분배된다. 샤드는 데이터 수집률이나 소비율 측면에서 스트림의 용량을 결정한다.
• 프로듀서는 데이터를 Kinesis Data Stream으로 보낸다.
• 컨슈머는 다양하다. 애플리케이션일 수도 있고 데스크톱이나 휴대전화와 같은 클라이언트일 수도 있고 매우 낮은 수준에서 AWS SDK를 활용하거나 더 높은 수준에서 Kinesis Producer Library (KPL)을 활용하기도 한다.
• Kinesis Agent를 활용해서 스트리밍할 서버, 예를 들면 Kinesis 스트림에서 애플리케이션 로그를 처리할 수도 있다.
• 프로듀서는 모두 동일한 역할을 한다. 매우 낮은 수준에서 SDK에 의존하며 Kinesis Data Stream에 레코드를 전달한다.
• 레코드는 근본적으로 두 가지 요소로 구성됩니다. 파티션 키와 최대 1MB 크기의 데이터 블롭으로 구성된다.
• 파티션 키는 레코드가 이용할 샤드를 결정하는 데 사용되고 데이터 블롭은 값 자체를 의미한다.
• 프로듀서는 데이터를 스트림으로 보낼 때 초당 1MB를 전송하거나 샤드당 1초에 천 개의 메시지를 전송할 수 있다.
• 데이터가 스트림에 들어가면 많은 컨슈머가 이 데이터를 사용한다.
• 컨슈머는 다양하다. SDK에 의존하거나 높은 수준에서는 Kinesis Client Library, KCL에 의존하는 애플리케이션이 있다.
• Kinesis 스트림에서 서버리스로 처리하려는 경우 Lambda 함수도 가능하다.
• Kinesis Data Firehose도 있고 Kinesis Data Analytics도 있다.
• 컨슈머가 레코드를 받으면 여기에는 파티션 키, 샤드에서 레코드의 위치를 나타내는 시퀀스 번호, 데이터 자체를 의미하는 데이터 블롭이 있다.
• Kinesis Data Stream에는 여러 소비 유형이 존재한다.
• 샤드마다 초당 2MB의 처리량을 모든 컨슈머가 공유할 수 있다. 아니면 컨슈머마다 샤드당 1초에 2MB씩 받을 수도 있다.
• 효율성을 높인 소비 유형, 즉 효율성을 높인 팬아웃 방식
• 정리하면 프로듀서가 Kinesis Data Stream에 데이터를 전송하고 데이터는 잠시 거기에 머물면서 여러 컨슈머에게 읽힌다.

특징

• 보존 기간은 1일에서 365일 사이로 설정할 수 있다. 즉, 데이터를 다시 처리하거나 확인할 수 있다.
• 데이터가 일단 Kinesis로 들어오면 삭제할 수 없으며 이러한 특징을 불변성이라고 한다.
• 또한 데이터 스트림으로 메시지를 전송하면 파티션 키가 추가되고 파티션 키가 같은 메시지들은 같은 샤드로 들어가게 되어 키를 기반으로 데이터를 정렬할 수 있다.
• 프로듀서는 SDK, Kinesis Producer Library (KPL), Kinesis Agent를 사용하여 데이터를 전송할 수 있고 컨슈머는 Kinesis Client Library (KCL)나 SDK를 써서 직접 데이터를 작성할 수 있다.
• 아니면 AWS에서 관리하는 Lambda나 Kinesis Data Firehose, Kinesis Data Analytics를 활용할 수도 있다.

Capacity Modes

• Kinesis Data Stream에는 두 가지 용량 유형이 있다.
• 먼저 전통적인 용량 유형으로 프로비저닝 유형이 있다.
• 여기에서는 프로비저닝할 샤드 수를 정하고 API를 활용하거나 수동으로 조정한다.
• Kinesis Data Stream에 있는 각 샤드는 초당 1MB나 1천 개의 레코드를 받아들이고 출력량의 경우에는 각 샤드가 초당 2MB를 받아들인다.
• 이는 일반적인 소비 유형이나 효율성을 높인 팬아웃 방식에 적용할 수 있다.
• 다만 샤드를 프로비저닝할 때마다 시간당 비용이 부과되므로 사전에 심사숙고해야 한다.
• 두 번째는 온디맨드 유형이다.
• 여기에서는 프로비저닝을 하거나 용량을 관리할 필요가 없다. 시간에 따라 언제든 용량이 조정된다.
• 기본적으로는 초당 4MB 또는 초당 4천 개의 레코드를 처리하지만 이 용량은 지난 30일 동안 관측한 최대 처리량에 기반하여 자동으로 조정된다.
• 이 유형에서는 시간당 스트림당 송수신 데이터양(GB 단위)에 따라 비용이 부과된다.
• 두 유형은 비용 산정 방식이 다르다.
• 어쨌든 사전에 사용량을 예측할 수 없다면 온디맨드 유형을 선택하자.
• 하지만 사전에 사용량을 계획할 수 있다면 프로비저닝 유형을 선택하자.

보안

• IAM 정책을 사용하여 샤드를 생성하거나 샤드에서 읽어 들이는 접근 권한을 제어할 수 있다.
• HTTPS로 전송 중 데이터를 암호화할 수 있으며 미사용 데이터는 CMS로 암호화할 수 있다.
• 클라이언트 측에서 데이터를 암호화하거나 해독할 수 있으며 이를 클라이언트 측 암호화라고 한다.
• 이는 직접 데이터를 암호화하고 해독해야 하기 때문에 수행하기 더 어렵다. 하지만 그만큼 보안이 더 강화된다.
• Kinesis에서 VPC 엔드포인트를 사용할 수 있다.
• 이를 이용하면 Kinesis에 인터넷을 거치지 않고 프라이빗 서브넷의 인스턴스에서 직접 손쉽게 접근할 수 있다.
• 마지막으로 모든 API 요청은 CloudTrail로 감시할 수 있다.

Data Firehose

• 프로듀서에서 데이터를 가져올 수 있는 유용한 서비스이며, 프로듀서는 Kinesis Data Stream에서 본 무엇이든 될 수 있다.
• 즉, 애플리케이션, 클라이언트, SDK, KPL, Kinesis Agent 모두 Kinesis Data Firehose로 생산할 수 있다.
• Kinesis Data Stream과 아마존 CloudWatch (로그 및 이벤트) 그리고 AWS IoT도 Kinesis Data Firehose로 생산할 수 있다. 이 모든 애플리케이션이 Kinesis Data Firehose로 데이터를 전송하면 Kinesis Data Firehose는 람다 기능을 활용해 데이터를 변환할지 선택할 수 있는데 이는 옵션이다.
• 일단 데이터를 변환하면 배치로 수신처에 쓸 수 있다.
• Kinesis Data Firehose는 소스에서 데이터를 가져오는데 주로 Kinesis Data Stream이다. 그리고 수신처에 데이터를 쓸 수 있다.
• 이때 Kinesis Data Firehose가 데이터 쓰는 법을 알기 때문에 별도로 코드를 쓸 필요가 없다.
• Kinesis Data Firehose의 수신처는 세 종류가 있다.
• 첫 번째 범주는 AWS 수신처다. (매우 중요)
• S3가 있다. 모든 데이터를 아마존 S3에 쓸 수 있다.
• 데이터 웨어하우스인 아마존 레드시프트도 있는데, 여기에 데이터를 쓸 때는 아마존 S3에 데이터를 쓰면 Kinesis Data Firehose가 복사 명령어를 내보낸다. 이 복사 명령어가 아마존 S3의 데이터를 아마존 레드시프트로 복사하는 것이다.
• AWS 범주의 마지막 수신처는 아마존 ElasticSearch다.
• 써드 파티 파트너 수신처도 있다. 데이터독, 스플렁크, 뉴렐릭, 몽고DB  다양한 수신처로 Kinesis Data Firehose가 데이터를 전송할 수 있다.
• 마지막으로, 만약 HTTP 엔드포인트가 있는 자체 API를 보유하고 있다면 Kinesis Data Firehose를 통해 커스텀 수신처로 데이터를 보낼 수 있다.
• 데이터가 이러한 수신처로 전송되고 나면 우리에게는 두 가지 옵션이 있다.
• 모든 데이터를 백업으로 S3 버킷에 보내거나, 혹은 수신처에 쓰이지 못한 데이터를 실패 S3 버킷에 보낼 수도 있다.
• Kinesis Data Firehose는 완전 관리형 서비스다.
• 관리가 필요하지 않으며, 자동으로 용량 크기가 조정되고, 서버리스이므로 관리할 서버가 없다.
• Kinesis Data Firehose를 통하는 데이터에 대해서만 비용을 지불하면 되므로 아주 효율적이다.
• 근 실시간으로 이루어집니다. 왜 근 실시간이냐면 Kinesis Data Firehose에서 수신처로 데이터를 배치로 쓰기 때문이다.
• 전체 배치가 아닌 경우 최소 60초의 지연시간이 발생하거나, 데이터를 수신처에 보내는 데 한 번에 적어도 1MB의 데이터가 있을 때까지 기다려야 한다. 그러므로 실시간 서비스가 아니라 실시간에 가까운 서비스다.

Kinesis Data Stream VS Kinesis Data Firehose

• 시험에 Kinesis Data Stream을 사용할 경우, Kinesis Data Firehose를 사용해야 하는 경우를 구분해야 하는 문제가 나온다.
• Kinesis Data Stream은 데이터를 대규모로 수집할 때 쓰는 스트리밍 서비스고, 프로듀서와 컨슈머에 대해 커스텀 코드를 쓸 수 있다.
• 실시간으로 이루어지며약 70ms 혹은 200ms 정도의 지연시간이 발생한다.
• 용량을 직접 조정할 수 있어 샤드 분할이나 샤드 병합을 통해 용량이나 처리량을 늘릴 수 있다.
• 제공한 용량만큼 비용을 지불하면 되며, 데이터는 1일에서 365일간 저장된다. 덕분에 여러 소비자가 같은 스트림에서 읽어 올 수 있고, 반복 기능도 지원된다.
• Kinesis Data Firehose도 수집 서비스로 데이터를 아마존 S3나 레드시프트, ElasticSearch 써드 파티 파트너나 자체 HTTP로 스트리밍해준다.
• 완전 관리되며, 서버리스이고, 근 실시간으로 이루어진다.
• 자동으로 용량 조정되어 관련해 걱정할 필요 없고, Kinesis Data Firehose를 통과하는 데이터에 대해서만 비용을 지불하면 된다.
• 데이터 스토리지가 없어 Kinesis Data Firehose의 데이터를 반복하는 기능은 지원되지 않는다.

Kinesis의 SQS FIFO에 대한 데이터 정렬

• SQS FIFO는 그룹 ID 숫자에 따른 동적 소비자 수를 원할 때 사용하면 좋은 모델이다.
• Kinesis 데이터 스트림을 사용할 경우는 예를 들어 트럭 10,000대가 많은 데이터를 전송하고 또 Kinesis 데이터 스트림에 샤드당 데이터를 정렬할 때다.

Amazon MQ

• MQTT, AMQP 등과 같은 기존에 쓰던 프로토콜을 사용하고 싶을 수 있는데 이때 Amazon MQ를 쓴다.
• RabbitMQ와 ActiveMQ 두 가지 기술을 위한 관리형 메시지 브로커 서비스다.
• RabbitMQ와 ActiveMQ는 온프레미스 기술로 앞서 설명했던 개방형 프로토콜 액세스를 제공한다.
• Amazon MQ를 이용하면 해당 브로커의 관리형 버전을 클라우드에서 사용할 수 있다.
• 먼저 Amazon MQ는 무한 확장이 가능한 SQS나 SNS처럼 확장성이 크지는 않다.
• Amazon MQ는 서버에서 실행되므로 서버 문제가 있을 수 있다.
• 고가용성을 위해 장애 조치와 함께 다중 AZ 설정을 실행할 수 있다.
• Amazon MQ는 SQS처럼 보이는 큐 기능과 SNS처럼 보이는 토픽 기능을 단일 브로커의 일부로 제공한다.
• Amazon MQ의 고가용성은 어떨까요?
• us-east-1라는 리전에 us-east-1a와 us-east-1b 두 개의 가용 영역이 있다고 가정해보자.
• 영역 하나는 활성 상태 그리고 또 다른 영역은 대기 상태다.
• 이제 두 영역에 각각 활성, 대기 상태인 Amazon MQ 브로커를 추가한다.
• 장애 조치 실행을 위해 백엔드 스토리지에 Amazon EFS도 정의해야 한다.
• EFS는 네트워크 파일 시스템으로 다중 가용 영역에 마운트할 수 있다.
• 이렇게 설정하면 장애 조치가 일어날 때마다 대기 상태 영역 역시 Amazon EFS에 마운트되므로 첫 번째 활성 큐와 동일한 데이터를 가질 수 있고 따라서 장애 조치도 올바르게 실행된다.
• 클라이언트가 Amazon MQ 브로커와 통신해서 장애 조치가 실행되는 경우에도 Amazon EFS 덕분에 데이터가 저장된다.