해시넷
로드밸런싱 편집하기
편집을 되돌릴 수 있습니다.
이 편집을 되돌리려면 아래의 바뀐 내용을 확인한 후 저장해주세요.
| 최신판 | 당신의 편집 | ||
| 1번째 줄: | 1번째 줄: | ||
| − | '''로드밸런싱'''(Load Balancing) | + | '''로드밸런싱'''(Load Balancing)이란 [[컴퓨터]] [[네트워크]] 기술의 일종으로 둘 혹은 셋 이상의 [[중앙처리장치]] 혹은 [[저장장치]]와 같은 컴퓨터 자원들에 작업을 나누는 것을 의미한다. 이로써 [[가용성]] 및 응답시간을 최적화시킬 수 있다. 예를 들어, [[메인프레임]] 1대(단일 구성체)보다 IA-32와 같은 일반적인 서버(복합 구성체)가 안정성 면에서 유리한 위치에 있다. 로드밸런싱 서비스는 그에 적합한 [[하드웨어]]와 [[소프트웨어]]에 의해 제공된다. 이 기술은 보통 내부 네트워크를 이용한 병렬처리(특히, 고가용성의 병렬처리)에 사용된다. 부하 분산이라고도 한다. |
== 개요 == | == 개요 == | ||
| − | |||
| − | |||
로드밸런싱을 위한 대부분의 응용 프로그램은 다수의 서버를 가지고 한 가지 종류의 인터넷 서비스를 지원하는 방식이다. 보통 로드밸런싱은 트래픽이 많은 웹 사이트, 인터넷 릴레이 챗(IRC, Internet Relay Chat) 네트워크, [[파일 전송 프로토콜]](FTP, File Transfer Protocol) 사이트, 네트워크 뉴스 전송 프로토콜(NNTP, Network News Transfer Protocol) 서버 그리고 [[DNS]] 서버에 적용이 되고 있다. 인터넷 서비스를 위해서는 소프트웨어를 이용한 로드밸런싱이 적용되며, 이 소프트웨어는 중간에 위치에 실제 서비스하는 서버와 클라이언트를 포트를 이용해 중개하고 있다. 그러나 사용자는 이를 알아차리지 못한다. 이를 투명성이라 한다. 또한, 보안이라는 측면에서 내부 네트워크 구조를 숨김으로써 [[크래킹]]을 막을 수 있다. 일부 로드밸런싱 소프트웨어는 실 서비스 서버들을 관리하는 역할을 수행하기도 한다. 로드밸런싱의 다른 방식으로는 라운드 로빈 DNS 라고 하는 특별한 하드웨어 및 소프트웨어가 필요가 없는 방식이 있다. 이 방식에서는 여러 개의 IP주소를 동일한 도메인 네임에 연관 지어 놓고 클라이언트들이 어떤 서버를 사용할 것인지 결정하게 하는 방식이다. 일반적인 로드밸런싱과는 다르게 "투명성"이 존재하지 않는다. 이미 내부의 서버들의 주소가 이미 노출되어 있기 때문이다. 이 방식은 DNS 서버에 대한 의존도가 높고 로드밸런싱이 원하는 대로 될 수 있다는 것이다.<ref name="부하분산 위키백과">부하분산 위키백과 - https://ko.wikipedia.org/wiki/%EB%B6%80%ED%95%98%EB%B6%84%EC%82%B0</ref> | 로드밸런싱을 위한 대부분의 응용 프로그램은 다수의 서버를 가지고 한 가지 종류의 인터넷 서비스를 지원하는 방식이다. 보통 로드밸런싱은 트래픽이 많은 웹 사이트, 인터넷 릴레이 챗(IRC, Internet Relay Chat) 네트워크, [[파일 전송 프로토콜]](FTP, File Transfer Protocol) 사이트, 네트워크 뉴스 전송 프로토콜(NNTP, Network News Transfer Protocol) 서버 그리고 [[DNS]] 서버에 적용이 되고 있다. 인터넷 서비스를 위해서는 소프트웨어를 이용한 로드밸런싱이 적용되며, 이 소프트웨어는 중간에 위치에 실제 서비스하는 서버와 클라이언트를 포트를 이용해 중개하고 있다. 그러나 사용자는 이를 알아차리지 못한다. 이를 투명성이라 한다. 또한, 보안이라는 측면에서 내부 네트워크 구조를 숨김으로써 [[크래킹]]을 막을 수 있다. 일부 로드밸런싱 소프트웨어는 실 서비스 서버들을 관리하는 역할을 수행하기도 한다. 로드밸런싱의 다른 방식으로는 라운드 로빈 DNS 라고 하는 특별한 하드웨어 및 소프트웨어가 필요가 없는 방식이 있다. 이 방식에서는 여러 개의 IP주소를 동일한 도메인 네임에 연관 지어 놓고 클라이언트들이 어떤 서버를 사용할 것인지 결정하게 하는 방식이다. 일반적인 로드밸런싱과는 다르게 "투명성"이 존재하지 않는다. 이미 내부의 서버들의 주소가 이미 노출되어 있기 때문이다. 이 방식은 DNS 서버에 대한 의존도가 높고 로드밸런싱이 원하는 대로 될 수 있다는 것이다.<ref name="부하분산 위키백과">부하분산 위키백과 - https://ko.wikipedia.org/wiki/%EB%B6%80%ED%95%98%EB%B6%84%EC%82%B0</ref> | ||
| − | == | + | == 특징 == |
| − | + | 로드밸런싱이란 들어오는 네트워크 트래픽을 서버 팜 또는 서버 풀이라고도 하는 [[백엔드]] 서버 그룹에 효율적으로 분산시키는 것을 말한다. 현대의 높은 트래픽의 웹사이트는 사용자나 클라이언트의 동시 요청 수십만 개(수백만 개는 아니더라도)를 처리하고 정확한 텍스트, 이미지, 비디오 또는 응용 프로그램 데이터를 빠르고 신뢰할 방법으로 반환해야 한다. 이러한 대용량을 충족하기 위해 비용 효율적으로 확장하려면 일반적으로 현대적인 컴퓨팅 모범 사례에 서버를 추가해야 한다. 부하 분산 장치는 속도 및 용량 활용도를 극대화하고 어느 서버도 과로하지 않도록 보장하여 성능을 저하할 수 있는 방식으로 서버 앞에 앉아 클라이언트 요청을 모든 서버에 라우팅하는 "트래픽 경찰" 역할을 한다. 단일 서버가 다운되면 로드밸런서는 트래픽을 나머지 온라인 서버로 리디렉션한다. 서버 그룹에 새 서버를 추가하면 로드밸런서가 자동으로 요청 전송을 시작한다. 이러한 방식으로 로드밸런서는 클라이언트 요청 또는 네트워크 로드를 여러 서버에 효율적으로 분산하고, 온라인 상태의 서버에만 요청을 전송하여 고가용성 및 안정성을 보장하고, 요구 사항에 따라 서버를 추가하거나 제거할 수 있는 유연성을 제공한다.<ref name="nginx"> 〈[https://www.nginx.com/resources/glossary/load-balancing/ What Is Load Balancing?]〉, 《nginx》</ref> | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | 로드밸런싱 기능이 있는 ADC는 IT 부서가 서비스의 확장성과 가용성을 보장하는 데 도움이 된다. 그것의 고급 트래픽 관리 기능은 사업체가 각 최종 사용자를 위한 정확한 자원으로 보다 효율적으로 요청하도록 도울 수 있다. ADC는 환경 전체에 걸쳐 수많은 애플리케이션과 서비스를 보안, 관리 및 모니터링하고 최상의 최종 사용자 환경을 보장하기 위한 단일 제어 지점을 제공할 수 있는 다른 많은 기능(예: 암호화, 인증 및 웹 애플리케이션 방화벽)을 제공한다.<ref name="시트릭스"> 〈[https://www.citrix.com/ko-kr/glossary/load-balancing.html What is load balancing?]〉, 《시트릭스》</ref> | |
| − | |||
| − | === | + | === 작동 방식 === |
| − | + | 로드밸런서는 정보 및 기타 서비스에 대한 사용자의 들어오는 요청을 처리한다. 그들은 그 요청을 처리하는 서버와 인터넷 사이에 앉아있다. 요청이 수신되면 로드밸런서는 먼저 풀에서 사용할 수 있는 온라인 서버를 확인한 다음 해당 서버로 요청을 라우트한다. 부하가 많은 시간 동안 로드밸런서는 트래픽 급증에 대응하여 서버를 동적으로 추가할 수 있다. 반대로 수요가 적으면 서버를 떨어뜨릴 수 있다. 로드밸런서는 물리적 어플라이언스, 소프트웨어 인스턴스 또는 둘 모두의 조합일 수 있다. 전통적으로 벤더는 전용 하드웨어에 독점 소프트웨어를 탑재하여 사용자에게 독립 실행형 어플라이언스(대개 쌍으로 구성)로 판매하여, 한 제품이 고장 나면 페일 오버를 제공한다. 네트워크가 성장하려면 추가 및/또는 더 큰 가전제품을 구매해야 한다. 이와는 대조적으로 소프트웨어 로드밸런싱은 가상 머신(VM) 또는 화이트 박스 서버에서 실행되며, 애플리케이션 제공 컨트롤러(ADC)의 기능으로 실행될 가능성이 크다. ADC는 일반적으로 캐싱, 압축, 트래픽 쉐이핑 등과 같은 추가 기능을 제공한다. 클라우드 환경에서 인기 있는 가상 로드밸런싱은 높은 수준의 유연성을 제공할 수 있다. 예를 들어, 사용자가 트래픽 급증 또는 네트워크 활동 감소를 미러링하기 위해 자동으로 스케일업 또는 스케일다운할 수 있다.<ref name="Margaret Rouse"> Margaret Rouse, 〈[https://searchnetworking.techtarget.com/definition/load-balancing load balancing]〉, 《techtarget》</ref> | |
== 기능 == | == 기능 == | ||
| 40번째 줄: | 16번째 줄: | ||
=== 네트워크 주소 변환 === | === 네트워크 주소 변환 === | ||
| − | 네트워크 주소 변환(NAT, Network Address Translation)은 사설 IP 주소를 공인 IP 주소로 변경, 주소변경의 역할을 한다.<ref name="박상수"> 박상수, 〈[https://medium.com/@pakss328/%EB%A1%9C%EB%93%9C%EB%B0%B8%EB%9F%B0%EC%84%9C%EB%9E%80-l4-l7-501fd904cf05 로드밸런서란?(L4, L7)]〉, 《미디엄》, 2018-12-07</ref> IPv4 에서 IP 주소가 부족하고 보안상에 몇가지 문제가 있어서 인터넷에서 사용할 수 없는 사설 | + | 네트워크 주소 변환(NAT, Network Address Translation)은 사설 IP 주소를 공인 IP 주소로 변경, 주소변경의 역할을 한다.<ref name="박상수"> 박상수, 〈[https://medium.com/@pakss328/%EB%A1%9C%EB%93%9C%EB%B0%B8%EB%9F%B0%EC%84%9C%EB%9E%80-l4-l7-501fd904cf05 로드밸런서란?(L4, L7)]〉, 《미디엄》, 2018-12-07</ref> IPv4 에서 IP 주소가 부족하고 보안상에 몇가지 문제가 있어서 인터넷에서 사용할 수 없는 사설 IP(10.0.0.0/255.0.0.0 , 172.16.0.0/255.240.0.0 , 192.168.0.0 /255.255.0.0)를 사용하는 경우가 많아지고 있다. 이때 인터넷 망에서 사설망의 호스트에 접근하기 위해서 네트워크 주소 변환 기능이 필요하게 된다.<ref name="서진우"></ref> |
=== 동적 소스 라우팅 프로토콜 === | === 동적 소스 라우팅 프로토콜 === | ||
| − | 동적 소스 라우팅 프로토콜(DSR, Dynamic Source Routing protocol)은 서버에서 클라이언트로 되돌아가는 경우 목적지 주소를 스위치의 IP 주소가 아닌 클라이언트의 IP 주소로 전달해서 네트워크 스위치를 거치지 않고 바로 클라이언트를 찾아가는 개념이다.<ref name="박상수"></ref> 실제 서버와 부하 분산 서버 사이에서 가상 IP 를 공유하는 방식으로 부하 분산 서버와 실제 작업 서버에 모두 동일한 가상 IP 를 가지도록 네트워크 구성해야 한다. 가상 IP 가 설정된 인터페이스를 통해 사용자의 요청을 받아들여 이 요청이 가상 서버 정책에 적용되는 요청인지를 확인 후 적용되는 패킷이면 정책에 따라 실제 작업 서버로 패킷을 포워딩하게 된다. 이때 실제 서버 역시 별도의 Arp 캐싱을 남기지 않는 에일리어스(Alias) 인터페이스를 통해 로드밸런싱 서버로부터 포워딩되는 패킷을 받아 들이게 된다. 만일 가상 IP 가 설정된 인터페이스에 arp 캐싱이 남는다고 하면 사용자가 부하 분산 서버를 통해 초기에 연결된 실제 작업와 연결되면 그 이후부터는 초기 접속한 작업 서버와만 통신이 이루어 지게 된다. 그렇기 때문에 반드시 커널 차원에서의 arp 히든 패치(hidden patch)를 시켜줘야 한다. | + | 동적 소스 라우팅 프로토콜(DSR, Dynamic Source Routing protocol)은 서버에서 클라이언트로 되돌아가는 경우 목적지 주소를 스위치의 IP 주소가 아닌 클라이언트의 IP 주소로 전달해서 네트워크 스위치를 거치지 않고 바로 클라이언트를 찾아가는 개념이다.<ref name="박상수"></ref> 실제 서버와 부하 분산 서버 사이에서 가상 IP 를 공유하는 방식으로 부하 분산 서버와 실제 작업 서버에 모두 동일한 가상 IP 를 가지도록 네트워크 구성해야 한다. 가상 IP 가 설정된 인터페이스를 통해 사용자의 요청을 받아들여 이 요청이 가상 서버 정책에 적용되는 요청인지를 확인 후 적용되는 패킷이면 정책에 따라 실제 작업 서버로 패킷을 포워딩하게 된다. 이때 실제 서버 역시 별도의 Arp 캐싱을 남기지 않는 에일리어스(Alias) 인터페이스를 통해 로드밸런싱 서버로부터 포워딩되는 패킷을 받아 들이게 된다. 만일 가상 IP 가 설정된 인터페이스에 arp 캐싱이 남는다고 하면 사용자가 부하 분산 서버를 통해 초기에 연결된 실제 작업와 연결되면 그 이후부터는 초기 접속한 작업 서버와만 통신이 이루어 지게 된다. 그렇기 때문에 반드시 커널 차원에서의 arp 히든 패치(hidden patch)를 시켜줘야 한다. DR 방식은 패킷의 데이터 프레임 부분의 MAC 주소만을 변경하여 패킷을 포워딩 하기 때문에 물리적인 세크먼트(같은 subnet)안에서만 동작이 가능하다.<ref name="서진우"></ref> |
=== 터널링 === | === 터널링 === | ||
| − | 터널링(Tunneling)은 인터넷상에서 눈에 보이지 않는 통로를 만들어 통신할 수 있게 하는 개념이다. 데이터를 캡슐화해서 연결된 상호 간에만 캡슐화된 패킷을 구별해 캡슐화를 해제할 수 있다.<ref name="박상수"></ref> IP 터너링은 IP화된 정보(IP 데이터그램) 안에 IP화된 정보를 감싸 넣는(encapsulate) 기술이다. 이를 이용하여 보다 왠(WAN)을 대상으로 작업 서버 노드를 구성할 수 있게 된다. 실제 가상 IP 주소로 향하는 요구 패킷이 로드밸런싱 서버로 전달 되면 로드밸런싱 서버에서 패킷의 목적지 주소와 포트를 검사하여 가상 서버 정책과 일치 하면 스케줄링에 따라 실제 작업 서버로 전달하게 된다. 이때 패킷을 일반적인 스트림(Stream) 방식으로 전달하는 것이 아닌 캣슐 형식으로 싸서 전달하게 된다. 이리 전달 되면 작업 서버에서는 감싸진 패킷을 다시 풀고 요청을 처리한 다음 실제 서버의 라우팅 테이블에 따라 사용자에게 직접 결과를 돌려주는 방식이다. IP 터너링 방식은 | + | 터널링(Tunneling)은 인터넷상에서 눈에 보이지 않는 통로를 만들어 통신할 수 있게 하는 개념이다. 데이터를 캡슐화해서 연결된 상호 간에만 캡슐화된 패킷을 구별해 캡슐화를 해제할 수 있다.<ref name="박상수"></ref> IP 터너링은 IP화된 정보(IP 데이터그램)안에 IP화된 정보를 감싸 넣는(encapsulate) 기술이다. 이를 이용하여 보다 왠(WAN)을 대상으로 작업 서버 노드를 구성할 수 있게 된다. 실제 가상 IP 주소로 향하는 요구 패킷이 로드밸런싱 서버로 전달 되면 로드밸런싱 서버에서 패킷의 목적지 주소와 포트를 검사하여 가상 서버 정책과 일치 하면 스케줄링에 따라 실제 작업 서버로 전달하게 된다. 이때 패킷을 일반적인 스트림(Stream) 방식으로 전달하는 것이 아닌 캣슐 형식으로 싸서 전달하게 된다. 이리 전달 되면 작업 서버에서는 감싸진 패킷을 다시 풀고 요청을 처리한 다음 실제 서버의 라우팅 테이블에 따라 사용자에게 직접 결과를 돌려주는 방식이다. IP 터너링 방식은 DR 방식의 물리적인 세그먼트의 영향을 받지 않고 어디든지 작업을 분산 할 수 있는 장점이 있다. 그래서 거의 무한한 확장성을 가지게 된다. 하지만 모든 서버가 IP 터널링 전송 규약을 지원해야 하기에 지원하지 못하는 OS 에서는 문제가 발생하게 된다.<ref name="서진우"></ref> |
== 유형 == | == 유형 == | ||
| 89번째 줄: | 65번째 줄: | ||
=== 사용자 정의 로드 방식 === | === 사용자 정의 로드 방식 === | ||
사용자 정의 로드 방식(Custom Load Method)을 로드밸런서가 간이 망 관리 프로토콜(SNMP, Simple Network Management Protocol)을 통해 개별 서버의 로드를 쿼리할 수 있다. 관리자는 쿼리할 서버의 로드를 CPU 사용량, 메모리 및 응답 시간 등 정의한 후 이들의 요청에 맞게 이들 로드를 결합할 수 있다.<ref name="시트릭스"></ref> | 사용자 정의 로드 방식(Custom Load Method)을 로드밸런서가 간이 망 관리 프로토콜(SNMP, Simple Network Management Protocol)을 통해 개별 서버의 로드를 쿼리할 수 있다. 관리자는 쿼리할 서버의 로드를 CPU 사용량, 메모리 및 응답 시간 등 정의한 후 이들의 요청에 맞게 이들 로드를 결합할 수 있다.<ref name="시트릭스"></ref> | ||
| + | |||
| + | == 로드밸런서 == | ||
| + | 로드밸런싱은 두 개 이상의 컴퓨터 자원에 작업을 나누는 것을 의미하며 로드밸런서는 작업을 담당하는 장비를 의미한다. 로드밸런서는 OSI 7계층을 기준으로 어떻게 부하를 분산하는지에 따라 종류가 나뉜다. 2계층을 기준으로 부하를 분산하면 L2, 3계층을 기준으로 부하를 분산한다면 L3인 방식이다. 상위 계층으로 갈수록 섬세한 로드밸런싱이 가능하지만, 가격이 비싸진다. 하위 계층으로 갈수록 간단한 로드밸런싱이 가능하고 가격이 저렴해진다. 사업의 규모가 확장되고, 클라이언트의 수가 늘어나게 되면 기존 서버만으로는 정상적인 서비스가 불가능하게 된다.<ref name="개발자 EricJeong"> 개발자 EricJeong, 〈[https://deveric.tistory.com/91 로드밸런서의 종류와 동작방식]〉, 《티스토리》, 2020-03-23</ref> | ||
| + | |||
| + | * '''하드웨어 로드밸런서''' | ||
| + | :하드웨어 로드밸런서는 이름에서 알 수 있듯이 애플리케이션과 네트워크 트래픽을 분산하기 위해 물리적 사내 하드웨어에 의존한다. 이 장치들은 많은 양의 트래픽을 처리할 수 있지만 종종 많은 가격표를 가지고 있으며 유연성의 측면에서 상당히 제한적이다.<ref name="dnsstuff"></ref> | ||
| + | |||
| + | * '''소프트웨어 로드밸런서''' | ||
| + | :소프트웨어 로드밸런서는 상용 또는 오픈 소스라는 두 가지 형태로 제공되며 사용하기 전에 설치해야 한다. 클라우드 기반 밸런서와 마찬가지로 하드웨어 솔루션보다 가격이 저렴한 경향이 있다.<ref name="dnsstuff"></ref> | ||
| + | |||
| + | * '''가상 로드밸런서''' | ||
| + | :가상 로드밸런서는 하드웨어 로드밸런싱 장치의 소프트웨어를 가상 시스템에 배포하기 때문에 소프트웨어 로드밸런서와는 다르다.<ref name="dnsstuff"></ref> | ||
| + | |||
| + | === 종류 === | ||
| + | 로드밸런서는 L2, L3, L4, L7으로 나뉠 수 있다. 로드밸런싱에는 L4 로드밸런서와 L7 로드밸런서가 가장 많이 활용된다. 그 이유는 L4 로드밸런서부터 포트 정보를 바탕으로 로드를 분산하는 것이 가능하기 때문이다. 한 대의 서버에 각기 다른 포트 번호를 부여하여 다수의 서버 프로그램을 운영하는 경우라면 최소 L4 로드밸런서 이상을 사용해야만 한다. 스위치라는 용어도 많이 쓴다. | ||
| + | |||
| + | ==== L2 로드밸런싱 ==== | ||
| + | 데이터 링크 계층(L2)에서 정의된 정보를 바탕으로 로드밸런싱을 하는 것이다. [[맥주소]](MAC, Media Access Control Address)를 이용하여 전달할 서버를 결정한다.L4, l7 로드밸런서 대비 로드밸런싱 전략이 제한적이다. L2DSR 전략에서 로드밸런서는 inbound 패킷의 맥주소를 서버의 맥주소로 변환한 뒤 서버에게 전달한다. 이 전략을 사용하기 위해서는 로드밸런서와 서버가 반드시 같은 네트워크에 속해야 한다. 로드밸런서가 알 수 있는 게 맥 주소밖에 없는데, 패킷의 MAC 주소를 서버의 MAC 주소로 변경을 했을 때 이 패킷이 바로 서버로 가야 한다. IP는 그대로인데 MAC 주소만 바꿔서 서버에 도달해야 하는데, 이를 위해서 서버와 로드밸런서 모두 VIP가 설정되어야 하는 등 이런저런 제약이 있다.<ref name="2kindsofcs"> 2kindsofcs, 〈[https://2kindsofcs.tistory.com/56 L2 / L4 / L7 로드 밸런싱]〉, 《티스토리》, 2020-05-17</ref> | ||
| + | |||
| + | ==== L3 로드밸런싱 ==== | ||
| + | 네트워크 계층(L3)에서 정의된 정보를 바탕으로 로드밸런싱을 하는 것이다. 포트 간 패킷 스위칭을 위해 IP 나 IPX 주소를 기반으로 스위칭한다. 특정 프로토콜을 사용하는 패킷에 대해 스위칭이 가능하다. L2에 라우팅 기능이 추가된 것이다. 라우터가 있다. Broadcast 트래픽으로 전체 성능 저하를 막을 수 있다. 트래픽 체크, 가상 랜 등의 많은 부가 기능을 제공한다. 특정 프로토콜을 이용해야 스위칭할 수 있다.<ref name="2kindsofcs"></ref> | ||
| + | |||
| + | ==== L4 로드밸런싱 ==== | ||
| + | 전송 계층(L4)의 정보를 바탕으로 부하를 분산한다. IP 주소와 포트 번호를 이용한다. L3의 정보도 활용하니까 정확히는 L3 and L4 로드 밸런싱이 맞겠지만, n번 레이어를 활용한다는 것은 n-1 이하의 레이어들도 활용할 수 있다는 것이며 통상 L4 로드밸런싱이라 불린다. L4 로드밸런서는 패킷 헤더의 소스 IP 와 destination IP를 네트워크 주소 변환을 통해 바꿔서 서버에게 전달한다. 반대로 클라이언트로 패킷이 갈 때도 소스 IP 와 destination IP를 바꿔서 클라이언트에게 잘 전달되도록 한다. L2보다는 비용이 더 비싸지만 IP 와 포트 번호를 활용하여 상대적으로 더 섬세한 라우팅이 가능하다. 내용물을 보지 않기 때문에 TLS termination이 없다.<ref name="2kindsofcs"></ref> | ||
| + | |||
| + | ==== L7 로드밸런싱 ==== | ||
| + | 응용계층(L7)의 정보를 바탕으로 부하를 분산한다. TLS termination이 일어난다. 소프트웨어적인 로드밸런싱이 필요하다. L2, L4 로드 밸런싱은 물리적 단계에서 충분하지만, L7은 소프트웨어를 사용해야 하므로 비용이 더 비싸다. 가장 섬세한 라우팅이 가능하다. HTTP 헤더, 쿠키 등과 같은 사용자의 요청을 기준으로 특정 서버에 트래픽을 분산하는 것이 가능하다. 쉽게 말해 패킷의 내용을 확인하고 그 내용에 따라 로드를 특정 서버에 분배하는 것이 가능한 것이다. URL에 따라 부하를 분산시키거나, HTTP 헤더의 쿠키값에 따라 부하를 분산하는 등 클라이언트의 요청을 보다 세분화해 서버에 전달할 수 있다. 또한 L7 로드밸런서의 경우 특정한 패턴을 지닌 바이러스를 감지해 네트워크를 보호할 수 있으며, DoS/DDoS와 같은 비정상적인 트래픽을 필터링할 수 있어 네트워크 보안 분야에서도 활용되고 있다.<ref name="2kindsofcs"></ref><ref name="가비아"></ref> | ||
=== 대처 방법 === | === 대처 방법 === | ||
| 97번째 줄: | 100번째 줄: | ||
* '''스케일 아웃''' | * '''스케일 아웃''' | ||
:스케일 아웃(Scale out)은 접속된 서버의 대수를 늘려 처리 능력을 향상하는 것이다. 수평 스케일로 불리기도 한다. 전형적으로 웹 서버 펌으로서 사용되고 있는 랙 마운트 서버군에 서버를 추가하는 것이나 브레이드 서버에 브레이드를 추가하는 것 등이다. 서버의 가상화 기능을 사용하고 하나의 케이스 내에서 가상적으로 복수 서버를 구축해 스케일 아웃과 동등의 효과를 제공할 수도 있다. 개개의 처리는 비교적 단순하지만, 다수의 처리를 동시 병행적으로 실시하지 않으면 안 되는 경우에 적합한데 갱신 데이터의 정합성 유지에 대한 요건이 별로 어렵지 않은 경우에 적절하다. 높은 병렬성을 실현하기 쉬운 경우이다. 웹 서버 펌, 데이터가 읽기 전용인 검색엔진, 데이터 분석 처리 VOD 일부의 과학기술 계산, 메일 서버나 게시판 등의 애플리케이션 등에 적용할 수 있다.<ref name="islove8587"></ref> | :스케일 아웃(Scale out)은 접속된 서버의 대수를 늘려 처리 능력을 향상하는 것이다. 수평 스케일로 불리기도 한다. 전형적으로 웹 서버 펌으로서 사용되고 있는 랙 마운트 서버군에 서버를 추가하는 것이나 브레이드 서버에 브레이드를 추가하는 것 등이다. 서버의 가상화 기능을 사용하고 하나의 케이스 내에서 가상적으로 복수 서버를 구축해 스케일 아웃과 동등의 효과를 제공할 수도 있다. 개개의 처리는 비교적 단순하지만, 다수의 처리를 동시 병행적으로 실시하지 않으면 안 되는 경우에 적합한데 갱신 데이터의 정합성 유지에 대한 요건이 별로 어렵지 않은 경우에 적절하다. 높은 병렬성을 실현하기 쉬운 경우이다. 웹 서버 펌, 데이터가 읽기 전용인 검색엔진, 데이터 분석 처리 VOD 일부의 과학기술 계산, 메일 서버나 게시판 등의 애플리케이션 등에 적용할 수 있다.<ref name="islove8587"></ref> | ||
| + | |||
| + | == 장단점 == | ||
| + | 로드밸런싱은 고가의 서버로 확장하지 않고 저렴한 비용에 다수의 서버로 증설하여 경제적으로 비용 절감을 할 수 있다. 대량의 트래픽으로 1대의 서버로 집중적인 부하율이 높아지면 L4 스위치가 이를 감지하여 합리적으로 로드밸런싱을 처리 할 수 있다. 1대의 서버 장애가 발생하여도 서비스 중단없이 다른 서버로 적절히 자동으로 분배하여 서비스가 계속 운용 가능하게 할 수 있다. 추후 사용량이 많아 서버 확장으로 서비스 중단없이 서버 증설이 가능하다. 단점으로 로드밸런서를 사용할 때 어려운 문제 중 하나가 세션 데이터를 관리하는 것이다. 클라이언트의 연결 정보를 저장하는 세션이 로드밸런싱을 통해 하나의 서버 장비에 저장이 되는 경우, 추후 다른 서버로 접속하게 되면, 해당 클라이언트의 세션이 유지되지 않는다는 것이다. 서버에 액세스할 때마다 다른 세션을 사용한다면 특정 사용자의 정보를 일관성 있게 유지할 수 없게 된다. 이러한 문제를 해결하기 위해 세션을 고정한다. 이 방법으로 특정 사용자의 요청이 전달될 노드를 고정할 수 있지만 고정된 세션의 노드에 장애가 발생하면 고정한 의미가 없어진다. 장애가 발생하여 비활성화된 노드에 대한 고려가 필요하다.<ref name="JehongLee"> JehongLee, 〈[http://www.incodom.kr/Load_Balancing Load Balancing]〉, 《incodom》, 2016-03-30</ref><ref name="goodGid"> goodGid, 〈[https://goodgid.github.io/Load-Balancing-And-Clustering/ 로드 밸런싱과 클러스터링]〉, 《깃허브》, 2018-09-03</ref> | ||
{{각주}} | {{각주}} | ||
