# REL 8 변경 사항은 어떻게 적용합니까?
새로운 기능을 배포하고 워크로드와 운영 환경에서 알려진 소프트웨어를 실행하고 예측 가능한 방식으로 패치 또는 교체할 수 있도록 하려면 변경 사항을 제어해야 합니다. 이러한 변경이 제어되지 않으면 변경의 영향을 예측하거나 변경으로 인해 발생하는 문제를 해결하기가 어려워집니다.
**Topics**
+ [REL08-BP01 배포와 같은 표준 활동에 런북 사용](rel_tracking_change_management_planned_changemgmt.md)
+ [REL08-BP02 배포의 일부로 기능 테스트 통합](rel_tracking_change_management_functional_testing.md)
+ [REL08-BP03 배포의 일부로 복원력 테스트 통합](rel_tracking_change_management_resiliency_testing.md)
+ [REL08-BP04 변경 불가능한 인프라를 사용하여 배포](rel_tracking_change_management_immutable_infrastructure.md)
+ [REL08-BP05 자동화를 통한 변경 사항 배포](rel_tracking_change_management_automated_changemgmt.md)
# REL08-BP01 배포와 같은 표준 활동에 런북 사용
런북은 특정 결과를 달성하기 위한 미리 정의된 절차입니다. 수동 또는 자동으로 표준 활동을 수행할 때 런북을 사용합니다. 워크로드 배포, 워크로드 패치 적용 또는 DNS 수정과 같은 활동이 여기에 포함됩니다.
예를 들어 [배포 중에 롤백이 안전한지 확인하는 프로세스를 준비합니다.](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments). 서비스를 안정적으로 유지하려면 고객 중단 없이 배포를 롤백할 수 있는지 확인하는 것이 중요합니다.
런북 절차를 수행할 때는 유효하고 효과적인 수동 프로세스에서 시작하고, 이를 코드에 구현한 다음, 필요한 경우 자동으로 실행되도록 트리거합니다.
고도로 자동화된 정교한 워크로드의 경우에도 [게임 데이를 실행하거나](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays) 엄격한 보고 및 감사 요구 사항을 충족할 때 런북을 유용하게 사용할 수 있습니다.
플레이북은 특정 인시던트에 대응하여 사용되며 런북은 특정 결과를 달성하기 위해 사용됩니다. 런북은 일상적인 활동에 대한 것이고, 플레이북은 일상적이지 않은 이벤트에 대응하는 데 사용되는 경우가 많습니다.
**일반적인 안티 패턴:**
+ 프로덕션 환경에서 계획되지 않은 구성 변경 수행
+ 더 빠르게 배포하기 위해 계획의 단계를 건너뛰고, 그 결과 배포에 실패
+ 변경 사항 되돌리기를 테스트하지 않고 변경 수행
**이 모범 사례 수립의 이점:** 변경 계획을 효과적으로 수립하면 영향을 받는 모든 시스템을 파악할 수 있으므로 변경 사항을 성공적으로 실행할 수 있습니다. 테스트 환경에서 변경 사항을 검증하면 신뢰성을 높일 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 런북에 절차를 문서화하면 잘 알려진 이벤트에 일관된 방식으로 신속하게 대응할 수 있습니다.
+ [AWS Well-Architected Framework: 개념: 런북](https://wa.aws.amazon.com/wat.concept.runbook.en.html)
+ 코드형 인프라의 원칙을 사용해 인프라를 정의합니다. AWS CloudFormation 또는 신뢰할 수 있는 서드 파티 제품을 사용하여 인프라를 정의하면 버전 제어 소프트웨어를 통한 변경 사항의 각 버전을 차례대로 확인할 수 있습니다.
+ AWS CloudFormation 또는 신뢰할 수 있는 서드 파티 제품을 사용하여 인프라를 정의합니다.
+ [AWS CloudFormation이란 무엇인가요?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ 우수한 소프트웨어 설계 원칙으로 분리된 단일 템플릿을 생성합니다.
+ 구현 권한, 템플릿 및 책임자를 결정합니다.
+ [AWS Identity and Access Management로 액세스 제어 ](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-iam-template.html)
+ 버전을 제어하려면 AWS CodeCommit 또는 신뢰할 수 있는 서드 파티 도구와 같은 소스 제어를 사용합니다.
+ [AWS CodeCommit이란 무엇입니까?](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
## 리소스
**관련 문서:**
+ [APN 파트너: 자동화된 배포 솔루션의 생성을 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=devops)
+ [AWS Marketplace: 배포 자동화에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps)
+ [AWS Well-Architected Framework: 개념: 런북](https://wa.aws.amazon.com/wat.concept.runbook.en.html)
+ [AWS CloudFormation이란 무엇인가요?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [AWS CodeCommit이란 무엇입니까?](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
**관련 예시:**
+ [플레이북 및 런북으로 운영 자동화](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
# REL08-BP02 배포의 일부로 기능 테스트 통합
기능 테스트는 자동화된 배포의 일부로 실행됩니다. 성공 기준이 충족되지 않으면 파이프라인이 중지되거나 롤백됩니다.
이러한 테스트는 파이프라인에서 프로덕션 전에 준비되는 사전 프로덕션 환경에서 실행됩니다. 이 작업을 배포 파이프라인의 일부로 수행하는 것이 가장 좋습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 배포의 일부로 기능 테스트를 통합합니다. 기능 테스트는 자동화된 배포의 일부로 실행됩니다. 성공 기준이 충족되지 않으면 파이프라인이 중지되거나 롤백됩니다.
+ AWS CodePipeline에 모델링된 소프트웨어 릴리스 파이프라인의 '테스트 작업'을 실행하는 중에 AWS CodeBuild를 호출합니다. 이 기능을 사용하면 단위 테스트, 정적 코드 분석, 통합 테스트 등 코드에 대해 다양한 테스트를 손쉽게 실행할 수 있습니다.
+ [AWS CodePipeline Adds Support for Unit and Custom Integration Testing with AWS CodeBuild(AWS CodePipeline, AWS CodeBuild를 사용한 단위 및 맞춤형 통합 테스트 관련 지원 추가)](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ AWS Marketplace 솔루션을 사용하여 소프트웨어 제공 파이프라인의 일부로 자동화된 테스트를 실행합니다.
+ [소프트웨어 테스트 자동화](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
## 리소스
**관련 문서:**
+ [AWS CodePipeline Adds Support for Unit and Custom Integration Testing with AWS CodeBuild(AWS CodePipeline, AWS CodeBuild를 사용한 단위 및 맞춤형 통합 테스트 관련 지원 추가)](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [소프트웨어 테스트 자동화](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
+ [AWS CodePipeline란 무엇입니까?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
# REL08-BP03 배포의 일부로 복원력 테스트 통합
복원력 테스트( [카오스 엔지니어링의 원칙 사용)](https://principlesofchaos.org/)는 사전 프로덕션 환경에서 자동화된 배포 파이프라인에 포함되어 실행됩니다.
이러한 테스트는 프로덕션 전 환경에서 파이프라인에서 준비되고 실행됩니다. 또한 프로덕션 환경에서도 다음의 일부로 실행되어야 합니다. [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html#GameDays).
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 배포의 일부로 복원력 테스트를 통합합니다. 프로덕션 환경에서 격변의 조건을 견딜 수 있는 워크로드의 기능에 대한 신뢰성을 확보하기 위해 시스템을 실험하는 분야인 카오스 엔지니어링을 사용합니다.
+ 복원력 테스트는 결함 또는 리소스 저하를 발생시켜 워크로드가 설계된 복원력으로 대응하는지 평가합니다.
+ [Well-Architected lab: Level 300: Testing for Resiliency of EC2 RDS and S3(Well-Architected 실습: 레벨 300: EC2 RDS 및 S3의 복원력 테스트)](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html)
+ 이러한 테스트는 자동화된 배포 파이프라인의 사전 프로덕션 환경에서 정기적으로 실행할 수 있습니다.
+ 또한 예약된 게임 데이의 일부로 프로덕션에서 실행해야 합니다.
+ 카오스 엔지니어링 원칙을 사용하여 다양한 장애 하에서 워크로드의 성능이 어떻게 나타날지에 대한 가설을 제안한 다음 복원력 테스트를 사용하여 가설을 테스트합니다.
+ [Principles of Chaos Engineering(카오스 엔지니어링의 원칙)](https://principlesofchaos.org/)
## 리소스
**관련 문서:**
+ [Principles of Chaos Engineering(카오스 엔지니어링의 원칙)](https://principlesofchaos.org/)
+ [AWS Fault Injection Simulator란 무엇입니까?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**관련 예시:**
+ [Well-Architected lab: Level 300: Testing for Resiliency of EC2 RDS and S3(Well-Architected 실습: 레벨 300: EC2 RDS 및 S3의 복원력 테스트)](https://wellarchitectedlabs.com/Reliability/300_Testing_for_Resiliency_of_EC2_RDS_and_S3/README.html)
# REL08-BP04 변경 불가능한 인프라를 사용하여 배포
변경 불가능한 인프라는 프로덕션 워크로드의 현재 위치에서 업데이트, 보안 패치 또는 구성 변경이 발생하지 않도록 규정하는 모델입니다. 변경이 필요한 경우 아키텍처가 새 인프라에 구축되고 프로덕션 환경에 배포됩니다.
변경 불가능한 인프라 패러다임의 가장 일반적인 구현 형태는 ***변경 불가능한 서버입니다.***. 즉, 서버에 업데이트 또는 수정이 필요한 경우 이미 사용 중인 서버를 업데이트하는 대신 새 서버가 배포됩니다. 따라서 SSH를 통해 서버에 로그인하고 소프트웨어 버전을 업데이트하는 대신 애플리케이션의 모든 변경은 코드 리포지토리에 소프트웨어를 푸시(예: git push)하는 것으로 시작됩니다. 변경이 불가능한 인프라에서는 변경이 허용되지 않으므로 배포된 시스템의 상태를 확신할 수 있습니다. 변경이 불가능한 인프라는 본질적으로 더 일관되고 안정적이며 예측 가능하며 소프트웨어 개발 및 운영의 여러 측면을 간소화합니다.
변경이 불가능한 인프라에서 애플리케이션을 배포할 때는 Canary 또는 블루/그린 배포를 사용합니다.
[https://martinfowler.com/bliki/CanaryRelease.html](https://martinfowler.com/bliki/CanaryRelease.html) 는 일반적으로 단일 서비스 인스턴스에서 실행되는 새 버전(Canary)으로 소수의 사용자를 연결하는 방식입니다. 그런 다음 생성되는 동작 변경 또는 오류를 면밀히 조사합니다. 중대한 문제가 발생하여 사용자에게 이전 버전을 다시 제공해야 하는 경우에는 Canary에서 트래픽을 제거할 수 있습니다. 배포가 정상적으로 진행되면 배포가 완료될 때까지 변경 사항에서 오류를 모니터링하면서 원하는 속도로 배포를 계속 진행할 수 있습니다. Canary 배포를 지원하는 배포 구성을 사용하여 AWS CodeDeploy를 구성할 수 있습니다.
[https://martinfowler.com/bliki/BlueGreenDeployment.html](https://martinfowler.com/bliki/BlueGreenDeployment.html) 는 Canary 배포와 비슷합니다. 단, 전체 애플리케이션 플릿이 병렬로 배포됩니다. 이 패턴에서는 블루와 그린의 두 스택에서 번갈아 가며 배포를 수행합니다. 이 패턴에서도 새 버전으로 트래픽을 전송한 다음 배포에 문제가 발생하면 이전 버전으로 장애 복구할 수 있습니다. 일반적으로 모든 트래픽은 한 번에 전환되지만, Amazon Route 53의 가중치 기반 DNS 라우팅 기능을 사용하면 각 버전에 대한 트래픽의 일부를 사용하여 새 버전의 채택을 유도할 수도 있습니다. 블루/그린 배포를 지원하는 배포 구성을 사용하여 AWS CodeDeploy와 AWS Elastic Beanstalk를 구성할 수 있습니다.
![\[AWS Elastic Beanstalk 및 Amazon Route 53를 사용한 블루/그린 배포를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/blue-green-deployment.png)
변경 불가능한 인프라의 이점:
+ **구성 드리프트 감소:** 알려진 기본 버전 제어 구성에서 서버를 자주 교체하면 인프라가 알려진 상태로 **재설정되므로** 구성 드리프트가 방지됩니다.
+ **간소화된 배포**: 업그레이드를 지원할 필요가 없으므로 배포가 간소화됩니다. 업그레이드는 단지 새로운 배포일 뿐입니다.
+ **안정성 있는 원자 단위 배포:** 배포가 성공적으로 완료되거나 아무 것도 변경되지 않습니다. 따라서 배포 프로세스의 신뢰도가 개선됩니다.
+ **빠른 롤백 및 복구 프로세스를 통해 배포 안전성 개선:** 이전 작업 버전이 변경되지 않으므로 배포가 더 안전합니다. 오류가 감지되면 롤백할 수 있습니다.
+ **일관된 테스트 및 디버깅 환경:** 모든 서버에 동일한 이미지가 사용되므로 환경 간에 차이가 없습니다. 하나의 빌드가 여러 환경에 배포됩니다. 또한 일관되지 않은 환경이 방지되고 테스트 및 디버깅이 간소화됩니다.
+ **확장성 개선:** 서버가 기본 이미지를 사용하고 일관적이며 반복 가능하므로 자동 조정이 간단합니다.
+ **간소화된 도구 체인**: 프로덕션 소프트웨어 업그레이드를 관리하는 구성 관리 도구를 제거할 수 있으므로 도구 체인이 간소화됩니다. 서버에 추가 도구 또는 에이전트가 설치되지 않습니다. 변경은 기본 이미지에 수행되고 테스트된 후 롤아웃됩니다.
+ **보안 강화:** 서버에 대한 모든 변경을 거부하면 인스턴스에서 SSH를 비활성화하고 키를 제거할 수 있습니다. 이렇게 하면 공격 벡터가 줄어들어 조직의 보안 태세를 개선할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 변경 불가능한 인프라를 사용하여 배포합니다. 변경 불가능한 인프라는 프로덕션 시스템의 *현재 위치에서* 업데이트, 보안 패치 또는 구성 변경이 발생하지 않도록 규정하는 모델입니다. 변경이 필요한 경우 새 버전의 아키텍처가 구축되고 프로덕션 환경에 배포됩니다.
+ [블루/그린 배포 개요](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-blue-green)
+ [Deploying Serverless Applications Gradually(점진적으로 서버리스 애플리케이션 배포)](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html)
+ [변경 불가능한 인프라: 불변성을 통한 안정성, 일관성 및 신뢰성](https://medium.com/@adhorn/immutable-infrastructure-21f6613e7a23)
+ [CanaryRelease](https://martinfowler.com/bliki/CanaryRelease.html)
## 리소스
**관련 문서:**
+ [CanaryRelease](https://martinfowler.com/bliki/CanaryRelease.html)
+ [Deploying Serverless Applications Gradually(점진적으로 서버리스 애플리케이션 배포)](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/automating-updates-to-serverless-apps.html)
+ [변경 불가능한 인프라: 불변성을 통한 안정성, 일관성 및 신뢰성](https://medium.com/@adhorn/immutable-infrastructure-21f6613e7a23)
+ [블루/그린 배포 개요](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html#welcome-deployment-overview-blue-green)
+ [Amazon Builders' Library: 배포 중 롤백 안전 보장](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
# REL08-BP05 자동화를 통한 변경 사항 배포
배포 및 패치 적용이 자동화되므로 부정적인 영향이 제거됩니다.
프로덕션 시스템을 변경하는 것은 조직에서 가장 위험 부담이 큰 영역에 속합니다. 배포는 소프트웨어를 통해 해결할 수 있는 업무상의 문제와 더불어 해결해야 하는 가장 중요한 문제로 간주됩니다. 오늘날에는 배포 관련 문제를 해결하려면 운영 과정에서 해당하는 모든 영역(변경 사항 테스트/배포, 용량 추가/제거, 데이터 마이그레이션 포함)에 자동화를 사용해야 합니다. AWS CodePipeline을 사용하면 워크로드를 해제하는 데 필요한 단계를 관리할 수 있습니다. 여기에는 AWS CodeDeploy를 사용하여 Amazon EC2 인스턴스, 온프레미스 인스턴스, 서버리스 Lambda 함수 또는 Amazon ECS 서비스에 대한 애플리케이션 코드 배포를 자동화하는 배포 상태가 포함됩니다.
**권장 사항**
일반적인 통념으로는 가장 어려운 작업 절차에 사람을 투입하는 것이 좋다고 하지만 AWS에서는 바로 그런 이유로 가장 어려운 절차를 자동화할 것을 권장합니다.
**일반적인 안티 패턴:**
+ 수동으로 변경 수행
+ 비상 워크플로를 통해 자동화 단계를 건너뜀
+ 계획을 따르지 않음
**이 모범 사례 수립의 이점:** 자동화를 사용하여 모든 변경 사항을 배포하면 인적 오류가 발생할 가능성이 사라지고 프로덕션을 변경하기 전에 테스트하여 계획이 완료되었는지 확인할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 배포 파이프라인을 자동화합니다. 배포 파이프라인을 사용하면 이상 징후의 자동 테스트 및 탐지를 실행하여 프로덕션 배포 전 특정 단계에서 파이프라인을 중지하거나 변경 사항을 자동으로 롤백할 수 있습니다.
+ [Amazon Builders' Library: 배포 중 롤백 안전 보장](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
+ [Amazon Builders' Library: 지속적 전달을 통한 신속한 배포](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/)
+ AWS CodePipeline 또는 신뢰할 수 있는 서드 파티 제품을 사용하여 파이프라인을 정의하고 실행합니다.
+ 코드 저장소에 변경 사항이 전달되고 나서 실행되도록 파이프라인을 구성합니다.
+ [AWS CodePipeline이란 무엇입니까?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
+ Amazon Simple Notification Service(Amazon SNS) 및 Amazon Simple Email Service(Amazon SES)를 사용하여 파이프라인의 문제에 대한 알림을 전송하거나 Amazon Chime과 같은 팀 채팅 도구에 통합합니다.
+ [Amazon Simple Notification Service란 무엇입니까?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
+ [Amazon SES란 무엇입니까?](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html)
+ [Amazon Chime이란 무엇일까요?](https://docs.aws.amazon.com/chime/latest/ug/what-is-chime.html)
+ [Automate chat messages with webhooks(Webhook으로 채팅 메시지 기능 자동화)](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html)
## 리소스
**관련 문서:**
+ [APN 파트너: 자동화된 배포 솔루션의 생성을 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=devops)
+ [AWS Marketplace: 배포 자동화에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=DevOps)
+ [Automate chat messages with webhooks(Webhook으로 채팅 메시지 기능 자동화)](https://docs.aws.amazon.com/chime/latest/ug/webhooks.html)
+ [Amazon Builders' Library: 배포 중 롤백 안전 보장](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments)
+ [Amazon Builders' Library: 지속적 전달을 통한 신속한 배포](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/)
+ [AWS CodePipeline란 무엇입니까?](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
+ [CodeDeploy란 무엇입니까?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
+ [Amazon SES란 무엇입니까?](https://docs.aws.amazon.com/ses/latest/DeveloperGuide/Welcome.html)
+ [Amazon Simple Notification Service란 무엇입니까?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
**관련 동영상:**
+ [AWS Summit 2019: CI/CD on AWS(AWS 기반 CI/CD)](https://youtu.be/tQcF6SqWCoY)