Messaging
메시징 서비스를 통해 애플리케이션을 여러 계층으로 분리할 수 있다. 이를 통해 서비스 간 안정성이 보장되고 비동기 방식으로 동작하여 응답 속도가 빨라질 수 있다.
계층 별로 독립적인 확장도 가능하다.
Amazon SQS
개요
간단한 대기열 서비스이며, 메시지를 포함한다.
완전 관리형 서비스이며 애플리케이션을 분리하는 데 사용된다.
무제한 처리량을 제공한다. 따라서, 초당 원하는 만큼 메시지를 보낼 수 있고 대기열에도 원하는 만큼 메시지를 포함시킬 수 있다.
메시지는 기본적으로 4일 동안 대기열에 남아 있고, 대기열에 있을 수 있는 최대 시간은 14일이다. 따라서 대기열에 메시지를 보내자마자 소비자가 읽는 것이 좋고, 해당 보존 기간 내에 처리한 후 대기열에서 삭제해야 한다.
지연 시간이 짧아서 SQS는 메시지를 보내거나 읽을 때 10밀리초 이내로 매우 빠르게 응답을 받는다.
한 메시지의 크기는 256KB 미만이어야 한다.
SQS는 대기열 서비스이므로 높은 처리량, 높은 볼륨 등이 있어서 중복 메시지가 있을 수 있다.
out of order 메시지를 보낼 수도 있다.
생산자
SQS 대기열에 메시지를 보내는 주체
한 개 이상일 수 있다.
SDK(SendMessage API)를 사용하여 SQS에 메시지를 보낼 수 있다.
소비자
대기열에서 메시지를 처리하고 수신해야 하는 대상
대기열에서 메시지를 ReceiveMessage API를 통해 폴링하여 소비자에게 온 메시지를 읽는다. 처리된 메시지는 대기열에서 삭제한다.
SQS로부터 메시지를 폴링해 처리하는 코드를 애플리케이션에 작성해야 한다. 애플리케이션은 EC2 인스턴스 혹은 자체 온프레미스 서버, AWS Lambda의 람다 함수에서 실행할 수 있다.
여러 소비자가 SQS 대기열에서 메시지를 소비할 수 있다. 이 때 소비자 인스턴스를 ASG로 관리하고 CloudWatch를 통해 대기열의 메시지 개수(ApproximateNumberOfMessages)에 대한 알림을 보내 자동 스케일링되도록 할 수 있다.
한 번에 최대 10개의 메세지를 받는다.
메시지를 처리한 후에는 DeleteMessage API를 이용해 SQS의 메시지를 제거할 수 있다.
SQS를 사용해 비디오를 처리하는 애플리케이션은 다음과 같이 동작할 수 있다.
프론트엔드 계층은 요청을 받고 백엔드 계층은 비디오를 인코딩 처리하도록 분리한다.
요청을 받았을 때 비디오에 대한 정보를 SQS에 전달하여 백엔드 계층에서 이를 폴링해 인코딩 처리가 되도록 할 수 있다.
프론트엔드의 경우 다수의 요청 처리에 적합한 유형의 EC2 인스턴스를 사용할 수 있고 백엔드의 경우 비디오 처리를 수행할 때 그래픽 처리 장치인 GPU가 제공되는 EC2 인스턴스를 사용할 수 있다. 이를 통해 워크로드를 최적화할 수 있다.
이외에도 데이터베이스에 쓰기 요청을 애플리케이션이 직접 보내지 않고, SQS에 먼저 저장하면 컨슈머가 메시지를 기반으로 데이터베이스에 데이터를 저장할 수 있다.
HTTPS API를 사용하여 메시지를 보내고 생성할 수 있어 전송 중 암호화 보장한다. KMS 키를 사용하거나 클라이언트 측 암호화를 할 수도 있다.
IAM 정책을 통해 SQS API에 대한 접근을 규제할 수 있다.
SQS 액세스 정책을 통해 SQS 대기열에 대해 여러 계정이 접근할 수 있도록 하거나, 다른 서비스가 SQS에 메시지를 전송할 수 있도록 할 수 있다. (S3 버킷 정책과 유사하다.)
Message Visibility Timeout
소비자가 메시지를 폴링하면 해당 메세지는 다른 소비자들에게 일시적으로 보이지 않게 된다.
메시지 가시성 시간 초과 동안만 보이지 않게 되며 기본값은 30초이다. 이 시간이 지나면 다시 다른 소비자들에게 메시지가 보이게 된다.
메시지는 가시성 시간 초과가 되기 전에 처리되어야 한다. 만약 그렇지 않다면 메시지가 중복 처리될 수 있다.
소비자가 메시지를 처리하다가 메시지를 처리하는 데 시간이 오래 걸릴 것 같다면 가시성 시간 초과 기간이 벗어나지 않도록 ChangeMessageVisibility API를 통해 메시지 가시성 시간 초과 값을 다시 설정할 수 있다.
가시성 시간 초과를 매우 높게 설정하면 소비자가 충돌했을 때 메시지가 SQS 대기열에 보이기까지 몇 시간이 걸린다. 매우 낮은 값으로 설정하면 소비자가 해당 메시지를 처리할 시간이 충분하지 않으면 다른 소비자가 메시지를 여러 번 읽어 중복 처리될 수 있다.
가시성 시간 초과는 애플리케이션에 적합하게 설정되어야 한다.
0초에서 12시간까지 설정할 수 있다.
롱 폴링
폴링 방식이란 소비자가 큐에서 메시지를 요청할 때 현재 큐에 메시지가 없으면 메시지가 도착할 때까지 기다리는 것을 의미한다.
소비자가 큐를 폴링할 때 메시지가 도착할 때까지 기다릴 수 있는데, 롱 폴링을 사용하면 소비자가 API 호출 수를 줄일 수 있다. API 호출 수가 줄어들면 애플리케이션의 지연 시간이 감소한다. SQS에서 메시지를 받자마자 소비자에게 전송되기 때문이다.
롱 폴링은 1초에서 20초 사이로 설정할 수 있으며 오래동안 기다릴수록 더 효율적이고 SQS에 대한 API 호출 수가 줄어든다. 따라서 전체적으로 짧은 폴링보다 롱 폴링을 선호해야 한다.
WaitTimeSeconds 매개변수를 사용하여 큐 수준이나 API 수준에서 롱 폴링을 활성화할 수 있다.
FIFO Queues
큐에 있는 메시지에 대한 순서를 보장한다.
기본적으로 300 msg/s 처리량을 보장하며, 배치 사용 시 3000msg/s 를 보장한다.
중복 제거를 통해 정확히 1번 전송하는 기능을 제공한다. 중복 제거를 위해 deduplication ID를 메시지에 함께 넣는다.
메시지는 순서를 지키며 컨슈머로부터 소비된다.
메시지 그룹 ID를 기준으로 정렬된다.
FIFO Queues의 이름은
.fifo로 끝나야 하며, 해당 문자를 포함해 최대 80자로 작성해야 한다.만약 표준 대기열을 사용하는 기존 애플리케이션이 있고, FIFO 대기열의 정렬(ordering) 또는 정확히 한 번(exactly-once) 처리 기능을 이용하고 싶다면 대기열과 애플리케이션을 정확히 구성해야 한다. 기존의 표준 대기열을 FIFO 대기열로 변환할 수는 없다.
Amazon SNS
개요
Pub/Sub 방식을 이용해 하나의 토픽에 메시지를 보내면 구독자들이 메시지를 수신하는 방식으로 동작한다.
메시지 하나를 여러 수신자에게 보낼 때 적합하다.
이벤트 생산자는 한 SNS 토픽에만 메시지를 보낸다.
구독자는 해당 토픽에 있는 모든 메시지를 받는다. 메시지는 필터링할 수 있다.
토픽 별로 최대 1,200만 이상의 구독자까지 수용 가능하다.
계정당 가질 수 있는 토픽 수는 최대 10만 개이다.
SNS를 통해 메시지를 보내면, 구독자들은 이 결과를 바탕으로 이메일을 보내거나 문자 및 모바일 알림을 보내거나 지정된 HTTP 또는 HTTPS 엔드 포인트로 데이터를 보낼 수 있다. 또한 SQS, 람다, Firehose와 같은 AWS 서비스와 통합하여 메시지를 활용할 수 있다.
SNS는 다양한 AWS 서비스로부터 데이터를 수신할 수 있다.
Direct Publish 방식을 사용하면 토픽에 메시지를 보내는 대신 플랫폼 엔드포인트에 보내 Google GCM, Apple APNS, Amazon ADM 등 모바일 SDK를 통해 모바일 알림을 보낼 수 있다.
HTTPS API 혹은 KMS 키를 사용한 데이터 암호화를 제공한다. 클라이언트 측 암호화도 가능하다.
모든 SNS API는 IAM 정책으로 규제된다.
SNS 액세스 정책을 통해 SNS 토픽에 교차 계정 액세스 권한을 갖거나 S3 이벤트와 같은 서비스가 SNS 주제에 작성할 수 있도록 허용할 수 있다.
팬아웃 패턴
SNS 토픽으로 메시지가 오면 여러 개의 SQS 대기열로 메시지를 팬아웃하는 방식을 의미한다.
다수의 SQS 대기열로 메시지를 보내려 할 때 모든 SQS 대기열에 개별적으로 전송하려고 하면 애플리케이션에서 충돌이 발생하여 전송이 실패될 수도 있고, SQS 대기열을 더 추가할 때 애플리케이션을 수정해야 한다. 따라서 팬아웃 패턴을 사용하는 것이 좋다.
완벽하게 분리된 모델이며 데이터 손실이 없다.
SQS를 통해 데이터 지속성, 지연 처리, 작업 재시도 등의 장점을 가진다.
새로운 SQS 대기열을 SNS 토픽의 구독자로 쉽게 추가할 수 있다.
SNS토픽이 SQS 대기열에게 쓰기할 수 있도록 접근 정책을 허용해야 한다.
한 리전의 SNS 토픽이 다른 리전의 SQS 대기열에 메시지를 보낼 수 있다.
SQS 대기열 뿐만 아니라 이메일이나 Lambda 함수 등 다른 형식의 애플리케이션도 SNS 토픽을 구독하여 메시지를 받아볼 수 있다.
Kinesis Data Firehose를 통해 SNS에서 Amazon S3 또는 다른 AWS 서비스로 직접 데이터를 보낼 수 있다. SNS가 KDF와 직접적으로 통합되어있기 때문이다.
FIFO 토픽을 통해 토픽 메시지의 순서를 보장하는 방식을 사용할 수 있다. SQS FIFO와 유사한 특징을 가진다. SQS 기본 혹은 FIFO 대기열을 구독자로 가질 수 있다. 정렬, 중복 제거 시에 유용하다.
메시지 필터링이란 SNS 토픽 구독자들에게 전송할 메세지를 필터링하는 JSON 정책이다. 특정 대기열은 특정 문자열을 포함한 메시지만 처리하도록 하여 효율적으로 운영할 수 있다.
Amazon Kinesis
스트리밍 데이터를 쉽게 수집, 프로세스, 분석할 수 있도록 해주는 서비스이다.
애플리케이션 로그, 메트릭, 웹사이트 클릭 스트림 등 실시간 데이터를 입력받는다.
Kinesis Data Streams / Kinesis Data Firehose / Kinesis Data Analytics / Kinesis Video Streams 서비스를 각각 제공한다.
Kinesis Data Streams
실시간 데이터를 Amazon Kinesis Data Streams로 내보내거나 읽어오기 위한 서비스가 필요하다.
프로듀서
웹사이트, 디바이스 등에서 데이터를 가져와 Kinesis 데이터 스트림으로 보내기 위한 애플리케이션을 구성할 수 있다.
Kinesis 에이전트를 설치하여 메트릭과 로그를 Kinesis Data Streams로 보낼 수도 있다.
컨슈머
실시간 데이터를 사용하는 애플리케이션, 람다 함수, Amazon Data Firehose, Managed Service for Apache Flink 등이 될 수 있다.
데이터를 최대 365일 동안 스트림에 보관할 수 있다.
소비자에 의해 데이터를 재처리(replay) 할 수 있다.
Kinesis 데이터 스트림으로 데이터를 전송한 후에는 삭제할 수 없다. 만료될 때 까지 기다리는 수밖에 없다.
최대 1MB의 데이터를 Kinesis 데이터 스트림으로 전송할 수 있다.
동일한 파티션 ID를 가진 두 개의 데이터 포인트를 전송하면 데이터가 순서대로 정렬된다.
KMS 암호화 및 HTTPS 암호화를 제공한다.
높은 처리량을 위해 최적화된 프로듀서/컨슈머 애플리케이션을 작성하려면 KPL(Kinesis Producer Library), KCL(Kinesis Client Library)을 사용해야 한다.
용량 모드
프로비저닝 모드
스트림의 샤드 개수를 선택한다. 샤드란 스트림의 크기를 의미한다.
수천 개의 샤드를 가질 수도 있다.
샤드가 많을수록 인바운드 처리량이 늘어난다.
각 샤드에 대해 초당 1MB 읽기가 가능하며, 용량 측면에서는 초당 천 개의 레코드를 읽을 수 있다. 아웃 트래픽은 초당 2MB이다.
만약 초당 10,000개의 레코드 또는 초당 10MB를 스트림에 전송하려면, 10개의 샤드로 확장해야 한다.
샤드 수 조정은 수동으로 가능하다.
시간당 프로비저닝된 각 샤드에 대해 비용을 지불한다.
온디맨드 모드
Kinesis 데이터 스트림의 용량을 프로비저닝하거나 관리할 필요가 없다.
초당 약 4,000개의 레코드 또는 4MB의 기본 용량이 제공된다.
지난 30일 동안 관찰된 처리량에 따라 자동으로 Kinesis 데이터 스트림의 용량이 확장된다.
스트림마다 시간당 요금이 부과되며, Kinesis 데이터 스트림에 들어오고 나가는 데이터의 양에 따라 요금이 청구된다.
Amazon Data Firehose
소스에서 타깃 목적지로 데이터를 전송하는 서비스이다.
원래 Kinesis Data Firehose로 불렸지만, 현재는 Kinesis 이상의 기능을 수행하여 Amazon Data Firehose로 불린다.
애플리케이션, client와 같은 프로듀서가 필요하다.
SDK를 사용하거나 Kinesis 에이전트, Kinesis 데이터 스트림, Amazon CloudWatch, AWS IoT를 프로듀서로 사용할 수 있다.
Kinesis 데이터 스트림의 경우 Firehose가 직접 레코드를 가져와서 수신한다.
람다 함수를 사용하여 데이터를 변환할 수 있다.
데이터 타입을 변환하려 할 때 버퍼에 데이터가 쌓이고 가끔씩 플러시되어 많은 대상에 일괄 쓰기를 수행해야 하는 경우 유용하다.
예를 들어 Amazon S3로 데이터를 전송하기 전에 데이터를 CSV에서 JSON 형식으로 변경하려는 경우 람다 함수에서 작업을 수행할 수 있다.
데이터는 Amazon S3로 전송하거나, 분석을 수행하기 위해 Amazon Redshift로 데이터를 전송하거나, Amazon OpenSearch로 데이터를 전송할 수 있다.
Datadog, Splunk, New Relic, MongoDB와 같은 타사 파트너로도 데이터를 전송할 수 있다.
커스텀 HTTP 엔드포인트를 통해 데이터를 전송할 수도 있다.
백업을 위해 S3 버킷으로 전송된 모든 데이터 또는 실패한 데이터를 저장해둘 수 있다.
완전 관리형 서비스이며, 자동 확장 기능을 제공한다.
서버리스 방식이며 서비스 내에서 사용한 만큼만 비용을 청구한다.
Near Real-Time이다. 버퍼 용량을 크기 및 시간에 따라 조절한 후 한 번에 플러시하기 때문이다.
CSV, JSON, parquet, Avro 텍스트 또는 바이너리 데이터를 지원하며, 파이어호스 내에서 데이터를 parquet 또는 ORC 타입으로 변환할 수 있다. gzip 또는 snappy로 압축할 수도 있다.
Last updated
