Spanner용 출시 체크리스트

이 출시 체크리스트는 Spanner에서 프로덕션 애플리케이션을 출시하기 전에 고려해야 하는 사항의 목록을 제공합니다. 이 체크리스트에서는 모든 사항을 다루지는 않지만 위험을 최소화하고 성능을 최적화하며 비즈니스 및 운영 목표와 일치하도록 하는 주요 고려사항을 강조하여 원활하고 신뢰할 수 있는 Spanner 배포를 위한 체계적인 방식을 제공합니다.

이 체크리스트는 다음과 같은 섹션으로 나누어져 있습니다.

설계, 개발, 테스트, 최적화

Spanner의 분산 아키텍처를 사용하여 고성능과 높은 확장성을 얻으려면 스키마 설계, 트랜잭션, 쿼리를 최적화해야 합니다. 엄격한 프로덕션 규모 및 엔드 투 엔드 테스트를 통해 시스템이 실제 워크로드, 최대 부하, 동시 작업을 처리할 수 있도록 하면서 프로덕션에서 병목 현상이나 오류의 위험을 최소화할 수 있습니다.

체크박스 활동
❑  
확장성과 Spanner의 분산 아키텍처를 염두에 두고 스키마를 설계합니다. 핫스팟이 방지되도록 적절한 기본 키 및 색인 선택과 같은 권장사항을 따르고 관련 데이터의 테이블 인터리브 처리와 같은 최적화를 고려하세요. 스키마 설계 권장사항을 검토하여 예상 워크로드에서 스키마가 고성능과 높은 확장성을 모두 지원하는지 확인합니다.
❑  
최소한의 잠금과 최대 성능을 위해 트랜잭션과 쿼리를 최적화합니다. 잠금 읽기-쓰기, 강력한 읽기 전용, Partitioned DML 문과 같은 Spanner의 트랜잭션 모드를 사용하여 일관성, 처리량, 지연 시간 간의 균형을 유지합니다. 쿼리에 읽기 전용 트랜잭션을, 최대 DML 처리량에 일괄 처리를 또는 대규모 업데이트 및 삭제에 Partitioned DML 문을 사용하여 잠금 범위를 최소화합니다. 격리 수준이 다른 시스템(예: PostgreSQL 또는 MySQL)에서 마이그레이션하는 경우에는 트랜잭션을 사용하여 성능 병목 현상을 방지합니다. 자세한 내용은 트랜잭션을 참조하세요.
❑  
엄격한 대규모 부하 테스트를 수행하여 스키마 설계, 트랜잭션 동작, 쿼리 성능을 검증합니다. 다양한 트랜잭션 도형 및 쿼리 패턴을 포함한 실제 애플리케이션 부하를 모방하는 최대 부하 및 동시 실행이 많은 시나리오를 시뮬레이션합니다. 이러한 조건에서 지연 시간과 처리량을 평가하여 데이터베이스 설계와 인스턴스 토폴로지가 성능 요구사항을 충족하는지 확인합니다. 개발 중에 부하 테스트를 반복적으로 사용하여 구현을 최적화하고 미세 조정합니다.
❑  
부하 테스트를 확장하여 격리된 애플리케이션뿐만 아니라 상호작용하는 모든 서비스를 포함합니다. 일괄 로드 또는 데이터베이스에 액세스하는 관리 태스크와 같은 동시 프로세스와 함께 포괄적인 사용자 경험을 시뮬레이션합니다. 프로덕션 Spanner 인스턴스 구성에서 테스트를 실행하여 부하 테스트 드라이버와 서비스가 의도한 프로덕션 배포 토폴로지와 지리적으로 일치하는지 확인합니다. 이러한 전체적인 방식은 사전에 잠재적인 충돌을 식별하고 실제 운영 중에 원활한 데이터베이스 성능을 보장합니다.
❑  
예측 가능한 쿼리 성능을 보장하려면 워크로드가 테스트된 옵티마이저 버전을 사용합니다. 기본적으로 Spanner 데이터베이스는 최신 쿼리 옵티마이저 버전을 사용합니다. 통제된 환경에서 새로운 옵티마이저 버전을 정기적으로 평가하고 호환성 및 성능 개선사항을 확인한 후에만 기본 버전을 업데이트합니다. 자세한 내용은 쿼리 옵티마이저 개요를 참조하세요.
❑  
효율적인 쿼리 실행 계획을 지원하도록 쿼리 옵티마이저 통계가 최신 상태인지 확인합니다. 통계는 자동으로 업데이트되지만 대규모 데이터 수정(예: 일괄 삽입, 업데이트 또는 삭제), 새 색인 추가 또는 스키마 변경과 같은 시나리오에서는 수동으로 새 통계 패키지를 구성하는 것이 좋습니다. 최적의 쿼리 성능을 유지하려면 쿼리 옵티마이저 통계를 최신 상태로 유지해야 합니다.

마이그레이션(선택사항)

데이터베이스 마이그레이션은 각 개별 마이그레이션 여정의 세부정보를 심층적으로 살펴봐야 하는 포괄적인 프로세스입니다. 마이그레이션 전략에서 다음 사항을 고려하세요.

체크박스 활동
❑  
마이그레이션 컷오버를 위한 자세한 표준 운영 절차(SOP)를 개발합니다. 여기에는 애플리케이션 출시, 데이터베이스 전환, 수동 개입을 최소화하기 위한 자동화 단계가 포함됩니다. 사전에 잠재적인 다운타임 기간을 파악하고 이해관계자에게 충분히 알립니다. 강력한 모니터링 및 알림 메커니즘을 구현하여 마이그레이션 프로세스를 실시간으로 추적하고 이상치를 즉시 감지합니다. 마이그레이션 후에 데이터 무결성과 애플리케이션 기능을 확인하는 유효성 검사가 전환 프로세스에 포함되어 있는지 확인합니다.
❑  
마이그레이션 중에 심각한 문제가 발생할 경우 소스 시스템으로 되돌릴 수 있는 세부적인 대체 계획을 준비합니다. 스테이징 환경에서 대체 절차를 테스트하여 신뢰할 수 있고 최소한의 다운타임으로 실행할 수 있는지 확인합니다. 대체를 트리거하는 조건을 명확하게 정의하고 팀에서 이 계획을 신속하고 효율적으로 실행할 수 있도록 교육합니다.

배포

적절한 배포 계획을 통해 Spanner 구성이 가용성, 지연 시간, 확장성에 대한 워크로드 요구사항을 충족하면서 지리적 및 운영 고려사항을 고려할 수 있습니다. 크기 조정, 리소스 관리, 장애 조치 시나리오, 자동화를 조정하면 위험이 최소화되고 최적의 성능이 보장되며 중요한 작업 중에 리소스 제약이나 중단이 방지될 수 있습니다.

체크박스 활동
❑  
Spanner 인스턴스 구성(리전, 이중 리전 또는 멀티 리전)이 애플리케이션의 워크로드 가용성 및 지연 시간 요구사항에 맞는지 확인하고 지리적 고려사항도 고려합니다. 예상 스토리지 크기, 트래픽 패턴, 권장 사용률 한도를 기반으로 대상 컴퓨팅 용량을 계산하여 영역 또는 리전 중단에 대비한 충분한 용량을 확보합니다. 자동 확장을 사용 설정하여 트래픽 급증에 대비합니다. 컴퓨팅 용량 상한을 설정하여 비용 보호 수단을 강구할 수 있습니다. 자세한 내용은 컴퓨팅 용량, 노드, 처리 단위를 참조하세요.
❑  
이중 리전 또는 멀티 리전 인스턴스 구성을 사용하는 경우 지연 시간에 가장 민감한 위치에 배포된 서비스에서 애플리케이션 쓰기 지연 시간을 최소화하는 리더 리전을 선택합니다. 다양한 리더 리전이 작업 지연 시간에 미치는 영향을 테스트하고 애플리케이션 성능이 최적화되도록 조정합니다. 애플리케이션 토폴로지가 리전 중단 중에 리더 리전 변경사항에 적응할 수 있도록 하여 장애 조치 시나리오를 계획합니다. 자세한 내용은 데이터베이스의 리더 리전 수정을 참조하세요.
❑  
운영 명확성과 Google Cloud 리소스 추적을 위해 태그와 라벨을 적절하게 구성합니다. 태그를 사용하여 환경이나 워크로드 유형별로 인스턴스를 그룹화합니다. 비용 분석과 권한 관리에 도움이 되는 메타데이터에 라벨을 사용합니다. 자세한 내용은 태그를 사용하여 액세스 제어 및 인스턴스 구성을 참조하세요.
❑  
특히 출시 시 갑작스럽게 트래픽이 급증할 것으로 예상되는 서비스의 경우 Spanner 워밍업이 필요한지 평가합니다. 초기 부하가 높은 상태에서 지연 시간을 테스트하면 최적의 성능을 보장하기 위해 출시 전 워밍업이 필요할 수 있습니다. 워밍업이 필요한 경우 인위적인 부하를 생성합니다. 자세한 내용은 애플리케이션 출시 전 데이터베이스 워밍업을 참조하세요.
❑  
배포하기 전에 Spanner 한도와 할당량을 검토합니다. 필요한 경우 Google Cloud 콘솔에서 할당량 증가를 요청하여 최대 부하 기간 동안 제약 조건을 방지합니다. 배포 후 문제를 방지하려면 엄격한 한도(예: 데이터베이스당 최대 테이블 수)에 유의하세요. 자세한 내용은 할당량 및 한도를 참조하세요.
❑  
구성이 효율적이고 오류가 없도록 Terraform과 같은 자동화 도구를 사용하여 Spanner 인스턴스를 프로비저닝하고 관리합니다. 스키마 관리의 경우 업데이트 중에 우발적으로 스키마가 삭제되지 않도록 Liquibase와 같은 도구를 사용하는 것이 좋습니다. 자세한 내용은 Spanner에서 Terraform 사용을 참조하세요.

재해 복구

데이터를 보호하고 다운타임을 최소화하며 예기치 않은 장애 발생 시 비즈니스 연속성을 보장하려면 강력한 재해 복구(DR) 전략을 수립해야 합니다. 복원 절차를 정기적으로 테스트하고 백업을 자동화하면 운영 준비 상태, 복구 목표 준수, 조직의 니즈에 맞는 신뢰할 수 있는 데이터 보호를 보장할 수 있습니다.

체크박스 활동
❑  
데이터 보호, 복구 목표, 장애 시나리오를 포함하는 포괄적인 Spanner 재해 복구 전략을 정의합니다. 비즈니스 연속성 요구사항에 부합하는 명확한 복구 시간 목표(RTO) 및 목표 복구 시간(RPO)을 설정합니다. 백업 빈도, 보관 정책을 지정하고 PITR(point-in-time recovery)을 사용하여 장애 발생 시 데이터 손실을 최소화합니다. 재해 복구 개요를 검토하여 애플리케이션의 가용성, 안정성, 보안을 준수하는 데 적합한 도구와 기법을 파악합니다. 자세한 내용은 Spanner의 데이터 보호 및 복구 솔루션 백서를 참조하세요.
❑  
다양한 복구 시나리오에 대한 단계별 가이드 등 백업 및 복원 절차에 대한 자세한 문서를 만듭니다. 이러한 절차를 정기적으로 테스트하여 운영 준비 상태를 확인하고 RTO 및 RPO 요구사항을 검증합니다. 테스트는 실제 오류 조건과 시나리오를 시뮬레이션하여 공백을 파악하고 복구 프로세스를 개선해야 합니다. 자세한 내용은 복원 개요를 참조하세요.
❑  
일관되고 신뢰할 수 있는 데이터 보호를 위해 자동 백업 일정을 구현합니다. 비즈니스 니즈와 규제 의무에 맞게 빈도와 보관 설정을 구성합니다. Spanner의 백업 예약 기능을 사용하여 백업 생성, 관리, 모니터링을 자동화합니다. 자세한 내용은 백업 일정 만들기 및 관리를 참조하세요.
❑  
서비스 중단 시 지연 시간 영향이 최소화되도록 애플리케이션의 인스턴스 구성 토폴로지와 장애 조치 절차를 일치시킵니다. 재해 복구 시나리오를 테스트하여 리더 리전이 장애 조치 리전으로 이동할 때 애플리케이션이 효율적으로 작동할 수 있는지 확인합니다. 자세한 내용은 데이터베이스의 리더 리전 수정을 참조하세요.

쿼리 옵티마이저 및 통계 관리

쿼리 옵티마이저 버전과 통계를 관리하는 것은 예측 가능하고 효율적인 쿼리 성능을 유지하는 데 중요합니다. 테스트된 버전을 사용하고 통계를 최신 상태로 유지하면 특히 중요한 데이터나 스키마를 수정하는 동안에 안정성을 보장하고 예상치 못한 성능 변화를 방지하며 쿼리 실행 계획을 최적화할 수 있습니다.

체크박스 활동
❑  
기본적으로 Spanner 데이터베이스는 최신 쿼리 옵티마이저 버전을 사용합니다. 예측 가능한 쿼리 성능을 보장하려면 워크로드가 테스트된 옵티마이저 버전을 사용합니다. 통제된 환경에서 새로운 옵티마이저 버전을 정기적으로 평가하고 호환성 및 성능 개선사항을 확인한 후에만 기본 버전을 업데이트합니다. 자세한 내용은 쿼리 옵티마이저 개요를 참조하세요.
❑  
효율적인 쿼리 실행 계획을 지원하도록 쿼리 옵티마이저 통계가 최신 상태인지 확인합니다. 통계는 자동으로 업데이트되지만 대규모 데이터 수정(예: 일괄 삽입, 업데이트 또는 삭제), 새 색인 추가 또는 스키마 변경과 같은 시나리오에서는 수동으로 새 통계 패키지를 구성하는 것이 좋습니다. 최적의 쿼리 성능을 유지하려면 쿼리 옵티마이저 통계를 최신 상태로 유지해야 합니다.
❑  
일괄 삭제 후 또는 새 통계 생성이 쿼리 성능에 예기치 않은 영향을 줄 수 있는 경우와 같은 특정 시나리오에서는 특정 통계 패키지를 고정하는 것이 좋습니다. 이렇게 하면 새 패키지를 생성하고 테스트할 때까지 일관된 쿼리 성능이 제공됩니다. 통계를 고정해야 하는 니즈를 정기적으로 검토하고 업데이트된 패키지가 검증되면 고정을 해제합니다. 자세한 내용은 쿼리 옵티마이저 통계 패키지를 참조하세요.

보안

민감한 정보를 보호하고 Spanner에서 무단 액세스를 방지하려면 액세스 제어 조치를 구현해야 합니다. 최소 권한 액세스, 세분화된 액세스 제어(FGAC), 데이터베이스 삭제 보호를 적용하면 위험을 최소화하고 규정을 준수하며 실수나 악의적인 행위로부터 중요한 애셋을 보호할 수 있습니다.

체크박스 활동
❑  
데이터베이스에 액세스하는 모든 사용자와 서비스 계정에 대한 최소 권한 원칙에 따라 Identity and Access Management(IAM) 정책을 검토하고 구현합니다. 특정 태스크를 수행하는 데 필요한 권한만 할당하고 액세스 제어 권한을 정기적으로 감사하여 이 모델을 준수하도록 합니다. 자동화된 프로세스에 최소 권한이 있는 서비스 계정을 사용하여 무단 액세스 위험을 줄입니다. 자세한 내용은 IAM 개요를 참조하세요.
❑  
애플리케이션에 테이블 내 특정 행, 열 또는 셀에 대한 제한된 액세스가 필요한 경우 세분화된 액세스 제어(FGAC)를 구현합니다. 사용자 속성 또는 데이터 값을 기반으로 조건부 액세스 정책을 설계하고 적용하여 세분화된 액세스 규칙을 적용합니다. 변화하는 보안 및 규정 준수 요구사항에 맞게 이러한 정책을 정기적으로 검토하고 업데이트합니다. 자세한 내용은 세분화된 액세스 제어 개요를 참조하세요.
❑  
일관되고 신뢰할 수 있는 데이터 보호를 위해 자동 백업 일정을 구현합니다. 비즈니스 니즈와 규제 의무에 맞게 빈도와 보관 설정을 구성합니다. Spanner의 백업 예약 기능을 사용하여 백업 생성, 관리, 모니터링을 자동화합니다. 자세한 내용은 백업 일정 만들기 및 관리를 참조하세요.
❑  
데이터베이스 삭제 보호를 사용 설정하여 실수로 인한 또는 승인되지 않은 삭제를 방지합니다. 이를 엄격한 IAM 제어와 결합하여 삭제 권한을 신뢰할 수 있는 소수의 사용자 집합이나 서비스 계정으로 제한합니다. 또한 Terraform과 같은 인프라 자동화 도구를 구성하여 데이터베이스가 의도치 않게 삭제되는 것을 방지합니다. 이러한 계층적 방식은 중요한 데이터 애셋에 대한 위험을 최소화합니다. 자세한 내용은 실수로 인한 데이터베이스 삭제 방지를 참조하세요.

로깅 및 모니터링

효과적인 로깅 및 모니터링은 데이터베이스 작업에 대한 가시성을 유지하고 이상치를 감지하며 시스템 상태를 보장하는 데 중요합니다. 감사 로그, 분산 추적, 대시보드, 사전 알림을 사용하면 문제를 신속하게 파악 및 해결하고 성능을 최적화하며 규정 준수 요구사항을 충족할 수 있습니다.

체크박스 활동
❑  
감사 로깅을 사용 설정하여 데이터베이스 활동에 대한 자세한 정보를 캡처합니다. 규정 준수 및 운영 요구사항에 따라 감사 로그 수준을 적절하게 구성하여 액세스 패턴을 모니터링하고 이상치를 효과적으로 감지합니다. 특히 DATA_READ 및 DATA_WRITE 요청의 경우 모든 SQL 및 DML 문이 로깅되므로 감사 로그가 커질 수 있습니다. 자세한 내용은 Spanner 감사 로깅을 참조하세요.

사용자 정의 로그 버킷으로 이러한 로그를 라우팅하면 로그 보관 비용을 최적화하고(첫 30일의 요금은 청구되지 않음) 로그 뷰를 사용하여 로그 액세스를 세부적으로 제어할 수 있습니다.
❑  
OpenTelemetry로 애플리케이션 로직을 계측하여 클라이언트 측 측정항목을 수집해 추적 및 모니터링 가능성을 배포합니다. OpenTelemetry 계측을 설정하여 Spanner에서 trace와 측정항목을 캡처하여 애플리케이션 성능과 데이터베이스 상호작용에 대한 엔드 투 엔드 가시성을 보장합니다. 자세한 내용은 OpenTelemetry를 사용하여 커스텀 클라이언트 측정항목 캡처를 참조하세요.
❑  
모니터링 측정항목을 만들고 구성하여 쿼리 성능, 지연 시간, CPU 사용률, 스토리지 사용량을 시각화합니다. 이러한 측정항목은 데이터베이스 성능의 실시간 추적과 이전 분석에 사용합니다. 자세한 내용은 Cloud Monitoring으로 인스턴스 모니터링을 참조하세요.
❑  
문제를 사전에 감지하고 해결하기 위해 중요한 측정항목에 대한 기준점 기반 모니터링 알림을 정의합니다. 긴 쿼리 지연 시간, 낮은 스토리지 가용성 또는 예상치 못한 트래픽 급증과 같은 조건에 대한 알림을 구성합니다. 신속하게 조치를 취할 수 있도록 이러한 알림을 사고 대응 도구와 통합합니다. 자세한 내용은 Spanner 측정항목에 대한 알림 만들기를 참조하세요.

클라이언트 라이브러리

Spanner에서 성능을 최적화하고 문제를 디버그하며 복원력을 유지하려면 작업 태그 지정, 세션 풀, 재시도 정책을 구성해야 합니다. 이러한 조치는 모니터링 가능성을 개선하고 지연 시간을 줄이며 워크로드 수요와 일시적인 오류를 효율적으로 처리하여 시스템 동작을 애플리케이션 요구사항에 맞춥니다.

체크박스 활동
❑  
클라이언트 라이브러리에서 의미 있는 쿼리 요청 및 트랜잭션 태그를 사용하도록 구성합니다. 요청 및 트랜잭션 태그를 사용하여 쿼리, 읽기, 트랜잭션을 파악할 수 있습니다. 태그에서 애플리케이션 구성요소, 요청 유형 또는 사용자 컨텍스트와 같은 문맥 메타데이터를 사용하여 고급 디버깅 및 내부 검사를 사용 설정하는 것이 좋습니다. 보다 쉽게 성능을 분석하고 문제를 해결할 수 있도록 쿼리 통계와 로그에 태그가 표시되는지 확인합니다. 자세한 내용은 요청 태그 및 트랜잭션 태그를 사용한 문제 해결을 참조하세요.
❑  
클라이언트 라이브러리에서 세션 풀링을 사용 설정하여 세션 관리를 최적화합니다. 지연 시간을 최소화하면서 워크로드 수요에 맞게 최소 및 최대 세션과 같은 풀 설정을 구성합니다. 세션 사용량을 정기적으로 모니터링하여 이러한 파라미터를 미세 조정하고 세션 풀에서 일관된 성능 이점을 제공하도록 합니다. 자세한 내용은 세션을 참조하세요.
❑  
드물지만 복원력과 성능 간의 균형이 유지되도록 최대 시도 횟수 및 지수 백오프 간격을 포함한 재시도에 대한 기본 클라이언트 라이브러리 파라미터를 구성해야 합니다. 이러한 정책이 애플리케이션 니즈에 부합하는지 철저히 테스트합니다. 자세한 내용은 커스텀 제한 시간 및 재시도 구성을 참조하세요.

지원

다운타임과 영향을 최소화하려면 명확한 사고 역할과 책임을 정의하여 Spanner 관련 문제에 신속하고 조율된 방식으로 대응합니다. 자세한 내용은 지원 받기를 참조하세요.

체크박스 활동
❑  
Spanner 관련 사고 관리와 관련된 모든 팀원의 역할과 책임을 정의하는 사고 대응 프레임워크를 명확하게 수립합니다. 사고 발생 시 효율적인 조정과 커뮤니케이션을 위해 사고 지휘관, 커뮤니케이션 책임자, 주제 전문가(SME)와 같은 사고 역할을 지정합니다. 문제 식별, 에스컬레이션, 완화, 해결을 위한 프로세스를 개발하고 문서화합니다. 사고 대응에 대한 Google SRE 워크북 및 사고 관리에 설명된 권장사항을 따릅니다. 정기적인 사고 대응 교육 및 시뮬레이션을 실시하여 준비 상태를 유지하고 압박이 높은 시나리오를 효과적으로 관리하는 팀 능력을 향상시킵니다.

비용 관리

자동 확장, 증분 백업과 같은 비용 관리 전략을 구현하면 효율적으로 리소스를 활용하고 비용을 크게 줄일 수 있습니다. 리소스 프로비저닝을 워크로드 수요에 맞추고 프로덕션 외 환경을 최적화하면 성능과 유연성을 유지하면서 비용을 더욱 줄일 수 있습니다.

체크박스 활동
❑  
예측 가능한 워크로드의 비용을 줄이기 위해 Spanner용 CUD를 평가하고 구매합니다. 이러한 약정을 사용하면 주문형 가격에 비해 비용을 크게 줄일 수 있습니다. 이전 사용 패턴을 분석하여 최적의 CUD 약정을 결정합니다. 자세한 내용은 약정 사용 할인 및 Spanner 가격 책정을 참조하세요.
❑  
컴퓨팅 용량 사용률을 모니터링하고 프로비저닝된 리소스를 조정하여 권장 CPU 사용률 수준을 유지합니다. 컴퓨팅 리소스를 과도하게 프로비저닝하면 불필요한 비용이 발생할 수 있고 프로비저닝이 부족하면 성능이 영향을 받을 수 있습니다. 권장되는 최대 Spanner CPU 사용률 가이드라인에 따라 리소스를 경제적으로 조정합니다.
❑  
자동 확장을 사용 설정하여 워크로드 수요에 따라 컴퓨팅 용량을 동적으로 조정합니다. 이렇게 하면 최대 부하가 발생하는 기간에는 최적의 성능을 보장하고 활동이 적은 기간에는 비용을 줄일 수 있습니다. 상한과 하한이 있는 확장 정책을 구성하여 비용을 관리하고 과도한 확장을 방지합니다. 자세한 내용은 자동 확장 개요를 참조하세요.
❑  
증분 백업을 사용하여 백업 스토리지 비용을 줄입니다. 증분 백업은 마지막 백업 이후의 데이터 변경사항만 저장합니다. 이렇게 하면 전체 백업과 비교하여 스토리지 요구사항이 크게 줄어듭니다. 증분 백업을 백업 전략에 통합합니다. 자세한 내용은 증분 백업을 참조하세요.
❑  
가장 최적의 인스턴스 구성을 선택하고 환경을 사용하지 않을 때 리소스 프로비저닝을 해제하여 프로덕션이 아닌 환경의 비용을 최적화합니다. 예를 들어 영업시간 이후에 중요하지 않은 환경의 크기를 줄이거나 개발 및 테스트 시나리오의 리소스 확장을 자동화합니다. 이 방식은 운영 유연성을 유지하면서 비용을 최소화합니다.