View a markdown version of this page

서버리스 애플리케이션 테스트 기법 - AWS 권장 가이드
모의 테스트에뮬레이션 테스트클라우드에서 테스트

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

서버리스 애플리케이션 테스트 기법

서버리스 애플리케이션 코드에 대한 테스트 실행에는 모의 테스트, 에뮬레이션 테스트, 클라우드에서의 테스트라는 세 가지 주요 접근 방식이 있습니다. 일반적으로 단일 프로젝트 범위 내에서 이러한 접근 방식을 혼합하여 사용할 수 있습니다. 예를 들어 코드를 로컬에서 개발할 때 모의 테스트를 사용하고, 배포 전에 서비스 동작을 더 가깝게 복제하기 위한 에뮬레이션 테스트를 사용하고, 야간 지속적 통합 및 지속적 전달(CI/CD) 프로세스의 일환으로 클라우드 테스트를 사용할 수 있습니다.

모의 테스트

모의 객체는 코드에 클라우드 서비스의 동작을 시뮬레이션하는 대체 객체를 생성하는 전략입니다. 예를 들어 Amazon S3 서비스의 모의 객체를 사용하는 테스트를 작성하고 PutObject 메서드가 호출될 때마다 특정 응답 객체를 반환하도록 해당 모의 객체를 구성할 수 있습니다. 테스트가 실행되면 모의 객체는 Amazon S3나 다른 서비스 엔드포인트를 직접적으로 호출하지 않고 응답을 반환합니다.

이러한 대체 객체는 지정된 테스트에 필요한 구현량을 줄이기 위해 모의 프레임워크에 의해 생성되는 경우가 많습니다. 일부 모의 프레임워크는 일반 프레임워크이고 다른 모의 프레임워크는 AWS SDKs용으로 특별히 설계되었습니다.

모의는 스터브와 함께 더 넓은 범주의 가짜에 속합니다. 모의 객체는 일반적으로 개발자가 테스트 코드의 일부로 생성하거나 구성한다는 점에서 에뮬레이터(이 섹션의 뒷부분에서 설명)와 다른 반면 에뮬레이터는 에뮬레이션하는 시스템과 동일한 방식으로 API(예: REST API)를 노출하는 독립 실행형 애플리케이션입니다.

모의 객체를 사용하면 다음과 같은 이점이 있습니다.

  • 모의 객체는 해당 서비스에 직접 액세스할 필요 없이 API 및 서비스형 소프트웨어(SaaS) 제공업체와 같이 애플리케이션의 제어 범위를 벗어나는 타사 서비스를 시뮬레이션할 수 있습니다.

  • 또한 모의 객체는 특히 서비스 중단과 같이 장애 조건을 시뮬레이션하기 어려운 경우 장애 조건을 테스트하는 데 유용합니다.

  • 에뮬레이터와 마찬가지로 모의 프레임워크는 구성 후 빠른 로컬 개발을 제공할 수 있습니다.

  • 모의 객체는 거의 모든 종류의 객체에 대한 대체 동작을 제공할 수 있으므로 모의 전략은 에뮬레이터보다 더 다양한 서비스에 대한 적용 범위를 생성할 수 있습니다.

  • 새로운 기능 또는 동작을 사용할 수 있게 되면 모의 테스트는 업데이트된 AWS SDK를 사용할 수 있게 되는 즉시 새로운 기능을 시뮬레이션할 수 있는 일반 모의 프레임워크를 사용(또는 다시 사용)하여 더 빠르게 대응할 수 있습니다.

모의 테스트에는 다음과 같은 단점이 있습니다.

  • 모의 객체에는 일반적으로 상당한 양의 설정 및 구성 작업이 필요하며, 특히 응답을 제대로 모의하기 위해 다양한 서비스의 반환 값을 결정하려고 할 때 그렇습니다.

  • 모의 객체는 테스트를 작성하는 개발자가 작성하거나 구성하므로 이는 개발자의 책임입니다.

  • 서비스의 API 및 반환 값을 이해하려면 클라우드에 액세스해야 할 수 있습니다.

  • 모의 클라우드 API 서명이 변경되거나, 반환 값 스키마가 발전하거나, 테스트된 애플리케이션 로직이 새 API를 직접적으로 호출하기 위해 확장될 때마다 모의 업데이트가 필요하기 때문에 모의는 유지 관리하기 어려울 수도 있습니다. 이러한 변경으로 인해 개발자에게 추가 테스트 개발 워크로드가 발생합니다.

  • 모의 테스트는 로컬에서 통과할 수 있지만 실제 서비스의 동작을 복제하는 대신 시뮬레이션하여 환경별 문제를 감지하지 못하기 때문에 클라우드에서 실패할 수 있습니다.

  • 에뮬레이터와 같은 모의 프레임워크는 AWS Identity and Access Management (IAM) 정책 위반, 서비스 할당량 제한 또는 페이로드 크기 제약 조건을 감지할 수 없으며 배포된 환경의 애플리케이션 동작에 영향을 미칠 수 있는 Amazon CloudWatch AWS CloudTrail또는 Amazon GuardDuty와 같은 보조 서비스를 트리거하지 않습니다.

  • 모의 객체는 권한 부여가 실패하거나 할당량을 초과할 때 애플리케이션이 수행할 작업을 시뮬레이션하는 데 더 효과적이지만 모의 객체 테스트는 코드가 프로덕션 환경에 배포될 때 실제로 어떤 결과가 발생할지 결정할 수 없습니다.

에뮬레이션 테스트

에뮬레이션 테스트는 유사한에뮬레이터라고 하는 로컬에서 실행되는 애플리케이션을 통해 활성화됩니다 AWS 서비스. 에뮬레이터에는 클라우드의 해당 API와 유사한 API가 있으며 유사한 반환 값을 제공합니다. 또한 API 호출로 시작되는 상태 변경을 시뮬레이션할 수 있습니다. 예를 들어 Amazon S3 에뮬레이터는 PutObject 메서드가 호출될 때 로컬 디스크에 객체를 저장할 수 있습니다. GetObject가 동일한 키로 호출되면 에뮬레이터는 디스크에서 동일한 객체를 읽고 반환합니다.

에뮬레이션 테스트의 이점은 다음과 같습니다.

  • 로컬 환경에서 독점적으로 코드를 개발하는 데 익숙한 개발자에게 가장 친숙한 환경을 제공합니다. 예를 들어 n-티어 애플리케이션 개발에 익숙하다면 프로덕션 환경에서 실행되는 것과 유사한 데이터베이스 엔진과 웹 서버가 로컬 시스템에서 실행되어 빠르고 격리된 로컬 테스트 기능을 제공할 수 있습니다.

  • 클라우드 인프라(예: 개발자 클라우드 계정)를 변경할 필요가 없으므로 기존 테스트 패턴으로 쉽게 구현할 수 있습니다. 에뮬레이션 테스트는 빠른 로컬 개발 반복의 이점을 제공합니다.

그러나 에뮬레이터에는 몇 가지 단점이 있습니다.

  • 특히 CI/CD 파이프라인의 일부로 사용되는 경우 설정 및 복제가 어려운 경우가 많습니다. 이로 인해 IT 직원 또는 소프트웨어 설치를 관리하는 개발자의 워크로드와 유지 관리가 증가할 수 있습니다.

  • 에뮬레이션된 기능과 API는 일반적으로 서비스 변경에 뒤쳐져 지원이 추가되기 전까지는 새 기능을 채택하는 데 방해가 될 수 있습니다.

  • 에뮬레이터에는 지원, 업데이트, 버그 수정 또는 기능 패리티 개선이 필요할 수 있으며, 이는 에뮬레이터 작성자(대개 타사)의 책임입니다.

  • 에뮬레이터에 의존하는 테스트는 로컬에서 성공적인 결과를 제공할 수 있지만 일반적으로 에뮬레이션되지 않는 IAM 정책 및 할당량 AWS 과 같은의 다른 측면과의 상호 작용으로 인해 클라우드에서 실패할 수 있습니다.

  • 일부 에는 에뮬레이터 AWS 서비스 를 사용할 수 없으므로 에뮬레이션에만 의존하는 경우 애플리케이션의 일부에 대해 만족스러운 테스트 옵션이 없을 수 있습니다.

클라우드에서 테스트

클라우드에서 테스트는 데스크톱 환경 대신 클라우드 환경에 배포된 코드를 대상으로 테스트를 실행하는 프로세스입니다. 클라우드 네이티브 애플리케이션 개발을 통해 클라우드 테스트 가치가 높아집니다. 예제:

  • 클라우드에서 최신 APIs 및 서비스 기능에 대해 테스트를 실행하여 테스트가 새로운 서비스와 기능을 AWS 계속 시작할 때 최신 반환 값과 동작을 반영하는지 확인할 수 있습니다.

  • 테스트에는 IAM 정책, 서비스 할당량, 구성 및 모든 서비스가 포함될 수 있습니다.

  • 클라우드 테스트 환경은 프로덕션 런타임 환경과 가장 유사하므로 클라우드에서 실행하는 테스트는 환경 전반에 걸쳐 진행하면서 가장 일관된 결과를 얻을 수 있습니다.

클라우드 테스트의 단점은 다음과 같습니다.

  • 클라우드 환경에 배포는 일반적으로 데스크톱 환경에 배포하는 것보다 시간이 더 걸립니다. AWS Serverless Application Model (AWS SAM) Accelerate, AWS Cloud Development Kit (AWS CDK) 감시 모드 및 SST와 같은 도구는 클라우드 배포 반복과 관련된 지연 시간을 줄이는 데 도움이 됩니다.

  • 로컬 개발 환경을 사용하는 로컬 테스트와 달리 클라우드 테스트에는 추가 서비스 비용이 발생할 수 있습니다.

  • 고속 인터넷에 액세스할 수 없는 경우 클라우드에서 테스트하는 것이 불가능할 수 있습니다. 

  • 규제 산업에서 엔터프라이즈 보안 정책은 클라우드 환경에 대한 개발자 액세스를 제한하여 로컬 개발 워크플로의 일부로 클라우드 테스트를 실행하기 어렵거나 불가능하게 만들 수 있습니다.

  • 개발자 환경의 공유 계정에서는 스택 수준에서 환경 경계를 설정하는 경우가 많으며, 때로는 접두사를 사용하여 소유권을 식별하는 등의 네임스페이스 유형 전략을 사용하는 경우도 있습니다. 사전 프로덕션 및 프로덕션 환경의 경우 일반적으로 계정 수준에서 경계가 설정되어 잡음이 많은 이웃 문제로부터 워크로드를 격리하고 최소 권한 보안 제어를 지원하고 민감한 데이터를 보호합니다. 격리된 환경을 생성해야 하는 요구 사항은 DevOps 팀에 추가 부담을 줄 수 있습니다. 특히 계정 및 인프라를 엄격하게 제어하는 기업에 있는 경우 더욱 그렇습니다.