환경 계획
Azure 자산은 기본 구성, 조직 전체 리소스와 설정, 애플리케이션 워크로드를 비롯한 많은 구성 요소로 구성됩니다. 각각 다른 용도로 여러 환경에 걸쳐 자산을 분산했을 수도 있습니다.
이 단원에서는 모든 배포 및 구성에 일관되게 코드를 사용하는 경우의 이점에 대해 알아봅니다. 그런 다음, 각 환경에 적용할 수 있는 컨트롤 및 자동화 수준을 살펴봅니다. 또한 배포 프로세스의 각 단계를 통해 변경 내용이 어떻게 진행되는지, 선택한 배포 전략을 지원하는 데 필요한 컨트롤 및 거버넌스 유형을 살펴봅니다.
인프라를 코드로 정의
Azure 배포 및 구성은 애플리케이션, 가상 머신, 스토리지 서비스, 네트워킹보다 훨씬 더 많은 것을 다룹니다. 예를 들어, 다음 항목은 각각 해당 Azure 리소스를 사용하는 구성의 한 형태입니다.
- 리소스 그룹, 구독, 관리 그룹을 만들어 리소스를 구성합니다.
- Azure Policy 정의, 이니셔티브, 할당을 정의하고 적용하여 다른 리소스를 구성하는 방법을 제어합니다.
- 사용자, 그룹, 워크로드 ID가 Azure 리소스에 액세스할 수 있도록 역할을 할당합니다.
- 경고를 포함한 모니터링을 구성하여 Azure 리소스를 관찰하고 예상대로 작동하는지 확인합니다.
인프라를 코드로 처음 정의하기 시작할 때는 템플릿 또는 정의에서 정의할 수 있는 모든 항목을 인식하지 못할 수 있습니다. 하지만 자동화 사용에 익숙해짐에 따라 환경에 대한 모든 것을 코드로 정의하는 것이 좋습니다. 이렇게 하면 모든 Azure 구성에 대해 일관되고, 테스트되고, 승인된 프로세스를 사용할 수 있습니다. 또한 코드는 Git 리포지토리에서 버전 관리되고 추적되므로 시간이 지남에 따라 Azure 환경이 어떻게 변경되었는지 검토할 수 있습니다. Git 리포지토리를 사용하여 각 변경 내용의 기록을 추적할 수 있습니다.
예를 들어, Azure Monitor 경고를 구성해야 한다고 가정합니다. 처음에는 자동화를 사용하여 경고를 배포하는 것은 적절하지 않다고 생각할 수 있습니다. 그러나 경고는 Azure 구성의 중요한 부분입니다. 경고가 올바르게 만들어지지 않으면 중요한 프로덕션 문제에 대한 알림을 놓칠 수 있습니다. 코드에서 경고를 정의하면:
- 팀 멤버가 경고와 구성을 검토할 수 있습니다.
- 먼저 비프로덕션 환경에 경고를 배포하여 테스트할 수 있습니다.
- Azure 구성의 변경 내용을 완전히 추적할 수 있습니다.
환경
인프라를 자동으로 배포하려는 경우 사용하려는 환경을 나열하면 도움이 됩니다. 많은 조직에는 각각 다른 특성을 가진 다양한 환경 유형이 있습니다. 예를 들면 다음과 같습니다.
- 일부 환경에서는 프로덕션 코드를 실행하는 반면, 다른 환경에서는 동일한 코드의 비프로덕션 버전을 실행하지만 다른 구성을 사용할 수 있습니다.
- 일부 환경은 수명이 길며 삭제할 수 없습니다. 다른 환경은 자동으로 만들어지고 더 이상 사용되지 않을 때 삭제되는 임시 환경입니다.
- 일부 환경은 인프라 또는 소프트웨어 개발 팀에서 사용합니다. 다른 환경은 보안 팀에서 사용하거나 잠재 고객에게 제품을 시연해야 하는 경우 영업 팀에서도 사용합니다.
장난감 회사가 웹 사이트에 사용할 수 있는 환경을 고려합니다.
애플리케이션 또는 인프라에 대한 변경 내용을 적용하고 커밋하는 경우 파이프라인은 개발, 테스트, 스테이징이라는 일련의 비프로덕션 환경을 통해 변경 내용을 배포합니다. 정의된 팀 멤버가 배포를 계속하기 전에 구성을 확인하거나 파이프라인 로그를 볼 수 있도록 특정 지점에서 수동 승인 단계를 수행할 수도 있습니다. 그런 다음, 파이프라인은 결국 변경 내용을 프로덕션 환경에 배포합니다.
해당 환경 외에도 영업 팀에는 고객과 대화하는 데 사용하는 자체 데모 환경이 있습니다. 영업 팀은 프로덕션 환경의 복사본을 사용하여 데모 환경을 만듭니다. 보안 및 테스트 팀은 각각 침투 테스트 및 성능 테스트를 위해 프로덕션 환경의 임시 복사본을 만드는 경우가 있습니다.
개발 팀에도 자체 환경 세트가 있습니다. 개발 팀에는 해당 멤버가 새 기능을 탐색하거나 Azure 서비스로 실험할 때 사용할 샌드박스가 있습니다. 또한 개발 팀은 검토하고 병합하는 각 GitHub 끌어오기 요청에 대한 PR 검토 환경을 만듭니다.
제어된 환경
이러한 환경 중 일부에서는 변경 내용을 검토하고 적용하는 공식적인 프로세스를 요구하는 것이 좋습니다. 이 유형의 환경을 제어된 환경이라고 합니다. 프로덕션 환경은 항상 제어되어야 합니다. 일부 비프로덕션 환경에도 컨트롤을 적용하는 것이 좋습니다. 이렇게 하면 프로덕션 배포 전에 컨트롤이 적용하는 모든 제한 사항을 잘 이해하고 테스트할 수 있습니다.
반면, 제어되지 않는 환경에는 공식적인 컨트롤이 많지 않거나 없습니다. 이 환경은 다른 환경과 동일한 코드 및 유사한 구성을 포함할 수 있지만 더 많은 실험과 임시 구성 변경을 허용합니다. 제어되지 않는 환경에서 사용자는 Azure Portal을 사용하거나 Azure CLI/Azure PowerShell 명령을 직접 실행하여 구성을 수정할 수 있습니다. 또한 조직의 승인된 프로세스를 사용하지 않고 리소스를 만들 수도 있습니다. 프로덕션 환경과 같은 제어된 환경에 적용할 수 있으려면 먼저 제어되지 않는 환경에서 변경한 내용을 코드로 캡처해야 합니다.
참고
경우에 따라 환경은 실제로 여러 물리적 환경 또는 배포를 나타낼 수 있습니다. 예를 들어 끌어오기 요청 검토를 위한 임시 환경을 만드는 경우 팀에 여러 끌어오기 요청이 열려 있기 때문에 동시에 여러 개의 별도 환경이 활성화될 수 있습니다. 그러나 환경을 계획하려는 경우 환경에는 동일한 특성과 컨트롤이 포함되기 때문에 환경을 동일한 것으로 간주할 수 있습니다.
팀과 의논한 후에는 제어된 환경과 제어되지 않는 환경을 지정합니다. 또한 각 환경을 소유하는 사용자를 결정합니다.
| 환경 이름 | Description | 소유자 | 수명 | 컨트롤 수준 |
|---|---|---|---|---|
| 개발 | 여러 개발자의 변경 내용을 단일 환경으로 통합합니다. | 운영 팀 | 수명이 김 | 제어 |
| 테스트 | 변경 내용에 대한 수동 및 자동화된 테스트를 실행하기 위한 환경입니다. | 운영 팀 | 수명이 김 | 제어 |
| 스테이징 | 프로덕션 유사 구성을 사용하여 프로덕션 전에 변경 내용이 배포되는 최종 비프로덕션 환경입니다. | 운영 팀 | 수명이 김 | 제어 |
| 생산 | 프로덕션 워크로드를 실행합니다. | 운영 팀 | 수명이 김 | 제어 |
| 데모 | 영업 팀에서 새 고객에게 제품을 시연하는 데 사용됩니다. | 영업 팀 | 수명이 김 | 제어되지 않음 |
| 성능 테스트 | 성능 및 스트레스 테스트를 실행하기 위해 프로덕션 환경의 복제본으로 동적으로 만들어진 다음, 테스트가 완료되면 삭제됩니다. | 테스트 팀 | 수명이 짧음 | 제어되지 않음 |
| 침투 테스트 | 침투 및 보안 테스트를 실행하기 위해 프로덕션 환경의 복제본으로 동적으로 만들어진 다음, 테스트가 완료되면 삭제됩니다. | 보안 팀 | 수명이 짧음 | 제어되지 않음 |
| PR 검토 | 팀 멤버가 애플리케이션이나 인프라를 변경하기 위해 만드는 각 끌어오기 요청에 대해 동적으로 만들어집니다. 끌어오기 요청이 닫히면 환경이 삭제됩니다. | 개발 팀 | 수명이 짧음 | 제어되지 않음 |
| 개발 샌드박스 | 실험 또는 탐색을 위해 개발 팀 멤버가 만든 다음, 더 이상 필요하지 않은 경우 삭제됩니다. | 개발 팀 | 수명이 짧음 | 제어되지 않음 |
이전 환경 목록은 예제일 뿐입니다. 자체 조직에서 사용하는 환경, 해당 환경의 수명, 환경에 필요한 컨트롤 수준을 결정해야 합니다.
팁
나중에 추가하고 손상된 코드를 많이 수정하는 대신 배포 초기에 해당 프로세스를 적용할 때 인프라 코드를 린팅, 테스트, 검토하는 것이 훨씬 더 쉽습니다.
마찬가지로, 보안 컨트롤이 처음부터 존재하는 경우, 일부 비프로덕션 환경에 적용되는 경우 보안 컨트롤을 훨씬 더 쉽게 사용할 수 있습니다. 이렇게 팀은 제어된 환경 내에서 작업하는 데 익숙해집니다.
학습 경로 전체에서 이러한 개념 중 일부를 점진적으로 도입했습니다. 가능한 한 빨리 배포 프로세스에 이러한 요소를 추가하는 것이 좋습니다.
각 환경의 격리
각 환경을 분리하고 가능한 한 자체 포함되도록 하는 것이 중요합니다. 각 환경에 전용 Azure 구독을 사용하면 도움이 될 수 있지만 환경을 분리된 상태로 유지하도록 주의해야 합니다.
환경 간 이동 방지 예를 들어, 프로덕션 환경의 가상 네트워크를 비프로덕션 환경의 가상 네트워크에 피어링하지 마세요. 피어링하면 누군가가 비프로덕션 환경 내에서 프로덕션 데이터를 실수로 변경하거나 중요한 프로덕션 데이터를 비프로덕션 환경으로 유출하기 쉽습니다.
검사 및 게이트
배포 프로세스가 진행됨에 따라 배포에 대한 신뢰도를 높이기 위해 일련의 검사를 실행해야 합니다. 배포가 진행되는 각 환경에 적합한 검사를 결정해야 합니다.
일반적으로 인프라에 대한 검사에는 다음이 포함됩니다.
- 코드 검토.
- 검토 중인 코드를 임시 환경에 배포하고 환경에 대한 자동화 또는 수동 테스트 실행
- 린팅.
- 사전 실행 유효성 검사.
- 수동 테스트.
- 수동 승인.
- 자동화된 기능 테스트.
- 자동화된 스모크 테스트.
- 다음 환경으로 진행하기 전에 이전 환경의 상태 신호 기다리기.
이러한 검사 중 일부는 각 제어된 환경 등에 대해 배포 프로세스 내에서 여러 번 실행할 수 있습니다.
팁
배포 프로세스를 디자인할 때는 얼마나 작거나 분명한지에 관계없이 수행해야 하는 모든 단계를 나열합니다. 최대한 자세하게 설명합니다. 처음에는 모든 것을 자동화하지 않을 수도 있지만 이 사례를 따르면 나중에 자동화된 배포 프로세스에 대한 청사진을 만드는 데 도움이 됩니다.
게이트는 배포를 계속하기 위해 성공해야 하는 자동 또는 수동 검사입니다.
수동 작업
코드 검토 및 배포 프로세스 중에 가능한 한 많은 검사를 자동화하는 것이 좋습니다. 그러나 조직에서는 프로덕션 또는 기타 제어된 환경에 배포하기 위해 수동 승인이 필요할 수 있습니다.
배포에 수동 승인 게이트를 사용하는 경우 다음 권장 사례를 따릅니다.
- 배포를 승인할 수 있는 사용자를 명확하게 정의합니다. 개별 사용자를 지정하는 대신 Microsoft Entra 그룹을 사용하여 승인자를 정의합니다. 나중에 승인자 목록을 쉽게 변경할 수 있습니다.
- 긴급 배포를 위한 프로세스를 포함합니다. 일반 승인자를 사용할 수 없는 경우 배포를 승인할 수 있는 사용자를 계획합니다. 한밤중이나 휴가 기간에 긴급 배포를 수행해야 할 수 있습니다.
- 사용자 개입을 배포 승인 또는 거부로만 제한합니다. 자동화할 수 없는 단계가 있는 경우 아니면 사용자가 배포 작업을 실행하도록 요구하지 마세요.
거버넌스
Azure는 다음을 포함하여 환경을 관리하는 데 도움이 되는 도구와 기능을 제공합니다.
- Azure Policy - 조직의 요구 사항에 맞지 않는 방식으로 구성된 리소스를 검색합니다. 또한 리소스가 규정을 준수하지 않는 방식으로 생성되거나 다시 구성되는 것을 방지하는 데 도움이 됩니다.
- 잠금 - 중요한 리소스의 변경 또는 삭제를 방지합니다.
- 관리 그룹 - Azure 구독을 구성하고 환경 전체에서 역할 기반 액세스 제어 및 정책을 일관되게 구성하는 데 도움이 됩니다.
- Azure Monitor - 리소스의 메트릭과 로그를 기록하고, 리소스를 대시보드에 표시하고, 리소스가 예상 값에서 벗어날 때 자동으로 경고합니다.
Azure 자산을 빌드하는 경우 Azure 랜딩 존을 사용하는 것이 좋습니다. 랜딩 존을 사용하면 처음부터 환경에 거버넌스를 빌드할 수 있습니다. 대부분의 랜딩 존에는 환경을 구성하는 데 도움이 되는 미리 빌드된 Bicep 및 Terraform 파일이 포함됩니다. 요약 부분에서 자세한 정보 링크를 제공합니다.