Well-Architected 프레임워크의 지속 가능성 요소 원칙은 워크로드의 리소스 사용량을 최적화하는 데 도움이 되는 권장사항을 제공합니다.Google Cloud Google Cloud
원칙 개요
클라우드 환경의 지속 가능성을 높이려면 리소스 사용량을 최적화하는 것이 중요합니다. 컴퓨팅 주기에서 데이터 스토리지에 이르기까지 프로비저닝된 모든 리소스는 에너지 사용량, 물 집약도, 탄소 배출량에 직접적인 영향을 미칩니다. 워크로드의 환경 발자국을 줄이려면 클라우드 리소스를 프로비저닝, 관리, 사용할 때 정보에 입각한 선택을 해야 합니다.
권장사항
리소스 사용량을 최적화하려면 다음 섹션의 권장사항을 고려하세요.
자동 및 동적 확장 구현
자동 및 동적 확장을 사용하면 리소스 사용량이 최적화되어 유휴 상태이거나 과도하게 프로비저닝된 인프라로 인한 에너지 낭비를 방지할 수 있습니다. 낭비되는 에너지가 줄어들면 비용과 탄소 배출량이 줄어듭니다.
다음 기법을 사용하여 자동 및 동적 확장성을 구현하세요.
수평 확장 사용
수평 확장은 대부분의 클라우드 중심 애플리케이션에 권장되는 확장 기법입니다. 수직 확장이라고 하는 각 인스턴스의 크기를 늘리는 대신 인스턴스를 추가하여 부하를 분산합니다. 예를 들어 관리형 인스턴스 그룹 (MIG)을 사용하여 Compute Engine VM 그룹을 자동으로 확장할 수 있습니다. 수평으로 확장된 인프라는 인스턴스 장애가 애플리케이션의 가용성에 영향을 미치지 않으므로 더 복원력이 뛰어납니다. 수평 확장은 부하 수준이 가변적인 애플리케이션을 위한 리소스 효율적인 기법이기도 합니다.
적절한 확장 정책 구성
워크로드의 요구사항에 따라 자동 확장 설정을 구성합니다. 애플리케이션 동작에 특정한 커스텀 측정항목과 임곗값을 정의합니다. CPU 사용률에만 의존하는 대신 비동기 작업의 큐 깊이, 요청 지연 시간, 커스텀 애플리케이션 측정항목과 같은 측정항목을 고려하세요. 잦은 불필요한 확장 또는 플래핑을 방지하려면 명확한 확장 정책을 정의하세요. 예를 들어 Google Kubernetes Engine (GKE)에 배포하는 워크로드의 경우 적절한 클러스터 자동 확장 정책을 구성합니다.
사후 대응적 확장과 사전 예방적 확장 결합
사후 대응적 확장을 사용하면 시스템이 실시간 부하 변화에 따라 확장됩니다. 이 기법은 부하가 예측 불가능하게 급증하는 애플리케이션에 적합합니다.
사전 예방적 확장은 고정된 일일 영업시간 및 주간 보고서 생성과 같이 예측 가능한 패턴이 있는 워크로드에 적합합니다. 이러한 워크로드의 경우 예약된 자동 확장을 사용하여 예상 부하 수준을 처리할 수 있도록 리소스를 미리 프로비저닝합니다. 이 기법은 리소스 확보를 위한 경쟁을 방지하고 효율성을 높여 더 원활한 사용자 환경을 보장합니다. 이 기법은 주요 판매 이벤트 및 집중적인 마케팅 노력과 같은 알려진 부하 급증에 대해 사전에 계획하는 데도 도움이 됩니다.
Google Cloud GKE Autopilot, Cloud Run, MIG와 같은 관리형 서비스 및 기능은 워크로드 패턴을 학습하여 사전 예방적 확장을 자동으로 관리합니다. 기본적으로 Cloud Run 서비스가 트래픽을 수신하지 않으면 인스턴스 0개로 확장됩니다.
스테이트리스(Stateless) 애플리케이션 설계
애플리케이션이 수평으로 확장되려면 구성요소가 스테이트리스(Stateless)여야 합니다. 즉, 특정 사용자의 세션 또는 데이터가 단일 컴퓨팅 인스턴스에 연결되지 않습니다. Redis용 Memorystore와 같이 컴퓨팅 인스턴스 외부에 세션 상태를 저장하면 모든 컴퓨팅 인스턴스가 모든 사용자의 요청을 처리할 수 있습니다. 이 설계 접근 방식을 사용하면 원활하고 효율적인 수평 확장이 가능합니다.
예약 및 일괄 처리 사용
일괄 처리는 대규모의 긴급하지 않은 워크로드에 적합합니다. 일괄 작업은 에너지 효율성과 비용을 위해 워크로드를 최적화하는 데 도움이 될 수 있습니다.
다음 기법을 사용하여 예약 및 일괄 작업을 구현하세요.
저탄소 집약도 일정 예약
탄소 배출량이 적은 리전에서 그리고 지역 전력망에 클린 에너지 비율이 높은 기간에 일괄 작업을 실행하도록 예약합니다. 리전의 탄소 강도가 가장 낮은 시간대를 확인하려면 탄소 발자국 보고서를 사용하세요.
중요하지 않은 워크로드에 스팟 VM 사용
스팟 VM 을 사용하면 사용되지 않는 Compute Engine 용량을 대폭 할인된 가격으로 활용할 수 있습니다. 스팟 VM은 선점될 수 있지만 전용의 항상 사용 가능한 리소스가 필요 없이 대규모 데이터 세트를 비용 효율적으로 처리할 수 있는 방법을 제공합니다. 스팟 VM은 중요하지 않은 내결함성 일괄 작업에 적합합니다.
작업 통합 및 병렬화
개별 작업을 시작하고 종료하는 오버헤드를 줄이려면 유사한 작업을 하나의 대규모 일괄 처리로 그룹화하세요. Batch와 같은 서비스에서 이러한 대규모 워크로드를 실행합니다. 이 서비스는 필요한 인프라를 자동으로 프로비저닝하고 관리하므로 리소스 사용률을 최적화할 수 있습니다.
관리형 서비스 사용
Batch 및 Dataflow 와 같은 관리형 서비스는 리소스 프로비저닝, 예약, 모니터링을 자동으로 처리합니다. 클라우드 플랫폼은 리소스 최적화를 처리합니다. 애플리케이션 로직에 집중할 수 있습니다. 예를 들어, Dataflow는 파이프라인의 데이터 볼륨을 기반으로 작업자 수를 자동으로 확장하므로 유휴 리소스에 대한 비용을 지불하지 않습니다.
VM 머신 계열을 워크로드 요구사항에 맞게 조정
Compute Engine VM에 사용할 수 있는 머신 유형은 다양한 워크로드에 최적화된 머신 계열로 그룹화됩니다. 워크로드의 요구사항에 따라 적절한 머신 계열을 선택하세요.
| 머신 계열 | 권장 워크로드 유형 | 지속 가능성 안내 |
|---|---|---|
| 범용 인스턴스 (E2, N2, N4, Tau T2A/T2D): 이러한 인스턴스는 CPU와 메모리의 균형 잡힌 비율을 제공합니다. | 웹 서버, 마이크로서비스, 중소형 데이터베이스, 개발 환경 | E2 시리즈는 리소스의 동적 할당으로 인해 비용 효율성과 에너지 효율성이 높습니다. Tau T2A 시리즈는 대규모 워크로드의 성능 단위당 에너지 효율성이 더 높은 Arm 기반 프로세서를 사용합니다. |
| 컴퓨팅 최적화 인스턴스 (C2, C3): 이러한 인스턴스는 높은 vCPU-메모리 비율과 코어당 높은 성능을 제공합니다. | 고성능 컴퓨팅 (HPC), 일괄 처리, 게임 서버, CPU 기반 데이터 분석 | C 시리즈 인스턴스를 사용하면 CPU 집약적인 작업을 더 빠르게 완료할 수 있으므로 작업의 총 컴퓨팅 시간과 에너지 소비량이 줄어듭니다. |
| 메모리 최적화 인스턴스 (M3, M2): 이러한 인스턴스 는 대용량 메모리가 필요한 워크로드용으로 설계되었습니다. | SAP HANA 또는 인메모리 분석과 같은 대규모 인메모리 데이터베이스 및 데이터 웨어하우스 | 메모리 최적화 인스턴스를 사용하면 메모리 집약적인 워크로드를 더 적은 물리적 노드에 통합할 수 있습니다. 이 통합은 여러 개의 작은 인스턴스를 사용하는 것과 비교했을 때 필요한 총 에너지를 줄여줍니다. 고성능 메모리는 데이터 액세스 지연 시간을 줄여 CPU가 활성 상태로 소비하는 총 시간을 줄일 수 있습니다. |
| 스토리지 최적화 인스턴스 (Z3): 이러한 인스턴스는 높은 처리량과 낮은 지연 시간의 로컬 SSD 스토리지를 제공합니다. | 데이터 웨어하우징, 로그 분석, SQL, NoSQL, 벡터 데이터베이스 | 스토리지 최적화 인스턴스는 대규모 데이터 세트를 로컬에서 처리하므로 교차 위치 네트워크 데이터 이그레스에 사용되는 에너지를 없애는 데 도움이 됩니다. 높은 IOPS 작업에 로컬 스토리지를 사용하면 과도하게 여러 표준 인스턴스를 프로비저닝하지 않아도 됩니다. |
| 가속기 최적화 인스턴스 (A3, A2, G2): 이러한 인스턴스는 AI, ML, HPC와 같은 GPU 및 TPU 가속 워크로드용으로 빌드되었습니다. | ML 모델 학습 및 추론, 과학 시뮬레이션 | TPU는 최적의 에너지 효율성을 위해 설계되었습니다. 와트당 더 높은 컴퓨팅을 제공합니다. NVIDIA H100 GPU가 있는 A3 시리즈와 같은 GPU 가속 인스턴스는 대규모 모델을 학습하는 데 CPU 전용 대안보다 훨씬 더 에너지 효율적일 수 있습니다. GPU 가속 인스턴스 의 공칭 전력 사용량이 더 높지만 작업은 훨씬 더 빠르게 완료됩니다. |
최신 머신 유형으로 업그레이드
최신 머신 유형을 사용하면 지속 가능성을 개선하는 데 도움이 될 수 있습니다. 머신 유형이 업데이트되면 에너지 효율성을 높이고 와트당 더 높은 성능을 제공하도록 설계되는 경우가 많습니다. 최신 머신 유형을 사용하는 VM은 더 낮은 전력 소비로 동일한 양의 작업을 완료할 수 있습니다.
CPU, GPU, TPU는 다음과 같은 칩 아키텍처의 기술적 발전을 통해 이점을 얻는 경우가 많습니다.
- 특수 코어: 프로세서의 발전에는 일반적인 워크로드를 위한 특수 코어 또는 명령어 포함되는 경우가 많습니다. 예를 들어 CPU에는 벡터 연산을 위한 전용 코어 또는 통합 AI 가속기가 있을 수 있습니다. 이러한 작업이 기본 CPU에서 오프로드되면 작업이 더 효율적으로 완료되고 에너지 소비량이 줄어듭니다.
- 향상된 전원 관리: 칩 아키텍처의 발전에는 워크로드에 따라 전압과 주파수를 동적으로 조정하는 것과 같은 더 정교한 전원 관리 기능이 포함되는 경우가 많습니다. 이러한 전원 관리 기능을 사용하면 칩이 최대 효율로 실행되고 유휴 상태일 때 저전력 상태로 전환되어 에너지 소비를 최소화할 수 있습니다.
칩 아키텍처의 기술적 개선사항은 지속 가능성과 비용에 다음과 같은 직접적인 이점을 제공합니다.
- 와트당 더 높은 성능: 이는 지속 가능성을 위한 핵심 측정항목입니다. 예를 들어 C4 VM은 40% 더 높은 가성비를 보여줍니다 동일한 에너지 소비량에 대해 C3 VM과 비교했을 때. C4A 프로세서는 동급 x86 프로세서보다 60% 더 높은 에너지 효율성을 제공합니다. 이러한 성능 기능을 사용하면 작업을 더 빠르게 완료하거나 동일한 부하에 더 적은 인스턴스를 사용할 수 있습니다.
- 총 에너지 소비량 감소: 프로세서가 개선되면 특정 작업에 컴퓨팅 리소스가 더 짧은 시간 동안 사용되므로 전반적인 에너지 사용량과 탄소 발자국이 줄어듭니다. 탄소 영향은 일괄 작업 및 ML 모델 학습과 같은 수명이 짧고 컴퓨팅 집약적인 워크로드에서 특히 높습니다.
- 최적의 리소스 사용률: 최신 머신 유형은 최신 소프트웨어에 더 적합하고 클라우드 플랫폼의 고급 기능과 더 호환되는 경우가 많습니다. 이러한 머신 유형은 일반적으로 더 나은 리소스 사용률을 지원하므로 과도한 프로비저닝의 필요성을 줄이고 모든 와트의 전력이 생산적으로 사용되도록 보장하는 데 도움이 됩니다.
컨테이너형 애플리케이션 배포
지속 가능한 클라우드 컴퓨팅 전략의 일환으로 GKE 및 Cloud Run과 같은 컨테이너 기반의 완전 관리형 서비스를 사용할 수 있습니다. 이러한 서비스는 리소스 사용률을 최적화하고 리소스 관리를 자동화하는 데 도움이 됩니다.
Cloud Run의 Scale-to-zero 기능 활용
Cloud Run은 서비스에 수신 트래픽이 없거나 작업이 완료되면 인스턴스를 자동으로 0으로 확장하는 관리형 서버리스 환경을 제공합니다. 자동 확장은 유휴 인프라의 에너지 소비를 없애는 데 도움이 됩니다. 리소스는 요청을 적극적으로 처리할 때만 전원이 공급됩니다. 이 전략은 간헐적 또는 이벤트 기반 워크로드에 매우 효과적입니다. AI 워크로드의 경우 Cloud Run과 함께 GPU를 사용하여 GPU가 사용될 때만 GPU를 소비하고 비용을 지불할 수 있습니다.
GKE를 사용하여 리소스 최적화 자동화
GKE는 애플리케이션이 필요한 리소스만 사용하도록 보장하는 컨테이너 오케스트레이션 플랫폼입니다. 리소스 최적화를 자동화하는 데 도움이 되도록 GKE는 다음과 같은 기법을 제공합니다.
- 빈 패킹: GKE Autopilot은 사용 가능한 노드에 여러 컨테이너를 지능적으로 패킹합니다. 빈 패킹은 각 노드의 사용률을 극대화하고 유휴 상태이거나 사용률이 낮은 노드의 수를 줄여 에너지 소비를 줄이는 데 도움이 됩니다.
- 수평형 포드 자동 확장 (HPA): HPA를 사용하면 컨테이너 복제본 (포드)의 수가 CPU 사용량 또는 커스텀 애플리케이션별 측정항목과 같은 사전 정의된 측정항목을 기반으로 자동으로 조정됩니다. 예를 들어 애플리케이션의 트래픽이 급증하면 GKE는 수요를 충족하기 위해 포드를 추가합니다. 트래픽이 줄어들면 GKE는 포드 수를 줄입니다. 이 동적 확장은 리소스의 과도한 프로비저닝을 방지하므로 불필요한 컴퓨팅 용량에 대한 비용을 지불하거나 파워업하지 않아도 됩니다.
- 수직형 포드 자동 확장 (VPA): 개별 컨테이너의 CPU 및 메모리 할당과 한도를 자동으로 조정하도록 GKE를 구성할 수 있습니다. 이 구성을 사용하면 컨테이너에 필요한 것보다 더 많은 리소스가 할당되지 않으므로 리소스 과도한 프로비저닝을 방지하는 데 도움이 됩니다.
- GKE 다차원 포드 자동 확장: 복잡한 워크로드의 경우 HPA와 VPA를 동시에 구성하여 포드 수와 각 포드의 크기를 모두 최적화할 수 있습니다. 이 기법은 필요한 성능에 대해 가능한 가장 작은 에너지 발자국을 보장하는 데 도움이 됩니다.
- 토폴로지 인식 예약 (TAS): TAS는 데이터 센터 인프라의 물리적 구조를 기반으로 포드를 배치하여 GKE의 AI 및 ML 워크로드의 네트워크 효율성을 높입니다. TAS는 네트워크 홉을 최소화하기 위해 워크로드를 전략적으로 공동 배치합니다. 이 공동 배치는 통신 지연 시간과 에너지 소비를 줄이는 데 도움이 됩니다. TAS는 노드와 특수 하드웨어의 물리적 정렬을 최적화하여 작업 완료를 가속화하고 대규모 AI 및 ML 워크로드의 에너지 효율성을 극대화합니다.
탄소 인식 예약 구성
Google은 가장 깨끗한 전기를 제공하는 위치 및 시간 으로 워크로드를 지속적으로 이동합니다. 또한 이전 장비를 다른 사용 사례에 맞게 용도를 변경하거나 수집합니다. 이 탄소 인식 예약 전략을 사용하여 컨테이너형 워크로드가 클린 에너지를 사용하도록 할 수 있습니다.
탄소 인식 예약을 구현하려면 리전의 데이터 센터에 전원을 공급하는 에너지 믹스에 대한 정보를 실시간으로 확인해야 합니다. 이 정보는 GitHub의 리전용 무탄소 에너지 Google Cloud 저장소 또는 BigQuery 공개 데이터 세트에서 머신 판독 가능 형식으로 가져올 수 있습니다. Google 연간 탄소 데이터 세트를 계산하는 데 사용되는 시간당 그리드 믹스 및 탄소 집약도 데이터는 Electricity Maps에서 가져옵니다.
탄소 인식 예약을 구현하려면 다음 기법을 사용하는 것이 좋습니다.
- 지리적 이동: 재생 에너지원을 더 많이 사용하는 리전에서 워크로드를 실행하도록 예약합니다. 이 접근 방식을 사용하면 더 깨끗한 전력망을 사용할 수 있습니다.
- 시간 이동: 일괄 처리와 같은 중요하지 않은 유연한 워크로드의 경우 비수기 시간 또는 재생 에너지가 가장 풍부할 때 워크로드가 실행되도록 구성합니다. 이 접근 방식을 시간 이동이라고 하며 클린 에너지원을 사용할 수 있을 때 이를 활용하여 전반적인 탄소 발자국을 줄이는 데 도움이 됩니다.
에너지 효율적인 재해 복구 설계
재해 복구 (DR)를 준비하려면 보조 리전에 중복 리소스를 미리 프로비저닝해야 하는 경우가 많습니다. 하지만 유휴 상태이거나 사용률이 낮은 리소스는 상당한 에너지 낭비를 초래할 수 있습니다. 복구 시간 목표 (RTO)를 손상시키지 않고 리소스 사용률을 극대화하고 탄소 영향을 최소화하는 DR 전략을 선택하세요.
콜드 스타트 효율성 최적화
다음 접근 방식을 사용하여 보조 (DR) 리전에서 활성 리소스를 최소화하거나 없애세요.
- **콜드 DR 우선순위 지정**: DR 리전에서 리소스를 사용 중지하거나 Scale-to-zero 상태로 유지합니다. 이 접근 방식은 유휴 컴퓨팅 리소스의 탄소 발자국을 없애는 데 도움이 됩니다.
- 서버리스 장애 조치 활용: 관리형 서버리스 서비스 Cloud Run과 같은 서비스를 DR 엔드포인트에 사용합니다. Cloud Run은 사용 중이 아닐 때 0으로 확장되므로 트래픽이 DR 리전으로 전환될 때까지 에너지를 소비하지 않는 DR 토폴로지를 유지할 수 있습니다.
- 코드형 인프라 (IaC)로 복구 자동화: DR 사이트에서 리소스를 실행 (웜) 상태로 유지하는 대신 Terraform과 같은 IaC 도구를 사용하여 필요할 때만 환경을 빠르게 프로비저닝합니다.
중복성과 사용률의 균형 조정
리소스 중복성은 에너지 낭비의 주요 원인입니다. 중복성을 줄이려면 다음 접근 방식을 사용하세요.
- 활성-수동보다 활성-활성 선호: 활성-수동 설정에서 수동 사이트의 리소스는 유휴 상태이므로 에너지가 낭비됩니다. 최적으로 크기가 조정된 활성-활성 아키텍처는 두 리전의 프로비저닝된 모든 리소스가 트래픽을 적극적으로 처리하도록 보장합니다. 이 접근 방식을 사용하면 인프라의 에너지 효율성을 극대화할 수 있습니다.
- 적절한 크기의 중복성: 고가용성 또는 DR 요구사항을 충족하는 데 복제가 필요한 경우에만 리전 간에 데이터와 서비스를 복제합니다. 추가 복제본마다 영구 스토리지 및 네트워크 이그레스의 에너지 비용이 증가합니다.