위키원
로드밸런싱
로드밸런싱(Load Balancing) 또는 부하 분산이란 컴퓨터 네트워크 기술의 일종으로 둘 혹은 셋 이상의 중앙처리장치 혹은 저장장치와 같은 컴퓨터 자원들에 작업을 나누는 것을 의미한다. 이로써 가용성 및 응답시간을 최적화시킬 수 있다. 예를 들어, 메인프레임 1대(단일 구성체)보다 IA-32와 같은 일반적인 서버(복합 구성체)가 안정성 면에서 유리한 위치에 있다. 로드밸런싱 서비스는 그에 적합한 하드웨어와 소프트웨어에 의해 제공된다. 이 기술은 보통 내부 네트워크를 이용한 병렬처리에 사용된다.
개요[편집]
로드밸런싱이란 들어오는 네트워크 트래픽을 서버 팜 또는 서버 풀이라고도 하는 백엔드 서버 그룹에 효율적으로 분산시키는 것을 말한다. 현대의 높은 트래픽의 웹사이트는 사용자나 클라이언트의 동시 요청 수십만 개를 처리하고 정확한 텍스트, 이미지, 비디오 또는 응용 프로그램 데이터를 빠르고 신뢰할 방법으로 반환해야 한다. 이러한 대용량을 충족하기 위해 비용 효율적으로 확장하려면 일반적으로 현대적인 컴퓨팅 모범 사례에 서버를 추가해야 한다. 부하 분산 장치는 속도 및 용량 활용도를 극대화하고 어느 서버도 과로하지 않도록 보장하여 성능을 저하할 수 있는 방식으로 서버 앞에 앉아 클라이언트 요청을 모든 서버에 라우팅하는 트래픽 경찰 역할을 한다. 단일 서버가 다운되면 로드밸런서는 트래픽을 나머지 온라인 서버로 리디렉션한다. 서버 그룹에 새 서버를 추가하면 로드밸런서가 자동으로 요청 전송을 시작한다. 이러한 방식으로 로드밸런서는 클라이언트 요청 또는 네트워크 로드를 여러 서버에 효율적으로 분산하고, 온라인 상태의 서버에만 요청을 전송하여 고가용성 및 안정성을 보장하고, 요구 사항에 따라 서버를 추가하거나 제거할 수 있는 유연성을 제공한다.[1]
로드밸런싱을 위한 대부분의 응용 프로그램은 다수의 서버를 가지고 한 가지 종류의 인터넷 서비스를 지원하는 방식이다. 보통 로드밸런싱은 트래픽이 많은 웹 사이트, 인터넷 릴레이 챗(IRC, Internet Relay Chat) 네트워크, 파일 전송 프로토콜(FTP, File Transfer Protocol) 사이트, 네트워크 뉴스 전송 프로토콜(NNTP, Network News Transfer Protocol) 서버 그리고 DNS 서버에 적용이 되고 있다. 인터넷 서비스를 위해서는 소프트웨어를 이용한 로드밸런싱이 적용되며, 이 소프트웨어는 중간에 위치에 실제 서비스하는 서버와 클라이언트를 포트를 이용해 중개하고 있다. 그러나 사용자는 이를 알아차리지 못한다. 이를 투명성이라 한다. 또한, 보안이라는 측면에서 내부 네트워크 구조를 숨김으로써 크래킹을 막을 수 있다. 일부 로드밸런싱 소프트웨어는 실 서비스 서버들을 관리하는 역할을 수행하기도 한다. 로드밸런싱의 다른 방식으로는 라운드 로빈 DNS 라고 하는 특별한 하드웨어 및 소프트웨어가 필요가 없는 방식이 있다. 이 방식에서는 여러 개의 IP주소를 동일한 도메인 네임에 연관 지어 놓고 클라이언트들이 어떤 서버를 사용할 것인지 결정하게 하는 방식이다. 일반적인 로드밸런싱과는 다르게 "투명성"이 존재하지 않는다. 이미 내부의 서버들의 주소가 이미 노출되어 있기 때문이다. 이 방식은 DNS 서버에 대한 의존도가 높고 로드밸런싱이 원하는 대로 될 수 있다는 것이다.[2]
장단점[편집]
로드밸런싱은 고가의 서버로 확장하지 않고 저렴한 비용에 다수의 서버로 증설하여 경제적으로 비용 절감을 할 수 있다. 대량의 트래픽으로 1대의 서버로 집중적인 부하율이 높아지면 L4 스위치가 이를 감지하여 합리적으로 로드밸런싱을 처리 할 수 있다. 1대의 서버 장애가 발생하여도 서비스 중단없이 다른 서버로 적절히 자동으로 분배하여 서비스가 계속 운용 가능하게 할 수 있다. 추후 사용량이 많아 서버 확장으로 서비스 중단없이 서버 증설이 가능하다. 로드밸런싱 기능이 있는 ADC는 IT 부서가 서비스의 확장성과 가용성을 보장하는 데 도움이 된다. 고급 트래픽 관리 기능은 사업체가 각 최종 사용자를 위한 정확한 자원으로 보다 효율적으로 요청하도록 도울 수 있다. ADC는 환경 전체에 걸쳐 수많은 애플리케이션과 서비스를 보안, 관리 및 모니터링하고 최상의 최종 사용자 환경을 보장하기 위한 단일 제어 지점을 제공할 수 있는 다른 많은 기능(예: 암호화, 인증 및 웹 애플리케이션 방화벽)을 제공한다.[3]
단점으로 로드밸런서를 사용할 때 어려운 문제 중 하나가 세션 데이터를 관리하는 것이다. 클라이언트의 연결 정보를 저장하는 세션이 로드밸런싱을 통해 하나의 서버 장비에 저장이 되는 경우, 추후 다른 서버로 접속하게 되면, 해당 클라이언트의 세션이 유지되지 않는다는 것이다. 서버에 액세스할 때마다 다른 세션을 사용한다면 특정 사용자의 정보를 일관성 있게 유지할 수 없게 된다. 이러한 문제를 해결하기 위해 세션을 고정한다. 이 방법으로 특정 사용자의 요청이 전달될 노드를 고정할 수 있지만 고정된 세션의 노드에 장애가 발생하면 고정한 의미가 없어진다. 장애가 발생하여 비활성화된 노드에 대한 고려가 필요하다.[4][5]
작동 방식[편집]
로드밸런싱은 두 개 이상의 컴퓨터 자원에 작업을 나누는 것을 의미하며 로드밸런서는 작업을 담당하는 장비를 의미한다. 로드밸런서는 정보 및 기타 서비스에 대한 사용자의 들어오는 요청을 처리한다. 그들은 그 요청을 처리하는 서버와 인터넷 사이에 앉아있다. 요청이 수신되면 로드밸런서는 먼저 풀에서 사용할 수 있는 온라인 서버를 확인한 다음 해당 서버로 요청을 라우트한다. 부하가 많은 시간 동안 로드밸런서는 트래픽 급증에 대응하여 서버를 동적으로 추가할 수 있다. 반대로 수요가 적으면 서버를 떨어뜨릴 수 있다. 로드밸런서는 물리적 어플라이언스, 소프트웨어 인스턴스 또는 둘 모두의 조합일 수 있다. 전통적으로 벤더는 전용 하드웨어에 독점 소프트웨어를 탑재하여 사용자에게 독립 실행형 어플라이언스(대개 쌍으로 구성)로 판매하여, 한 제품이 고장 나면 페일 오버를 제공한다. 네트워크가 성장하려면 추가 및/또는 더 큰 가전제품을 구매해야 한다. 이와는 대조적으로 소프트웨어 로드밸런싱은 가상 머신(VM) 또는 화이트 박스 서버에서 실행되며, 애플리케이션 제공 컨트롤러(ADC)의 기능으로 실행될 가능성이 크다. ADC는 일반적으로 캐싱, 압축, 트래픽 쉐이핑 등과 같은 추가 기능을 제공한다. 클라우드 환경에서 인기 있는 가상 로드밸런싱은 높은 수준의 유연성을 제공할 수 있다. 예를 들어, 사용자가 트래픽 급증 또는 네트워크 활동 감소를 미러링하기 위해 자동으로 스케일업 또는 스케일다운할 수 있다.[6]
로드밸런서는 OSI 7계층을 기준으로 어떻게 부하를 분산하는지에 따라 종류가 나뉜다. 2계층을 기준으로 부하를 분산하면 L2, 3계층을 기준으로 부하를 분산한다면 L3인 방식이다. 상위 계층으로 갈수록 섬세한 로드밸런싱이 가능하지만, 가격이 비싸진다. 하위 계층으로 갈수록 간단한 로드밸런싱이 가능하고 가격이 저렴해진다. 사업의 규모가 확장되고, 클라이언트의 수가 늘어나게 되면 기존 서버만으로는 정상적인 서비스가 불가능하게 된다.[7]
- 하드웨어 로드밸런서 : 이름에서 알 수 있듯이 애플리케이션과 네트워크 트래픽을 분산하기 위해 물리적 사내 하드웨어에 의존한다. 이 장치들은 많은 양의 트래픽을 처리할 수 있지만 종종 많은 가격표를 가지고 있으며 유연성의 측면에서 상당히 제한적이다.[8]
- 소프트웨어 로드밸런서 : 상용 또는 오픈 소스라는 두 가지 형태로 제공되며 사용하기 전에 설치해야 한다. 클라우드 기반 밸런서와 마찬가지로 하드웨어 솔루션보다 가격이 저렴한 경향이 있다.[8]
- 가상 로드밸런서 : 하드웨어 로드밸런싱 장치의 소프트웨어를 가상 시스템에 배포하기 때문에 소프트웨어 로드밸런서와는 다르다.[8]
로드밸런서는 L2, L3, L4, L7으로 나뉠 수 있다. 로드밸런싱에는 L4 로드밸런서와 L7 로드밸런서가 가장 많이 활용된다. 그 이유는 L4 로드밸런서부터 포트 정보를 바탕으로 로드를 분산하는 것이 가능하기 때문이다. 한 대의 서버에 각기 다른 포트 번호를 부여하여 다수의 서버 프로그램을 운영하는 경우라면 최소 L4 로드밸런서 이상을 사용해야만 한다. 스위치라는 용어도 많이 쓴다.
L2 로드밸런싱[편집]
데이터 링크 계층(L2)에서 정의된 정보를 바탕으로 로드밸런싱을 하는 것이다. 맥주소(MAC, Media Access Control Address)를 이용하여 전달할 서버를 결정한다.L4, l7 로드밸런서 대비 로드밸런싱 전략이 제한적이다. L2DSR 전략에서 로드밸런서는 inbound 패킷의 맥주소를 서버의 맥주소로 변환한 뒤 서버에게 전달한다. 이 전략을 사용하기 위해서는 로드밸런서와 서버가 반드시 같은 네트워크에 속해야 한다. 로드밸런서가 알 수 있는 게 맥 주소밖에 없는데, 패킷의 MAC 주소를 서버의 MAC 주소로 변경을 했을 때 이 패킷이 바로 서버로 가야 한다. IP는 그대로인데 MAC 주소만 바꿔서 서버에 도달해야 하는데, 이를 위해서 서버와 로드밸런서 모두 VIP가 설정되어야 하는 등 이런저런 제약이 있다.[9]
L3 로드밸런싱[편집]
네트워크 계층(L3)에서 정의된 정보를 바탕으로 로드밸런싱을 하는 것이다. 포트 간 패킷 스위칭을 위해 IP 나 IPX 주소를 기반으로 스위칭한다. 특정 프로토콜을 사용하는 패킷에 대해 스위칭이 가능하다. L2에 라우팅 기능이 추가된 것이다. 라우터가 있다. Broadcast 트래픽으로 전체 성능 저하를 막을 수 있다. 트래픽 체크, 가상 랜 등의 많은 부가 기능을 제공한다. 특정 프로토콜을 이용해야 스위칭할 수 있다.[9]
L4 로드밸런싱[편집]
전송 계층(L4)의 정보를 바탕으로 부하를 분산한다. IP 주소와 포트 번호를 이용한다. L3의 정보도 활용하니까 정확히는 L3 and L4 로드 밸런싱이 맞겠지만, n번 레이어를 활용한다는 것은 n-1 이하의 레이어들도 활용할 수 있다는 것이며 통상 L4 로드밸런싱이라 불린다. L4 로드밸런서는 패킷 헤더의 소스 IP 와 destination IP를 네트워크 주소 변환을 통해 바꿔서 서버에게 전달한다. 반대로 클라이언트로 패킷이 갈 때도 소스 IP 와 destination IP를 바꿔서 클라이언트에게 잘 전달되도록 한다. L2보다는 비용이 더 비싸지만 IP 와 포트 번호를 활용하여 상대적으로 더 섬세한 라우팅이 가능하다. 내용물을 보지 않기 때문에 TLS termination이 없다.[9]
L7 로드밸런싱[편집]
응용계층(L7)의 정보를 바탕으로 부하를 분산한다. TLS termination이 일어난다. 소프트웨어적인 로드밸런싱이 필요하다. L2, L4 로드 밸런싱은 물리적 단계에서 충분하지만, L7은 소프트웨어를 사용해야 하므로 비용이 더 비싸다. 가장 섬세한 라우팅이 가능하다. HTTP 헤더, 쿠키 등과 같은 사용자의 요청을 기준으로 특정 서버에 트래픽을 분산하는 것이 가능하다. 쉽게 말해 패킷의 내용을 확인하고 그 내용에 따라 로드를 특정 서버에 분배하는 것이 가능한 것이다. URL에 따라 부하를 분산시키거나, HTTP 헤더의 쿠키값에 따라 부하를 분산하는 등 클라이언트의 요청을 보다 세분화해 서버에 전달할 수 있다. 또한 L7 로드밸런서의 경우 특정한 패턴을 지닌 바이러스를 감지해 네트워크를 보호할 수 있으며, DoS/DDoS와 같은 비정상적인 트래픽을 필터링할 수 있어 네트워크 보안 분야에서도 활용되고 있다.[9][10]
기능[편집]
로드밸런싱 클러스터를 생각하면 대부분 로드밸런서를 앞단에 두고 백엔드의 리얼 서버에 작업을 분산하는 서버 측면의 로드밸런싱 방식을 알고 있다. 하지만 클라이언트에 로드밸런싱 모듈을 넣어 서버의 상황을 클라이언트가 서버로부터 얻어내어 클라이언트가 직접 서버로 분산해서 들어가는 클라이언트 측면의 로드밸런싱도 있다. 서버 측면의 로드밸런싱 방식으로는 DNS 호스트를 이용한 라운드로빈 DNS 방법과 리저브 프록시와 같은 응용 프로그램 계층의 로드밸런싱 그리고 L4 스위치와 같은 IP 계층의 로드밸런싱 방식이 있다. 리눅스 가상 서버 역시 IP 계층의 로드밸런싱 방식에 속한다.[11] 로드밸런싱에서 사용하는 주요 기능은 다음과 같다.
네트워크 주소 변환[편집]
네트워크 주소 변환(NAT, Network Address Translation)은 사설 IP 주소를 공인 IP 주소로 변경, 주소변경의 역할을 한다.[12] IPv4 에서 IP 주소가 부족하고 보안상에 몇가지 문제가 있어서 인터넷에서 사용할 수 없는 사설 IP를 사용하는 경우가 많아지고 있다. 이때 인터넷 망에서 사설망의 호스트에 접근하기 위해서 네트워크 주소 변환 기능이 필요하게 된다.[11]
동적 소스 라우팅 프로토콜[편집]
동적 소스 라우팅 프로토콜(DSR, Dynamic Source Routing protocol)은 서버에서 클라이언트로 되돌아가는 경우 목적지 주소를 스위치의 IP 주소가 아닌 클라이언트의 IP 주소로 전달해서 네트워크 스위치를 거치지 않고 바로 클라이언트를 찾아가는 개념이다.[12] 실제 서버와 부하 분산 서버 사이에서 가상 IP 를 공유하는 방식으로 부하 분산 서버와 실제 작업 서버에 모두 동일한 가상 IP 를 가지도록 네트워크 구성해야 한다. 가상 IP 가 설정된 인터페이스를 통해 사용자의 요청을 받아들여 이 요청이 가상 서버 정책에 적용되는 요청인지를 확인 후 적용되는 패킷이면 정책에 따라 실제 작업 서버로 패킷을 포워딩하게 된다. 이때 실제 서버 역시 별도의 Arp 캐싱을 남기지 않는 에일리어스(Alias) 인터페이스를 통해 로드밸런싱 서버로부터 포워딩되는 패킷을 받아 들이게 된다. 만일 가상 IP 가 설정된 인터페이스에 arp 캐싱이 남는다고 하면 사용자가 부하 분산 서버를 통해 초기에 연결된 실제 작업와 연결되면 그 이후부터는 초기 접속한 작업 서버와만 통신이 이루어 지게 된다. 그렇기 때문에 반드시 커널 차원에서의 arp 히든 패치(hidden patch)를 시켜줘야 한다. 동적 소스 라우팅 프로토콜 방식은 패킷의 데이터 프레임 부분의 맥주소만을 변경하여 패킷을 포워딩 하기 때문에 물리적인 세크먼트(같은 subnet)안에서만 동작이 가능하다.[11]
터널링[편집]
터널링(Tunneling)은 인터넷상에서 눈에 보이지 않는 통로를 만들어 통신할 수 있게 하는 개념이다. 데이터를 캡슐화해서 연결된 상호 간에만 캡슐화된 패킷을 구별해 캡슐화를 해제할 수 있다.[12] IP 터너링은 IP화된 정보(IP 데이터그램) 안에 IP화된 정보를 감싸 넣는(encapsulate) 기술이다. 이를 이용하여 보다 왠(WAN)을 대상으로 작업 서버 노드를 구성할 수 있게 된다. 실제 가상 IP 주소로 향하는 요구 패킷이 로드밸런싱 서버로 전달 되면 로드밸런싱 서버에서 패킷의 목적지 주소와 포트를 검사하여 가상 서버 정책과 일치 하면 스케줄링에 따라 실제 작업 서버로 전달하게 된다. 이때 패킷을 일반적인 스트림(Stream) 방식으로 전달하는 것이 아닌 캣슐 형식으로 싸서 전달하게 된다. 이리 전달 되면 작업 서버에서는 감싸진 패킷을 다시 풀고 요청을 처리한 다음 실제 서버의 라우팅 테이블에 따라 사용자에게 직접 결과를 돌려주는 방식이다. IP 터너링 방식은 동적 소스 라우팅 프로토콜 방식의 물리적인 세그먼트의 영향을 받지 않고 어디든지 작업을 분산 할 수 있는 장점이 있다. 그래서 거의 무한한 확장성을 가지게 된다. 하지만 모든 서버가 IP 터널링 전송 규약을 지원해야 하기에 지원하지 못하는 OS에서는 문제가 발생하게 된다.[11]
유형[편집]
로드밸런싱 유형에는 관계형 데이터베이스를 위한 SQL Server 로드밸런싱, 여러 지리적 위치에서의 문제 해결을 위한 글로벌 서버 로드밸런싱, 도메인 이름 기능을 보장하기 위한 DNS 서버 로드밸런싱 등 네트워크에 대해 고려해야 할 여러 가지 특정 유형의 로드밸런싱이 있다.[8]
네트워크 로드밸런싱[편집]
네트워크 로드밸런싱은 이름에서 알 수 있듯이 네트워크 계층 정보를 활용하여 네트워크 트래픽을 전송할 위치를 결정한다. 이는 모든 형태의 TCP/UDP 트래픽을 처리하도록 설계된 4계층 로드밸런싱을 통해 달성된다. 네트워크 부하 분산은 모든 부하 분산 솔루션 중 가장 빠른 것으로 여겨지지만, 서버 간 트래픽 분산에 있어서는 부족한 경향이 있다.[8]
HTTP(S) 로드밸런싱[편집]
HTTP(S) 로드밸런싱은 가장 오래된 형태의 로드밸런싱 중 하나이다. 이 형태의 로드밸런싱은 L7에 의존하며, 이는 애플리케이션 계층에서 작동한다는 것을 의미한다. HTTP 로드밸런싱은 HTTP 주소와 함께 제공되는 정보를 기반으로 배포 결정을 형성할 수 있기 때문에 종종 가장 유연한 유형의 로드밸런싱이라고 불린다.[8]
내부 로드밸런싱[편집]
내부 로드밸런싱은 네트워크 부하 분산과 거의 동일하지만 내부 인프라의 균형을 맞추기 위해 활용될 수 있다. 로드밸런싱 장치의 유형을 말할 때 하드웨어 로드밸런싱 장치, 소프트웨어 로드밸런싱 장치 및 가상 로드밸런싱 장치가 있다는 점도 유의해야 한다.[8]
알고리즘[편집]
로드밸런싱 의사결정을 수행하기 위한 알고리즘으로 로드밸런서 그룹은 알고리즘을 사용하여 의사결정을 수행한다. 의사결정은 새 연결을 전달한 원격 서버를 결정한다. 로드밸런서 그룹은 가중치 및 비 가중치 알고리즘을 지원한다. 부하 분산 방식에는 크게 정적 부하 분산과 동적 부하 분산으로 나뉜다. 정적 부하 분산 방식은 클라이언트로부터 요청을 받으면, 서버 상태와 상관없이 서버가 가지고 있는 설정을 기준으로 할당하는 방식이다. 상시 변하는 서버 상태를 전혀 고려하지 않고 단순히 서버에 할당함으로써 다음 순서로 할당할 서버를 예측하기가 쉽다. 라운드 로빈, 가중치, 액티브-스탠바이가 있다. 동적 부하 분산 방식은 클라이언트로부터 요청을 받으면, 서버 상태에 따라 할당할 대상의 서버를 결정한다. 서버나 클라이언트의 상태에 따라 어느 서버에 할당할 것인가 결정하기 때문에 다양한 프로토콜과 애플리케이션에 유연하게 대처할 수 있다. 최소 연결 수, 최단 응답 시간, 최소 부하 등이 있다.[13]
라운드 로빈 방식[편집]
라운드 로빈(Round Robin Method)은 클라이언트로부터 받은 요청을 로드밸런싱 대상 서버에 순서대로 할당받는 방식이다. 첫 번째 요청은 첫 번째 서버, 두 번째 요청은 두 번째 서버, 세 번째 요청은 세 번째 서버에 할당한다. 로드밸러닝 대상 서버의 성능이 동일하고 처리 시간이 짧은 애플리케이션의 경우, 균등하게 분산이 이루어지기 때문에 이 방식을 사용한다. 로드밸런싱 대상 서버의 성능이 다른 경우에 파일 전송 프로토콜, 세션 유지 기능(Persistence)이 필요한 애플리케이션의 경우 서버 처리와 관계없이 연결이 할당되는 라운드 로빈 방식은 적합하지 않다. 서버와의 연결이 오래가지 않는 경우에 활용하기 적합하다.[13]
가중 라운드 로빈 방식[편집]
가중 라운드 로빈 방식(Weighted Round Robin Method)은 실제 서버에 서로 다른 처리 용량을 지정할 수 있다. 각 서버에 가중치를 부여할 수 있으며, 여기서 지정한 정숫값을 통해 처리 용량을 정한다. 기본 가중치는 1이다. 예를 들어 실제 서버가 A, B, C이고 각각의 가중치가 4, 3, 2일 경우 스케줄링 순서는 ABCABCABA 가 된다. 가중 라운드 로빈 방식을 사용하면 실제 서버에서 네트워크 접속을 셀 필요가 없고 동적 스케줄링 알고리즘보다 스케줄링의 과부하가 적으므로 더 많은 실제 서버를 운영할 수 있다. 그러나 요청에 대한 부하가 매우 많을 때 실제 서버 사이에 동적인 부하 불균형 상태가 생길 수 있다. 라운드 로빈 방식은 가중 라운드 로빈 방식의 특별한 한 종류이며 모든 가중치가 동일한 경우이다. 가상 서버의 규칙을 변경하고 나서 스케줄링 순서를 생성하는 데는 거의 과부하가 걸리지 않으며 실제 스케줄링에 어떠한 과부하도 추가하지 않는다. 그러므로 라운드 로빈 방식만 단독으로 실행하는 것은 불필요한 일이다.[14]
IP 해시 방식[편집]
IP 해시 방식(IP Hash Method)은 클라이언트의 IP 주소를 특정 서버로 매핑하여 요청을 처리하는 방식이다. 사용자의 IP를 해싱(Hashing)해 로드를 분배하기 때문에 사용자가 항상 동일한 서버로 연결되는 것을 보장한다.[10]
최소 연결 방식[편집]
최소 연결 방식(Least Connection Method)은 가장 접속이 적은 서버로 요청을 직접 연결하는 방식을 말한다. 각 서버에서 동적으로 실제 접속한 숫자를 세어야 하므로 동적 스케줄링 알고리즘 중의 하나이다. 비슷한 성능의 서버로 구성된 가상 서버는 아주 큰 요구가 한 서버로만 집중되지 않기 때문에, 접속 부하가 매우 큰 경우에도 아주 효과적으로 분산을 한다. 가장 빠른 서버에서 더 많은 네트워크 접속을 처리할 수 있다. 그러므로 다양한 처리 용량을 지닌 서버로 구성했을 때도 훌륭하게 작동한다는 것을 한눈에 알 수 있을 것이다. 그렇지만 실제로는 전송 제어 프로토콜(TCP, Transmission Control Protocol)의 TIME_WAIT 상태 때문에 아주 좋은 성능을 낼 수는 없다. 전송 제어 프로토콜의 TIME_WAIT는 보통 2분이다. 그런데 접속자가 아주 많은 웹 사이트는 2분 동안에 몇천 개의 접속을 처리해야 할 경우가 있다. 서버 A는 서버 B보다 처리용량이 두 배일 경우 서버 A는 수천 개의 요청을 처리하고 전송 제어 프로토콜의 TIME_WAIT 상황에 직면하게 된다. 그렇지만 서버 B는 몇천 개의 요청이 처리되기만을 기다리게 된다. 그래서 최소 접속 스케줄링을 이용할 경우 다양한 처리용량을 지난 서버로 구성되었을 경우 로드밸런싱이 효율적으로 되지 못할 수 있는 것이다.[14]
최소 응답 시간 방식[편집]
최소 응답 시간(Least Response Time Method)은 최소 연결 방법보다 정교한 최소 응답 시간 방법은 서버가 상태 모니터링 요청에 응답하는 데 걸리는 시간에 따라 달라진다. 응답 속도는 서버가 얼마나 적재되어 있는지와 전반적인 예상 사용자 경험을 나타내는 지표다. 일부 로드밸런싱 장치도 각 서버의 활성 연결 수를 고려한다.[3]
최소 대역폭 방식[편집]
최소 대역폭 방식(Least Bandwidth Method)은 비교적 간단한 알고리즘으로, 최소 대역폭 방법은 초당 메가비트(Mbps)로 측정했을 때 현재 가장 적은 양의 트래픽을 제공하는 서버를 찾는다.[3]
최소 패킷 방식[편집]
최소 패킷 방식(Least Packets Method)은 주어진 기간 동안 패킷을 가장 적게 수신한 서비스를 선택한다.[3]
해싱 메소드[편집]
해싱 메소드 방식(Hashing Methods)은 이 범주의 메소드는 수신 패킷의 다양한 데이터의 해시에 기초하여 결정을 내린다. 여기에는 수신 패킷에서 소스/대상 IP 주소, 포트 번호, URL 또는 도메인 이름과 같은 연결 또는 헤더 정보가 포함된다.[3]
사용자 정의 로드 방식[편집]
사용자 정의 로드 방식(Custom Load Method)을 로드밸런서가 간이 망 관리 프로토콜(SNMP, Simple Network Management Protocol)을 통해 개별 서버의 로드를 쿼리할 수 있다. 관리자는 쿼리할 서버의 로드를 CPU 사용량, 메모리 및 응답 시간 등 정의한 후 이들의 요청에 맞게 이들 로드를 결합할 수 있다.[3]
대처 방법[편집]
- 스케일 업
- 스케일 업(Scale up)은 서버 자체를 증강하는 것에 의해서 처리 능력을 향상하는 것이다. 수직 스케일로 불리기도 한다. 전형적으로는 대칭형 멀티 프로세서(SMP)에 대해 프로세서를 추가하는 것이나 프로세서 그 자체를 고성능 모델로 옮겨놓는 것을 가리킨다. 애플리케이션 서버에서는 스케일 아웃이 가능해도 빈번히 갱신이 발생하여 정합성 유지가 어려운 데이터베이스 서버에서는 스케일 업이 필요하다. 하나의 이미지 데이터베이스에 대해서 빈번히 갱신이 발생하는, 온라인 트랜잭션 처리(OLTP)에는 스케일 업이 적합하다.[15]
- 스케일 아웃
- 스케일 아웃(Scale out)은 접속된 서버의 대수를 늘려 처리 능력을 향상하는 것이다. 수평 스케일로 불리기도 한다. 전형적으로 웹 서버 펌으로서 사용되고 있는 랙 마운트 서버군에 서버를 추가하는 것이나 브레이드 서버에 브레이드를 추가하는 것 등이다. 서버의 가상화 기능을 사용하고 하나의 케이스 내에서 가상적으로 복수 서버를 구축해 스케일 아웃과 동등의 효과를 제공할 수도 있다. 개개의 처리는 비교적 단순하지만, 다수의 처리를 동시 병행적으로 실시하지 않으면 안 되는 경우에 적합한데 갱신 데이터의 정합성 유지에 대한 요건이 별로 어렵지 않은 경우에 적절하다. 높은 병렬성을 실현하기 쉬운 경우이다. 웹 서버 펌, 데이터가 읽기 전용인 검색엔진, 데이터 분석 처리 VOD 일부의 과학기술 계산, 메일 서버나 게시판 등의 애플리케이션 등에 적용할 수 있다.[15]
각주[편집]
- ↑ 〈What Is Load Balancing?〉, 《nginx》
- ↑ 부하분산 위키백과 - https://ko.wikipedia.org/wiki/%EB%B6%80%ED%95%98%EB%B6%84%EC%82%B0
- ↑ 3.0 3.1 3.2 3.3 3.4 3.5 〈What is load balancing?〉, 《시트릭스》
- ↑ JehongLee, 〈Load Balancing〉, 《incodom》, 2016-03-30
- ↑ goodGid, 〈로드 밸런싱과 클러스터링〉, 《깃허브》, 2018-09-03
- ↑ Margaret Rouse, 〈load balancing〉, 《techtarget》
- ↑ 개발자 EricJeong, 〈로드밸런서의 종류와 동작방식〉, 《티스토리》, 2020-03-23
- ↑ 8.0 8.1 8.2 8.3 8.4 8.5 8.6 〈What Is Server and Application Load Balancing? Types, Configuration Methods, and Best Tools〉, 《dnsstuff》, 2020-01-06
- ↑ 9.0 9.1 9.2 9.3 2kindsofcs, 〈L2 / L4 / L7 로드 밸런싱〉, 《티스토리》, 2020-05-17
- ↑ 10.0 10.1 가비아, 〈로드밸런서(Load Balancer)의 개념과 특징〉, 《네이버 블로그》, 2019-12-10
- ↑ 11.0 11.1 11.2 11.3 서진우, 〈실무 관리자를 위한 Linux Enterprise Server ( Load Balancing cluster )〉, 《클루닉스》
- ↑ 12.0 12.1 12.2 박상수, 〈로드밸런서란?(L4, L7)〉, 《미디엄》, 2018-12-07
- ↑ 13.0 13.1 멍개, 〈(서버) 부하분산 방식〉, 《네이버 블로그》, 2015-11-21
- ↑ 14.0 14.1 〈가상 서버 스케줄링 알고리즘〉, 《이글루스》
- ↑ 15.0 15.1 islove8587, 〈스케일 아웃(Scale out)과 스케일 업(Scale up)〉, 《네이버 블로그》, 2015-11-24
참고자료[편집]
- 부하분산 위키백과 - https://ko.wikipedia.org/wiki/%EB%B6%80%ED%95%98%EB%B6%84%EC%82%B0
- 〈가상 서버 스케줄링 알고리즘〉, 《이글루스》
- 〈What is load balancing?〉, 《시트릭스》
- 〈load balancing〉, 《techtarget》
- 〈What Is Load Balancing?〉, 《nginx》
- 멍개, 〈(서버) 부하분산 방식〉, 《네이버 블로그》, 2015-11-21
- islove8587, 〈스케일 아웃(Scale out)과 스케일 업(Scale up)〉, 《네이버 블로그》, 2015-11-24
- JehongLee, 〈Load Balancing〉, 《incodom》, 2016-03-30
- goodGid, 〈로드 밸런싱과 클러스터링〉, 《깃허브》, 2018-09-03
- 박상수, 〈로드밸런서란?(L4, L7)〉, 《미디엄》, 2018-12-07
- 가비아, 〈로드밸런서(Load Balancer)의 개념과 특징〉, 《네이버 블로그》, 2019-12-10
- 〈What Is Server and Application Load Balancing? Types, Configuration Methods, and Best Tools〉, 《dnsstuff》, 2020-01-06
- 개발자 EricJeong, 〈로드밸런서의 종류와 동작방식〉, 《티스토리》, 2020-03-23
- 2kindsofcs, 〈L2 / L4 / L7 로드 밸런싱〉, 《티스토리》, 2020-05-17
같이 보기[편집]
