4 min to read
Deployment / TIL
배포 자동화 / 파이프라인
배포 자동화
배포 자동화란, 한 번의 클릭 혹은 명령어 입력을 통해 전체 배포 과정을 자동으로 진행하는 것이다.
배포 자동화는 수동적이고 반복적인 배포 과정을 자동화함으로써 시간이 절약된다.
또한 전체 배포 과정을 매번 일관돠게 진행하는 구조를 설계하기 때문에, 휴먼 에러(Human Error)를 방지할 수 있다. 휴먼 에러란, 사람이 수동적으로 배포 과정을 진행하는 중에 생기는 실수를 말한다. 그 전에 했던 배포 과정과 비교하여 특정 과정을 생략하거나 다르게 진행하여 오류가 발생하는 것이 휴먼 에러의 예이다.
배포 자동화 파이프라인
파이프라인이란, 소스 코드의 관리부터 실제 서비스로의 배포 과정을 연결하는 구조를 뜻한다. 파이프라인은 전체 배포 과정을 여러 단계로 분리하고, 각 단계는 파이프라인 안에서 순차적으로 실행되며, 단계마다 주어진 작업을 수행한다.
- Source 단계 : 원격 저장소에 관리되고 있는 소스 코드에 변경 사항이 일어날 경우, 이를 감지하고 다음 단계로 전달하는 작업을 수행한다. (버전 컨트롤 도구를 이용한 소스코드 관리 및 전달)
- Build 단계 : Source 단계에서 전달받은 코드를 컴파일, 빌드, 테스트하여 가공한다. Build 단계를 거쳐 생성된 결과물을 다음 단계로 전달하는 작업을 수행한다.
- Deploy 단계 : Build 단계로부터 전달받은 결과물을 실제 서비스에 반영하는 작업을 수행한다.
AWS 개발자 도구
개발자 도구 섹션에서 제공하는 서비스를 활용해 배포 자동화 파이프라인을 구축할 수 있다.
개발자 도구 제공 서비스 목록
- CodeCommit
Github와 유사한 서비스를 제공하는 버전 관리 도구이며, Source 단계를 구성할 때 CodeCommit 서비스를 이용한다. 보안에 대한 강점이 있지만, 과금 가능성을 고려해야 한다. - CodeBuild
Build 단계에서 이용하며, 유닛 테스트, 컴파일, 빌드와 같은 필수적으로 실행되어야 할 작업을 명령어를 통해 실행할 수 있다. - CodeDeploy
실행되고 있는 서버 애플리케이션에 실시간으로 변경사항을 전달하고 반영할 수 있다. - CodePipeline
각 단계를 연결하는 파이프라인을 구축할 때 이용한다. - Cloud9
- CloudShell
- X-Ray
- AWS FIS
- CodeArtifact
- CodeStar
배포 전략
블루 / 그린 배포
애플리케이션 또는 마이크로서비스의 이전 버전에 있던 사용자 트래픽을 이전 버전과 거의 동일한 새 버전으로 점진적으로 이전하는 애플리케이션 릴리스 모델
배포를 자동화할 때 겪는 어려움 중 하나는 소프트웨어를 최종 테스트 단계에서 실제 프로덕션 단계로 전환하는 *컷오버 자체이다. 일반적으로 *다운 타임을 최소화하려면, 이 작업을 신속하게 수행해야 하는데, 컷오버와 다운타임 프로덕션 환경을 확보함으로써 이를 실현시킬 수 있다.
- 컷오버(cutonver) : 기존에 운영되던 환경을 중단시키고, 새로 구축된 환경으로 오픈하는 것
- 다운타임(Downtime) : 시스템을 이용할 수 없는 시간
두 환경은 다르지만, 최대한 동일해야 한다. 경우에 따라 하드웨어의 다른 부분일 수도 있고 동일한 하드웨어에서 실행되는 다른 가상 머신일 수도 있다. 또한 두 슬라이스에 대해 별도의 IP 주소를 사용하여 별도의 영역으로 분할된 단일 운영 환경이 될 수도 있다.
무중단 배포여야 하고, 한 시점에 하나의 버전만 액티브 상태여야 하며, 롤백이 쉬워야 한다.
▼ Example ▼
blue를 실제 운영 중인 환경으로 가정한 경우
- 새로운 버전을 릴리스 하고 싶은 경우 green 환경에서 테스트를 진행한다.
- 테스트가 정상 완료되면 blue 환경에서 들어가던 모든 요청을 green 환경으로 변경한다.
- 이후 blue는 이전 green 환경의 역할을 가져감과 동시에 green이 잘 동작하지 않을 때 사용할 수 있는 백업 서버로의 역할도 수행이 가능하게 된다.
블루/그린 배포는 동일하게 구성된 환경을 하나 더 추가함으로써 서비스의 가동 중단 시기를 최소화시킬 수 있고, 서비스되고 있는 환경에 문제가 발생한 경우 백업 서버로 사용할 수 있다.
또한, 다음 배포를 위한 최종 테스트 단계의 *스테이징 환경으로 사용할 수 있다.
- 스테이징 환경 : 운영 환경과 거의 동일한 환경으로 만들어 놓고, 운영 환경으로 이전하기 전에 여러가지 비 기능적인 부분(보안, 성능, 장애 등)을 검증하는 환경
롤링 배포
애플리케이션이 실행 중인 인프라를 완전히 교체하여 이전 버전의 애플리케이션을 새로운 버전 애플리케이션으로 서서히 교체하는 배포 전략이다. 롤링 배포는 가용 자원이 제한적일 경우에 사용된다.
롤링 배포는 사용 중인 인스턴스(v1) 내에서 새 버전(v2)을 점진적으로 교체하게 된다.
업그레이드 과정에서 문제가 발견되면 일반적으로 롤링 배포를 “reverse”로 이동하여 새 버전의 앱을 제거하고 이전 버전을 다시 시작할 수 있고, Downtime이 없다.
하지만 배포가 진행되는 동안 구 버전과 신 버전이 공존하기 때문에 후환성 문제가 발생할 수 있고, 배포 중인 서버는 서비스가 중단된 상태이기 때문에 서버 부하량을 체크하며 배포를 진행해야 한다.
카나리 배포
전체 인프라에 새로운 소프트웨어 버전을 릴리스하여 모든 사용자가 사용할 수 있도록 하기 전에 변경 사항을 천천히 릴리스함으로써 프로덕션 환경에 새로운 소프트웨어 버전을 도입하는 위험을 줄이는 기술이다.
블루/그린 배포와 유사하게 사용자가 라우팅되지 않는 인프라의 하위 집합에 새 버전의 소프트웨어를 배포하는 것으로 시작한다.
카나리 배포는 광부들이 광산으로 들어갈 때 새장에 카나리아를 넣어 가져가는 것에서 유래했는데, 광산에서 유독가스가 누출되면 광부들이 중독되기 전에 카나리아가 먼저 죽게 된다. 카나리 릴리스는 비슷한 개념으로 잠재적 문제를 초기에 발견하여 전체 운영환경이나 사용자에게 영향을 미치는 것을 방지한다.
특정 서버에만 배포를 진행하여 오류 여부를 확인하고 문제가 없다면 모든 서버에 새로운 버전을 단계적으로 배포하는 방식이다.
카나리 배포는 문제 발생 시 먼저 배포가 진행됐던 서버만 롤백하면 되기 때문에 비교적 롤백이 간편하다. 운영 환경에서 부하를 서서히 증가시키며 신규 버전이 운영 환경에서 어떠한 반응을 보이는지 모니터링하고 수치를 측정할 수 있다. 또한 특정 서버로 먼저 배포를 진행하기 때문에 문제 발생 시 리스크가 비교적 적다.