[AWS] CI/CD 배포 전략

배포 전략이란?

이 전엔 배포를 하는 것이 수 개월 혹은 수 년에 한 번씩 이루어지는 작업이었다.

최근에는 서비스를 더욱 작게 만들고 빈번히 배포하는 방식으로 변화하고 있다.

→ 변경 사항이 생겼을 때 더 빠르게 반영이 가능하지만 리스크가 존재한다.

→ 그렇기에 배포 전략을 구성해야한다!

배포 전략 종류

• 인플레이스 배포(In-place Deployment)
• 롤링 배포(Rolling Update Deployment)
• 블루/그린 배포(Blue/Green Deployment)
• 카나리 배포(Canary Deployment)

각 배포 전략마다 장점과 단점이 모두 존재하기 때문에 상황에 따라 전략을 선택해야 한다.

---

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

인플레이스 배포는 사용중인 환경에 새로운 변경 사항이 포함된 어플리케이션만 반영하는 방법

<출처 :  https://blog.naver.com/classmethodkr/222540331678 >

애플리케이션을 업데이트하거나 새 버전을 배포할 때 기존 인프라 또는 서버에서 바로 변경을 적용하는 배포 방식이다. 기존 환경에서 애플리케이션의 코드, 구성, 또는 라이브러리를 업데이트하면서 새 버전을 배포하며, 별도의 새로운 서버를 생성하지 않는다.

인플레이스 배포의 주요 특징

1. 동일한 서버에서 배포 진행:
   • 새 버전의 애플리케이션이 기존 서버에서 바로 설치된다.
   • 배포가 완료되면 기존 버전은 제거되거나 덮어씌워진다.
2. 빠른 배포:
   • 추가적인 리소스(예: 새로운 서버) 없이 기존 리소스를 활용하므로 배포 속도가 빠르다.
3. 비용 효율성:
   • 새로운 서버나 환경을 생성하지 않아 비용이 절감된다.
4. 다운타임 발생 가능성:
   • 배포 중에 기존 애플리케이션이 중단될 수 있다.
   • 특별한 조치를 취하지 않는 한, 사용자는 새 버전 배포 동안 서비스 중단을 경험할 가능성이 있다.

장점

• 리소스 절약: 새 환경을 생성할 필요가 없어 리소스 소비가 적다.
• 빠른 업데이트: 배포가 신속하게 이루어질 수 있다.
• 단순성: 관리 및 실행이 상대적으로 간단하다.

단점

• 다운타임 위험: 배포 중 서비스 중단이 발생할 가능성이 있다.
• 롤백의 어려움: 문제가 발생할 경우 이전 버전으로 빠르게 되돌리기가 어렵다.
• 한정된 테스트 환경: 새 버전을 기존 서버에서 직접 실행하므로, 문제가 발생하면 시스템 전체에 영향을 줄 수 있다.

인플레이스 배포의 활용 예시

• 소규모 애플리케이션이나 비즈니스에서, 배포 속도가 중요하고 다운타임의 영향이 적은 경우.
• 개발 또는 테스트 환경에서 간단하게 업데이트를 적용하려는 경우.

---

롤링 배포(Rolling Update Deployment)

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

<출처 : https://blog.naver.com/classmethodkr/222540331678>

롤링 배포의 동작 원리

1. 기존 서버 중 일부(또는 하나)를 선택하여 새 버전으로 업데이트한다.
2. 업데이트된 서버가 정상적으로 작동하는지 확인한다.
3. 확인 후 다음 서버를 업데이트한다.
4. 이 과정을 반복하여 모든 서버가 새 버전으로 전환될 때까지 진행한다.

롤링 배포의 주요 특징

• 점진적 전환:
  • 모든 서버를 동시에 업데이트하지 않고, 여러 단계로 나누어 배포한다.
• 무중단 배포:
  • 다운타임 없이 애플리케이션의 새 버전을 배포할 수 있다.
  • 요청은 새 버전과 기존 버전의 서버로 나뉘어 처리되므로 서비스는 지속된다.
• 자동화 지원:
  • Kubernetes, AWS Elastic Beanstalk 등 많은 배포 도구에서 기본적으로 지원하는 배포 방식이다.

장점

1. 무중단 서비스:
   • 시스템 가용성을 유지하면서 배포를 진행할 수 있다.
2. 점진적 릴리스:
   • 문제가 발생하면 배포를 중단하거나 롤백하기가 용이하다.
3. 리소스 활용:
   • 기존 서버를 활용하므로 추가적인 인프라 비용이 발생하지 않는다.

단점

1. 구버전과 신버전의 공존:
   • 배포 중에 트래픽이 두 버전으로 나뉘어 처리되기 때문에, 상태 비호환성(예: 데이터베이스 스키마 변경)이 발생할 수 있다.
2. 배포 시간 증가:
   • 전체 서버를 업데이트하는 데 시간이 더 오래 걸릴 수 있다.
3. 복잡한 모니터링:
   • 배포 중에 신/구 버전 간의 성능 및 오류를 모니터링해야 하므로 복잡성이 증가한다.

---

블루/그린 배포(Blue/Green Deployment)

<출처 :  https://blog.naver.com/classmethodkr/222540331678 >

블루/그린 배포는 애플리케이션 배포 전략 중 하나로, 두 개의 독립된 환경을 사용하여 애플리케이션의 새 버전을 무중단으로 배포하는 방법이다. 기존 버전(블루)과 새 버전(그린)을 별도의 환경에서 운영한 뒤, 안정성을 확인하고 트래픽을 새 버전(그린)으로 전환하는 방식이다.

동작 원리

1. 블루 환경:
   • 기존에 운영 중인 애플리케이션이 배포된 환경이다.
   • 사용자 트래픽을 처리하고 있는 환경이다.
2. 그린 환경:
   • 새 버전의 애플리케이션이 배포될 별도의 환경이다.
   • 기존 환경과 동일한 구조를 가지며, 새 버전이 이곳에서 테스트된다.
3. 트래픽 전환:
   • 새 버전(그린)이 안정적으로 작동한다고 판단되면, 트래픽을 블루 환경에서 그린 환경으로 전환한다.
   • 일반적으로 로드 밸런서를 통해 트래픽을 조정한다.
4. 롤백 지원:
   • 문제가 발생하면 트래픽을 다시 블루 환경으로 전환하여 빠르게 롤백할 수 있다.

블루/그린 배포의 장점

1. 무중단 배포:
   • 블루와 그린 환경이 독립적이므로, 다운타임 없이 배포가 가능하다.
2. 빠른 롤백:
   • 문제가 발생하면 트래픽만 블루 환경으로 다시 전환하면 되므로 롤백이 빠르다.
3. 테스트 환경 제공:
   • 그린 환경에서 실제와 동일한 조건으로 새 버전을 테스트할 수 있다.

블루/그린 배포의 단점

1. 리소스 비용:
   • 두 개의 환경을 운영해야 하므로, 인프라 비용이 증가할 수 있다.
2. 데이터 동기화:
   • 상태 데이터(예: 데이터베이스)가 있는 경우, 블루와 그린 환경 간 동기화가 필요하여 복잡도가 증가한다.
3. 전환 리스크:
   • 트래픽 전환 시 문제 발생 가능성(예: 캐시 충돌, 세션 문제 등)이 존재한다.

레드/블랙 배포와의 차이점

레드/블랙 배포는 본질적으로 블루/그린 배포와 동일한 개념을 다른 이름으로 부르는 것이다.

• 레드/블랙이라는 이름은 Netflix에서 이 배포 방식을 사용할 때 붙인 용어로, 배포 전략의 이름만 다를 뿐 구조와 동작 방식은 동일하다.
• 블루/그린에서 사용되는 환경이 레드와 블랙으로 이름만 변경된 것으로, 실제 배포 프로세스와 이점/제한은 같다.
• 일반적으로 “구 버전의 환경을 새 버전의 환경으로 똑같이 구축해서 합 번에 전환한다.” 라고 생각하는 것은 Red/Black 배포의 정의이다. 그래서 실제로 Blue/Green 배포는 “신 버전과 구 버전의 어플리케이션이 한 순간이라도 공존하였다.” 라고 하는 것이 옳다.
  • 다만 레드/블랙 배포에 대한 정의는 사람마다 매우 다양하기에 모호하다.

---

카나리 배포(Canary Deployment)

<출처 :  https://blog.naver.com/classmethodkr/222540331678 >

카나리 배포는 애플리케이션의 새 버전을 점진적으로 배포하여, 초기에는 소수의 사용자에게만 새 버전을 제공한 뒤 문제가 없을 경우 점차 모든 사용자로 확대하는 배포 전략이다.

이 방식의 이름은 과거 광산에서 유해 가스를 감지하기 위해 카나리아를 사용했던 사례에서 유래되었다. 소규모 사용자 그룹이 초기 테스트 역할을 하며, 안전성이 확인되면 전체로 확장하는 방식이다.

카나리 배포의 동작 원리

1. 새 버전 배포:
   • 소규모의 서버나 사용자 그룹을 대상으로 새 버전을 배포한다.
   • 이 소규모 그룹은 전체 트래픽의 일부를 처리한다.
2. 모니터링 및 검증:
   • 새 버전의 안정성과 성능을 모니터링한다.
   • 오류, 성능 문제, 사용자 피드백 등을 평가한다.
3. 확장:
   • 새 버전이 안정적이라 판단되면 트래픽 비율을 점진적으로 늘려가며 확대 배포한다.
   • 최종적으로 모든 트래픽이 새 버전으로 처리되게 한다.
4. 롤백 옵션:
   • 문제가 발생하면 소규모 그룹에서만 영향을 받으므로 빠르게 이전 버전으로 롤백할 수 있다.

카나리 배포의 주요 특징

• 점진적 배포:
  • 한 번에 전체 사용자에게 배포하지 않고, 단계적으로 배포한다.
• 빠른 피드백:
  • 초기 사용자 그룹을 통해 새 버전에 대한 피드백을 신속하게 얻을 수 있다.
• 리스크 관리:
  • 새 버전의 문제가 전체 사용자에게 영향을 미치지 않도록 제한한다.

장점

1. 안정성 확보:
   • 소규모 사용자 그룹으로 시작하여 문제를 미리 감지할 수 있다.
2. 빠른 롤백:
   • 문제가 발생해도 소수의 사용자에게만 영향을 미치므로 롤백이 쉽다.
3. 효율적인 리소스 활용:
   • 별도의 새로운 환경이 필요하지 않으며 기존 인프라를 활용할 수 있다.

단점

1. 복잡성 증가:
   • 트래픽 조정, 모니터링, 확장 관리를 위한 추가적인 도구와 설정이 필요하다.
2. 데이터 불일치 가능성:
   • 구 버전과 신 버전이 동시에 운영되므로 데이터의 일관성을 유지하는 데 어려움이 있을 수 있다.
3. 모니터링 부담:
   • 새 버전의 안정성을 평가하고 문제가 발생할 경우 적시에 조치해야 하므로 지속적인 모니터링이 필요하다.

1.