단독 테넌트 노드에서 VM 워크로드를 실행하려면 먼저 단독 테넌트 노드를 배포하는 방법을 결정해야 합니다. 특히 필요한 노드 그룹 수와 노드 그룹에서 사용할 유지보수 정책을 결정해야 합니다.
노드 그룹: 적절한 노드 그룹 수를 선택하려면 가용성과 리소스 사용률을 비교해야 합니다. 노드 그룹이 적으면 리소스 사용률과 비용을 최적화할 수 있지만 단일 영역으로 제한됩니다. 여러 영역에 노드 그룹을 배포하면 가용성을 높일 수 있지만 리소스 사용률이 낮아질 수 있습니다.
자동 확장 및 유지보수 정책: 실행할 운영체제 및 소프트웨어의 라이선스 요구사항에 따라 노드 자동 확장 및 선택한 유지보수 정책이 라이선스 비용과 가용성에 영향을 미칠 수 있습니다.
단독 테넌트 노드 사용 방법을 올바르게 결정하려면 요구사항을 신중하게 고려해야 합니다.
요구사항 평가
다음 섹션에는 필요한 노드 그룹 수와 노드 그룹에서 사용할 유지보수 정책을 결정하기 전에 고려해야 할 여러 요구사항이 나와 있습니다.
BYOL 및 코어당 라이선스
Compute Engine에 Bring Your Own License(BYOL, 사용자 라이선스 사용)를 사용하려는 경우 단독 테넌트 노드를 사용하면 이러한 라이선스로 인한 하드웨어 요구사항 또는 제약조건을 해결할 수 있습니다.
Windows Server와 같은 일부 소프트웨어 및 운영체제는 실제 CPU 코어에서 라이선스를 부여받을 수 있으며 가상 머신의 기반이 되는 하드웨어를 변경할 수 있는 빈도에 대한 제한을 정의할 수 있습니다. 노드 자동 확장 및 기본 유지보수 정책으로 인해 라이선스 약관에서 허용하는 것보다 더 자주 하드웨어가 변경될 수 있으며 이로 인해 추가 라이선스 비용이 발생할 수 있습니다.
코어별 BYOL에 맞게 최적화하려면 다음 권장사항을 따르세요.
인프라 비용 및 라이선스 비용 간 균형 찾기: Compute Engine에서 BYOL 워크로드를 실행하는 전반적인 비용을 계산하려면 인프라 비용과 라이선스 비용을 모두 고려해야 합니다. 경우에 따라 인프라 비용을 최소화하면 라이선스 오버헤드가 증가하거나 그 반대가 될 수 있습니다. 예를 들어 코어 수가 많은 노드 유형을 사용하는 것은 특정 워크로드의 비용/성능 측면에서 가장 좋지만 라이선스의 가격이 코어별로 책정된 경우 추가 라이선스 비용이 발생할 수 있습니다.
BYOL 및 비BYOL 워크로드에 별도의 노드 그룹 사용: 라이선스가 필요한 코어 수를 제한하려면 단일 노드 그룹에서 BYOL 워크로드와 비BYOL 워크로드를 혼합하지 말고 대신 별도의 노드 그룹을 사용하세요.
여러 BYOL 라이선스 모델(예: Windows Server Datacenter 및 Standard)을 사용하는 경우 라이선스 모델로 노드 그룹을 분할하면 라이선스 추적을 간소화하고 라이선스 비용을 줄일 수 있습니다.
코어/메모리 비율이 높은 CPU 오버커밋 및 노드 유형 사용: 노드 유형은 소켓, 코어, 메모리 간의 비율이 다릅니다. 코어 대 메모리 비율이 더 높은 노드 유형을 사용하고 CPU 오버커밋을 사용 설정하면 라이선스에 필요한 코어 수를 줄일 수 있습니다.
수평 축소 자동 확장 방지: 노드 그룹 자동 확장을 사용하면 현재 수요를 기반으로 노드 그룹을 자동으로 늘리거나 줄일 수 있습니다. 노드 그룹이 자주 확장되거나 축소되면 VM이 실행되는 하드웨어를 자주 변경한다는 의미입니다.
물리적 머신 간에 라이선스를 이동할 수 있는 하드웨어를 더 자주 변경할 경우 이러한 하드웨어 변경으로 인해 실제로 사용하는 코어에 대해 라이센스를 더 부여받아야 할 수 있습니다.
물리적 머신 간에 이동할 수 있는 빈도에 제한이 있는 경우 자동 확장을 사용 중지하거나 수평 확장만으로 자동 확장을 구성하여 과도한 라이선스 비용을 피할 수 있습니다.
기본 유지보수 정책 사용 안 함: 기본 유지보수 정책을 사용하면 VM 가용성을 최적화하지만 하드웨어 변경을 자주 유발할 수 있습니다. 하드웨어 변경을 최소화하고 라이선스 비용을 최적화하려면 노드 그룹 내 마이그레이션 유지보수 또는 그대로 다시 시작 정책을 사용하세요.
코어별 라이선스가 필요하지 않은 워크로드의 경우 다음 권장사항을 대신 고려하세요.
- 기본 유지보수 정책 사용: 라이브 마이그레이션을 사용하면 기본 유지보수 정책은 그대로 다시 시작 정책보다 더 높은 가용성을 제공하며 노드 그룹 내 마이그레이션 유지보수 정책의 추가 인프라 비용을 방지할 수 있습니다.
관리
워크로드가 두 개 이상 있거나 단독 테넌트 노드에서 실행해야 하는 개발 워크로드와 프로덕션 워크로드가 모두 있는 경우 다음 권장사항을 고려하세요.
개발 및 프로덕션 환경에 별도의 노드 그룹 사용: 별도의 노드 그룹을 사용하면 환경을 다른 노드와 격리하고 다음과 같은 상황을 방지할 수 있습니다.
- 개발 VM은 CPU, 디스크 또는 네트워크 리소스('시끄러운 이웃')를 과도하게 소비하여 프로덕션 VM의 성능에 영향을 주는 상황
- 개발 워크로드가 노드 그룹의 용량을 소진하여 새 프로덕션 VM 생성을 방해하는 상황
각 환경에서 노드 그룹 수 제한: 여러 노드 그룹을 실행하는 경우 각 노드 그룹을 완전히 활용하기 어려울 수 있습니다. 사용률을 최적화하려면 각 환경의 워크로드를 결합하고 적은 수의 노드 그룹에 예약하세요.
노드 그룹 관리 전용 프로젝트 사용: 각 환경에 대해 노드 그룹을 관리할 전용 프로젝트를 만듭니다. 그런 다음 워크로드가 포함된 프로젝트와 노드 그룹을 공유합니다.
이 접근 방식을 사용하면 각 워크로드마다 별도의 프로젝트를 사용하여 액세스 제어를 간소화하는 동시에 워크로드 간에 노드 그룹을 공유하여 리소스 사용률을 최적화할 수 있습니다.
노드 그룹을 개별 프로젝트와 공유: 노드 그룹을 전체 조직과 공유하는 대신 개별 프로젝트와만 공유합니다. 프로젝트를 개별적으로 선택하면 환경 간 분리를 유지하고 노드 그룹에 대한 정보가 다른 프로젝트에 공개되지 않습니다.
내부 비용 기여 분석 프로세스 설정: 노드 그룹 실행 비용은 노드 그룹이 포함된 프로젝트에서 발생합니다. 이 비용을 개별 프로젝트 또는 워크로드에 기여해야 하는 경우 단독 테넌트 VM의 사용량을 추적하고 이 데이터를 사용하여 내부 비용 기여 분석을 수행하는 방법을 고려하세요.
사용 가능 여부
워크로드는 가용성 요구사항, 고가용성이 애플리케이션 레이어에서 실현될 수 있는지 또는 인프라 레이어에서 구현되어야 하는지 여부에 따라 다릅니다.
클러스터링된 애플리케이션: 일부 워크로드는 복제 및 부하 분산과 같은 클러스터링 기법을 사용하여 애플리케이션에서 고가용성을 구현할 수 있습니다.
이러한 워크로드의 예시로는 Active Directory 도메인 컨트롤러, SQL Server 장애 조치 클러스터 인스턴스 및 가용성 그룹, IIS에서 실행되는 클러스터링된 부하 분산 애플리케이션이 있습니다.
대부분의 VM이 사용 가능한 경우 클러스터링된 애플리케이션은 일반적으로 개별 VM 중단을 유지할 수 있습니다.
클러스터링되지 않은 애플리케이션: 일부 워크로드는 클러스터링 기능을 구현하지 않을 수 있으며 대신 VM 자체를 계속 사용할 수 있어야 합니다.
이러한 워크로드의 예시로는 복제되지 않은 데이터베이스 서버 또는 스테이트풀(Stateful) 애플리케이션 서버가 있습니다.
개별 VM의 가용성을 최적화하려면 예정된 노드 유지보수 이벤트가 발생한 경우 VM을 라이브 마이그레이션할 수 있는지 확인해야 합니다.
라이브 마이그레이션은 기본 유지보수 정책 및 노드 그룹 내 마이그레이션 유지보수 정책에서 지원되지만 그대로 다시 시작 유지보수 정책을 사용하는 경우 지원되지 않습니다.
비핵심 애플리케이션: 일괄 워크로드, 개발/테스트 워크로드, 기타 우선순위가 낮은 워크로드는 특별한 가용성 요구사항이 없을 수 있습니다. 이러한 워크로드의 경우 노드 유지보수 중에 개별 VM을 사용할 수 없는 경우 허용될 수 있습니다.
워크로드의 가용성 요구사항을 충족하려면 다음 권장사항을 살펴보세요.
다른 영역 또는 리전의 노드 그룹을 사용하여 클러스터링된 워크로드 배포: 단독 테넌트 노드와 노드 그룹은 영역별 리소스입니다. 영역별 중단를 방지하려면 여러 영역 또는 리전에 여러 노드 그룹을 배포합니다. 노드 어피니티를 사용하여 클러스터링된 애플리케이션의 각 인스턴스가 다른 영역 또는 리전의 서로 다른 노드에서 실행되도록 합니다.
2개 이상의 노드 그룹에서 기본 또는 그대로 다시 시작 유지보수 정책을 사용하는 경우 유지보수 기간이 중복되지 않도록 구성합니다.
클러스터링된 애플리케이션의 여러 인스턴스가 단일 영역에서 실행되어야 하는 경우 안티-어피니티를 사용하여 VM 인스턴스가 서로 다른 노드 또는 노드 그룹에 예약되도록 합니다.
고가용성이 필요한 클러스터링되지 않은 워크로드에 대한 그대로 다시 시작 유지보수 정책 방지: 그대로 다시 시작 유지보수 정책은 기본 노드에 유지보수가 필요할 때 필요로 할 때 VM을 종료하므로 고가용성이 필요한 클러스터링되지 않은 워크로드를 실행하는 노드 그룹에 다른 유지보수 정책을 사용하는 것이 좋습니다.
관리형 인스턴스 그룹을 사용하여 워크로드의 복원력 및 가용성 향상: 워크로드 상태를 모니터링하고 필요한 경우 자동으로 VM 인스턴스 재생성하는 데 관리형 인스턴스 그룹을 사용하여 배포의 복원력과 가용성을 높일 수 있습니다. 스테이트리스(Stateless) 및 스테이트풀(Stateful) 워크로드 모두에 관리형 인스턴스 그룹을 사용할 수 있습니다.
성능
워크로드는 성능 변동에 민감할 수 있습니다. 특정 내부 애플리케이션 또는 테스트 워크로드의 경우 하루 동안 일관된 성능을 보장하는 것보다 비용 최적화가 더 중요할 수 있습니다. 외부에 노출된 애플리케이션과 같은 다른 워크로드의 경우 리소스 사용률보다 성능이 더 핵심적이고 중요할 수 있습니다.
단독 테넌트 노드를 최대한 활용하려면 다음 권장사항을 고려하세요.
성능에 민감한 워크로드에 전용 노드 그룹 및 CPU 오버커밋 사용: CPU 오버커밋을 사용하면 단독 테넌트 노드의 VM 밀도를 높이고 필요한 단독 테넌트 노드 수를 줄일 수 있습니다.
CPU 오버커밋을 사용하려면 CPU 오버커밋을 지원하는 노드 유형을 사용해야 합니다. 노드 그룹에 CPU 오버커밋을 사용 설정하면 단독 테넌트 노드당 추가 요금이 발생합니다.
CPU 오버커밋에 적합한 워크로드에 전용 노드 그룹을 사용하고 이 노드 그룹에만 CPU 오버커밋을 사용 설정하는 경우 CPU 오버커밋이 가장 경제적일 수 있습니다. 성능에 민감한 워크로드를 실행해야 하는 모든 노드 그룹에는 CPU 오버커밋을 사용 중지된 상태로 둡니다.
CPU 오버커밋에 높은 코어 대 메모리 비율로 노드 유형 사용: CPU 오버커밋을 사용하면 VM 간에 코어를 공유할 수 있지만 VM 간에 메모리를 공유할 수는 없습니다. CPU 코어당 메모리가 더 많은 노드 유형을 사용하면 메모리가 제한 요소가 되지 않을 수 있습니다.
성능에 민감한 워크로드에 노드 자동 확장 사용: 성능에 민감한 워크로드에 대한 다양한 리소스 요구사항을 수용하려면 자동 확장을 사용하도록 노드 그룹을 구성합니다.
배포 패턴
단독 테넌트 노드를 사용하는 가장 좋은 방법은 개별 요구사항에 따라 달라집니다. 다음 섹션에서는 개별 요구사항에 맞는 아키텍처를 파생하기 위한 시작점으로 사용할 수 있는 패턴을 설명합니다.
혼합 성능 요구사항을 위한 여러 노드 그룹
성능에 민감한 워크로드(예: 고객 대면 애플리케이션)와 성능에 민감한 애플리케이션(예: 내부 애플리케이션)의 조합이 있는 경우 서로 다른 노드 유형을 사용하는 여러 노드 그룹을 사용할 수 있습니다.
- 한 노드 그룹은 CPU 오버커밋과 vCPU 대 메모리 비율이 1:8인 노드 유형을 사용합니다. 이 노드 그룹은 성능에 민감하지 않은 워크로드에 사용됩니다.
- 두 번째 노드 그룹은 CPU 오버커밋 없이 vCPU 대 메모리 비율이 1:4인 컴퓨팅 최적화 노드 유형을 사용합니다. 이 노드 그룹은 성능이 중요한 워크로드에 사용되며 필요에 따라 확장 및 축소되도록 구성됩니다.
클러스터링된 코어당 라이선스가 부여된 워크로드에 대한 다중 영역 고가용성
코어당 라이선스를 사용하는 클러스터링된 워크로드를 실행하고 하드웨어 변경사항을 최소화해야 하는 경우 유지보수 기간이 겹치지 않는 여러 노드 그룹을 사용하여 가용성과 라이선스 오버헤드 간의 균형을 맞출 수 있습니다.
- 여러 노드 그룹이 여러 영역 또는 리전에 배포됩니다.
- 모든 노드 그룹은 다시 시작 유지보수 정책을 사용합니다. 노드 그룹이 겹치지 않는 유지보수 기간을 사용하므로 한 번에 하나의 노드 그룹에만 유지보수 관련 중단이 발생할 수 있습니다.
- 클러스터링된 워크로드를 실행하는 VM 인스턴스는 어피니티 라벨을 사용하므로 각 클러스터 노드가 다른 영역의 노드 그룹에 예약됩니다.
혼합된 코어당 라이선스가 부여된 워크로드의 다중 영역 고가용성
코어별 라이선스를 사용하지만 모든 워크로드가 클러스터링되지 않은 경우 이기종 유지보수 정책을 사용하여 이전 패턴을 확장할 수 있습니다.
- 기본 노드 그룹은
a영역에 배포되며 클러스터링된 워크로드와 클러스터링되지 않은 워크로드를 모두 실행합니다. 하드웨어 유지보수로 인한 서비스 중단을 최소화하기 위해 노드 그룹은 노드 그룹 내 마이그레이션 유지보수 정책을 사용합니다. - 하나 이상의 보조 노드 그룹이 추가 영역 또는 리전에 배포됩니다. 이러한 노드 그룹은 다시 시작 유지보수 정책을 사용하지만 겹치지 않는 유지보수 기간을 사용합니다.
- 클러스터링된 워크로드를 실행하는 VM 인스턴스는 어피니티 라벨을 사용하므로 각 클러스터 노드가 다른 영역의 노드 그룹에 예약됩니다.
- 클러스터링되지 않은 워크로드를 실행하는 VM 인스턴스는 어피니티 라벨을 사용하여 기본 노드 그룹에 배포됩니다.
보조 노드 그룹에서 클러스터링된 워크로드만 예약하면 다시 시작 유지보수 정책으로 인한 일시적인 서비스 중단이 전체 가용성에 미치는 영향을 최소화할 수 있습니다. 동시에 기본 노드 그룹에 대해서만 노드 그룹 내 마이그레이션 유지보수 정책을 사용하여 라이선스 및 인프라 오버헤드를 제한합니다.
다음 단계
단독 테넌트 노드 자세히 알아보기
단독 테넌트 VM의 CPU 오버커밋 방법 알아보기