안전한 배포 방식 채택
 오류나 예기치 못한 조건의 영향을 최소화하기 위해 배포 프로세스에 가드 레일을 구현합니다. |
|---|
개발 주기 동안 워크로드 아티팩트는 구현, 테스트 및 버그 수정 과정에서 많은 변경을 거칩니다.
배포 프로세스는 표준 운영 절차를 따라야 합니다. 모든 변화는 동일한 수준의 엄격성을 가지고 전개되어야 합니다. 이 원칙은 코드, 구성 및 모든 관련 아티팩트에도 동일하게 적용됩니다. 핵심은 프로덕션에서 예측 가능성을 확보하기 위해 가능한 한 일찍 안전 사례를 적용하는 것입니다. 오류가 고객에게 전달되더라도 최대한 빨리 복구 변경 내용을 롤아웃할 수 있어야 합니다.
예제 시나리오
Contoso Air는 고객이 앱을 통해 직접 항공편을 예약할 수 있는 웹 애플리케이션을 개발했습니다. 해당 앱은 1년 이상 운영되었습니다.
이 앱은 Azure에 완전히 배포되었으며 Azure App Service, Azure Cosmos DB, Azure Functions, Azure Logic Apps 및 Azure Service Bus를 기반으로 합니다.
자동화된 배포 표준 체계화
파이프라인과 같은 자동화된 배포 프로세스를 사용하여 모든 변경 내용을 배포하는 프로세스를 표준화합니다. 모든 환경에서는 파이프라인을 사용해야 합니다. 자산과 버전을 환경별로 분류하여 쉽게 추적하고 식별할 수 있도록 합니다.
일관된 배포 방법을 사용하면 프로세스 오류와 분산으로 인해 발생하는 문제를 줄이고 워크로드 문제에 활동을 집중할 수 있습니다.
표준화는 배포가 안전하고, 신뢰할 수 있고, 반복적으로 완료되도록 보장합니다.
분류를 통해 이전 배포 및 발생한 문제에 대한 로그를 쉽게 볼 수 있습니다. 해당 정보를 사용하면 롤백 및 롤포워드 작업을 신속하게 처리할 수 있습니다.
Contoso의 과제
- Contoso Air 워크로드 팀은 자동화된 빌드 및 배포 파이프라인을 사용하지만, 배포에는 일반적으로 다양한 구성 설정을 변경하고 유효성을 검사하기 위해 작업 전반에 걸쳐 수동 개입이 필요합니다.
- 수동 개입으로 인해 배포 시 오류가 자주 발생하고, 모든 릴리스가 전체 팀에 극도로 스트레스가 많고 중단이 되는 이벤트가 됩니다. 수동 개입으로 인해 배포에 실패했을 때 롤백하기가 어렵습니다.
접근 방식 및 결과 적용
- 팀은 배포의 일부로 구성 변경을 자동화하고 추가된 기능을 기존 배포 파이프라인에 통합하기 위해 시간을 할당합니다.
- 각 환경과 관련된 구성 설정은 해당 JSON 파일에 외부화되어 추가 추적성을 위해 소스 제어에 저장됩니다. 비밀로 간주되는 설정은 각 환경에도 할당되는 비밀 자격 증명 모음 저장소에 저장됩니다.
- 이제 모든 변경 내용이 배포 중에 기록되어 문제 해결 및 감사에 도움이 되는 완벽한 추적성이 확보되었습니다. 또한 팀은 파이프라인의 구성 변경 내용의 유효성을 검사하기 위해 자동화된 테스트도 추가합니다.
- 다음으로, 팀은 프로세스를 더욱 최적화하기 위해 롤백을 완전히 자동화하는 작업을 진행할 것입니다.
- 새로운 자동화 덕분에 배포가 더욱 안정적이고 예측 가능해졌고, 팀 사기도 높아졌습니다.
자주 배포
정기적으로 소규모 증분 업데이트를 배포합니다.
이 방식을 사용하면 프로젝트 관리 관점에서 사용자 스토리와 작업 항목을 관리하기 쉬운 상태로 유지하는 데 도움이 되며 배포에 실패할 때 대규모 문제가 발생할 위험을 줄일 수 있습니다.
Contoso의 과제
- 팀의 배포 프로세스는 전통적으로 3~4개월마다 주요 릴리스를 수행하는 것이었습니다. 이런 사례로 인해 릴리스의 유효성을 검사하기 어렵습니다. 이 팀은 또한 너무 많은 움직이는 부품으로 인한 문제를 해결하는 데 어려움을 겪었습니다.
- 중간 릴리스 핫픽스를 필요로 하거나 롤백하고 중단해야 하는 문제가 있는 릴리스가 여러 번 발생했습니다.
- 릴리스는 매우 스트레스가 많고 "모두가 힘을 합쳐야 하는" 상황으로 취급되어 팀 사기에 부정적인 영향을 미쳤습니다.
접근 방식 및 결과 적용
- 최근에 문제가 있는 릴리스 이후, 관련자들은 팀에 배포에 대한 더 나은 방식을 제안해 달라고 요청했습니다. 팀은 빈번하고 작은 변화를 선호하도록 관행을 변경하기로 결정했습니다. 각 릴리스의 범위를 빌드가 하위 환경 전반으로 확산됨에 따라 철저히 테스트된 하나 또는 (최대) 몇 가지 관련 변경 내용으로 제한합니다.
- 그 결과, 릴리스가 훨씬 더 효율적으로 이루어졌고, 품질도 향상되었습니다. 릴리스의 유효성을 검사하기가 더 쉽고 문제를 해결하는 것도 더 단순합니다.
- 예측 가능한 릴리스가 정기적으로 이루어지니 팀의 자신감과 사기를 회복하는 데 도움이 되었습니다. 사용자들도 이점을 얻고 있습니다. 릴리스 품질이 높을수록 중단이 줄어들고 새로운 기능에 훨씬 더 빨리 액세스할 수 있습니다.
점진적 노출 방식 사용
실사를 거쳐 점진적으로 업데이트를 롤아웃합니다. 업데이트가 모든 사용자에게 안전하게 적용될 때까지 인스턴스와 고객 수를 점진적으로 늘릴 수 있는 제어 기능을 제공하는 배포 모델을 사용합니다.
각 업데이트를 제어된 방식으로 테스트하여 문제가 프로덕션 초기에 해결되도록 합니다. 전체 고객 기반에 영향을 미치는 잘못된 업데이트를 출시하지 마세요.
업데이트가 이전 버전과 호환되는지 테스트합니다.
Contoso의 과제
- 팀은 더 작은 규모의 릴리스로 방식을 전환하여 큰 이점을 얻고 있습니다. 이제 릴리스에 덜 시간을 할애하고 추가적인 운영적 우수성 개선을 위해 계속해서 노력할 활력을 얻고 있습니다.
- 새로운 기능을 실험하면서 일부 변경 내용은 사용자에게 좋은 반응을 얻지 못했거나 가파른 학습 곡선으로 인해 지원 요청이 증가했습니다.
- 인기가 없거나 사용하기 쉽지 않은 기능을 출시하는 영향을 최소화하는 동시에 사용자 생산성을 최대화하기 위해 애플리케이션을 지속적으로 혁신할 수 있는 방법을 고민합니다.
접근 방식 및 결과 적용
- 기능 플래그를 사용하여 새로운 기능을 사용자에게 점진적으로 공개하는 기능 릴리스 모델을 구현하기로 결정했습니다.
- 새로운 기능을 계획하는 단계에서는 어떤 사용자에게 먼저 해당 기능을 노출할지 선택하는 기준이 정의됩니다. 소수의 사용자 그룹이 새로운 기능을 먼저 받을 수 있도록 선정되었습니다. 사용자 피드백에 따라 해당 기능은 점차 더 큰 그룹에 배포되어, 결국 전체 사용자 집단이 새 버전을 실행하게 됩니다. 점점 더 많은 사용자가 새로운 기능을 사용하게 되면서, 지원 팀은 지원 사례의 결과를 문서화하여 내부적으로 공유하고, 잠재적으로는 외부 FAQ에 추가할 예정입니다.