AWS CodeDeploy & 배포 전략

배포 전략

• 인-플레이스 배포(In-place Deployment)

  여러 개의 가동중인 서버 (인스턴스)를 갖춘 환경에서 한 번에 정해진 수만큼의 서버에 새로운 변경 사항이 포함된 애플리케이션을 배포하는 방법 이다.

  

  이 방식을 사용하는 대표적인 서비스가 AWS CodeDeploy 이다. 배포 그룹의 각 환경(인스턴스)에 있는 애플리케이션을 일시정지한 후, 최신 상태의 애플리케이션의 변경 사항이 설치 되면 새 버전의 앱을 실행하는 형식으로 이루어진다. 로드 밸런서(LB)를 사용하면 각 인스턴스가 배포중이라고 해도 등록을 해제할 수 있으며, 배포 완료 후에 이전 버전으로 복원도 가능 하다.

  이 인-프레이스 배포 방식 상 EC2, 온-프레미스 환경에만 사용 가능한 배포 전략이 된다.

  • 요약하자면, 여러 가동 중인 서버(인스턴스) 에서 일부에 새 애플리케이션 버전을 배포하는 방식입니다. AWS CodeDeploy 서비스에서 이 전략을 사용합니다. 배포 그룹 내 각 인스턴스에서 기존 앱을 중지하고 새 버전을 설치/실행합니다. 로드밸런서를 사용하면 배포 중 인스턴스를 제외할 수 있고, 이전 버전으로 롤백도 가능합니다. 단, EC2, 온-프레미스 환경에서만 가능한 배포 전략입니다.

---

• 롤링 배포(Rolling Update Deployment)

  여러 개의 가동중인 서버(인스턴스)를 갖춘 환경에서 한 번에 정해진 수만큼의 서버에 새로운 변경 사항이 포함된 애플리케이션을 배포하는 방법

  

  구 버전에서 새 버전으로 트래픽을 점진적으로 전환하며, 구 버전의 인스턴스도 점차 삭제 된다. 그렇기 때문에 서버 수의 제약이 있을 경우에는 유용한 방법이 될 수 있지만 배포 중 인스턴스의 수가 감소 되기 때문에 서버 처리 용량을 미리 고려해야 한다. 이 방식을 사용하고 있는 서비스는 AWS Elastic Beanstalk와 CodeDeploy 이다. CodeDeploy 는 공식 문서에서 직접적으로 서술된 부분이 없기 때문에 알기 어렵지만 기본적으로 롤링 배포를 하도록 설정 되어 있다. 그래서 EC2, 온-프레미스의 경우, 인-플레이스 배포가 롤링 배포와 혼합된 방식을 따르고 있고, Lambda나 ECS의 경우는 롤링 배포가 기본적인 배포 방식이 된다고 이해하면 될 것 이다.

  덤으로 Elastic Beanstalk의 배포 방법을 보면, 롤링이 그냥 롤링과 추가 배치를 사용한 롤링으로 나뉘게 되는데, 둘 다 구 버전에서 새 버전으로 점진적으로 전환되는 것은 동일하지만, 추가 배치를 사용한 롤링의 경우는 새 버전의 인스턴스를 배포한 후 바로 시작하여 배포 프로세스 중에도 모든 용량이 유지 되도록 한다.

  • 요약하자면, 롤링 배포(Rolling Update Deployment) 는 서버 환경에서 인스턴스 수를 점진적으로 업데이트하며 새 애플리케이션 버전으로 전환하는 방식입니다. 기존 버전의 인스턴스를 점차 삭제하면서 새 버전으로 트래픽을 이동시킵니다. 서버 수가 제한적일 때 유용하지만, 배포 중 전체 인스턴스 수가 감소하므로 처리 용량을 고려해야 합니다. AWS Elastic Beanstalk와 CodeDeploy에서 이 방식을 기본적으로 사용하는데, CodeDeploy는 EC2/온프레미스의 경우 인-플레이스 배포와 혼합되고, Lambda나 ECS에서는 롤링 배포가 기본입니다. Elastic Beanstalk의 롤링에는 일반 롤링과 추가 배치 롤링이 있는데, 둘 다 점진적 전환이지만 추가 배치 방식은 배포 중에도 전체 용량을 유지합니다.

---

• 블루/그린(Blue/Green Deployment)

  새로운 변경사항이 포함된 애플리케이션을 위한 새로운 환경을 구축하고 교체하는 방법 이다.

  

  흔히 Blue/Green 배포를 “구 버전의 환경을 새 버전의 환경으로 똑같이 구축하여 한 번에 전환 한다” 라고 생각할 수도 있다. 사실 이것은 Red/Black 배포의 정의 이다. 그래서 실제로는 “신 버전과 구 버전의 애플리케이션이 한 순간이라도 공존하였다” 라고 하는 것이 더 올바르다.

  Blue/Green 배포는 하나의 버전만 프로덕션 되기 때문에 버전 관리 문제를 방지할 수 있고, 운영 환경에 영향을 주지 않고 실제 서비스 환경으로 새 버전 테스트가 가능 하게 된다.

  그리고, 주로 인-플레이스 배포와 비교될 때 언급되는 장점으로 새 버전으로 전환 후에 문제가 생겼을 시 구 버전으로 되돌리기 위한 롤백도 인-플레이스 배포 보다 더 빠르다는 장점이 있다.

  단, 구 버전과 새 버전 두 환경 모두 갖출 필요가 있기 때문에 시스템 자원이 두 배로 필요해지며, 비용이 그 만큼 비싸지기 때문에 비용을 고려한 구성이 필요 하다. 이런 단점은 AWS와 같은 클라우드 서비스에서는 종량 과금이라는 메리트가 있어 큰 부담 요소로 작용 되지 않으니 신경 안 써도 될 것 이다.

  Blue/Green 배포도 Elastic Beanstalk, CodeDeploy에서 이 방식을 사용할 수 있다.

  • 요약하자면, 블루/그린 배포(Blue/Green Deployment) 는 새 애플리케이션 버전을 위해 별도의 환경을 구축한 후, 기존 환경을 교체하는 방식입니다. 새 버전과 기존 버전이 잠깐 공존하는 것이 특징입니다. 이를 통해 버전 관리 문제를 방지하고 실제 환경에서 새 버전을 테스트할 수 있습니다. 인-플레이스 배포에 비해 롤백이 더 빠른 장점이 있지만, 두 개의 환경이 필요해 자원 비용이 두 배가 되는 단점이 있습니다. 다만 AWS 같은 클라우드 서비스에서는 종량제 과금으로 부담이 적습니다. Elastic Beanstalk와 CodeDeploy에서 이 방식을 사용할 수 있습니다.

---

• 카나리 배포(Canary Deployment)

  가동 중인 서버들의 일부에만 새로운 앱을 배포하여, 일부 트래픽을 새 버전의 환경으로 분산 하는 방법 이다.

  

  A/B 테스트가 가능 하고, 오류율 및 성능 모니터링에 유용하게 사용할 수 있다는 장점이 있다.

  트래픽을 분산시킬 라우팅은 임의적 또는 사용자 프로필 등을 기반으로 분류할 수 있다. 분산 후 결과에 따라 새 버전이 운영 환경을 대체할 수도 있고, 다시 구 버전으로 되돌릴 수도 있다.

  이 방법을 사용하는 가장 대표적인 서비스는 API Gateway 인데, 사실 API Gateway 외에 카나리 방식이 언급된 서비스가 하나 있다. 바로 CodeDeploy 이다. Blue/Green 배포의 배포 설정 타입의 종류 중 하나로 분류 되어 있다.

  위의 Blue/Green 배포 설명에서 “구 버전의 환경을 새 버전의 환경으로 똑같이 구축해서 한 번에 전환 한다” 라는 게 올바른 정의가 아니라고 했는데, Blue/Green 배포의 트래픽 전환 방식은 All-at-Once(한 번에)만 있는게 아니기 때문 이다.

  • 요약하자면, 카나리 배포(Canary Deployment) 는 가동 중인 서버의 일부에만 새 애플리케이션 버전을 배포하고, 일부 트래픽을 새 버전 환경으로 분산하는 방식입니다. 이를 통해 A/B 테스트와 오류율, 성능 모니터링이 가능합니다. 트래픽 분산은 임의적이거나 사용자 프로필 기반으로 할 수 있습니다. 결과에 따라 새 버전을 완전히 배포하거나 기존 버전으로 돌아갈 수 있습니다. 대표적인 서비스로 API Gateway가 있으며, CodeDeploy의 Blue/Green 배포 설정 타입 중 하나입니다. Blue/Green 배포의 트래픽 전환 방식은 All-at-Once 외에도 다른 옵션이 있습니다.

    • 옵션

      • All-at-Once: 카나리 배포 방식에서 All-at-Once 옵션을 선택하면 기존 버전의 트래픽을 한번에 모두 새 버전으로 전환하게 됩니다.

      • 리니어(Linear): 트래픽이 동일한 증분으로 이동하며, 각 증분 간 시간 간격이 동일합니다. 각 증분에서 이동할 트래픽 비율(%)과 각 증분 간의 시간 간격(분)을 지정하는 사전 정의된 선형 옵션입니다.

      • 카나리(Canary): 트래픽의 일부만 새 버전 환경으로 분산되어 모니터링 후 결과에 따라 전체 트래픽 전환 여부를 결정하는 옵션입니다.

---

CodeDeploy란

CodeDeploy는 AWS EC2 인스턴스, 온-프레미스 인스턴스, 서버리스 Lambda 함수 또는 AWS ECS 서비스로 애플리케이션 배포를 자동화 하는 배포 서비스

다양한 애플리케이션 콘텐츠를 배포할 수 있다.

• 코드
• 서버리스 AWS Lambda 함수
• 웹 및 구성 파일
• Executables
• 패키지
• 스크립트
• 멀티미디어 파일

CodeDeploy는 서버에서 실행되고 AWS S3 버킷, GitHub Repo 또는 Bitbucket Repo에 저장되는 애플리케이션 콘텐츠를 배포할 수 있다.

또한 CodeDeploy는 서버리스 Lambda 함수를 배포할 수 있다.

CodeDeploy를 사용하기 위해 기존 코드를 변경할 필요가 없다.

CodeDeploy를 사용하면 다음 작업을 쉽게 수행할 수 있다.

• 새 기능을 신속하게 출시
• AWS Lambda 함수 버전 업데이트
• 애플리케이션 배포 시 가동 중지 방지
• 오류가 발생하는 수동 배포와 관련된 다양한 위험 없이 애플리케이션 업데이트에 따른 복잡성 처리.

이 서비스는 인프라와 함께 규모를 조정할 수 있으므로 인스턴스 하나 또는 수천 개에 쉽게 배포할 수 있다.

• CodeDeploy 이점

  • 서버, 서버리스 및 컨테이너 애플리케이션 : CodeDeploy를 사용하면 서버 상의 기존 애플리케이션과 서버리스 AWS Lambda 함수 버전 또는 AWS ECS 애플리케이션을 배포하는 애플리케이션을 모두 배포할 수 있다.

  • 배포 자동화 : CodeDeploy는 개발, 테스트 및 프로덕션 환경에 걸쳐 애플리케이션 배포를 완전 자동화 한다. 그리고 CodeDeploy는 인프라에 맞춰 규모를 조정할 수 있으므로 인스턴스 하나 또는 수천 개에 배포할 수 있다.
  • 가동 중지 최소화 : 애플리케이션이 EC2/온프레미스 컴퓨팅 플랫폼을 사용하는 경우 CodeDeploy는 애플리케이션 가용성을 극대화 한다. 인-플레이스(In-place) 배포에서 CodeDeploy는 AWS EC2 인스턴스 전체에 대해 롤링 업데이트를 수행 한다. 업데이트 시 오프라인 상태가 될 수 있는 인스턴스 수를 지정할 수 있다. 블루/그린 배포 시에는 최신 애플리케이션 수정이 대체 인스턴스에 설치 된다. 선택한 경우 새로운 환경 테스트를 완료한 직후 이러한 인스턴스로 트래픽이 다시 라우팅 된다. 두 가지 배포 유형에 대해 CodeDeploy는 사용자가 구성한 규칙에 따라 애플리케이션 상태를 추적 한다.
  • 중지 및 롤백 : 오류가 있는 경우 자동 또는 수동으로 배포를 중지하고 롤백할 수 있다.
  • 중앙 집중식 제어 : CodeDeploy 콘솔 또는 AWS CLI를 통해 배포 상태를 시작 및 추적할 수 있다. 각 애플리케이션 개정이 배포된 시점 및 AWS EC2 인스턴스가 나열된 보고서가 제공 된다.
  • 채택 편의성 : CodeDeploy는 플랫폼과 관련된 제약이 없으므로 모든 애플리케이션과 작동 한다. 사용자는 설정 코드를 쉽게 재사용할 수 있다. 또한 CodeDeploy는 소프트웨어 릴리즈 프로세스 또는 지속적 전달 도구 체인과 통합이 가능 하다.
  • 동시 배포 : EC2/온-프레미스 컴퓨팅 플랫폼을 사용하는 1개 이상의 애플리케이션이 있는 경우에는 CodeDeploy를 통해 동일한 인스턴스 세트에 동시에 배포할 수 있다.

• CodeDeploy 컴퓨팅 플랫폼 개요

  • CodeDeploy는 세 가지 컴퓨팅 플랫폼에 애플리케이션을 배포할 수 있다.

    • EC2/온-프레미스 : 물리적 서버의 인스턴스를 설명 한다. AWS EC2 클라우스 인스턴스나 온-프레미스 서버 또는 둘 다일 수 있다. EC2/온-프레미스 컴퓨팅 플랫폼을 사용하여 만든 애플리케이션은 실행 파일과 구성 파일, 이미지 및 기타 항목으로 구성될 수 있다. EC2/온-프레미스 컴퓨팅 플랫폼을 사용하는 배포에서는 인 플레이스 또는 블루/그린 배포 유형을 사용하여 인스턴스로 트래픽을 전송되는 방식을 관리 한다.
    • AWS Lambda : 업데이트 버전의 Lambda 함수로 구성된 애플리케이션을 배포하는 데 사용 된다. AWS Lambda는 고가용성 컴퓨팅 구조의 서버리스 컴퓨팅 환경에서 Lambda 함수를 관리 한다. 컴퓨팅 리소스에 대한 모든 관리는 AWS Lambda를 통해 수행 된다.
    • AWS ECS : AWS ECS 컨테이너화된 애플리케이션을 작업 세트로 배포하는 데 사용 된다. CodeDeploy는 애플리케이션의 업데이트 버전을 새로운 대체 작업 세트로 설치하여 블루/그린 배포를 수행 한다. CodeDeploy는 프로덕션 트래픽을 원래 애플리케이션 작업 세트에서 대체 작업 세트로 다시 라우팅 한다. 배포가 성공하면 기존 작업 세트는 종료가 된다.