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

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

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

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

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

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

• 고가용성 작업. 배포 및 테스트 프로세스 및 도구는 전체 애플리케이션 안정성을 지원하기 위해 고가용성이어야 합니다.

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

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

Important

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

가동 중지 시간 없는 배포

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

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

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

중요 업무용 온라인 및 Azure 중요 업무용 연결 참조 구현은 이 다이어그램에 표시된 대로 이 배포 방법을 보여 줍니다.

애플리케이션 환경

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

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

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

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

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

개발 환경

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

디자인 고려 사항

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

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

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

디자인 권장 사항

• 개발 목적으로 컨텍스트 집합을 사용하여 전용 구독에 환경을 유지합니다.

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

테스트 또는 스테이징 환경

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

디자인 고려 사항

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

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

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

참고 항목

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

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

디자인 권장 사항

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

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

  참고 항목

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

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

프로덕션 환경

디자인 고려 사항

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

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

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

디자인 권장 사항

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

임시 파란색/녹색 배포

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

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

디자인 고려 사항

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

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

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

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

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

디자인 권장 사항

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

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

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

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

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

구독 범위 배포

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

중요 업무용 애플리케이션에 대한 구독 범위 지정에 대한 권장 사항의 개요를 보려면 다음 비디오를 참조하세요.

디자인 고려 사항

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

  Important

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

• 환경 경계. 프로덕션, 개발 및 테스트 환경을 별도의 구독에 배포합니다. 이렇게 하면 더 낮은 환경이 확장 제한에 기여하지 않습니다. 또한 명확한 관리 및 ID 경계를 제공하여 낮은 환경 업데이트로 인해 생산이 오염될 위험이 줄어듭니다.

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

디자인 권장 사항

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

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

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

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

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

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

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

디자인 고려 사항

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

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

• 확장성 제한. 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 도구 인스턴스를 호스트합니다. 지역 2에 중단이 있고 인스턴스를 사용할 수 없다고 가정합니다. 지역 1은 모든 트래픽을 자동으로 처리하며 적절한 장애 조치(failover) 환경을 제공하기 위해 추가 배율 단위를 배포해야 합니다. 그러나 지역 2의 Azure DevOps 종속성 때문에 수행할 수 없습니다.

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

디자인 권장 사항

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

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

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

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

분기 전략

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

디자인 고려 사항

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

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

디자인 권장 사항

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

  Important

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

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

• 분기를 main 통합 테스트에 주로 사용되는 지속적인 전진 및 안정적인 분기로 처리합니다.

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

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

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

DevOps용 AI

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

디자인 고려 사항

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

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

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

디자인 권장 사항

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

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

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

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

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

다음 단계

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

보안