다음을 통해 공유

코드로 인프라를 사용하기 위한 권장 사항

  • 아티클

이 Azure 잘 설계된 프레임워크 운영 우수성 검사 목록 권장 사항에 적용됩니다.

OE:05 표준화된 IaC(Infrastructure as Code) 방식을 사용하여 리소스와 해당 구성을 준비합니다. 다른 코드와 마찬가지로 일관된 스타일, 적절한 모듈화 및 품질 보증으로 IaC를 디자인합니다. 가능한 경우 선언적 접근 방식을 선호합니다.

이 가이드에서는 인프라 배포의 표준으로 IaC를 사용하기 위한 권장 사항을 설명합니다. IaC를 사용하면 인프라 배포 및 관리를 기존 소프트웨어 개발 사례에 통합할 수 있습니다. 워크로드의 모든 구성 요소에 대한 개발 및 배포를 위한 일관된 표준 방법론을 제공합니다. 수동 배포에 의존하면 워크로드가 일관되지 않은 구성과 잠재적으로 안전하지 않은 디자인의 위험에 처하게 됩니다.

정의

용어 정의
선언적 도구 배포의 끝 상태를 정의하고 시스템에 의존하여 정의된 최종 상태와 일치하도록 리소스를 배포하는 방법을 결정하는 도구의 범주입니다.
변경이 불가능한 인프라 각 배포에서 새 구성을 실행하는 새 인프라로 대체하려는 인프라입니다. 그것은 장소에서 변경되어서는 안됩니다.
명령적 도구 원하는 최종 상태를 초래하는 실행 단계를 나열하는 도구의 범주입니다.
모듈 복잡한 배포를 간소화하기 위해 리소스 그룹을 분할하기 위한 추상화 단위입니다.
변경 가능한 인프라 현재 위치에서 변경하려는 인프라입니다. 배포는 새 인프라로 대체하지 않고 인프라의 구성을 변경합니다.

주요 디자인 전략

공급망 및 표준화 도구 및 프로세스 가이드에서 설명한 대로 코드를 통해서만 인프라 변경(구성 변경 포함)을 배포하는 엄격한 정책이 있어야 합니다. CI/CD(지속적인 통합 및 지속적인 업데이트) 파이프라인을 통해 IaC를 배포해야 합니다. 이러한 정책을 채택하면 모든 IaC 배포에 대한 프로세스의 일관성을 적용하고, 환경 전체에서 구성 드리프트의 위험을 최소화하며, 환경 전체에서 인프라 일관성을 보장합니다. 또한 스타일 가이드에서 IaC 개발 및 배포 도구 및 프로세스를 표준화해야 합니다. 스타일 가이드에 대한 권장 사항은 다음과 같습니다.

명령적 도구보다 선언적 선호

선언적 도구 및 관련 파일은 명령적 도구보다 IaC를 배포하고 관리하는 데 더 나은 전반적인 선택입니다. 선언적 도구는 해당 정의 파일에 더 간단한 구문을 사용하여 배포가 완료된 후 원하는 환경 상태만 정의합니다. 명령적 도구는 원하는 끝 상태로 가는 데 필요한 단계를 정의하는 데 따라 달라지므로 파일이 선언적 파일보다 훨씬 복잡할 수 있습니다. 또한 선언적 정의 파일은 시간이 지남에 따라 발생할 수 있는 배포 스크립트와 같은 명령적 코드를 유지 관리하는 기술적 문제를 줄이는 데 도움이 됩니다.

네이티브 및 업계 표준 도구 사용

기본적으로 플랫폼에 통합되는 클라우드 플랫폼의 네이티브 도구 및 업계에서 입증된 기타 도구를 사용합니다. 클라우드 플랫폼은 IaC를 쉽고 간단하게 배포할 수 있는 도구를 제공합니다. 사용자 고유의 솔루션을 개발하는 대신 Terraform과 같은 네이티브 통합이 있는 이러한 도구 및 기타 타사 도구를 활용합니다. 네이티브 도구는 플랫폼에서 지원되며 대부분의 요구 사항에 대한 기본 제공 기능을 포함합니다. 플랫폼 공급자가 지속적으로 업데이트하므로 플랫폼이 발전함에 따라 더 유용합니다.

참고 항목

클라우드 공급자와 타사 개발자가 도구 및 API를 업데이트할 때 워크로드에서 최신 버전을 사용할 때 예기치 않은 문제가 발생할 수 있습니다. 새 버전의 도구 및 API를 채택하기 전에 철저히 테스트해야 합니다. 마찬가지로 배포 코드에서 도구 또는 API를 호출할 때는 '최신' 플래그를 사용하지 마세요. 워크로드에 대해 알려진 최신 버전을 호출하는 방법에 대해 의도적으로 수행해야 합니다.

작업에 적합한 도구 사용

특정 작업 및 인프라 유형에 적합한 도구를 사용합니다. 배포 외의 여러 작업은 인프라 수명 주기에 포함됩니다. 예를 들어 구성을 적용하고 유지 관리해야 하며, Bicep과 같은 배포를 스크립트하는 데 사용하는 도구가 모든 관리 작업에 가장 적합한 도구는 아닐 수 있습니다.

마찬가지로, 다양한 인프라 유형에 원하는 상태 구성(DSC)을 적용하려면 다른 도구가 필요할 수 있습니다. 예를 들어 VM용 DSC를 관리하기 위한 Ansible과 같은 특정 도구가 있는 반면 Flux는 Kubernetes 클러스터에서 DSC를 관리하는 데 유용한 도구입니다. PaaS(Platform as a Service) 서비스는 IaC를 통해 처리할 수 있는 다양한 구성 관리 도구(예: Azure 앱 Configuration)를 제공할 수 있습니다. SaaS(Software as a Service) 서비스는 플랫폼에 의해 더 엄격하게 제어되므로 더 제한적일 수 있습니다.

IaC 사례의 범위에 있는 모든 작업 및 유형의 인프라에 대해 생각하고 필요한 작업을 수행하고 개발 및 관리 관행에 통합할 수 있는 도구를 표준화합니다.

여러 환경 지원

스크립트와 템플릿은 다양한 환경을 쉽게 배포할 수 있을 만큼 유연해야 합니다. 매개 변수, 변수 및 구성 파일을 사용하여 코드 승격 스택에 환경을 배포하도록 수정할 수 있는 표준 리소스 집합을 배포합니다. 리소스 크기, 개수, 이름, 배포할 위치 및 일부 구성 설정과 같은 추상 설정입니다. 그러나 너무 많이 추상화하지 않도록 주의하십시오. 워크로드 수명 주기 동안 실제로 변경되지 않거나 거의 변경되지 않을 수 있는 매개 변수 또는 변수를 사용하여 추상화할 수 있는 설정이 있습니다. 추상화해서는 안 됩니다.

참고 항목

다른 환경에 다른 IaC 자산을 사용하지 마세요. 예를 들어 프로덕션 및 테스트 환경에 대해 다른 Terraform 파일이 없어야 합니다. 모든 환경에서는 하나의 파일을 사용해야 합니다. 필요에 따라 해당 파일을 조작하여 다른 환경에 배포할 수 있습니다.

기능을 캡슐화할 때 적절한 균형 사용

모듈 사용을 전략화하고 표준화합니다. 매개 변수 및 변수와 마찬가지로 모듈은 인프라 배포를 반복 가능하게 만들 수 있습니다. 그러나 사용하는 방법에 대해 신중하게 생각하십시오. 표준화된 추상화 전략은 모듈이 합의된 특정 목표를 충족하도록 빌드되도록 하는 데 도움이 됩니다. 모듈을 사용하여 복잡한 구성 또는 리소스 조합을 캡슐화합니다. 리소스의 기본 구성만 사용하는 경우 모듈을 사용하지 마세요. 또한 새 모듈을 개발하는 데 신중해야 합니다. 적절한 경우 유지 관리되는 오픈 소스 모듈을 사용합니다(예: 민감하지 않은 시나리오).

문서 수동 단계

수동 단계에 대한 문서 표준입니다. 사용자 환경에 특정하고 수동 개입이 필요한 인프라 배포 및 유지 관리와 관련된 단계가 있을 수 있습니다. 이러한 단계를 최대한 최소화하고 명확하게 문서화해야 합니다. 스타일 가이드 및 표준 운영 절차에서 수동 단계를 표준화하여 작업이 안전하고 일관되게 수행되도록 합니다.

분리된 리소스를 처리하는 표준을 문서화합니다. 구성 관리에 사용하는 도구 및 해당 제한 사항에 따라 워크로드에서 특정 리소스가 더 이상 필요하지 않고 IaC 도구가 리소스를 자동으로 제거할 수 없는 경우가 있을 수 있습니다. 예를 들어 일부 함수에 대해 VM에서 PaaS 서비스로 이동하고 있으며 IaC 도구에 사용 중지된 리소스를 제거하는 논리가 없다고 가정해 보겠습니다. 워크로드 팀이 수동으로 삭제할 필요가 없는 경우 이러한 리소스는 분리될 수 있습니다. 이러한 시나리오를 처리하려면 분리된 리소스를 검색하고 삭제하는 전략을 표준화합니다. 템플릿이 최신 상태인지 확인하는 방법도 고려해야 합니다. 이러한 상황에서 계획해야 할 사항을 이해하려면 IaC 도구의 제한 사항을 조사합니다.

워크로드에 IaC를 사용하는 데 적용되는 다음 권장 사항을 고려합니다.

IaC 파이프라인에 계층화된 접근 방식 사용

계층화된 접근 방식을 사용하여 워크로드 스택 내에서 IaC 파이프라인을 정렬합니다. IaC 파이프라인을 계층으로 분리하면 복잡한 환경을 관리할 수 있습니다. 수십 또는 수백 개의 리소스를 모놀리식 패키지로 배포하는 것은 비효율적이며, 종속성 손상과 같은 여러 문제가 발생할 수 있습니다. 배포 수명 주기 또는 기능과 같은 요소가 밀접하게 일치하는 리소스로 구성된 계층에 맞춰진 여러 파이프라인을 사용하면 IaC 배포를 더 쉽게 관리할 수 있습니다.

네트워킹 리소스와 같은 핵심 인프라는 구성 업데이트보다 더 복잡한 변경이 거의 필요하지 않으므로 해당 리소스는 낮은 터치 IaC 파이프라인을 구성해야 합니다. 워크로드의 복잡성에 따라 리소스에 대한 중간 터치 및 하이 터치 IaC 파이프라인이 하나 이상 있을 수 있습니다. 예를 들어 Kubernetes 기반 애플리케이션 스택을 사용하면 하나의 중간 터치 계층이 클러스터, 스토리지 리소스 및 데이터베이스 서비스로 구성될 수 있습니다. 높은 터치 계층은 연속 배달 모드에서 매우 자주 업데이트되는 애플리케이션 컨테이너로 구성됩니다.

IaC 및 애플리케이션 코드를 동일하게 처리

IaC 아티팩트가 애플리케이션 코드 아티팩트와 동일하게 처리하면 모든 파이프라인에서 코드를 관리하기 위해 동일한 엄격함을 적용할 수 있습니다. 또한 IaC 개발 및 배포 사례는 애플리케이션 사례를 반영해야 합니다. 버전 제어, 분기, 코드 승격 및 품질에 대한 표준은 모두 동일해야 합니다. 또한 애플리케이션 코드 자산과 함께 IaC 자산을 배치하는 것이 좋습니다. 이렇게 하면 모든 배포에서 동일한 프로세스가 수행되도록 하고 필요한 애플리케이션 코드 이전에 인프라를 실수로 배포하는 것과 같은 문제를 방지하거나 그 반대의 경우도 마찬가지입니다.

중앙 집중식 표준 및 리소스 사용

표준화 및 재사용을 위해 조직의 다른 팀과 공동 작업합니다. 대규모 조직에는 워크로드를 개발하고 지원하는 여러 팀이 있을 수 있습니다. 표준에 동의하도록 팀 간 협업을 통해 라이브러리, 템플릿 및 모듈을 다시 사용하여 워크로드 환경 전반에서 효율성과 일관성을 얻을 수 있습니다. 마찬가지로, IaC 도구는 실제적인 범위까지 조직 전체에서 표준화되어야 합니다.

IaC 코드에서 보안 적용

보안이 배포 파이프라인의 일부인지 확인하려면 "코드로 보안" 원칙을 적용합니다. IaC 개발 프로세스의 일부로 취약성 검사 및 구성 강화를 포함합니다. IaC 리포지토리에서 노출되는 키와 비밀을 검사합니다. IaC를 사용하는 한 가지 이점은 보안 중심 팀 구성원이 배포 전에 코드를 검토하여 보안에 의해 릴리스하도록 승인된 구성이 실제로 프로덕션에 배포되는지 확인할 수 있다는 것입니다. 자세한 지침은 개발 수명 주기를 보호하기 위한 권장 사항을 참조 하세요.

루틴 및 비 루틴 활동을 테스트합니다. 배포 롤백 프로세스를 포함하여 배포, 구성 업데이트 및 복구 프로세스를 테스트합니다.

변경할 수 없는 배포 모델 채택

변경 가능한 인프라와 변경할 수 없는 인프라 배포 중에서 선택하는 것은 몇 가지 요인에 따라 달라집니다. 워크로드가 중요 비즈니스용인 경우 변경할 수 없는 인프라를 사용하는 것이 가장 좋습니다. 마찬가지로 배포 스탬프를 기반으로 하는 성숙한 인프라 디자인이 있는 경우 애플리케이션 코드와 새 인프라를 안정적으로 배포할 수 있으므로 변경할 수 없는 인프라를 사용하는 것이 좋습니다. 반대로, 안전한 배포 사례에서 완화 가능한 배포 문제가 발생할 때 배포를 롤 포워드하는 것이 선호되는 옵션인 경우 변경 가능한 인프라를 사용하는 것이 더 나은 선택이 될 수 있습니다. 이 경우 인프라를 현재 위치에서 업데이트할 수 있습니다.

고려 사항

향상된 전문화: 경우에 따라 워크로드 팀에 새 언어를 도입하는 것은 학습 곡선과 함께 제공되며 공급업체 잠금으로 인해 잘못된 선택이 될 수 있습니다. 팀 구성원을 교육하고 클라우드 공급자의 도구 지원을 기반으로 올바른 도구를 분석해야 합니다.

유지 관리 노력 증가: IaC 구현을 최신 상태로 안전하게 유지하려면 코드 베이스 및 도구 유지 관리가 필요합니다. 기술 부채를 적절히 추적하고 부채를 줄이는 것이 보상되는 문화를 조성합니다.

구성 변경 시간 증가: 명령줄 지침을 사용하거나 포털에서 직접 인프라를 배포하려면 코딩 시간 및/또는 아티팩트를 테스트할 필요가 없습니다. 코드 검토 및 품질 보증 사례와 같은 권장 사례를 따라 배포 시간을 최소화합니다.

모듈화의 복잡성 증가: 더 많은 모듈 및 매개 변수화를 사용하면 시스템을 디버그 및 문서화하는 데 걸리는 시간이 늘어나고 추상화 계층이 추가됩니다. 모듈화 사용의 균형을 조정하여 복잡성을 줄이고 과잉 엔지니어링을 방지합니다.

Azure 촉진

ARM 템플릿(Azure Resource Manager 템플릿) 및 Bicep 은 선언적 구문을 사용하여 인프라를 배포하기 위한 Azure 네이티브 도구입니다. ARM 템플릿은 JSON으로 작성된 반면 Bicep은 도메인별 언어입니다. 둘 다 Azure 파이프라인 또는 GitHub Actions CI/CD 파이프라인에 쉽게 통합할 수 있습니다.

Terraform 은 Azure에서 완전히 지원되는 또 다른 선언적 IaC 도구입니다. 인프라를 배포하고 관리하는 데 사용할 수 있으며 CI/CD 파이프라인에 통합할 수 있습니다.

클라우드용 Microsoft Defender 사용하여 IaC에서 잘못된 구성을 검색할 수 있습니다.

예시

제공된 Resource Manager, Bicep 또는 Terraform 파일을 통해 배포할 수 있는 Virtual Desktop 구현의 예는 Azure Virtual Desktop 랜딩 존 가속기 아키텍처 및 관련 참조 구현을 참조하세요.

운영 우수성 검사 목록

전체 권장 사항 집합을 참조하세요.

운영 우수성 검사 목록