예약 된 이벤트가 아닌 람다 함수로 SQS 대기열을 처리하는 방법은 무엇입니까?

예약 된 이벤트가 아닌 람다 함수로 SQS 대기열을 처리하는 방법은 무엇입니까?

---

다음은 내가 작업하려는 단순화 된 계획입니다.

http 요청-> (Gateway API + lambda A)-> SQS-> (lambda B ?????)-> DynamoDB

따라서 다음과 같이 작동해야합니다. 많은 http 요청 (예 : 초당 최대 500 개)에서 오는 데이터는 람다 함수 A에 의해 SQS 대기열에 배치됩니다. 그런 다음 다른 함수 B가 대기열을 처리합니다. 최대 10 개의 항목을 읽습니다. (일부 주기적으로) BatchWriteItem을 사용하여 DynamoDB에 기록합니다.

문제는 두 번째 람다 함수를 트리거하는 방법을 알 수 없다는 것입니다. DynamoDB ASAP에 최대한 빨리 들어가려면 대기열의 모든 데이터가 필요하기 때문에 초당 여러 번 (또는 적어도 초당 한 번) 자주 호출해야합니다 ( 여기 에 설명 된대로 예약 된 이벤트를 통해 람다 함수 B를 호출 하는 것은 옵션이 아닙니다. )

---

SQS없이 DynamoDB에 직접 쓰지 않는 이유는 무엇입니까?

SQS를 전혀 사용하지 않는 것이 좋습니다. SQS로 해결하려는 문제는 DynamoDB 스로틀 링입니다. 자체 조절이 아니라 AWS SDK를 사용하여 DynamoDB에 데이터를 쓰는 동안 처리되는 방식 : 레코드를 하나씩 작성하고 조절하면 AWS SDK는 자동으로 쓰기를 재 시도하므로 http 클라이언트의 요청 처리 시간이 증가합니다. 전망.

따라서 일시적으로 데이터를 대기열에 저장하고 "200 OK"응답을 클라이언트에 보낸 다음 별도의 함수로 대기열을 처리하여 DynamoDB의 BatchWriteItem 호출 (경우에 따라 자동 재시도 대신 처리되지 않은 항목을 반환)으로 여러 레코드를 작성하고 싶습니다. 제한). 레코드를 수신하고 DynamoDB에 저장하는 사이의 지연을 늘리는 대신 일부 레코드를 잃는 것을 선호합니다.

UPD : 관심이있는 사람이 있다면 조절의 경우 aws-sdk가 자동 재 시도를 건너 뛰도록하는 방법을 찾았습니다 . 특별 파라미터 maxRetries가 있습니다. 어쨌든 아래 제안 된대로 Kinesis를 사용하겠습니다.

---

[이것은 귀하의 명시적인 질문에 직접 답변하지 않으므로 내 경험상 비추천 할 것입니다. :) 그러나 해결하려는 근본적인 문제에 대해서는 대답하겠습니다.]

들어오는 요청의 홍수를 가져 와서 DynamoDB에 페이스 방식으로 작성하기 위해 AWS Lambda 함수에 공급하는 방법은 제안 된 아키텍처의 SQS를 Amazon Kinesis 스트림으로 교체하는 것입니다.

Kinesis 스트림은 AWS Lambda 함수를 구동 할 수 있습니다.

Kinesis 스트림은 지정된 키에 대해 전달 된 메시지의 순서를 보장합니다 (순서있는 데이터베이스 작업에 적합).

Kinesis 스트림을 사용하면 DynamoDB 쓰기 용량에 맞게 조정할 수있는 병렬로 실행할 수있는 AWS Lambda 함수 수를 지정할 수 있습니다 (파티션 당 하나씩).

Kinesis 스트림은 하나의 AWS Lambda 함수 호출에서 사용 가능한 여러 메시지를 전달할 수 있으므로 추가 최적화가 가능합니다.

참고 : Amazon Kinesis 스트림에서 읽은 다음 함수를 호출하는 것은 실제로 AWS Lambda 서비스이며, AWS Lambda를 직접 호출하는 Kinesis 스트림이 아닙니다. 그러나 때로는 Kinesis가이를 구동 할 때 시각화하는 것이 더 쉽습니다. 사용자의 결과는 거의 동일합니다.

---

불행히도 SQS와 Lambda를 직접 통합 할 수는 없습니다. 그러나 아직 너무 걱정하지 마십시오. 해결책이 있습니다! 또 다른 아마존 서비스를 믹스에 추가해야 모든 문제가 해결됩니다.

http requests --> (Gateway API + lambda A) --> SQS + SNS --> lambda B --> DynamoDB

두 번째 람다 서비스에 대한 SNS 알림을 트리거하여 시작할 수 있습니다. 시작되면 대기열을 비우고 모든 결과를 DynamoDB에 쓸 수 있습니다. Lambda에 대해 가능한 이벤트 소스를 더 잘 이해하려면 이 문서를 확인하십시오 .

---

2018 년 6 월 28 일부터 이제 SQS를 사용하여 AWS Lambda 함수를 기본적으로 트리거 할 수 있습니다. 더 이상 해결 방법이 필요하지 않습니다!

https://aws.amazon.com/blogs/aws/aws-lambda-adds-amazon-simple-queue-service-to-supported-event-sources/

---

또 다른 해결책은 SQS에 항목을 추가하고 이벤트를 사용하여 대상 Lambda 함수를 호출하여 비동기식으로 만드는 것입니다.

그러면 비동기식 Lambda가 SQS에서 원하는만큼 항목을 가져 와서 처리 할 수 ​​있습니다.

또한 비동기 Lambda에 예약 된 호출을 추가하여 오류가 발생한 대기열의 모든 항목을 처리합니다.

[업데이트] 이제 대기열의 새 메시지에 Lambda 트리거를 설정할 수 있습니다.

---

비용 효율적인 솔루션은 모든 것을 SQS에있는 그대로 유지 한 다음 대기열에서 항목을 처리하는 다중 스레드 Lambda 함수를 호출하는 예약 된 이벤트를 실행하는 것입니다.

이렇게하면 대기열 작업자가 제한과 정확히 일치 할 수 있습니다. 큐가 비어 있으면 함수가 조기에 완료되거나 단일 스레드에서 폴링을 시작할 수 있습니다.

예를 들어 Kinesis는 원래 주문이 필요하지 않습니다. 또한 여러 Lambda를 동시에 실행하는 것은 하나의 다중 스레드 Lambda를 실행하는 것보다 확실히 더 비쌉니다.

Lambda는 I / O에 관한 것이므로 AWS 서비스에 대한 외부 호출을 수행하므로 하나의 함수가 매우 적합 할 수 있습니다.

---

SQS 대기열에서 메시지를 수집하는 방법은 다음과 같습니다.

package au.com.redbarn.aws.lambda2lambda_via_sqs;

import java.util.List;

import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.SQSEvent;
import com.amazonaws.services.lambda.runtime.events.SQSEvent.SQSMessage;

import lombok.extern.log4j.Log4j2;

@Log4j2
public class SQSConsumerLambda implements RequestHandler<SQSEvent, String> {

    @Override
    public String handleRequest(SQSEvent input, Context context) {

        log.info("message received");

        List<SQSMessage> records = input.getRecords();

        for (SQSMessage record : records) {
            log.info(record.getBody());
        }

        return "Ok";
    }
}

DynamoDB 코드를에 추가하면 handleRequest()Lambda B가 완료됩니다.

---

이 문제에 대한 내 해결책은 다음과 같습니다.

HTTP request --> DynamoDb --> Stream --> Lambda Function

이 솔루션에서는 테이블에 대한 스트림을 설정해야합니다. 스트림은 작성하게 될 Lambda 함수로 처리됩니다. SQS 또는 다른 것을 사용할 필요가 없습니다.

물론 이것은 단순한 디자인이며 단순한 문제에만 작동합니다. 더 복잡한 시나리오의 경우 Kinesis를 사용하십시오 (다른 답변에서 언급 됨).

다음 은 주제에 대한 AWS 설명서 링크 입니다.

---

이제 AWS가 SQS가 람다 함수를 트리거 할 수있는 방법을 찾았다 고 생각합니다. 따라서 메시지 순서에 신경 쓰지 않는 경우 SQS를 사용하여 데이터의 버스트로드를 다이나모로 매끄럽게 할 수 있다고 생각합니다. 이 새로운 업데이트에 대한 블로그를 확인하십시오. https://aws.amazon.com/blogs/aws/aws-lambda-adds-amazon-simple-queue-service-to-supported-event-sources/

참고 URL : https://stackoverflow.com/questions/34678691/how-to-process-sqs-queue-with-lambda-function-not-via-scheduled-events