분산환경에서 SQS 리스너 서버 고려점

0. 서론

---

SQS를 사용하면 이벤트를 처리하는 서버가 한대 있을 때는 별로 걱정할 것이 없으나, 이벤트 처리하는 서버가 다운 타임 없이 SQS를 이용해 이벤트를 처리하고 싶은 경우 고려해야 할 요소들이 몇 개 있다고 생각했습니다.

• 메세지 서버가 다운되었을 경우 처리
• 메세지 중복 처리

그래서 SQS는 어떤 방식으로 분산환경에서 이런 문제들을 해결하고 있는지 알아보고 정리하고자 글을 작성합니다.

 

1. SQS 알아보기

---

SQS란?

• 분산 소프트웨어 시스템 및 구성 요소를 통합하고 분리할 수 있는 안전하고 내구성이 뛰어나며 사용 가능한 호스팅 대기열을 제공합니다.

SQS의  주요 특징?

완전관리형 서비스

• 인프라를 직접 운영할 필요 없이 AWS에서 자동으로 관리해 줌
• 확장성이 뛰어나며 트래픽 증가에 자동 대응

가용성 및 내구성

• 분산 대기열을 통해 고가용성 및 내구성을 보장
• 실제로 SQS Server는 여러대로 구성되어있고, 각각의 큐에서 메시지를 가지고 있음
• 메시지 보관 기간을 최소 60초에서 최대 14일로 설정 가능

SQS 아키텍처

보안

• IAM(Identity and Access Management)을 통한 접근 제어
• Server-Side Encryption (SSE)을 통한 데이터 암호화 지원

SQS의 대기열 종류

표준 대기열

• 제한 없이 메시지를 처리
• 최소 한번 메시지 전달해 메시지 중복 처리가 발생할 수 있음
• 메시지 순서를 지키려고 하지만 보장받지 못함
• 높은 처리량이 필요한 서비스에 적합

FIFO 대기열

• 메시지 순서 보장
• 정확히 한 번만 전달해 중복 처리 방지할 수 있음
• 기본적으로 초당 300개의 메시지를 처리함
• 결제 시스템과 같은 순서 보장이 필요한 서비스에 적합함

 

2. SQS ACK

---

예상 문제점

• SQS 리스너 서버가 모종의 이유로 다운되었을 경우, 현재 작업하고 있던 SQS 메시지가 어떻게 될지 고민해 봄
• 문제에 대한 해결책을 찾기 전에는 SQS 메시지가 유실될 수도 있다고 생각함

해결책

• SQS의 Acknowledge를 이용해서 메시지가 잘 처리되었는지 확인할 수 있음
• SQS는 Acknowledge를 받기 전까지 Message를 삭제하지 않기 때문에 메시지가 유실되는 일이 없음
• 만약 문제가 발생해 Acknowledge를 받지 못한 경우, 설정한 Visibility Timeout이 지나면 동일 메시지를 다른 SQS 리스너 서버에서 처리할 수 있게 됨

SQS ACK, NACK

Acknowledgement 

표준 SQS Acknowledgement Default

• Acknowledgement Interval: 1초
• Acknowledgement Threshold: 10개 메시지
• Acknowledgement Ordering: 병렬

FIFO SQS Acknowledgement Default

• Acknowledgement Interval: 즉시 처리
• Acknowledgement Threshold: 즉시 처리
• Acknowledgement Ordering:  즉시 처리하는 경우 병렬, 배치 처리하는 경우 순서대로

Acknowledgement Mode 종류

• ON_SUCCESS - 메시지가 성공한 경우에만 Acknowledges
• ALWAYS - 메시지 성공 여부에 상관없이 항상 Acknowledges
• MANUAL - 프레임워크를 이용하지 않고 Listener 메서드의 Acknowledgement 객체를 이용해서 다룸

 

3. SQS Visibility Timeout

---

예상 문제점

• SQS 리스너 서버가 여러대라고 가정
• SQS 메시지를 여러 대의 서버가 하나의 메시지를 중복해서 처리할 수 있는 가능성도 있다고 생각함.
• 이 경우 이메일 발송이나, 결제를 진행하는 경우 원하는 방향으로 동작하지 않을 수 있음.

해결책

• SQS의 Visibility Timeout을 사용하면 이를 해결할 수 있음.
• SQS로부터 메시지를 받으면 대기열에 남아 있지만, Visibility Timeout 시간 동안 다른 Consumer에게 표시되지 않습니다.
• 이러한 가시성을 통해 다른 Consumer가 중복으로 메시지를 처리하지 않도록 할 수 있습니다.

Visibility Timeout 시간동안 Message not returned

완벽한 해결책은 아니다?

• Visibility Timeout을 초과한 후에 다른 Consumer에서 동일한 메세지를 소비하는 경우가 발생할 수 있음
• 작업에 대한 타임아웃을 Visibility Timeout으로 설정한 시간보다 작게 설정해 중복으로 메시지를 처리하지 않도록 제어

4. 추가로 고민해 볼 문제

---

롤링 배포 시 메시지 정합성 문제

상황은 다음과 같습니다.

• 멀티모듈 아키텍처로 이루어져 있고, SQS로 전달할 메시지 객체를 API 서버와 SQS Listener 서버가 공통으로 사용하고 있음
• 새로운 데이터를 추가한 메시지 객체가 있고, 해당 객체를 바탕으로 신버전의 API 서버가 구버전의 Listener 서버로 메시지를 전달할 때, 객체의 정보가 달라 정합성 문제가 발생할 수 있다고 생각

해당 문제를 해결하고 싶지만 롤링 배포 방식의 고유 단점 때문에 근본적인 문제인 배포 방식을 Blue-Green으로 변경하는 것이 유일한 해결책이라 생각하고 있습니다. 문제점에 대해 지적할 점이나 해결책에 대한 정보가 있다면 댓글 한번 부탁드리겠습니다.

 

이것으로 글을 마무리하겠습니다. 읽어주셔서 감사합니다.

 

래퍼런스

• https://channel.io/ko/blog/articles/1d129345
• https://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html
• https://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html
• https://docs.awspring.io/spring-cloud-aws/docs/3.0.0-SNAPSHOT/reference/html/index.html#acknowledging-messages
• https://aws.amazon.com/ko/blogs/tech/how-channel-talk-handles-high-volume-traffic-with-amazon-sqs/