다음을 통해 공유

Azure DevTest Labs 인프라 강화

  • 아티클

엔터프라이즈 규모에서 DevTest Labs를 성공적으로 구현하려면 주요 결정 사항을 고려하고 Azure DevTest Labs의 신속한 배포 및 구현을 위한 방식을 계획해야 합니다.

이 문서에서는 구현을 계획할 때 고려해야 할 주요 결정 사항을 설명하고 권장되는 배포 방식을 제공합니다.

주요 결정 사항

엔터프라이즈급으로 DevTest Labs를 구현하기 전에 몇 가지 중요한 사항을 결정해야 합니다. 높은 수준에서 이러한 결정 사항을 파악하는 조직은 향후에도 적절한 디자인 관련 결정을 내릴 수 있습니다. 하지만 이러한 결정 사항으로 인해 조직의 개념 증명 시작이 지연되어서는 안 됩니다.

초기 강화 계획에 포함되는 세 가지 주요 영역은 다음과 같습니다.

  • 네트워킹 및 보안
  • 구독 토폴로지
  • 역할 및 책임

네트워킹 및 보안

네트워킹 및 보안은 어떤 조직에서나 운영의 토대가 되는 요소입니다. 엔터프라이즈급 배포를 진행하려면 훨씬 더 심층적인 분석이 필요하지만, 개념 증명을 올바르게 완료하는 데 필요한 요구 사항의 수는 배포보다는 적습니다. 개념 증명 시에 중점적으로 파악해야 하는 몇 가지 주요 영역은 다음과 같습니다.

  • Azure 구독 - DevTest Labs를 배포하려면 Azure 구독에 액세스할 수 있어야 하며 리소스를 만드는 데 적합한 권한이 있어야 합니다. 기업계약, 종량제 등의 여러 가지 방식을 통해 Azure 구독 액세스 권한을 얻을 수 있습니다. Azure 구독 액세스 권한을 얻는 방법에 대한 자세한 내용은 엔터프라이즈용 Azure 라이선싱을 참조하세요.
  • 온-프레미스 리소스 액세스 – DevTest Labs의 리소스가 온-프레미스 리소스에 액세스할 수 있어야 하는 조직도 있습니다. 온-프레미스 환경에서 Azure로의 보안 연결이 필요합니다. 시작하기 전에 VPN 또는 Azure ExpressRoute 연결을 설정하고 구성하는 것이 중요합니다. 자세한 내용은 가상 네트워크 개요를 참조하세요.
  • 기타 보안 요구 사항 - 개념 증명을 구현하기 전에 컴퓨터 정책, 공용 IP 주소 액세스, 인터넷 연결 등의 기타 보안 요구 사항을 검토해야 할 수 있습니다.

구독 토폴로지

구독 토폴로지는 기업에 DevTest Labs를 배포할 때 반드시 고려해야 하는 디자인 관련 요소입니다. 하지만 개념 증명이 완료될 때까지 모든 사항을 확정해야 하는 것은 아닙니다. 엔터프라이즈 구현에 필요한 구독 수를 평가할 때 고려할 수 있는 두 가지 상반된 방식은 다음과 같습니다.

  • 전체 조직에 구독 하나 사용
  • 사용자별 구독 사용

다음 섹션에서는 각 방식의 장점에 대해 중점적으로 설명합니다.

구독 하나 사용

대기업에서는 구독 하나를 사용하는 방식을 효율적으로 관리할 수 없는 경우가 많습니다. 그러나 구독 수를 제한하는 경우에는 다음과 같은 이점이 제공됩니다.

  • 예측 - 기업의 구독 비용을 예측할 수 있습니다. 구독이 하나이면 모든 리소스가 단일 풀에 포함되므로 예산을 책정하기가 훨씬 쉬워집니다. 이 방식에서는 청구 주기의 특정 시점에 비용 제어 조치를 취할 시기를 더 간단하게 결정할 수 있습니다.
  • 관리 효율성 - 여러 구독을 업데이트하는 것이 아니라 구독 하나에서만 모든 업데이트를 수행하면 되므로 VM, 아티팩트, 수식, 네트워크 구성, 권한, 정책을 더 쉽게 관리할 수 있습니다.
  • 네트워킹 - 온-프레미스 연결 기능이 필요한 기업의 경우 구독이 하나이면 네트워킹 작업이 더 간소화됩니다. 추가 구독이 있으면 여러 구독에서 가상 네트워크를 연결해야 하는데(허브-스포크 모델), 그러려면 추가 구성과 관리를 수행해야 하며 IP 주소 공간도 추가로 필요합니다.
  • 팀 협업 - 모든 작업자가 같은 구독에서 작업을 하므로 협업을 더 쉽게 수행할 수 있습니다. 예를 들어 동료에게 VM을 다시 할당하거나 팀 리소스를 공유하는 것이 더 쉽습니다.

사용자별 구독 사용

사용자별로 별도의 구독을 사용하는 방식 역시 단일 구독과 동일한 기회를 제공합니다. 여러 구독을 사용하는 경우의 이점은 다음과 같습니다.

  • Azure 크기 조정 할당량은 채택을 방해하지 않습니다. 예를 들어 이 문서 작성 시점에 Azure에서는 구독당 스토리지 계정 200개를 포함할 수 있습니다. 그리고 Azure 내 대다수 서비스에는 운영 할당량도 있으며 대부분의 할당량(전체는 아님)은 사용자 지정할 수 있습니다. 이 사용자별 구독 모델에서는 대부분의 할당량에 도달하는 상황이 발생할 가능성이 거의 없습니다. 현재 Azure 크기 조정 할당량에 대한 자세한 내용은 Azure 구독 및 서비스 제한, 할당량 및 제약 조건을 참조하세요.
  • 지불 거절 - 조직에서 현재 모델을 사용해 비용을 처리할 수 있으므로 그룹이나 개별 개발자에 대한 지불 거절이 훨씬 쉬워집니다.
  • 소유권 및 권한 - DevTest Labs의 환경에서는 단순한 권한과 소유권이 사용됩니다. 즉, 개발자에게 구독 수준 액세스 권한을 제공하며 네트워킹 구성, 랩 정책, VM 관리 등의 모든 작업에 대해서는 전적으로 개발자가 책임을 집니다.

하지만 기업에서는 제약 조건이 많아 위의 두 가지 극단적 방식을 사용하기가 어려울 수 있습니다. 그러므로 이 두 방식의 중간에 해당하는 방식으로 구독을 설정해야 할 수 있습니다. 모범 사례에 따르면, 조직은 가능한 한 적은 수의 구독 사용을 목표로 해야 합니다. 총 구독 수를 늘리는 강제 함수에 유의하세요. 이처럼 구독 토폴로지는 DevTest Labs의 엔터프라이즈 배포에서 중요한 요소이기는 하지만 구독 토폴로지로 인해 개념 증명이 지연되어서는 안 됩니다. 조직의 구독 및 랩 세분성을 결정하는 방법에 대한 세부 정보는 거버넌스 문서에 나와 있습니다.

역할 및 책임

DevTest Lab 개념 증명에는 각기 책임이 정의된 세 가지 기본 역할(구독 소유자, DevTest Labs 소유자, DevTest Labs 사용자)이 포함되며 필요에 따라 참가자도 포함될 수 있습니다.

  • 구독 소유자 – 구독 소유자에게는 사용자 할당, 정책 관리, 네트워킹 토폴로지 작성/관리, 할당량 증가 요청을 비롯한 Azure 구독을 관리하기 위한 권한이 있습니다. 자세한 내용은 문서를 참조하십시오.
  • DevTest Labs 소유자 - DevTest Labs 소유자에게는 랩에 대한 모든 관리 권한이 있습니다. 이 사용자는 사용자 추가/제거, 비용 설정 관리, 일반 랩 설정, 기타 VM/아티팩트 기반 작업을 담당합니다. 랩 소유자에게는 모든 DevTest Labs 사용자 권한도 있습니다.
  • DevTest Labs 사용자 – DevTest Labs 사용자는 랩에서 가상 머신을 만들고 사용할 수 있습니다. 이 개별 사용자에게는 직접 만드는 VM에 대한 최소한의 관리 기능(VM 시작/중지/삭제/구성)이 제공됩니다. 하지만 다른 사용자의 VM을 관리할 수는 없습니다.

DevTest Labs의 구현 오케스트레이션

이 섹션에서는 Azure DevTest Labs의 신속한 배포 및 구현을 위해 권장되는 방식을 제공합니다. 아래 그림에는 다양한 업계 요구 사항과 시나리오 지원을 위한 유연성을 확인하면서 진행할 수 있는 전체 프로세스가 규범 지침 형식으로 강조 표시되어 있습니다.

Diagram showing steps for implementing Azure DevTest Labs.

가정

이 문서에서는 DevTest Labs 파일럿을 구현하기 전에 다음 항목을 준비했다고 가정합니다.

  • Azure 구독: 파일럿 팀에게 Azure 구독에 리소스를 배포할 액세스 권한이 있어야 합니다. 개발 및 테스트 워크로드만 구현에 포함되는 경우에는 Windows 가상 머신의 요금이 더 저렴하며 사용 가능한 이미지는 추가로 제공되는 Enterprise DevTest 제품을 선택하는 것이 좋습니다.
  • 온-프레미스 액세스: 필요한 경우 온-프레미스 액세스를 이미 구성한 상태여야 합니다. 사이트 간 VPN 연결 또는 Express 경로를 통해 온-프레미스에 액세스할 수 있습니다. Express 경로를 통한 연결은 대개 설정하는 데 몇 주가 걸릴 수 있으므로 프로젝트를 시작하기 전에 Express 경로를 준비해 두는 것이 좋습니다.
  • 파일럿 팀: DevTest Labs를 사용하는 초기 개발 프로젝트 팀과 해당하는 개발 또는 테스트 활동을 확인했으며, 이러한 팀의 요구 사항/목표/목적을 결정해야 합니다.

중요 시점 1: 초기 네트워크 토폴로지 및 디자인 설정

Azure DevTest Labs 솔루션 배포 시 처음으로 확인해야 하는 주요 분야는 가상 머신에 대해 계획된 연결을 설정하는 것입니다. 아래 단계에서는 필요한 절차를 대략적으로 설명합니다.

  1. Azure에서 DevTest Labs 구독에 할당되는 IP 초기 IP 주소 범위를 정의합니다. 이 단계에서는 이후 확장에 대비해 충분히 큰 블록을 제공할 수 있도록 VM 수의 예상 사용량을 예측해야 합니다.
  2. DevTest Labs에 대해 원하는 액세스 방법을 확인합니다(예: 외부/내부 액세스). 이 단계에서는 가상 머신에 공용 IP 주소를 사용할지(인터넷에서 해당 가상 머신에 직접 액세스할 수 있는지) 여부를 결정해야 합니다.
  3. 나머지 Azure 클라우드 환경 및 온-프레미스와의 연결 방법을 확인하고 설정합니다. Express 경로를 통한 강제 라우팅을 사용하는 경우 가상 머신에는 회사 방화벽을 통과할 수 있는 적절한 프록시 구성이 필요할 가능성이 많습니다.
  4. VM을 도메인에 가입시키려는 경우에는 클라우드 기반 도메인(예: Microsoft Entra Directory Services)에 가입할지 아니면 온-프레미스 도메인에 가입할지를 결정합니다. 온-프레미스의 경우 가상 머신이 가입하는 Active Directory 내 OU(조직 구성 단위)를 결정합니다. 또한 사용자에게 VM이 가입된 도메인 액세스 권한이 있는지를 확인하거나 도메인에서 컴퓨터 레코드를 만들 수 있는 서비스 계정을 설정합니다.

중요 시점 2: 파일럿 랩 배포

네트워크 토폴로지를 구축한 후에는 다음 단계를 수행하여 첫 번째/파일럿 랩을 만들 수 있습니다.

  1. 초기 DevTest Labs 환경을 만듭니다.
  2. 랩에서 사용할 허용 가능한 VM 이미지와 크기를 결정합니다. DevTest Labs에 사용할 사용자 지정 이미지를 Azure에 업로드할 수 있는지 여부를 결정합니다.
  3. 랩에 대한 초기 Azure RBAC(Azure 역할 기반 액세스 제어)를 만들어(랩 소유자 및 랩 사용자) 랩에 대한 액세스를 보호합니다. DevTest Labs의 ID로는 Microsoft Entra ID와 동기화되는 Active Directory 계정을 사용하는 것이 좋습니다.
  4. 일정, 비용 관리, 클레임할 수 있는 VM, 사용자 지정 이미지 또는 수식과 같은 정책을 사용하도록 DevTest Labs를 구성합니다.
  5. Azure Repos/Git 등의 온라인 리포지토리를 설정합니다.
  6. 사용할 리포지토리(공용 리포지토리, 프라이빗 리포지토리 또는 두 리포지토리의 조합)를 결정합니다. 배포 및 장기 유지용으로 JSON 템플릿을 구성합니다.
  7. 필요한 경우 사용자 지정 아티팩트를 만듭니다. 이 단계는 선택 사항입니다.

중요 시점 3: 설명서, 지원, 학습, 개선

초기 파일럿 팀이 구현을 시작하려면 심층 지원이 필요할 수도 있습니다. 초기 팀의 경험을 토대로 하여 Azure DevTest Labs를 지속적으로 출시하는 데 적합한 설명서와 지원 방법을 준비합니다.

  1. 파일럿 팀에게 신규 DevTest Labs 리소스(데모, 설명서)를 소개합니다.
  2. 파일럿 팀의 경험을 토대로 하여 필요한 설명서를 계획하고 제공합니다.
  3. 공식적인 신규 팀 온보딩 프로세스를 결정합니다(랩 작성/구성, 액세스 권한 제공 등).
  4. 초기 활용도에 따라 원래 예측했던 IP 주소 공간이 현재도 적절하며 정확한지를 확인합니다.
  5. 적절한 규정 준수 및 보안 검토가 완료되었는지 확인합니다.

다음 단계

이 시리즈의 다음 문서인 Azure DevTest Labs 인프라 거버넌스를 확인합니다.