Microsoft AZ-400: 릴리스 관리 및 배포 전략 — 학습 가이드

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

다음의 일부입니다: Microsoft DevOps Engineer Expert AZ-400 — 학습 가이드. 검증된 답안으로 연습하기: Microsoft 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

개요

Azure에서의 릴리스 관리는 가용성을 보호하면서 피드백을 가속화하는, 반복 가능하고 정책에 따라 관리되는 제공 방식에 달려 있습니다. 배포 전략, 게이트를 통한 유효성 검사, 링 기반 노출, 기능 플래그를 사용한 다크 론칭을 마스터하면 팀은 안전성을 희생하지 않으면서 지속적으로 제공할 수 있습니다. Azure Pipelines, Azure Deployment Environments, Azure Front Door/Traffic Manager, Azure App Configuration은 점진적 배포, 다중 환경 오케스트레이션, 감사 가능한 변경 제어를 위한 통합된 도구 체인을 제공합니다. 이 섹션에서는 각 기능의 사용 시점과 방법, 이들을 함께 연결하는 방법, 그리고 프로덕션 수준의 파이프라인에서 요구되는 롤백 및 문서화 관행에 대해 설명합니다.

배포 전략 및 점진적 배포

블루-그린(레드/블랙) 배포는 현재 버전(블루)이 트래픽을 처리하는 동안 병렬 환경(그린)에 새 버전을 배포합니다. Azure App Service에서는 배포 슬롯을 사용하여 블루-그린을 구현합니다. 스테이징 슬롯에 배포하고, 워밍업한 후, 슬롯을 교환합니다. 롤백은 슬롯을 다시 교환하여 즉시 수행할 수 있으므로 블루-그린이 가장 빠른 롤백 옵션입니다. 트래픽이 이동하기 전에 바인딩과 앱 설정을 검증하려면 슬롯 교환을 “미리 보기로 교환” 기능과 함께 사용하세요.

카나리 배포는 먼저 소수의 사용자에게 배포한 다음, 상태가 정상적으로 유지되면 점진적으로 트래픽을 늘립니다. Azure에서는 다음을 사용하여 카나리를 구현할 수 있습니다.

Azure Front Door의 가중치 기반 라우팅을 사용하여 애플리케이션 레이어에서 상태 프로브 및 WAF와 함께 이전 백엔드와 새 백엔드 간에 트래픽을 분할합니다.
지역 수준의 제어가 필요할 때 DNS 기반의 글로벌 카나리를 위해 Azure Traffic Manager의 가중치 기반 엔드포인트를 사용합니다.
Ingress(예: NGINX 카나리 주석) 또는 서비스 메시 트래픽 분할을 통한 AKS 카나리. 다음 단계로 진행하기 전에 게이트에서 오류 예산, 지연 시간 백분위수, 포화도를 평가해야 합니다.

롤링 업데이트는 인스턴스를 점진적으로 교체하여 이중 플릿 비용을 방지합니다. AKS에서는 maxSurge 및 maxUnavailable을 사용하여 rollingUpdate를 구성하고, readiness/liveness probes와 PDB를 통해 가용성을 보호해야 합니다. VM Scale Sets의 경우 애플리케이션 상태 프로브와 함께 롤링 업그레이드 정책을 사용합니다. 롤링 방식은 경제적이지만 시스템 전반의 회귀 문제 발생 시 블루-그린 방식보다 복구가 느립니다.

기능 플래그는 릴리스와 배포를 분리합니다. 다크 론칭은 기본적으로 비활성화된 코드 경로를 제공하여, 기능을 노출하지 않고 인프라를 테스트합니다. 플래그를 사용하여 비용이 많이 드는 마이그레이션을 제어하고, 점진적으로 UI를 공개하며, 문제가 되는 동작을 신속하게 중단시킬 수 있습니다. 이는 카나리 및 링 배포를 보완하는 방식입니다. 즉, 광범위하게 배포한 후 점진적으로 활성화합니다.

링 기반 배포는 여러 사용자 집단에 걸쳐 점진적인 노출을 공식화합니다. R0(내부), R1(카나리 고객), R2(단일 지역), R3+(전역)와 같은 링을 정의합니다. 승격 기준은 객관적이어야 합니다. 예를 들어 SLO 준수, Sev2+ 심각도 인시던트 없음, 수용 가능한 비즈니스 KPI 등이 있습니다. 링을 트래픽 전환(Front Door/Traffic Manager), 환경 검사, 승인 게이트와 결합하여 조기에 중단하거나 롤백할 수 있습니다.

점진적 트래픽 전환을 위한 Azure Front Door와 Traffic Manager 비교: Front Door는 레이어 7에서 작동하며 즉각적인 변경, 상태 프로브, 세션 선호도, 경로 기반 라우팅, 가중치 기반 분할 기능을 제공하여 앱 레이어 카나리 및 A/B 테스트에 이상적입니다. Traffic Manager는 DNS에서 작동하며 지역 기반 라우팅, 크로스 클라우드 장애 조치 또는 지역 수준 카나리에 더 적합하지만 DNS TTL 고려 사항이 있고 애플리케이션 레이어 기능은 없습니다.

환경, 승인 및 게이트

Azure Deployment Environments는 가드레일을 통해 개발/테스트 환경 프로비저닝을 표준화합니다. 환경 정의는 반복 가능한 스택을 설명하는 코드형 인프라(Bicep/ARM/Terraform) 템플릿입니다. 이 정의는 서비스에 등록된 Git 리포지토리인 카탈로그에 저장되어, 버전 관리되고 검색 가능한 환경 블루프린트를 제공합니다. 개발자는 기업 정책(할당량, RBAC, 네트워킹)에 따라 제어되는 개발/테스트 인스턴스를 셀프서비스로 프로비저닝하여, 일관성 없는 구성을 제거하고 하위 환경을 프로덕션 토폴로지와 일치시킬 수 있습니다.

승인은 필요한 경우 사람이 개입하는 제어를 설정합니다. Azure Pipelines에서는 다음과 같습니다.

배포 전 승인은 지정된 승인자가 동의할 때까지 스테이지를 차단합니다. 스테이징에서 프로덕션으로 전환하거나 카나리 단계를 넘어 링을 확장하는 등 고위험 전환에 사용합니다.
배포 후 승인은 릴리스가 완료로 표시되기 전에 유효성 검사 활동(UAT 승인, 감사 단계)을 확인합니다.
요청이 자동으로 만료되도록 승인 시간 초과를 구성합니다. 만료된 승인은 스테이지를 실패 처리하고 통제되지 않는 변경을 방지합니다. 직무 분리가 필요한 경우 여러 승인자를 요구하거나 순차적 승인을 설정합니다. 일관된 거버넌스를 위해 “승인 및 검사"를 통해 환경 및 서비스 연결에 승인을 적용합니다.

릴리스 게이트는 승격 전에 객관적인 증거를 강제합니다. Azure Pipelines는 다음과 같은 검사를 지원합니다.

메트릭이나 경고를 쿼리하는 Azure Monitor 검사(예: 활성 Sev2 경고 없음, 오류율 임계값 미만, p95 지연 시간 목표 미만). 게이트는 성공/실패 또는 시간 초과가 될 때까지 정의된 간격으로 재평가합니다.
외부 품질 서비스, 부하 테스트 또는 내부 규정 준수 엔드포인트를 호출하는 REST API 호출 검사. 응답을 구문 분석하고 기준이 충족되지 않으면 차단합니다.
릴리스 전에 필수 작업, 버그 또는 변경 요청이 올바른 상태인지 확인하는 작업 항목 쿼리 검사(예: 모든 “반드시 수정” 결함 해결됨). 릴리스 또는 커밋 범위에 맞춰진 쿼리를 사용합니다.

링 경계와 카나리 단계에서 게이트를 구현하여 주관적인 승격 결정에서 측정 가능한 결정으로 전환합니다.

다중 환경 파이프라인, 변수 및 종속성

명시적 종속성 및 환경 범위 지정을 사용하여 다단계 YAML 파이프라인을 설계합니다. 전략 블록(runOnce, rolling, canary)이 있는 배포 작업을 사용하여 점진적 롤아웃을 모델링하고, 자동 롤백을 위한 preDeploy, routeTraffic, postRouteTraffic, on: failure 후크를 포함합니다. 스테이지는 dependsOn 및 조건을 선언하여 이전 환경이 게이트와 승인을 통과한 후에만 이후 환경이 실행되도록 해야 합니다.

다음 방법을 통해 환경별 구성을 관리합니다:

환경별로 범위가 지정되고 비밀 정보 관리를 위해 Azure Key Vault에 연결된 변수 그룹을 사용합니다. 스테이지별로 그룹을 참조하고 민감한 값은 소스 제어에서 제외합니다.
YAML 템플릿과 런타임 매개변수를 사용하여 서비스 전반의 배포를 표준화하고 환경별 값(연결 문자열, 기능 플래그 기본값, Front Door 가중치)을 전달합니다.
appsettings 및 Kubernetes 매니페스트에 대한 토큰화 또는 변환 작업을 사용하여 코드로 관리되는 구성의 드리프트를 방지합니다.

여러 환경에 배포할 때는 프로모션이 포함된 불변 아티팩트를 선호합니다(한 번 빌드하여 여러 번 배포). 작업 항목을 커밋 및 빌드에 연결하여 동일한 아티팩트가 개발에서 프로덕션으로 이동할 때 추적성을 유지하고, 정확한 릴리스 노트와 감사를 가능하게 합니다.

롤백 전략 및 데이터베이스 고려 사항

배포하기 전에 롤백을 계획하십시오:

자동 롤백은 상태 신호를 사용하여 사람의 개입 없이 복구합니다. AKS에서는 maxSurge/maxUnavailable를 보수적으로 설정하고 실패한 롤아웃에 대한 자동 롤백을 활성화합니다. kubectl rollout undo를 사용하거나 배포 전략 실패 후크에 의존하여 이전 ReplicaSet을 트리거합니다. Azure App Service에서는 슬롯 교체 복원이 즉시 이루어집니다. 상태 검사 및 배포 게이트와 함께 사용하여 자동으로 결정하도록 합니다.
수동 롤백은 복구에 운영자의 판단이 필요한 경우(데이터 위험, 부분적 실패)에 적합합니다. Front Door/Traffic Manager 가중치를 재라우팅하거나, 슬롯 교체를 취소하거나, 마지막으로 알려진 정상 빌드를 재배포하는 원클릭 파이프라인 작업을 제공합니다. 이전 아티팩트를 즉시 사용할 수 있도록 유지하고 의사 결정 과정을 문서화합니다.
데이터베이스 롤백은 특별한 주의가 필요합니다. 하위 호환성이 없는 변경을 피하십시오. 확장-축소 패턴을 사용합니다: 읽기/쓰기가 호환되는 동안 컬럼/테이블을 추가하고 데이터를 채웁니다. 필요한 경우 두 스키마에 모두 쓰는 코드를 배포하고, 나중에 사용되지 않는 요소를 제거합니다. Azure SQL Database의 경우 다음을 결합합니다:
- 멱등성을 가지며 버전이 관리되는 스크립트와 배포 전/후 유효성 검사를 포함하는 DACPAC 또는 마이그레이션 프레임워크(EF Core)를 사용합니다.
- 잠금 경합을 최소화하기 위해 온라인 작업(재개 가능한 인덱스 재구축, 파티션 전환)을 사용합니다.
- 데이터 손실 위험을 인지하고 최후의 수단으로 특정 시점 복원 및 활성 지역 복제를 사용합니다. 스키마 다운그레이드 전에 기능 플래그를 통해 기능을 끕니다. Azure Monitor 및 Query Store에서 수집된 데이터베이스 상태(DTU/CPU, 교착 상태)를 기반으로 프로모션을 제어합니다.

Azure App Configuration을 사용한 기능 플래그 및 릴리스 노트 자동화

Azure App Configuration은 .NET, Java, Node.js 등을 위한 SDK를 통해 기능 관리를 중앙 집중화합니다. 레이블을 사용하여 환경 또는 링(ring)별로 플래그 범위를 지정하고, 동적 새로 고침을 활성화하여 앱이 재배포 없이 변경 사항을 적용하도록 할 수 있습니다.

대상 지정 필터를 사용하면 사용자/그룹, 클레임, 디바이스 또는 사용자 지정 특성을 기반으로 세분화된 활성화가 가능합니다. 코호트(예: 내부 테넌트, VIP 고객)를 정의하여 링과 일치시킵니다.
백분율 롤아웃은 기능을 무작위 하위 집합에 점진적으로 노출합니다. 1~5%에서 시작하여 KPI를 검증한 후 단계를 올립니다. Front Door 가중치와 조율하여 사용자 및 트래픽 수준에서 계층화된 제어를 수행합니다.
킬 스위치는 인시던트 발생 시 기능을 즉시 비활성화합니다. 실행에 배포가 필요 없는 전역 ‘끄기’ 토글로 고위험 경로(결제, 데이터 쓰기)를 보호합니다. 감사 및 인시던트와의 상관관계 분석을 위해 모든 토글을 기록합니다.

추적성과 커뮤니케이션을 제공하기 위해 릴리스 노트를 자동화합니다.

커밋 메시지와 PR이 ID를 참조하도록 요구하여 작업 항목 연결을 강제합니다. Azure DevOps는 빌드 및 릴리스를 작업 항목 및 커밋과 자동으로 연결합니다.
파이프라인에서 ‘릴리스 노트 생성’ 작업 또는 REST API 호출을 사용하여 대상 환경에 대한 마지막 성공적인 배포 이후의 변경 사항 및 작업 항목 목록을 생성합니다. 기능, 수정, 주요 변경 사항, 데이터베이스 마이그레이션 섹션이 포함된 Markdown을 출력합니다.
프로젝트 Wiki에 노트를 게시하고, 빌드 아티팩트로 패키징하며, 릴리스에 첨부합니다. 규정 준수를 위해 배포 메타데이터(빌드 번호, 커밋 SHA, 환경, 승인자, 통과한 게이트)를 포함합니다.

실제 문제 시나리오

Adobe는 피크 캠페인 기간 동안 전환율을 위협하지 않으면서 Azure에서 호스팅되는 마케팅 사이트에 새로운 개인화 엔진을 도입해야 합니다. 팀은 자주 배포하고, 기능을 점진적으로 노출하며, SLO를 검증하고, KPI가 저하되면 즉시 롤백해야 합니다.

Azure Deployment Environments로 환경 정의

Git 기반 카탈로그에 앱, AKS, Azure SQL, Front Door를 위한 환경 정의(Bicep)를 생성합니다. 개발자는 안전하게 dev/test 환경을 셀프 프로비저닝하여 프로덕션과의 패리티(parity)를 보장하고 실험을 위한 임시 테스트 스택을 사용할 수 있습니다. ADE는 할당량과 RBAC를 적용하여 비용과 액세스를 제어합니다.

다단계 YAML로 한 번 빌드하고 여러 번 배포

단일 아티팩트가 ring-r0, ring-r1, ring-r2, prod 단계를 거쳐 승격됩니다. 각 단계는 서로 의존하며, 적절한 경우 canary 및 rolling 전략을 사용하는 배포 작업을 통해 링 전반에 걸쳐 일관된 바이너리를 보장합니다.

레거시 웹 티어를 위해 App Service 슬롯으로 블루-그린 배포 사용

스테이징 슬롯에 배포하고, 워밍업한 후, ring-r0 내부 사용자를 위해 교체(swap)합니다. Adobe의 SLO가 저하되면 슬롯을 다시 교체하여 거의 제로 다운타임으로 가장 빠른 롤백을 제공합니다.

Azure Front Door 가중치 라우팅을 통해 카나리 도입

레거시 및 신규 개인화 백엔드를 모두 등록합니다. ring-r1에서 신규 백엔드로 1%의 트래픽부터 시작합니다. Front Door 상태 프로브와 즉각적인 가중치 업데이트를 통해 트래픽 패턴에 맞춰 안전하고 신속한 조정이 가능합니다.

객관적인 검사로 승격 게이트 설정

Application Insights에서 가져온 p95 지연 시간, 오류율, 전환 KPI에 대한 Azure Monitor 검사를 추가합니다. Adobe의 내부 실험 서비스에 대한 REST API 검사를 추가하여 가드레일 메트릭을 확인합니다. 링 승격 전에 “반드시 수정해야 할(Must Fix)” 버그가 해결되었는지 확인하기 위해 작업 항목 쿼리 검사를 구성합니다. 게이트는 주기적으로 평가되며, 중단된 변경을 방지하기 위해 시간 초과됩니다.

중요한 전환 지점에서 승인 요구

ring-r2 및 prod에 대한 배포 전 승인은 마케팅 및 SRE의 서명이 필요하며, 처리되지 않고 남는 릴리스를 피하기 위해 4시간의 시간 제한을 설정합니다. 배포 후 승인은 UAT 및 분석 검증이 완료되었음을 확인한 후 릴리스를 종료합니다.

Azure App Configuration 기능 플래그로 노출 제어

다크 런칭(dark launching)을 구현하여 새로운 엔진이 초기에 존재하지만 비활성화된 상태로 만듭니다. 대상 지정 필터를 사용하여 내부 직원(ring-r0) 및 선택된 고객 코호트(ring-r1)에 대해 활성화합니다. 백분율 롤아웃을 적용하여 노출을 확장합니다. 킬 스위치는 이상 징후가 나타날 경우 재배포 없이 몇 초 만에 엔진을 전역적으로 비활성화합니다.

확장-축소 마이그레이션으로 데이터 보호

추가적인 SQL 변경 사항을 먼저 배포하고, 비동기적으로 데이터를 백필(backfill)하며, 필요한 경우 이중 쓰기(dual-write)를 수행합니다. 안정성이 입증된 후에만 더 이상 사용되지 않는 스키마를 제거합니다. 게이트는 DTU, 교착 상태(deadlock), 장기 실행 쿼리를 모니터링하여 안전하지 않은 승격을 방지합니다.

롤백 경로 자동화

배포 작업의 실패 후크(hook)가 롤백을 트리거합니다: Front Door 가중치가 신규 백엔드에 대해 0%로 돌아가고, App Service는 역방향 슬롯 교체를 수행하며, AKS는 kubectl rollout undo를 실행합니다. 복잡한 시나리오를 위해 운영자는 수동 원클릭 롤백을 계속 사용할 수 있습니다.

릴리스 문서 자동화

파이프라인은 연결된 작업 항목 및 커밋에서 Markdown 릴리스 노트를 생성하여, 활성화된 기능, 데이터베이스 변경 사항, 통과한 게이트를 강조 표시합니다. 노트는 Azure DevOps Wiki에 게시되고 릴리스에 첨부되어 감사 요구 사항을 충족하고 이해관계자에게 가시성을 제공합니다.

이 접근 방식은 각 도구의 강점을 활용합니다: 안전하고 재현 가능한 환경을 위한 ADE; 거버넌스가 적용된 흐름을 위한 YAML 전략 및 승인; 계층화된 점진적 배포를 위한 Front Door 및 App Configuration; 객관적인 품질 관리를 위한 Azure Monitor 및 게이트; 그리고 복원력과 추적성을 위한 자동화된 롤백 및 릴리스 노트.

← 컨테이너화 및 Kubernetes · 모든 도메인 · 보안 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →