AWS CCP 자격증 - 11 (클라우드 통합)

클라우드 통합이란?

 

어느 시점에 가면 애플리케이션이 여러 개 생겨서 서로 통신이 이루어져야 합니다.

두 가지 패턴 타입으로 애플리케이션을 서로 통신하게 만들 수 있습니다

 

첫 번째는 동기식 통신입니다.

동기식 통신의 과정은 애플리케이션이 다른 애플리케이션에 요청을 합니다.

예를 들어 뭔가를 구매하는 서비스를 만들어서 판매한 물품을 배송하는 서비스에 연결해야 된다고 하면

구매 서비스와 배송 서비스를 동시에 통합하려고 하게됩니다.

이 과정에서 서로 직접 요청을 주고받기에 동기식 통신입니다.

 

두 번째는 비동기식 통신 입니다. (이벤트 기반)

 

예를 들어 통신할 대기열이 있을 때입니다

이번에는 구매 서비스가 뭔가를 판매할 때마다 대기열에 주문을 올려두면 배송 서비스가 대기열에서 읽어들여 주문을 받습니다.

이 예시에서 볼 수 있듯이 구매 서비스와 배송 서비스는 서로 직접적으로 통합되지 않습니다

decoupled라는 게 있는데 중간에 통신할 대기열이 있어서 훌륭한 통합 패턴이 생깁니다.

 

Amazon SQS (Simple Queue Service)

 

애플리케이션을 분리할 수 있도록 해주는 첫 번째 서비스를 살펴보겠습니다

Amazon SQS인데요, Simple Queue Service의 약자입니다

 

Queue가 뭘까요? 여기에 SQS 대기열을 생성하고 있다고 해보죠

그러면 우리는 프로듀서가 해당 대기열로 메시지를 전송하게 할 수 있습니다

 

그러면 프로듀서는 하나가 될 수도 있고 여럿일 수도 있겠죠

그런 다음 메시지가 대기열에 저장되면 대기열을 폴링하는 컨슈머가 메시지를 읽을 수

있습니다

 

그러니까 대기열에서 메시지를 요청하면서 대기열을 폴링하는데 컨슈머는 하나일 수도 있고

여럿일 수도 있겠죠

 

이 예시에서는 컨슈머가 메시지를 폴링하면 작업을 공유하고요

컨슈머마다 다른 메시지를 받게 됩니다

메시지 처리가 끝나면 예를 들어 영상을 처리하기 위해 대기열의 메시지를 삭제해버리고 메시지는 사라집니다

 

이 구조에서는 프로듀서가 메시지를 대기열로 보내게 하고 프로듀서와 분리된 컨슈머가

대기열에서 메시지를 읽어들여서 서로 다른 속도로 처리하게 합니다

 

 분리(Decouple)가 나온다면 SQS

 

SQS는 애플리케이션 티어 사이를 분리할 때 사용 가능합니다.

 

웹 서버가 있고 이 웹 서버가 요청을 받는데 아마 Application Load Balancer를 통해서겠죠

 

요청은 Auto Scaling Group의 EC2 인스턴스를 통해 처리됩니다

그리고 예를 들어 어떤 영상을 처리해달라는 사용자의 요청이 있다고 해보죠

이때 영상 애플리케이션으로 직접 전송하는 것이 아니라 메시지를 SQS 대기열에 삽입할 수 있습니다,

그러면 Auto Scaling Group의 EC2 인스턴스로 구성된 영상 처리 계층이 생깁니다

 

이 EC2 인스턴스가 SQS 대기열에서 읽어들여 영상을 처리하게 됩니다

여기서 좋은 점이 첫 번째를 제외한 두 번째 Auto Scaling Group의 규모를 조정할 수 있다는 건데요

그래서 분리라고 합니다

게다가 예를 들어 SQS 대기열에 있는 메시지 수에 따라 규모를 조정할 수도 있습니다

이렇게 하면 두 계층, 즉 웹 서버와 영상 처리가 SQS 대기열에서 완전히 분리되어 독립적으로 조정됩니다.

그러면 최상의 사용자 경험을 제공할 수 있고 비용 효율과 규모 조정 문제도 해결되죠

 

또 다른 Amazon SQS 기능은 FIFO 대기열을 둔다는 겁니다

일반적인 SQS Queue라면 컨슈머는 메시리를 한번에 읽을 수 있고 순서도 각자 다를 수 있지만

Amazon SQS FIFO Queue는 메시지가 순서대로 처리됩니다.

 

Amazon Kinesis

Kinesis -> 실시간 빅 데이터 스트리밍 서비스

Kinesis의 하위 서비스로 이것들이 있죠 Amazon Kinesis Streams는 클릭 스트림, IOT 기기, 척도, 로그 서버와 같은 데서

데이터를 가져옵니다 데이터를 분석하고 실시간으로 출력을 생산하길 원한다면 Kinesis Data Analytics를 사용합니다.

 

Kinesis Firehose는 출력값을 도착지에 직접 보낼 때 사용하죠

예를 들어, Amazon S3 버킷이나 Amazon Redshift 데이터베이스와 같이 데이터를 분석할 수 있는 곳에 말이죠

그리고 거기에서 더 많은 분석을 수행할 수 있습니다

 

Amazon SNS

애플리케이션을 분리하는 두 번째 방식입니다. 

하나의 메시지를 다수의 수신자에게 보내고 싶을 때, 직접 통합으로 라우팅할 수 있습니다.

예를 들어, 구매 서비스는 이메일 알림을 보내고 사기 탐지 서비스, 배송 서비스와 SQS 대기열에 통신합니다.

이 방식은 꽤 복잡해집니다 4개의 직접 통합이 필요하기 때문입니다

 

대신에 게시-구독(pub/sub) 통합을 사용할 수 있습니다 SNS 주제가 있고 구매 서비스는 SNS 주제에 메시지를 보냅니다

주제는 똑똑하게도 자동으로 이메일 알림을 보내고 사기 탐지 서비스 배송 서비스 심지어 SQS 대기열에도 보냅니다

SNS는 Simple Notification Service의 약자로

이벤트 게시자는 오직 하나의 SNS 주제에 메시지를 보냅니다

SNS 주제 알림을 리스닝할 이벤트 구독자를 원하는 만큼 가질 수 있습니다

주제를 구독하는 각 구독자는 모든 메시지를 받을 수 있습니다

따라서 소비자가 메시지를 공유하는 SQS와는 다릅니다

주제의 각 구독자는 SNS 주제로 보내지는 모든 메시지를 받습니다

 

각 SNS 주제는 1,200만 명 이상의 구독자를 가질 수 있고 계정 당 100,000개의 주제를 가질 수 있습니다.

SNS는 많은 목적지를 가집니다 즉 많은 구독자에게 게시할 수 있죠 AWS 서비스 측면에서는 SQS, Lambda

Kinesis Data Firehose가 SNS 게시 활동의 대상이 될 수 있습니다

 

또한 SNS로부터 이메일을 직접 보낼 수 있고 SMS와 모바일 알림을 보낼 수 있습니다

마지막으로 HTTP나 HTTPS 엔드 포인트로 데이터를 보낼 수 있죠

 

시험에서 알림 게시-구독, 구독자 등등을 본다면 Amazon SNS를 생각하시면 됩니다.

 

Amazon MQ

Amazon MQ는 아주 간단합니다

 

RabbitMQ와 ActiveMQ 이 2가지 기술을 지원하는 관리형 메시지 브로커 서비스인데요

 

RabbitMQ와 ActiveMQ는 앞서 말한 개방형 프로토콜에 액세스 권한을 제공하는 온프레미스 기술입니다

 

그러면 Amazon MQ 덕분에 클라우드에 이런 브로커를 관리형 버전으로 갖추게 되는 거죠

이런 식으로 개념을 이해하시면 되고요

 

우선 AmazonMQ는 거의 무한대로 규모 조정이 가능한 SQS나 SNS만큼 확장성이 있지는 않습니다,

그리고 AmazonMQ는 서버에서 샐행되기 때문에 서버 문제가 발생할 수 있습니다

그래서 가용성을 높이고 싶다면 장애 조치를 지원하는 다중 AZ 설치를 실행하면 됩니다.

 

또 AmazonMQ는 SQS와 같은 대기열 기능을 제공하고 SNS와 같은 토픽 기능도 단일 브로커에 포함해 제공합니다

 

그러니까 AmazonMQ는 오로지 업체가 클라우드로 마이그레이션하는 경우에만 사용되고

M MQTT, AMQP, STOMP 등등 이런 개방형 프로토콜 중 하나를 사용해야 합니다

그게 아니라면 SQS와 SNS를 사용해야 되죠, AmazonMQ보다 훨씬 확장성이 좋고

Amazon Web Service와도 통합이 더 잘되니까요

 

클라우드 통합 요약

그럼 이 섹션에서 배운 내용을 전부 정리해보겠습니다

 

SQS는 AWS의 대기열 처리 서비스입니다

SQS 대기열에 여러 프로듀서를 둘 수 있고, 메시지는 대기열에 최대 14일까지 보관했다가 삭제합니다.

컨슈머는 이 메시지들을 읽을 수 있고 읽기 작업을 공유하는데요 읽기 작업을 쪼개는 거죠

메시지는 읽어서 처리가 끝나면 삭제됩니다 즉, 컨슈머가 작업을 마치면 메시지는 사라지죠

AWS 내에서 애플리케이션을 분리할 때 사용합니다 언제든 대기열 처리나 분리가 나오면 SQS를 떠올리세요

 

SNS는 AWS의 알림 서비스입니다 프로듀서와 구독자가 있죠

구독자는 이메일일 수도 있고 Lambda, SQS, HTTP, 모바일일 수도 있고요, 하나의 SNS 토픽에 구독자가 여럿이라면 SNS가 모두에게 메시지를 전송합니다

SNS는 메시지를 보유하지 않으니까 메시지 장기 저장 장치는 아니죠 AWS 내에서 pub/sub, 구독자, 토픽, 알림용으로

사용됩니다

마지막으로 Kinesis를 살펴봤는데요, 실시간 데이터 스트리밍 서비스로, 데이터 영속성을 갖추게 됩니다.

또 실시간으로 Kinesis 위에다 분석을 실행할 수도 있죠

끝으로 AmazonMQ가 있었습니다, 관리형 메시지 브로커로 클라우드에서 ActiveMQ와 RabbitMQ를 지원하죠

온프레미스에서 클라우드로 마이그레이션하면서 MQTT나 AMQP 아니면 그 밖의 프로토콜을 사용할 때

필요한 서비스입니다