배포 패턴이란?
‘배포 패턴’은 새 애플리케이션 기능을 사용자에게 원활하게 출시하는 자동화된 방법입니다. 적절한 배포 패턴은 가동 중지 시간을 최소화하는 데 도움이 됩니다. 일부 패턴을 사용하면 새로운 기능을 점진적으로 출시할 수 있습니다. 이렇게 하면 선정된 사용자를 통해 새 기능을 입증한 후에 모든 사용자에게 해당 기능을 제공할 수 있습니다.
이 섹션에서는 몇 가지 일반적인 배포 패턴에 대해 알아봅니다. 또한 Tailspin 팀이 선택한 패턴을 구현하는 데 Azure App Service가 어떻게 도움이 되는지 알아봅니다.
아침 회의
Tailspin 팀은 기분이 좋습니다. 파이프라인 덕분에 프로세스의 속도를 높일 수 있었기 때문입니다. 팀은 웹앱을 데이터베이스와 통합할 수 있는 개발 환경을 갖추고 있습니다. Tim 님과 Amita 님은 모두 작업을 간소화하는 자동화된 테스트를 할 수 있어 만족하고 있습니다. 일반적으로 지연 시간과 버그가 줄어들었습니다.
그러나 항상 그렇듯이 문제가 있습니다. Tim 님이 발언하고 있는 팀 회의를 살펴보겠습니다.
Tim: 모두 만족할 수 있는 파이프라인을 만들기는 참 어려운 것 같습니다. Irwin 님은 새 기능을 릴리스하는 데 시간이 너무 오래 걸리는 것 같다고 말합니다. 경영진에서 릴리스를 승인할 때까지 아무 작업도 수행할 수 없으며, 현재로서는 승인을 받은 후 기능을 출시하는 원활한 방법이 없습니다. 프로세스는 길고 복잡합니다. 수동으로 작업해야 하고 가동 중지 시간도 발생합니다. 전체 프로세스에 5일 정도 걸릴 수 있습니다. 프로세스가 너무 길다는 것은 알고 있지만, 딱히 해결 방법이 없습니다. 커피를 더 마시면 솔루션을 찾을 수 있을까요.
Andy: 물론 커피는 효과적인 문제 해결에 꼭 필요하긴 합니다.
저희에게 필요한 솔루션은 좋은 배포 패턴이라고 생각합니다. 배포 패턴은 자동으로 전환을 수행하는 방법입니다. 최종 사전 프로덕션 단계에서 라이브 프로덕션으로 소프트웨어를 이동합니다.
올바른 패턴을 선택하면 가동 중지 시간을 최소화하는 등 분명 도움이 될 것입니다. 배포 패턴의 또 다른 장점은 프로덕션에서 반드시 수행해야 하는 테스트를 실행할 수 있다는 것입니다.
‘Andy 님이 화이트보드에 필기하기 시작합니다.’
고려해야 할 가능성은 다음과 같습니다.
- 청록색 배포
- 카나리아 릴리스
- 기능 토글
- 다크 론치
- A/B 테스트
- 점진적 노출 배포
각 패턴을 간략하게 살펴보겠습니다.
파란색-녹색 배포
‘파란색-녹색 배포’는 동일한 두 개의 환경을 실행하여 위험과 가동 중지 시간을 줄입니다. 관련 환경을 ‘파란색’과 ‘녹색’이라고 합니다. 언제든지 환경 중 하나만 라이브입니다. 일반적으로 파란색-녹색 배포에는 트래픽 흐름을 제어하는 데 도움이 되는 라우터 또는 부하 분산 장치가 포함됩니다.
파란색이 라이브라고 가정하겠습니다. 새 릴리스를 준비할 때 녹색 환경에서 최종 테스트를 수행합니다. 소프트웨어가 녹색 환경에서 작동하면 들어오는 모든 요청이 녹색 환경으로 이동하도록 라우터를 전환하기만 하면 됩니다.
파란색-녹색 배포를 사용하면 롤백을 빠르게 수행할 수 있습니다. 녹색 환경에서 문제가 발생하는 경우 라우터를 다시 파란색 환경으로 전환하면 됩니다.
카나리아 릴리스
‘카나리아 릴리스’는 모든 사용자를 문제에 노출시키지 않고도 발생 가능한 문제를 조기에 식별하는 방법입니다. 바로 모든 사용자가 사용할 수 있게 하기 전에 소수의 사용자에게만 새 기능을 제공하는 것입니다.
카나리아 릴리스를 사용하면 기능을 릴리스할 때 발생하는 상황을 모니터링할 수 있습니다. 릴리스에 문제가 있으면 픽스를 적용합니다. 카나리아 릴리스가 안정화된 것을 확인한 후에는 릴리스를 실제 프로덕션 환경으로 이동합니다.
기능 토글
기능 토글을 사용하여 런타임에 “스위치를 전환”합니다. 사용자에게 새로운 기능이나 변경된 기능을 노출하지 않고도 새 소프트웨어를 배포할 수 있습니다.
해당 배포 패턴을 사용하면 Mara 님과 제가 토글 뒤에 새 기능을 빌드합니다. 릴리스가 발생하면 기능이 “해제”되어 프로덕션 소프트웨어에 영향을 주지 않습니다. 토글을 구성하는 방법에 따라 스위치를 “켜기”로 전환하고 원하는 방식으로 기능을 노출할 수 있습니다.
예를 들어 몇몇 사용자에게 먼저 기능을 노출하여 반응을 확인할 수 있습니다. 임의의 샘플 사용자가 관련 기능을 볼 수 있습니다. 또는 모든 사용자 볼 수 있도록 기능을 라이브 상태로 전환할 수 있습니다.
그러나 해당 배포 패턴은 다른 팀원들보다 Mara 님과 저에게 유용할 것 같습니다. 기능 토글 패턴의 가장 큰 장점은 너무 많은 분기를 만들지 않을 수 있다는 것입니다. 분기를 병합하는 일은 어려운 일입니다.
다크 론치
‘다크 론치’는 카나리아 릴리스나 기능 토글 전환과 유사합니다. 다크 론치에서는 모든 사용자에게 새 기능을 노출하는 대신 소규모의 사용자에게 기능을 릴리스합니다.
해당 사용자는 팀을 위해 기능을 테스트하고 있음을 알 수 없습니다. 새 기능을 강조 표시하지도 않습니다. 그래서 해당 패턴을 다크 론치라고 합니다. 소프트웨어는 점진적으로 또는 눈에 띄지 않게 사용자에게 릴리스되어 피드백을 얻고 성능을 테스트할 수 있습니다.
A/B 테스트
‘A/B 테스트’는 웹 페이지 또는 앱의 두 버전을 비교하여 성능이 더 좋은 버전을 알아냅니다. A/B 테스트는 클래식 실험과 같습니다.
A/B 테스트에서는 사용자에게 두 개 이상의 페이지 변형을 임의로 표시합니다. 그런 다음 통계 분석을 사용하여 목표에 더 적합한 변형을 결정합니다.
점진적 노출 배포
‘점진적 노출 배포’는 ‘링 기반 배포’라고도 합니다. 프로덕션 환경에서 변경 내용이 유효한지 확인하는 동시에 그러한 변경 내용이 사용자에게 미치는 영향을 제한하는 또 다른 방법입니다.
링은 기본적으로 카나리아 단계의 확장입니다. 카나리아 릴리스 자체는 효과를 측정하기 위한 단계로 릴리스됩니다. 다른 링을 추가하는 것은 본질적으로 같은 개념입니다.
링 기반 배포에서는 위험을 허용하는 고객에게 먼저 변경 내용을 배포합니다. 그런 다음 점진적으로 더 많은 고객에게 출시합니다.
파란색-녹색 배포 구현하기
‘Andy가 Tim을 바라봅니다.’
Andy: 내용이 조금 많습니다. 생각할 시간을 조금 드릴까요? 아니면 저희가 같이...
Tim: 파란색-녹색이 좋겠어요.
‘회의에 참여한 팀원 모두 웃습니다.’
Mara: 커피 덕분에 빨리 결정할 수 있었나요?
Tim: 기능 토글 방법을 사용하면 Andy 님과 Mara 님이 작업 방식을 바꿔야 합니다. 한 번에 하나씩 하는 것이 좋을 것 같습니다. 기능을 점차적으로 노출하는 방법에는 통계 분석 또는 기능 토글이 필요합니다.
파란색-녹색 배포를 사용하면 제가 제어할 수 있을 것 같습니다. 라우터를 전환은 간단할 뿐만 아니라 쉽고 안전할 것 같습니다. 그리고 파란색-녹색 배포를 사용하면 경영진이 평가할 수 있는 환경이 있습니다. 경영진의 승인을 받으면 쉽게 전환할 수 있습니다. 그러니 파란색-녹색 배포부터 살펴봅시다.
제가 궁금한 것은 파이프라인에 파란색-녹색 배포를 어떻게 구현하나요?
배포 슬롯이란?
Andy: Azure App Service를 사용하고 있기 때문에 ‘배포 슬롯’을 활용할 수 있습니다. 배포 슬롯은 자체 호스트 이름을 갖춘 실행 중인 앱입니다.
아직 Space Game 웹 사이트를 자동화된 파이프라인의 일부로 프로덕션에 배포할 준비가 되지는 않았습니다. 하지만 테스트로 스테이징 환경에 배포 슬롯을 추가할 수 있습니다.
부하 분산 장치 또는 라우터를 설정하는 대신 기존 ‘스테이징’ 환경에서 사용 중인 App Service 인스턴스에 두 번째 슬롯을 추가하면 됩니다. 기본 슬롯을 ‘파란색’, 보조 슬롯을 ‘녹색’이라고 할 수 있습니다.
이렇게 하면 가동 중지 시간 없이 새 기능을 배포할 수 있습니다. 두 배포 슬롯 간에 애플리케이션 및 애플리케이션 구성을 교환합니다. 기본적으로 두 슬롯의 IP 주소를 교환하는 것입니다.
Tim: 좋습니다. 파란색-녹색 배포의 해당 변형을 ‘가동 중지 시간 없는 배포’라고 부르면 좋을 것 같습니다.
Andy: 매우 좋네요! Tim 님과 함께 해당 배포 패턴을 구현하겠습니다. 다음에 회의를 소집해 결과를 소개하겠습니다.
기능 플래그 사용에 대한 권장 사항
기능 플래그는 팀이 고려한 릴리스 주기 방법 중 하나였습니다. 팀은 기능 플래그를 사용하지 않기로 결정했지만, 많은 사람이 유용하게 사용하고 있습니다. 이 섹션에서는 기능 플래그에 대한 자세한 정보를 제공합니다.
‘기능 토글’이라고도 하는 ‘기능 플래그’를 사용하면 코드를 변경하지 않고도 시스템의 작동 방식을 변경할 수 있습니다. 기능 플래그를 사용하면 새 코드를 중앙 개발 분기에 푸시하고 코드가 배포되지만, 반드시 코드가 작동하는 것은 아닙니다. 플래그는 일반적으로 조건부 논리를 제어하는 변수의 값으로 구현됩니다.
팀이 은행 애플리케이션의 중앙 개발 분기에서 작업하고 있다고 가정해 보겠습니다. 나중에 복잡한 병합 작업을 피하기 위해 기본 분기의 모든 작업을 수행하기로 결정했다고 하겠습니다. 하지만 문제가 발생합니다. 이자 계산 코드를 상당 부분 변경하고 있는데, 고객은 매일 해당 코드를 사용합니다. 더 큰 문제는 변경 작업을 완료하는 데 몇 주가 걸린다는 점입니다. 주요 코드를 그렇게 오랜 기간 작동하지 않게 둘 수 없습니다.
해당 시나리오에서는 기능 플래그가 좋은 해결책이 될 수 있습니다. 기능 플래그가 설정되지 않은 사용자가 원래의 이자 계산 코드를 계속 사용할 수 있도록 코드를 변경할 수 있습니다. 한편, 팀에 기능 플래그가 설정되어 있으므로 팀은 변경 중인 코드를 확인할 수 있습니다.
또 다른 유형의 기능 플래그는 릴리스 플래그입니다. 이자 계산 코드에 대한 작업을 완료한 후 해당 작업을 공개적으로 릴리스하기 전에 사용해보고자 한다고 가정해 보겠습니다. 그리고 새 코드와 발생 가능한 문제를 처리하는 데 적합한 사용자 그룹이 있다고 해보겠습니다. 해당 사용자 그룹이 먼저 기능을 사용해 볼 수 있습니다. 구성을 변경하여 사용자 그룹이 기능 플래그를 설정하게 하고 새 코드를 테스트할 수 있습니다. 문제가 발생하는 경우 플래그를 사용하지 않도록 빠르게 설정할 수 있습니다.