클라우드 통합
클라우드 통합 개요
어느 시점에 도달하면 애플리케이션이 여러 개 생겨서 서로 통신이 이뤄져야 한다. 이때 두 가지 패턴 타입으로 애플리케이션을 서로 통신하게 만들 수 있다.
동기식 통신
동기식 통신은 애플리케이션이 다른 애플리케이션에 요청을 할 때 서로 직접 요청을 주고받는 것이다.
예를 들어 뭔가를 구매하는 서비스를 만들어서 판매한 물품을 배송하는 서비스에 연결해야 된다고 할 때 서로 직접 요청을 주고받는 구매 서비스와 배송 서비스를 동시에 통합하는 것이다.
서로 다른 애플리케이션 사이에 동기식 통신이 생기면 갑자기 트래픽이 몰렸을 경우 등에 문제가 될 수 있다.
이 경우 애플리케이션을 분리해서 대기열 모델인 SQS나 pub/sub 모델인 Kinesis를 이용하는 것이 더 나은 방법이다.
비동기식/이벤트 기반
비동기식 또는 이벤트 기반은 중간에 통신할 대기열이 있을 때이다.
예를 들어 구매 서비스가 뭔가를 판매할 때마다 대기열에 주문을 올려두면 배송 서비스가 대기열에서 읽어들여 주문을 받는다. 그리고 두 서비스는 서로 직접적으로 요청을 주고받지 않으며 통합되지 않는다.
Amazon SQS
애플리케이션을 분리할 수 있도록 해주는 첫 번째 서비스로 Amazon SQS를 살펴보자
SQS 개요
SQS는 Simple Queue Service의 약자로 프로듀서가 메시지를 보내서 Queue에 메시지를 저장하고, 이를 컨슈머가 가져가서 처리하는 방식이다. 이때 Queue는 일반적으로 각 어플리케이션들이 가지고 있는 Coupling(결합)을 끊어주는 역할을 한다.
SQS는 완전 관리형이고 서버리스이며 애플리케이션을 분리할 때 사용한다. 또한 한도 없이 초당 메시지 1개에서 수만 개까지도 규모 조정이 가능하다. 기본 메시지 보유기한은 4일이고, 최장 14일까지여서 가능한 기본 보유기한 안에 처리하는 것이 좋다.
대기열에서 대기할 수 있는 메시지 수는 제한이 없고, 컨슈머가 메시지를 읽고 나면 메시지는 삭제되어 사라진다. 또한 지연 시간도 짧은데 이때 지연 시간이 짧다는 건 발행과 구독에 10ms 미만이 걸린다는 것을 의미하고, 컨슈머가 메시지 읽는 작업을 공유해서 수평적으로 규모를 조정한다.
SQS 기능
1. 애플리케이션의 티어 사이를 분리
SQS는 애플리케이션 티어 사이를 분리할 때 사용 가능하다.
예를 들어 웹 서버가 있고, 요청을 받는데 ALB를 통해 받을 때 해당 요청은 ASG의 EC2 인스턴스를 통해 처리된다. 그리고 어떤 영상을 처리해달라는 사용자의 요청이 있을 때 영상 애플리케이션 그룹으로 바로 요청을 보내는 것이 아니라 메시지를 SQS Queue(대기열) 안에 넣는다. 그러면 영상 처리 그룹의 EC2 인스턴스가 SQS 대기열에서 읽어들여 영상을 처리하게 된다.
여기서 첫 번째와 두 번째의 ASG의 규모를 독립적으로 조정할 수 있다는 장점이 있다. SQS 대기열에 있는 메시지 수에 따라 규모를 조정할 수 있게 되는 것이다. 이렇게 하면 두 계층이 SQS 대기열로 인해 완전히 분리되어 독립적으로 조정된다.
2. FIFO 대기열
SQS의 또 다른 기능 중 하나는 선입선출(FIFO: First-In-First-Out) 대기열을 둔다는 것이다.
일반적인 SQS 대기열이라면 컨슈머는 메시지를 한꺼번에 읽을 수 있고 순서도 각자 다를 수 있지만, SQS FIFO 대기열로는 메시지가 들어온 순서대로 처리된다.
Amazon Kinesis
Kinesis 개요
Kinesis는 빅 데이터 스트리밍 서비스이다. 관리 서비스이며 대규모로 실시간 스트리밍 데이터를 수집 및 처리, 분석하기 위해 사용된다.
CCP 시험에서는 위의 내용 이상으로 알 필요가 없지만 아래 내용은 알아두면 좋은 내용이다.
Kinesis Data Stream은 지연 시간이 적은 스트리밍 서비스로 수백, 수천 개의 소스에 대규모로 삽입한다. 소스는 데이터를 생산하는 무엇이든 될 수 있으며 우리가 생각하는 무엇이든 될 수 있다.
Kinesis Data Firehose는 스트리밍을 우리가 알고 있는 곳에 로드한다. 예를 들어 S3, Redshift 등이 있다.
Kinesis Data Analytics는 SQL 언어를 사용하여 스트리밍에 대한 실시간 분석을 수행한다.
Kinesis Video Streams는 분석이나 머신 러닝을 위해 실시간 영상 스트리밍을 모니터링 한다.
Amazon SNS
애플리케이션을 분리할 수 있도록 해주는 두 번째 서비스로 Amazon SNS를 살펴보자
SNS 개요
SNS는 Single Notification Service의 약자로 소비자가 메시지를 공유하는 SQS와는 다르게 이벤트 게시자는 오직 하나의 SNS 주체에 메시지를 보내고, SNS 주제 알림을 리스닝할 이벤트 구독자를 원하는 만큼 가질 수 있다. 따라서 주제를 구독하는 각 구독자는 모든 메시지를 받을 수 있다.
주제의 각 구독자는 SNS 주제로 보내지는 모든 메시지를 받는다. 각 SNS 주제는 1,200만 명 이상의 구독자를 가질 수 있고, 계정 당 100,000개의 주제를 가질 수 있다. SNS 주제는 많은 구독자에게 게시할 수 있다.
시험에서 알림, 게시-구독, 구독자를 본다면 Amazon SNS를 생각하면 된다.
AWS 서비스 측면에서 대상이 될 수 있는 것
AWS 서비스 측면에서는 SQS, Lambda, Kinesis Data Firehose가 SNS 게시 활동의 대상이 될 수 있다. 또한 SNS로부터 이메일을 직접 보낼 수 있고, SMS와 모바일 알림을 보낼 수 있으며 HTTP/HTTPS 엔드 포인트로도 데이터를 보낼 수 있다.
Amazon MQ
SQS와 SNS 그리고 그에 따르는 클라우드 네이티브 서비스는 AWS에서 만든 독점 프로토콜로 자체 API 세트를 사용한다.
하지만 클라우드로 애플리케이션을 마이그레이션할 때 API를 사용하기 위해 애플리케이션을 수정하고 싶지 않을 것이다. 그냥 MQTT나 STOMP 등의 익숙한 기존 개방형 프로토콜을 사용하고 싶을 것이다.
이때 사용할 수 있는 것이 바로 Amazon MQ이다.
MQ 개요
MQ는 RabbitMQ와 ActiveMQ 기술을 지원하는 관리형 메시지 브로커 서비스이다. RabbitMQ와 ActiveMQ는 앞서 말한 개방형 프로토콜에 액세스 권한을 제공하는 온프레미스 기술이지만 MQ 덕분에 클라우드에 이런 브로커를 관리형 버전으로 갖추게 되는 것이다.
MQ는 SQS와 같은 대기열 기능을 제공하고 SNS와 같은 단일 토픽 기능도 단일 브로커에 포함해 제공한다. 하지만 MQ는 거의 무한대로 규모 조정이 가능한 SQS나 SNS만큼 확장성이 있지 않고, 서버에서 실행되기 때문에 서버 문제가 발생할 수 있어서 가용성을 높이려면 장애 조치를 지원하는 다중 가용 영역 설치를 해야 한다.
따라서 MQ는 업체가 클라우드로 마이그레이션 하는 경우에만 사용되고 개방형 프로토콜 중 하나를 사용해야 한다. 그게 아니라면 SQS와 SNS를 사용하는 것이 확장성과 AWS와의 통합에서 더 좋다.
