Messaging

  • 메시징 서비스를 통해 애플리케이션을 여러 계층으로 분리할 수 있다. 이를 통해 서비스 간 안정성이 보장되고 비동기 방식으로 동작하여 응답 속도가 빨라질 수 있다.

  • 계층 별로 독립적인 확장도 가능하다.

대기열 모델에는 SQS를, pub/sub 모델의 경우 SNS를, 실시간 스트리밍을 하고 대용량 데이터를 다룬다면 Kinesis를 사용할 수 있다.

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