Deployment
1 AWS Elastic Beanstalk Deployment
- AWS Elastic Beanstalk는 AWS에서 애플리케이션을 쉽게 배포하고 관리할 수 있는 완전 관리형 서비스입니다.
- 다양한 배포 방식을 제공하여, 개발자는 애플리케이션의 특성과 요구에 맞는 배포 방법을 선택할 수 있습니다.
2 주요 배포 방식
2.1 All at Once
- 모든 인스턴스에서 동시에 새로운 버전을 배포하는 방식입니다.
- 장점:
- 배포 속도가 빠릅니다.
- 간단하고 설정이 필요 없습니다.
- 추가 비용이 없습니다.
- 개발 환경에 적합합니다.
- 단점:
- 배포 중 애플리케이션이 잠시 다운타임을 가질 수 있습니다.
- 실패 시 전체 환경이 영향을 받을 수 있습니다.
- 사용 시기:
- 애플리케이션에 약간의 다운타임이 허용될 때.
- 배포가 간단하고 빠르게 완료되어야 할 때.
- 비용을 최소화해야 하거나 개발 환경에서 배포를 테스트할 때.
2.2 Rolling
- 인스턴스를 그룹으로 나누어 순차적으로 새로운 버전을 배포하는 방식입니다.
- 인스턴스 그룹(버킷)을 설정하여 배포할 수 있습니다.
- 버킷 사이즈는 한 번에 업데이트할 인스턴스의 수를 정의합니다.
- 버킷 사이즈가 2로 설정된 경우, 한 번에 두 개의 인스턴스가 업데이트됩니다.
- 장점:
- 다운타임을 최소화할 수 있습니다.
- 각 그룹의 배포 가 완료된 후 다음 그룹으로 넘어갑니다.
- 애플리케이션이 동시에 두 버전을 실행하므로, 트래픽을 계속 처리할 수 있습니다.
- 새로운 인스턴스를 생성할 필요가 없어 비용이 추가되지 않습니다.
- 단점:
- 배포 속도가 다소 느릴 수 있습니다.
- 배포 중 일부 인스턴스는 새로운 버전, 일부는 이전 버전을 실행할 수 있습니다.
- 애플리케이션이 용량 이하로 실행됩니다.
- 사용 시기:
- 애플리케이션의 가용성을 유지하면서 배포해야 할 때.
2.3 Rolling with Additional Batch
- 새로운 인스턴스를 추가하여 배포 중 애플리케이션의 가용성을 유지하면서 다운타임을 최소화하는 방식입니다.
- 인스턴스 그룹(버킷)을 설정하여 배포할 수 있습니다.
- 예를 들어, 버킷 사이즈를 2로 설정할 수 있습니다.
- 장점:
- 애플리케이션이 최대 용량으로 실행됩니다.
- 거의 무중단 배포가 가능합니다.
- 새로운 버전을 배포하는 동안 추가 인스턴스를 사용하여 기존 버전의 가용성을 유지합니다.
- 단점:
- 추가 인스턴스가 필요하므로 소규모 추가 비용이 발생할 수 있습니다.
- 배포 속도가 다소 느릴 수 있습니다.
- 사용 시기:
- 무중단 배포가 필요하고 추가 리소스를 사용할 수 있을 때.
- 프로덕션 환경에서 안정적인 배포가 필요할 때.
2.4 Blue/Green
- 새로운 버전을 별도의 환경에 배포한 후, 트래픽을 새로운 환경으로 전환하는 방식입니다.
- 이는 AWS Elastic Beanstalk가 직접 제공하는 기능은 아니며, 사용자가 구성해야 하는 방식입니다.
- Route 53을 사용해 트래픽을 분할하고 새로운 환경으로 전환하는 방식으로 구현할 수 있습니다.
- 새로운 "그린" 환경을 생성하고 새로운 버전을 배포합니다.
- 가중치 기반 정책을 사용하여 일부 트래픽을 그린 환경으로 리디렉션할 수 있습니다.
- 환경 테스트가 완료되면 Elastic Beanstalk의 "URL 스왑" 기능을 사용하여 트래픽을 새로운 환경으로 전환합니다.
- 장점:
- 무중단 배포가 가능합니다.
- 새로운 환경을 독립적으로 검증할 수 있으며, 문제가 발생하면 빠르게 롤백할 수 있습니다.
- 단점:
- 두 개의 환경을 유지해야 하므로 비용이 증가할 수 있습니다.
- 트래픽 전환 과정이 필요합니다.
- 사용 시기:
- 무중단 배포가 필수적이고, 신속한 롤백이 필요할 때.
- 새로운 버전을 검증하고 안정성을 확인한 후에 배포하고자 할 때.
2.5 Immutable
- 새로운 인스턴스를 생성하여 새로운 버전을 배포한 후, 배포가 완료되면 기존 인스턴스를 새로운 인스턴스로 교체하는 방식입니다.
- 새로운 인스턴스를 위한 임시 ASG(Auto Scaling Group)를 생성하여 새로운 버전을 배포하고, 배포가 성공적으로 완료되면 임시 ASG를 기존 ASG로 교체합니다.
- 실패 시에는 임시 ASG를 종료하여 롤백합니다.
- 장점:
- Zero 다운타임: 애플리케이션 가용성을 유지합니다.
- 높은 안정성: 배포 중 기존 인스턴스는 그대로 유지됩니다.
- 빠른 롤백: 실패 시 새로운 ASG(Auto Scaling Group)만 종료하면 됩니다.
- 단점:
- 높은 비용: 두 배의 용량을 일시적으로 유지하므로 비용이 증가합니다.
- 긴 배포 시간: 배포가 가장 오래 걸리는 방식입니다.
- 사용 시기:
- 무중단 배포가 필요하고, 높은 안정성이 요구될 때.
- 프로덕션 환경에서 안정적인 배포가 필수적일 때.
2.6 Traffic Splitting
- 트래픽의 일부를 새로운 버전으로 전환하여 테스트한 후, 문제가 없으면 전체 트래픽을 전환하는 방식입니다.
- Canary Testing을 사용하여 새로운 애플리케이션 버전을 동일한 용량의 임시 ASG(Temporary Auto Scaling Group)에 배포합니다.
- 설정된 시간 동안 트래픽의 일부를 임시 ASG로 전환합니다.
- 배포 상태를 지속적으로 모니터링하여, 문제가 발생하면 자동으로 롤백을 수행합니다.
- 배포가 성공적으로 완료되면, 새로운 인스턴스를 임시 ASG에서 원래 ASG(Main Auto Scaling Group)로 마이그레이션하고, 이전 애플리케이션 버전을 종료합니다.
- 장점:
- 단계적으로 새로운 버전을 테스트할 수 있습니다.
- 애플리케이션의 다운타임 없이 배포할 수 있습니다.
- 실패 시 빠르게 롤백할 수 있습니다.
- 단점:
- 트래픽 분할 설정이 필요합니다.
- 두 개의 버전을 동시에 유지해야 하므로 관리가 복잡할 수 있습니다.
- 임시 ASG를 사용함에 따라 소규모 추가 비용이 발생할 수 있습니다.
- 사용 시기:
- 새로운 버전의 안정성을 점진적으로 검증하고자 할 때.
- 애플리케이션의 무중단 배포가 요구될 때.
2.7 비교
| 방법 | 실패한 배포의 영향 | 배포 시간 | 무중단 배포 | DNS 변경 없음 | 롤백 과정 | 코드 배포 위치 |
|---|---|---|---|---|---|---|
| 일괄 배포 (All at once) | 다운타임 | ⏱️ | ❌ | ✔️ | 수동 재배포 | 기존 인스턴스 |
| 롤링 배포 (Rolling) | 단일 배치 서비스 중단; 실패 이전의 성공적인 배치는 유지 | ⏱️⏱️ | ✔️ | ✔️ | 수동 재배포 | 기존 인스턴스 |
| 추가 배치 롤링 배포 (Rolling with an additional batch) | 첫 번째 배치 실패 시 최소화; 그렇지 않으면 롤링과 유사 | ⏱️⏱️⏱️ | ✔️ | ✔️ | 수동 재배포 | 새 인스턴스 및 기존 인스턴스 |
| 변경 불가 배포 (Immutable) | 최소화 | ⏱️⏱️⏱️ | ✔️ | ✔️ | 새 인스턴스 종료 | 새 인스턴스 |
| 트래픽 스플리팅 (Traffic Splitting) | 일시적으로 새로운 버전으로 라우팅된 클라이언트 트래픽의 일부 영향 | ⏱️⏱️⏱️⏱️ | ✔️ | ✔️ | 트래픽 재라우팅 및 새 인스턴스 종료 | 새 인스턴스 |
| 블루/그린 배포 (Blue/Green) | 최소화 | ⏱️⏱️⏱️⏱️ | ✔️ | ❌ | URL 스왑 | 새 인스턴스 |
3 배포 방법 선택 가이드
- 다운타임 허용 여부: 애플리케이션의 다운타임이 허용되는지 여부에 따라 배포 방법을 선택합니다.
- 배포 속도: 빠른 배포가 필요한 경우 All at Once, 안정성이 중요한 경우 Immutable 또는 Blue/Green을 선택합니다.
- 비용 고려: 추가 인스턴스가 필요한 방법은 비용이 증가할 수 있으므로 예산을 고려합니다.
- 롤백 용이성: 롤백이 쉬운 방법을 선호하는 경우 Blue/Green 또는 Immutable을 선택합니다.
참고 자료