AWS SQS(Simple Quere Service)

SQS (Simple Queue Service)

SQS(Simple Queue Service)는 애플리케이션을 구성하는 다양한 각각의 컴포넌트가 메시지를 주고받을 수 있게 해주는 관리형 메시지 서비스이다. SQS는 높은 가용성과 탄력성을 제공하여 수십만 건의 메시지를 수 초 만에 처리할 수 있다. 특히 이런 SQS를 좀 더 확장하여 요즘 기술 추세를 보면 애플리케이션 확장성과 신뢰성을 높이기 위해 또 불필요한 요소를 최소화해 하나의 서버에서 실행되는 단일 애플리케이션을 구현하되 각각의 마이크로서비스로 세분화한다. 여기서 마이크로서비스는 서로 다른 서버에서 실행되지만 서로에게 메시지를 전송하며 긴밀하게 통신하고 하나의 마이스크로서비스에 이상이 생기더라도 각각의 서버에서 실행되기 때문에 다른 컴포넌트에는 영향을 주지 않는다. SQS는 메시지를 담는 큐를 생성하고 프로듀서 컴포넌트와 컨슈머 컴포넌트로 구성된다. 프로듀서 컴포넌트는 큐에 메시지를 넣는 역할이고 컨슈머 컴포넌트는 메시지를 읽는 역할을 한다. 메시지의 최대 크기는 256KB이다. 프로듀서 컴포넌트가 SendMessage 액션을 통해 큐에 메시지를 넣는데 이때 큐에 입력된 메시지는 이동 중 메시지라고 하거나 인플라이트 메시지라고 한다. 그리고 큐에 메시지가 들어오면 컨슈머 컴포넌트가 ReceiveMesage 액션을 통해 큐에 있는 메시지를 처리할지 확인하고 메시지를 소비한다. 그리고 컨슈머 컴포넌트는 메시지를 처리한 뒤 DeleteMessage 액션을 통해서 메시지가 있던 큐에서 처리한 메시지를 삭제한다. SQS로 전송되는 API 호출 횟수를 효율적으로 최소화하기 위해 최대 10개의 메시지를 일괄적으로 처리할 수 있다. 전반적인 메시지 흐름은 간단하지만 조금 상세히 보면 나름 복잡한 로직이 있다. 앞서 말한 것처럼 컨슈머 컴포넌트는 처리한 메시지에 대해서 무조건 큐에서 메시지를 삭제하는 건 아니다. 메시지는 기본적으로 보유기간은 4일인데 처리한 메시지에 대해 삭제 여부는 컨슈머 컴포넌트가 결정하게 되고 특정한 컨슈머 컴포넌트가 메시지를 확인한 후에 다른 컨슈머 컴포넌트는 일정 기간 동안 해당 메시지를 확인할 수 없다. 이러한 개념을 가시성 중지 기간이라고 부른다. 가시성 중지 기간은 둘 이상의 컨슈머 컴포넌트가 하나의 메시지를 중복하여 처리하는 경우가 발생하지 않도록 하기 위함이다. 가시성 중지 기간의 기본 시간은 30초이고, 최소 시간은 가시성 중지 기간을 없는 개념으로 0초로 설정할 수 있고 반면에 가시성 중지 기간 최대 시간은 12시간까지도 설정할 수 있다. SQS는 Standard Queue와 FIFO(First-In, First-Out) Queue 두 가지 타입의 Queue가 존재한다. Queue 기반의 애플리케이션들은 큐의 작동 방식에 따라서 애플리케이션의 성능에 영향을 받기 때문에 애플리케이션에 따라 적절한 Queue를 선택해야 한다. 어떠한 애플리케이션에서는 초당 수천 개의 메시지를 처리해야 하는 경우도 있고, 메시지가 도착하는 대로 즉시 메시지를 처리해야 하는 경우도 있다. Standard Queue는 성능이 월등하여 거의 무제한의 처리 성능을 제공하여 빠르게 다수의 메시지를 처리할 수 있다. 메시지가 순서에 무관하게 전달되고 중복되더라도 Standard Queue는 중복 메시지를 처리할 수 있고 최대 12만 개의 인플라이트 메시지를 처리할 수 있다. FIFO Queue는 Standard Queue보다는 상대적으로 성능이 떨어지는데 초당 3천 개의 메시지를 Queue에 전달할 수 있고 FIFO의 말 그대로 선입선출 방식이기 때문에 순서를 제어할 수는 없다. FIFO Queue는 대략 2만 개의 인플라이트 메시지를 처리할 수 있다. FIFO Queue 다른 특징으로는 단위로 Queue를 분할하여 Queue에 입력된 메시지의 하위 그룹을 만들 수 있다. 메시지를 전송할 때 다수의 프로듀서 컴포넌트가 있는 경우 분할한 메시지 그룹을 이용하여 프로듀서 컴포넌트별 메시지 순서를 관리할 수 있다. Queue에서 메시지를 확인할 때 숏폴링과 롱폴링 중 하나를 선택할 수 있다. 기본값인 숏폴링은 메시지의 누락이 발생하더라도 즉시 메시지를 확인해야 할 때 사용하고, 롱폴링은 정확성이 목적이기 때문에 약간의 지연이 발생할 순 있지만 모든 메시지를 정확하게 확인할 수 있다. 숏폴링을 선택하면 SQS는 대기 중인 메시지 내용만 확인하고 메시지 도착 후 지연 시간이 짧기 때문에 Queue에 메시지가 있는 상황에서 메시지가 없다면 메시지가 없다는 응답을 받을 수도 있다. 다시 말해 지연이 없고 정확성이 떨어지는 만큼 정확성 측면에서 메시지의 착오를 줄이려면 여러 번 조회해야 한다. 반대로 롱폴링을 선택하면 큐에서 대기 중인 모든 메시지를 반환하고 모든 Queue 서버를 확인하므로 응답 시간이 오래 걸린다. 지연시간이 있는 대신에 정확성이 좋아 조회 빈도수가 적기 때문에 숏폴링보다 경제적이라고 할 수 있다. 가끔은 컨슈머 컴포넌트가 정상적으로 처리하지 못한 메시지가 큐에 남을 수 있는데 이를 DeadLetter라고 한다. DeadLetter는 하나의 특정 컨슈머 컴포넌트가 메시지를 처리했으나 실패했고, 이어서 다른 컨슈머 컴포넌트도 마찬가지로 메시지를 처리하는 데 실패하여 남는 메시지이다. DeadLetter는 해당 Queue에서 벗어날 수 없다. 이런 문제를 해결하기 위해 SQS는 Source Queue에서 DeadLetter Queue에 따로 보관할 수 있도록 한다. DeadLetter Queue는 기존의 Queue와 동일한 Queue 타입을 선택해야 한다. Standard Queue일 경우 DeadLetter Queue도 Standard Queue 타입으로, FIFO Queue일 경우 DeadLetter Queue도 Standard Queue 타입이어야 한다. 그다음 Queue의 maxReceiveCount 속성을 이용하여 최대 인출 시도 횟수를 설정하면 된다.