디커플링 애플리케이션(SQS, SNS, Kinesis)

(Stephane Maarek의 Udemy AWS Certified Solutions Architect Associate 강의를 참고했습니다.)

 

우리가 여러 애플리케이션을 배포한다고 하면, 이 애플리케이션들은 서로 통신이 필요하다. 예를 들어, 유튜브 같은 서비스를 생각해봤을 때, 사용자가 영상을 업로드하는 앱, 영상을 인토딩하는 앱, 썸네일을 만드는 앱, 알림을 보내는 앱 등등이 따로 동작하지만 서로 정보를 주고받아야 한다.

 

이때, 애플리케이션의 통신은 2가지 방식을 따른다. 우선 동기식(Synchronous) 방식은 바로 상대방의 응답을 기다리는 방식으로, 주문 후에 결제가 끝날 때까지 주문 서비스가 기다리는 상황을 생각해볼 수 있다. 또 다른 방식은 비동기식(Asynchronous)으로 메세지만 남겨두고 바로 다음 일을 하는 것이다.

 

여기서 동기식이 문제가 될 수 있다. 평소 트래픽보다 갑작스럽게 트래픽이 많아지는 경우, 서비스가 느려지거나 장애가 발생할 가능성이 있기 때문이다. 이럴 때는 애플리케이션끼리 직접 연결하지 않고 중간에 메시지 서비스를 두어 분리(Decouple)하는 방법을 사용한다. AWS에서는 Decouple을 위해 Queue 모델인 SQS, Publish/Subscribe 모델인 SNS, 실시간 스트리밍 데이터 처리 서비스인 Kinesis를 제공한다. 이 서비스를 통해 필요한 부분만 독립적으로 확장하는 것이 가능하다.

1. SQS

SQS 작동 방식

 

SQS는 큐(Queue)를 사용한 간단한 대기 서비스이다. 하나 또는 여러 개의 주체가 메시지를 SQS 큐, 즉 대기열에 전달하여 저장한다. 이를 소비하는 주체는 큐로부터 메시지를 받아 처리하여 대기열에서 삭제한다. 대기열 서비스는 생산자와 소비자 사이를 분리하는 버퍼 역할을 수행하는 것이다. SQS는 AWS에서 제공하는 가장 오래된 서비스인만큼 확실하게 구축되어 있다.

 

SQS의 특징을 살펴보자면, 우선 무제한 처리량을 얻을 수 있다는 점이다. 즉 초당 원하는 만큼 메시지를 보낼 수 있고 대기열에도 원하는 만큼 메시지를 저장할 수 있다. 또한 메시지를 큐에 보관할 수 있는 기간은 기본 4일에 최대 14일까지 가능하다. 메시지를 넣거나 가져오는 속도도 10ms 이하로 매우 빠르다. 메세지 하나의 최대 크기는 1MB이다.

 

SQS는 메시지를 최소 한 번은 전달하는 것을 보장한다. 그 과정에서 같은 메세지가 두 번 이상 전달될 수도 있기에, 처리하는 쪽에서 중복 처리를 방지하는 로직을 만들어야 한다. 또한 여러 서버에서 병렬로 최대한 빠르게 처리하기 때문에 메세지의 순서가 바뀔 수도 있다.

 

SQS 대기열의 동작 과정을 좀 더 자세히 살펴보면, 우선 Producer가 SendMessage API를 사용해 SQS 대기열에 메시지를 전달한다. 메시지는 Consumer가 지우기 전까지 보관 기간 이내의 시간 동안 SQS 대기열에 있다가, Consumer가 Polling하면서 꺼내진다. Consumer는 한 번에 10개까지 메시지를 수신할 수 있다. Consumer는 동작 중인 EC2 인스턴스나 서버, 혹은 AWS 람다가 될 수 있다. 메시지를 수신한 Consumer는 메시지를 처리한 후에 DeleteMessage API를 통해 대기열에서 해당 메시지를 제거한다.

 

SQS는 여러 개의 Consumer를 가질 수 있으며, 여러 개의 EC2 인스턴스 Consumer가 동시에 병렬적으로 처리하도록 하여 처리 속도를 크게 향상시킨다. 이처럼 SQS는 더 많은 메시지가 들어와 처리량을 늘려야 하면 Consumer를 추가하고 수평 확장을 수행해서 처리량을 개선한다.

ASG를 이용한 SQS 활용 사례

 

Consumer가 ASG 안에서 EC2 인스턴스를 실행한다고 하면, ASG는 대기열 길이에 따라 자동 확장을 수행한다. 이 대기열 길이 측정은 ApproximateNumberOfMessages라는 CloudWatch 지표로 확인할 수 있다. CloudWatch 알람을 설정하여 대기열 길이가 특정 길이를 넘어가면 ASG가 확장을 수행하도록 할 수도 있다.

 

1) SQS 보안

그렇다면 SQS에서는 데이터를 어떻게 보호하고, 누가 SQS를 사용할 수 있는지 어떻게 제어할까? 우선 암호화를 사용한다. SQS에서는 3가지 암호화 방식을 제공하는데, HTTPS를 이용해 전송 중에 암호화하는 방식, KMS 키를 이용해 메시지를 큐에 저장할 때 암호화하는 방식, 클라이언트가 직접 암호화를 수행하는 방식이다.

 

또한 IAM 정책을 통해 SQS API에 접근할 수 있는 사용자를 통제하고, S3 버킷 정책과 유사한 SQS 접근 정책을 설정하여 다른 AWS 계정이나 SNS, S3 같은 서비스가 큐에 접근하도록 허용할 수 있다.

 

2) SQS Message Visibility Timeout

메시지가 한 Consumer에 의해 Poll 되면, 해당 메시지는 다른 Consumer들에게 보이지 않는다. 메시지가 보이지 않도록 정해진 시간, 즉 Message Visibility Timeout은 디폴트 30초로, 이는 메시지 처리 시간으로 30초가 주어졌다는 것을 의미한다. 이 시간이 끝난 후에는 해당 메시지가 SQS에서 보이는 상태로 변경된다.

 

메시지가 시간 내에 처리되지 못했다면 해당 메시지는 2번 처리될 것이기 때문에 Consumer는 ChangeMessageVisibility API를 호출하여 시간을 더 요청할수 있다. 만약 Visibility Timeout이 너무 길다면, Consumer가 충돌했을 때 해당 메시지가 다시 보이기까지 오래 걸릴 것이다. 반대로, Visibility Timeout이 너무 짧다면, 중복 처리가 발생할 수 있다.

 

3) SQS Long Polling

Consumer가 대기열로부터 메시지 수신 요청을 했을 때, 대기열이 비어있다면 메시지가 도착할 때까지 대기할 수 있는데, 이것을 Long Polling이라 부른다. Long Polling을 사용하 메시지가 도착하자마자 소비자에게 전송된다. Long Polling은 소비자가 API 호출 횟수를 줄이는 동시에 효율성을 증가시키고, 지연 시간을 단축할 수 있다.

 

대기 시간은 1초부터 20초까지 가능하며, 대기 시간이 길수록 API 호출 횟수를 줄이고 지연 시간이 단축되기 때문에 시간을 길게 설정할수록 좋다. WaitTimeSeconds 매개변수를 사용해 큐 수준이나 API 수준에서 이를 활성화할 수 있다.

 

4) SQS FIFO Queue

FIFO란, First In First Out의 약자로 큐에서 메시지를 꺼낼 때, 먼저 들어온 것을 먼저 빼내는 방식이다. 표준 대기열 방식보다 순서가 확실히 보장된다는 것이 특징이다. 따라서 이 방식에서는 처리량에 제한이 있다. 배치가 아닐 경우에는 초당 300개의 메시지를 처리하고, 배치 방식, 즉 메시지를 묶어서 보낸다면 초당 3000개까지 처리한다. 또한 중복을 제거하도록 도와주는 기능이 존재한다.

2. SNS

SNS의 역할

 

메시지 하나를 여러 수신자에게 보낸다고 가정해보자. Direct Integration을 사용하여 여러 수신자에게 각각 메시지를 전송할 수 있다. 하지만 새로운 수신 서비스를 추가할 때마다 통합을 생성하고 작성해야 하므로 번거로운 방식이다. 이때, Pub/Sub을 활용하면 간편해진다. Producer가 메시지를 SNS 주제(Topic)로 전송하기만 하면, 이 주제를 게시하여 각 구독자들이 해당 메시지를 수신하고 보관할 수 있도록 한다.

 

SNS에서 이벤트를 만드는 Producer는 SNS Topic 하나에만 메시지를 보낸다. SNS Topic을 구독하는 Consumer는 원하는 만큼 추가할수 있다. 각 구독자는 메시지를 수신하고, 필터링 기능으로 구독자가 필요한 메시지만 수신하는 것도 가능하다. 하나의 Topic에는 최대 1250만 개의 구독자를 연결할 수 있다. SNS Topic은 계정당 최대 100,000개까지 생성할 수 있다. 또한 CloudWatch 알람, 람다, ASG 알림 등 많은 AWS 서비스에서 SNS에 데이터를 전송할 수 있다.

 

그렇다면 SNS는 어떻게 동작할까? SDK를 사용한 Topic Publish로 SNS에 메시지를 게시할 수 있는데, Topic과 Subscription을 생성하고, SNS Topic에 게시하면 된다. 또 다른 방법은 모바일 앱 SDK 전용 직접 게시 방법인데, 플랫폼 애플리케이션과 플랫폼 엔드포인트를 생성한 후에 플랫폼 엔드포인트에 게시하면 된다. 수신 가능 대상은 Google GCM, Apple APNS, Amazon ADM 등이다.

 

SNS도 SQS와 마찬가지로 암호화와 접근 제어를 통해 보안을 지원한다. 마찬가지로 HTTPS를 이용해 전송 중에 암호화하는 방식, KMS 키를 이용해 메시지를 큐에 저장할 때 암호화하는 방식, 클라이언트가 직접 암호화를 수행하는 방식의 암호화 방식을 지원하며, IAM 정책을 통한 SNS API 접근 사용자 통제 및 SNS 접근 정책 설정을 통한 다른 AWS 계정이나 서비스의 접근을 허용할 수 있다.

 

SNS Message Filtering

 

앞서 설명했듯이, JSON 정책을 사용해 SNS Topic 구독자들에게 전달할 메시지를 필터링할 수 있다. 만약 구독이 필터 정책을 가지고 있지 않다면, 모든 메시지를 수신한다.

3. Fanout Pattern

Fanout Pattern

 

SNS와 SQS를 함께 사용하여 Fanout Pattern을 만들 수 있다. 핵심아이디어는 이벤트는 한 번만 발행하고, 여러 개의 SQS 대기열로 동시에 복사하여 각 시스템이 독립적으로 처리하도록 하는 것이다. 즉, SNS에 한 번만 Publish하면 구독 중인 모든 SQS 대기열이 메시지를 받는 구조이다.

 

이 아키텍처에서는 Producer와 Consumer가 완전히 분리되며, 메시지가 손실없이 안전하게 보관된다. SQS의 장점인 데이터 유지 및 지연 처리, 작업 재시도가 가능하며, SQS 구독자를 필요할 때마다 추가할 수 있다. 이때, 이 아키텍처를 위해서는 SNS가 SQS 대기열에 메시지를 쓸 수 있도록 허용해주어야 한다.  또한, SQS와 SNS가 같은 리전에 있을 필요도 없다.

SNS FIFO + SQS FIFO

 

구독자로는 SQS 표준 대기열과 FIFO 대기열 모두 가능하기 때문에, 필요에 따라 둘 중에 선택해서 Fan out을 설계할 수 있다.

4. Kinesis

Kinesis는 실시간 스트리밍 데이터를 손쉽게 수집 및 처리하여 분석할 수 있도록 하는 도구이다. 실시간 데이터는 애플리케이션 로그, 지표, 웹사이트 클릭 스트림, IoT 원격 측정 데이터 등 데이터가 빠르게 실시간으로 생성되는 데이터를 의미한다.

 

Kinesis는 4가지 서비스로 구성된다. Kinesis Data Streams에서는 데이터 스트림을 수집하여 처리 및 저장하고, Kinesis Data Firehose에서는 데이터 스트림을 AWS 내부나 외부의 데이터 저장소로 읽어들인다. Kinesis Data Analytics는 SQL 언어나 Apache Flink를 활용해 데이터 스트림을 분석하며, 마지막으로 Kinesis Video Streams는 비디오 스트림을 수집, 처리 및 저장한다.

1) Kinesis Data Streams

Kinesis Data Streams

 

Kinesis Data Streams는 실시간 스트리밍 데이터를 수집 및 저장한다. 이를 통해 실시간 데이터를 원하는 Consumer로 데이터를 전달한다. 데이터는 365일까지 저장 가능하며, SQS와 달리 이미 처리된 데이터도 재처리가 가능하다. 즉, 데이터는 보관 기간이 만료될 때까지 삭제되지 않는다. 레코드 하나의 최대 크기는 10MB이고, 전체 데이터 순서는 보장되지 않지만 같은 Partition Key를 가진 데이터에 대해서는 순서가 보장된다는 특징이 있다.

 

KMS를 이용한 저장 시 암호화 방식과 HTTPS를 활용한 전송 시 암호화 방식을 사용할 수 있다. 또한 Producer가 Kinesis로 효율적으로 데이터를 보내도록도와주는 KPL과 Consumer가 Kinesis로부터 쉽게 데이터를 읽도록 도와주는 KCL 라이브러리를 제공한다.

 

Kinesis는 용량을 두 가지 방식으로 관리한다. 우선, Provisioned Mode에서는 직접 샤드(Shard) 개수를 정하며, 각 샤드는 입력 1MB/s 혹은 초당 1000레코드, 출력은 2MB/s를 처리할 수 있다. 만약 트래픽이 증가하면 샤드를 수동으로 확장해야 한다. 비용은 샤드 개수만큼 지불한다. On-Demand Mode는 AWS가 자동으로 관리하며, 처음에는 기본적으로 4MB/s 또는 4000Record/s를 제공하다가 트래픽이 늘어나면 자동으로 확장한다. 샤드 기준이 아닌 스트림 사용 시간 및 전송 데이터 양으로 비용이 청구된다.

2) Amazon Data Firehouse

Amazon Data Firehose는 실시간으로 들어오는 데이터를 거의 실시간으로 원하는 저장소나 분석 서비스에 자동으로 전달해주는 완전관리형 서비스다. 예를 들어 웹사이트에서 로그가 계속 발생하면 이 로그를 S3에 저장하고, Redshift에서 분석하며 OpenSearch로 검색하고 싶을 수 있다. Firehose는 데이터를 받아서 목적지로 자동 전달한다.

 

완전 관리형 서비스라는 것은 AWS가 서버 관리, 확장, 장애 복구까지 모두 담당하므로 사용자는 데이터 넣기와 목적지 지정만 수행하면 된다. 또한 S3, Redshift, OpenSearch와 같은 AWS 서비스뿐 아니라 Datadog, MongoDB 같은 외부 서비스도 지원한다. AWS 서비스가 아니더라도 HTTP api가 있다면 데이터 전송이 가능하며, 사용한 만큼 지불하는 비용 시스템을 가진다.

 

Firehose의 중요한 특징 중 하나는 거의 실시간으로 전달한다는 것이다. Firehose에서는 데이터가 들어올 때 즉시 저장하지 않고, 잠시 모아 두었다가(버퍼 기능) 크기나 시간 기준이 맞았을 때 저장한다. CSV, JSON, Parquet, Avro, Raw Text, Binary Data까지 다양한 형식을 지원하고, 자동 형식 변환도 지원한다. 람다를 호출하여 CSV to JSON 처럼 형식 변환을 수행할 수도 있다.