클라우드의 분산된 리소스에서 애플리케이션 스택을 실행할 때는 여러 위치에 걸쳐서 사용 가능한 리소스로 네트워크 트래픽을 효율적으로 리우팅해야 합니다. Google Cloud 인프라 안정성 가이드에 포함된 이 문서에서는 클라우드 워크로드의 안정성 개선을 돕기 위해 사용할 수 있는 트래픽 및 부하 관리 기술에 대해 설명합니다.
용량 계획
Google Cloud에 배포된 애플리케이션에 인프라 리소스가 적절하게 포함되었는지 확인하기 위해서는 필요한 용량을 예측하고 배포된 용량을 관리해야 합니다. 이 섹션에서는 용량 계획 및 관리에 도움이 되는 가이드라인을 제공합니다.
애플리케이션 부하 예측
부하를 예측할 때는 사용자 수 및 애플리케이션이 요청을 수신할 수 있는 비율과 같은 요소를 고려해야 합니다. 예측 시에는 이전 부하 추세, 시즌별 변동 요인, 특별 이벤트 중 부하 급증, 신규 지역 확장과 같은 비즈니스 변화로 인한 성장을 고려해야 합니다.
용량 요구사항 예측
배포 아키텍처를 기반으로 하고 애플리케이션의 성능 및 안정성 목표를 고려해서 예상 부하를 처리하는 데 필요한 Google Cloud 리소스 수량을 예측합니다. 예를 들어 Compute Engine 관리형 인스턴스 그룹(MIG)을 사용하려면 각 MIG 크기, VM 머신 유형, 영구 디스크 수, 유형, 크기를 결정합니다. Google Cloud 가격 계산기를 사용하여 Google Cloud 리소스 비용을 예측할 수 있습니다.
적절한 중복성 계획
용량 요구사항을 예측할 때는 애플리케이션 스택의 모든 구성요소에 대해 적절한 중복성을 제공합니다. 예를 들어 N+1 중복성을 달성하기 위해서는 예측 부하를 처리하는 데 필요한 최솟값을 넘어서 애플리케이션 스택의 모든 구성요소에 적어도 하나 이상의 중복 구성요소가 있어야 합니다.
애플리케이션 벤치마킹
부하 테스트를 실행하여 애플리케이션의 리소스 효율성을 확인합니다. 리소스 효율성은 애플리케이션 부하와 애플리케이션이 소비하는 CPU 및 메모리와 같은 리소스 사이의 관계를 나타냅니다. 부하가 너무 높으면 애플리케이션 리소스 효율성이 저하될 수 있고, 시간에 따라 효율성이 변경될 수 있습니다. 정상 및 최대 부하 조건 모두 부하 테스트를 수행하고 정기적으로 벤치마킹 테스트를 반복하세요.
할당량 관리
Google Cloud 서비스 할당량은 클라우드 리소스의 소비 제어를 도와주는 프로젝트별 제한 값입니다. 할당량은 두 가지 유형입니다. 리소스 할당량은 리전에 있는 리전별 Google Kubernetes Engine(GKE) 클러스터 수와 같이, 만들 수 있는 최대 리소스를 나타냅니다. 비율 할당량은 특정 기간에 서비스에 전송할 수 있는 API 요청 수를 제한합니다. 할당량은 영역, 리전 또는 전역적일 수 있습니다. 프로젝트에서 사용하려는 서비스에 대해 현재 리소스 할당량과 API 비율 할당량을 검토합니다. 필요한 용량에 비해 할당량이 충분한지 확인합니다. 필요한 경우 추가 할당량을 요청할 수 있습니다.
컴퓨팅 용량 예약
필요할 때 Compute Engine 리소스 용량을 사용할 수 있도록 보장하기 위해서는 예약을 만들 수 있습니다. 예약을 사용하면 특정 영역에서 선택한 머신 유형에 지정된 VM 수에 따라 일정 용량을 보장할 수 있습니다. 예약은 프로젝트에 따라 다르게 지정할 수 있고 여러 프로젝트 간에 공유할 수 있습니다. 결제 고려사항을 포함하여 예약에 대한 자세한 내용은 Compute Engine 영역별 리소스 예약을 참조하세요.
사용률 모니터링과 주기적인 요구사항 재평가
필요한 리소스를 배포한 후에는 용량 사용률을 모니터링해야 합니다. 그러면 유휴 리소스 삭제로 비용을 최적화할 기회도 발견할 수 있습니다. 용량 요구사항을 주기적을 재평가하고 애플리케이션 동작, 성능 및 안정성 목표, 사용자 부하 및 IT 예산의 변경사항을 고려해야 합니다.
자동 확장
여러 위치에 분산된 리소스에서 애플리케이션을 실행할 때는 이러한 위치 중 하나에서 중단이 발생해도 애플리케이션이 사용 가능한 상태로 유지됩니다. 또한 중복성은 사용자가 일관적인 애플리케이션 동작을 경험하도록 보장하는 데 도움이 됩니다. 예를 들어 부하 급증이 있을 때 중복된 리소스는 애플리케이션이 예측 가능한 수준으로 계속 작동하도록 보장합니다. 하지만 애플리케이션 부하가 낮을 때는 중복성으로 인해 클라우드 리소스 사용률이 비효율적으로 낮아질 수 있습니다.
예를 들어 어떤 전자상거래 애플리케이션에서는 장바구니 구성요소가 주문 확인 후 200 밀리초 이내에 주문의 99.9%에 대해 결제를 처리해야 할 수 있습니다. 이렇게 부하가 높은 기간 중의 요구사항을 충족하기 위해 중복 컴퓨팅 및 스토리지 용량을 프로비저닝할 수 있습니다. 하지만 애플리케이션 부하가 낮아지면 프로비저닝된 용량 중 일부가 사용되지 않거나 사용률이 낮은 상태로 유지될 수 있습니다. 사용되지 않는 리소스를 삭제하려면 사용률을 모니터링하고 용량을 조정해야 합니다. 자동 확장은 중복 리소스 관리에 따른 운영 부담 없이 클라우드 용량을 관리하고 필요한 가용성 수준을 유지하는 데 도움이 됩니다. 애플리케이션 부하가 늘어나면 자동 확장이 추가 리소스를 자동으로 프로비저닝하여 애플리케이션 가용성을 향상시켜 줍니다. 부하가 낮은 기간 중에는 자동 확장이 사용되지 않은 리소스를 삭제하고 비용을 줄여 줍니다.
Compute Engine과 같은 특정 Google Cloud 서비스를 사용하면 프로비저닝하는 리소스에 대해 자동 확장을 구성할 수 있습니다. Cloud Run과 같은 관리형 서비스는 아무 것도 구성할 필요 없이 용량을 자동으로 확장할 수 있습니다. 다음은 자동 확장을 지원하는 Google Cloud 서비스 예시입니다. 이 목록은 일부일 뿐 모든 내용을 포함하지는 않습니다.
- Compute Engine: MIG를 사용하면 Compute Engine VM에 배포되는 스테이트리스(Stateless) 애플리케이션을 확장하여 현재 부하에 맞게 용량을 자동으로 조정할 수 있습니다. 자세한 내용은 인스턴스 그룹 자동 확장을 참조하세요.
- GKE: 현재 부하에 맞게 노드 풀 크기를 자동 조정하도록 GKE 클러스터를 구성할 수 있습니다. 자세한 내용은 클러스터 자동 확장 처리를 참조하세요. Autopilot 모드로 프로비저닝하는 GKE 클러스터의 경우 GKE가 트래픽을 기반으로 노드 및 워크로드를 자동으로 확장합니다.
- Cloud Run: Cloud Run에서 프로비저닝하는 서비스가 현재 부하를 처리하는 데 필요한 컨테이너 인스턴스 수로 자동으로 확장됩니다. 애플리케이션에 부하가 없으면 서비스가 컨테이너 인스턴스 수 0개로 자동으로 축소됩니다. 자세한 내용은 컨테이너 인스턴스 자동 확장 정보를 참조하세요.
- Cloud Run 함수: 각 함수 요청이 함수 인스턴스에 할당됩니다. 인바운드 요청 볼륨이 기존 함수 인스턴스 수를 초과하면 Cloud Run 함수가 자동으로 새로운 함수 인스턴스를 시작합니다. 자세한 내용은 Cloud Run 함수 실행 환경을 참조하세요.
- Bigtable: Bigtable 인스턴스에서 클러스터를 만들 때 자동으로 확장하도록 클러스터를 구성할 수 있습니다. Bigtable은 CPU 및 스토리지 부하를 모니터링하고 지정한 대상 활용률을 유지하도록 클러스터 노드 수를 조정합니다. 자세한 내용은 Bigtable 자동 확장을 참조하세요.
- 서버리스 Dataproc: Apache Spark 배치 워크로드를 제출할 때 서버리스 Dataproc는 효율적으로 워크로드를 실행하기 위해 실행자 수와 같은 워크로드 리소스를 동적으로 확장합니다. 자세한 내용은 Spark 자동 확장을 위한 서버리스 Dataproc를 참조하세요.
부하 분산
부하 분산은 트래픽을 사용 가능한 리소스로만 라우팅하고 개별 리소스가 오버로드되지 않도록 보장함으로써 애플리케이션 안정성을 향상시켜 줍니다.
클라우드 배포에 대한 부하 분산 장치를 선택하고 구성할 때는 다음과 같이 안정성과 관련된 디자인 권장사항을 고려하세요.
내부 트래픽 부하 분산
외부 클라이언트와 애플리케이션 사이의 트래픽뿐만 아니라 애플리케이션 스택의 계층 간 트래픽에 대해서도 부하 분산을 구성할 수 있습니다. 예를 들어 3계층 웹 애플리케이션 스택에서는 웹 및 앱 계층 간 안정적인 커뮤니케이션을 위해 내부 부하 분산기를 사용할 수 있습니다.
적절한 부하 분산기 유형 선택
여러 리전 간에 분산된 애플리케이션으로 외부 트래픽을 부하 분산하려면 전역 부하 분산 장치 또는 여러 리전별 부하 분산 장치를 사용할 수 있습니다. 자세한 내용은 멀티 리전 배포를 위한 전역 부하 분산의 이점과 위험을 참조하세요.
백엔드가 단일 리전에 있고 전역 부하 분산 기능이 필요하지 않으면 영역 중단을 견딜 수 있는 리전별 부하 분산 장치를 사용할 수 있습니다.
부하 분산 장치 유형을 선택할 때는 가용성 외에도 TLS 종료에 대한 지리적 제어, 성능, 비용, 트래픽 유형과 같은 다른 요소를 고려해야 합니다. 자세한 내용은 부하 분산 장치 선택을 참조하세요.
상태 확인 구성
자동 확장은 애플리케이션이 현재 부하를 처리하는 데 적합한 리소스를 확보하는 데 도움이 됩니다. 그러나 인프라 리소스가 충분하더라도 애플리케이션 또는 일부가 응답하지 않을 수 있습니다. 예를 들어 애플리케이션을 호스팅하는 모든 VM이 RUNNING 상태일 수 있습니다. 그러나 일부 VM에 배포된 애플리케이션 소프트웨어는 충돌이 발생한 상태일 수 있습니다.
부하 분산 상태 점검은 부하 분산 장치가 애플리케이션 트래픽을 응답하는 백엔드로만 라우팅하도록 보장합니다. 백엔드가 MIG인 경우에는 사용할 수 없는 VM을 자동 복구하도록 추가적인 상태 점검 레이어를 구성할 수 있습니다. MIG에 대해 자동 복구를 구성하면 사용할 수 없는 VM이 사전적으로 삭제되고 새 VM이 생성됩니다.
비율 제한
경우에 따라서는 애플리케이션의 부하가 빠르게 또는 지속적으로 증가할 수 있습니다. 애플리케이션이 이렇게 증가하는 부하를 처리하도록 설계되지 않은 경우 애플리케이션 또는 이를 사용하는 리소스가 실패하여, 애플리케이션이 사용 불가능하게 될 수 있습니다. 부하 증가는 네트워크 기반의 분산 서비스 거부(DDoS) 공격과 같은 악의적인 요청에 의해 발생할 수 있습니다. 또한 클라이언트 소프트웨어의 구성 오류와 같은 기타 요인으로 인해 갑작스러운 부하 급증이 발생할 수도 있습니다. 애플리케이션이 과도한 부하를 처리할 수 있도록 하려면 적절한 비율 제한 메커니즘 적용을 고려할 수 있습니다. 예를 들어 Google Cloud 서비스가 수신할 수 있는 API 요청 수에 할당량을 설정할 수 있습니다.
비율 제한 기법은 클라우드 인프라 비용을 최적화하는 데에도 도움을 줄 수 있습니다. 예를 들어 특정 리소스에 대해 프로젝트 수준의 할당량을 설정하여 이러한 리소스에 대해 프로젝트에서 발생할 수 있는 청구를 제한할 수 있습니다.
네트워크 서비스 등급
Google Cloud 네트워크 서비스 등급을 사용하면 인터넷 시스템과 Google Cloud 워크로드 사이의 연결을 최적화할 수 있습니다. 전역적으로 사용자에게 서비스를 제공하고 둘 이상의 리전에 백엔드가 포함된 애플리케이션의 경우 프리미엄 등급을 선택합니다. 인터넷 트래픽은 전송 시스템과 가장 가까운 접속 지점(PoP)에 있는 고성능 Google 네트워크로 들어갑니다. Google 네트워크 내에서 트래픽은 입력 PoP에서 Compute Engine VM과 같은 적합한 Google Cloud 리소스로 라우팅됩니다. 아웃바운드 트래픽은 Google 네트워크를 통해 전송되고 대상에 가장 가까운 PoP에서 종료됩니다. 이러한 라우팅 방법은 사용자와 사용자에게 가장 가까운 PoP 사이의 네트워크 홉 수를 줄임으로써 사용자의 가용성 인식 수준을 개선하는 데 도움이 됩니다.