클라우드 통합에 대하여
- 어느 시점에 가면 애플리케이션이 여러 개 생겨서 서로 통신이 이루어지게 된다.
- 두 가지 패턴 타입으로 애플리케이션을 서로 통신하게 만들 수 있다.
1) 첫 번째, "동기식 통신"
: 애플리케이션이 다른 애플리케이션에 요청을 한다. 예를 들어, 뭔가를 구매하는 서비스를 만들어서 판매한 물품을 배송하는 서비스에 연결해야 된다고 보면 구매 서비스와 배송 서비스를 동시에 통합해야 한다. ( 서로 직접 요청을 주고 받으니깐)
1) 두 번째, "비동기식 또는 이벤트 기반"
: 예를 들어, 구매 서비스가 뭔가를 판매할 때마다 대기열에 주문을 올려두면 배송 서비스가 대기열에서 읽어들여 주문을 받을때, 밑의 이미지 예시에서 볼 수 있듯이 구매 서비스와 배송 서비스는 서로 직접적으로 통합되지 않습니다.
SQS(Simple Queue Service)
- 애플리케이션을 분리할 수 있는 첫 번째 서비스이다.
- AWS의 대기열 처리 서비스이다.
- 메시지는 대기열에 최대 14일까지 보관했다가 삭제한다. 그리고 대기열에서 대기할 수 있는 메시지 수는 제한이 없다.
- FIFO(선입선출) 대기열을 둔다.
- 소비자는 메시지들을 읽을 수 있고 읽기 작업을 공유한다.
- 메시지는 읽어서 처리가 끝나면 삭제된다.(= 소비자가 작업을 마치면 메시지는 사라진다)
- AWS내에서 애플리케이션을 분리할 때 사용한다.
- 완전 관리형이고 서버가 필요없는 서비스이다.
- 밑의 이미지 설명
: 웹 서버가 있고 이 웹 서버는 요청을 받는데 애플리케이션 로드 밸런싱을 통해서 요청을 받는다. 요청은 Auto Scaling Group의 EC2 인스턴스를 통해 처리가 된다. 예를 들어, 어떤 영상을 처리해달라는 사용자의 요청을 받으면 이때 영상 애플리케이션으로 직접 전송하는 것이 아니라 메시지를 SQS 대기열에 삽입할 수 있다. 그러면 Auto Scaling Group의 EC2 인스턴스로 구성된 영상 처리 계층이 생겨 EC2 인스턴스가 SQS 대기열에서 읽어들여 영상을 처리하게 된다. (좋은 점은 첫 번째와 독립적으로 두 번째 Auto Scaling Group의 규모를 조정할 수 있다는 것이다.)
SNS(Simple Notification Service)
- 애플리케이션을 분리할 수 있는 두 번째 서비스이다.
- AWS 알림 서비스이다.
- SNS 주제 알림을 리스닝할 이벤트 구독자를 원하는 만큼 가질 수 있다. 그리고 주제를 구독하는 각 구독자는 모든 메시지를 받을 수 있다.
- 이벤트 게시자는 오직 하나의 SNS 주제에 메시지를 보낸다.
- AWS 내에서 pub/sub, 구독자, 토픽, 알림용으로 다시 사용된다.
- AWS 서비스 측면에서 구독자는 이메일, Lambda, SQS, HTTP, 모바일 등이다.
Kinesis
- 실시간 데이터 스트리밍 서비스이다.
- 대규모로 실시간 스트리밍 데이터를 수집 및 처리하고 분석하기 위해 사용된다.(= 비디오 스트림에서 실시간 분석을 수행할 수 있다.)
- 데이터 영속성을 갖추게 된다.
- 유형
→ Kinesis Data Streams
: 지연 시간이 적은 스트리밍 서비스로, 수백, 수천 개의 소스에 대규모로 삽입한다. 소스는 데이터를 생산하는 무엇이든 될 수가 있다. 예를 들어, 트럭, 보트 등등
→ Kinesis Data Firehose
: 스트리밍을 우리가 알고 있는 곳에 로드한다. 예를 들어, Amazon S3, Redshift 등이 있다.
→ Kinesis Data Analytics
: SQL 언어를 사용하여 스트리밍에 대한 실시간 분석을 수행한다.
→ Kinesis Video Strams
: 분석이나 머신 러닝을 위해 실시간 영상 스트리밍을 모니터링 한다.
- 밑의 이미지 설명
: Amazon Kinesis Streams는 클릭 스트림, IOT기기, 척도, 로그 서버와 같은 데서 데이터를 가지고 온다. 데이터를 분석하고 실시간으로 출력을 생산하기 원한다면 Kinesis Data Analytics를 사용한다. 그리고 Kinesis Firehose는 출력값을 도착지에 직접 보낼 때 사용한다. 예를 들어, Amazon S3 버킷이나 Amazon Redshift 데이터베이스와 같이 데이터를 분석할 수 있는 곳에서, 그리고 그곳에서 더 많은 분석을 수행할 수 있다.
Amazon MQ
- 클라우드에서 Active MQ와 Rabbit MQ 이 두가지 기술을 지원하는 관리형 메시지 브로커 서비스이다.
- 개방형 프로토콜에 액세스 권한을 제공하는 온프레미스 기술이다.
- 온프레미스에서 클라우드로 마이그레이션하면서 MQTT나 AMQP 아니면 그 밖의 프로토콜을 사용할 때 필요한 서비스이다.(위의 두 번째 설명과 유사하지만 이해를 돕기위해 적었습니다.)
- AmazonMQ는 거의 무한대로 규모 조정이 가능한 SQS나 SNS만큼 확장성이 있지는 않다. 그리고 서버에서 실행되기 때문에 서버 문제가 발생할 수 있다. 그래서 가용성을 높이고 싶다면 장애 조치를 지원하는 다중 AZ 설치를 실행하면 된다.
- 정리하자면, AmazonMQ는 오로지 업체가 클라우드로 마이그레이션하는 경우에만 사용되고 M MQTT, AMQP, STOMP 등등 이런 개방형 프로토콜 중 하나를 사용해야 한다. 그게 아니라면 더 확장성이 좋고 Amazon Web Service와도 통합이 더 잘되는 SQS와 SNS를 사용해야 된다.
'AWS(Amazon Web Service)' 카테고리의 다른 글
| [AWS] 클라우드 모니터링 (0) | 2024.09.06 |
|---|---|
| [AWS] Global Applications Architecture (0) | 2024.09.06 |
| [AWS] AWS 글로벌 인프라 활용 (2) | 2024.09.03 |
| [AWS] 대규모 배포 및 인프라 관리 (1) | 2024.09.02 |
| [AWS] Lambda & Batch에 대하여 (+ Lightsail) (3) | 2024.09.01 |