[Container 이론] 7. 배포(Deployment)의 3가지 방식

목차

1. Blue/Green
2. canary
3. rolling update

---

Blue/Green 배포

블루-그린 배포는 로드 밸런서, Kubernetes와 같은 컨테이너 오케스트레이션 플랫폼 또는 자동화된 배포 파이프라인을 비롯한 다양한 기술을 사용하여 구현할 수 있습니다. 핵심은 모든 문제에 대해 애플리케이션을 모니터링하면서 이전 버전에서 새 버전으로 트래픽을 점진적으로 전환하는 방법을 갖는 것입니다.

 

이 방식은 새 버전의 소프트웨어 애플리케이션을 릴리스하는 데 사용되는 배포 전략입니다. 이 접근 방식에서는 애플리케이션의 새 버전이 이전 버전과 함께 배포되지만 처음에는 트래픽이 이전 버전으로만 전달됩니다. 새 버전이 테스트되고 안정적인 것으로 확인되면 트래픽을 완전히 제공하고 이전 버전이 더 이상 필요하지 않을 때까지 트래픽이 점차 새 버전으로 이동됩니다.

"블루-그린 배포"라는 이름은 응용 프로그램의 이전 버전을 "블루" 버전이라고 하고 새 버전을 "그린" 버전이라고 한다는 사실에서 유래되었습니다. 이 접근 방식은 기존 배포 방법에 비해 다음과 같은 몇 가지 이점을 제공합니다.

• 장점
  
  1. 가동 중지 시간 최소화
     블루-그린 업데이트를 사용하면 트래픽이 전환되기 전에 새 버전이 이전 버전과 함께 배포되므로 가동 중지 시간이 최소화됩니다.
     
     
  2. 손쉬운 롤백
     새 버전에서 문제가 감지되면 두 버전이 동시에 실행되므로 이전 버전으로 쉽게 롤백할 수 있습니다.
     
     
  3. 위험 감소
     애플리케이션의 두 버전이 동시에 실행되기 때문에 사용자에게 영향을 미치는 문제나 오류의 위험이 줄어듭니다.
• 단점
  
  1. 비용
     두 버전의 애플리케이션을 동시에 배포하고 실행해야 하므로 블루-그린 업데이트에는 더 높은 인프라 비용이 필요합니다.
     
     
  2. 복잡성
     두 개의 별도 배포를 관리하는 것은 단일 배포를 관리하는 것보다 더 복잡할 수 있습니다.

---

작동 방식예시

1. 웹 애플리케이션 시나리오에서 애플리케이션의 프런트 엔드 코드를 업데이트한다고 가정합니다. 블루-그린 배포를 사용하면 프런트 엔드 코드의 새 버전("녹색" 버전)을 만들고 기존 버전("청색" 버전)과 함께 배포합니다. 트래픽은 처음에 녹색 버전이 테스트되는 동안 파란색 버전으로 전달됩니다. 그린 버전이 철저히 테스트되면 트래픽이 완전히 처리되고 블루 버전이 해제될 수 있을 때까지 트래픽이 점차 그린 버전으로 전환됩니다.
   
   
2. 마이크로서비스 아키텍처에는 애플리케이션을 제공하기 위해 함께 작동하는 여러 서비스가 있을 수 있습니다. 블루-그린 배포를 사용하면 이전 버전("블루" 버전)을 계속 실행하면서 각 서비스를 한 번에 하나씩 새 버전("그린" 버전)으로 업데이트합니다. 모든 서비스가 업데이트되면 트래픽을 완전히 처리하고 이전 버전이 더 이상 필요하지 않을 때까지 트래픽이 새 버전으로 전환됩니다.
   
   
3. 클라우드 인프라 환경에서는 고가용성을 보장하기 위해 실행 중인 애플리케이션의 여러 인스턴스가 있을 수 있습니다. 블루-그린 배포를 사용하면 기존 인스턴스("파란색" 인스턴스)와 함께 새 버전의 애플리케이션("녹색" 인스턴스)으로 새 인스턴스 세트를 생성합니다. 트래픽은 처음에 녹색 인스턴스가 테스트되는 동안 파란색 인스턴스로 전달됩니다. 녹색 인스턴스가 철저히 테스트되면 트래픽을 완전히 처리하고 파란색 인스턴스를 폐기할 수 있을 때까지 트래픽이 점차 녹색 인스턴스로 전환됩니다.

블루-그린 배포를 통해 다운타임이나 사용자 중단 없이 새 버전으로 원활하게 전환할 수 있습니다. 또한 문제 발생 시 빠른 롤백을 허용하여 높은 수준의 안정성과 가용성을 보장합니다.

---

Blue/Green 배포 방식을 사용하는 기업

• Netflix
  Netflix는 블루-그린 배포를 사용하여 새 버전의 소프트웨어를 배포하는 것으로 유명합니다. 예를 들어 스트리밍 서비스를 업데이트할 때 이전 버전("파란색" 서버)과 함께 새로운 서버 집합("녹색" 서버)에 새 버전을 배포합니다. 그린 서버가 완전히 테스트되고 작동되면 트래픽을 완전히 처리할 때까지 트래픽이 점진적으로 이동되며 블루 서버는 해제될 수 있습니다.
  
  
• AWS
  AWS Elastic Beanstalk는 블루-그린 배포 접근 방식을 사용하여 애플리케이션에 업데이트를 배포합니다. 업데이트된 버전의 애플리케이션을 위한 새 환경을 생성하고 트래픽을 완전히 제공할 때까지 점진적으로 트래픽을 라우팅하며 문제가 발생할 경우 이전 환경이 계속 실행됩니다.

---

Canary(카나리/카나리아) 배포

카나리 배포는 사용자 또는 서버의 작은 하위 집합이 나머지 사용자 또는 서버보다 먼저 새 버전의 애플리케이션으로 업데이트되는 배포 기술입니다. 이를 통해 더 많은 청중에게 배포하기 전에 라이브 환경에서 새 버전을 테스트할 수 있습니다.

"카나리"라는 이름은 유독 가스에 대한 조기 경보 시스템으로 탄광에서 카나리를 사용하는 관행에서 유래되었습니다. 마찬가지로 소프트웨어 개발에서 카나리 배포는 애플리케이션의 새 버전과 관련된 문제나 오류에 대한 조기 경고 시스템 역할을 합니다.

카나리 배포는 사용자 또는 서버의 하위 집합에 새 릴리스를 점진적으로 롤아웃하고 나머지 사용자 또는 서버에 대해 기존 버전을 계속 실행하여 통제된 방식으로 새 소프트웨어 릴리스를 테스트하는 데 사용되는 기술입니다.

• 장점
  
  1. 위험 감소
     카나리 업데이트를 사용하면 모든 사용자에게 배포하기 전에 더 작은 사용자 또는 서버 하위 집합에서 새로운 기능이나 업데이트를 테스트할 수 있으므로 모든 사용자에게 영향을 미치는 문제나 오류의 위험을 줄일 수 있습니다.
     
     
  2. 초기 피드백
     사용자 또는 서버의 더 작은 하위 집합에서 새 업데이트를 테스트함으로써 조직은 모든 ​​사람에게 배포되기 전에 새 버전에 대한 초기 피드백을 받을 수 있습니다.
     
     
  3. 손쉬운 롤백
     새 버전에서 문제가 감지되면 일부 사용자 또는 서버만 영향을 받았기 때문에 이전 버전으로 쉽게 롤백할 수 있습니다.
• 단점
  
  1. 복잡성
     여러 배포를 관리하는 것은 단일 배포를 관리하는 것보다 더 복잡할 수 있습니다.
     
     지연된 롤아웃
     새 버전은 일부 사용자 또는 서버에만 롤아웃되므로 모든 사용자 또는 서버에 대한 롤아웃이 지연될 수 있습니다.

카나리 배포는 트래픽 분할, 기능 플래그 또는 점진적 롤아웃과 같은 다양한 기술을 사용하여 구현할 수 있습니다. 핵심은 애플리케이션의 성능을 모니터링하면서 애플리케이션을 점진적으로 업데이트하고 필요한 경우 신속하게 롤백하는 방법을 갖추는 것입니다.

---

작동 방식 예시

1. 많은 사용자에게 서비스를 제공하는 웹 애플리케이션이 있고 새 기능을 릴리스하려고 합니다. 한 번에 모든 사용자에게 기능을 릴리스하는 대신 카나리 배포를 사용하여 사용자 하위 집합에서 새 기능을 테스트하기로 결정합니다.
   
   
2. 소수의 사용자(예: 5%)를 카나리 그룹의 일부로 식별하고 나머지 사용자는 애플리케이션의 기존 버전을 계속 사용합니다.
   
   
3. 새 버전의 애플리케이션을 서버의 하위 집합에 배포하고 사용자 비율에 따라 애플리케이션의 이전 버전과 새 버전 모두에 트래픽을 전달하도록 로드 밸런서를 구성합니다.
   
   
4. 사용자가 사이트를 방문함에 따라 로드 밸런서는 애플리케이션의 새 버전으로 이동하는 사용자 비율을 점진적으로 늘립니다.
   
   
5. 새 버전의 애플리케이션을 주의 깊게 모니터링하여 문제나 오류가 없는지 확인합니다.
   
   
6. 문제가 감지되면 신속하게 배포를 롤백하고 모든 사용자를 이전 버전으로 다시 리디렉션할 수 있습니다.
   
   
7. 새 버전이 완전히 테스트되고 안정적인 것으로 확인되면 새 버전으로 이동하는 사용자 비율을 늘려 모든 사용자에게 점진적으로 새 기능을 출시할 수 있습니다.

카나리 배포를 통해 모든 사용자에게 한 번에 영향을 주지 않고 통제된 환경에서 새로운 기능을 테스트할 수 있습니다. 또한 문제 발생 시 빠른 롤백을 허용하여 높은 수준의 안정성과 가용성을 보장합니다.

---

Canary 배포 방식을 사용하는 기업

• Facebook
  Facebook은 카나리 배포를 사용하여 소프트웨어의 새 버전을 모든 사용자에게 배포하기 전에 소수의 사용자에게 테스트합니다. 예를 들어 모바일 앱을 업데이트할 때 소규모 사용자 하위 집합에 새 버전을 출시하고 더 많은 사용자에게 점진적으로 출시하기 전에 피드백을 모니터링할 수 있습니다.
  
  
• LinkedIn
  LinkedIn은 카나리 배포를 사용하여 웹 사이트의 새 버전을 테스트합니다. 새 버전을 서버의 하위 집합에 배포하고 점진적으로 트래픽을 해당 서버로 라우팅하면서 나머지 서버에서 이전 버전을 계속 실행합니다. 이를 통해 모든 사용자에게 릴리스하기 전에 실제 환경에서 새 버전을 테스트할 수 있습니다.

---

Rolling Update 배포

롤링 업데이트 배포는 배포 프로세스 중에 응용 프로그램을 실행하고 사용자가 사용할 수 있도록 유지하면서 이전 버전에서 새 버전으로 원활하고 점진적으로 전환할 수 있는 소프트웨어 응용 프로그램을 업데이트하기 위한 전략입니다.

롤링 업데이트 배포는 애플리케이션에 대한 트래픽을 관리하기 위해 로드 밸런서 또는 기타 기술과 함께 자주 사용됩니다. 롤링 업데이트 배포의 주요 이점은 새 버전이 완전히 배포되어 작동할 때까지 애플리케이션의 이전 버전을 계속 사용할 수 있기 때문에 사용자의 중단 및 중단 시간을 최소화한다는 것입니다.

 

롤링 업데이트를 사용하면 업데이트 프로세스 중에 애플리케이션을 실행하고 사용자가 사용할 수 있도록 유지하면서 애플리케이션의 이전 버전에서 새 버전으로 원활하고 점진적으로 전환할 수 있습니다. 새 버전을 한 번에 서버 하위 집합에 배포하고 성능을 면밀히 모니터링함으로써 조직은 모든 ​​사용자 또는 서버에 한 번에 영향을 미치는 문제나 오류의 위험을 최소화할 수 있습니다.

• 장점
  
  1. 가동 중지 시간 최소화
     롤링 업데이트를 통해 상당한 가동 중지 시간이나 사용자 중단 없이 점진적으로 업데이트를 배포할 수 있습니다.
     
     
  2. 손쉬운 롤백
     새 버전에서 문제가 감지되면 두 버전의 애플리케이션이 동시에 실행되므로 이전 버전으로 쉽게 롤백할 수 있습니다.
     
     
  3. 비용 효율적
     한 번에 한 버전의 애플리케이션만 실행되므로 롤링 업데이트는 인프라 비용이 적게 듭니다.
     
     
• 단점:
  
  1. 더 긴 배포 시간
     새 버전이 모든 서버에 롤아웃되기 전에 서버 하위 집합에 점진적으로 배포되므로 롤링 업데이트를 배포하는 데 시간이 더 오래 걸릴 수 있습니다.
     
     
  2. 문제 위험
     새버전이 점진적으로 배포되기 때문에 배포 과정에서 사용자에게 영향을 미치는 문제 또는 오류의 위험이 있습니다.

---

작동 방식 예시

1. 애플리케이션의 새 버전을 준비하여 시작합니다. 여기에는 코드 변경, 새 기능 추가 또는 라이브러리 또는 종속성 업데이트가 포함될 수 있습니다.
   
   
2. 나머지 서버에서 실행 중인 이전 버전을 유지하면서 서버의 하위 집합에 새 버전을 배포합니다. 로드 밸런서를 사용하여 애플리케이션의 이전 버전과 새 버전 간에 트래픽을 라우팅할 수 있습니다.
   
   
3. 새 버전의 애플리케이션으로 전달되는 트래픽 비율을 점진적으로 늘립니다. 예를 들어 트래픽의 10%를 새 버전으로 보낸 다음 20%, 50% 등으로 늘릴 수 있습니다.
   
   
4. 애플리케이션의 새 버전을 주의 깊게 모니터링하여 문제나 오류가 없는지 확인하십시오. 문제가 감지되면 신속하게 배포를 롤백하고 트래픽을 이전 버전으로 다시 리디렉션할 수 있습니다.
   
   
5. 새 버전이 완전히 테스트되고 안정적인 것으로 확인되면 모든 트래픽을 새 버전으로 리디렉션하고 이전 버전을 폐기할 수 있습니다.

롤링 업데이트를 사용하면 중단 시간이나 사용자 중단 없이 새 버전으로 원활하게 전환할 수 있습니다. 또한 문제 발생 시 빠른 롤백을 허용하여 높은 수준의 안정성과 가용성을 보장합니다.

---

Rolling Update 배포를 사용하는 기업

Google
Google은 롤링 업데이트를 자주 사용하여 새 버전의 서비스를 배포합니다. 예를 들어 검색 엔진 알고리즘을 업데이트할 때 서버의 하위 집합에 새 버전을 점진적으로 롤아웃하고 나머지 서버에서는 이전 버전을 계속 실행합니다. 이를 통해 Google은 새 버전을 면밀히 모니터링하고 문제나 버그를 식별하며 필요한 경우 신속하게 배포를 롤백할 수 있습니다. 새 버전이 완전히 테스트되고 안정적인 것으로 확인되면 모든 서버에 출시됩니다.

---

이 글을 읽고 배포 방법을 결정할 때 유의할 점은 "Google이 쓰니까 이게 더 좋은거야"라는 생각은 금물이라는 것 입니다. 각자가 맡은 프로젝트가 어떤 것인지 잘 파악하고, 어떤 방식으로 진행하는것이 더 효율적이고 비용절감이 가능할지 생각하는게 먼저가 되야합니다.