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

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

모의 테스트

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 모의 객체 테스트는 데스크톱 환경에서는 통과하지만 클라우드에서는 실패할 수 있습니다.

• 에뮬레이터와 같은 모의 프레임워크는 테스트 또는 감지 AWS Identity and Access Management (IAM) 정책 또는 할당량 제한에 제한됩니다.

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

클라우드에서 테스트

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

• 클라우드에서 최신 API 및 반환 값에 대해 테스트를 실행할 수 있습니다.

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

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

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

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

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

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

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

에뮬레이션 테스트

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

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

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

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

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

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

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

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

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

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