AWS SQS를 이용하여 테넌트 별 비동기 작업 줄세우기

최근 회사에서 진행 중인 작업에서 아래와 같은 요구사항을 만나게 되었습니다.

• 서비스 내에는 수 많은 테넌트가 존재
• 각 테넌트 내에서는 특정 이벤트가 발생하고, 이를 처리하는 워커 로직이 필요 (한번 실행에 500ms ~ 5s, 테넌트 내 데이터 양에 비례)
• 이벤트 발생 빈도는 높지 않음
• 이 때 이들 워커 로직은 테넌트 별로 오로지 하나씩만 동작해야 함. (테넌트 내 동시성 X)

해당 글에서는 이 요구사항을 만족시키기 위한 방안에 대해 다뤄보도록 하겠습니다.

최초 구현

초기에는 이 요구사항을 만족시키기 위해, 아래와 같은 방향성으로 작업을 진행했습니다. 각 구조에 대한 설명은 아래와 같습니다.

• 서버 애플리케이션에서는 유저의 특정 행동에 따라 이벤트를 발행하여 SQS로 전달합니다.
• 전달된 이벤트는 사전에 등록된 AWS 람다를 트리거하여 소비됩니다.
• 이 때 람다에서는 작업에 앞서, 테넌트 별 유일성을 보장하기 위해 테넌트 식별자를 통한 분산락을 요청합니다. 이 때 분산락은 Mysql의 Named Lock을 통해 구현하였습니다.
• Named Lock을 대기하다가 최대 대기 시간(10s)을 넘어가는 케이스는 DLQ를 통해 큐에 다시 넣어주도록 구현했습니다.

최초 구현 방식의 문제

위처럼 구현하고나니 크게 두가지 문제가 있었습니다.

첫번째는 비용 문제입니다.

위 구조에서는 이벤트가 큐에 들어가고 나면 일단 람다를 띄우고 거기에서 분산락을 대기하며 테넌트 별 동시성을 제어합니다. 람다의 경우엔 실제 실행시간에 비례하여 비용이 발생하기 때문에, 실제 로직의 동작 외에 불필요하게 락을 대기하는 시간이 모두 비용에 포함되게 됩니다. 이벤트가 스팟성으로 많이 발생하는 상황에서는 단 10초 간 실행될 수 있는 만큼의 이벤트만 소비되고, 나머지 이벤트들은 전부 10초 간 대기 후 재시도하게 되는데 동시성 제어를 위한 락 대기에 거의 모든 시간이 소비되어 비용적인 측면에서 엄청난 낭비가 발생합니다.

두번째는 혼잡 제어 문제입니다.

위 구조에서는 동시에 발생한 이벤트들 중, 락을 획득한 단 하나의 프로세스를 제외하면 재시도 단계에서 그대로 동일한 경쟁자들과 경합이 발생합니다. 이는 위에서 언급한 비용 문제를 더욱 심화시킵니다.

개선된 구현 방안

다음은 최초 구현에서 발생하던 문제를 해소한 구조입니다. 적용된 아이디어는 아래와 같습니다.

• 각 이벤트들은 이벤트 페이로드 내에 최대 재시도 횟수를 갖습니다.
• 이벤트로 인해 트리거된 람다 워커에서 분산락 획득을 시도는 하나, 대기는 하지 않습니다.
• 분산락 획득에 실패한 이벤트들은 페이로드 내 재시도 횟수를 하나 감소시킨채 큐에 다시 밀어넣습니다.
• 이 때 SQS Delay Seconds 옵션을 도입하여 분산락 획득 프로세스의 로직이 끝난 뒤 람다에 전달될 수 있도록 텀을 가집니다.
• 재시도 횟수가 늘어날수록 현재 해당 테넌트에 대한 이벤트가 전반적으로 혼잡한 것이기 때문에, 재시도 횟수가 늘어날수록 대기 시간이 지수적으로 증가하는 ExponentialBackoff를 도입하여 Delay Seconds를 계산합니다.
• 모든 실패 이벤트들이 동일한 Delay Seconds를 가질 경우 다음 페이즈에서 동일하게 경쟁할 것이기 때문에, Backoff 시간을 계산할 때 랜덤성을 추가합니다.
• 이전 방식에 비해 평균 재시도 횟수가 늘어날 것이기 때문에 최대 재시도 횟수를 넉넉하게 주도록 하고, 최대 재시도 횟수를 넘은 경우엔 DLQ를 통해 개발자들이 알 수 있게 합니다.

추가적으로 고민 해볼 내용

위와 같이 개선점을 반영한 뒤에도 더 나은 방식이 없을까 하고 리서치를 계속하고 있습니다.

그리고 현재까지 확인한 내용 중 가장 적용해봄직한 방안은 바로 SQS의 메시지 그룹 기능을 이용하는 것입니다.

SQS의 메시지 그룹은 쉽게 말하면 SQS 내부에서 FIFO를 보장하는 최소 단위인데요. 메시지 그룹 ID를 테넌트 식별자로 사용하는 방법을 이용하면 "테넌트 별 동시성" 요구사항을 쉽게 충족할 수 있어보입니다.

다만 FIFO와 기존에 사용하던 Standard는 Trade off로 작용하는 구간들이 존재하는데, 이에 대한 검증이 아직은 부족하여 도입을 못해보고 있는 상황입니다.

참고

• https://channel.io/ko/blog/articles/1d129345
• https://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-queue-types.html