테스트 관점에서 서버리스 애플리케이션 워크플로 재고찰

1단계: 요구 사항

아키텍처 개요

• AWS Lambda와 Step Functions를 사용하는 배치 처리 워크플로입니다.
• 세 개의 상태가 직선 형태로 연결됩니다.
• 각 Lambda 함수에는 단위 테스트를 적용하지만 Step Functions 워크플로는 수동으로 테스트합니다.

테스트 목표

• Step Functions 워크플로 테스트를 자동화합니다.
• 입력값과 출력값이 예상값과 일치하는지 확인합니다.
• GitHub Actions를 사용하여 테스트를 CI/CD 파이프라인에 통합합니다.
• 테스트를 위해 실제 AWS 환경에 배포하지 않습니다.

2단계: 계획

도구 및 기술

• Step Functions Local: Step Functions를 로컬에서 실행하고 테스트합니다.
• GitHub Actions: CI/CD 워크플로를 자동화합니다.
• LocalStack 또는 유사 도구: AWS Lambda를 로컬에서 시뮬레이션합니다.

GitHub Actions 워크플로

• 푸시 또는 풀 리퀘스트 시 테스트를 실행하도록 워크플로를 설정합니다.
• 로컬 테스트 환경에 Step Functions Local Docker 이미지를 사용합니다.
• Lambda 시뮬레이션에 LocalStack을 사용합니다.
• https://www.localstack.cloud/
• Step Functions 정의를 가져와 워크플로를 로컬에서 실행합니다.
• 각 상태의 입력값과 출력값을 확인합니다.

워크플로 단계

• [ 1 ] 컨테이너 시작:
• Step Functions Local Docker 이미지를 가져와 시작합니다.
• Lambda 시뮬레이션을 위해 LocalStack을 설정합니다.
• [ 2 ] Step Functions 정의 가져오기:
• 상태 머신 정의를 로컬 환경으로 가져옵니다.
• [ 3 ] 워크플로 실행:
• 로컬 엔드포인트를 사용하여 Step Functions 워크플로를 트리거합니다.
• [ 4 ] 결과 검증:
• 입력값과 출력값을 예상값과 비교합니다.
• [ 5 ] 결과 보고:
• 테스트 성공 또는 실패를 나타내는 보고서나 상태를 생성합니다.

서버리스 아키텍처를 테스트하는 방법

소개

• 서버리스 아키텍처는 고객에게 가치를 빠르게 제공할 수 있게 하는 상당한 이점을 제공합니다.
• 여기서는 시스템 성능이나 비용이 아니라 테스트 관점의 검증에 초점을 맞춥니다.

테스트가 필요한 이유

• 테스트는 시스템 동작을 이해하고 예측하며 제어하는 데 도움이 됩니다.
• 시스템 위험을 식별하고 정량화할 수 있습니다.
• 테스트를 작성하면 요구 사항을 더 잘 이해할 수 있습니다.
• 테스트는 결과의 재현 가능성과 설명 가능성을 보장합니다.
• 테스트의 주된 목표는 알려지지 않은 위험을 줄이는 것입니다.

테스트 유형

• 단위 테스트: 개별 구성 요소나 함수를 격리하여 테스트합니다.
• 통합 테스트: 결합된 구성 요소 간의 상호 작용을 테스트합니다.
• 로직 테스트: 비즈니스 로직의 정확성을 검증합니다.
• 워크플로 테스트: 프로세스나 워크플로의 전체 흐름을 테스트합니다.
• API 테스트: API의 기능과 안정성을 테스트합니다.

권장 사항

• 여러 테스트 유형과 각각의 목적 및 목표를 파악하는 것이 중요합니다.
• 이러한 테스트 유형을 이해하면 서버리스 아키텍처를 위한 효과적인 테스트 전략을 설계하는 데 도움이 됩니다.

더 쉬운 테스트를 위한 처리 분리

핵심 사항

• 테스트하기 쉬운 단위: 테스트하기 쉬운 단위는 이해하기도 쉽습니다.
• 시스템 명확성: 시스템을 분리된 테스트 가능 단위로 설계하면 무엇을, 언제, 왜 수행하는지 자연스럽게 드러납니다.
• 복잡성 방지: 테스트하기 어렵다면 한곳에 너무 많은 책임과 로직이 집중되어 있을 가능성이 큽니다.

예시 비교

• 부족한 아키텍처: 하나의 Lambda 함수가 다른 서버에서 데이터를 가져오는 작업과 DynamoDB에서 데이터를 처리하고 저장하는 작업을 모두 담당합니다.
• 적절한 아키텍처: 각 작업(데이터 가져오기, 데이터 처리 및 저장)에 별도의 Lambda 함수를 사용합니다.

분리의 이점

• 각 부분을 개별적으로 더 쉽게 테스트할 수 있습니다.
• 오류가 발생했을 때 문제의 정확한 위치를 더 쉽게 찾을 수 있습니다.
• 오류 발생부터 오류 식별 및 수정까지 걸리는 시간을 줄입니다.

일반 원칙

• 메서드 분리: 메서드를 분리하는 동일한 원칙이 여러 프로그래밍 언어(예: Python, Ruby, Go)에 적용됩니다.
• 작은 단위: 작고 테스트 가능한 단위가 무엇인지 판단하고 그에 따라 이 분리 원칙을 적용합니다.

시스템 설계의 테스트 관점

• 취약점 식별: 테스트 관점에서는 한곳에 책임이 과도하게 집중되는 등의 취약점을 쉽게 식별할 수 있습니다.
• 오류 탐지 시간 단축: 높은 테스트 용이성은 개발 주기를 단축하는 것과 마찬가지로 오류 발생부터 탐지 및 수정까지 걸리는 시간을 줄이는 데 도움이 됩니다.
• 빠른 제공: 높은 테스트 용이성은 시스템을 더 빠르게 제공하는 데 기여합니다.

테스트 관점에서 서버리스 아키텍처를 구축할 때 고려할 핵심 사항

• 처리 분리: 테스트하기 쉬운 단위는 이해하기도 쉽습니다. 프로세스를 분리하면 취약점을 식별하고 오류 탐지 시간을 줄이는 데 도움이 됩니다.
• 복잡성 방지: 한곳에 책임과 로직이 집중되면 테스트가 어려워집니다. 프로세스를 분리하여 테스트와 문제 해결을 단순화합니다.
• 높은 테스트 용이성: 시스템 제공 속도를 높이고 개발 주기를 단축하는 데 기여합니다.

최종 목표

• 엔지니어의 궁극적인 목표는 사용자에게 가치를 제공하는 것입니다.
• 성공적인 결과를 보장하려면 항상 사용자 가치를 염두에 두어야 합니다.
• 통찰을 공유하고 테스트 관행을 개선하기 위한 토론과 협업을 장려합니다.