프로덕션으로 승격하기

이제 새로운 기능이 테스트를 마치고 master 브랜치에 병합되었으니, 프로덕션으로 승격할 준비가 되었습니다. dev 단계를 prod로 승격하여 진행할 예정입니다.

Seed로 이동한 후, dev 단계 하단의 Promote 버튼을 클릭하세요.

변경 사항 목록이 표시됩니다. 주요 변경 사항만 여기에 표시됩니다. 변경 목록에는 Lambda 함수와 API Gateway 메서드가 추가된 것을 확인할 수 있습니다. Lambda 실행 IAM 역할 및 Lambda의 CloudWatch 로그 그룹과 같은 몇 가지 사소한 리소스도 추가되었지만, 기본적으로 숨겨져 있습니다.

Promote to Production을 클릭하세요.

이렇게 하면 prod 단계의 빌드가 시작됩니다.

수동 승인이 필요한 이유

전통적인 모놀리식 애플리케이션(서버리스가 아닌) 개발에서는 코드가 주로 애플리케이션 로직으로 구성됩니다. 애플리케이션 로직은 비교적 쉽게 롤백할 수 있고, 일반적으로 부작용이 없습니다.

서버리스 앱은 IaC(Infrastructure as Code) 패턴을 채택하며, 인프라 정의(serverless.yml)가 코드베이스에 포함됩니다. 서버리스 앱이 배포되면 코드가 업데이트되고 인프라 변경 사항이 적용됩니다. serverless.yml 파일의 오타로 인해 리소스가 삭제될 수 있습니다. 데이터베이스 리소스의 경우 영구적인 데이터 손실로 이어질 수 있습니다.

이러한 문제를 방지하기 위해, 인프라 변경 사항이 프로덕션 환경으로 승인되기 전에 검토 단계를 거치는 것이 좋습니다.

변경 세트(Change Set)란 무엇인가요?

CloudFormation은 변경 세트라는 기능을 제공합니다. 여러분이 스택에 배포할 새로운 템플릿을 CloudFormation에 제공하면, CloudFormation은 추가, 수정, 삭제될 리소스를 보여줍니다. 이를 일종의 시뮬레이션(dry run)으로 생각할 수 있습니다.

CI/CD 파이프라인의 수동 승인 단계에서 CloudFormation 변경 세트를 생성하는 것을 권장합니다. 이렇게 하면 적용될 정확한 인프라 변경 사항을 검토할 수 있습니다. 이 추가 단계는 프로덕션 환경에 배포될 수 있는 되돌릴 수 없는 인프라 변경을 방지하는 데 큰 도움이 됩니다.

하지만 CloudFormation 템플릿과 변경 세트는 읽기 어려울 수 있습니다. 이 부분에서 Serverless Framework는 Lambda와 API 리소스를 간결하고 간단한 문법으로 프로비저닝할 수 있도록 잘 지원합니다. 실제로는 Lambda 역할, Lambda 버전, Lambda 로그 그룹, API Gateway 리소스, API Gateway 메서드, API Gateway 배포 등 많은 리소스가 프로비저닝됩니다. 하지만 CloudFormation이 이러한 리소스의 변경 목록을 보여줄 때(일반적으로 암호 같은 이름으로), 실제로 주의를 기울여야 하는 변경 사항이 가려질 수 있습니다. 그래서 Seed에서는 CloudFormation 변경 세트를 개선하기 위해 추가적인 노력을 기울였습니다. 개발자에게 관련된 변경 사항을 보여주고, 특별히 주의가 필요한 변경 사항을 강조합니다.

다음으로, 코드를 롤백해야 하는 상황에 대해 살펴보겠습니다.