fromm의 SQS와 DLQ - 2. Throughput을 효과적으로 늘리기 위한 Partial Batch 사용

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

들어가며

지난 fromm의 SQS와 DLQ - 1. DeadLetterQueue를 도입하기까지 에서 fromm 이 SQS 를 선택한 이유와 DeadLetterQueue를 사용해 안정성을 높일 수 있는 방법을 알아보았습니다. 해당 항목이 궁금하신 분들이라면 지난글을 참고하면 좋을 것 같습니다.

EventDriven Architecture를 선택하고 SQS를 사용해 시스템 결합도를 낮추고 유연성을 높였다면 이후 관심사는 이런 환경에서 어떻게 데이터를 잘 처리하는가 였습니다. 이번 글에서는 SQS의 throughput을 어떻게 증가시킬 수 있는지에 대해 알아보겠습니다.

SQS의 throughput 증가시키기

SQS는 기본적으로 매우 높은 메시지 처리량을 가지고 있다고 AWS는 말합니다. 표준 대기열의 경우 API 호출수는 거의 무제한 이라고 표현하고 있으며 표준 대기열보다 처리량이 좀더 낮은 FIFO 대기열의 경우에도 리전별 차이는 있지만 한국 리전은 최대 초당 90000개의 메시지를 처리할 수 있다고 합니다. 하지만 이때 최대 호출을 위해서 배치 처리 API를 사용해야 합니다.

SQS throughput을 최대로 사용하기 위한 방법은 크게 다음 두가지가 있습니다.

• Horizontal Scaling
• Action Batching

Horizontal Scaling

Horizontal Scaling의 경우 SQS의 메시지를 처리하는 클라이언트의 갯수 혹은 쓰레드 수를 늘려 메시지의 처리량을 증가시키는 방법입니다.

EC2, ECS, EKS 등으로 SQS 메시지를 처리하는 경우 인스턴스를 늘려 메시지의 처리량을 선형적으로 증가시킬 수 있습니다. 이때 Auto Scaling을 통해 클라이언트 수를 동적으로 조정하여 SQS의 메시지가 많을때는 인스턴스를 추가해 빠르게 처리하고 적을때는 인스턴스를 줄여 비용을 줄일 수도 있습니다.

하지만 fromm 서비스의 경우 SQS의 메시지 핸들러 클라이언트로 Lambda를 사용하고 있고 Lambda의 이벤트 소스가 SQS일 경우 Lambda는 분당 300개의 인스턴스까지 오토스케일링 됩니다. 이렇게 AWS 자체적으로 메시지 클라이언트의 오토스케일링을 지원해준다는 점이 SQS를 선택한 주요한 이유중 하나였고 따라서 fromm 서비스에서는 SQS Client의 horizontal scaling을 크게 신경쓰고 있지는 않습니다.

Action Batching

Action Batching은 SQS의 메시지를 한번에 여러개를 처리하여 throughput을 증가시킬 수 있는 방법입니다. 한번에 여러개의 메시지를 처리하여 네트워크 오버헤드를 줄이고 효율성을 높일 수 있고 Lambda의 Concurrency를 최적화 할 수 있습니다. 표준 대기열의 경우 한번에 최대 10000개의 메시지를 배치로 처리할 수 있습니다.

AWS Document 에 SQS Batch size의 max value가 10, 10000 으로 혼용되어 사용되고 있는데 aws-lambda-now-supports-batch-windows-of-up-to-5-minutes-for-functions 에 따르면 10에서 10000으로 증가되었음을 알 수 있습니다.

Action Batch 구성하기

action batch 처리를 위한 serverless 및 타입스크립트 코드 예시를 알아보도록 하겠습니다.

serverless YAML config

serverless.yml

service: hello-fromm

provider:
  name: aws
  runtime: nodejs20.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
          batchSize: 100
          maximumBatchingWindow: 60
          functionResponseType: ReportBatchItemFailures

.
.
.
(지난 글의 resource config와 같음)

functions의 handler 설정에 batchSize, maximumBatchingWindow, functionResponseType 을 추가해 메시지 배치처리를 할 수 있습니다.

• batchSize : 한번에 배치로 처리할 최대 메시지 수를 결정합니다.
• maximumBatchingWindow : 메시지를 폴링하는 최대 시간을 설정합니다. 단 이 시간동안 반드시 메시지를 기다린다는 보장은 없으며 설정한 batchSize 까지 메시지 갯수가 되지 않거나 batchWindow 만큼 시간이 되지 않더라도 메시지가 처리될 수 있습니다. ex. batchSize 50, maximumBatchingWindow 60으로 설정되었으나 10초만에 7개의 메시지만 배치처리, 실제로 이렇게 동작하는 경우가 훨씬 많습니다.
• functionResponseType : Response Type을 지정해 배치 처리중 실패한 메시지만을 재처리할 수 있습니다.

이때 maximumBatchingWindow, functionResponseType 는 생략될 수 있습니다.

Partial Batch Failure

메시지를 배치로 여러개를 처리하다 보면 중간중간 처리에 실패한 메시지가 포함될 수 있습니다. 만약 functionResponseType 를 설정하지 않고 그냥 배치만 사용한다면 SQS handler Lambda는 가져온 메시지들이 처리에 성공했는지 실패했는지만을 리턴합니다. 이때 중간에 처리한 메시지가 한개라도 포함되어 있다면 가져온 메시지 전체를 재시도하게 됩니다.

이미 성공한 메시지가 재처리 되더라도 전혀 상관이 없다면 코드의 간결함을 유지하기 위해 기본 설정 그대로 action batch를 사용해도 되지만 그렇지 않는 경우도 많이 발생할 수 있습니다. 예를 들어 사용자에게 Push 전송을 위해 SQS를 사용하고 이를 배치처리 하고있다면 성공한 메시지가 여러번 처리되어 사용자에게 중복된 Push가 여러번 발송될 수 있습니다. 이를 해결하기 위해 ReportBatchItemFailures 라는 handler Lambda의 Response Type을 지정해 실패한 메시지만을 재처리하는 partial batch failure를 활용할 수 있습니다.

Lambda Handler Source Code

lambda.ts

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

  const helloFrommService = app.get(HelloFrommService);
  
  const batchItemFailures: SQSBatchItemFailure[] = [];

  for (const record of event.Records) {
        try {
            await helloFrommService.executeTestData(JSON.parse(record.body));

        } catch (e) {
            batchItemFailures.push({ itemIdentifier: record.messageId });
            
            // logging, alerting, etc...
        }
    }

    return { batchItemFailures };
}

지난번 코드와 달라진 점으로는 다음과 같습니다.

• 1개가 아닌 여러개의 record를 가져오므로 각 레코드를 반복문으로 처리를 한다는 것
• 각 레코드에서 에러가 발생하면 batchItemFailures 라는 배열에 해당 레코드 message ID를 담아 실패한 레코드만을 명시적으로 반환한다는 것
• 리턴이 명시적이므로 handler 코드에서 error throw가 없어졌다는 것

위 코드를 통해 SQS의 Action Batch를 사용할 수 있을 뿐만 아니라 실패한 메시지만 안전하게 재처리할 수 있습니다.

마치며

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

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

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

노머스 지원하기

참고자료

Serverless Framework Documentation

Increasing throughput using horizontal scaling and action batching with Amazon SQS

Best practices for implementing partial batch responses