엔터프라이즈용 Azure DevTest Labs 아키텍처

Azure DevTest Labs
Azure Artifacts
Azure Bastion

이 문서에서는 설계 지침을 중심으로 ESLZ(엔터프라이즈 규모 랜딩 존)에서 Azure DevTest Labs(DTL 또는 Lab)를 준비하기 위한 아키텍처 접근 방식을 제공합니다.

아키텍처

엔터프라이즈의 DTL 아키텍처에서 플랫폼 기반은 일반적으로 중앙 집중식 네트워킹, ID 및 거버넌스를 위해 ESLZ에 제공된 지침에 따라 플랫폼 관리자가 설정합니다. ESLZ 플랫폼 설정에 대한 자세한 내용은 Azure에서 엔터프라이즈 규모 랜딩 존 구현을 참조하세요.

애플리케이션 팀의 책임은 다음 다이어그램의 오른쪽 하단에 표시된 DevTest 구독에서 핵심 DTL 리소스를 프로비저닝하는 것입니다. 이 경우 이미 설정된 기반이 사용됩니다. 관리 그룹에 적용된 정책은 DevTest 구독 및 리소스로 이어집니다.

DTL에만 기본 제공 제한이 없지만 랩에서 사용되는 다른 Azure 리소스는 Azure 구독 제한을 초과하여 확장될 수 있습니다. 이러한 경우 DTL의 대규모 배포를 처리하기 위해 여러 Azure 구독이 필요할 수 있습니다.

Diagram of the reference architecture for DevTest Labs in an enterprise.

이 아키텍처의 Visio 파일을 다운로드합니다.

데이터 흐름

  • Network 관리istrator는 허브 가상 네트워크와 피어되는 네트워크 리소스 그룹에 NSG, UDR과 같은 스포크 가상 네트워크 및 기타 네트워크 리소스를 만듭니다. 피어링은 ESLZ 자동화에 따라 회사 관리 그룹에 할당된 Azure 정책에 의해 만들어집니다. 이 피어링을 통해 회사 사용자는 개인 IP로 VPN/ExpressRoute를 통해 랩 VM에 액세스할 수 있습니다.
  • 랩 소유자는 프로젝트 요구 사항에 따라 기본 제공 랩 정책을 구성합니다. Azure DevTest Labs에서 랩에 대한 모든 정책 관리에서 사용 가능한 모든 정책을 검토할 수 있습니다. 이 문서와 관련된 몇 가지 정책은 다음과 같습니다.
    • 모든 랩 VM이 스포크 가상 네트워크에 생성되도록 가상 네트워크 설정을 구성합니다.
    • 모든 랩 VM이 지정된 랩 리소스 그룹에 생성되도록 랩 설정을 구성합니다. 이러한 방식으로 랩 VM이 여러 리소스 그룹에 배포되지 않습니다.
    • 브라우저 커넥트 허브 가상 네트워크에 배포된 Bastion 호스트를 사용하여 공용 IP 없이 인터넷을 통해 랩 VM에 대한 RDP/SSH 액세스를 보호합니다.
    • 랩 사용자를 구성하고 최소 권한에 따라 적절한 역할을 할당합니다. DTL은 소유자, 기여자 및 사용자라는 세 가지 기본 제공 역할을 제공합니다.
    • 랩 가상 머신에 도메인 조인에 대한 요구 사항이 있는 경우 랩에서 도메인 조인 아티팩트를 필수 아티팩트로 구성합니다.
    • 아티팩트 및 환경 템플릿에 대해 랩에서 프라이빗 Github/ADO 리포지토리를 구성합니다. 리포지토리는 애플리케이션 코드베이스를 저장하는 데에도 사용할 수 있습니다.
  • 애플리케이션 팀은 랩 리소스(VM 및 PaaS 환경)를 수동으로 스핀업하거나 DTL 작업을 사용하여 리소스를 배포하도록 Azure Pipelines를 설정할 수 있습니다.

리소스 토폴로지

DevTest 구독 내에서 랩에 대한 리소스 그룹 조직을 간소화하면 리소스의 기본 달성 가능성이 향상됩니다. 일반적으로 기업에서 네트워크 관련 리소스는 네트워크 관리자에 의해 제어되며 별도의 리소스 그룹을 사용하여 애플리케이션 리소스와 격리됩니다.

랩 리소스는 위의 다이어그램과 같이 DevTest 구독 내의 두 리소스 그룹 내에서 배포될 수 있습니다.

  • 가상 네트워크, NSG, 경로를 포함하는 네트워크 리소스 그룹(rg-network-dtl)입니다. 네트워크 리소스는 동일한 구독 내의 여러 랩에서 공유할 수 있습니다.
  • 핵심 랩 리소스가 포함된 랩 리소스 그룹(rg-team-lab1). 기본적으로 DTL은 모든 새 가상 머신에 대한 리소스 그룹을 만들며 이러한 격리를 원하는 경우에 적합합니다. 그렇지 않은 경우 이 구성을 변경하여 동일한 리소스 그룹에 있는 모든 VM을 배포할 수 있습니다. 여러 팀이 DTL을 공유하거나 팀 또는 프로젝트 요구 사항에 따라 별도의 DTL을 가동할 수 있습니다.

DTL을 프로비저닝할 때 다음 인프라 리소스가 자동으로 만들어집니다.

  • Key Vault: DTL 사용자는 KeyVault를 사용하여 Windows VM용 암호, Linux VM용 공용 SSH 키 또는 개인용 액세스 토큰을 저장하여 아티팩트를 통해 Git 리포지토리를 복제할 수 있습니다.
  • 스토리지 계정: DTL은 다음과 같은 용도로 스토리지 계정을 사용합니다.
    • 가상 머신을 만드는 데 사용할 수 있는 수식 문서를 저장합니다.
    • 아티팩트를 적용하여 생성된 배포 및 확장 로그를 포함한 아티팩트 결과를 저장합니다.
    • VHD(가상 하드 디스크)를 업로드하여 랩에 사용자 지정 이미지를 만듭니다.
    • 가상 머신 및 환경 생성 중에 더 빠르게 검색하기 위해 자주 사용되는 아티팩트 및 Azure Resource Manager 템플릿을 캐싱합니다.
  • 가상 네트워크: DTL은 기존 가상 네트워크가 제공되지 않는 한 기본 가상 네트워크를 만듭니다. 이 아키텍처에서는 허브 가상 네트워크와 피어링된 기존 스포크 가상 네트워크를 사용하는 것이 좋습니다.

구성 요소

  • ESLZ(엔터프라이즈 규모 랜딩 존)는 Azure에서 랜딩 영역을 대규모로 효율적으로 구성하고 운영할 수 있도록 하는 아키텍처 접근 방식이자 참조 구현입니다. Azure 랜딩 존은 규모, 보안, 거버넌스, 네트워킹 및 ID를 설명하는 다중 구독 Azure 환경의 출력입니다. DTL은 관리 그룹 및 구독 토폴로지에 설명된 대로 DevTest 랜딩 존 또는 샌드박스 구독에 배포할 수 있습니다.
  • DTL(Azure DevTest Labs)은 개발자와 테스터가 개발 및 테스트 환경을 신속하게 프로비저닝하는 데 사용하는 완전 관리형 서비스입니다. DTL을 통해 사용자는 가상 머신 및 PaaS 리소스를 만들 수 있습니다. VM 만들기는 기본적으로 지원되지만 PaaS 리소스는 환경 템플릿을 사용하여 만들 수 있습니다.
  • DTL 정책을 사용하면 각 랩의 정책(설정)을 관리하여 랩에서 비용을 관리하고 낭비를 최소화할 수 있습니다. DTL 정책을 사용하면 랩에서 허용되는 VM 크기를 지정하여 랩 낭비를 최소화할 수 있습니다. 이 정책이 활성화되면 목록의 VM 크기만 사용하여 VM을 만들 수 있습니다.
  • 허브 및 스포크 구성은 비용 절감, 구독 제한 극복, 워크로드 격리 등의 이점을 제공합니다. 허브 가상 네트워크는 많은 스포크 가상 네트워크와 온-프레미스 네트워크에 대한 연결의 중심점 역할을 합니다. 스포크 가상 네트워크는 허브와 피어링하며 워크로드를 격리하는 데 사용할 수 있습니다. DTL은 스포크 네트워크에 배치할 수 있으므로 엔터프라이즈는 DMZ로 가능한 허브의 방화벽, Express Route/VPN 연결, 워크로드에 대한 분리된 관리와 같은 보안 기능을 중앙에서 제어할 수 있습니다. 일반적으로 스포크 가상 네트워크를 포함한 가상 네트워크는 플랫폼 관리자가 제공합니다. 앱 팀은 지정된 서브넷에서 DTL을 프로비저닝할 수 있습니다. 자세한 내용은 네트워킹 토폴로지에 나와 있습니다.
  • Azure Bastion은 공용 IP 주소를 통한 노출 없이 VM에 대한 보다 안전하고 원활한 RDP(원격 데스크톱 프로토콜) 및 SSH(Secure Shell Protocol) 액세스를 제공하는 완전 관리형 서비스입니다. DTL은 네트워킹 토폴로지에 설명된 대로 인터넷을 통해 직접 노출하지 않고 Bastion 호스트를 사용하여 VM에 안전하게 RDP/SSH를 수행할 수 있습니다. 기본적으로 DTL은 공용 IP 또는 공유 공용 IP를 통한 VM 연결을 허용합니다.
  • DTL 아티팩트를 사용하면 Windows PowerShell 스크립트 실행, Bash 명령 실행 및 소프트웨어 설치와 같이 가상 머신이 프로비전될 때 수행되는 작업을 지정할 수 있습니다. 아티팩트 매개 변수를 통해 시나리오에 대한 아티팩트를 사용자 지정할 수 있습니다. DevTest Labs에서 유지 관리하는 공용 아티팩트 리포지토리는 Windows 및 Linux에서 사용할 수 있는 여러 가지 일반적인 도구를 제공합니다. 이 리포지토리에 대한 링크는 랩에 자동으로 추가됩니다.
  • Azure DevTest Labs에 포함된 수식은 가상 머신을 만드는 데 사용되는 기본 속성 값의 목록입니다.
  • DTL 환경을 통해 사용자는 랩 범위 내에서 일관된 방식으로 복잡한 인프라를 배포할 수 있습니다. Azure Resource Manager 템플릿을 사용하여 DevTest Labs의 리소스 집합으로 환경을 생성할 수 있습니다. 이러한 환경에는 리소스 관리자 템플릿이 생성할 수 있는 모든 Azure 리소스가 포함될 수 있습니다.

대안

고객은 정책, RBAC 그룹, VM 확장 및 Automation과 같은 Azure 기본 기능을 사용하여 여러 서비스를 결합하여 DevTest Labs와 유사한 솔루션을 구축할 수 있습니다.

DevTest Labs를 사용할 경우의 주요 이점은 즉시 사용 가능한 통합 기능과 직관적인 인터페이스로, Azure에 대한 깊은 기술이 없는 신규 사용자(관리자 및 개발자)도 쉽게 사용할 수 있습니다. 이러한 방식으로 DTL은 구현 및 기본 테넌트에서 시간과 노력을 절약합니다.

시나리오 정보

DTL은 팀 내의 개발자가 승인을 기다리지 않고 VM(가상 머신) 및 PaaS 리소스를 효율적으로 자체 관리할 수 있도록 지원하여 걱정 없는 셀프 서비스 환경을 제공합니다. 특히 개발자 데스크톱, 테스트 환경, 학습 세션 및 샌드박스 조사와 같이 Azure를 시작할 때 주요 시나리오에 큰 가치를 더합니다. 기본 제공되는 랩 정책 및 임계값을 통해 손쉽게 비용을 절감할 수 있습니다. DTL의 핵심 개념에 대해 자세히 알아보려면 DevTest Labs 개념을 참조하세요.

이 문서에는 DTL 컨텍스트에서 관리 그룹 및 구독 토폴로지, 네트워킹, ID, 기업계약 제안, 애플리케이션 자동화 및 DevTest 워크로드의 보안에 대한 권장 사항이 포함되어 있습니다.

DevTest 워크로드를 대규모로 마이그레이션하는 기업은 이 엔터프라이즈 규모 아키텍처를 설정하면 이점을 얻을 수 있으며 다음을 달성할 수 있습니다.

  • DTL을 사용하여 애플리케이션 개발/테스트에 집중하고 모든 플랫폼 관리, 네트워킹, 보안 및 ID 설정을 중앙 IT 팀에 맡길 수 있으므로 애플리케이션 팀의 운영 오버헤드가 감소합니다.
  • DevTest 워크로드 전반에 걸쳐 조직 규정 준수를 중앙 집중식으로 적용합니다.

잠재적인 사용 사례

이 아키텍처는 다음이 필요한 조직에 유용합니다.

  • 처음부터 DevTest 워크로드를 위해 완전히 통합된 운영 컨트롤 플레인
  • 플랫폼 및 애플리케이션 워크로드 간의 명확한 문제 분리

전통적으로 이 아키텍처는 구독 전반에 걸쳐 DevTest 워크로드를 대규모로 배포하기 위한 시작점 역할을 합니다.

고려 사항

이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일단의 지침 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.

보안

우수한 보안은 중요한 데이터 및 시스템에 대한 고의적인 공격과 악용을 방어합니다. 자세한 내용은 보안 요소의 개요를 참조하세요.

보안 기준은 Azure Security Benchmark 버전 2.0의 지침을 DTL에 적용합니다.

거버넌스 및 규정 준수

다음 링크는 DTL에 대한 거버넌스 및 규정 준수를 처리합니다.

ID 및 액세스 관리

엔터프라이즈 조직은 일반적으로 Microsoft Entra ID, Azure RBAC(역할 기반 액세스 제어 ) 및 사용자 지정 역할 정의를 통해 설계된 운영 액세스에 대한 최소 권한 접근 방식을 따릅니다. RBAC 역할을 사용하면 가상 머신 만들기, 환경 만들기, 아티팩트 시작, 중지, 다시 시작, 삭제 및 적용과 같은 DTL 리소스를 관리할 수 있습니다.

  • 랩에 대한 액세스는 팀 내의 업무를 다른 역할로 분리하도록 구성할 수 있습니다. 이러한 세 가지 RBAC 역할은 소유자, DevTest Labs 사용자 및 참가자입니다. DTL 리소스는 예산, 컴퓨터 및 필수 소프트웨어에 대한 프로젝트 및 팀 요구 사항을 이해하는 사람이 소유해야 합니다. 일반적인 모델은 랩 소유자로서 프로젝트 리드 또는 앱 관리자이고 팀 구성원은 랩 사용자입니다. 기여자 역할은 랩 리소스 관리 권한이 필요한 앱 인프라 멤버에게 할당할 수 있습니다. 랩 소유자는 정책을 구성하고 랩에 필요한 사용자를 추가할 책임이 있습니다.
  • 사용자가 도메인 기반 ID에 연결해야 하는 엔터프라이즈의 경우 플랫폼 구독에 추가된 도메인 컨트롤러를 사용하여 DTL VM을 도메인에 조인할 수 있습니다. DTL 아티팩트는 VM을 자동으로 도메인에 조인하는 방법을 제공합니다. 기본적으로 DTL 가상 머신은 로컬 관리자 계정을 사용합니다.
  • DTL은 Azure 리소스에 대한 관리 ID를 지원합니다. DTL에서 관리 ID를 사용하여 Key Vault, Storage에 액세스하고 VM 및 PaaS 리소스를 배포합니다. 랩 VM 사용자가 Azure 리소스에 액세스할 수 있도록 DTL의 랩 VM에 사용자 할당 관리 ID를 할당합니다.

네트워킹 토폴로지

조직은 종종 허브와 스포크가 별도의 가상 네트워크에 배포되고 구독이 피어링을 통해 연결되는 지역 허브 스포크 네트워크 토폴로지로 운영됩니다.

이전 아키텍처 다이어그램에서 볼 수 있듯이 DTL 리소스는 허브 가상 네트워크와 피어링되는 기존 스포크 가상 네트워크를 사용합니다. 플랫폼 구독의 일부인 허브 가상 네트워크는 RDP/SSH 액세스를 통해 다음과 같은 보안 연결을 사용하도록 설정합니다.

  • VPN/ER을 통해 내부 사용자에 대한 개인 IP를 사용하는 DTL 가상 머신. 데이터베이스 및 Active Directory 도메인과 같은 일부 필수 구성 요소가 여전히 온-프레미스에 있는 하이브리드 애플리케이션 시나리오에서도 온-프레미스 환경에 연결해야 합니다.
  • 인터넷을 통한 배스천 호스트를 통해 외부 사용자에 대한 개인 IP를 사용하는 DTL 가상 머신. 또한 조직은 Bastion을 통한 브라우저 연결을 원하지 않는 경우 인터넷을 통한 기존 RDP 연결을 사용하는 대신 DTL에서 원격 데스크톱 게이트웨이를 구성할 수 있습니다.

허브 스포크 디자인은 DTL 리소스가 공용 인터넷에 직접 노출되는 것을 최소화하고 워크로드 격리를 제공하며 아키텍처를 확장할 수 있도록 합니다. 방화벽 및 DNS와 같은 특정 리소스는 스포크 네트워크에서 공유할 수 있습니다.

DTL은 또한 조직 규정 준수에서 허용하는 경우 공용 IP 또는 공유 IP를 통해 VM에 직접 연결하는 기능을 제공합니다.

비용 최적화

비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 높이는 방법을 찾는 것입니다. 자세한 내용은 비용 최적화 핵심 요소 개요를 참조하세요.

DevTest를 위한 기업계약

기업계약 고객은 엔터프라이즈 개발/테스트에 설명된 대로 개발/테스트 워크로드에 대해 더 낮은 요금에 가입하여 Azure에서 개발 및 테스트 워크로드를 실행할 수 있는 좋은 방법입니다. Azure Enterprise Portal 내에서 DevTest 구독을 사용하도록 설정하면 조직에서 다음을 수행할 수 있습니다.

  • 일반적으로 Azure 엔터프라이즈 구독에서 사용할 수 없는 클라이언트 운영 체제 실행
  • 컴퓨팅에 대해서만 비용을 지불하는 엔터프라이즈 소프트웨어 사용
  • 라이선스에 대한 자신감

운영 우수성

운영 우수성은 애플리케이션을 배포하고 프로덕션에서 계속 실행하는 운영 프로세스를 다룹니다. 자세한 내용은 운영 우수성 핵심 요소 개요를 참조하세요.

애플리케이션 자동화 및 DevOps

DTL의 컨텍스트에서 자동화에는 다음이 포함됩니다.

REST API, PowerShell, Azure CLI 및 Azure SDK를 비롯한 다양한 방법으로 Azure 및 DevTest Labs를 자동화할 수 있습니다.

개발 및 운영을 위한 DTL과 Azure DevOps의 통합은 Azure DevTest Labs 및 Azure DevOps 통합에 설명되어 있습니다. 또한 Azure 아키텍처 센터에서는 IaaS용 DevTest 및 DevOps에 대한 문서를 제공합니다.

관리 그룹 및 구독 토폴로지

관리 그룹구독에 대해 잘 설계된 토폴로지와 조직 구조 및 규정 준수 요구 사항은 향후 성장을 위한 적절한 격리 및 최대 유연성을 보장합니다. 관리 그룹 및 구독 설정은 랩을 프로비전하기 위해 애플리케이션 관리자 또는 랩 소유자에게 필요한 액세스를 제공하는 플랫폼 소유자의 책임입니다.

이전 아키텍처 다이어그램에 표시된 것처럼 애플리케이션 팀은 다음 몇 가지 의사 결정 사항에 따라 랜딩 존 관리 그룹 또는 샌드박스 관리 그룹의 구독에 DTL을 배포할 수 있습니다.

  • 랜딩 존 관리 그룹에 정의된 글로벌 조직 규정 준수가 DevTest 워크로드에 유효한 경우 온-프레미스 환경과의 연결 요구 사항에 따라 회사 또는 온라인 관리 그룹의 비프로덕션 랜딩 존 구독에 DTL을 배포할 수 있습니다. 이 경우 규정 준수를 위해 랜딩 존 관리 그룹에 적용된 모든 Azure 정책은 그 아래에 있는 모든 구독에 상속됩니다. 여기에는 관리자가 구성한 정책과 함께 DTL 리소스가 포함됩니다.
  • DTL은 탐색, 학습 및 조사를 위해 샌드박스 환경에서 구성할 수도 있습니다. 이 경우 DTL은 최소한의 제한이 있고 사용자가 자유롭게 탐색할 수 있도록 하는 샌드박스 관리 그룹의 구독에 배포할 수 있습니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

보안 주체 작성자:

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계