이번 포스팅에서는 Amazon SQS가 무엇인지 알아보고 실제 프로젝트에 적용해보는 시간을 가져보도록 하겠습니다.
해당 포스팅은 참고 자료에 올려진 사이트를 보며 공부한 내용입니다. 대단히 도움 많이 받았습니다. 감사합니다.
✈️ Amazon SQS란?
Amazon Simple Queue Service 공식 홈페이지
Amazon Simple Queue Service(SQS)는 마이크로 서비스, 분산 시스템 및 서버리스 애플리케이션을 쉽게 분리하고 확장할 수 있도록 지원하는 완전관리형 메시지 대기열 서비스입니다.
쉽게 말해 Amazon SQ는 AWS에서 운영해주는 메시지 큐 서비스입니다. 메시지 큐 서비스(또는 메시지 브로커)는, 소프트웨어 시스템 사이에 메시지를 주고 받을 수 있는 미들웨어를 의미합니다.
메시지 큐에 관해 알고 싶으신 분은 아래 링크로 들어가시면 좋을 것 같습니다.
마이크로 서비스(MSA) 사이에 메시지 큐를 두어 각 서비스 간의 메시지를 전달할 수 있습니다. 메시지 큐는 일반적으로 장애에 대한 내성이 높고, 메시지를 안전하게 저장해서 유실되지 않게 보장해줍니다.
마이크로 서비스끼리 직접 통신
사진 출처 : https://note.hatemogi.com/amazon-sqs.html
마이크로 서비스 A와 B가 통신을 해야 하는 상황에, 보통의 네트워크 통신을 한다면, 즉각적으로 결과를 확인해가며 동기식(synchronous)으로 통신할 수 있습니다. 대신 A나 B 둘 중 하나만 문제 상항을 만나더라도 전체 시스템이 실패하는 문제가 있습니다.
예를 들어 서비스 B에 장애가 발생하면, 해당 메시지를 주고 받아야 했던 상황 전체가, 시스템 차원에서 실패하게 됩니다. 즉, 서비스 B가 장애가 발생한다면 장애를 복구한 후 서비스 A가 서비스 B에게 다시 메시지를 재전송해야한다는 문제가 발생합니다.
메시지 큐를 활용한 간접 통신
사진 출처 : https://note.hatemogi.com/amazon-sqs.html
마이크로 서비스 중간에 메시지 큐 서비스를 활용하여 통신을 한다면, 메시지 송수신 채널을 유연하게 연결할 수 있습니다.
중간에 메시지 브로커가 안전하고 유연한 버퍼 역할을 해주기 때문에, 메시지를 발송하는 쪽에서 메시지 수신에 대한 걱정 없이 메시지를 보내고 다른 일을 할 수 있습니다.
예를 들어, 서비스 B에서 일시적인 문제가 발생했다고 하더라도, 서비스 A에서는 정상적으로 메시지를 브로커에 전달하고 자기 할 일을 하러가면 됩니다. 서비스 B 입장에서는 다시 정상 동작하는 시점에 해당 메시지를 가져올 수 있습니다.
✈️ Amazon SQS 특징
AWS에서 운영하고 있는 Amazon SQS의 특징에 대해서 알아보도록 하겠습니다.
사진 출처 : https://note.hatemogi.com/amazon-sqs.html
Producer는 메시지를 보내는 쪽을 의미하고, 받아서 사용하는 쪽을 Consumer라고 부릅니다.
SQS 시스템을 도입하면 MSA 환경에서의 시스템 확장성을 높일 수 있습니다.
예를 들어 고객의 요청을 받은 ELB 로드 밸런서가 웹 서비스들로 부하를 분산시켜주고, 각각의 웹 서비스 인스턴스들이 각자 SQS 큐에 메시지를 쌓고, 뒷 단에서 메시지를 처리하는 마이크로 서비스가 묵묵히 자기 일을 하는 식으로 시스템을 구성할 수 있습니다.
DB 값을 바꾸는 일처럼, 당장 즉각적인 처리르 반드시 해야하는 일만 앞단에서 처리하고, 이어서 관련한 시간이 오래 걸리는 일들을 분리해서, 큐 뒷단에서 처리할 수 있습니다.
기본 특징
SQS의 각 메시지는 최대 256KB 크기입니다. S3에 메시지 본문을 담는 방식을 추가로 지원하기 때문에, 제한 없이 사용할 수 있습니다.
또한 큐에 저장되는 메시지 건 수의 제한이 없습니다. 다만 각각의 메시지 유효기간은 최대 14일입니다. 14일 이내에 메시지를 처리해야합니다.
두 가지 큐 종류 - 표준 대기열 VS FIFO 대기열
보통의 메시지 큐 시스템은, 기본적으로 최소 한번 전송(at least once delivery)을 약속합니다. 혹시 문제가 생겼을 때, 최소한 한 번 이상 메시지를 전송해준다는 의미인데 여러 번 전송될 수도 있지만 어쨌든 유실되지 않는다는 약속을 지킵니다.
표준 대기열에서 적용하는 큐 시스템이며, FIFO 대기열을 선택하면, 정확히 한번(exactly once) 전송을 약속합니다. 최소 한번 전송 방식에서, 중복 여부를 브로커가 확인해줘서 두 번째 중복 메시지부터는 버려주는 시스템입니다.
FIFO 대기열 시스템은, 표준 대기열 시스템에 비해 확장성이 떨어지고, 비용이 약간 비쌉니다. 비용적인 측면에서는 둘 다 아주 저렴한 수준이긴 하지만 확장성에서 차이가 많이 일어납니다.
표준 대기열 시스템은 거의 무한대의 처리량을 지원하고, FIFO 시스템은 초당 최대 300건의 메시지 API를 처리할 수 있습니다. 한 번의 API에 최대 10개 메시지를 한 번에 배치 처리할 수 있기 때문에 초당 최대 3천건의 메시지를 처리할 수 있는 제한이 있습니다. 규모가 커질 경우 이런 제한이 문제가 될 수 있습니다. 그리고, FIFO 시스템은 메시지 전달 순서도 보장됩니다. 먼저 보낸 메시지가 먼저 수신됩니다. 이는 수신부가 하나여야 의미가 있긴 합니다.
표 출처 : https://note.hatemogi.com/amazon-sqs.html
메시지 생명 주기 - lifecycle
-
메시지 송신부(producer)가 SQS에 메시지 A를 보냅니다.
-
SQS는 메시지A를 사본을 만들어 여러 곳에 안전하게 보관합니다. (유실 방지)
-
수신부(consumer)가 SQS에서 메시지 A를 처리하고자 가져갑니다. (inflight 상태)
-
SQS입장에서 수신부가 메시지A를 가져갔기 때문에, 큐에 메시지가 남아있기는 하지만, 다른 컨슈머가 메시지 A를 (또) 가져가지 않도록 일정시간동안(visibility timeout) 수신요청에 드러나지 않습니다.
-
수신부(consumer)가 메시지를 정상 처리 완료했다면, 직접 SQS에 메시지A를 삭제하도록 요청합니다. (완료)
-
만약 어떤 이유로 수신부(consumer)가 메시지를 삭제하지 않는다면, 일정 시간이 지나면, 메시지 A가 다시 수신 요청에 드러납니다. (재처리 가능)
visibility timeout – 기본 30초. 0초에서 12시간 사이 설정 가능. 기본은 큐에 설정. 메시지 개별 설정도 가능.
