fromm의 SQS와 DLQ - 1. DeadLetterQueue를 도입하기까지

안녕하세요. 노머스 백엔드팀에서 fromm 서비스를 개발하는 김연태입니다.

fromm의 Event Driven

fromm의 서비스는 크게 아티스트와 프라이빗메시지를 주고받을 수 있는 fromm 앱과 fromm 앱의 이용권, 아티스트별 굿즈 등을 구매할 수 있는 fromm store 두 개의 서비스로 나뉘어 있습니다. 그리고 각 서비스는 주문, 결제, 프롬친구, 알림 등의 여러 모듈들로 구성되어 있습니다.

여러 모듈로 구성된 서비스에서 상품을 구매했는데 구매과정에서 앱에 이용권이 즉시 등록되지 않았다고, 혹은 앱에서 채팅메시지를 보냈는데 푸시알림이 가지 않았다고 이용권 구매가 실패하거나 채팅메시지 전송이 실패할 필요는 없습니다. 이와 같은 사례들은 즉시 반영되지는 않지만 언젠가 목표한대로 상태가 반영되면 되는 결과적 일관성(eventually consistency)를 통해 컴포넌트간 결합도를 낮출 수 있습니다. fromm 서비스의 백엔드는 이를 위해 event driven architecture를 선택했고 이벤트를 전달할 메시지 큐로 SQS를 활용하고 있습니다.

왜 SQS였나?

메시지 큐로 SQS를 선택한 이유는 다음과 같습니다.

SQS의 높은 트래픽 처리량

SQS는 표준대기열을 사용시 거의 무제한에 가까운 초당 API 작업을 지원하며 동시에 처리가능한 inflight message limit은 120,000개로 현재 fromm 서비스에서 발생하는 트래픽을 처리하기에 충분히 높은 처리량을 보여주고 있습니다. 또한 SQS의 표준대기열은 메시지의 at least once delivery를 보장하여 이벤트가 적절히 처리될 수 있음을 기대할 수 있습니다. 만약 메시지의 완벽한 순서보장과 exactly once가 필요하다면 처리량을 조금 포기하고 표준대기열 대신 FIFO Queue를 사용해도 된다는 옵션도 눈에 띄었습니다.

스파이크성 트래픽에 적절히 대응가능한 Lambda와 조합

fromm 서비스는 아티스트가 프라이빗 메시지를 발송하면 팬들이 다수 유입되며 순간적으로 API call이 다수 일어나는 스파이크성 트래픽의 특성을 보입니다. 미리 스케일아웃을 하기에는 아티스트가 언제 프라이빗메시지를 보낼지는 전혀 예상할 수 없으므로 트래픽이 적은 시점에 늘어난 인스턴스의 유휴자원으로 인한 비용을 포기하던지 SQS의 핸들러가 오토스케일링되는 시간동안 메시지가 늦게 처리될 수 있음을 감수해야 합니다.

SQS의 event handler로 node.js로 만든 Lambda를 활용하며 EC2, ECS의 오토스케일링에 비해 훨씬 빠른 스케일아웃을 할 수 있으며 JVM, .net에 비해 cold start 이슈에서도 비교적 자유로울 수 있습니다.

운영으로부터의 자유

물론 Kafka가 SQS에 비해 높은 성능과 가용성을 보여주고 에코시스템이 다양한 것이 사실이지만 Kafka를 장애없이 운영하기 위해선 많은 지식과 경험이 필요합니다. AWS를 통해 완전히 매니징되는 SQS를 선택함으로써 Kafka를 운영하다 마주칠 수 있는 모니터링, EBS 볼륨이슈, 주키퍼 이슈, 브로커 추가 중 순단 등 수많은 문제에서 자유로울 수 있었고 이런 낮은 러닝커브를 통해 모든 팀원들이 수월하게 SQS를 사용하고 관리할 수 있게 되었습니다.

SQS 사용중 마주한 문제점

그럼에도 불구하고 SQS를 사용하며 마주한 문제가 있습니다.

따로 핸들링 하지 않는 이상 계속 재처리 시도되는 실패한 메시지

SQS에서 메시지를 처리하기 위한 주요 API는 3가지 입니다.

• SendMessage : 메시지를 SQS에 producing 합니다.
• ReceiveMessage : 메시지를 consume 하여 처리합니다.
• DeleteMessage : 처리가 완료된 메시지를 SQS 큐에서 삭제합니다.

SQS는 메시지가 consume 되었다고 즉시 큐에서 삭제되지 않습니다. 핸들러에서 정상적으로 메시지가 처리된 후 DeleteMessage Request가 있어야지만 메시지가 큐에서 삭제되며 DeleteMessage Request가 없다면 메시지는 SQS에 설정된 Visibility Timeout, Delay Seconds을 거친 후 다시 소비될 수 있습니다.

Lambda에서는 명시적으로 DeleteMessage를 호출하지 않으며 정상적으로 Lambda function이 종료된 경우 DeleteMessage Request를 날려주게 됩니다. 따라서 Service 코드 등에서 throw Error가 발생하는 경우 Lambda는 정상적으로 종료되지 않고 DeleteMessage도 되지 않아 일정시간 후 메시지는 계속해서 재처리되게 됩니다.

재처리를 시도해 메시지가 다시 처리될 수 있다면 다행이지만 수차례 재시도 후에도 처리되지 않는 메시지는 대개 써드파티 API 문제 혹은 잘못된 배포로 인한 코드문제 등으로 계속해서 메시지가 처리되지 않을 가능성이 높습니다.

이런 상황이 지속된다면 SQS의 동시에 처리가능한 메시지 수 limit으로 인해 정상적으로 처리되어야 할 메시지가 처리되지 못할 수 있습니다. Error로 인한 알람을 걸어뒀다면 무한히 울리는 알람은 덤입니다😭

확인하기 어려운 실패한 메시지 레코드

SQS의 메시지가 큐에 들어와 Delay Seconds 동안 혹은 ReceiveMessage Request를 통해 Visibility Timeout 동안은 invisible 상태로 AWS console 에서 메시지의 레코드 내용을 확인할 수 없습니다. 하지만 만약 메시지가 지속적으로 실패를 해 재시도가 일어나고 있고 어플리케이션 로그로 원인을 찾지 못한다면 레코드 내용을 직접 확인해 잘못된 값이 있는지 원인을 찾아보고 싶을 때가 있습니다. 이런 경우 실패한 메시지를 언제 invisible 상태가 아니라 볼 수 있는지, 볼 수 있는 메시지가 있다 하더라도 정상적으로 소비되는 메시지인지 실패한 메시지인지 구분할 수 없어서 메시지의 레코드를 확인 할 수 없었습니다.

DLQ(DeadLetterQueue) 도입

SQS는 사용자가 설정한 횟수만큼 메시지 소비를 시도 후 계속해서 실패하면 실패한 메시지를 모아놓을 수 있는 DLQ를 지원합니다. SQS DLQ를 사용함으로써 앞서 마주한 SQS를 사용할 때의 문제점들을 다음과 같이 해결할 수 있습니다.

• DLQ에 실패한 메시지들이 모여있고 이 메시지들은 항상 visible한 상태이므로 AWS console에서 메시지를 receive해 레코드를 확인할 수 있다.
• 컨슈머에서 실패했을 때 알람을 보내기보단 DLQ로 전송될 때 알람을 보내는 방식을 통해 계속되는 알람을 받는게 아니라 1회만 알람을 받을 수 있다.
• 문제가 발생했을 때 내부 코드, 인프라, 서드파티 API 등 문제가 해결된다면 해결된 후 DLQ의 메시지를 Origin Queue로 Redrive해 다시 정상적으로 소비시킬 수 있다.

이러한 장점들 때문에 저희 팀에서는 즉시 DLQ를 도입해 기존의 문제점들을 해결하고자 했습니다.

DLQ 구성하기

간단한 소스코드 예시를 통해 어떻게 DLQ를 구성할 수 있는지 알아보겠습니다.

DLQ를 만드는 방법은 AWS console을 통하거나 AWS CLI, CloudFormation 등 여러 방법이 있지만 예시에서는 Lambda를 프로비져닝 할 때 많이 사용하는 serverless framework를 통해 SQS Queue, DLQ, Lambda Handler를 구성해 보도록 하겠습니다.

Lambda Handler Source Code

lambda.ts

export const handler = async event => {
  const app = await NestFactory.create(AppModule);
  
  const helloFrommService = app.get(HelloFrommService);

  try {
    await helloFrommService.executeTestData(JSON.parse(event.Records[0].body));
  } catch (e) {
    // logging, alerting, etc...
    throw e;
  }
}

Lambda 핸들러는 DLQ를 사용하지 않을때의 소스코드와 크게 다르지 않습니다.

다만 지정된 횟수만큼 메시지가 재시도 된 후 DLQ로 메시지가 보내질 때에만 알람을 받고 싶다면 catch 블록 안에서 if (*event*.Records[0].attributes.ApproximateReceiveCount >= maxReceiveCount){ ...alert } 를 통해 알람을 받을 수 있습니다.

serverless YAML config

serverless.yml

service: hello-fromm

provider:
  name: aws
  runtime: nodejs18.x
  region: ap-northeast-2
  memorySize: 1024
  timeout: 60
  tracing:
    lambda: true

functions:
  HelloFromm:
    handler: src/lambda.handler
    events:
      - sqs:
          arn:
            Fn::GetAtt:
              - HelloFrommQueue
              - Arn

resources:
  Resources:
    HelloFrommQueue:
      Type: AWS::SQS::Queue
      Properties:
        QueueName: Hello-Fromm-Queue
        VisibilityTimeout: 60
        MessageRetentionPeriod: 2000 # should be less than or equal to HelloFrommDeadLetterQueue's MessageRetentionPeriod
        RedrivePolicy:
          deadLetterTargetArn:
            Fn::GetAtt:
              - HelloFrommDeadLetterQeueue
              - Arn
          maxReceiveCount: 5
    HelloFrommDeadLetterQeueue:
        Type: AWS::SQS::Queue
        Properties:
            QueueName: Hello-Fromm-DeadLetterQueue
            MessageRetentionPeriod: 1209600 # 14 * 24 * 60 * 60 = 14 days, available range : 60 ~ 1209600

위와 같은 serverless.yml config file을 통해 lambda, SQS Queue, DLQ 를 모두 프로비저닝 할 수 있습니다.

여기서 주의해야할 점은

• SQS Queue와 DLQ는 같은 타입이어야 합니다. 표준대기열은 DLQ도 표준대기열이어야 하고 FIFO 큐는 DLQ도 FIFO큐여야 합니다.
• DLQ의 MessageRetentionPeriod는 항상 SQS Queue의 값보다 커야합니다. SQS Queue에서 Record당 카운트되는 MessageRetentionPeriod는 DLQ에서도 초기화되지 않고 지속적으로 카운트됩니다. 즉 DLQ의 MessageRetentionPeriod 값이 SQS Queue의 MessageRetentionPeriod 값과 같거나 작으면 DLQ로 메시지가 이동되자 마자 retentionPeriod가 끝나 즉시 삭제될 수 있습니다.

마치며

지금까지 fromm서비스에 SQS와 DLQ를 도입하게된 과정과 방법을 간략히 알아보았습니다. 다음번 포스트는 SQS partial batch를 DLQ와 함께 사용하는 방법에 대해 알아보도록 하겠습니다.

여기까지 글을 관심있게 읽어주신 모든분께 감사드립니다🙇‍

당신의 예술이 세상을 바꾼다.

저희와 함께 서비스의 품질을 높이기 위해 고민하고 함께 성장해나갈 개발자를 찾습니다. 관심있으신분들은 언제든지 지원부탁드립니다😀

노머스 지원하기

참고자료

Serverless Framework Documentation

Amazon SQS Dead-Letter Queues