AWS Message-Driven 실전 2편: SQS 구축과 테스트 검증

이번 포스트에서는 SQS를 설정하고 테스트까지 해보도록 하자

 

---

 

1. SQS란 무엇인가?

---

1-1. SQS(Simple Queue Service)

• AWS에서 제공하는 완전 관리형 메시지 큐 서비스로, 분산 시스템에서 메시지를 저장하고 전달하는 데 사용된다. 이 서비스를 사용하면 서버리스 마이크로서비스, 분산 시스템, 서버 기반 애플리케이션 간에 안정적이고 확장 가능하며 느슨하게 결합된 통신을 구현할 수 있다.
  
  

1-2. SQS의 기능과 장점

1. 탈중앙화 및 비동기 처리
   • SQS를 사용하면 메시지를 큐에 저장하여 애플리케이션의 각 부분이 자신의 속도로 처리할 수 있다. 이는 시스템 간의 탈중앙화를 가능하게 하고, 피크 시간에 발생하는 부하를 관리하는 데 도움이 된다.
     
     
2. 확장성 및 내구성
   • SQS는 자동으로 확장되므로, 처리해야 할 메시지의 양이 증가해도 시스템이 안정적으로 유지된다. 또한, AWS의 인프라를 사용하기 때문에 메시지는 안전하게 보관되며, 처리가 보장된다.
     
     
3. 느슨한 결합과 시스템 분리
   • SQS를 사용하면 서비스 간에 직접적인 연결 없이도 메시지를 주고받을 수 있다. 이는 서비스가 서로에 대해 덜 의존적이 되도록 하여, 유지보수와 확장성을 향상시킨다.

 

1-3. SNS와 SQS의 조합 사용 이유

1. 멀티 캐스팅 메시지
   • SNS는 메시지를 여러 SQS 큐로 전달할 수 있는 "publish/subscribe" 모델을 제공한다. 이를 통해 하나의 이벤트를 여러 시스템이나 서비스가 동시에 받아 처리할 수 있다.
     
     
2. 유연한 메시지 처리
   • SNS로부터 메시지를 받은 SQS는 메시지를 큐에 저장하고, 처리 준비가 된 서비스가 메시지를 가져가 처리할 수 있도록 한다. 이는 효율적인 작업 분배와 부하 관리를 가능하게 한다.
     
     
3. 신뢰성 있는 메시지 전달
   • SNS와 SQS를 함께 사용하면 메시지가 유실되지 않고 안정적으로 처리될 수 있도록 하는 여러 AWS의 내구성 있는 기능을 활용할 수 있다.

 

1-4. 다이어그램 예시

AWS SNS-SQS diagram

 

• 이 다이어그램은 AWS의 SNS와 SQS를 활용한 메시지 기반의 분산 시스템을 나타낸다.
• 주문 서비스는 SNS 토픽에 주문 정보를 publish 하고, 이 토픽은 메시지를 세 개의 SQS 큐로 분배(distribute)한다.
• 각 큐는 결제 서비스(Payment Service), 재고 서비스(Inventory Service), 알림 서비스(Notification Service)로 연결되어 있으며, 각 서비스는 자신에게 할당된 큐에서 메시지를 가져와 처리한다.
• 이 구조는 각 서비스의 독립적인 처리를 가능하게 하여 시스템의 탄력성과 확장성을 제공한다.

 

---

 

2. SQS 생성하기

---

2-1. SQS 찾기

• SNS를 만들었으니 이번에는 SQS를 만들도록 하자 (각각 만들고 3편에서 연동시킨다.)

SQS 생성하기

 

2-2. 대기열 생성

• 아래와 같은 페이지로 이동할 텐데 여기서 "대기열 생성" 버튼을 클릭한다.

SQS 메시지 대기열 생성

 

2-3. 대기열 생성 - 유형 선택

• 대기열 생성에서 유형은 "표준"을 선택하고 이름을 작성한다.

SQS 대기열 생성 - 유형선택

 

2-4. 대기열 생성 - 구성

• 아래로 스크롤해서 "구성" 설정을 하는데 좌측 박스 친 부분은 default설정을 그대로 두고 진행했으며 우측도 default값을 그대로 설정했다. (필요시 보존 기간 수정)

대기열 생성 - 구성

 

2-5. "구성"의 각 선택에 대한 설명

1. 표시 제한 시간 (Visibility Timeout)
   • 메시지가 큐에서 한 번 가져가진 후 다른 컨슈머가 못 보게 하는 시간.
   • 처리 후 삭제 안 하면 다시 보이게 됨. 처리 시간 내에 삭제해야 함.
   • 기본값은 30초, 처리 시간에 맞게 조절 필요.
   • 큐의 모든 메시지에 적용됨.
   • AWS SDK 읽기 시간보다 길게 설정하는 게 좋음.
     
     
2. 메시지 보존 기간 (Message Retention Period)
   • 메시지가 큐에 남아있는 최대 시간.
   • 1분부터 14일까지 설정 가능.
   • 배달 못한 메시지 대기열(Dead Letter Queue)의 보존 기간은 원래 큐의 보존 기간보다 길게 설정해야 함.
     
     
3. 전송 지연 (Delivery Delay)
   1. 메시지가 큐에 추가된 후 소비되기 전까지 지연되는 시간.
   2. 0초부터 15분까지 설정 가능.
   3. Standard 큐는 설정 시간이 계속 흘러가고, FIFO 큐는 설정 변경 후 메시지부터 적용됨.
      
      
4. 최대 메시지 크기 (Maximum Message Size)
   1. 큐에 보낼 수 있는 메시지의 최대 크기.
   2. 1바이트부터 256KB까지 가능.
   3. 256KB 이상은 Amazon SQS Extended Client Library 사용해서 S3 참조 포함 메시지로 전송 가능.
   4. 최대 2GB까지 가능.
      
      
5. 메시지 수신 대기 시간 (Receive Message Wait Time)
   1. 메시지 폴링 시 최대 대기 시간.
   2. 0초부터 20초까지 설정 가능.
   3. 긴 폴링으로 비용 절감 가능, 메시지가 있으면 즉시 반환.
   4. 0초 설정 시 짧은 폴링이 됨.
      
      
6. 콘텐츠 기반 중복 제거 (Content-Based Deduplication)
   1. 메시지 본문을 기반으로 중복 제거 ID 자동 생성.
   2. 중복 메시지 방지 기능임.

 

2-6. 대기열 생성 - 액세스 정책

• 기본 설정은 대기열 소유자만이 SQS 큐에 접근할 수 있게 한다.
• '커스텀 역할' 옵션을 통해 다른 AWS 계정, IAM 역할, IAM 사용자에게 큐 접근 권한을 부여할 수 있다. 이는 S3, SNS 등 다른 AWS 서비스와 큐를 통합할 때 특히 유용하다.
• 예를 들어, S3 버킷에서 파일이 업로드될 때 자동으로 SQS 메시지를 생성하거나, SNS 토픽으로부터 메시지를 받아 SQS 큐로 전달할 수 있게 설정 가능하다.

SQS access policy

 

 

2-7. 대기열 생성 - 리드라이브 허용 정책 (선택사항)

• 리드라이브 허용 정책 설정은 메시지 처리 실패 시 대응 방법을 정의하는 것이고, 그중 하나의 옵션이 배달 못한 편지 대기열 설정이다. 이 설정을 통해 실패한 메시지를 어떻게 처리할지 결정할 수 있다.
• 나는 비활성화했다.

SQS - 리드라이브 허용 정책

 

 

2-8. 대기열 생성 - 배달 못한 편지 대기열 (선택사항)

• 배달 못한 편지 대기열 설정은 실패한 메시지를 위한 DLQ(Dead Letter Queue)를 지정하는 부분이다.
• 메시지가 설정된 재시도 횟수를 초과하여 여전히 처리되지 못했을 때, 해당 메시지를 DLQ로 보내서 관리할 수 있게 해 준다.
• 이렇게 DLQ를 사용하면 실패한 메시지를 분리하여 문제 해결을 위한 분석이나 후속 조치를 취할 수 있다.
• 나는 비활성화했다.

SQS - 배달 못한 편지 대기열

 

2-9. 대기열 생성 - 태그 (선택 사항)

• 맨 하단의 "태그" 파트는 작성하지 않고(default상태) 하단의 “대기열 생성” 버튼을 누른다.

SQS 태그 선택

 

2-10. 대기열 생성 성공

• 대기열 생성에 성공하면 아래와 같이 방금 만든 대기열 세부정보 페이지로 이동하게 된다.
• 상단에 저런 초록색 팝업창이 나올 것이다.

SQS 대기열 생성 완료

 

---

 

3. SQS 메시지 테스트 하기 

---

3-1. 메시지 전송페이지 이동

• 방금 만든 SQS 대기열의 "세부 정보"로 들어가서 상단의 “메시지 전송 및 수신” 버튼을 클릭한다.

메시지 전송 및 수신버튼

 

3-2. 메시지 전송하기

• 메시지 전송 및 수신에서 “메시지 본문”에 내용을 작성하고 우측의 “메시지 전송” 버튼을 누른다.

sqs 메시지 전송하기

 

• 아래와 같이 메시지가 전송되었다고 나올 것이다.

sqs 메시지 전송 성공

 

3-3. 메시지 수신(폴링)하기

• 페이지 하단으로 스크롤해서 내려가면 “메시지 수신” 목록에 "사용 가능한 메시지"가 1개 생긴 것을 확인할 수 있을 것이다.
• 이제 우측 상단의 “메시지 폴링” 버튼을 클릭하자

sqs 메시지 폴링하기

 

 

3-4. 폴링 진행상황 확인하기

• 아래와 같이 “폴링 진행 상황”이 변동되고 하단에는 수신받은 메시지의 정보가 보이게 된다.

sqs 메시지 폴링 진행상황

 

• 이 상태에서 조금 기다리면 아래와 같이 "폴링 진행 상황"에 체크표시가 생긴다.

sqs 메시지 폴링 성공

 

3-5. 폴링 된 메시지 확인하기

• 위에서 메시지 목록에 있는 ID를 클릭하면 하단과 같이 팝업창이 열릴 것이고 여기에 내가 보냈던 메시지가 적혀있을 것이다.

SQS 폴링된 메시지 확인

 

 

 

이렇게 SQS 설정까지 마쳤는데 진행하면서 이 과정이 생각보다 간단하다고 느꼈다.
AWS는 참 사용자가 편하게 설계된 것 같다.
내부의 깊은 곳으로 들어간다면 당연히 어렵겠지만 이 정도의 클릭만으로도 누구나 보고 따라 해서 설계할 수 있도록 만들었다는 것에 새삼 대단함을 느낀다.
다음 포스트에서는 SNS와 SQS를 연동하고 테스트를 진행한다.

 

---

 

2023.11.06 - [AWS] - AWS Message-Driven 완성 3편: SNS와 SQS 연동 및 테스트 전략

AWS Message-Driven 완성 3편: SNS와 SQS 연동 및 테스트 전략

 

 

2023.11.06 - [AWS] - AWS Message-Driven 입문 1편: SNS 설정으로 시작하는 MSA

AWS Message-Driven 입문 1편: SNS 설정으로 시작하는 MSA