자신 있게 배포
 예측 가능한 방식으로 원하는 배포 상태에 도달합니다. |
|---|
모든 환경에서 워크로드의 호스팅 플랫폼, 애플리케이션, 데이터 및 구성 리소스 전반에서 예측 가능성이라는 목표를 지속적으로 달성할 수 있는 워크로드 공급망을 빌드합니다. 배포 메커니즘은 자동화, 테스트, 모니터링, 버전 관리가 가능해야 합니다. 모듈화되어 있어야 하며 수요에 따라 실행할 수 있어야 합니다. 이는 단일적인 엔드투엔드 프로세스로 표현되어서는 안 됩니다. 공급망은 반드시 더 빠른 실행을 위한 것이 아니라, 여러 번의 반복을 통해 일관성과 자체 문서화를 달성하기 위한 것입니다.
워크로드 팀은 자신의 워크로드와 관련된 공급망에 대한 책임을 집니다.
예제 시나리오
Contoso Manufacturing은 제조 과정을 모니터링하고 최적화하는 데 사용되는 Java 기반 애플리케이션을 개발했습니다. 이 워크로드는 최근 Azure로 마이그레이션되었으며 현재는 Azure Spring Apps, Azure Database for MySQL 및 Azure IoT Hub에서 실행되고 있습니다.
코드를 통해 인프라 구축
IaC(코드 제공 인프라)를 사용하여 프로덕션에 적합한 공급망의 반복 가능한 측면을 정의합니다. 명령형 방식보다 선언형 방법을 선호합니다.
선언적 IaC 기술은 자동화와 재사용성을 염두에 두고 설계되었습니다. 개인이 담당하던 인프라 구축 업무를 도구로 이전하여 일관된 품질을 달성할 수 있습니다.
인프라 관점에서 볼 때, 기술 선택의 폭이 좁아지면 도구의 변동이 제거되고 구성 편차를 쉽게 검색할 수 있습니다. 유지 관리도 더 쉬워질 것입니다. 선택 사항을 팀의 기존 기술 집합에 맞게 조정하면 팀은 쉽게 채택할 수 있습니다.
Contoso의 과제
- 온-프레미스 버전의 워크로드는 스크립트와 수동 단계를 결합하여 인프라를 빌드하고 여러 환경 간에 애플리케이션을 배포했습니다. Azure 마이그레이션 프로세스 초기에 팀은 새로운 플랫폼을 대상으로 하여 기존의 필수 스크립트를 수정하여 기존 자동화 코드베이스를 가능한 한 많이 다시 사용할 수 있었습니다. 이러한 방식은 Bicep과 같은 Azure 및 IaC 기술에 대한 전문 지식이 부족하여 취해졌습니다.
- 마이그레이션이 진행되고 팀이 플랫폼에 더 익숙해짐에 따라 Bicep에서 IaC 방식을 사용하는 것이 장기적으로 더 나은 솔루션이 될 것이라는 확신을 갖게 되었습니다.
접근 방식 및 결과 적용
- 내부적으로 지식이 부족했기 때문에, 팀은 워크로드에 대한 배포 자동화 스크립트를 마이그레이션하고 확장하는 작업을 프로젝트 초기 단계 동안 개발팀에 포함되어 작업하는 경험이 풍부한 계약자에게 계약했으며, 이를 통해 나머지 팀원에게 지식을 전수했습니다.
- 그 결과, Bicep 기반 구현은 Azure에서 인프라를 프로비전하는 보다 안정적이고 관리하기 쉽고 효율적인 방법을 제공합니다. 이제 VSCode에서 뛰어난 도구 지원이 제공되어 코드가 더 읽기 쉽고 유지 관리하기 쉬워졌습니다. 또한 완전히 idempotent이며 이전/명령적 버전으로는 완전히 수행할 수 없었던 상태 관리를 간소화합니다.
IaC를 애플리케이션 코드와 동일하게 취급합니다
IaC 개발 및 유지 관리를 위한 소프트웨어 권장 사항을 따릅니다. 적당히 모듈화하고, 사용자 지정 또는 가치가 낮은 추상화를 피하고, 다양한 수명 주기를 반영하기 위해 계층적 방식을 따릅니다. 하위 계층은 일정하게 유지하고 상위 계층은 필요에 따라 변경하는 기초 계층을 형성합니다.
애플리케이션 이진, IaC 템플릿, 매개 변수와 같은 배포 아티팩트는 공격 표면의 일부입니다. 비밀 관리, 액세스 제어 및 기타 보안 핵심 요소 원칙과 같은 보장을 적용합니다.
아티팩트는 애플리케이션 코드와 동일한 수준의 엔지니어링 엄격성을 경험합니다. 동료 평가와 테스트를 통한 품질 제어를 통해 배포에 대한 확신을 가질 수 있습니다.
계층적 방식은 유지 관리를 보다 쉽게 만들고 책임의 명확한 경계를 확립합니다.
아티팩트에 보안 제어를 추가하면 배포 프로세스 중에 시스템을 강화하는 데 도움이 됩니다.
Contoso의 과제
- 프로젝트 팀은 마이그레이션 작업을 시작할 때 넉넉한 예산을 가지고 있었기 때문에 매우 환경이 풍부한 계약자를 고용하였고, 단시간 안에 고품질의 작업을 제공했습니다. 계약자들은 개발을 위해 별도의 리포지토리를 사용했는데, 해당 리포지토리는 보안에 대한 정기적인 감사를 받지 않았지만, 주요 애플리케이션 코드 리포지토리는 그렇지 않았습니다.
- 팀은 솔루션의 대대적인 재디자인을 릴리스할 준비를 하고 있으며, 배포 코드에 상당한 변경이 필요합니다. 개발 리소스가 부족하기 때문에 최신 변경 일괄 처리는 두 명의 인턴이 진행하고 있습니다. 팀의 상급 개발자 중 한 명이 인턴을 돕기 위해 불려갔을 때 그는 팀의 개발 표준에 맞지 않는 여러 커밋이 리포지토리에 있다는 것을 알아챘습니다. 여기에는 API 키와 같은 애플리케이션 비밀이 코드베이스에 하드 코드되어 있는 것도 포함됩니다.
접근 방식 및 결과 적용
- 팀은 빌드 및 배포 코드베이스를 애플리케이션 코드에 사용된 것과 동일한 리포지토리로 옮기고 코드베이스의 다른 영역과 동일한 수준의 엔지니어링 엄격성을 적용하기로 결정했습니다. 첫 번째 커밋 전에 코드가 팀 표준에 반영되고, 애플리케이션 비밀이 제거되고, 다른 모든 팀 품질 표준 및 도구가 적용됩니다.
- 그 결과, 팀은 코드 품질을 높이는 동시에 코드베이스의 이 섹션을 보호할 수 있었습니다. 앞으로 이 코드베이스 영역에 대한 변경 내용은 동일한 표준을 따르고 품질 및 보안 도구를 사용한 피어 코드 검토 및 자동 코드 검사를 포함하여 핵심 애플리케이션 코드베이스에 사용된 동일한 도구를 활용합니다.
단일 매니페스트에서 배포 표준화
모든 환경에서 사용되는 공통 배포 매니페스트를 개발합니다. 해당 매니페스트를 그린필드 프로젝트, 증분 워크로드 업데이트 또는 재해 복구를 위한 기본 메커니즘으로 사용합니다.
이 방법을 적용하면 여러 자산을 유지 관리하는 데 드는 간접비를 제거할 수 있습니다.
재해가 발생하면 임시 환경을 만드는 대신 검증된 매니페스트를 배포할 수 있으므로 빠르고 안정적으로 복구할 수 있습니다.
Contoso의 과제
- Contoso Manufacturing은 완전 자동화된 파이프라인을 사용하여 인프라, 애플리케이션 코드 및 구성 변경 내용을 개발 및 프로덕션 환경에 배포합니다. 해당 애플리케이션은 단일 지역에서 높은 가용성을 제공하도록 구성되어 있습니다. MySQL 데이터베이스를 제외한 대부분의 애플리케이션 구성 요소는 상태 비저장입니다. 데이터베이스는 설정된 RTO/RPO에 따라 백업되고, 백업은 보조 지역에 복제됩니다.
- 주 지역에서 주요 또는 치명적인 장애가 발생하는 경우, 팀은 보조 지역에서 애플리케이션을 호스팅할 새로운 환경을 빌드할 계획입니다. 재해 복구 절차를 테스트하기 위한 계획된 훈련 중에, 여러 리소스의 가용성 부족과 기타 서비스 제한 사항으로 인해 보조 지역에서 환경을 다시 만들려고 하면 배포 스크립트가 실패합니다.
접근 방식 및 결과 적용
- 팀은 보조 지역에서 프로비전을 시도할 때 발생한 문제를 완화하기 위해 일부 리소스 사용을 두 지역에서 모두 사용 가능한 동등한 SKU로 바꾸고 일부 옵션을 구성 가능하게 하여 보조 지역에서 다르지만 유효한 값을 사용할 수 있도록 했습니다.
- 이 훈련을 통해 팀은 주요 인프라 장애에서 복구할 수 있는 기능에 대한 확신이 높아졌습니다.