AWS Simple Queue Service(SQS)는 안정적이고 확장 가능한 메시징 솔루션을 제공하고, AWS Lambda는 서버리스 컴퓨팅 기능을 제공합니다. 이 두 서비스를 결합하면 강력한 이벤트 기반 아키텍처가 가능해집니다. 이 블로그 게시물에서는 SQS와 Lambda의 통합을 자세히 살펴보고 메시지 소비와 처리의 메커니즘을 알아보겠습니다. 개별적으로 또는 일괄적으로 메시지를 처리하는 데 사용할 수 있는 옵션을 자세히 살펴보고 각 접근 방식의 장점과 고려 사항을 강조해 보겠습니다. 또한, 배치 크기, 배치 창, 최대 동시성, 대기열 가시성 시간 초과 등 Lambda 이벤트 소스 매핑과 SQS에 대한 주요 구성에 대해서도 논의하겠습니다. 우리를온클라우드 AI이 문서를 통해 SQS와 Lambda 통합의 힘을 이해해 보세요.
SQS와 Lambda 통합 이해
SQS와 Lambda는 확장 가능한 이벤트 기반 아키텍처를 구축하기 위한 강력한 통합을 제공합니다. Lambda 이벤트 소스 매핑을 사용하면 SQS 대기열의 메시지를 비동기적으로 처리하여 구성 요소를 분리하고 안정적인 메시지 전달을 보장할 수 있습니다. Lambda 함수가 SQS 대기열을 구독하는 경우 폴링 메커니즘을 사용하여 메시지가 도착할 때까지 기다립니다. Lambda는 메시지를 일괄적으로 처리합니다. Lambda는 각 배치마다 함수를 한 번씩 트리거합니다. 대기열에 메시지가 더 많으면 Lambda는 동시 처리 기능을 최대 1,000개까지 확장하여 분당 최대 60개의 기능을 추가할 수 있습니다. 성공적으로 처리되면 Lambda는 자동으로 큐에서 메시지를 삭제합니다.
Lambda를 사용하여 SQS에서 메시지 사용
SQS를 사용하면 메시지를 개별적으로 또는 일괄적으로 처리할 수 있습니다. 람다 이벤트 소스 매핑은 더 큰 규모의 배치를 지원하며, 표준 SQS 대기열의 경우 최대 10,000개 메시지 또는 6MB의 단일 배치를 지원합니다. 이와 대조적으로 SDK는 각 API 호출을 최대 10개의 메시지로 제한합니다. 이는 SQS에서 메시지를 사용할 때 가능한 한 Lambda 이벤트 소스 매핑을 사용해야 하는 이유 중 하나입니다.
메시지를 개별적으로 처리하면 처리 속도가 빨라지고 오류 처리가 간단해진다는 장점이 있습니다. 하지만 일괄 처리가 더 적합한 상황도 있습니다. 일괄 처리는 더 높은 처리량이나 더 높은 효율성이 필요하거나 비용 최적화가 중요할 때 유용합니다.
단일 메시지 처리
Lambda에서 개별 SQS 메시지를 사용하는 것은 비교적 간단합니다. 각 메시지는 Lambda 함수의 실행을 트리거하는 독립적인 이벤트로 처리됩니다. 메시지 처리 중에 발생할 수 있는 예외나 오류를 포착하기 위해 적절한 오류 처리를 구현하는 것이 여전히 중요합니다. Lambda 함수가 메시지를 성공적으로 처리하면 Lambda는 자동으로 큐에서 해당 메시지를 삭제합니다. 그러나 함수 실행 중에 오류가 발견되면 메시지는 추가 처리 또는 재시도를 위해 대기열로 반환됩니다. 이를 통해 오류가 발생해도 메시지가 손실되지 않고, 실패한 메시지를 적절하게 처리하고 다시 처리할 수 있습니다.
일괄 메시지 처리
Lambda가 SQS 대기열에서 일괄 메시지를 처리할 때 메시지는 대기열에 남아 있지만 대기열의 표시 시간 초과에 따라 일시적으로 숨겨집니다(이 블로그 게시물의 뒷부분에서 자세히 설명). Lambda 함수가 메시지 배치를 성공적으로 처리하면 Lambda는 자동으로 큐에서 메시지를 삭제합니다. 그러나 일괄 처리된 메시지를 처리하는 동안 함수에서 오류가 발생하면 해당 일괄 처리에 포함된 모든 메시지가 대기열에 다시 나타나 다시 표시됩니다.
메시지가 두 번 이상 처리되지 않도록 하려면 몇 가지 옵션이 있습니다. 첫째, 이벤트 소스 매핑을 구성하여 다음을 포함할 수 있습니다.일괄 항목 실패 보고함수 응답에서. 이를 통해 함수 코드에서 실패한 메시지를 처리하고 추적할 수 있으며, 배치를 처리할 때 권장되는 접근 방식입니다. 또는 Lambda 함수가 메시지를 성공적으로 처리하면 DeleteMessage라는 Amazon SQS API 작업을 사용하여 대기열에서 메시지를 명시적으로 삭제할 수 있습니다. 이 API 작업을 사용하면 메시지가 실수로 다시 처리되지 않도록 할 수 있습니다.
ReportBatchItemFailures 기능을 사용하여 부분적으로 실패한 메시지를 반환하는 방법에 대한 두 가지 예를 제공하겠습니다. 이를 통해 함수가 메시지를 두 번 이상 처리하지 않도록 할 수 있습니다. batchItemFailures 함수 응답을 작성하고 Middy 미들웨어를 사용하여 이를 수행하는 방법을 보여드리겠습니다.
주목할만한 구성
람다 이벤트 소스 매핑
배치 크기
배치 크기( 배치 크기) 구성은 각 배치에서 Lambda 함수로 전송되는 레코드 수를 결정합니다. 표준 대기열의 경우 배치 크기를 최대 10,000개 레코드로 설정할 수 있습니다. 하지만 구성된 레코드 수에 관계없이 총 배치 크기는 6MB를 초과할 수 없다는 점에 유의해야 합니다.
일괄 처리 창
배치 창( 최대 배칭 창(초)) 설정은 Lambda 함수를 호출하기 전에 레코드를 수집하는 최대 시간(초)을 결정합니다. 이 구성은 표준 대기열에만 적용됩니다.
최대 동시 연결 수
최대 동시성( 스케일링 구성) 기능을 사용하면 이벤트 소스 매핑에 대한 최대 동시 호출 수를 설정할 수 있으므로 Lambda에서 보존된 동시성을 사용할 때 과도한 제한으로 인해 발생하는 문제를 제거할 수 있습니다. 이 기능을 사용하면 특히 동일한 기능을 가진 여러 이벤트 소스 매핑을 사용할 때 동시성을 더 잘 제어할 수 있습니다.
SQS 구성
대기열 가시성 시간 초과
SQS의 가시성 시간 초과( 가시성 시간 초과)은 소비자가 메시지를 검색한 후 대기열에서 메시지가 보이지 않는 시간을 결정하는 설정입니다. 소비자가 대기열에서 메시지를 수신하면 해당 메시지는 가시성 시간 초과 기간 동안 다른 소비자에게 일시적으로 숨겨집니다. 0초보다 큰 일괄 처리 창을 선택하는 경우 대기열의 가시성 시간 제한 내에서 증가된 처리 시간을 고려해야 합니다. 가시성 시간 초과는 함수 시간 초과와 배치 창의 최소 6배로 설정하는 것이 좋습니다. 최대 배칭 창(초)) 값. 이를 통해 Lambda 함수가 각 이벤트 배치를 처리하고 제한 오류로 인해 발생할 수 있는 잠재적인 재시도를 처리할 수 있는 충분한 시간을 확보할 수 있습니다. 예를 들어, 함수 시간 초과가 30초이고 일괄 처리 창이 20초인 경우입니다. 이렇게 하면 (30 x 6) + 20 = 200초가 됩니다.
데드 레터 큐(DLQ)
Lambda가 메시지를 처리할 수 없는 경우 해당 메시지는 재시도를 위해 대기열로 반환됩니다. 그러나 메시지가 대기열에 여러 번 추가되어 불필요한 Lambda 리소스 소비가 발생하는 것을 방지하려면 배달 못한 편지 대기열(DLQ)을 지정하고 실패한 메시지를 해당 대기열로 보내는 것이 좋습니다. 실패한 메시지에 대한 재시도 횟수를 제어하려면 다음을 설정할 수 있습니다.최대 수신DLQ의 가치. 메시지가 수신 최대 수를 초과하여 다시 대기열에 추가되면 해당 메시지는 DLQ로 이동됩니다. 이렇게 하면 메인 큐에서 처리하지 않고도 나중에 실패한 메시지를 처리할 수 있습니다.
결론적으로
요약하자면, SQS와 Lambda의 통합은 이벤트 기반 아키텍처를 구축하기 위한 강력하고 확장 가능한 솔루션을 제공합니다. 이벤트 소스 매핑을 활용하고, 일괄 처리를 구성하고, 배달 못 한 편지 대기열 및 가시성 시간 초과와 같은 주목할 만한 기능을 활용하면 안정적인 메시지 처리를 보장하고 리소스 활용도를 최적화할 수 있습니다. 이러한 통합을 활용하면 분산 시스템의 잠재력을 최대한 실현하고 쉽게 확장 가능한 복원력 있는 애플리케이션을 만들 수 있습니다.
온클라우드 AIAWS 에이전트로서 우리는 Amazon 클라우드 서비스를 제공하고, Amazon 클라우드 서버에 대한 AWS 결제를 지원하고, AWS 마이그레이션, AWS 운영 및 유지 관리 호스팅과 기타 서비스를 제공합니다. 관련된 사항이 있으시면 저희에게 연락해 주시기 바랍니다.온클라우드 AI.
