매번 변경 사항을 프로덕션에 배포하는 것은 무섭지만, 프로덕션에 바로 배포하지 않는 것이 더 무섭습니다.
이것은 제가 Amazon에서 수억 명의 고객에게 배포하는 팀을 이끌며 사용했던 프로세스입니다. 컨설팅을 통해 저는 엔지니어링 팀들이 격주 정기 릴리스 배포에서 매 머지마다 배포하는 방식으로 전환하도록 이끌었습니다.
당연한 부분부터 시작하죠:
장애는 반드시 발생합니다. '만약'의 문제가 아니라 '언제'의 문제입니다.
단위 테스트, 통합 테스트, 도그푸딩, 엔드투엔드 테스트, 배포의 신에게 제물을 바치는 것까지, 그 무엇도 모든 버그를 잡아내지는 못합니다.
일주일 전에 여러분의 기능에 대해 수행했던 테스트는 팀원의 최신 변경 사항과 함께 테스트된 것이 아닙니다.
여러분의 테스트는 팀원 서비스의 프로덕션 이전 버전을 대상으로 수행되었는데, 그 서비스는 이제 변경되어 하위 호환되지 않는 변경 사항을 포함하고 있습니다.
기다릴수록 릴리스에 쌓이는 변경 사항이 많아집니다. 롤백이 필요할 때 1-2시간 분량이 아니라 2주 분량의 변경 사항을 롤백해야 할 수도 있습니다.
장애가 불가피하다는 전제를 받아들인다면, 릴리스 QA에 막대한 리소스를 투입하는 것보다 릴리스 모니터링 및 관측에 리소스를 집중하고 장애 발생 시 대응할 준비를 하는 것이 훨씬 합리적입니다.
이제, 어떻게 그렇게 할 수 있는지 알아보겠습니다.
전제 조건:
CI/CD
테스트는 생각보다 훨씬 덜 중요합니다. 테스트는 여러분의 변경 사항이 프로덕션에서 안전하다는 것을 증명할 수 없습니다. 그 무엇도 증명할 수 없습니다. 테스트가 하는 일은 실패 비용을 낮추는 것입니다. CI에서 잡힌 버그는 몇 분이면 해결됩니다. 프로덕션에서 잡힌 버그는 롤백하느라 저녁을 다 쓰게 만듭니다.
그러니 매 머지마다 전체 테스트 스위트를 실행하거나, 최소한 파이프라인의 일부로 실행하세요: 단위, 통합, 엔드투엔드 테스트. 버그가 파이프라인을 따라 내려갈수록 해결 비용은 커집니다.
모니터링/관측 가능성
가장 중요한 것은 회귀(regression)를 가능한 한 빨리 잡아내는 것입니다. 이를 위해서는 훌륭한 모니터링이 필요합니다. 다음과 같은 형태를 갖춰야 합니다:
- 메트릭: 오류, 지연 시간, 가용성
- 상관관계 ID가 포함된 로그
- 위 두 항목에 연결된 sev-3 및 sev-2(페이징) 알람
알람 임계값을 조정하는 데는 약간의 예술과 과학이 필요합니다. 민감도와 실제 장애 발생 시 대응 속도 사이의 균형이 중요합니다. sev-2 알림 목표 시간은 5-10분이어야 합니다.
처음에는 아마 틀릴 것이고, 너무 민감하게 설정할 가능성이 높습니다. 안타깝게도 이는 대부분 시행착오를 통해 배우는 것이므로, 처음에는 새벽 2시에 몇 번 깨게 될 것입니다.
기능 플래그
위험이 있는 변경 사항은 기능 플래그/원격 구성을 통해 배포해야 합니다. 기능 플래그를 사용하면 전체 배포를 롤백할 필요 없이 몇 분 안에 변경 사항을 롤백하거나 끌 수 있습니다. 또한 기능 플래그 서비스가 지원한다면(그래야 합니다), 기능을 비율 또는 코호트 단위로 점진적으로 롤아웃하여 잘못된 변경의 영향을 더욱 줄일 수 있습니다.
이를 통해 코드 배포와 코드 활성화를 분리할 수 있습니다. 미묘한 차이지만, 위험을 줄이는 데 있어 게임 체인저입니다.
참고: 플래그를 정리하는 프로세스가 필요합니다. 이상적으로는 생성된 각 플래그에 대한 제거 티켓을 만드는 것입니다. 그렇지 않으면 기능 플래그 서비스가 다운될 때(그럴 것입니다) 심각한 회귀가 발생할 수 있습니다. 제가 어떻게 아는지 물어보세요.
자동 롤백(배포 시 서킷 브레이커)
배포 시 서킷 브레이커는 플릿 전체에 배포를 롤아웃하는 동안 오류 수 또는 오류 비율이 감지되면 배포를 롤백할 수 있는 기능입니다. 대부분의 클라우드 제공업체는 이제 간단한 체크박스로 이 기능을 제공합니다.
하위 호환 변경
이미 하고 있어야 하지만, 매 커밋 배포는 이 관행을 강제합니다. 롤링 배포 중에는 이전 버전과 새 버전이 동시에 실행됩니다. 모든 변경 사항은 이전 버전과 함께 작동해야 합니다. 이를 피하려고 자정에 배포하던 꼼수는 더 이상 통하지 않습니다.
배포 전략
이제 이러한 준비를 갖췄다면, 변경 사항을 롤아웃할 때 위험을 줄이는 데 도움이 되는 몇 가지 배포 전략을 살펴보겠습니다.
원 박스(카나리)
원 박스 배포는 변경 사항을 더 큰 플릿의 박스 한 대에 배포하는 방식입니다. 이렇게 하면 잘못된 변경의 영향을 단 한 대의 호스트로 제한할 수 있습니다.
배포한 후 일정 기간 동안 그대로 두면 전체 트래픽의 일부만 수신하게 됩니다. 이 박스에 모니터링과 알림을 구성해 두면 문제가 발생했을 때 알림을 받을 수 있습니다.
롤링 배포
롤링 배포는 시간에 따라 비율 기반으로 롤아웃할 수 있게 해줍니다. 치명적인 오류가 발생하더라도 모든 머신에 영향을 미치기 전에 감지하여 롤백을 시작할 수 있습니다.
리전별 롤아웃
회사가 성장하면 다중 리전 배포를 하게 됩니다. 모든 리전에 동시에 배포하는 대신 특정 리전 하나에 먼저 배포할 수 있습니다(일반적으로 트래픽이 가장 낮은 리전).
이 방식이 적용되지 않는 경우
앱 스토어
모바일 앱 출시는 이 지침과 완전히 호환되지 않습니다. 앱 스토어 검토 대기열이 배포 주기를 제한하므로 다른 전략이 필요합니다.
인증 환경
의료 기기, 항공 전자, 산업 제어 등. 규제 기관의 빌드 인증이 필요하다면 지속적 배포를 할 수 없습니다.
온프레미스/자체 호스팅
업그레이드 시점을 통제할 수 없습니다. 운영하는 모든 것에는 여전히 지속적 배포를 적용할 수 있지만, 각 변경 사항에 버전을 부여해야 하며 채택 시점은 고객이 결정합니다.
어디서부터 시작할까
모든 것을 한 번에 하지 마세요. 순서가 중요합니다:
- CI를 green으로 만들고 빠르게 하세요. 이상적으로는 15분 미만
- 오류율, 지연 시간, 가용성에 대한 메트릭과 알람을 설정하세요. 이것이 가장 중요한 부분입니다.
- 위험한 변경 사항은 모두 플래그 뒤에 두세요.
- 원 박스 + 자동 롤백을 추가하세요.
- 릴리스 캘린더를 삭제하세요.
- 릴리스 일정을 잡지 않게 되어 생긴 모든 여유 시간의 새로운 활용처를 찾아보세요.
제가 함께 일한 대부분의 팀은 이 과정을 마치는 데 약 한 분기가 걸렸습니다. 도구 마련은 쉬운 부분입니다. 조직 프로세스와 정기 릴리스가 안전하다는 착각을 깨는 것이 어려운 부분입니다.
여러분의 팀이 릴리스 캘린더를 사용 중이고 벗어나고 싶다면, 그것이 바로 제가 하는 일입니다. DM 보내주세요.
