CLB 알고리즘의 비교 분석
가중 라운드 로빈 스케쥴링 Weighted Round-Robin Scheduling
가중 라운드 로빈 스케쥴링 알고리즘은 폴링을 기반으로 다른 서버에 대한 요청을 스케쥴링하는 것입니다. 다른 서버의 불균형 성능 문제를 해결할 수 있습니다. 가중치를 사용하여 서버의 처리 성능을 나타내고 폴링 방식으로 가중치별로 다른 서버에 대한 요청을 스케쥴링합니다. 새로운 연결 수를 기반으로 서버를 스케쥴링합니다. 여기서 가중치가 더 높은 서버가 더 일찍 연결을 수신하고 폴링할 가능성이 더 높습니다. 동일한 가중치를 가진 서버는 동일한 수의 연결을 처리합니다.
장점: 이 알고리즘은 단순성과 높은 실용성을 특징으로 합니다. 모든 연결의 상태를 기록할 필요가 없으므로 상태 비저장 스케쥴링 알고리즘입니다.
단점: 이 알고리즘은 비교적 단순하여 요청의 서비스 시간이 크게 변경되거나 각 요청에 다른 시간을 소비해야 하는 상황에는 적합하지 않습니다. 이러한 경우 서버 간에 부하 분산이 불균형하게 발생합니다.
적용 가능한 시나리오: 이 알고리즘은 각 요청이 기본적으로 최고의 로드 성능으로 백엔드에서 동일한 시간을 소비하는 시나리오에 적합합니다. 일반적으로 HTTP 서비스와 같은 비지속 연결 서비스에서 사용됩니다.
권장 사항: 각 요청이 기본적으로 백엔드에서 동일한 시간을 소비한다는 것을 알고 있는 경우(예시: 리얼 서버에서 처리되는 요청이 동일한 유형 또는 유사한 유형임) 가중 라운드 로빈 스케쥴링을 사용하는 것이 좋습니다. 각 요청 간의 시간 차이가 작은 경우, 이 알고리즘도 순회가 필요 없고, 효율성이 높으므로 권장됩니다.
가중 최소 연결 스케쥴링 Weighted Least-Connection Scheduling
원리
실제 상황에서는 각 클라이언트 요청이 서버에서 소비하는 시간이 크게 다를 수 있습니다. 작업 시간이 길어질수록 단순 라운드 로빈 또는 랜덤 부하 분산 알고리즘을 사용하는 경우 각 서버의 연결 프로세스 수가 크게 달라지고 부하 분산이 이루어지지 않을 수 있습니다. 라운드 로빈 스케쥴링과 달리 최소 연결 스케쥴링은 활성 연결 수를 기반으로 서버의 부하를 추정하는 동적 스케쥴링 알고리즘입니다. 스케쥴러는 각 서버에 현재 설정된 연결 수를 기록해야 합니다. 요청이 서버에 예약된 경우 연결 수가 1 증가합니다. 연결이 중지되거나 시간 초과되면 연결 수가 1 감소합니다. 가중 최소 연결 스케쥴링 알고리즘은 최소 연결 스케쥴링을 기반으로 하며 처리 성능에 따라 서버에 다른 가중치가 할당됩니다. 그 가중치에 따라 서버는 해당 수의 요청을 수신할 수 있습니다. 이 알고리즘은 최소 연결 스케쥴링을 개선한 것입니다.
1.1 리얼 서버의 가중치가 Wi(i=1…n)이고 현재 연결 수가 Ci(i=1…n)라고 가정합니다. 각 서버의 Ci/Wi 값은 순서대로 계산됩니다. 가장 작은 Ci/Wi 값을 가진 RS가 새 요청을 받는 다음 서버가 됩니다.
1.2 동일한 Ci/Wi 값을 가진 RS의 경우 가중치 라운드 로빈 스케쥴링을 기반으로 스케쥴링됩니다.
장점
이 알고리즘은 FTP와 같이 오랜 시간 처리가 필요한 요청에 적합합니다.
단점
API 제한으로 인해 최소 연결 및 세션 지속성을 동시에 활성화할 수 없습니다.
적용 시나리오
이 알고리즘은 백엔드에서 각 요청에 사용되는 시간이 크게 달라지는 시나리오에 적합합니다. 일반적으로 지속 연결 서비스에 사용됩니다.
권장 사항
다른 요청을 처리해야 하고 백엔드에서 서비스 시간이 크게 달라지는 경우(예시: 3ms 및 3s) 부하 분산을 달성하기 위해 가중 최소 연결 스케쥴링을 사용하는 것이 좋습니다.
원본 해싱 스케쥴링(ip_hash)
원리
원본 해싱 스케쥴링은 요청의 원본 IP 주소를 해시 키(Hash Key)로 사용하고 정적으로 할당된 해시 테이블에서 해당 서버를 찾습니다. 사용 가능하고 오버로드되지 않은 경우 요청이 이 서버로 전송됩니다. 그렇지 않으면 null이 반환됩니다.
장점
ip_hash는 원본 IP를 기억하고 hash 테이블을 통해 client의 요청을 동일한 rs로 매핑하여 특정 세션 지속성을 달성할 수 있습니다. 세션 지속성이 지원되지 않는 시나리오에서는 ip_hash를 스케쥴링에 사용할 수 있습니다.
권장 사항
이 알고리즘은 요청 원본 주소의 hash 값을 계산하고 가중치에 따라 해당 리얼 서버에 요청을 배포합니다. 이를 통해 동일한 클라이언트 IP의 요청을 동일한 서버에 배포할 수 있습니다. 이 알고리즘은 cookie를 지원하지 않는 TCP 프로토콜을 통한 부하 분산에 적합합니다.
부하 분산 알고리즘 선택 및 가중치 구성 예시
CLB의 향후 기능에서 레이어 7 포워딩은 최소 연결 부하 분산 방법을 지원합니다. 부하 분산 알고리즘을 선택하고 참고용으로 가중치를 구성하는 방법에 대한 예시를 제공하므로 RS 클러스터가 다양한 시나리오에서 안정적으로 비즈니스를 수행할 수 있습니다.
시나리오1
동일한 구성(CPU / 메모리)을 가진 3개의 RS가 있고 이들의 가중치를 모두 10으로 설정하고, 각 RS와 client 간에 100개의 TCP 연결이 설정되었다고 가정합니다. 새로운 RS가 추가되는 경우 4번째 서버의 부하를 빠르게 증가시키고 다른 3개의 서버에 대한 부하를 줄일 수 있는 최소 연결 스케쥴링 알고리즘을 사용하는 것이 좋습니다.
시나리오2
Tencent Cloud 서비스를 처음 사용한다고 가정합니다. 귀하의 웹사이트는 막 구축되었으며 로드가 적습니다. 모두 액세스 레이어 서버이므로 동일한 구성의 RS를 구입하는 것이 좋습니다. 이 시나리오에서는 모든 RS의 가중치를 10으로 구성하고 가중치 기반 라운드 로빈 스케쥴링 알고리즘을 사용하여 트래픽을 분산할 수 있습니다.
시나리오3
정적 웹 사이트에 대한 간단한 액세스 요청을 수행하는 5개의 리얼 서버가 있고 해당 서버의 컴퓨팅 성능 비율(CPU 및 메모리로 계산)이 9:3:3:3:1이라고 가정합니다. 이 시나리오에서는 RS의 가중치를 각각 90, 30, 30, 30, 10으로 구성할 수 있습니다. 정적 웹 사이트에 대한 액세스 요청은 대부분 비지속 연결 유형이므로 가중치 라운드 로빈 스케쥴링 알고리즘을 사용할 수 있으므로 CLB는 RS의 성능 비율에 따라 요청을 할당할 수 있습니다.
시나리오4
엄청난 양의 Web 액세스 요청을 처리하기 위해 10개의 RS가 있고 더 이상 서버를 구입하고 싶지 않다고 가정합니다. 과부하로 인해 서버 중 하나가 다시 시작되는 경우가 많습니다. 이 시나리오에서는 RS의 성능을 기반으로 기존 서버의 가중치를 구성하는 것이 좋습니다. 부하가 높은 서버는 무게가 더 작아야 합니다. 또한 최소 연결 스케쥴링 알고리즘을 사용하여 서버 과부하를 피하기 위해 활성 연결이 적은 RS에 요청을 할당할 수 있습니다.
시나리오5
지속 연결을 처리할 RS가 3개 있고 컴퓨팅 성능의 비율(CPU와 메모리로 계산)이 3:1:1이라고 가정합니다. 성능이 가장 좋은 서버는 더 많은 요청을 처리하지만 과부하 상태가 되는 것을 원하지 않습니다. 대신 유휴 서버에 새 요청을 할당하려고 합니다. 이 시나리오에서는 최소 연결 스케쥴링 알고리즘을 사용하고 사용량이 많은 서버의 가중치를 적절하게 줄일 수 있으므로 CLB가 활성 연결이 적은 RS에 요청을 할당하여 부하 분산을 달성할 수 있습니다.
시나리오6
클라이언트의 후속 요청이 동일한 서버에 할당되기를 원한다고 가정합니다. 가중 라운드 로빈 또는 가중 최소 연결 스케쥴링은 동일한 클라이언트의 요청이 동일한 서버에 할당되도록 보장할 수 없습니다. 지정된 애플리케이션 서버의 요구 사항을 충족하고 클라이언트 세션의 ‘고정성’(또는 ‘연속성’)을 유지하려면 ip_hash를 사용하여 트래픽을 분산하는 것이 좋습니다. 이 알고리즘은 서버 수가 변경되거나 서버를 사용할 수 없게 되지 않는 한 동일한 클라이언트의 모든 요청이 동일한 RS에 배포되도록 합니다.
가중치를 0으로 재설정하는 것과 바인딩 해제의 차이
가중치를 0으로 재설정: TCP 리스너는 기존 연결을 계속 포워딩하고 UDP 리스너는 동일한 5배 연결을 포워딩하며 HTTP/HTTPS 리스너는 기존 연결을 계속 포워딩합니다.
RS 바인딩 해제: TCP/UDP 리스너는 기존 연결 포워딩을 중지하고 HTTP/HTTPS 리스너는 기존 연결을 계속 포워딩합니다.
관련 문서