새 이미지가 업로드될 때 S3에 의해 트리거되는 Node.js AWS Lambda 함수로 비디오 처리 애플리케이션이 실행됩니다. 이 함수는 한 S3 버킷에서 이미지를 다운로드하고, 변환한 다음, 변환된 이미지를 두 번째 S3 버킷에 쓰고, DynamoDB의 메타데이터를 업데이트합니다. 이미지 크기가 증가함에 따라 Lambda 함수가 자주 타임아웃됩니다. 함수 타임아웃은 이미 최댓값으로 설정되어 있습니다. 회사는 서버를 관리하고 싶지 않습니다. 솔루션스 아키텍트는 호출 실패를 방지하기 위해 어떤 변경 조합을 구현해야 할까요? (두 가지 선택)

Lambda 함수가 타임아웃되는 문제는 처리 시간이 길거나 메모리 요구 사항이 높은 작업에 적합하지 않기 때문입니다. Docker 컨테이너로 애플리케이션을 패키징하고 Amazon ECR에 게시하는 것은 장기 실행 작업을 위한 유연한 배포 방법을 제공합니다. 그 다음, Amazon ECR의 이미지를 참조하는 AWS Fargate 호환성을 가진 Amazon ECS 태스크 정의를 생성하고, 새 파일이 S3에 도착할 때 Lambda 함수가 ECS Fargate 태스크를 시작하도록 수정하면, 서버리스 방식으로 장기 실행 및 리소스 집약적인 비디오 처리 작업을 효율적으로 처리할 수 있습니다. 이는 Lambda의 제한을 우회하면서 서버 관리에 대한 회사의 요구 사항을 충족합니다. "Parallel 상태를 사용하여 Lambda 함수를 병렬로 실행하는 AWS Step Functions 상태 머신을 생성하고 Lambda 함수의 프로비저닝된 동시성을 늘리는 것"은 동시성 문제를 해결할 수 있지만, 개별 함수의 타임아웃 문제를 해결하지 못하며, 여전히 Lambda의 실행 시간 제한에 묶여 있습니다. "Amazon ECR의 이미지를 참조하는 Amazon EC2 호환성을 가진 Amazon ECS 태스크 정의를 생성하고 새 파일이 S3에 도착하면 해당 태스크 정의를 사용하여 ECS EC2 태스크를 시작하도록 Lambda 함수를 수정하는 것"은 서버 관리의 부담을 지게 되므로 회사의 요구 사항에 부합하지 않습니다. "애플리케이션이 이미지를 Amazon EFS에 저장하고 메타데이터를 Amazon RDS DB 인스턴스에 저장하도록 변경하고 Lambda 함수가 EFS 파일 시스템을 마운트하도록 수정하는 것"은 저장소 및 데이터베이스 변경일 뿐, Lambda 함수의 타임아웃 문제를 직접적으로 해결하지 못합니다.