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를 통해 개발자들이 알 수 있게 합니다.

아예 접근을 달리하여 (with SQS FIFO Queue)

위와 같이 개선을 진행했지만, 여전히 한계는 존재했습니다.
무엇보다 락의 대기 시간을 최소화하긴 했으나 어쨌든 람다 워커는 실행되는 것은 계속 거슬리던 지점이었습니다.

람다 레벨에서는 이 문제를 해결할 수 없다고 판단하고, SQS 쪽 문서를 더 확인해봤는데 결론적으로는 SQS FIFO Queue를 이미 지원을 하고 있었고 이를 사용하면 되는 문제였습니다.

다만 FIFO Queue라고 해서 아예 동시성이 1로 제한되는 것이라면 도입이 어려웠을텐데, SQS에서는 FIFO Queue 내부적으로 Message Group을 관리하고 같은 그룹의 메시지들에 한해 동시성을 제한하고 있어서 테넌트 별로 유일한 Message Group ID를 생성하도록 제어하면 그런 문제도 없었습니다.

그렇게 람다 레벨에서의 분산락을 획득하는 로직을 제거하고 효과적으로 비용 최적화를 달성할 수 있었습니다. 다만 이를 도입하는 과정에서도 문제는 존재했습니다.

고정된 Visibility Timeout과 FIFO Queue 문제

SQS에 람다를 붙일 때 고려해야되는 설정 중 하나는 Visibility Timeout입니다. Visibility Timeout이란 아래 그림과 같이, 람다에서 SQS 메시지를 수신한 이후 시점부터 해당 메시지가 다른 람다에 의해 가져가질 수 있는 시점을 컨트롤하는데 이용됩니다. 람다에서 메시지를 수신한다고 SQS에서 메시지가 빼내어지는 것이 아닌, 람다가 메시지를 정상적으로 처리하지 못하는 케이스를 위해 일단은 큐 내부에 남겨두되 다른 람다에게 보여지는데까지는 시간이 걸리는 것으로 이해하면 됩니다.

이 때 람다의 최대 타임아웃은 15분이기 때문에, Visibility Timeout 역시 15분 이상으로 잡아줘야합니다. (물론 람다의 실행 시간을 정확히 알 수 있다면 그보다 짧아질 수 있겠으나 DB IO가 필요한 작업이라면 섣불리 예측하기 어렵습니다.) 이게 일반 SQS Queue에서는 단지 해당 메시지 처리만 지연이 되는 문제로 이어지지만 FIFO Queue에서는 이야기가 다릅니다.

앞서 이야기했듯 FIFO Queue 내부에는 Message Group이 존재하고 이 그룹 별로 람다 동시성을 엄격히 제한합니다. 또한 람다에서 메시지를 수신하더라도 그 즉시 큐에서 빼내지는 않는다고 이야기 했었습니다. 그런 상황에서 람다가 예상하지 못한 문제로 인해 비정상적으로 동작하게 된다면, Visibility Timeout 설정과 맞물려 해당 Message Group은 Visibility Timeout이 발생하고 해당 메시지가 다시 정상적으로 처리될 때까지 그 이후 모든 메시지가 지연되게 됩니다.

Visibility Timeout 문제의 해결

다행히도 AWS SQS는 ChangeMessageVisibility 커맨드를 통해 특정 메시지 단위로 Visibility Timeout 값을 변경하는 것이 가능합니다.

핸들러 로직 전체에 try-catch를 걸어주고 에러를 캐치하는 부분에서 ChangeMessageVisibility 커맨드를 실행 후 람다를 종료시킵니다. 그렇게 되면 FIFO Queue에서 특정 메시지가 실패하더라도, 해당 메시지는 이후 메시지들의 처리를 막지 않고 빠르게 재시도 혹은 DLQ로 전달될 것입니다.

아래는 NodeJS로 작성된 예시입니다.

export const handler: SQSHandler = async event => {
  for (const record of event.Records) {
    try {
      // 메시지 처리 로직
    } catch (err) {
      const sqsClient = new SQSClient({
        ...SQS Client를 위한 설정 추가
      })
      await sqsClient.send(
        new ChangeMessageVisibilityCommand({
          QueueUrl: 'your-queue-url',
          ReceiptHandle: record.receiptHandle,
          VisibilityTimeout: 5, // 5초 뒤 다시 람다에 전달됨
        }),
      )
      throw err
    }
  }
}

참고

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