Amazon MQ
- SQS와 SNS는 AWS의 독접 기술이기 때문에 클라우드 네이티브 서비스이다.
- 온프레미스에서 기존 애플리케이션을 실행하는 경우, 개방형 프로토콜인 MQTT, AMQP, STOMP, WSS, Openwire 등을 사용하면 된다.
- 애플리케이션을 클라우드에 마이그레이션하는 경우에는 SQS, SNS 프로토콜 혹은 API를 사용하기 위해 애플리케이션을 다시 구축하고 싶지 않고 MQTT, AMOP 등과 같은 기존에 쓰던 프로토콜을 사용하고 싶을 수 있는데 이때 'Amazon MQ'를 사용하면 된다.
- 상당한 간단한 서비스로 RabbitMQ와 ActiveMQ 두 가지 기술을 위한 관리형 메시지 브로커 서비스이다.
- RabbitMQ와 ActiveMQ는 온프레미스 기술로 앞서 설명했던 개방형 프로토콜 액세스를 제공한다.
- Amazon MQ를 이용하면 해당 브로커의 관리형 버전을 클라우드에서 사용할 수 있다.
- Amazon MQ는 무한 확장이 가능한 SQS나 SNS처럼 확장성이 크지는 않다.
- Amazon MQ는 서버에서 실행되므로 서버 문제가 있을 수 있기 때문에 - 고가용성을 위해 장애 조치와 함께 다중 AZ 설정을 실행할 수 있다.
- Amazon MQ는 SQS처럼 보이는 대기열 기능과 SNS처럼 보이는 주제 기능을 단일 브로커의 일부를 제공한다.
Amazon MQ - High Availability (고가용성)
- 예를 들어, us-east-1라는 리전에 us-east-1a와 us-east-1b 두 개의 가용 영역이 있다고 해보자.
- 영역 하나는 활성 상태 그리고 또 다른 영역은 대기 상태이다.
- 이제 두 영역에 각각 활성, 대기 상태인 Amazon MQ 브로커를 추가한다.
- 장애 조치 실행을 위해 백엔드 스토리지에 Amazon EFS도 정의해야 한다.
- 앞서 EFS는 네트워크 파일 시스템으로 다중 가용 영역에 마운트 할 수 있고 이렇게 설정하면 장애 조치가 일어날 때마다 대기 상태 영역 역시 Amazon EFS에 마운트되므로 첫 번째 활성 대기열과 동일한 데이터를 가질 수 있다.
- 클라이어튼가 Amazon MQ 브로커와 통신해서 장애 조치가 실행되는 경우에도 Amazon EFS 덕분에 데이터가 저장되는 것이다.
'AWS(Amazon Web Service)' 카테고리의 다른 글
[AWS] AWS's containers - ECS (0) | 2024.12.02 |
---|---|
[AWS] AWS's containers (1) | 2024.12.01 |
[AWS] SQS vs SNS vs Kineseis (0) | 2024.11.29 |
[AWS] AWS Integration & Messaging - Kinesis와 SQS FIFO에 대한 데이터 정렬 (0) | 2024.11.28 |
[AWS] AWS Integration & Messaging - Kinesis Data Firehose (0) | 2024.11.27 |