이제 계획된 전략에 따라 라이브 Azure 환경에 솔루션을 배포합니다. 이 단계에는 최종 준비, 배포 실행, 배포 후 확인 및 지원이 포함됩니다.
클라우드 네이티브 배포를 위한 관련자 준비
배포 일정 및 예상되는 영향을 발표합니다. 프로덕션 배포를 시작하기 전에 모든 관련 관련자에게 계획 및 가치를 전달합니다. 배포 일정 및 예상 사용자 효과를 알려 줍니다. 예를 들어 새 기능의 경우 가동 중지 시간 또는 사용자가 볼 수 있는 변경 내용을 미리 적어둡니다. 관련자는 비즈니스 이벤트와의 충돌을 식별하거나 타이밍에 대한 우려를 제기할 수 있습니다. 피드백을 위한 채널을 제공하고 배포 창이 운영 우선 순위와 일치하는지 확인합니다. 중단을 방지하기 위해 필요한 경우 일정을 조정합니다.
지원 팀 및 영향을 받는 그룹에 알립니다. 지원 팀이 대기 상태이고 릴리스되는 내용을 인식하여 사용자 문제 또는 문의를 처리할 수 있는지 확인합니다. 배포가 최종 사용자 또는 다른 시스템에 영향을 줄 수 있는 경우 해당 그룹에도 알립니다.
배포 기간 동안 기능에 대한 기대치를 설정합니다. 배포 창에는 기능 감소 또는 일시적인 지연이 포함될 수 있습니다. 혼동을 방지하고 비즈니스 연속성을 보장하기 위해 관련자에게 이러한 조건을 알릴 수 있습니다. 해당하는 경우 대체 절차 또는 해결 방법을 포함합니다.
사전 배포 준비 검토를 수행합니다. 준비 검토는 모든 팀이 자신의 역할을 이해하고 필요한 액세스 권한이 있음을 확인합니다. 각 지원 팀의 담당자와 회의를 열어 배포 계획, 성공 조건 및 롤백 기준을 검토합니다. 지원 팀에 적절한 시스템 액세스 및 모니터링 도구가 구성되어 있는지 확인합니다. 이 준비는 마이그레이션 중에 발생하는 모든 문제에 대한 조정된 응답을 보장합니다.
클라우드 네이티브 배포 작업 실행
배포 단계는 새 독립 실행형 워크로드인지 아니면 기존 시스템에 대한 기능 업데이트인지에 따라 약간 다릅니다.
새 클라우드 네이티브 워크로드 배포
프로덕션 환경을 만듭니다. CI/CD 파이프라인을 사용하여 스테이징에서 테스트된 동일한 구성을 사용하여 프로덕션 배포 파이프라인을 배포합니다. 스테이징에서 유효성 검사를 통과한 동일한 빌드 아티팩트, IaC 템플릿 및 배포 스크립트를 사용합니다. 별도의 환경에 배포하기 때문에 IaC 템플릿을 통해 필요한 모든 Azure 리소스를 만든 다음 애플리케이션 코드 또는 아티팩트를 배포합니다.
연기 테스트. 배포된 후에는 프로덕션 환경에서 스모크 테스트(기본 검사)를 수행하여 모든 서비스가 작동하며 핵심 기능이 라이브 환경에서 작동하는지 확인합니다. 주요 서비스가 실행 중이고, 데이터베이스에 액세스할 수 있고, 애플리케이션이 응답(상태 검사 엔드포인트 또는 몇 개의 키 페이지 적중)되는지 확인합니다. Azure Service Health 에서 구성 요소에 영향을 줄 수 있는 지역의 플랫폼 문제를 확인합니다. 이 테스트는 사용자가 시스템으로 전달되기 전에 검사합니다.
소규모 사용자 그룹에 배포합니다. 작은 사용자 집합에 새 시스템을 노출하여 점진적 롤아웃을 구현합니다. 이 롤아웃은 내부 사용자에게만 기능을 릴리스하거나 적은 비율의 라이브를 새 배포로 라우팅하여 수행할 수 있습니다. 오류 또는 성능 문제를 면밀히 모니터링합니다. Application Insights 및 사용자 지정 대시보드를 사용하여 오류율, 응답 시간 및 리소스 사용률을 실시간으로 확인합니다. 또한 카나리아 버전의 파일럿 사용자로부터 질적 피드백을 수집합니다.
모니터링하고 점진적으로 확장합니다. 점진적 출시는 위험을 줄이고 전체 릴리스 전에 실제 유효성 검사를 허용합니다. 작은 카나리아 사용자 그룹에 애플리케이션을 릴리스합니다. Azure Front Door 또는 Traffic Manager와 같은 부하 분산 장치를 사용하여 트래픽의 하위 집합을 새 배포로 라우팅합니다. 피드백을 수집하고 성능을 모니터링합니다. 유효성 검사에 성공한 후 모든 사용자에 대한 액세스를 강화하거나 엽니다.
기존 워크로드에 새 클라우드 네이티브 기능 배포
기존 클라우드 네이티브 워크로드에 새 기능을 배포하는 경우 위험 허용 범위, 인프라 제약 조건 및 출시 목표에 맞는 배포 전략을 선택합니다. 두 가지 일반적인 방법은 배치 환경 내 배포와 블루-그린(병렬 환경) 배포입니다.
동일한 환경 내에서 점진적으로 배포하기 위해 동일 위치 배포를 사용하세요.
별도의 환경을 프로비전하지 않고 기존 워크로드에 새 기능을 추가할 때 현재 위치 배포를 사용합니다. 이 방법을 사용하면 인프라 오버헤드를 최소화하면서 안전하고 증분 롤아웃할 수 있습니다.
작은 사용자 세그먼트에 기능 사용 기능 플래그 또는 구성 토글을 사용하여 기존 환경에 새 기능을 배포합니다. 먼저 내부 사용자, 베타 테스터 또는 적은 비율의 라이브 트래픽과 같은 제한된 대상 그룹에 이 기능을 사용하도록 설정합니다. 이 방법을 사용하면 문제가 발생할 경우 기능을 신속하게 사용하지 않도록 설정하는 기능을 유지하면서 실제 유효성 검사를 수행할 수 있습니다. 사용자 상호 작용에 태그가 지정되어 기능이 활성화된 세션과 사용하지 않도록 설정된 세션을 구분하여 나란히 비교할 수 있도록 합니다.
스모크 테스트. 배포된 후에는 프로덕션 환경에서 스모크 테스트(기본 검사)를 수행하여 모든 서비스가 작동하며 핵심 기능이 라이브 환경에서 작동하는지 확인합니다. 주요 서비스가 실행 중이고, 데이터베이스에 액세스할 수 있고, 애플리케이션이 응답(상태 검사 엔드포인트 또는 몇 개의 키 페이지 적중)되는지 확인합니다.
모니터링하고 점진적으로 확장합니다. Application Insights 또는 Azure Monitor와 같은 도구를 사용하여 애플리케이션 상태, 성능 및 오류 비율을 지속적으로 모니터링합니다. 변칙을 검색하기 위해 기능이 활성화된 사용자와 사용하지 않는 사용자 간의 메트릭을 비교합니다. 문제가 검색되지 않으면 기능 플래그 출시 비율을 점진적으로 늘리거나 사용자 그룹을 확장합니다. 각 증분 후에 모니터링을 반복합니다. 전체 롤아웃 후 최종 유효성 검사를 수행하여 모든 인스턴스 및 사용자 세그먼트에서 일관된 동작을 보장합니다.
병렬 환경에서 새 기능 배포
병렬 프로덕션 환경에 배포하여 기존 워크로드에 새 기능을 도입할 때 파란색-녹색 배포를 사용합니다. 이 방법은 사용자 트래픽을 새 버전으로 전환하기 전에 전체 유효성 검사를 허용하여 위험을 최소화합니다.
병렬 환경(녹색)을 만듭니다. CI/CD 파이프라인을 사용하여 스테이징에서 테스트된 동일한 구성을 사용하여 프로덕션 배포 파이프라인을 배포합니다. 스테이징에서 유효성 검사를 통과한 동일한 빌드 아티팩트, IaC 템플릿 및 배포 스크립트를 사용합니다. 별도의 환경에 배포하기 때문에 IaC 템플릿을 통해 필요한 모든 Azure 리소스를 만든 다음 애플리케이션 코드 또는 아티팩트를 배포합니다.
스모크 테스트를 통해 병렬 환경을 점검합니다. 배포된 후에는 프로덕션 환경에서 스모크 테스트(기본 검사)를 수행하여 모든 서비스가 작동하며 핵심 기능이 라이브 환경에서 작동하는지 확인합니다. 주요 서비스가 실행 중이고, 데이터베이스에 액세스할 수 있고, 애플리케이션이 응답(상태 검사 엔드포인트 또는 몇 개의 키 페이지 적중)되는지 확인합니다. Azure Service Health 에서 구성 요소에 영향을 줄 수 있는 지역의 플랫폼 문제를 확인합니다. 사용자가 시스템으로 안내되기 전에 이 스모크 테스트는 확인 단계입니다.
트래픽의 하위 집합을 병렬 환경으로 라우팅합니다. 점진적 출시는 위험을 줄이고 전체 릴리스 전에 실제 유효성 검사를 허용합니다. 작은 카나리아 사용자 그룹에 애플리케이션을 릴리스합니다. Azure Front Door 또는 Traffic Manager와 같은 부하 분산 장치를 사용하여 트래픽의 하위 집합을 새 배포로 라우팅합니다. 또는 라우팅 규칙 또는 기능 플래그를 통해 특정 사용자 세그먼트에만 새 기능을 노출합니다. Application Insights 또는 Azure Monitor를 사용하여 성능, 오류 비율 및 사용자 환경을 모니터링합니다. 파란색 환경과 녹색 환경 간의 사용자 트래픽을 비교하여 회귀 또는 변칙을 검색합니다.
모니터링하고 점진적으로 확장합니다. 새 버전의 성능이 좋다면, 부하를 100% 처리할 수 있을 때까지 트래픽 라우팅을 점진적으로 증가시킵니다. "녹색" 배포를 기본 배포로 승격합니다. 이전 "파란색" 배포는 이 프로세스 중에 그대로 유지되므로 롤백이 더 쉬워집니다. 심각한 문제가 발견되면 즉시 모든 트래픽을 안정적인 버전으로 다시 전환할 수 있습니다.
컷오버를 완료합니다. 유효성 검사에 성공하면 모든 사용자를 새 시스템으로 라우팅하거나 숨겨진 경우 라이브로 공식적으로 알릴 수 있습니다. 업데이트된 기능에 대한 이전 환경이 있는 경우 이제 안전한 유효성 검사 기간 후에 서비스 해제를 고려할 수 있습니다.
배포 성공 유효성 검사
새 워크로드 또는 기능을 배포한 후에는 기술적으로나 사용자의 관점에서 시스템이 제대로 작동하는지 확인해야 합니다.
중요한 사용자 경험의 유효성을 검사합니다. 스모크 테스트를 넘어 모든 주요 사용자 흐름이 라이브 환경에서 예상대로 작동하는지 확인합니다. 자동화된 테스트 도구 모음 또는 수동 QA를 사용하여 실제 시나리오의 유효성을 검사합니다. 인증, 트랜잭션 및 데이터 워크플로와 같은 고가용성 경로에 집중합니다. 이 테스트는 배포에서 새 시스템을 도입했는지 아니면 기존 시스템을 개선했는지에 따라 적용됩니다.
백그라운드 프로세스 및 통합을 확인합니다. 백그라운드 프로세스, 통합 및 예약된 작업이 올바르게 실행되고 있는지 확인합니다. 로그, 작업 상태 및 통합 엔드포인트를 확인하여 예상대로 작동하는지 확인합니다. 이 단계에서는 사용자에게 즉시 표시되지 않을 수 있는 자동 오류를 방지합니다.
시스템 상태에 대한 모니터링 대시보드를 검토합니다. Azure Monitor 및 Application Insights를 사용하여 로그 및 메트릭을 검사합니다. 오류 속도, 대기 시간, CPU/메모리 사용량 및 처리량의 변칙을 찾습니다. 모니터링 데이터가 올바르게 흐르고 있고 누락되거나 잘못 라우팅된 데이터가 없는지 확인합니다.
예기치 않은 트리거에 대한 경고를 검사합니다. 오류 속도, 대기 시간 또는 리소스 사용량에 대해 구성된 경고를 검토합니다. 경고가 예기치 않게 발생하지 않는 것을 확인하세요. 경고가 트리거되면 근본 원인을 조사하고 배포 관련 문제를 나타내는지 평가합니다.
관련자 및 사용자 체크 인을 수행합니다. 또한 배포 후 몇 명의 최종 사용자 또는 이해 관계자와 빠른 체크 인을 수행하여 사용자 관점에서 작업하고 있음을 인간적으로 확인하는 것이 좋습니다.
전체 유효성 검사 후에만 배포 완료를 선언합니다. 모든 유효성 검사 단계가 성공하고 시스템이 승인 조건을 충족한 후에만 배포가 완료된 것으로 간주합니다. 문제가 발견되면 중요한 문제를 즉시 해결합니다. 향후 업데이트에서 해결을 위해 사소한 문제를 기록합니다.
안정화 중 워크로드 지원
강화된 모니터링 및 지원 태세를 설정합니다. 프로덕션 환경에 배포하는 것은 여정의 끝이 아닙니다. 실시간 전환 직후 몇 시간 및 며칠 동안 시스템이 실제 부하 하에서 "증가"하는 동안 모니터링과 지원 준비태세를 강화하십시오. 새로운 변경 내용을 가장 잘 알고 있으므로 개발 팀이 운영 팀과 함께 문제를 신속하게 조사하고 해결하도록 하는 것이 좋습니다.
시스템 메트릭 및 사용자 피드백을 지속적으로 추적합니다. 첫 번째 주 또는 두 주를 안정화 기간으로 처리합니다. Azure Monitor 및 Application Insights를 사용하여 CPU, 메모리, 오류 비율 및 응답 시간과 같은 메트릭을 모니터링합니다. 지원 채널 또는 직접 아웃리치를 통해 사용자 피드백을 수집합니다. 이렇게 하면 자동화된 시스템이 놓칠 수 있는 문제를 감지할 수 있습니다.
관찰된 동작에 따라 구성을 조정합니다. 필요한 경우 구성을 조정합니다. 예를 들어 사용량이 예상보다 높은 경우 더 확장합니다. 로그가 너무 상세하거나 너무 부족한 경우 로그 설정을 수정합니다. 이러한 변경은 사용량이 많은 동안 성능 및 관찰성을 유지하는 데 도움이 됩니다. 이 단계에서 검색된 모든 문제가 향후 개선될 수 있도록 추적 시스템에 해결되거나 입력되었는지 확인합니다.
안정화 중에 발견된 모든 문제를 로그 및 심사합니다. 이 활성 지원 단계는 프로덕션 조건에서만 드러나는 문제를 포착하고 워크로드가 진정으로 목표를 충족하는지 확인합니다. 이 안정화 기간이 지나고 시스템의 성능에 대한 확신이 있으면 정상 작업 및 모니터링 절차로 전환할 수 있습니다.
안정화를 위한 종료 조건을 정의합니다. 시스템 성능, 오류 비율 및 사용자 만족도에 대한 명확한 임계값을 설정합니다. 시스템이 이러한 기준을 일관되게 충족하면 표준 작업 및 모니터링 절차로 전환합니다. 이러한 기준은 원활한 인계를 보장하고 지원 단계의 조기 폐쇄를 방지합니다.