서버리스 애플리케이션을 테스트할 때 발생할 수 있는 문제

에뮬레이터와 모의 호출을 사용하여 로컬 데스크톱에서 서버리스 애플리케이션을 테스트하면 CI/CD 파이프라인의 환경 간에 코드가 진행되면서 테스트 불일치가 발생할 수 있습니다. 애플리케이션의 비즈니스 로직을 검증하기 위해 데스크톱에서 생성하는 단위 테스트에는 클라우드 서비스의 중요한 측면이 포함되지 않거나 정확하게 나타나지 않을 수 있습니다. 전체 테스트는 로컬에서 단독으로 수행할 수 없습니다. 이를 위해서는 여러 서비스 간의 권한과 구성을 확인해야 합니다.

다음 섹션에서는 클라우드 테스트 전략을 구현할 때 발생할 수 있는 문제를 간략하게 설명합니다.

예제: S3 버킷을 생성하는 Lambda 함수

Lambda 함수의 로직이 S3 버킷 생성에 의존하는 경우 전체 테스트를 통해 Amazon S3가 직접적으로 호출되고 버킷이 성공적으로 생성되었는지 확인해야 합니다. 모의 테스트 설정에서는 성공 응답을 모의하고 잠재적으로 실패 응답을 처리하기 위한 테스트 사례를 추가할 수 있습니다. 에뮬레이션 테스트 시나리오에서는 CreateBucket API가 호출될 수 있지만 호출을 수행하는 ID는 역할을 가정한 Lambda 서비스에서 발생하지 않으며 대신 자리 표시자 인증이 사용됩니다. 이는 종종 보다 허용적인 역할 또는 사용자 ID입니다.

이전에 설명한 모의 및 에뮬레이션 설정은 Lambda 함수가 Amazon S3 호출에 성공하거나 실패할 경우 수행할 작업을 테스트할 가능성이 높습니다. 그러나 이러한 테스트에서는 함수 구성에 따라 Lambda 함수가 버킷을 성공적으로 생성할 수 있는지 여부를 캡처하지 못합니다. 이 구성은 AWS CloudFormation AWS SAM또는 HashiCorp Terraform과 같은 제품 및 서비스의 코드형 인프라(IaC)로 표시될 수 있습니다. HashiCorp 한 가지 가능한 문제는 기능에 할당된 역할에 s3:CreateBucket 작업을 허용하는 정책이 연결되어 있지 않기 때문에 클라우드 환경에 배포할 때 해당 기능이 항상 실패한다는 것입니다.

예제: Amazon SQS 대기열의 메시지를 처리하는 Lambda 함수

Amazon SQS 대기열이 Lambda 함수의 소스인 경우 전체 테스트를 통해 메시지가 대기열에 추가될 때 Lambda 함수가 성공적으로 간접 호출되었는지 확인해야 합니다. 에뮬레이션 테스트와 모의 테스트는 일반적으로 Lambda 함수 코드를 직접 실행하고 JSON 이벤트 페이로드 또는 역직렬화된 객체를 함수 핸들러의 입력으로 전달하여 Amazon SQS 통합을 시뮬레이션하도록 설정됩니다.

Amazon SQS 통합을 시뮬레이션하는 로컬 테스트에서는 Amazon SQS가 지정된 페이로드와 함께 직접적으로 호출 시 Lambda 함수가 어떤 작업을 수행하는지 테스트하지만, Lambda 함수가 클라우드 환경에 배포될 때 Amazon SQS가 해당 함수를 간접적으로 호출하는지는 확인되지 않습니다.

다음은 Amazon SQS 및 Lambda에서 발생할 수 있는 구성 문제의 몇 가지 예입니다.

• Amazon SQS 가시성 제한 시간이 너무 짧아 한 번만 의도했는데 여러 번 호출됩니다.

• Lambda 함수의 실행 역할은 대기열에서 메시지 읽기를 허용하지 않습니다(sqs:ReceiveMessage, sqs:DeleteMessage 또는 sqs:GetQueueAttributes를 통해).

• Lambda 함수에 전달된 샘플 이벤트가 Amazon SQS 메시지 크기 할당량을 초과합니다. 따라서 Amazon SQS에서는 해당 크기의 메시지를 전송할 수 없으므로 테스트가 유효하지 않습니다.

이러한 예에서 볼 수 있듯이 비즈니스 로직은 다루지만 클라우드 서비스 간의 구성은 다루지 않는 테스트는 신뢰할 수 없는 결과를 제공할 수 있습니다.