SQS, standard-queues를 사용하여 개발한다면 어떤 것을 고려해야할까?

sqs에서 서버로 message가 올 순서를 보장하는 방법에 대해 설명하려고 한다.

 

먼저 문제의 상황을 하나 가정해보자.

 

"글 작성"과 "글 수정" 요청이 sqs의 message로 오게되어서 처리하려고 한다.

이 과정은 순차적으로 수행되어야 한다. 글 수정을 하려면 글 작성이 되지않으면 안되기 때문이다.

 

fifo 구조의 queue라면 문제가 없지만, 순서를 보장하지 않는 standard라면 얘기가 달라진다.

서버가 멈추거나 늦게 처리되는 등 모종의 이유로 인해 순서가 바뀌어서 올 수도 있으므로 동시성 처리를 해주어야한다.

 

이러한 기능을 구현하기 위해 고려해야할 것들을 생각해보면 다음 두가지이다.

 

1. 글 수정을 하기전 글이 DB에 존재하는지 확인을 해야한다. (존재하지 않는다면 의도적인 exception을 발생시켜서 MessageVisibility 특성을 이용해서 재시도하게 만들 수 있다. 현재 3.0.0의 spring sqs 라이브러리 기준으로는 서버에서 정상적으로 처리를 해야만, sqs queue에서 message를 삭제하는 것이 Default설정이다.)

2. 수정 요청에도 순서가 중요하고 실제 운용되는 서버는 2대 이상이므로 DB를 이용해서 어떤 글이 최종 수정본으로 남아야하는지 구현해야한다.

 

서비스간에 update요청을 전달하는 문제는 여러가지 상황을 동시에 생각해야하므로 쉽진 않은 것 같다.

앞으로 standard-queues를 사용해서 개발하면서 이런 경우가 생긴다면 다음 4가지를 생각해볼 것이다.

 

1. sqs로 요청된 작업은 멱등성을 가지게 해야한다. 비즈니스 로직이 여러번 수행되더라도 문제 없어야 한다. 멱등성을 가지게 설계를 하던지, 푸쉬알림과 같은 1회성 실행을 만족해야한다면 DB 저장소에 마킹해두어 중복을 필터링함으로써, 여러 consumer에 의해 소비되어도 이상없도록 해야한다.

2. 동시성을 만족하는가. 순서가 있다면 처리 프로세스 내에서 exception을 발생시켜 순서를 보장시켜야 한다.

3. 작업이 Visibility Time(30초~12시간)보다 길게 걸리는가 -> 서버 프로세싱 메서드에도 Time out을 설정해야, 한 consumer에 의해 프로세스가 처리될 때, sqs의 time out에 의한 다른 consumer의 개입을 없앨 수 있다.

4. Retention Time(1분~14일)을 고려해야한다. 메시지가 클러스터에 얼마나 있어야 하는가.

 

요약!

중복 발행 특성 -> 멱등성, 동시성 고려

fallback 관점 -> 작업이 오래걸리는가, 서버가 일정시간 멈추면 언제까지 메시지가 남아있어야할지.

 

 

reference

Spring Cloud AWS

Amazon SQS 제한 시간 초과 - Amazon Simple Queue Service

AWS SQS를 도입하면서 했던 고민을 소개합니다.

SQS with Spring