- 릴리스 정보 및 공지 사항
- 제품 소개
- 구매 가이드
- 시작하기
- 운영 가이드
- 모범 사례
- OPS 가이드
- 문제 해결
- API 참조
- History
- Introduction
- API Category
- Making API Requests
- Instance APIs
- Listener APIs
- Backend Service APIs
- Target Group APIs
- Redirection APIs
- Other APIs
- ModifyLoadBalancersProject
- InquiryPriceCreateLoadBalancer
- InquiryPriceModifyLoadBalancer
- InquiryPriceRenewLoadBalancer
- DescribeLoadBalancerTraffic
- DescribeTaskStatus
- DescribeClsLogSet
- CreateClsLogSet
- CreateTopic
- CreateLoadBalancerSnatIps
- DeleteLoadBalancerSnatIps
- SetLoadBalancerSecurityGroups
- SetSecurityGroupForLoadbalancers
- ReplaceCertForLoadBalancers
- DescribeLoadBalancerListByCertId
- SetLoadBalancerClsLog
- DescribeQuota
- DescribeResources
- Classic CLB APIs
- Load Balancing APIs
- Data Types
- Error Codes
- CLB API 2017
- FAQ
- 연락처
- 용어집
- 릴리스 정보 및 공지 사항
- 제품 소개
- 구매 가이드
- 시작하기
- 운영 가이드
- 모범 사례
- OPS 가이드
- 문제 해결
- API 참조
- History
- Introduction
- API Category
- Making API Requests
- Instance APIs
- Listener APIs
- Backend Service APIs
- Target Group APIs
- Redirection APIs
- Other APIs
- ModifyLoadBalancersProject
- InquiryPriceCreateLoadBalancer
- InquiryPriceModifyLoadBalancer
- InquiryPriceRenewLoadBalancer
- DescribeLoadBalancerTraffic
- DescribeTaskStatus
- DescribeClsLogSet
- CreateClsLogSet
- CreateTopic
- CreateLoadBalancerSnatIps
- DeleteLoadBalancerSnatIps
- SetLoadBalancerSecurityGroups
- SetSecurityGroupForLoadbalancers
- ReplaceCertForLoadBalancers
- DescribeLoadBalancerListByCertId
- SetLoadBalancerClsLog
- DescribeQuota
- DescribeResources
- Classic CLB APIs
- Load Balancing APIs
- Data Types
- Error Codes
- CLB API 2017
- FAQ
- 연락처
- 용어집
가중 라운드 로빈 스케줄링
가중 라운드 로빈 스케줄링(Weighted Round-Robin Scheduling) 알고리즘은 폴링을 기반으로 다른 서버에 대한 요청을 스케쥴링하는 것입니다. 다른 서버의 불균형 성능 문제를 해결할 수 있습니다. 가중치를 사용하여 서버의 처리 성능을 나타내고 폴링 방식으로 가중치별로 다른 서버에 대한 요청을 스케쥴링합니다. 새로운 연결 수를 기반으로 서버를 스케쥴링합니다. 여기서 가중치가 더 높은 서버가 더 일찍 연결을 수신하고 폴링할 가능성이 더 높습니다. 동일한 가중치를 가진 서버는 동일한 수의 연결을 처리합니다.
장점: 이 알고리즘은 단순성과 높은 실용성을 특징으로 합니다. 모든 연결의 상태를 기록할 필요가 없으므로 상태 비저장 스케쥴링 알고리즘입니다.
단점: 이 알고리즘은 비교적 단순하여 요청의 서비스 시간이 크게 변경되거나 각 요청에 다른 시간을 소비해야 하는 상황에는 적합하지 않습니다. 이러한 경우 서버 간에 부하 분산이 불균형하게 발생합니다.
적용 가능한 시나리오: 이 알고리즘은 각 요청이 기본적으로 최고의 로드 성능으로 백엔드에서 동일한 시간을 소비하는 시나리오에 적합합니다. 일반적으로 HTTP 서비스와 같은 비지속 연결 서비스에서 사용됩니다.
권장 사항: 각 요청이 기본적으로 백엔드에서 동일한 시간을 소비한다는 것을 알고 있는 경우(예시: 리얼 서버에서 처리되는 요청이 동일한 유형 또는 유사한 유형임) 가중 라운드 로빈 스케쥴링을 사용하는 것이 좋습니다. 각 요청 간의 시간 차이가 작은 경우, 이 알고리즘도 순회가 필요 없고, 효율성이 높으므로 권장됩니다.
가중 최소 연결 스케쥴링
실제 상황에서는 클라이언트의 요청이 서버에 머무르는 데 소요되는 시간이 크게 다를 수 있습니다. 작업 시간이 길어질수록 단순 라운드 로빈 또는 랜덤 로드 밸런싱 알고리즘을 사용하면 각 서버의 연결 프로세스 수가 크게 달라져 로드 밸런싱 효과를 얻을 수 없습니다.
라운드 로빈 스케쥴링과 달리 최소 연결 스케쥴링은 활성 연결 수량으로 서버의 부하를 추정하는 동적 스케쥴링 알고리즘입니다. 스케쥴러는 각 서버에 현재 설정된 연결 수를 기록해야 합니다. 서버에 대한 요청이 스케쥴링된 경우 연결 수는 1 증가합니다. 연결이 중지되거나 시간 초과되면 연결 수는 1 감소합니다.
최소 연결 스케쥴링에 기반한 가중 최소 연결 스케쥴링(Weighted Least-Connection Scheduling) 알고리즘에서는 서버의 처리 능력에 따라 서로 다른 가중치를 할당합니다. 이러한 방식으로 서버는 가중치에 따라 해당 수의 요청을 수신할 수 있으며, 이는 최소 연결 스케쥴링의 개선입니다.
설명：
리얼 서버의 가중치는 wi이고 현재 연결 수는 ci라고 가정합니다. 각 서버의 ci/wi 값은 순서대로 계산됩니다. ci/wi 값이 가장 작은 리얼 서버는 새 요청을 받는 다음 서버가 됩니다. 동일한 ci/wi 값을 가진 리얼 서버가 있는 경우 가중치 라운드 로빈 스케쥴링을 기반으로 스케쥴링됩니다.
장점: 이 알고리즘은 FTP와 같이 오랜 시간 처리가 필요한 요청에 적합합니다.
단점: API 제한으로 인해 최소 연결과 세션 지속성을 동시에 활성화할 수 없습니다.
적용 가능한 시나리오: 이 알고리즘은 백엔드에서 각 요청에 사용되는 시간이 크게 달라지는 시나리오에 적합합니다. 일반적으로 지속적 연결 서비스에 사용됩니다.
권장 사항: 다른 요청을 처리해야 하고 백엔드에서 필요한 서비스 시간이 크게 다른 경우(예시: 3ms 및 3s) 부하 분산을 달성하기 위해 가중 최소 연결 스케쥴링을 사용하는 것이 좋습니다.
소스 해싱 스케쥴링
소스 해싱 스케쥴링 알고리즘(ip_hash)은 요청의 소스 IP 주소를 해시 키로 사용하고 정적으로 할당된 해시 테이블에서 해당 서버를 찾습니다. 사용 가능하고 오버로드되지 않은 경우 요청이 이 서버로 전송됩니다. 그렇지 않으면 null이 반환됩니다.
장점: ip_hash는 클라이언트의 요청을 해시 테이블을 통해 동일한 리얼 서버에 매핑할 수 있습니다. 따라서 세션 지속성이 지원되지 않는 시나리오에서는 간단한 세션 지속성 효과를 얻기 위해 사용할 수 있습니다.
권장 사항: 이 알고리즘은 요청 소스 주소의 해시 값을 계산하고 가중치를 기반으로 일치하는 리얼 서버에 요청을 배포합니다. 이러한 방식으로 동일한 클라이언트 IP의 모든 요청을 동일한 서버에 배포할 수 있습니다. 이 알고리즘은 Cookie를 지원하지 않는 프로토콜에 적합합니다.
부하 분산 알고리즘 선택 및 가중치 구성
리얼 서버 클러스터가 다양한 시나리오에서 안정적으로 비즈니스를 수행할 수 있도록 로드 밸런싱 알고리즘을 선택하고 가중치를 구성하는 방법에 대한 몇 가지 사례가 아래에 참고용으로 제공됩니다.
시나리오1:
1.1 동일한 구성(CPU/메모리)을 가진 3개의 리얼 서버가 있고 동일한 성능을 가지므로 모든 가중치를 10으로 설정했다고 가정합니다.
1.2 각각의 리얼 서버와 클라이언트 사이에 100개의 TCP 연결이 설정되고 새로운 리얼 서버가 추가됩니다.
1.3 이 시나리오에서는 4번째 리얼 서버의 부하를 빠르게 증가시키고 나머지 3개 서버에 대한 압력을 줄일 수 있는 최소 연결 스케쥴링 알고리즘을 사용하는 것이 좋습니다.
시나리오2:
1.1 Tencent Cloud 서비스를 처음 사용하고 웹사이트가 방금 낮은 부하로 구축되었다고 가정합니다. 모두 동일한 액세스 레이어 서버이므로 동일한 구성의 리얼 서버를 구입하는 것이 좋습니다.
1.2 이 시나리오에서는 모든 리얼 서버의 가중치를 기본값인 10으로 설정하고 가중치 기반 라운드 로빈 스케쥴링 알고리즘을 사용하여 트래픽을 분산할 수 있습니다.
시나리오3:
1.1 정적 페이지에 대한 단순 액세스 요청을 수행하는 5개의 리얼 서버가 있고 이러한 서버의 컴퓨팅 성능(CPU 및 메모리로 계산) 비율이 9:3:3:3:1이라고 가정합니다.
1.2 이 시나리오에서는 리얼 서버의 가중치를 각각 90, 30, 30, 30, 10으로 설정할 수 있습니다. 정적 웹 페이지에 대한 대부분의 액세스 요청은 비지속적 연결 유형이므로 가중 라운드 로빈 스케쥴링 알고리즘을 사용하여 CLB 인스턴스가 서버의 성능 비율에 따라 요청을 할당할 수 있습니다.
시나리오4:
1.1 10개의 리얼 서버가 방대한 양의 Web 액세스 요청을 처리하며 추가 서버를 구입하지 않을 경우 지출이 증가하고 서버 중 하나가 과부하로 인해 다시 시작되는 경우가 종종 있다고 가정합니다.
1.2 이 시나리오에서는 기존 서버의 성능에 따라 가중치를 설정하고 부하가 높은 서버에 상대적으로 작은 가중치를 설정하는 것이 좋습니다. 또한 서버 과부하를 피하기 위해 최소 연결 스케쥴링 알고리즘을 사용하여 활성 연결이 적은 리얼 서버에 요청을 할당할 수 있습니다.
시나리오5:
1.1 일부 지속적 연결을 처리하기 위해 3개의 리얼 서버가 있다고 가정하고 이러한 서버의 컴퓨팅 성능 비율(CPU 및 메모리로 계산)은 3:1:1입니다.
1.2 성능이 가장 좋은 서버는 더 많은 요청을 처리하지만 과부하를 원하지 않고 유휴 서버에 새 요청을 할당하려고 합니다.
1.3 이 시나리오에서는 최소 연결 스케쥴링 알고리즘을 사용하고 사용량이 많은 서버의 가중치를 적절하게 줄여 CLB 인스턴스가 활성 연결이 적은 리얼 서버에 요청을 할당하여 로드 밸런싱을 구현할 수 있습니다.
시나리오6:
1.1 클라이언트의 후속 요청이 동일한 서버에 할당되기를 원한다고 가정합니다. 가중 라운드 로빈 또는 가중 최소 연결 스케쥴링은 동일한 클라이언트의 요청이 동일한 서버에 할당되도록 보장할 수 없습니다.
1.2 특정 응용 프로그램 서버의 요구 사항을 충족하고 클라이언트 세션의 ‘고정성’(또는 ‘연속성’)을 유지하려면 ip_hash를 사용하여 트래픽을 분산할 수 있습니다. 이 알고리즘은 서버 수가 변경되거나 서버를 사용할 수 없게 되지 않는 한 동일한 클라이언트의 모든 요청이 동일한 리얼 서버에 배포되도록 할 수 있습니다.
예
아니오
문제 해결에 도움이 되었나요?