Google Cloud VMware Engine 배포 비용 최적화

* 본 아티클의 원문은 2022년 1월 28일 Google Cloud 블로그(영문)에 게재되었습니다.

Google Cloud VMware Engine에서는 ESXi 노드를 주문형으로 추가하고 삭제할 수 있어 단 몇 분 만에 전용 하드웨어와 함께 관리형 VMware 환경을 배포할 수 있습니다. 이러한 유연성은 필요에 따라 컴퓨팅 용량을 빠르게 추가할 때 특히 편리합니다. 하지만 예상치 못한 비용 증가를 피하려면 비용 최적화 전략과 검토 프로세스를 구현해야 합니다. 늘어난 워크로드 용량을 수용하려면 하드웨어를 ESXi 클러스터에 추가해야 하므로 프라이빗 클라우드를 확장할 때는 각별한 주의가 필요합니다.

이 블로그에서는 전반적인 비용 최적화에 초점을 맞춰 Google Cloud VMware Engine 프라이빗 클라우드를 운영하기 위한 권장사항을 살펴봅니다.

Google Cloud VMware Engine 결제 원칙

고객에게는 배포된 VMware ESXi 노드 수를 기준으로 한 시간 단위 요금이 청구됩니다. Compute Engine에서 가상 머신 인스턴스에 제공하는 약정 기반 가격 책정 모델과 마찬가지로 Google Cloud VMware Engine도 1년 및 3년 약정 사용 할인을 제공합니다. 자세한 가격 책정 정보는 Google Cloud VMware Engine 제품 개요 페이지의 가격 책정 섹션을 참조하세요.

비용 최적화 전략 1: 약정 사용 할인 적용

약정 사용 할인(CUD)은 1년 또는 3년간 특정 리전에서 여러 Google Cloud VMware Engine 노드를 실행한다는 약정을 기반으로 한 할인입니다. 3년 약정의 CUD에서는 계약이 시작될 때 비용을 전액 청구할 경우 최대 50% 할인이 제공될 수 있습니다. 예상하셨겠지만 약정 기반 할인은 구매 후 취소할 수 없습니다. 따라서 프라이빗 클라우드에서 실행할 노드 수에 대한 확신이 있어야 합니다. Google Cloud VMware Engine이 데이터 센터를 마이그레이션할 대상 플랫폼이라면 1년 또는 3년간 실행할 최소한의 노드 수에 이 할인을 적용하고 정기적으로 필요한 노드 수를 수정하세요.

비용 최적화 전략 2: 스토리지 소비 최적화

워크로드에서 많은 스토리지를 소비하는 경우(예: 백업 시스템, 파일 서버 또는 대규모 데이터베이스) 클러스터를 확장해 추가 vSAN 스토리지 용량을 추가해야 할 수 있습니다. 스토리지 소비를 적게 유지하려면 다음 최적화 전략을 고려해 보세요.

1. 동일한 수준의 FTT(허용되는 장애)를 유지하면서 RAID 1(기본 스토리지 정책)이 아닌 RAID 5 또는 RAID 6을 사용하는 커스텀 스토리지 정책을 적용하세요. FTT 수는 ESXi 클러스터의 월간 업타임 SLA와 직접적인 관련이 있어 주요 측정항목으로 간주됩니다. RAID 1 인코딩 스키마는 중복성을 위해 데이터 블록을 미러링하기 때문에 FTT=1인 RAID 1을 사용하는 스토리지 정책에서는 스토리지 오버헤드가 100% 발생하게 됩니다. 마찬가지로 FTT=2가 필요한 경우(예: 99.99% 업타임 가용성을 필요로 하는 보다 중요한 워크로드) RAID 1에서 스토리지 오버헤드가 200% 생성됩니다. RAID 5 구성은 FTT=1인 스토리지 정책을 33%에 불과한 스토리지 오버헤드로 달성할 수 있으므로 스토리지 효율성이 더 높습니다. RAID 6에서도 FTT=2를 단 50%의 스토리지 오버헤드로 제공할 수 있습니다. 즉, RAID 1 기본 스토리지 정책을 사용할 때보다 스토리지 소비를 50% 절약할 수 있습니다. 그러나 RAID 1은 스토리지 기기에 대해 필요한 I/O 작업 수가 적으며 더 나은 성능을 제공할 수 있다는 점을 참고하세요.
2. '씬 프로비저닝' 형식을 사용해 새 디스크를 만드세요. 씬 프로비저닝된 디스크는 소규모로 시작했다가 디스크에 기록되는 데이터가 늘어남에 따라 확장되므로 스토리지 공간을 절약할 수 있습니다.
3. vSAN 스토리지를 백업으로 채우지 마세요. Actifio와 같은 백업 도구는 VMware 환경 및 Cloud Storage와의 통합을 제공합니다. 이에 따라 운영자는 저렴한 스토리지 위치로 백업을 이동시킬 수 있습니다. 장기 보관해야 하는 백업 데이터는 특정 기간이 지난 후 저렴한 스토리지 클래스로 데이터를 이동시키는 수명 주기 정책을 사용해 Cloud Storage 버킷 내에 저장해야 합니다.
4. vSAN 클러스터의 중복 삭제 및 압축을 사용해 중복된 데이터 블록 수를 줄여 전체 스토리지 소비를 줄이세요.

비용 최적화 전략 3: ESXi 클러스터 크기 조정

1. CPU, 메모리, 스토리지 사용률이 높아도 워크로드 장애 없이 ESXi 노드의 중단을 지원할 수 있도록 ESXi 클러스터 크기를 조정하세요. 리소스 사용률이 최대 용량에 가깝게 클러스터를 작동시킬 경우 갑작스러운 하드웨어 장애가 발생하면 서비스 중단이 발생할 수 있습니다. 최대 리소스 사용률 측정항목(CPU, 메모리 또는 스토리지)을 약 70%로 설정하면 클러스터를 안전하게 작동하면서 클러스터의 기능을 사용할 수 있습니다.
   
2. 단일 노드 클러스터로 새 프라이빗 클라우드 배포를 시작하고 필요할 때 확장하세요. Google Cloud VMware Engine에 최근 테스트 및 개념 증명을 위해 단일 노드를 포함한 프라이빗 클라우드를 만들 수 있는 기능을 추가했습니다. 단일 노드 클러스터는 최대 60일 동안만 유지되며 SLA가 적용되지 않습니다. 하지만 2일 차 도구, 구성, 테스트와 통합하는 동안 비용을 최소화할 수 있는 좋은 방법입니다. 프라이빗 클라우드 시작 영역을 완전히 구성한 후 단일 노드 클러스터를 노드가 3개인 클러스터로 확장해 SLA의 적용을 받을 수 있습니다.
   
3. 가능하다면 ESXi 클러스터를 통합하세요. 여러 개의 클러스터에서 워크로드를 실행 중이라면 여러 클러스터에서 리소스가 보다 효율적으로 분산되도록 클러스터를 통합할 수 있는지 검토하세요. 예를 들어 워크로드가 OS 유형 또는 프로덕션 및 비프로덕션에 따라 구분되어 있는 경우 클러스터를 통합하면 리소스 사용률을 높일 수 있습니다. 하지만 라이선스 요구사항 등 통합을 막는 기타 제약조건이 있는지 신중하게 검토해야 합니다. 라이선스 요구사항으로 인해 VM을 특정 노드에서 실행해야 한다면 DRS 어피니티 규칙을 사용해 워크로드를 특정 노드에 고정하는 것을 고려하세요.
   
4. 가능하다면 프라이빗 클라우드를 통합하세요. 프라이빗 클라우드를 여러 개 실행하는 경우 프라이빗 클라우드를 통합할 수 있는지 검토하세요. 프라이빗 클라우드마다 자체적인 관리 VM 집합이 필요하기 때문에 전체 리소스 소비에 오버헤드가 발생합니다.

비용 최적화 전략 4: 워크로드의 리소스 사용률 검토

1. 애플리케이션이 안정적으로 실행되면 이후 지속적으로 VM의 리소스 사용률을 검토하세요. vCenter 측정항목을 프로그래매틱 방식으로 또는 시각적으로 추출하여 적정 크기 권장사항을 확보하세요. 예를 들어 VM에서 CPU 및 메모리 리소스를 필요 이상으로 사용하는 경우 애플리케이션의 정기 다운타임 동안 VM 매개변수를 조정하세요(재부팅 필요).

vCenter에서 CPU 및 메모리 사용률 통계를 추출하고 데이터를 CSV 파일 등의 편리한 형식으로 저장하는 스크립트의 실행을 예약해 보세요. 예를 들어 스크립트 실행 호스트에서 PowerShell을 사용해 이를 구현할 수 있습니다.

최소 30일간의 평균 CPU 및 메모리 사용률을 합리적인 기준 값과 비교하여 워크로드를 사용률 초과 또는 미달 리소스로 분류하는 기준을 정의하세요.

예시 조건(요구사항에 맞춰 기준 조정 가능):

1. CPU 사용량(30일 및 1년 평균) 비율 (<) 50% 미만
2. CPU 사용량(30일 및 1년 최대) 비율 (<) 80% 미만

위와 같이 권장되지만 갑작스러운 변경은 피하고 워크로드 요구사항을 기준으로 항상 신중하게 데이터를 검토해야 합니다.

2. Cloud Monitoring 및 독립형 에이전트 통합을 사용해 클러스터 및 워크로드 측정항목을 검토하세요. 설치 가이드를 따라 측정항목 전달을 사용 설정해 vCenter 측정항목을 Cloud Monitoring과 통합합니다.

3. 워크로드가 CPU/메모리의 제약을 받는 경우 VMware vROps와 같은 타사 도구를 사용해 확보한 용량 및 사용률 통계를 바탕으로 적정 크기로 조정하세요(자세한 내용은 블로그 게시물 참조). vROps를 사용하려면 추가 라이선스가 필요하며 VM/호스트마다 vROps를 설치해야 합니다.

비용 최적화 관리 - 인력 및 프로세스

비용 최적화의 효율성은 운영을 지원하고 실행할 수 있는 인력 및 프로세스의 준비 여건에도 달려 있습니다.

1. 비용 최적화 부서 마련 - 클라우드 운영 모델의 비용 관리 및 최적화는 단일 팀의 책임이 아니며 오히려 여러 팀/역할의 공동의 노력이 필요합니다. 최적화를 공동의 최우선 과제로 삼고 Cloud 핵심 전략팀(CoE), 재무팀(최적화 목표 정의 및 지출 모니터링), 설계팀(최적화 옵션 검토), 운영/SRE팀(옵션 구현) 내에 비용 최적화를 위한 중앙 부서를 구축하려면 경영진의 후원과 지원이 필요합니다. 가용성 및 성능이 워크로드에 미치는 영향을 검증하기 위해 비즈니스/애플리케이션 이해관계자의 참여도 이끌어내야 합니다.

2. Crawl-Walk-Run(기어가기-걷기-달리기) 접근방식 채택 - 비용 최적화는 지속적인 작업으로서 기업의 클라우드 도입 성숙도 곡선을 따릅니다. 시작할 때 지원 프로세스 및 도구를 정의하고 확장하면서 개선해 나가세요.

3. 최적화 옵션 우선순위 지정 - 최적화는 상당한 비용 절감 효과를 가져올 수 있지만 이를 위해서는 리소스 노력과 시간이 소요됩니다. 잠재적 절감 효과와 예상되는 작업량을 토대로 옵션의 우선순위를 정하여 지출을 줄이고 즉각적 성과를 실현할 수 있는 가장 영향력 있는 방법을 찾아야 합니다.

4. 보고 및 측정 - 중요한 주요 측정항목(예: 사용자/테넌트-고객당 비용)을 식별하고 KPI를 정의하여 이를 기준으로 최적화 성과 및 성공을 지속적으로 측정해야 합니다.

재무 책임 및 비즈니스 가치 실현을 위한 전체적인 프레임워크는 Cloud FinOps 백서를 참조하세요. 클라우드 비용 최적화 원칙 블로그 게시물에서 도구 및 비용 최적화 권장사항에 대한 추가 안내도 확인하세요.

클릭 유도 문구

이 블로그 게시물에서 프라이빗 클라우드의 전반적인 비용을 절감할 수 있는 다양한 수준의 구현 전략을 살펴보았습니다. 단기간 내에 비용을 절감하기 위해 구현할 수 있는 즉각적 성과로는CUD 사용과 커스텀 스토리지 정책으로 전반적인 vSAN 스토리지 소비 최적화 등이 있습니다. 특히 VMware Engine을 1년 이상 워크로드의 플랫폼으로 사용하는 경우 CUD 사용이 유효합니다.

클러스터 및 VM 사용률 측정항목을 모니터링하는 프로세스 채택을 포함한 최적화 전략은 워크로드가 과도하게 큰지 여부를 파악하는 데 도움이 됩니다. 하지만 워크로드 크기 조정을 서둘러서는 안 되며 안정적인 상태에서 측정항목을 신중하게 검토해야 합니다. 이러한 비용 최적화는 장기적으로 효과가 나타납니다.

Google Cloud에서 개발한 아키텍처 프레임워크는 지출을 최적화하면서 Google Cloud VMware Engine을 도입할 수 있어 클라우드 여정의 수익을 극대화하는 데 도움이 됩니다. 자세한 내용은 Google Cloud 계정팀에 문의하세요.

기업 고객의 비용 최적화 프로세스 구현과 관련해 도움을 주신 웨인 추에게 감사의 말을 전합니다.