워크로드 개발 공급망 설계에 대한 권장 사항

  • 아티클

이 Azure Well-Architected Framework 운영 우수성 검사 목록 권장 사항에 적용됩니다.

OE:06 예측 가능한 자동화된 파이프라인을 통해 제안된 변경 내용을 구동하는 워크로드 공급망을 빌드합니다. 파이프라인은 환경 전체에서 이러한 변경 내용을 테스트하고 승격합니다. 공급망을 최적화하여 워크로드를 안정적이고 안전하며 비용 효율적이고 성능이 뛰어나게 만듭니다.

이 가이드에서는 CI/CD(지속적인 통합 및 지속적인 업데이트) 파이프라인을 기반으로 하는 워크로드 개발 공급망을 설계하기 위한 권장 사항을 설명합니다. 워크로드를 유지 관리하는 예측 가능하고 표준화된 방법을 갖도록 공급망을 개발합니다. CI/CD 파이프라인은 공급망의 표현이지만 단일 공급망이 있어야 합니다. 동일한 프로세스를 따르고 동일한 도구를 사용하는 여러 파이프라인이 있을 수 있습니다.

공급망을 통합하여 워크로드 변경을 제대로 관리하지 않을 때 발생할 수 있는 손상으로부터 워크로드를 보호합니다. 항상 워크로드 상태를 알고 있으므로 예측할 수 없는 동작이 발생할 위험이 없습니다. 이 위험 복합 문제가 발생할 때 변경에 대 한 설명 되지 않은 추적 중요 한 시간을 보낼 필요가 있는 경우. 이러한 위험을 최소화하려면 공급망을 정의하는 프로세스와 도구를 표준화하고 워크로드 팀이 완전히 사용할 수 있도록 합니다.

정의

용어 정의
공급망 클라우드 워크로드에서 공급망은 환경 전반의 인프라 및 애플리케이션 변화에 영향을 주는 데 사용하는 표준화된 도구 및 프로세스 제품군입니다.

주요 디자인 전략

참고

이 가이드의 권장 사항은 코드 승격 체인의 워크로드 환경을 참조합니다. 샌드박스 또는 기타 예비 및 개념 증명 환경에는 덜 엄격하고 구조가 필요합니다.

핵심 테넌

다음 권장 사항은 공급망의 핵심 신조를 정의하는 데 도움이 될 수 있습니다.

공급망 프로세스 및 도구를 통해 제안된 워크로드를 변경합니다. 자동화된 템플릿 기반 배포의 엄격한 정책을 적용합니다. 이 방법을 사용하면 모든 환경에서 워크로드의 구성이 표준화되고, 잘 정의되고, 엄격하게 제어되도록 할 수 있습니다. 코드 승격 체인의 환경의 경우 수동 프로세스 또는 클라우드 플랫폼의 컨트롤 플레인(예: 포털 또는 API)과의 인간 상호 작용을 사용하여 업데이트를 수행하지 마세요. 정의한 배포 사례에 따라 파이프라인을 통해 환경에 대한 모든 변경 내용을 통합합니다. 이 정책을 적용하려면 읽기 전용으로 액세스를 기본값으로 제한하고 액세스 권한 부여 게이트를 사용하여 쓰기 액세스를 허용하는 것이 좋습니다.

이 테넌트의 중요한 측면은 모든 변경 내용이 프로덕션에 배포될 때까지 제안된변경 내용 이라는 것입니다. 통합 및 스모크 테스트와 같은 자동화된 테스트를 통해 공급망에서 변경 내용을 자동으로 거부할 수 있습니다.

반복 가능하고 변경할 수 없는 IaC(Infrastructure as Code)를 배포합니다. IaC는 소스 코드를 미러링하는 버전 관리 시스템을 사용하는 설명이 포함된 모델의 인프라 관리입니다. 애플리케이션을 만들 때 동일한 소스 코드는 컴파일될 때마다 동일한 이진 파일을 생성해야 합니다. 이와 비슷한 방식으로, IaC 모델은 적용될 때마다 동일한 환경을 생성합니다.

IaC를 통합하여 팀이 잘 설정된 표준 프로세스를 따르도록 합니다. 일부 조직에서는 인프라를 배포하고 구성할 단일 개인 또는 소규모 개인 그룹을 지정합니다. 완전히 자동화된 프로세스를 구현하는 경우 인프라 배포에는 개인의 관리가 덜 필요합니다. 책임은 자동화 프로세스 및 도구로 이전됩니다. 팀 구성원은 일관성과 품질을 유지하기 위해 인프라 배포를 시작할 수 있습니다.

워크로드를 하나의 템플릿에 번들로 묶어 배포를 쉽고 반복 가능하게 만들 수 있는 논리적 구성 요소 그룹으로 디자인합니다. 이러한 번들을 스탬프 또는 배율 단위로 생각할 수 있습니다. 자세한 내용은 배포 스탬프 패턴을 참조하세요. 워크로드를 배포하여 동일한 지역 내의 다른 지역 또는 영역으로 스케일 아웃해야 하는 경우 파이프라인을 사용하여 스탬프를 배포합니다. 스탬프를 디자인하는 방법에 따라 전체 워크로드 대신 워크로드의 하위 집합을 배포할 수 있습니다. IaC 파이프라인에 네트워킹 구성 요소를 포함시켜 배포 스탬프가 기존 리소스에 자동으로 연결되도록 합니다.

일관성과 효율성을 위해 IaC 파이프라인을 최적화하려면 변경 가능한 인프라가 아닌 변경할 수 없는 인프라를 설계합니다. 변경할 수 없는 인프라를 구현하여 scope 모든 시스템이 각 배포와 동시에 업데이트된 구성으로 대체되도록 합니다.

모든 환경 및 파이프라인에서 하나의 코드 자산 및 아티팩트 집합을 사용합니다. 조직의 일반적인 문제점은 비프로덕션 환경이 프로덕션 환경과 다른 경우입니다. 프로덕션 및 비프로덕션 환경을 수동으로 빌드하면 환경 간에 구성이 일치하지 않습니다. 이러한 불일치로 인해 테스트 속도가 느려지고 변경 내용이 프로덕션 시스템에 해를 끼칠 가능성이 높아집니다. IaC 접근 방식은 이러한 문제를 최소화합니다. IaC 자동화를 사용하는 경우 모든 환경에 대해 동일한 인프라 구성 파일을 사용하여 거의 동일한 환경을 생성할 수 있습니다. 인프라 구성 파일에 매개 변수를 추가하고 각 환경의 요구 사항에 맞게 조정할 수 있습니다.

비용을 제어하기 위해 일반적으로 프로덕션 환경과 비프로덕션 환경 간에 차이가 있습니다. 프로덕션 환경에서와 동일한 수준의 중복성 및 성능이 필요하지 않은 경우가 많습니다. 리소스의 수와 SKU는 환경마다 다를 수 있습니다. 변경할 때 예측 가능성을 유지하는 데 도움이 되도록 표준화된 매개 변수를 사용하여 분산을 제어하고 이해해야 합니다.

공급망 및 파이프라인 설계에 조직 구조를 반영합니다. organization 팀 간에 사일로화될 수 있습니다. 각 팀은 공급망의 일부를 관리할 수 있습니다. 예를 들어 많은 조직에는 네트워킹, 데이터 및 컴퓨팅 리소스와 같은 인프라 도메인을 관리하는 팀이 있습니다. 이러한 팀은 애플리케이션 개발, 테스트 및 배포를 관리하는 개발 팀과는 별개입니다. 일부 조직에서는 개발 및 인프라 팀이 모든 인프라 및 애플리케이션 배포를 전체적으로 관리하는 DevOps 팀에 통합됩니다. 공급망에 관련된 팀을 구성하는 방법에는 여러 가지가 있습니다. 공급망은 원활하게 협력하는 모든 팀에 의존합니다. 모든 팀이 표준 프로세스를 따르고 표준 도구를 사용하여 공급망을 최대한 효율적으로 만들어야 합니다.

워크로드 수명 주기의 일부를 아웃소싱하는 경우 공급망은 타사 공급업체에 의존할 수 있습니다. 이러한 공급업체는 내부 리소스와 마찬가지로 공급망의 성공에 매우 중요합니다. 사용하는 프로세스 및 도구에 대해 모든 팀 간에 상호 합의가 있는지 확인합니다.

배포 방법을 표준화합니다. 워크로드에 허용되는 프로덕션 가동 중지 시간에 대해 제품 소유자에게 문의하세요. 가동 중지 시간이 허용되는 정도에 따라 요구 사항에 적합한 배포 방법을 선택할 수 있습니다. 이상적으로는 유지 관리 기간 동안 배포를 수행하여 복잡성과 위험을 줄여야 합니다. 가동 중지 시간이 허용되지 않는 경우 파란색-녹색 배포 방법을 사용합니다.

점진적 노출 접근 방식을 사용하여 대규모 고객에게 감지되지 않은 버그를 도입할 위험을 줄입니다. 카나리아 배포라고도 하는 이 메서드는 제어된 사용자 그룹에 점진적 순서로 배포됩니다. 더 많은 사용자에게 영향을 미치기 전에 문제를 catch합니다. 초기 출시 그룹은 출시 전략을 알고 있는 고객의 하위 섹션일 수 있습니다. 고객의 이 하위 섹션은 약간의 예기치 않은 동작을 허용하고 피드백을 제공할 수 있습니다. 또는 출시 중에 버그의 폭발 반경을 포함하는 데 도움이 되는 내부 사용자 그룹일 수 있습니다.

배포 방법을 정의할 때 각 배포에서 실행 가능한 가장 작은 변경 내용만 배포하는 표준 정책을 채택합니다. 워크로드의 중요도 및 구성 요소의 복잡성과 같은 요인에 따라 실행 가능한 가장 작은 변경 사항을 결정합니다. 변경할 수 없는 인프라를 사용하는 경우 가장 작은 실행 가능한 변경은 일반적으로 이전 버전을 실행하는 리소스를 대체하기 위해 최신 구성으로 리소스를 배포하는 것입니다. 변경 가능한 인프라를 사용하는 경우 가장 작은 실행 가능한 변경은 scope 리소스 그룹에 대한 단일 업데이트일 뿐이라고 결정할 수 있습니다.

계층화된 접근 방식을 따라 다양한 수명 주기를 반영합니다. 기본 계층은 대부분의 워크로드 수명 주기 동안 정적으로 유지되어야 하며 애플리케이션 계층은 자주 변경됩니다. 이러한 차이점을 고려하려면 각 계층에서 변경 내용을 적용할 수 있는 다른 파이프라인이 있어야 합니다.

랜딩 존은 가장 낮은 계층에 있습니다. 랜딩 존은 구독, 관리 그룹, 리소스 그룹, 거버넌스 함수 및 네트워킹 토폴로지와 같은 기본 요소의 논리적 그룹화입니다. 랜딩 존을 사용하면 워크로드를 쉽게 배포하고 관리할 수 있으며, 환경 구성에 대해 반복 가능한 접근 방식을 통해 중앙 운영 팀 또는 플랫폼 팀을 제공합니다. 일관된 환경을 제공하기 위해 모든 Azure 랜딩 존은 일반적인 디자인 영역 집합, 참조 아키텍처, 참조 구현 및 디자인 요구 사항에 맞게 배포를 수정하는 프로세스를 제공합니다. Azure 랜딩 존 디자인 원칙은 구독 민주화와 함께 정책 기반 거버넌스를 기반으로 권장되는 사례를 제공합니다. 랜딩 존에는 워크로드 수명 주기 동안 최소한의 변경이 필요합니다.

수신 및 송신 네트워크 컨트롤러, 부하 분산, 네트워크 라우팅 솔루션, DNS 관리 및 핵심 서버와 같은 핵심 인프라 및 기능도 자주 변경되지 않아야 합니다. 그러나 자주 구성 업데이트가 필요할 수 있습니다.

애플리케이션 및 데이터 계층에는 자주 구성 업데이트가 필요하고 인프라를 자주 변경해야 합니다. 이러한 구성 요소에는 가장 동적 파이프라인이 있어야 합니다.

전체적인 테스트 전략을 계획합니다. 시스템 안정성의 핵심 원칙은 왼쪽 시프트 원칙입니다. 애플리케이션 개발 및 배포는 왼쪽에서 오른쪽으로 진행되는 일련의 단계로 표시되는 프로세스입니다. 테스트를 프로세스의 끝으로 제한해서는 안 됩니다. 가능한 한 테스트를 시작 또는 왼쪽으로 이동합니다. 오류를 조기에 발견하면 오류를 복구하는 것이 더 저렴합니다. 나중에 애플리케이션 수명 주기에서 수정하는 데 비용이 많이 들거나 불가능할 수 있습니다.

애플리케이션 코드, 인프라 템플릿 및 구성 스크립트를 포함한 모든 코드를 테스트합니다. 애플리케이션을 실행하는 환경은 애플리케이션 코드와 동일한 메커니즘을 통해 버전 제어 및 배포되어야 합니다. 팀에서 애플리케이션 코드에 이미 사용하는 것과 동일한 테스트 패러다임을 사용하여 환경을 테스트하고 유효성을 검사할 수 있습니다.

가능하면 자동화된 테스트를 사용하여 일관성을 보장합니다. 공급망 설계에 다음 유형의 테스트를 포함합니다.

  • 단위 테스트: 단위 테스트는 일반적으로 연속 통합 루틴의 일부로 실행됩니다. 단위 테스트는 광범위하고 빠릅니다. 코드의 100%를 커버하고 30초 미만으로 실행하는 것이 이상적입니다.

    단위 테스트를 구현하여 개별 코드 모듈의 구문과 기능이 알려진 입력에 대해 정의된 출력을 생성하는 것과 같은 방식으로 작동하는지 확인합니다. 단위 테스트를 사용하여 IaC 자산이 유효한지 확인할 수도 있습니다.

    템플릿 및 스크립트를 포함하여 모든 코드 자산에 단위 테스트를 적용합니다.

  • 스모크 테스트: 스모크 테스트는 워크로드가 테스트 환경에서 일어서고 예상대로 수행될 수 있는지 확인합니다. 스모크 테스트는 구성 요소의 상호 운용성을 확인하지 않습니다.

    스모크 테스트는 인프라 및 애플리케이션에 대한 배포 방법론이 작동하고 프로세스가 완료된 후 시스템이 의도한 대로 응답하는지 확인합니다.

  • 통합 테스트: 통합 테스트는 애플리케이션 구성 요소가 개별적으로 작동하는지 확인한 다음 구성 요소가 예상대로 상호 작용할 수 있는지 여부를 결정합니다.

    대규모 통합 테스트 제품군을 실행하는 데 상당한 시간이 걸릴 수 있습니다. 따라서 왼쪽 이동 원칙을 통합하고 소프트웨어 개발 수명 주기 초기에 테스트를 수행하는 것이 가장 좋습니다. 스모크 테스트 또는 단위 테스트로 테스트할 수 없는 시나리오에 대한 통합 테스트를 예약합니다.

    필요한 경우 정기적으로 장기 실행 테스트 프로세스를 실행할 수 있습니다. 정기적인 간격은 적절한 절충을 제공하고 애플리케이션 구성 요소가 도입된 지 하루가 지난 후부터 애플리케이션 구성 요소 간의 상호 운용성 문제를 검색합니다.

    일부 테스트 시나리오는 수동 실행의 이점을 누릴 수 있습니다. 테스트에 인간 대화형 요소를 도입해야 하는 경우 수동 테스트를 사용합니다.

  • 수락 테스트: 컨텍스트에 따라 수락 테스트를 수동으로 수행할 수 있습니다. 부분적으로 또는 완전히 자동화될 수 있습니다. 수용 테스트는 소프트웨어 시스템이 요구 사항 사양을 충족하는지 여부를 결정합니다.

    이 테스트의 기본 목적은 시스템의 비즈니스 요구 사항 준수를 평가하고 시스템이 최종 사용자에게 배달하는 데 필요한 기준을 충족하는지 여부를 확인하는 것입니다.

테스트를 통해 코드 승격 프로세스 전체에서 품질 게이트를 구현합니다. 개발 및 테스트와 같은 하위 환경과 스테이징 및 프로덕션과 같은 더 높은 환경을 통해 코드를 배포합니다. 배포가 품질 게이트를 통과할 때 변경 내용이 프로덕션으로 이동하기 전에 품질 목표를 충족하는지 확인합니다. 비즈니스 요구 사항에 따라 품질 게이트의 초점이 결정됩니다. 또한 기본 Well-Architected 프레임워크 원칙인 보안, 안정성 및 성능 효율성도 고려합니다.

또한 승인 워크플로를 품질 게이트에 통합합니다. 적절한 경우 승인 워크플로를 명확하게 정의하고 자동화합니다. 품질 수용 조건을 자동화에 정의하여 효율적이고 안전하게 게이트를 통과할 수 있습니다.

Azure 촉진

Azure DevOps 는 협업적이고 효율적이며 일관된 개발 사례를 빌드하는 데 도움이 되는 서비스 모음입니다.

Azure Pipelines는 애플리케이션에서 CI/CD를 지원하는 빌드 및 릴리스 서비스를 제공합니다.

Azure용 GitHub Actions 배포를 간소화하기 위해 Azure와 통합됩니다. GitHub Actions 사용하여 CI/CD 프로세스를 자동화합니다. 리포지토리에 대한 모든 끌어오기 요청을 빌드하고 테스트하는 워크플로를 만들거나 병합된 끌어오기 요청을 프로덕션에 배포할 수 있습니다.

IaC 배포에 Terraform, Bicep 및 Azure Resource Manager 사용할 수 있습니다. 요구 사항과 도구에 대한 팀의 친숙함에 따라 이러한 도구 중 하나 이상을 배포 및 리소스 관리에 사용할 수 있습니다.

조직 맞춤

클라우드 채택 프레임워크 중앙 팀이 워크로드 랜딩 존을 제공하는 지침을 제공합니다. 워크로드 랜딩 존은 워크로드의 사용자 지정 공급망이 애플리케이션을 배포하는 위치입니다.

자세한 내용은 랜딩 존 및Azure 랜딩 존 디자인 원칙을 참조하세요.

예제

Azure Pipelines를 사용하여 CI/CD 파이프라인을 빌드하는 방법을 보여 주는 예제는 Azure Pipelines 기준 아키텍처를 참조하세요.

운영 우수성 검사 목록

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

운영 우수성 검사 목록