다음을 통해 공유

자동화

  • 아티클

소프트웨어 정의 클라우드 인프라에서 팀은 다양한 도구와 기술을 사용하여 인프라를 프로비전, 구성 및 관리합니다. 팀이 발전하고 성장함에 따라 포털 및 수동 작업 사용에서 코드 및 자동화를 사용하여 인프라 및 서비스를 프로비전, 구성 및 관리하는 것으로 전환할 수 있습니다.

플랫폼 자동화 고려 사항

  • EaC(Everything as Code) 방법론을 구현하면 팀이 주요 이점을 잠금 해제하고, 강력한 개발 문화를 만들고, 각 팀의 모든 사용자가 배포되는 방법과 리소스를 검사할 수 있습니다. 또한 EaC를 사용하면 플랫폼 팀이 민첩성과 효율성을 개선하는 주요 개발 사례를 채택할 수 있습니다. 팀은 리포지토리에 코드를 수용하고 버전 제어 시스템을 사용하여 변경 내용을 추적하고 프로덕션으로 이동하는 변경 내용을 제어할 수 있습니다.
  • Teams는 4-eyes 원칙을 따르고 피어 프로그래밍 또는 피어 검토를 사용하여 코드 변경이 단독으로 수행되지 않도록 할 수 있습니다. 피어 프로그래밍 및 피어 검토는 코드 품질을 향상시키고, 팀이 변경에 대한 책임을 공유하고, 합의 및 배포된 내용에 대한 팀 지식을 높일 수 있도록 합니다. 코드 검토는 팀 구성원이 코딩 및 자동화를 위한 새로운 기술과 방법을 학습할 수 있는 환상적인 방법입니다.
  • 팀은 Git과 같은 버전 제어 시스템을 Git 리포지토리와 함께 사용하여 피어 검토를 적용해야 합니다. Git 리포지토리를 사용하면 팀에서 중요한 분기를 정의하고 분기 정책으로 보호할 수 있습니다. 정책을 사용하여 이러한 분기에서 최소 팀 구성원 승인 수와 같은 특정 조건을 충족하도록 요구한 후 보호된 분기에 병합할 수 있습니다.
  • Teams는 EaC 방법론과 변경 검토 프로세스를 CI/CD(연속 통합 및 지속적인 업데이트) 프로세스와 연결해야 합니다. 모든 코드 변경은 정적 코드 분석, 유효성 검사 및 테스트 배포를 실행하는 CI 프로세스를 자동으로 트리거해야 합니다. CI를 사용하면 개발자가 향후 문제를 일으킬 수 있는 오류에 대해 조기에 코드를 확인합니다(빠른 실패 또는 시프트-왼쪽 테스트라고도 함). 팀에서 사용하는 분기 전략에 따라 중요한 분기를 변경하면 다른 환경에 배포가 트리거됩니다. 변경 내용이 승인되고 main에 병합되면 CD 프로세스에서 해당 변경 내용을 프로덕션에 배포합니다. 이 코드 관리 시스템은 각 환경에서 실행되는 작업에 대한 단일 정보 소스를 팀에 제공합니다.
  • 플랫폼이 완전히 자체 복구되고 워크로드 팀에 셀프 서비스를 제공하도록 하려면 플랫폼 팀이 프로비전, 구성 및 플랫폼 관리에서 워크로드 팀을 위한 랜딩 존 구독 프로비저닝에 이르기까지 모든 것(익스트림 자동화라고도 함)을 자동화하기 위해 노력해야 합니다. 익스트림 자동화를 통해 플랫폼 팀은 플랫폼을 배포, 구성 및 관리하는 대신 가치를 제공하는 데 집중할 수 있습니다. 또한 익스트림 자동화는 팀이 더 많은 자동화를 구축하는 데 더 많은 시간을 할애할 수 있는 자체 향상 주기를 만듭니다.
  • 플랫폼 팀이 운영 활동을 자동화하고 사용자 개입을 줄임에 따라 Azure에서 워크로드 팀 혁신을 가능하게 하고 가속화하는 중요한 작업으로 포커스를 이동해야 합니다. 이를 위해 플랫폼 팀은 플랫폼의 도구, 스크립트 및 기능 향상에 따라 빌드 및 개발의 여러 주기를 반복해야 합니다.
  • 팀이 Azure 랜딩 존 배포를 시작하는 데 도움이 되는 여러 옵션을 사용할 수 있습니다. 이러한 옵션은 현재 팀 기능에 따라 달라지며 팀이 발전함에 따라 증가할 수 있습니다. 특히 플랫폼 배포의 경우 각 Teams의 IaC 숙련도 및 도구 기본 설정에 따라 포털, Bicep 또는 Terraform 기반 환경 중에서 선택할 수 있습니다.
    • IaC(Infrastructure as Code)를 계속 알고 있고 포털을 사용하여 리소스를 배포하고 관리하는 데 더 익숙한 신규 및 신흥 플랫폼 팀은 Azure 랜딩 존 가속기를 사용하여 시작할 수 있으며, 이는 여전히 ClickOps 접근 방식을 사용하는 팀을 지원합니다. ClickOps는 포털, 관리 콘솔 및 마법사를 클릭하여 리소스를 프로비전, 구성 및 관리하는 프로세스입니다. 이 가속기를 사용하면 팀이 포털을 초기 배포 도구로 사용하고 플랫폼 엔지니어링 완성도가 증가함에 따라 점진적으로 Azure CLI, PowerShell 또는 IaC를 추가로 사용할 수 있습니다.
    • AzOps 솔루션을 통해 팀은 ClickOps 기반에서 DevOps 지원으로 플랫폼 자동화 및 관리 방식을 발전시킬 수 있습니다. 팀은 개인 계정 액세스 사용에서 AzOps 및 IaC를 사용하는 CI/CD에만 의존하는 DevOps 원칙 및 사례 사용으로 전환할 수 있습니다. AzOps를 사용하면 팀이 자체 아키텍처를 가져오거나, Azure 랜딩 존 포털 가속기에서 배포한 아키텍처를 사용하거나(AzOps 통합이 ALZ 포털 환경의 일부가 아니기 때문에 초기 포털 기반 배포 후), 브라운필드 배포와 통합하거나, 사용자 지정 템플릿(Bicep 또는 ARM)을 사용하여 플랫폼을 빌드하고 운영할 수 있습니다.
    • 확립된 기술과 기능을 갖춘 플랫폼 팀은 DevOps 원칙 및 사례를 따르는 명문화된 접근 방식을 채택할 수 있습니다. 팀은 개인 계정에서 Azure 액세스를 사용하지 않고 CI/CD 파이프라인을 통해 모든 작업을 실행하는 쪽으로 전환하는 IaC 및 최신 개발 방식을 기반으로 해야 합니다. 팀은 ALZ-Bicep 또는 Azure 랜딩 존 Terraform 모듈과 같은 IaC 기반 가속기를 사용하여 이 전환을 가속화해야 합니다.
  • IaC 기반 가속기는 관리 범위가 제한적입니다. 새 버전은 더 많은 기능과 향상된 리소스 관리 기능을 제공합니다. 가속기를 사용하는 경우 팀은 가속기로 시작하는 계층화된 접근 방식을 고려한 다음, 자동화 계층을 추가해야 합니다. 자동화 계층은 레거시 애플리케이션에 대한 도메인 컨트롤러 배포와 같은 플랫폼 기능을 사용하여 워크로드 팀을 완벽하게 지원하기 위해 팀에 필요한 기능을 제공합니다.
  • 플랫폼 팀이 DevOps 접근 방식으로 전환함에 따라 긴급 수정을 처리하기 위한 프로세스를 설정해야 합니다. PIM(Privileged Identity Management) 적격 권한을 사용해 액세스를 요청하여 수정을 수행하고 나중에 코드로 다시 가져와 구성 드리프트를 제한하거나 코드를 사용하여 빠른 수정을 구현할 수 있습니다. 팀은 나중에 각 수정 사항을 재작업하고 기술적인 문제를 제한할 수 있도록 항상 백로그에 빠른 수정 사항을 등록해야 합니다. 일부 플랫폼 코드가 완전히 검토되지 않고 팀 코딩 지침 및 원칙을 충족하지 않으므로 기술적인 문제가 너무 많으면 향후 감속으로 이어집니다.
  • Azure 정책을 사용하여 플랫폼에 일부 자동화를 추가할 수 있습니다. IaC를 사용하여 Azure 정책(PaC(Policy-as-Code)이라고 함)을 배포하고 관리하는 것이 좋습니다. 이러한 정책을 사용하면 로그 수집과 같은 활동을 자동화할 수 있습니다. 또한 많은 PaC 프레임워크는 예외 프로세스를 구현하므로 워크로드 팀이 정책에서 예외를 요청할 수 있도록 계획합니다.
  • "정책 기반 거버넌스"를 사용하여 보안 제어를 충족하지 않는 리소스를 배포하려고 할 때 워크로드 팀에 신호를 보낼 수 있습니다. 이러한 상황에 deny 효과가 있는 정책을 배포하는 것이 좋습니다. 이를 통해 워크로드 팀은 모든 항목을 코드로 처리하고 코드가 한 가지를 선언하고 정책이 배포 시 설정을 변경하는 구성 드리프트를 방지할 수 있습니다. 워크로드 팀이 코드에 supportOnlyHttpsTraffic = false가 정의된 스토리지 계정을 배포하고 modify 정책이 배포 시 이를 true로 변경하여 규정 준수 상태를 유지하는 경우와 같이 modify 효과를 사용하지 않도록 합니다. 이렇게 하면 배포된 코드에서 코드 드리프트가 발생합니다.

플랫폼 자동화 디자인 권장 사항

  • Azure 플랫폼, 설명서, 배포 및 테스트 프로세스의 완전한 투명성 및 구성 제어를 위해 Everything as Code 접근 방식을 따릅니다.
  • 버전 제어를 사용하여 다음을 비롯한 모든 코드 리포지토리를 관리합니다.
    • 코드 제공 인프라(Infrastructure as Code)
    • 코드로서의 정책
    • 코드로 구성
    • 코드로 배포
    • 코드로서의 설명서
  • 4-eyes 원칙과 피어 프로그래밍 또는 피어 검토 프로세스를 구현하여 프로덕션에 배포되기 전에 팀에서 모든 코드 사항을 검토하도록 합니다.
  • 팀에 대한 분기 전략을 채택하고 보호하려는 분기에 대한 분기 정책을 설정합니다 . 분기 정책을 사용하면 팀은 끌어오기 요청을 사용하여 병합을 변경해야 합니다.
  • CI/CD(연속 통합 및 지속적인 업데이트)를 사용하여 다양한 환경에 대한 코드 테스트 및 배포를 자동화합니다.
  • 플랫폼의 프로비전, 구성 및 관리와 워크로드 팀을 위한 랜딩 존 구독 프로비전과 같은 모든 작업을 자동화합니다.
  • 팀의 기능과 일치하는 사용 가능한 가속기 중 하나를 사용하여 Azure 랜딩 존 배포를 시작합니다.
  • 계층화된 배포 접근 방식을 사용하여 가속기에서 다루지 않지만 워크로드 팀을 완전히 지원하는 데 필요한 기능을 추가할 계획입니다.
  • 코드를 사용하여 빠른 수정을 구현하는 프로세스를 설정합니다. 언제든지 팀의 백로그에 빠른 수정 사항을 등록하여 각 수정 사항을 나중에 다시 작업할 수 있으며 기술적인 문제를 제한할 수 있습니다.
  • 코드 제공 인프라를 사용하여 Azure 정책(Policy-as-Code라고 함)을 배포하고 관리하는 것이 좋습니다.
  • 정책에 대한 예외 프로세스를 구현합니다. 워크로드 팀이 정책에서 예외를 요청하도록 계획하고 필요할 때 팀의 차단을 해제할 준비를 합니다.
  • "정책 기반 거버넌스"를 사용하여 보안 제어를 충족하지 않는 리소스를 배포하려고 할 때 워크로드 팀을 차단합니다. 이렇게 하면 코드가 배포되는 것과 다른 상태를 선언하는 구성 드리프트를 줄일 수 있습니다.

자세히 알아보기