AWS

Cloud Intergration(클라우드 통합) - 애플리케이션끼리 연결하려면?

S_N_Y 2024. 3. 9. 00:10

 

 

애플리케이션끼리 연결하려면 어떻게 해야할까?⛓️

어느 시점에 가면 애플리케이션이 여러 개가 생겨서 서로 통신이 이루어져야 하는데 AWS에서는 두 가지 패턴으로 애플리케이션을 서로 통신하게 할 수 있다.

첫 번째 패턴은 동기식 통신(Synchronous communications)이라는 것인데 애플리케이션이 다른 애플리케이션에 요청을 하는 것이다. (예 : 뭔가를 구매하는 서비스와 판매한 물품을 배송하는 서비스를 연결해야된다고 가정했을 때, 구매 서비스와 배송 서비스를 동시에 통합하려고 하는 것)

두 번째 패턴은 비동기식(이벤트 기반)인데 예를 들어 통신할 대기열이 있을 때이다. 구매 서비스가 뭔가를 판매할 때마다 대기열에 주문을 올려두면 배송 서비스가 대기열에서 읽어들여 주문을 받는다. 

=> 예시에서 볼 수 있듯이 구매 서비스와 배송 서비스를 서로 직접적으로 통합해버릴지, 중간에 통신한 대기열(decoupled)을 만들지 결정하는 것이다. 

어떤 서비스를 통해 어떤 방법을 채택할지 알아보자

 

#0 SQS(Simple Queue Service) 🌌- AWS의 대기열 처리 서비스(분리하는 서비스 1)

애플리케이션을 분리할 수 있도록 해주는 첫 번째 서비스를 소개하겠다.

SQS는 AWS의 대기열 처리 서비스이다. 

SQS 대기열을 생성하고 있다고 가정해보자. producer가 해당 대기열로 메세지를 전송하게 할 수 있다. producer가 여럿일 때 메세지가 대기열에 저장되면 대기열을 polling하는 consumer가 메세지를 읽을 수 있다. consumer가 메세지를 polling하면 작업을 공유하고 consumer마다 다른 메세지를 받게 된다. 메세지 처리가 끝나면 예를 들어 영상을 처리하기 위해 대기열의 메세지를 삭제해버리고 메세지는 사라진다. 

=> 이 구조에서는 producer가 메세지를 대기열로 보내게 하고 preoducer와 분리된 consumer가 대기열에서 메세지를읽어들여서 서로 다른 속도로 처리하게 한다.

 

SQS의 특징은 다음과 같이 정리할 수 있다.⤵️

 

- AWS 완전 관리형 서비스

- 서버를 제공하지 않아도 애플리케이션을 분리할 때 사용한다.

- 한도 없이 규모 조정이 가능한데다 대기열에서 대기할 수 있는 메세지 수가 제한이 없다. 

- consumer가 메세지를 읽고 나면 메세지는 삭제되어 사라진다.

- 지연 시간도 짧다.

- consumer가 메세지 읽는 작업을 공유해서 수평적으로 규모를 조정한다.

... 

- tiers(티어) 사이를 분리할 때 사용이 가능하다. 

                                   ▼

웹 서버가 있고 이 웹 서버가 Application Load Balancer를 통해서 아마 요청을 받을텐데 요청은 Auto Scaling Group의 EC2 인스턴스를 통해 처리한다. 

tiers(티어) 사이를 분리할 때 사용이 가능하다는 예시의 그림설명

예를 들어 어떤 영상을 처리해달라는 사용자의 요청이 있다고 쳤을 때, 영상 애플리케이션으로 직접 전송하는 것이 아니라 메세지를 SQS 대기열에 넣을 수 있다. 그러면 Auto Scaling Group의 EC2 인스턴스로 구성된 영상 처리 계층(이미지 상 VIDEO PROCESSING)이 생긴다. 이 EC2 인스턴스가 SQS 대기열에서 읽어들여 영상을 처리하게 된다. 

여기서 좋은 점이 Auto Scaling Group의 규모를 조정할 수 있다는 것인데 이것을 분리했다고 표현할 수 있고 SQS 대기열에 있는 메세지 수에 따라 규모를 조정할 수도 있다.

=> 이렇게 하면 두 계층, 즉 웹 서버와 영상 처리가 SQS 대기열에서 완전히 분리되어서 독립적이게 된다.

 

+) SQS의 또 다른 기능 : 선입선출(FIFO) 대기열 기능

1, 2, 3, 4 순서대로 보내고 읽는 순서이다.

그림 상 producer가 1, 2, 3, 4 순으로 메세지를 전송한다면 consumer도 해당 순서대로 이 메세지들을 읽는다.

(일반적인 SQS 대기열이라면 consumer는 메세지를 한꺼번에 읽을 수 있고 순서도 다를 수 있는데, 이것을 사용하면 메세지가 순서대로 처리된다!)

 

#1 Kinesis - 실시간 빅데이터 스트리밍 서비스📈

Kinesis는 관리 서비스로 대규모로 실시간 스트리밍 데이터를 수집 혹은 처리하고 더 나아가 분석하기 위해 사용된다.

Kinesis Data Streams : 지연 시간이 적은 스트리밍 서비스로 수백~수천 개의 소스(데이터를 생산하는 어떠한 것 - 클릭 스트림, IoT 등)에 대규모로 수집하고 저장한다. (샤드의 수를 조절해서 얼마나 받을지도 조절할 수 있다)

Kinesis Data Firehose : 스트리밍을 우리가 알고 있는 곳에 로드한다. 예를 들면 S3, Readshift, Elastic search 등이 있다.

Kinesis Data Analytics : SQL언어를 사용해서 스트리밍에 대한 실시간 분석을 수행한다.

Kinesis Video Streams : 분석이나 머신 러닝을 위해 실시간 영상 스트리밍을 모니터링한다.

 

#2 SNS 📩- AWS의 알림 서비스(분리하는 서비스2)

하나의 메세지를 다수의 수신자에게 보내고 싶을 때 어떻게 해야할까?

=> 직접 통합으로 라우팅할 수 있다!

설명을 위한 이미지

예를 들어 구매 서비스는 왼쪽 그림과 같이 여러 가지의 서비스와 SQS에게로 통신하면 4개의 다이렉트 통합이 필요하기 때문에 꽤나 복잡하다. 

대신에 게시/구독(Pub/Sub) 통합을 사용할 수 있는데, SNS 주제(SNS Topic)가 있으면 구매 서비스는 SNS 주제(SNS Topic) 에 메세지를 보낸다. SNS Topic은 자동으로 아까 해당하는 여러 가지 서비스와 SQS에게 보낸다!

 

SNS란? - Simple Notification Service

이벤트 게시자는 오직 하나의 SNS topic에 메세지를 보낸다. 그리고 SNS topic 알림을 들을 이벤트 구독자를 원하는만큼 가질 수 있다. topic을 구독하는 각 구독자는 해당하는 메세지를 받을 수 있다는 점에서 소비자와 메세지를 공유하는 SQS와는 개념이 좀 다르다.

SNS는 많은 구독자에게 게시할 수 있다. AWS 서비스 측면에서는 SQS, Lambda, Kinesis Data Firehose가 SNS 게시 활동의 대상이 될 수 있다. 그리고 SNS로부터 이메일, SMS, 모바일 알림 등을 직접 보낼 수 있고 HTTP, HTTPS 등 엔드 포인트로 데이터를 보낼 수 있다. 

 

#3  Amazon MQ -  AWS 말고 익숙한 프로토콜 사용하기🛜

SQS와 SNS 그리고 그에 따르는 클라우드 네이티브 서비스는 AWS 프로토콜로 자체 API 세트를 사용한다.

그런데 온프레미스로 기존 애플리케이션을 실행하면 MQTT나 AMQP, STOMP, Openwire, WSS와 같은 오픈 프로토콜을 사용할텐데 AWS로 애플리케이션을 마이그레이션할 때,  SQS와 SNS와 같은 AWS 자체 프로토콜을 쓰려고 기존 애플리케이션을 변경할 필요 없이 익숙한 기존 프로토콜을 사용할 수 있게 도와주는 서비스이다.

Amazon MQ는 자세히 말하면 RabbitMQ와 ActiveMQ 이 두 가지 기술을 지원하는 관리형 메세지 브로커 서비스인데 RabbitMQ와 ActiveMQ는 앞서 언급했던 개방형 프로토콜에 액세스 권한을 제공하는 온프레미스 기술이다..!

=> 그러나 거진 무한대로 규모 조정이 가능한 SQS나 SNS만큼 확장성이 있지는 않다. 

      그리고 서버에서 실행되기 때문에 서버 문제가 발생할 수도 있다.

      (가용성을 높이고 싶으면 장애 조치를 지원하는 Multi- AZ를 실행하면 된다)

 

✅짤막한 개념 정리

AWS 글로벌 액셀러레이터는 로컬 또는 글로벌 사용자와 함께 애플리케이션의 가용성과 성능을 향상시키는 서비스이지만 S3에서는 사용할 수 없다.

Amazon S3 Transfer Acceleration을 사용하면 클라이언트와 S3 버킷 간의 장거리 파일 전송을 빠르고 쉽고 안전하게 수행할 수 있다. Transfer AccelerationAmazon CloudFront의 전 세계적으로 분산된 엣지 로케이션을 활용합니다. 데이터가 엣지 로케이션에 도착하면 데이터는 최적화된 네트워크 경로를 통해 Amazon S3로 라우팅됩니다.

Route 53 기능(전체 목록은 x) : 도메인 등록, DNS, 상태 확인, 라우팅 정책