고성능/고확장성 SQS 처리 방법

Amazon VPC BC2와 SOS를 활용하여 **초당 수백만 개의 메시지를 메시지 큐에 전송하고 수신하는 애플리케이션을 구현해 달라는 요청을 받았습니다. 애플리케이션이 **EC2 인스턴스와 SQS 간에 충분한 대역폭을 확보하도록 하려고 합니다.애플리케이션과 SQS 간의 통신을 위한 **가장 확장 가능한 솔루션을 제공하는 옵션은 무엇입니까?

A. Elastic Load Balancer를 사용하여 애플리케이션 인스턴스가 올바르게 구성되었는지 확인하십시오.
B. EBS 최적화 옵션이 활성화된 프라이빗 서브넷에서 애플리케이션 인스턴스가 시작되었는지 확인하십시오.
C. 애플리케이션 인스턴스가 associate-public-IP-address=true 옵션이 활성화된 퍼블릭 서브넷에서 시작되었는지 확인합니다.
D. SQS 대기열 크기를 감시하도록 구성된 오토스케일링 그룹 및 자동 확장 트리거를 사용하여 프라이빗 서브넷에서 애플리케이션 인스턴스 시작 (D. Launch application instances in private subnets with an Auto Scaling group and Auto Scaling triggers configured to watch the SQS queue size)

핵심 요구사항 
- 대규모 메세지 처리 (수백만 건/초)
- EC2 인스턴스 <-> SQS 간 통신에 충분한 네트워크 대역폭 필요
- 가장 확장 가능한 방식

 

 

EC2와 SQS 간 통신의 대역폭을 넘어 전체 애플리케이션의 확장성에 대한 문제다.

위 여러 선지 중 D가 가장 올바른 답안이라고 할 수 있다.

D

• SQS는 EC2에서 API 호출을 통해 메세지를 주고 받으며, Auto Scaling 을 통해서 인스턴스 수를 큐의 길이에 따라서 동적으로 정할 수가 있음!!!! 이 방식은 큐가 길어지면 인스턴스를 자동으로 늘려 처리량을 확보할 수 있기 때문에 
• 또한 프라이빗 서브넷에서 서비스 사용 시, VPC 엔드포인트를 활용할 것이고, 이는 퍼블릭에서 사용하는 것보다 안정적이고 저지연으로 SQS에 접근이 가능하므로 가장 바람직 하다. 

 

고성능/ 고확장성 SQS 처리를 위해서는, 

1. VPC 엔드포인트(SQS용) 설정 -> 프라이빗 네트워크 내에서 SQS에 접근이 가능. 

2. Auto Scaling Group + SQS 큐 길이 기반 트리거 -> 메세지 증가에 따른 대응 가능

 

---

A

• ELB에 대해서 나오는데, SQS 통신에는 ELB가 필요 없다... SQS는 ELB 없어도 직접 API 요청으로 메세지를 송수신할 수 있다.

B

• EBS-optimized (EBS 최적화 옵션)은 EC2 <-> EBS간 대역폭 향상과 관련된 기능임!!! SQS는 EBS와 무관.

C

• 퍼블릭 IP를 부여해서 인터넷을 통해 SQS에 접근하는 방법은 비용과 대역폭 측면에서 비효율적이다.  또한 SQS.는 VPC 엔드포인트(Gateway나 Interface 타입)를 통해 프라이빗 네트워크 내부에서 직접 접근이 가능하므로, 굳이 퍼블릭 서브넷에서 운영을 할 필요가 없음. 완전 비효율적이고, 확장성이 떨어짐!!!!!