기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

서버리스 애플리케이션 테스트에 대한 모범 사례

다음 섹션에서는 서버리스 애플리케이션을 테스트할 때 효과적인 적용 범위를 확보하기 위한 모범 사례를 간략하게 설명합니다.

클라우드에서 테스트 우선순위 지정

잘 설계된 애플리케이션의 경우 다양한 테스트 기법을 사용하여 다양한 요구 사항 및 조건을 충족할 수 있습니다. 하지만 현재 도구를 기반으로 볼 때 가급적 클라우드에서의 테스트에 집중하는 것이 좋습니다. 클라우드에서 테스트하면 개발자 지연이 발생하고 비용이 증가하며 때로는 추가 DevOps 제어에 대한 투자가 필요할 수 있지만 이 기법은 가장 안정적이고 정확하며 완전한 테스트 범위를 제공합니다.

테스트를 수행할 격리된 환경에 액세스할 수 있어야 합니다. 동일한 코드에서 작업하는 여러 개발자가 동일한 이름을 가진 리소스에 API 호출을 배포하거나 호출하려고 할 때 발생할 수 있는 리소스 이름 지정 문제를 방지하기 AWS 계정 위해 각 개발자에게 전용가 있어야 합니다. 불필요한 지출 방지를 위해 적절한 알림 및 제어 기능을 갖춘 이러한 환경을 구성해야 합니다. 예를 들어, 생성할 수 있는 리소스의 유형, 계층 또는 크기를 제한하고 예상 비용이 지정된 임계값을 초과할 때 이메일 알림을 설정할 수 있습니다.

단일를 다른 개발자 AWS 계정 와 공유해야 하는 경우 자동화된 테스트 프로세스는 각 개발자마다 고유한 리소스의 이름을 지정해야 합니다. 예를 들어 AWS SAM CLI sam deploy 또는 sam sync 명령을 유발하는 업데이트 스크립트 또는 TOML 구성 파일은 로컬 개발자의 사용자 이름을 포함하는 스택 이름을 자동으로 지정할 수 있습니다.

클라우드에서 테스트는 단위 테스트, 통합 테스트, 엔드 투 엔드 테스트 등의 모든 테스트 단계에서 중요합니다.

필요한 경우 모의 객체를 사용합니다.

모의 프레임워크는 빠른 단위 테스트를 작성하는 데 유용한 도구입니다. 이는 테스트에서 수학 또는 재무 계산이나 시뮬레이션과 같은 복잡한 내부 비즈니스 로직을 다뤄야 할 경우 특히 유용합니다. 테스트 사례 또는 입력 변형이 많고 입력이 다른 클라우드 서비스에 대한 호출 패턴이나 내용을 변경하지 않는 단위 테스트를 찾아보세요. 이러한 시나리오에 대한 모의 테스트를 만들면 개발자의 반복 시간을 개선할 수 있습니다.

모의 테스트를 사용하는 단위 테스트에서 다루는 코드는 클라우드에서의 테스트에서도 다루어야 합니다. 이는 모의 객체가 여전히 개발자의 랩톱 또는 빌드 머신에서 실행 중이며 환경이 클라우드에 있을 때와 다르게 구성될 수 있기 때문에 필요합니다. 예를 들어 코드에는 특정 입력 파라미터로 실행할 때 Lambda가 할당하도록 구성된 것보다 더 많은 메모리를 사용하거나 더 많은 시간이 걸리는 AWS Lambda 함수가 포함될 수 있습니다. 또는 코드에 동일한 방식으로 구성되지 않은 환경 변수(또는 전혀 구성되지 않은 환경 변수)가 포함될 수 있으며, 이로 인해 코드가 다르게 동작하거나 실패할 수 있습니다.

클라우드 서비스를 모의하여 해당 서비스 통합의 적절한 구현을 검증하지 마십시오. 다른 기능을 테스트할 때 클라우드 서비스를 모의하는 것이 허용될 수 있지만 클라우드에서 클라우드 서비스 호출을 테스트하여 올바른 구성 및 기능 구현을 검증해야 합니다.

모의 테스트는 특히 많은 수의 사례를 자주 테스트할 때 단위 테스트에 가치를 더할 수 있습니다. 연결 지점 수에 따라 필요한 모의 객체를 구현하는 노력 정도가 높아지기 때문에 통합 테스트에서는 이러한 이점이 감소합니다. 엔드 투 엔드 테스트에서는 대개 모의 프레임워크로는 쉽게 시뮬레이션할 수 없는 상태와 복잡한 로직을 다루기 때문에 모의 객체를 사용하면 안 됩니다.

에뮬레이션 테스트의 장단점 이해

에뮬레이터는 특정 사용 사례에 적합한 실용적인 선택일 수 있습니다. 예를 들어 인터넷 액세스가 제한적이거나 일관되지 않거나 느린 개발 팀은 에뮬레이션 테스트가 클라우드 환경으로 이동하기 전에 코드를 반복하는 가장 신뢰할 수 있는 방법임을 알게 될 수 있습니다.

대부분의 다른 상황에서는 에뮬레이터를 선택적으로 사용합니다. 에뮬레이터에 크게 의존하는 경우 에뮬레이션 공급업체가 기능 패리티를 제공하기 위한 업데이트를 릴리스할 때까지 새 AWS 서비스 기능을 테스트에 통합하는 것이 어려울 수 있습니다. 또한 에뮬레이터는 개발 시스템 및 빌드 시스템 전반의 설정 및 구성을 위해 선결제 및 지속적인 투자가 필요합니다. 또한 많은 클라우드 서비스에는 에뮬레이터를 사용할 수 없습니다. 에뮬레이션 우선 전략을 선택하면 해당 서비스를 사용하지 못하거나 실제 서비스 동작에 대해 잘 테스트되지 않은 코드 및 구성을 생성할 수 있습니다.

에뮬레이션 테스트를 사용하는 경우 클라우드 테스트로 최대한 보완하여 적절한 클라우드 구성이 있는지 확인하고 에뮬레이션 환경에서만 시뮬레이션하거나 모의할 수 있는 서비스와의 상호 작용을 테스트합니다.

에뮬레이션 테스트는 단위 테스트에 대한 빠른 피드백을 제공할 수 있으며 에뮬레이션 소프트웨어의 기능 및 동작 패리티에 따라 일부 통합 및 end-to-end 테스트도 지원할 수 있습니다.

자연 경계를 통한 범위 테스트

서버리스 애플리케이션이 더 많은 아키텍처 구성 요소에서 확장됨에 따라 특히 단일 목적 함수 및 이벤트 기반 분리와 같은 모범 사례를 따를 때 하위 시스템을 중심으로 자연 경계가 나타납니다. 이러한 경계는 구성 요소 간의 계약을 검증할 수 있는 효과적인 테스트 엣지 역할을 합니다.

아키텍처 경계 식별

애플리케이션 설계에서 자연스러운 심을 찾습니다.

Lambda 코드를 비즈니스 로직과 분리

핵심 비즈니스 로직에서 Lambda 코드를 격리하여 테스트를 간소화합니다. Lambda 핸들러는 AWS 런타임과 애플리케이션 로직 간의 씬 어댑터 역할을 해야 합니다. 이벤트 데이터를 추출하고 검증한 다음 Lambda 종속성이 없는 테스트 가능한 함수에 위임해야 합니다. 이를 통해 Lambda 객체를 모의하거나 복잡한 환경을 설정하지 않고도 비즈니스 로직을 이식하고 추론하기 쉬우며 간단하게 테스트할 수 있습니다.

경계를 계약으로 취급

경계를 통하지 않고 경계에서 테스트합니다. 전체 다운스트림 시스템을 요구하지 않고 엣지를 통과하는 항목을 검증합니다. 이러한 동일한 경계는 프로덕션에서 관찰성 후크 역할을 합니다. 테스트하는 아키텍처 심은 Amazon CloudWatch Logs, AWS X-Ray 추적 및 EventBridge 이벤트를 사용하여 모니터링을 위해 계측할 수 있습니다.

비동기 워크플로에 테스트 하네스 사용

서버리스 애플리케이션은 이벤트가 처리를 트리거하고, 메시지가 대기열을 통해 흐르며, 워크플로가 즉각적인 응답 없이 여러 서비스에 걸쳐 있는 비동기식 패턴에 의존하는 경우가 많습니다. 단순히 함수를 호출하고 반환 값을 검사할 수는 없습니다. 결과는 나중에 데이터베이스, 로그 스트림 또는 다른 서비스에 나타날 수 있습니다.

테스트 하네스는 애플리케이션과 함께 배포하는 인프라를 테스트하여이 비동기 동작을 관찰하고 검증합니다. 테스트 하네스에는 일반적으로 다음이 포함됩니다.

테스트 코드는 이벤트를 시작하고 워크플로가 완료될 때까지 기다린 다음 테스트 하네스를 쿼리하여 예상 결과가 발생했는지 확인합니다.

모범 사례는 다음과 같습니다.

테스트 하네스는 여러 서비스에서 워크플로를 검증하는 통합 테스트, 전체 사용자 여정을 확인하는 end-to-end 테스트, 서비스가 EventBridge, Amazon SNS, Amazon SQS 또는 Amazon Kinesis를 통해 통신하는 이벤트 기반 아키텍처에 가장 유용합니다.

개발자 격리를 위한 클라우드 환경 구성

클라우드에서 테스트하려면 서로 격리된 환경이 필요합니다. 개발자가 팀 개발 계정 AWS 계정과 같은 단일를 공유하는 경우 각 개발자 또는 기능 브랜치에 대해 별도의 애플리케이션 스택을 생성하는 것이 좋습니다. 이렇게 하면 리소스를 격리하고, 이름 충돌을 방지하며, 테스트 중에 할당량 경합이나 노이즈가 많은 이웃 문제를 방지할 수 있습니다.

AWS Systems Manager Parameter Store 또는 유사한 도구를 사용하여 API 엔드포인트 및 대기열 이름과 같은 스택별 구성을 관리합니다. 비용 효율성을 위해 Amazon Relational Database Service(RDS) 클러스터와 같은 비용이 많이 드는 리소스를 개발자 스택 간에 공유하는 동시에 스택당 격리된 경량 서버리스 리소스(예: Lambda 함수, API Gateway 단계 및 DynamoDB 테이블)를 유지합니다.

규제 산업에서 엔터프라이즈 보안 정책은 클라우드 환경에 대한 개발자 액세스를 제한하여 로컬 개발 워크플로의 일부로 클라우드 테스트를 실행하기 어려울 수 있습니다. 이러한 경우 에뮬레이션 테스트는 로컬 모의 테스트와 전체 클라우드 검증 간의 격차를 해소할 수 있지만 액세스가 허용될 때마다 클라우드 테스트로 보완해야 합니다.

피드백 루프 가속화

클라우드에서 테스트할 때 도구와 기법을 사용하여 개발 피드백 루프를 가속화하세요. 예를 들어 AWS SAM 가속 및 AWS CDK 감시 모드를 사용하여 코드 수정을 클라우드 환경으로 푸시하는 데 걸리는 시간을 줄입니다. GitHub Serverless Test Samples 리포지토리의 샘플에서 이러한 기법 중 일부를 살펴봅니다.

또한 소스 제어에 체크인한 후뿐만 아니라 개발 중에 로컬 시스템에서 클라우드 리소스를 최대한 빨리 생성하고 테스트하는 것이 좋습니다. 이를 통해 솔루션을 개발할 때 더 빠르게 탐색하고 실험할 수 있습니다. 또한 개발 머신에서 배포를 자동화하는 기능을 통해 클라우드 구성 문제를 보다 신속하게 발견하고 소스 제어에 대한 수정 사항을 업데이트하고 승인하는 데 낭비되는 노력을 줄일 수 있습니다.