배포 방법

지속적 전달 프로세스에서 새 버전의 소프트웨어를 출시하기 위한 여러 배포 전략과 변형을 고려할 수 있습니다. 이 단원에서는 가장 일반적인 배포 방법인 한 번에 모두(바로 배포), 롤링, 변경 불가능 및 블루/그린에 대해 설명합니다. AWS는 이러한 방법 중 AWS CodeDeploy 및 AWS Elastic Beanstalk에서 지원되는 방법을 나타냅니다.

다음 표에는 각 배포 방법의 특성이 요약되어 있습니다.

방법	배포 실패로 인한 영향	배포 시간	가동 중지 없음	DNS 변경 없음	롤백 프로세스	코드 배포 위치
바로 배포	가동 중지		☓	✓	재배포	기존 인스턴스
롤링	단일 배치가 서비스에서 제외됨. 실패하기 전 성공한 배치가 새 애플리케이션 버전 실행.	†	✓	✓	재배포	기존 인스턴스
추가 배치를 사용한 롤링(beanstalk)	첫 번째 배치가 실패할 경우 최소화. 그렇지 않은 경우 롤링과 유사함.	†	✓	✓	재배포	새 인스턴스 및 기존 인스턴스
변경 불가능	최소화		✓	✓	재배포	새 인스턴스
트래픽 분할	최소화		✓	✓	트래픽 재라우팅 및 새 인스턴스 종료	새 인스턴스
블루/그린	최소화		✓	☓	이전 환경으로 다시 전환	새 인스턴스

한 번에 모두(바로 배포)

한 번에 모두(바로 배포)는 기존 서버 플릿에 새 애플리케이션 코드를 롤아웃하는 데 사용할 수 있는 방법입니다. 이 방법은 한 배포 작업에서 모든 코드를 대체합니다. 플릿의 모든 서버가 한 번에 업데이트되므로 가동 중단이 필요합니다. 기존 DNS 레코드를 업데이트할 필요가 없습니다. 배포에 실패한 경우 작업을 복원하는 유일한 방법은 모든 서버에 코드를 다시 배포하는 것입니다.

AWS Elastic Beanstalk에서 이 배포는 한 번에 모두라고 하며, 단일 및 부하 분산 애플리케이션에 사용할 수 있습니다. AWS CodeDeploy에서 이 배포 방법은 배포 구성이 AllAtOnce인 바로 배포라고 합니다.

롤링 배포

롤링 배포를 사용하면 모든 플릿이 한 번에 업그레이드되지 않도록 여러 부분으로 나뉩니다. 배포 프로세스 중에 두 가지 소프트웨어 버전(새 버전과 이전 버전)이 동일한 플릿에서 실행됩니다. 이 방법을 사용하면 가동 중지 없이 업데이트할 수 있습니다. 배포에 실패하면 플릿의 업데이트된 부분만 영향을 받습니다.

카나리 릴리스라고 하는 롤링 배포 방법의 변형은 처음에는 아주 적은 비율의 서버에 새 소프트웨어 버전을 배포하는 작업이 포함됩니다. 이렇게 하면 변경 사항의 영향을 최소화하면서 소수의 서버에서 소프트웨어가 프로덕션에서 어떻게 동작하는지 관찰할 수 있습니다. 카나리 배포에서 오류 발생률이 높아지면 소프트웨어가 롤백됩니다. 그렇지 않으면 새 버전을 사용하는 서버의 비율이 점차 증가합니다.

AWS Elastic Beanstalk는 두 가지 배포 옵션인 추가 배치를 사용한 롤링 및 롤링으로 롤링 배포 패턴을 따랐습니다. 이러한 옵션을 사용하면 서버의 서비스를 중단하기 전에 애플리케이션을 먼저 확장하여 배포 중에 전체 기능을 유지할 수 있습니다. AWS CodeDeploy에서는 이 패턴을 OneAtTime 및 HalfAtaTime과 같은 패턴을 사용하여 바로 배포의 변형으로 수행합니다.

변경 불가능 및 블루/그린 배포

변경 불가능 패턴은 애플리케이션 코드의 새 구성 또는 버전으로 완전히 새로운 서버 집합을 시작하여 애플리케이션 코드의 배포를 지정합니다. 이 패턴은 간단한 API 호출로 새 서버 리소스가 생성되는 클라우드 기능을 활용합니다.

블루/그린 배포 전략은 변경 불가능 배포 유형이며 다른 환경을 만들어야 합니다. 새 환경이 가동되고 모든 테스트를 통과하면 트래픽이 이 새 배포로 이동합니다. 결정적으로 이전 환경인 “블루” 환경은 롤백이 필요한 경우 유휴 상태로 유지됩니다.

AWS Elastic Beanstalk는 변경 불가능 및 블루/그린 배포 패턴을 지원합니다. AWS CodeDeploy도 블루/그린 패턴을 지원합니다. AWS 서비스가 이러한 변경 불가능 패턴을 달성하는 방법에 대한 자세한 내용은 AWS 기반 블루/그린 배포 백서를 참조하세요.