[AWS] Decoupling System
AWS로 시스템을 설계하고, 아키텍처를 구성하고 있는 컴포넌트들이 다른 컴포넌트에 직접적으로 의존하는 경우 컴포넌트끼리 강한 결합이 발생해 의존성이 커지고, 한 컴포넌트에서 발생한 오류가 다른 컴포넌트로 전이되는 등 여러 문제점이 발생한다.
이 때 SQS / SNS / Kinesis 등 미들웨어를 도입해 아키텍처 내 컴포넌트들을 Decoupling 해서 메세지나 이벤트를 통해 컴포넌트들을 연결한다면 전체 시스템의 확장성, 유지보수성을 크게 향상시킬 수 있다.
SQS
Simple Queing Service 약자로 AWS에서 제공하는 메세지 큐 서비스이다.
MSA나 분산 시스템에서 컴포넌트 간의 통신을 디커플링하고 비동기 처리할 때 사용된다.
Amazon SQS의 세부 구현 사항이 공개되지는 않았지만.. SQS를 사용하면 그냥 EC2에다가 Kafka나 RabbitMQ 띄워서 메세지 큐로 쓰는 것 보다 편하게 API 호출으로 시스템을 관리할 수 있다.
Producer는 메세지 큐에 메세지를 전달하는 컴포넌트이고, Consumer는 메세지 큐에서 메세지를 받아 처리하는 컴포넌트이다.
Consumer는 Poll 작업으로 메세지 큐에 새로 들어온 메세지가 있는지 주기적으로 확인하고, 처리된 메세지는 메세지 큐에서 삭제한다.
여러 Consumer는 동시에 큐를 Poll 할 수 있지만 메세지를 가져온 경우 해당 메세지가 다른 Consumer에게 노출되지 않으니 중복 처리가 방지된다.
Consumer가 메세지를 가져간 경우 Message Visibility Timeout으로 정의된 시간까지는 다른 Consumer에게 해당 메세지가 노출되지 않는다.
Visibility Timeout으로 지정된 시간이 너무 짧은 경우 Consumer가 메세지를 처리하는 중에도 해당 메세지가 큐에 반환될 수 있으니 처리 시간이 오래 걸릴 것 같은 경우 Consumer에서 ChangeMessageVisibility API를 호출해 연장할 수 있다.
SQS를 ASG와 연계해서 사용하는 경우 SQS에 쌓이는 메세지의 양과 처리 시간을 모니터링해 Consumer 인스턴스를 축소하거나 확장할 수 있다.
메세지 처리 순서가 중요한 경우 FIFO Queue를, 순서가 중요하지 않으면 Standard Queue를 사용하자.
SNS
Simple Notification Service 약자로 Pub/Sub 시스템을 구현할 때 사용된다.
Producer가 메세지를 발행할 때 여러 Subscriber에게 동시에 전달할 수 있는 시스템으로, 이벤트 기반 아키텍처를 구현 시 한 서비스에서 발생한 이벤트를 다른 여러 서비스에 전달할 때 사용한다.
여러 AWS 서비스들과 통합되어있어 이메일, HTTP 엔드포인트 외에도 SQS, Lambda, Kinesis 등 여러 서비스들을 Subscriber로 설정할 수 있다.
SNS를 앞에 두고 여러 SQS를 Subscripber로 설정하는 경우 작업을 좀 더 효과적으로 처리할 수 있다.
각 SQS Queue는 메세지를 비동기적으로 처리할 수 있어 Producer와 Consumer가 독립적으로 운영되고, Queue마다 독립적으로 스케일링 할 수 있어 시스템을 좀 더 안정적으로 운영할 수 있다.
Producer가 SNS에 메세지를 발행할 때 메세지 속성을 함께 전달하는 경우, SNS가 메세지를 여러 Subscriber로 전달할 때 메세지 속성을 사용해 분기시킬 수 있어 이 메세지들을 처리하는 Queue에서 특정 메세지 속성만을 처리하도록 설정해 Message Filtering 기능을 구현할 수 있다.
Kinesis
실시간 데이터 스트리밍 플랫폼으로 대용량 데이터를 실시간으로 다룰 때 사용한다.
실시간 데이터를 Kinesis Data Stream으로 전달하기 위해 Producer 비즈니스 로직을 작성한다.
수집된 데이터는 Producer를 통해 Kinesis Data Stream으로 전달되고, 여러 AWS 서비스가 Consumer로 동작해 데이터를 처리한다.
Data Firehose는 Kinesis의 Consumer 역할을 수행해 Data Stream에서 가져온 데이터를 S3, Redshift 등으로 전달해준다.
데이터를 즉시 전송하지 않고 어느정도 쌓였을 때 배치 처리하기에 Near Real-Time서비스라고 불리고, AWS가 모든 인프라를 자동으로 관리해 줘 사용자가 별도로 인프라 관련 설정을 조작하지 않아도 돼 편리하다.
'DevOps > Amazon Web Service' 카테고리의 다른 글
[AWS] Serverless Architecture (0) | 2025.02.27 |
---|---|
[AWS] S3 - Simple Storage Service (0) | 2025.01.22 |
[AWS] Route53 (0) | 2025.01.18 |
[AWS] RDS - Relational Database Service (0) | 2025.01.17 |
[AWS] Availability and Scalability (0) | 2025.01.14 |
댓글
이 글 공유하기
다른 글
-
[AWS] Serverless Architecture
[AWS] Serverless Architecture
2025.02.27 -
[AWS] S3 - Simple Storage Service
[AWS] S3 - Simple Storage Service
2025.01.22 -
[AWS] Route53
[AWS] Route53
2025.01.18 -
[AWS] RDS - Relational Database Service
[AWS] RDS - Relational Database Service
2025.01.17