Google Cloud Well-Architected Framework의 성능 최적화 요소에 있는 이 원칙은 워크로드 요구사항의 변화에 따라 리소스를 동적으로 조정하는 기능인 탄력성을 통합하는 데 도움이 되는 권장사항을 제공합니다.
탄력성을 통해 시스템의 여러 구성요소를 독립적으로 확장할 수 있습니다 이러한 목표 확장을 통해 리소스를 과도하게 프로비저닝하거나 과소 프로비저닝하지 않고도 필요한 곳에 정확히 리소스를 할당하여 성능과 비용 효율성을 개선할 수 있습니다.
원칙 개요
시스템의 성능 요구사항은 시스템이 수직 확장 또는 수평 확장되는 시기와 방법에 직접적인 영향을 줍니다. 시스템의 용량을 평가하고 기준에서 시스템이 처리할 것으로 예상되는 부하를 결정해야 합니다. 그런 다음 시스템이 부하의 증가 및 감소에 어떻게 반응하도록 할지 결정해야 합니다.
부하가 증가하면 시스템은 수평으로 확장하거나 수직으로 확장하거나 또는 둘 다 확장해야 합니다. 수평 확장의 경우 복제본 노드를 추가하여 시스템의 전체 용량이 증가한 수요를 충족하기에 충분한지 확인해야 합니다. 수직 확장의 경우 애플리케이션의 기존 구성요소를 더 많은 용량, 더 많은 메모리, 더 많은 저장용량이 포함된 구성요소로 교체합니다.
부하가 감소하면 시스템이 축소 (수평, 수직 또는 둘 다)되어야 합니다.
시스템이 확장되거나 축소되는 상황을 정의합니다. 트래픽이 많은 것으로 알려진 기간에는 시스템을 수동으로 수직 확장할 계획을 세우세요. 부하 증가 또는 감소에 대응하는 자동 확장과 같은 도구를 사용합니다.
권장사항
탄력성을 활용하려면 다음 섹션의 권장사항을 고려하세요.
최대 부하 기간에 대비한 계획
고객 수요가 증가할 것으로 예상되는 기간과 같이 알려진 이벤트에 대한 효율적인 확장 경로를 계획해야 합니다.
트래픽이 많다고 알려진 기간에 앞서 시스템을 확장하는 것이 좋습니다. 예를 들어 소매 조직의 경우 시즌별 판매 기간 동안 수요가 증가할 것으로 예상됩니다. 시스템이 증가된 부하를 즉시 처리하거나 기존 한도를 즉시 조정할 수 있도록 판매 전에 시스템을 수동으로 확장 또는 수평 확장하는 것이 좋습니다. 그러지 않으면 시스템에서 실시간 변경에 대한 응답으로 리소스를 추가하는 데 몇 분 정도 걸릴 수 있습니다. 애플리케이션 용량이 빠르게 증가하지 않아 일부 사용자에게 지연이 발생할 수 있습니다.
수요 또는 트래픽 급증과 같은 알 수 없거나 예기치 않은 이벤트의 경우 자동 확장 기능을 사용하여 측정항목을 기반으로 한 탄력적 확장을 트리거할 수 있습니다. 이러한 측정항목에는 CPU 사용률, 부하 분산기 제공 용량, 지연 시간은 물론 Cloud Monitoring에서 정의하는 커스텀 측정항목도 포함될 수 있습니다.
예를 들어 Compute Engine 관리형 인스턴스 그룹 (MIG)에서 실행되는 애플리케이션을 생각해 보세요. 이 애플리케이션의 경우 평균 CPU 사용률이 75%에 도달할 때까지 각 인스턴스가 최적의 성능을 발휘해야 합니다. 이 예시에서는 CPU 사용률이 기준에 도달하면 더 많은 인스턴스를 만드는 자동 확장 정책을 정의할 수 있습니다. 이렇게 새로 생성된 인스턴스는 부하를 흡수하는 데 도움이 되므로 MIG에 구성한 최대 인스턴스 수에 도달할 때까지 평균 CPU 사용률이 최적의 비율로 유지됩니다. 수요가 감소하면 자동 확장 정책이 더 이상 필요하지 않은 인스턴스를 삭제합니다.
BigQuery에서 리소스 슬롯 예약을 계획하거나 관리형 자동 확장 처리를 사용하여 Spanner에서 자동 확장 구성 한도를 조정합니다.
예측 확장 사용
시스템 구성요소에 Compute Engine이 포함된 경우 예측 자동 확장이 워크로드에 적합한지 평가해야 합니다. 예측 자동 확장은 CPU 사용률과 같은 측정항목의 이전 추세를 기반으로 향후 부하를 예측합니다. 예측은 몇 분마다 다시 계산되므로 자동 확장 처리는 최근 부하 변화에 맞춰 예측을 빠르게 조정합니다. 예측 자동 확장을 사용하지 않으면 자동 확장 처리는 관찰된 부하의 실시간 변화에 따라 사후 대응적으로만 그룹을 확장할 수 있습니다. 예측 자동 확장은 실시간 데이터 및 이전 데이터 모두와 함께 작동하여 현재 부하와 예측 부하에 모두 대응합니다.
서버리스 아키텍처 구현
다음과 같이 본질적으로 탄력적인 서버리스 서비스로 서버리스 아키텍처를 구현하는 것이 좋습니다.
규칙 미세 조정이 필요한 다른 서비스 (예: Compute Engine)의 자동 확장과 달리 서버리스 자동 확장은 즉시 실행되며 리소스 0개로 축소할 수 있습니다.
Kubernetes용 Autopilot 모드 사용
Kubernetes를 더 세부적으로 제어해야 하는 복잡한 애플리케이션의 경우 Google Kubernetes Engine (GKE)의 Autopilot 모드를 고려하세요. Autopilot 모드는 기본적으로 자동화와 확장성을 제공합니다. GKE는 트래픽에 따라 노드와 리소스를 자동으로 확장합니다. GKE는 노드를 관리하고, 애플리케이션의 새 노드를 만들고, 자동 업그레이드 및 복구를 구성합니다.