대부분의 부하 분산기는 순차 순환 또는 흐름 기반 해시 방식을 사용하여 트래픽을 분산시킵니다. 하지만 이 방식을 사용하는 부하 분산기는 수요가 사용 가능한 제공 용량을 초과하는 경우 적용이 어려울 수 있습니다. 이 기사에서는 Cloud Load Balancing을 사용하여 이러한 문제를 해결하고 글로벌 애플리케이션 용량을 최적화하는 방법에 대해 설명합니다. 이렇게 하면 기존의 부하 분산 구현보다 사용자 환경이 향상되고 비용이 절감되는 경우가 많습니다.
이 문서는 Cloud Load Balancing 제품과 관련된 권장사항 시리즈의 일부입니다. 이 문서에 동봉된 가이드는 부하 분산으로 용량 관리를 참조하세요. 지연 시간에 대한 심층 정보는 부하 분산으로 애플리케이션 지연 최적화를 참조하세요.
글로벌 애플리케이션의 용량 문제
IT 예산이 한정적이고, 워크로드가 예측 불가능하며 이따금씩 몰리는 경우에는 특히 글로벌 애플리케이션을 확장하기가 어려울 수 있습니다. Google Cloud와 같은 퍼블릭 클라우드 환경에서는 자동 확장 및 부하 분산과 같은 유연한 기능이 도움이 될 수 있습니다. 그러나 이 섹션에서 설명한 것처럼 자동 확장 처리에는 몇 가지 제한 사항이 적용됩니다.
새 인스턴스 시작 지연
자동 확장과 관련된 가장 일반적인 문제는 요청을 받은 애플리케이션이 트래픽을 신속하게 처리할 준비가 되지 않았다는 것입니다. VM 인스턴스 이미지에 따라 일반적으로 VM 인스턴스가 준비되기 전에 스크립트를 실행하고 정보를 로드해야 합니다. 부하 분산으로 사용자를 새 VM 인스턴스로 안내하는 데는 몇 분 정도 걸리는 경우가 많습니다. 이 기간 동안 트래픽은 이미 용량을 초과했을 수 있는 기존의 VM 인스턴스로 분산됩니다.
백엔드 용량이 제한되는 애플리케이션
일부 애플리케이션은 자동 확장이 전혀 지원되지 않습니다. 예를 들어 데이터베이스의 백엔드 용량이 제한되는 경우가 있습니다. 수평적으로 확장되지 않는 데이터베이스에는 특정 수의 프런트엔드만 액세스할 수 있습니다. 애플리케이션이 초당 지원되는 요청 수가 제한된 외부 API를 사용하는 경우 애플리케이션도 자동으로 확장할 수 없습니다.
비탄성 라이선스
라이선스가 부여된 소프트웨어를 사용하는 경우 라이선스에서 사전 설정된 최대 용량으로 제한하는 경우가 많습니다. 따라서 라이선스를 즉시 추가할 수 없기 때문에 자동 확장 기능이 제한될 수 있습니다.
VM 인스턴스 여유 공간 부족
트래픽 급증을 고려하여 자동 확장 처리 기능에 충분한 여유 공간을 확보해야 합니다(예: 자동 확장 처리가 CPU 용량 70%에서 트리거됨). 비용을 절약하려면 CPU 용량의 90%와 같이 목표를 더 높게 설정할 수 있습니다. 그러나 트리거 값을 높이면 광고 캠페인의 수요가 급증하는 경우처럼 트래픽이 급증하는 경우 확장 병목 현상이 발생할 수 있습니다. 트래픽의 급증 빈도와 새로운 VM 인스턴스를 준비하는 데 걸리는 시간에 따라 여유 공간의 크기를 균형 있게 조절해야 합니다.
지역별 할당량
한 지역에서 예기치 않은 급증이 발생하면 기존 리소스 할당량으로 인해 확장 가능한 인스턴스 수가 현재 급증을 처리하는 데 필요한 수준 미만으로 제한될 수 있습니다. 리소스 할당량 증가를 처리하는 데는 몇 시간이나 며칠이 걸릴 수 있습니다.
글로벌 부하 분산으로 이러한 문제 해결
외부 애플리케이션 부하 분산기 및 외부 프록시 네트워크 부하 분산기는 전역적으로 동기화된 Google 프런트엔드(GFE) 서버를 통해 프록시 처리되는 전역 부하 분산 제품으로서 이러한 유형의 부하 분산 문제를 더 쉽게 완화할 수 있습니다. 이러한 제품은 대부분의 리전별 부하 분산 솔루션과 달리 백엔드에 트래픽이 분산되기 때문에 이러한 과제를 해결할 수 있는 솔루션을 제공합니다.
이러한 차이점은 다음 섹션에서 설명합니다.
다른 부하 분산기에서 사용하는 알고리즘
대부분의 부하 분산기는 동일한 알고리즘을 사용하여 백엔드 간에 트래픽을 분산합니다.
- 순차 순환 대기. 패킷은 패킷의 소스 및 대상에 관계없이 모든 백엔드 간에 똑같이 분산됩니다.
- 해싱. 패킷 흐름은 소스 IP, 대상 IP, 포트 및 프로토콜을 비롯한 트래픽 정보의 해시를 기반으로 식별됩니다. 동일한 해시 값을 생성하는 모든 트래픽은 동일한 백엔드로 전달됩니다.
해싱 부하 분산은 현재 외부 패스 스루 네트워크 부하 분산기에 사용할 수 있는 알고리즘입니다. 이 부하 분산기는 2튜플 해싱(소스 및 대상 IP 기반), 3튜플 해싱(소스 IP, 대상 IP 및 프로토콜 기반), 5튜플 해싱(소스 IP, 대상 IP, 소스 포트, 대상 포트, 프로토콜)을 지원합니다.
이 두 가지 알고리즘을 사용하면 비정상적인 인스턴스가 배포 대상에서 제외됩니다. 그러나 백엔드의 현재 부하는 부하 분산 시 거의 고려 대상이 아닙니다.
일부 하드웨어 또는 소프트웨어 부하 분산기는 가중 순차 순환 대기, 최소 부하, 가장 빠른 응답 시간 또는 활성 연결 수와 같은 다른 측정항목을 기반으로 트래픽을 전달하는 알고리즘을 사용합니다. 그러나 트래픽 급증으로 인해 부하가 예상 수준을 초과해도 트래픽은 여전히 용량을 초과하는 백엔드 인스턴스로 분산되어 지연 시간이 크게 늘어납니다.
일부 부하 분산기는 백엔드 용량을 초과하는 트래픽이 다른 풀로 전달되거나 정적 웹 사이트로 리디렉션되는 고급 규칙을 허용합니다. 이렇게 하면 이 트래픽을 효과적으로 거부하고 '서비스를 사용할 수 없음. 나중에 다시 시도하세요'라는 메시지를 보낼 수 있습니다. 일부 부하 분산기는 요청을 대기열에 넣을 수 있는 옵션을 제공합니다.
글로벌 부하 분산 솔루션은 DNS 기반 알고리즘으로 구현되는 경우가 많으며, 사용자 위치 및 백엔드 부하를 기반으로 다양한 리전별 부하 분산 IP를 제공합니다. 이러한 솔루션은 리전별 배포를 위해 전체 또는 일부 트래픽을 다른 리전으로 장애 조치할 수 있게 해줍니다. 그러나 모든 DNS 기반 솔루션에서 장애 조치는 DNS 항목의 TTL(수명) 값에 따라 보통 몇 분이 걸립니다. 일반적으로 소량의 트래픽은 이 시간을 훨씬 지나 TTL이 당연히 만료되었을 시기에도 이전 서버로 계속 전달됩니다. 따라서 DNS 기반 글로벌 부하 분산은 트래픽 급증 시나리오에서 트래픽을 처리하기 위한 최적의 솔루션이 아닙니다.
외부 애플리케이션 부하 분산기 작동 방식
외부 애플리케이션 부하 분산기는 다른 접근 방식을 사용합니다. Google 글로벌 네트워크 에지 위치 대부분에 분산된 GFE 서버를 통해 트래픽이 프록시 처리됩니다. 이는 현재 전 세계 80개 이상의 위치에 있습니다. 부하 분산 알고리즘은 GFE 서버에 적용됩니다.
외부 애플리케이션 부하 분산기는 에지 노드에서 전역으로 공지되는 안정적인 단일 IP 주소를 통해 사용할 수 있으며 연결은 GFE에서 종료됩니다.
GFE는 Google의 글로벌 네트워크를 통해 상호 연결됩니다. 부하가 분산된 각 리소스의 사용 가능한 백엔드와 사용 가능한 제공 용량을 설명하는 데이터는 전역 제어 플레인을 사용하여 모든 GFE에 지속적으로 분산됩니다.
부하가 분산된 IP 주소에 대한 트래픽은 Waterfall by Region이라는 특수 부하 분산 알고리즘을 사용하여 외부 애플리케이션 부하 분산기 구성에 정의된 백엔드 인스턴스로 프록시 처리됩니다. 이 알고리즘은 인스턴스와 사용자의 근접성, 들어오는 부하, 각 영역 및 리전에서 백엔드의 사용 가능한 용량을 고려하여 요청을 처리하기 위한 최적의 백엔드를 결정합니다. 마지막으로, 전 세계 부하 및 용량도 고려됩니다.
외부 애플리케이션 부하 분산기는 사용 가능한 인스턴스를 기반으로 트래픽을 분산시킵니다. 이 알고리즘은 부하를 기준으로 새 인스턴스를 추가하기 위해 인스턴스 그룹 자동 확장과 함께 작동합니다.
리전 내 트래픽 흐름
정상적인 상황에서는 모든 트래픽이 사용자에게 가장 가까운 리전으로 전송됩니다. 부하 분산은 다음 지침에 따라 수행됩니다.
각 리전 내에서 트래픽은 인스턴스 그룹 간에 분산되며, 이는 각 그룹의 용량에 따라 여러 영역에 있을 수 있습니다.
영역 간에 용량이 동일하지 않으면 사용 가능한 제공 용량에 비례하여 영역에 부하가 책정됩니다.
영역 내에서 요청은 각 인스턴스 그룹의 인스턴스 간에 균등하게 분산됩니다.
세션은 세션 어피니티 설정에 따라 클라이언트 IP 주소 또는 쿠키 값을 기준으로 유지됩니다.
백엔드를 사용할 수 없게 된 경우를 제외하고, 기존 TCP 연결은 다른 백엔드로 이동하지 않습니다.
다음 다이어그램에서는 이 경우의 부하 분산을 보여줍니다. 이 경우에는 각 영역의 용량이 적어 해당 리전에서 가장 가까운 사용자의 부하를 처리할 수 있습니다.
다른 리전으로의 트래픽 오버플로
전체 지역이 백엔드 서비스에 설정된 제공 용량을 기준으로 결정된 용량에 도달하면 Waterfall by Region 알고리즘이 트리거되고, 트래픽이 가용 용량이 있는 가장 가까운 지역으로 오버플로됩니다. 각 리전이 용량에 도달하면 트래픽이 다음 가장 가까운 리전으로 전달됩니다. 리전과 사용자의 근접성은 GFE에서 인스턴스 백엔드까지의 네트워크 왕복 시간으로 정의됩니다.
다음 다이어그램은 한 리전이 처리 가능한 양보다 많은 트래픽을 수신할 때 다음으로 가장 가까운 리전에 트래픽이 오버플로되는 것을 보여줍니다.
비정상 백엔드로 인한 리전 간 오버플로
상태 확인 결과 특정 리전의 백엔드 중 절반 이상이 비정상 상태로 밝혀질 경우 GFE는 우선 다음으로 가장 가까운 리전에 일부 트래픽을 오버플로합니다. 해당 리전이 비정상화됨에 따라 트래픽이 완전히 실패하지 않도록 하기 위한 조치입니다. 비정상 백엔드가 있는 리전에 남아 있는 용량이 충분하더라도 이러한 오버플로가 발생합니다.
다음 다이어그램은 하나의 영역에 있는 대부분의 백엔드가 비정상이기 때문에 적용되는 오버플로 메커니즘을 보여줍니다.
모든 리전이 용량을 초과하는 경우
모든 리전에 대한 트래픽이 용량에 도달하거나 용량을 초과할 경우 각 리전의 용량 대비 오버플로의 상대적 수준이 동일하게 유지되도록 트래픽이 분산됩니다. 예를 들어 글로벌 수요가 글로벌 용량을 20% 초과하는 경우 모든 리전에서 트래픽을 가능한 로컬로 유지하면서 리전 용량보다 20% 초과하는 요청을 수신하는 방식으로 트래픽이 분산됩니다.
다음 다이어그램은 이 글로벌 오버플로 규칙이 적용된 상태를 보여줍니다. 이 경우 단일 리전이 많은 트래픽을 수신하므로 전 세계에서 사용 가능한 제공 용량으로 전혀 분산될 수 없습니다.
자동 확장 중 일시적인 오버플로
자동 확장은 각 백엔드 서비스에 구성된 용량 제한을 기반으로 하며 트래픽이 구성된 용량 제한에 가까워지면 새로운 인스턴스를 가져옵니다. 요청이 늘어나는 속도와 새로운 인스턴스가 온라인 상태가 되는 속도에 따라 다른 리전으로의 오버플로가 불필요할 수 있습니다. 다른 경우에는 새로운 로컬 인스턴스가 온라인 상태가 되어 실시간 트래픽을 처리할 준비가 될 때까지 오버플로가 임시 버퍼로 작동할 수 있습니다. 자동 확장으로 확장된 용량이 충분하면 모든 새 세션이 가장 가까운 리전으로 분산됩니다.
오버플로의 지연 효과
Waterfall by Region 알고리즘에 따르면 외부 애플리케이션 부하 분산기가 일부 트래픽을 다른 리전으로 오버플로할 수 있습니다. 그러나 TCP 세션과 SSL 트래픽은 여전히 사용자에게 가장 가까운 GFE에서 종료합니다. 이는 애플리케이션 지연 시간을 줄이는 데 도움이 됩니다. 자세한 내용은 부하 분산을 통한 애플리케이션 지연 시간 최적화를 참조하세요.
실습: 용량 관리의 효과 측정
오버플로가 어떻게 발생하고, HTTP 부하 분산기를 사용하여 이를 어떻게 관리할 수 있는지 알아보려면 이 문서와 함께 제공되는 부하 분산을 통한 용량 관리 가이드를 참조하세요.
외부 애플리케이션 부하 분산기를 사용하여 용량 문제 해결
앞에서 설명한 문제점을 해결하기 위해 외부 애플리케이션 부하 분산기와 외부 프록시 네트워크 부하 분산기가 다른 리전으로 용량을 오버플로할 수 있습니다. 글로벌 애플리케이션의 경우 사용자에게 응답할 때 전반적인 지연 시간이 약간 길 경우 리전별 백엔드를 사용하는 것보다 더 나은 환경이 제공됩니다. 리전별 백엔드를 사용하는 애플리케이션은 명목상 지연 시간이 짧지만 과부하가 걸릴 수 있습니다.
이 문서의 시작 부분에서 언급한 시나리오를 외부 애플리케이션 부하 분산기가 어떻게 처리하는지 다시 살펴보겠습니다.
새 인스턴스 시작 지연. 로컬 트래픽 급증 시 자동 확장 처리로 용량을 충분히 빠르게 추가할 수 없는 경우 외부 애플리케이션 부하 분산기가 다음으로 가장 가까운 리전에 임시로 연결을 오버플로합니다. 이렇게 하면 원래 리전의 기존 사용자 세션이 기존 백엔드에 남아 있을 때 최적의 속도로 처리되고 새로운 사용자 세션은 약간만 지연됩니다. 원래 리전에서 추가 백엔드 인스턴스가 확장되는 즉시 새 트래픽은 사용자에게 가장 가까운 리전으로 다시 라우팅됩니다.
백엔드 용량이 제한되는 애플리케이션. 자동으로 확장되는 않지만 여러 리전에서 사용할 수 있는 애플리케이션은 한 리전의 수요가 평상시 트래픽 요구에 맞게 배포된 용량을 초과할 경우 다음으로 가장 가까운 리전으로 계속 오버플로될 수 있습니다.
비탄성 라이선스. 소프트웨어 라이선스 수가 제한되어 있고 현재 리전의 라이선스 풀이 모두 소진된 경우 외부 애플리케이션 부하 분산기를 통해 라이선스를 사용할 수 있는 리전으로 트래픽을 이동할 수 있습니다. 이를 위해 최대 인스턴스 수가 자동 확장 처리 기능의 최대 라이선스 수로 설정됩니다.
VM 여유 공간 부족. CPU 사용량이 높으면 자동 확장이 트리거되도록 설정할 수 있으므로 리전 오버플로가 가능하여 비용을 절약할 수 있습니다. 다른 리전으로의 오버플로로 인해 글로벌 용량이 항상 충분하기 때문에 사용 가능한 백엔드 용량을 각 리전별 피크 미만으로 구성할 수도 있습니다.
리전별 할당량. Compute Engine 리소스 할당량이 요구 사항에 맞지 않으면 외부 애플리케이션 부하 분산기 오버플로가 트래픽의 일부를 리전별 할당량 내에서 확장 가능한 리전으로 자동 리디렉션합니다.
다음 단계
다음 페이지에서는 Google의 부하 분산 옵션에 대한 자세한 정보와 배경 지식을 제공합니다.
- 부하 분산을 통한 용량 관리 가이드
- 부하 분산으로 애플리케이션 지연 최적화
- 네트워킹 기초 Codelab
- 외부 패스 스루 네트워크 부하 분산기
- 외부 애플리케이션 부하 분산기
- 외부 프록시 네트워크 부하 분산기