5 minute read

A successful deployment model 번역

출처: https://thomasvilhena.com/2019/08/a-successful-deployment-model

성공적인 배포를 위한 5가지 규칙

  1. 테스트, 스테이징, 프로덕션 환경은 같은 배포 이미지를 사용해야 한다.
  2. 시스템 업데이트는 무중단으로 해야 한다.
  3. 배포 프로세스를 완전히 자동화해야 한다.
  4. 자동 모니터링 시스템을 구축해서 조기에 문제를 발견할 수 있어야 한다.
  5. 이전 버전으로 롤백을 지원해야 한다.

소프트웨어 개발 시 배포는 엄청 중요하다. 안정 버전부터 기능 추가 버전까지 다양한 버전을 배포하면서 아무리 테스트를 돌리고 QA를 해도 배포한 버전에 결함이 없다고 확신할 수 없다. 그래서 성공적인 배포를 위해서는 출시는 물론, 모니터링과 복구도 생각해야 한다.

배포 과정을 자세히 살펴보며 각 과정에 따르는 위험을 관리하는 법을 알아본다.

1. 배포 가능한 이미지

배포 가능한 이미지는 테스트, 준비 및 프로덕션을 위해 생성된 실행 가능한 패키지이다.

일반적으로 두 가지 형식이 있다.

  • 컨테이너 이미지: 가상화 플랫폼에서 애플리케이션을 독립적으로 실행하는 데 필요한 모든 것(소스 코드, 런타임, 시스템 및 설정 등)을 기반으로 구축된 실행 파일

  • 바이너리 이미지: 특정 OS를 대상으로 소스 코드를 빌드한 응용 프로그램의 이진 파일

배포 가능한 이미지를 생성하는 게 배포의 첫 단계이다.

그래서 규칙 1:

테스트, 스테이징, 프로덕션 환경은 같은 배포 이미지를 사용해야 한다.

즉, 문제가 발생해서 코드를 수정해야 할 때마다, 새로 생성된 배포 이미지는 테스트 환경에서부터 유효성 검사 다시 시작해야 한다. 이로 인해 애플리케이션 재빌드 시 시스템 구성 변경이나 갑작스러운 패키지 종속성 업데이트로 발생할 수 있는 불확실성을 각 환경을 통과할 때마다 줄일 수 있다.

2. 시스템 중단시간

배포로 인해 사용자의 불편이 발생해서는 안 된다. 약간의 시스템 중단은 애플리케이션의 신뢰도를 하락시키고 금전적 손실을 일으킨다.

이를 염두에 둘 때 규칙 2:

시스템 업데이트는 무중단으로 해야 한다.

컨테이너 이미지를 사용하면 무중단 업데이트가 쉬워진다. 옛 버전과 새 버전을 동시에 띄운 뒤 트래픽을 새로운 버전으로 옮기면 되기 때문이다.

2가지 방식으로 가능하다.

  • Hard Switch: 이전 버전의 연결을 바로 끊어서 전체 사용자가 새 버전을 사용하게 하는 것
  • Canary release: 소수의 사용자만 새 버전에 노출시키고(ex: 5%) 이 버전이 안정적이라고 확신할수록 새 버전으로 서서히 사용자를 옮기는 것(5%에서 100%로)

Canary release는 배포 위험을 완화하기에 더 좋지만 설정하는데 많은 작업이 필요하다.

3. 자동 실행

수동으로 배포했다가 조그마한 실수로 시스템을 다운시킬 수 있다.

그래서

배포 프로세스를 완전히 자동화해야 한다.

배포를 한 번에 다 안 해도 괜찮다. 메인 레포의 마스터 브랜치에 커밋 한 번만 해도 프로덕션 배포를 시작하는 지속적 배포를 사용해도 좋다. 대신에 테스트와 Canary release, 모니터링을 잘 해야 한다.

4. 모니터링

문제가 발생하자마자 자동으로 발견해서 최대한 빨리 고치기 위해 모니터링을 한다. 우리가 손댈 필요도 없게 모니터링이 포괄적이라면 좋겠다. 하지만 그럴 일은 없으니까 보통은 문제 발생 시 시스템 관리자에게 알람을 울리게 하는 것에 만족한다.

그래서 4번째 규칙:

자동 모니터링 시스템을 구축해서 조기에 문제를 발견할 수 있어야 한다.

Health 모니터링과 에러 모니터링이 가장 효과적이다.

Health 모니터링

시스템 지표과 비즈니스 지표을 정의해서 프로그램이 이러한 지표에 맞게 동작하는지 추적하고, 예상 작동 범위를 벗어나면 경고를 울린다.

시스템 지표의 예시

  • 활성 데이터베이스 연결 수
  • 초당 웹 서버 요청
  • 호스트 시스템 당 사용 가능한 메모리
  • 호스트 시스템 당 IOPS

비즈니스 지표의 예시

  • 사용자 등록률
  • 온라인 사용자 수
  • 이미지 업로드 속도 (미디어 공유 응용 프로그램의 경우)
  • 요금과 같은 콘텐츠 (소셜 응용 프로그램의 경우)

에러 모니터링

여기서 에러는 인증 토큰 만료 에러나 데이터베이스 쿼리 시간 초과 에러 같이 지속해서 발생하지만 일반으로 예상 가능한 에러를 뜻한다.

아래 같은 경우 경고를 울린다.

  • 일반적인 에러가 많이 증가하거나 감소하는 경우
  • 예기치 않은 새로운 에러가 일관적으로 나타나는 경우

가역성(Reversibility)

배포했을 때 문제는 어떻게든 발생할 것이다.

배포 환경이라도 대처 가능한 문제가 있고 시스템을 바로 다운시키는 문제가 있다. 후자의 경우 롤백을 통해 시스템을 안정된 상태로 바로 되돌릴 수 있다.

그래서 5번째 규칙:

이전 버전으로 롤백을 지원해야 한다.

그런데 주의해야 하는 경우가 있다. 애플리케이션이 발전할수록 데이터베이스 스키마나 저장된 데이터도 발전한다.

이전 응용 프로그램 버전과의 호환성을 유지하면서 데이터베이스가 발전하도록 설계하면 괜찮다.

이를 위해서는 마이그레이션 스크립트도 배포에 통합시키거나 DB에 변경사항을 커밋하거나 DB를 되돌린다.

적합하고 안정적인 배포 프로세스를 달성하는 데는 노력과 시간이 많이 든다. 처음부터 완전한 프로세스를 구축하기 보단 점차 개선해야 한다.

You May Also Enjoy