Azure의 중요 업무용 워크로드에 대한 배포 및 테스트

실패한 배포 및 잘못된 릴리스는 애플리케이션 중단의 일반적인 원인입니다. 배포 및 테스트에 대한 접근 방식은 중요 업무용 애플리케이션의 전반적인 안정성에 중요한 역할을 합니다.

배포 및 테스트는 중요 업무용 워크로드에 대한 일관된 결과를 보장하기 위해 모든 애플리케이션 및 인프라 운영의 기초가 되어야 합니다. 매주, 매일 또는 더 자주 배포할 준비를 합니다. 이러한 목표를 지원하기 위해 CI/CD(연속 통합 및 지속적인 배포) 파이프라인을 디자인합니다.

전략은 다음을 구현해야 합니다.

• 엄격한 시험판 테스트. 업데이트 애플리케이션 상태를 위태롭게 할 수 있는 결함, 취약성 또는 기타 요인을 도입해서는 안 됩니다.

• 투명한 배포. 사용자에게 영향을 주지 않고 언제든지 업데이트를 롤아웃할 수 있어야 합니다. 사용자는 중단 없이 애플리케이션과의 상호 작용을 계속할 수 있어야 합니다.

• 고가용성 작업. 전반적인 애플리케이션 안정성을 지원하려면 배포 및 테스트 프로세스 및 도구를 고가용성으로 사용해야 합니다.

• 일관된 배포 프로세스. 여러 환경에 인프라 및 애플리케이션 코드를 배포하는 데 동일한 애플리케이션 아티팩트 및 프로세스를 사용해야 합니다. 엔드 투 엔드 자동화는 필수입니다. 수동 개입은 안정성 위험을 초래할 수 있으므로 피해야 합니다.

이 디자인 영역에서는 가동 중지 시간을 최소화하고 애플리케이션 상태 및 가용성을 유지하기 위해 배포 및 테스트 프로세스를 최적화하는 방법에 대한 권장 사항을 제공합니다.

중요

이 문서는 Azure Well-Architected Framework 중요 업무용 워크로드 시리즈의 일부입니다. 이 시리즈에 익숙하지 않은 경우 중요 업무용 워크로드란?으로 시작하는 것이 좋습니다.

가동 중지 시간 없는 배포

가동 중지 시간 없는 배포에 대한 개요는 다음 비디오를 참조하세요.

가동 중지 시간 없는 배포를 달성하는 것은 중요 업무용 애플리케이션의 기본 목표입니다. 업무 시간 동안 새 릴리스가 출시되더라도 애플리케이션을 하루 종일 사용할 수 있어야 합니다. 리소스를 임시로 처리할지 여부와 같은 주요 디자인 결정을 추진하기 위해 배포 프로세스를 정의하고 계획하기 위해 노력을 미리 투자하세요.

가동 중지 시간 배포를 수행하려면 기존 인프라 옆에 새 인프라를 배포하고, 철저히 테스트하고, 최종 사용자 트래픽을 전환한 다음, 이전 인프라의 서비스 해제만 수행합니다. 배율 단위 아키텍처와 같은 다른 사례도 중요합니다.

중요 업무용 온라인 및 Azure Mission-Critical 연결된 참조 구현은 다음 다이어그램과 같이 이 배포 방법을 보여 줍니다.

애플리케이션 환경

애플리케이션 환경에 대한 권장 사항에 대한 개요는 다음 비디오를 참조하세요.

배포 작업의 유효성을 검사하고 스테이징하려면 다양한 유형의 환경이 필요합니다. 형식에는 다양한 기능과 수명 주기가 있습니다. 일부 환경은 프로덕션 환경을 반영하고 수명이 길어질 수 있으며, 다른 환경은 수명이 짧고 프로덕션보다 기능이 적을 수 있습니다. 개발 주기 초기에 이러한 환경을 설정하면 프로덕션 환경에 릴리스하기 전에 민첩성, 프로덕션 및 사전 프로덕션 자산 분리 및 운영의 철저한 테스트를 보장하는 데 도움이 됩니다. 필요에 따라 낮은 환경에 간소화를 적용할 수 있지만 모든 환경은 프로덕션 환경을 최대한 많이 반영해야 합니다. 이 다이어그램은 중요 업무용 아키텍처를 보여줍니다.

몇 가지 일반적인 고려 사항이 있습니다.

• 구성 요소는 환경 간에 공유해서는 안 됩니다. 가능한 예외는 가상 테스트 데이터의 방화벽 및 원본 위치와 같은 다운스트림 보안 어플라이언스입니다.

• 모든 환경에서는 Terraform 또는 ARM(Azure Resource Manager) 템플릿과 같은 IaC(Infrastructure as Code) 아티팩트 를 사용해야 합니다.

개발 환경

임시 개발 환경 및 자동화된 기능 유효성 검사에 대한 자세한 내용은 다음 비디오를 참조하세요.

디자인 고려 사항

• 기능. 안정성, 용량 및 보안에 대한 낮은 요구 사항은 개발 환경에 허용됩니다.

• 수명 주기. 개발 환경은 필요에 따라 만들어지고 짧은 시간 동안 존재해야 합니다. 수명 주기가 짧을수록 코드 기반에서 구성 드리프트를 방지하고 비용을 절감할 수 있습니다. 또한 개발 환경은 종종 기능 분기 수명 주기를 공유합니다.

• 밀도. 팀은 병렬 기능 개발을 지원하기 위해 여러 환경이 필요합니다. 단일 구독 내에서 공존할 수 있습니다.

디자인 권장 사항

• 개발 목적으로 컨텍스트가 설정된 전용 구독에 환경을 유지합니다.

• 자동화된 프로세스를 사용하여 기능 분기 개발 환경으로 코드를 배포합니다.

테스트 또는 스테이징 환경

이러한 환경은 테스트 및 유효성 검사에 사용됩니다. 프로덕션에 버그가 없는 배포를 보장하기 위해 많은 테스트 주기가 수행됩니다. 중요 업무용 워크로드에 대한 적절한 테스트는 지속적인 유효성 검사 및 테스트 섹션에 설명되어 있습니다.

디자인 고려 사항

• 기능. 이러한 환경은 안정성, 용량 및 보안을 위해 프로덕션 환경을 반영해야 합니다. 프로덕션 부하가 없는 경우 가상 사용자 로드를 사용하여 현실적인 메트릭과 중요한 상태 모델링 입력을 제공합니다.

• 수명 주기. 이러한 환경은 수명이 짧습니다. 테스트 유효성 검사가 완료된 후에 제거해야 합니다.

• 밀도. 하나의 구독에서 많은 독립 환경을 실행할 수 있습니다. 또한 전용 구독에서 각각 여러 환경을 사용하는 것도 고려해야 합니다.

참고

중요 업무용 애플리케이션은 엄격한 테스트를 받아야 합니다.

단일 환경에서 다른 테스트 함수를 수행할 수 있으며 경우에 따라 수행해야 합니다. 예를 들어 의미 있는 결과를 제공하기 위해 비정상 상황 테스트의 경우 애플리케이션이 삽입된 오류에 어떻게 반응하는지 이해할 수 있도록 먼저 애플리케이션을 로드에 배치해야 합니다. 이것이 바로 카오스 테스트 및 부하 테스트가 일반적으로 병렬로 수행되는 이유입니다.

디자인 권장 사항

• 하나 이상의 스테이징 환경이 프로덕션과 유사한 테스트 및 유효성 검사를 사용하도록 프로덕션을 완전히 반영하는지 확인합니다. 이 환경 내의 용량은 테스트 작업의 실행에 따라 유연할 수 있습니다.

• 가상 사용자 로드를 생성하여 환경 중 하나의 변경 내용에 대한 현실적인 테스트 사례를 제공합니다.

  참고

  중요 업무용 온라인 참조 구현은 사용자 부하 생성기의 예를 제공합니다.

• 개발 및 릴리스 주기 내에서 스테이징 환경의 수와 해당 용도를 정의합니다.

프로덕션 환경

디자인 고려 사항

• 기능. 애플리케이션에 대한 최고 수준의 안정성, 용량 및 보안 기능이 필요합니다.

• 수명 주기. 워크로드와 인프라의 수명 주기는 동일하게 유지되지만 모니터링 및 로깅을 포함한 모든 데이터에는 특별한 관리가 필요합니다. 예를 들어 백업 및 복구를 위해서는 관리가 필요합니다.

• 밀도. 일부 애플리케이션의 경우 다른 클라이언트, 사용자 또는 비즈니스 기능을 수용하기 위해 다른 프로덕션 환경을 사용하는 것이 좋습니다.

디자인 권장 사항

프로덕션 및 하위 환경에 대한 명확한 거버넌스 경계를 갖습니다. 각 환경 유형을 전용 구독에 배치하여 해당 목표를 달성합니다. 이 세분화는 낮은 환경의 리소스 사용률이 프로덕션 할당량에 영향을 주지 않도록 합니다. 전용 구독도 액세스 경계를 설정합니다.

임시 파란색/녹색 배포

파란색/녹색 배포 모델에는 두 개 이상의 동일한 배포가 필요합니다. 파란색 배포는 프로덕션 환경에서 사용자 트래픽을 제공하는 활성 배포입니다. 녹색 배포는 트래픽을 수신하도록 준비 및 테스트된 새로운 배포입니다. 녹색 배포가 완료되고 테스트되면 트래픽이 파란색에서 녹색으로 점진적으로 전달됩니다. 부하 전송에 성공하면 녹색 배포가 새 활성 배포가 됩니다. 그런 다음, 단계적 프로세스를 통해 이전 파란색 배포를 해제할 수 있습니다. 그러나 새 배포에 문제가 있는 경우 중단될 수 있으며 트래픽은 이전 파란색 배포에 남아 있거나 리디렉션될 수 있습니다.

Azure Mission-Critical 인프라 와 애플리케이션 이 배포 스탬프의 일부로 함께 배포되는 파란색/녹색 배포 방법을 권장합니다. 따라서 인프라 또는 애플리케이션에 대한 변경 사항을 롤아웃하면 항상 두 계층이 모두 포함된 녹색 배포가 발생합니다. 이 방법을 사용하면 사용자 트래픽을 리디렉션하기 전에 인프라 및 애플리케이션 엔드투엔드에 대한 변경의 영향을 완전히 테스트하고 유효성을 검사할 수 있습니다. Azure 플랫폼, 리소스 공급자 및 IaC 모듈과 같은 다운스트림 종속성과의 호환성이 유효성을 검사할 수 있으므로 이 접근 방식은 변경 내용을 릴리스하는 것에 대한 신뢰를 높이고 가동 중지 시간 업그레이드를 제로 가동 중지할 수 있도록 합니다.

디자인 고려 사항

• 기술 기능. Azure 서비스의 기본 제공 배포 기능을 활용합니다. 예를 들어 Azure App Service 배포 후 교환할 수 있는 보조 배포 슬롯을 제공합니다. AKS(Azure Kubernetes Service)를 사용하면 각 노드에서 별도의 Pod 배포를 사용하고 서비스 정의를 업데이트할 수 있습니다.

• 배포 기간. 스탬프에 변경된 구성 요소 대신 인프라 및 애플리케이션이 포함되어 있으므로 배포를 완료하는 데 시간이 더 오래 걸릴 수 있습니다. 그러나 모든 구성 요소가 예상대로 작동하지 않을 위험이 시간 문제를 재정의하기 때문에 이는 허용됩니다.

• 비용 영향. 배포가 완료될 때까지 공존해야 하는 두 개의 병렬 배포로 인해 추가 비용이 발생합니다.

• 트래픽 전환. 새 배포의 유효성을 검사한 후에는 트래픽을 파란색 환경에서 녹색 환경으로 전환해야 합니다. 이 전환에는 환경 간의 사용자 트래픽 오케스트레이션이 필요합니다. 전환은 완전히 자동화되어야 합니다.

• 수명 주기. 중요 업무용 배포 스탬프는 임시로 간주되어야 합니다. 수명이 짧은 스탬프를 사용하면 리소스가 프로비전되기 전에 매번 새로운 시작이 만들어집니다.

디자인 권장 사항

• 파란색/녹색 배포 접근 방식을 채택하여 모든 프로덕션 변경 내용을 릴리스합니다. 모든 유형의 변경에 대해 매번 모든 인프라와 애플리케이션을 배포하여 일관된 상태와 가동 중지 시간을 달성합니다. 환경을 재사용할 수 있지만 중요 업무용 워크로드에는 사용하지 않는 것이 좋습니다. 단일 릴리스와 연결된 수명 주기를 사용하여 각 지역 배포 스탬프를 임시로 처리합니다.

• Azure Front Door와 같은 전역 부하 분산 장치를 사용하여 파란색 환경과 녹색 환경 간의 사용자 트래픽의 자동화된 전환을 오케스트레이션합니다.

• 트래픽을 전환하려면 낮은 트래픽을 사용하는 녹색 백 엔드 엔드포인트를 볼륨 가중치(예: 10%)에 추가합니다. 녹색 배포의 낮은 트래픽 볼륨이 작동하고 예상되는 애플리케이션 상태를 제공하면 트래픽이 점진적으로 증가합니다. 이렇게 하는 동안 즉시 명확하지 않을 수 있는 오류를 catch하기 위해 짧은 램프업 기간을 적용합니다.

  모든 트래픽이 전환된 후 기존 연결에서 파란색 백 엔드를 제거합니다. instance 경우 전역 부하 분산 장치 서비스에서 백 엔드를 제거하고 큐를 드레이닝하고 다른 연결을 분리합니다. 이렇게 하면 보조 프로덕션 인프라 유지 관리 비용을 최적화하고 새 환경에 구성 드리프트가 없는지 확인하는 데 도움이 됩니다.

  이 시점에서 이전 환경과 비활성 파란색 환경을 해제합니다. 다음 배포의 경우 파란색과 녹색이 반전된 프로세스를 반복합니다.

구독 범위 배포

애플리케이션의 크기 조정 요구 사항에 따라 크기 조정 단위로 사용하려면 여러 프로덕션 구독이 필요할 수 있습니다.

다음 비디오를 확인하여 중요 업무용 애플리케이션에 대한 구독 범위 지정에 대한 권장 사항 개요를 확인합니다.

디자인 고려 사항

• 확장성. 트래픽이 많은 대규모 애플리케이션 시나리오의 경우 단일 구독의 크기 조정 제한이 확장성을 제한하지 않도록 여러 Azure 구독에서 스케일링할 솔루션을 디자인합니다.

  중요

  여러 구독을 사용하려면 적절한 관리가 필요한 추가 CI/CD 복잡성이 필요합니다. 따라서 단일 구독의 제한이 제한될 수 있는 극단적인 규모의 시나리오에서만 여러 구독을 권장합니다.

• 환경 경계. 프로덕션, 개발 및 테스트 환경을 별도의 구독에 배포합니다. 이렇게 하면 낮은 환경이 규모 제한에 영향을 주지 않습니다. 또한 명확한 관리 및 ID 경계를 제공하여 낮은 환경 업데이트의 프로덕션 오염 위험을 줄입니다.

• 거버넌스. 여러 프로덕션 구독이 필요한 경우 전용 애플리케이션 관리 그룹을 사용하여 정책 집계 경계를 통해 정책 할당을 간소화하는 것이 좋습니다.

디자인 권장 사항

• 전용 구독에 각 지역 배포 스탬프를 배포하여 구독 제한이 애플리케이션 전체에 걸쳐 있지 않고 단일 배포 스탬프의 컨텍스트 내에서만 적용되도록 합니다. 적절한 경우 단일 지역 내에서 여러 배포 스탬프를 사용하는 것을 고려할 수 있지만 독립적인 구독에 배포해야 합니다.

• 일관된 지역 구독 배포를 사용하도록 전용 구독에 전역 공유 리소스를 배치합니다. 주 지역에 특수 배포를 사용하지 않습니다.

지속적인 유효성 검사 및 테스트

테스트는 애플리케이션 코드 및 인프라의 상태를 완전히 확인할 수 있는 중요한 활동입니다. 더 구체적으로 말하면 테스트를 통해 안정성, 성능, 가용성, 보안, 품질 및 규모에 대한 표준을 충족할 수 있습니다. 테스트는 애플리케이션 디자인 및 DevOps 전략의 일부로 잘 정의되고 적용되어야 합니다. 테스트는 로컬 개발자 프로세스( 내부 루프)와 전체 DevOps 수명 주기( 외부 루프)의 일부로 릴리스 파이프라인 프로세스에서 프로덕션 환경으로의 경로에서 코드가 시작되는 주요 관심사입니다.

연속 유효성 검사 및 테스트에 대한 개요를 보려면 다음 비디오를 봅니다.

이 섹션에서는 외부 루프 테스트에 중점을 둡니다. 다양한 유형의 테스트에 대해 설명합니다.

테스트	설명
유닛 테스트	애플리케이션 비즈니스 논리가 예상대로 작동하는지 확인합니다. 코드 변경의 전반적인 효과의 유효성을 검사합니다.
연기 테스트	인프라 및 애플리케이션 구성 요소를 사용할 수 있고 예상대로 작동하는지 여부를 식별합니다. 일반적으로 단일 가상 사용자 세션만 테스트됩니다. 결과는 시스템이 예상 값과 동작으로 응답하는 것입니다. 일반적인 스모크 테스트 시나리오에는 웹 애플리케이션의 HTTPS 엔드포인트에 도달하고, 데이터베이스를 쿼리하고, 애플리케이션에서 사용자 흐름을 시뮬레이션하는 것이 포함됩니다.
UI 테스트	애플리케이션 사용자 인터페이스가 배포되고 사용자 인터페이스 상호 작용이 예상대로 작동하는지 확인합니다. UI 자동화 도구를 사용하여 자동화를 추진해야 합니다. UI 테스트 중에 스크립트는 실제 사용자 시나리오를 모방하고 작업을 실행하고 의도한 결과를 달성하는 일련의 단계를 완료해야 합니다.
부하 테스트	미리 결정된 임계값에 도달할 때까지 부하를 빠르게 증가시키고/또는 점진적으로 증가시켜 확장성 및 애플리케이션 작업의 유효성을 검사합니다. 부하 테스트는 일반적으로 정의된 부하에서 애플리케이션 요구 사항이 충족되는지 확인하기 위해 특정 사용자 흐름을 중심으로 설계되었습니다.
스트레스 테스트	기존 리소스를 오버로드하는 활동을 적용하여 솔루션 제한을 확인하고 시스템이 정상적으로 복구할 수 있는지 확인합니다. 기본 목표는 잠재적인 성능 병목 상태 및 확장 제한을 식별하는 것입니다. 반대로 시스템의 컴퓨팅 리소스를 축소하고 로드 시 작동 방식을 모니터링하고 복구할 수 있는지 여부를 결정합니다.
성능 테스트	부하 및 스트레스 테스트의 측면을 결합하여 부하에서 성능의 유효성을 검사하고 애플리케이션 작업에 대한 벤치마크 동작을 설정합니다.
카오스 테스트	인공 오류를 시스템에 삽입하여 반응 방식을 평가하고 복원력 측정, 운영 절차 및 완화의 효과의 유효성을 검사합니다. 인프라 구성 요소를 종료하고, 의도적으로 성능을 저하시키고, 애플리케이션 오류를 도입하는 것은 시나리오가 실제로 발생할 때 애플리케이션이 예상대로 반응하는지 확인하는 데 사용할 수 있는 테스트의 예입니다.
침투 테스트	애플리케이션 및 해당 환경이 예상되는 보안 상태의 요구 사항을 충족하는지 확인합니다. 목표는 보안 취약성을 식별하는 것입니다. 보안 테스트에는 알려진 CVE(Common Vulnerabilities and Exposures)에 대한 검사 및 모니터링을 통해 엔드투엔드 소프트웨어 공급망 및 패키지 종속성이 포함될 수 있습니다.

디자인 고려 사항

• 자동화. 자동화된 테스트는 애플리케이션 또는 인프라 변경 내용을 시기적절하고 반복 가능한 방식으로 유효성을 검사하는 데 필수적입니다.

• 테스트 순서. 테스트가 수행되는 순서는 실행 중인 애플리케이션 환경의 필요성과 같은 다양한 종속성 때문에 중요한 고려 사항입니다. 테스트 기간도 순서에 영향을 줍니다. 실행 시간이 짧은 테스트는 테스트 효율성을 높이기 위해 가능한 경우 주기 초기에 실행되어야 합니다.

• 확장성 제한. Azure 서비스에는 소프트 및 하드 제한이 다릅니다. 부하 테스트를 사용하여 예상되는 프로덕션 부하 중에 시스템이 부하를 초과할 위험이 있는지 여부를 확인하는 것이 좋습니다. 부하 테스트는 자동 크기 조정에 적절한 임계값을 설정하는 데 유용할 수도 있습니다. 자동 크기 조정을 지원하지 않는 서비스의 경우 부하 테스트를 통해 자동화된 운영 절차를 미세 조정할 수 있습니다.

  활성/수동 네트워크 구성 요소 또는 데이터베이스와 같은 시스템 구성 요소가 적절하게 스케일링되지 않는 것은 제한적일 수 있습니다. 스트레스 테스트는 제한 사항을 식별하는 데 도움이 될 수 있습니다.

• 실패 모드 분석. 애플리케이션 및 기본 인프라에 오류를 도입하고 효과를 평가하는 것은 솔루션의 중복 메커니즘을 평가하는 데 필수적입니다. 이 분석 중에 영향의 위험, 영향 및 폭(부분 또는 전체 중단)을 식별합니다. 중요 업무용 온라인 참조 구현을 위해 만들어진 예제 분석은 개별 구성 요소의 중단 위험을 참조하세요.

• 모니터링. 테스트 결과를 개별적으로 캡처 및 분석하고 집계하여 시간에 따른 추세를 평가해야 합니다. 정확도 및 적용 범위에 대한 테스트 결과를 지속적으로 평가해야 합니다.

디자인 권장 사항

복원력 테스트를 Azure DevOps CI/CD 파이프라인과 통합하는 방법을 보려면 다음 비디오를 참조하세요.

• 인프라 및 애플리케이션 구성 요소에 대한 모든 테스트를 자동화하여 일관성을 보장합니다. CI/CD 파이프라인에서 테스트를 통합하여 해당하는 경우 오케스트레이션하고 실행합니다. 기술 옵션에 대한 자세한 내용은 DevOps 도구를 참조하세요.

• 모든 테스트 아티팩트 를 코드로 처리합니다. 다른 애플리케이션 코드 아티팩트와 함께 유지 관리 및 버전을 제어해야 합니다.

• 배포 및 테스트 주기를 위해 테스트 인프라의 SLA를 SLA와 정렬합니다.

• 모든 배포의 일부로 스모크 테스트를 실행합니다. 또한 스트레스 및 비정상 상황 테스트와 함께 광범위한 부하 테스트를 실행하여 애플리케이션 성능 및 작동성이 유지 관리되고 있는지 확인합니다.

  • 실제 최대 사용 패턴을 반영하는 부하 프로필을 사용합니다.
  • 부하 테스트와 동시에 비정상 상황 실험 및 실패 주입 테스트를 실행합니다.

  팁

  Azure Chaos Studio 는 기본 카오스 실험 도구 모음입니다. 이 도구를 사용하면 비정상 상황 실험을 쉽게 수행하고 Azure 서비스 및 애플리케이션 구성 요소 내에서 오류를 삽입할 수 있습니다.

  Chaos Studio는 일반적인 오류 시나리오에 대한 기본 제공 비정상 상황 실험을 제공하고 인프라 및 애플리케이션 구성 요소를 대상으로 하는 사용자 지정 실험을 지원합니다.

• 부하 또는 스모크 테스트에 레코드 만들기와 같은 데이터베이스 상호 작용이 필요한 경우 권한이 감소된 테스트 계정을 사용하고 실제 사용자 콘텐츠에서 테스트 데이터를 분리할 수 있도록 합니다.

• 알려진 CVE에 대한 엔드 투 엔드 소프트웨어 공급망 및 패키지 종속성을 검사하고 모니터링합니다.

  • GitHub 리포지토리용 Dependabot 을 사용하여 리포지토리가 의존하는 최신 패키지 및 애플리케이션 릴리스로 리포지토리가 자동으로 최신 상태로 유지되도록 합니다.

코드 배포로서의 인프라

IaC(Infrastructure as code)는 인프라 정의를 다른 애플리케이션 아티팩트와 함께 제어되는 소스 코드로 처리합니다. IaC를 사용하면 환경 전반에서 코드 일관성이 향상되고, 자동화된 배포 중에 인적 오류의 위험을 제거하고, 추적 및 롤백을 제공합니다. 파란색/녹색 배포의 경우 완전히 자동화된 배포에서 IaC를 사용하는 것이 필수적입니다.

중요 업무용 IaC 리포지토리에는 전역 및 지역 리소스에 매핑되는 두 가지 고유한 정의가 있습니다. 이러한 유형의 리소스에 대한 자세한 내용은 핵심 아키텍처 패턴을 참조하세요.

디자인 고려 사항

• 반복 가능한 인프라. 매번 동일한 환경을 생성하는 방식으로 중요 업무용 워크로드를 배포합니다. IaC는 기본 모델이어야 합니다.

• 자동화. 모든 배포는 완전히 자동화되어야 합니다. 인적 프로세스는 오류가 발생하기 쉽습니다.

디자인 권장 사항

• IaC를 적용하여 모든 Azure 리소스가 선언적 템플릿에 정의되고 소스 제어 리포지토리에서 유지 관리되도록 합니다. 템플릿이 배포되고 리소스가 CI/CD 파이프라인을 통해 소스 제어에서 자동으로 프로비전됩니다. 명령적 스크립트를 사용하지 않는 것이 좋습니다.

• 모든 환경에 대해 수동 작업을 금지합니다. 유일한 예외는 완전히 독립적인 개발자 환경입니다.

DevOps 도구

DevOps 프로세스가 전체 함수 및 애플리케이션 디자인에 영향을 주므로 배포 도구를 효과적으로 사용하는 것이 전반적인 안정성에 매우 중요합니다. 예를 들어 장애 조치(failover) 및 크기 조정 작업은 DevOps 도구에서 제공하는 자동화에 따라 달라질 수 있습니다. 엔지니어링 팀은 전체 워크로드와 관련하여 배포 서비스를 사용할 수 없다는 영향을 이해해야 합니다. 배포 도구는 안정적이고 고가용성이어야 합니다.

Microsoft는 중요 업무용 애플리케이션을 효과적으로 배포하고 관리할 수 있는 두 개의 Azure 네이티브 도구 집합인 GitHub Actions 및 Azure Pipelines를 제공합니다.

디자인 고려 사항

• 기술 기능. GitHub 및 Azure DevOps의 기능은 겹칩니다. 둘 다 최대한 활용하기 위해 함께 사용할 수 있습니다. 일반적인 방법은 배포에 Azure Pipelines를 사용하는 동안 GitHub.com 또는 GitHub AE 에 코드 리포지토리를 저장하는 것입니다.

  여러 기술을 사용할 때 추가되는 복잡성에 유의하세요. 전반적인 안정성에 대해 풍부한 기능 집합을 평가합니다.

• 지역 가용성. 최대 안정성 측면에서 단일 Azure 지역에 대한 종속성은 운영 위험을 나타냅니다.

  예를 들어 트래픽이 지역 1 및 지역 2의 두 지역에 분산되어 있다고 가정합니다. 지역 2는 Azure DevOps 도구 instance 호스트합니다. 지역 2에 중단이 있고 instance 사용할 수 없다고 가정합니다. 지역 1은 모든 트래픽을 자동으로 처리하며 적절한 장애 조치(failover) 환경을 제공하기 위해 추가 배율 단위를 배포해야 합니다. 그러나 지역 2의 Azure DevOps 종속성으로 인해 수행할 수 없습니다.

• 데이터 복제. 메타데이터, 파이프라인 및 소스 코드를 포함한 데이터는 지역 간에 복제되어야 합니다.

디자인 권장 사항

• 두 기술 모두 단일 Azure 지역에서 호스트되어 재해 복구 전략을 제한적으로 만들 수 있습니다.

  GitHub Actions 빌드 작업(연속 통합)에 적합하지만 복잡한 배포 작업(지속적인 배포)에 대한 기능이 부족할 수 있습니다. Azure DevOps의 풍부한 기능 집합을 고려할 때 중요 업무용 배포에 권장됩니다. 그러나 장만을 평가한 후에는 선택해야 합니다.

• 배포 도구에 대한 가용성 SLA를 정의하고 더 광범위한 애플리케이션 안정성 요구 사항에 맞게 조정합니다.

• 활성/수동 또는 활성/활성 배포 구성을 사용하는 다중 지역 시나리오의 경우 배포 도구 집합을 호스팅하는 주 지역을 사용할 수 없게 되더라도 장애 조치(failover) 오케스트레이션 및 크기 조정 작업이 계속 작동할 수 있는지 확인합니다.

분기 전략

분기하는 데는 여러 가지 유효한 방법이 있습니다. 최대 안정성을 보장하는 전략을 선택해야 합니다. 좋은 전략은 병렬 개발을 가능하게 하고, 개발에서 프로덕션으로의 명확한 경로를 제공하며, 빠른 릴리스를 지원합니다.

디자인 고려 사항

• 액세스를 최소화합니다. 개발자는 기능/* 및 수정/* 분기에서 작업을 수행해야 합니다. 이러한 분기는 변경의 진입점이 됩니다. 역할 기반 제한은 분기 전략의 일부로 분기에 적용해야 합니다. 예를 들어 관리자만 릴리스 분기를 만들거나 분기에 대한 명명 규칙을 적용할 수 있습니다.

• 비상 사태에 대한 가속화된 프로세스입니다. 분기 전략을 사용하면 핫픽스를 최대한 빨리 기본 병합할 수 있습니다. 이렇게 하면 향후 릴리스에 수정 사항이 포함되며 문제의 되풀이는 방지됩니다. 긴급한 문제를 해결하는 사소한 변경에 대해서만 이 프로세스를 사용하고 제한과 함께 사용합니다.

디자인 권장 사항

• 소스 제어에 GitHub의 사용 우선 순위를 지정합니다.

  중요

  기능 작업 및 릴리스를 최소한으로 자세히 설명하는 분기 전략을 만들고 분기 정책 및 권한을 사용하여 전략이 적절하게 적용되도록 합니다.

• 자동화된 테스트 프로세스를 트리거하여 코드 변경 기여 수락되기 전에 유효성을 검사합니다. 팀 구성원도 변경 내용을 검토해야 합니다.

• 기본 분기를 통합 테스트에 주로 사용되는 지속적으로 앞으로 이동하고 안정적인 분기로 처리합니다.

  • PR을 통해서만 기본 변경해야 합니다. 분기 정책을 사용하여 직접 커밋을 금지합니다.
  • PR이 기본 병합할 때마다 통합 환경에 대한 배포가 자동으로 시작됩니다.
  • 기본 분기는 안정적인 것으로 간주되어야 합니다. 언제든지 기본 릴리스를 만드는 것이 안전해야 합니다.

• 기본 분기에서 만들어지고 프로덕션 환경에 배포하는 데 사용되는 전용 릴리스/* 분기를 사용합니다. release/* 분기는 리포지토리에 남아 있어야 하며 릴리스를 패치하는 데 사용할 수 있습니다.

• 핫픽스 프로세스를 문서화하고 필요한 경우에만 사용합니다. 릴리스 분기로 후속 병합 및 프로덕션에 배포하기 위한 fix/* 분기에 핫픽스를 만듭니다.

DevOps용 AI

CI/CD 파이프라인에 AIOps 방법론을 적용하여 기존 테스트 방법을 보완할 수 있습니다. 이렇게 하면 잠재적인 회귀 또는 저하를 감지할 수 있으며 잠재적인 부정적인 영향을 방지하기 위해 배포를 선제적으로 중지할 수 있습니다.

디자인 고려 사항

• 원격 분석 데이터의 볼륨입니다. CI/CD 파이프라인 및 DevOps 프로세스는 기계 학습 모델에 대한 다양한 원격 분석을 내보낸다. 원격 분석은 테스트 결과 및 배포 결과에서 복합 배포 단계의 테스트 구성 요소에 대한 운영 데이터에 이르기까지 다양합니다.

• 확장성. ETL(추출, 변환, 로드)과 같은 기존 데이터 처리 방법은 배포 원격 분석 및 애플리케이션 가시성 데이터의 증가를 따라잡기 위해 처리량을 조정하지 못할 수 있습니다. 데이터 가상화와 같은 ETL 및 데이터 이동이 필요하지 않은 최신 분석 접근 방식을 사용하여 AIOps 모델에서 지속적인 분석을 수행할 수 있습니다.

• 배포가 변경되었습니다. 배포 결과와 자동화된 분석 및 상관 관계를 위해 배포 변경 내용을 저장해야 합니다.

디자인 권장 사항

• 수집할 DevOps 프로세스 데이터 및 분석 방법을 정의합니다. 각 배포 내에서 변경된 테스트 실행 메트릭 및 시계열 데이터와 같은 원격 분석이 중요합니다.

  • AIOps 모델 내에서 분석 및 상관 관계를 위해 스테이징, 테스트 및 프로덕션 환경에서 애플리케이션 가시성 데이터를 노출합니다.

• MLOps 워크플로를 채택합니다.

• 컨텍스트 인식 및 종속성을 인식하는 분석 모델을 개발하여 스키마 및 동작 변경을 해결하기 위한 자동화된 기능 엔지니어링을 통해 예측을 제공합니다.

• 배포 파이프라인 내에서 가장 잘 학습된 모델을 등록하고 배포하여 모델을 운영합니다.

다음 단계

보안 고려 사항을 검토합니다.

보안