AWS 스탠다드 SQS를 FIFO SQS처럼 사용하기

서비스간 통신을 위해서 여러가지 방법이 있지만, 최근 가장 일반적인 방법은 메시지큐를 사용하는 것이며 그 중 가장 보편화된 인프라가 AWS의 SQS이다. SQS는 두가지의 타입이 존재하는데, Standard 큐와 FIFO 큐이다. 두가지의 차이점은 지난번 포스팅에 있다.

2023.02.23 - [개발 이야기] - AWS SQS의 활용

AWS SQS의 활용

 

비즈니스 요건 상 반드시 FIFO를 사용해야 하는 경우가 있다. 왜냐하면, Standard SQS는 First Input, First Output을 지원하지 않기 때문이다. 다음과 같은 상황을 생각해 보자

• 상품의 가격이 100원에서 300원으로, 다시 200원으로 변경되었다. 연결된 모든 서비스에서 가격을 변경해야 한다. 만약 메시지 순서가 보장되지 않는다면 연계된 서비스에서 200원을 처음 적용시킨 뒤 300원을 나중에 적용하는 크리티컬한 문제가 발생한다.
• 사용자의 이름이 Hello에서 World로 변경되었고 다시 Console로 변경되었다. 연계된 서비스에서는 Console이란 이름을 가져야하나 메시지 순서가 보장되지 않는다면 World라는 이름을 가지고 있을 수도 있다.

 

이러한 크리티컬한 상황에서 스탠다드 큐를 FIFO처럼 사용할 수 있는 방법이 있으니 바로 Timestamp를 이용하는 방법이다. 데이터가 변경된 시스템에서 메시지를 퍼블리쉬한 Timestamp를 넣어주고 연계된 시스템의 타깃 테이블에 이 Timestamp를 같이 저장하는 방법이다. 

위와 같은 테이블 구조를 가지고 있으면서 데이터를 적용하기 전에 Timestamp 값을 비교하는 방법이 유일하게 FIFO 방식으로 데이터를 처리할 수 있는 방법이다. 만약 처리하는 메시지의 Timestamp가 테이블의 Timestamp보다 값이 작으면 그 메시지를 무시하게 된다면 메시지 순서에 상관 없이 올바른 데이터를 저장할 수 있게 된다.

 

물론 이 방법을 사용하면 불필요한 데이터 SELECT가 한 번 더 발생하나, 한 Row의 SELECT는 퍼포먼스에도 크게 상관 없으니 비싼 FIFO 큐보다 저렴한 Standard 큐를 FIFO 처럼 사용할 수 있는 방법이 되겠다. Audit 목적으로 받은 모든 메시지를 별도에 테이블에 저장한다면 왜 중간의 메시지가 무시되었는지도 모두 트랙킹 할 수 있을 것이다.