[0425] 배포 자동화 - 배포 전략

학습 목표

• 배포 자동화의 정의와 이점에 대해 설명할 수 있다.
• 배포 파이프라인이 무엇인지 정의할 수 있다.
• 파이프라인을 구성하는 단계(Stages)와 작업(Actions)에 대해 설명할 수 있다.
• AWS 개발자 도구를 활용하여 파이프라인을 구축할 수 있다.
• 배포 자동화 파이프라인 구축 과정에서 문제가 발생할 경우, log 파일과 공식 문서를 통해 해결할 수 있다.
• 다양한 배포 전략 (롤링, 블루/그린, 카나리)을 이해할 수 있다.

---

블루/그린 배포

---

• 애플리케이션 또는 마이크로서비스의 이전 버전에 있던 사용자 트래픽을 이전 버전과 거의 동일한 새 버전으로 점진적으로 이전하는 애플리케이션 릴리스 모델
• 필요한 이유
  • 배포를 자동화할 때 겪는 어려움 중 하나는 소프트웨어를 최종 테스트 단계에서 실제 프로덕션 단계로 전환하는 컷오버 자체
  • 일반적으로 다운타임을 최소화하려면 이 작업을 신속하게 수행해야 함
  • 블루/그린 배포는 가능한 동일한 두 가지 프로덕션 환경을 확보함으로써 이를 실현시킬 수 있음
  • 컷오버(cutover): 기존에 운영되던 환경을 중단시키고, 새로 구축된 환경으로 오픈하는 것
  • 다운타임(downtime): 시스템을 이용할 수 없는 시간

• 배포 방식
  • blue를 실제 운영 중인 환경으로 가정
  • 새로운 버전을 릴리스 하고 싶은 경우 green 환경에서 테스트 진행
  • 테스트가 정상 완료 된다면 blue 환경에서 들어가던 모든 요청을 green 환경으로 변경
  • 이후 blue는 이전 green 환경의 역할을 가져감과 동시에 green이 잘 동작하지 않을 때 사용할 수 있는 백업 서버로의 역할도 수행이 가능하게 됨
• 배포 원칙
  • 두 환경은 다르지만, 최대한 동일해야 함
    • 경우에 따라 하드웨어의 다른 부분일 수도 있고 동일한(또는 다른) 하드웨어에서 실행되는 다른 가상머신일 수도 있음
    • 두 슬라이스에 대해 별도의 IP 주소를 사용하여 별도의 영역으로 분할된 단일 운영 환경이 될 수도 있음
  • 무중다 배포여야 함
  • 한 시점에 하나의 버전만 액티브 상태여야 하며, 롤백이 쉬워야 함
• 장점
  • 동일하게 구성된 환경을 하나 더 추가함으로써 서비스의 가동 중단 시기를 최소화시킬 수 있음
  • 서비스되고 있는 환경(블루 혹은 그린)에 문제가 발생한 경우 백업 서버로 사용할 수 있음
  • 다음 배포를 위한 최종 테스트 단계의 스테이징 환경으로 사용할 수 있음
    • 스테이징 환경: 운영 환경과 거의 동일한 환경을 만들어 놓고, 운영 환경으로 이전하기 전에 여러 가지 비기능적인 부분(보안, 성능, 장애 등)을 검증하는 환경

---

롤링 배포

---

• 애플리케이션이 실행 중인 인프라를 완전히 교체하여 이전 버전의 애플리케이션을 새로운 버전의 애플리케이션으로 서서히 교체하는 배포 전략
• 가용 자원이 제한적일 경우에 사용

• 배포 방식
  • 사용 중인 인스턴스(v1) 내에서 새 버전(v2)을 점진적으로 교체하게 됨
• 장점
  • 업그레이드 과정에서 문제가 발견되면 일반적으로 롤링 배포를 “reverse”로 이동하여 새 버전의 앱을 제거하고 이전 버전을 다시 시작할 수 있음
• 단점
  • 배포가 진행되는 동안 구버전과 신버전이 공존하기 때문에 호환성 문제가 발생할 수 있음
  • 배포 중인 서버는 서비스가 중단된 상태이기 때문에 서버 부하량을 체크하며 배포를 진행해야 함

---

카나리 배포

---

• 전체 인프라에 새로운 소프트웨어 버전을 릴리스하여 모든 사용자가 사용할 수 있도록 하기 전에 변경 사항을 천천히 릴리스함으로써 프로덕션 환경에 새로운 소프트웨어 버전을 도입하는 위헙을 줄이는 기술
• 블루/그린 배포와 유사하게 사용자가 라우팅되지 않는 인프라의 하위 집합에 새 버전의 소프트웨어를 배포하는 것으로 시작함
• 광부들이 광산으로 들어갈 때 새장에 카나리아를 넣어 가져가는 것에서 유래함
• 광산에서 유독가스가 누출되면 광부들이 중독되기 전에 카나리아가 먼저 죽게 됨
• 비슷한 개념으로 잠재적 문제를 초기에 발견하여 운영환경이나 사용자에게 영향을 미치는 것을 방지

• 배포 방식
  • 특정 서버에만 배포를 진행하여 오류 여부를 확인하고 문제가 없다면 모든 서버에 새로운 버전을 단계적으로 배포
• 장점
  • 문제 발생 시 먼저 배포가 진행되었던 서버만 롤백하면 되므로 비교적 롤백이 간편함
  • 운영 환경에서 신규 버전을 테스트할 수 있음
    • 부하를 서서히 증가시키며 신규 버전이 운영 환경에서 어떠한 반응을 보이는지 모니터링하고 수치를 측정할 수 있음
  • 특정 서버로 먼저 배포를 진행하기 때문에 문제 발생 시 리스크가 비교적 적음