[공통]Load balancer 로드 밸런서

로드 밸런서는 어떤 CSP를 사용하던지 대부분 기능을 제공해준다.

 

그냥 쉽게만 바로 본다면

 

부하를 분산하자!!

 

만약 네이버 홈페이지가 1개의 서버에서 운영된다고 가정해보자.

 

아무리 scale up 한다 해도 그 한개의 서버는 국내/외에 있는 네이버 사용자를 수용하기엔 턱없이 부족하다.

 

그리고 만약 그 한개의 서버가 고장난다면? 그 즉시 네이버 홈페이지를 사용할 수 없게 된다.

 

이러한 SPOF(단일 장애 지점)을 해결하기 위해 1개가 아닌 여러개의 서버를 두고 홈페이지를 운영한다.

 

naver.com 이라는 도메인을 좀더 알아보자

 

% dig www.naver.com|grep naver

; <<>> DiG 9.10.6 <<>> www.naver.com

;www.naver.com. IN A

www.naver.com. 21320 IN CNAME www.naver.com.nheos.com.

www.naver.com.nheos.com. 149 IN A 223.130.195.95

www.naver.com.nheos.com. 149 IN A 223.130.200.104

 

1개의 CNAME과 2개의 A 레코드가 나온다. 

 

그냥 단순하게 만 본다면 크롬 브라우저에서 www.naver.com 를 입력해서 들어가면 2개의 웹서버 중에 하나의 서버가 나의 요청에 응대를 해준다.

 

그런데 말입니다. 앞서 말한 것 처럼 과연 2대의 서버로 네이버 홈페이지를 처리하는 걸까? 

(좀더 엄밀히 말하면 네이버는 각 서비스 마다 사용하는 A 레코드들이 모두 다르다, 단지 위의 예는 www 에 대해서고, mail이나, cafe 등은 또 다른 서버이며 www가 아닌 별도의(mail,cafe,etc) 서비스 인 것이다)

 

2대는 1대에 비해 분명 좋다. 그런데 국내외를 처리하기에는 아주 많이 부족하다.

 

내가 네이버를 구축한 엔지니어는 아니지만, 이럴 때 사용하는 것이 바로 Load balancer[로드 밸런서] 이다.

 

load 라는 뜻은 리눅스의 top 에서 cpu load 를 확인할 수 있는 것 처럼 무엇인가가 처리해야 할 때 처리해야하는 일들을 의미한다.

 

아래는 리눅스의 top 명령어 첫재쭐 오른쪽에 cpu 의 사용하는 평균 값(1분,5분,15분)

load average: 0.56, 1.08, 1.27

 

뭐 어쨌든 이러한 로드가 너무 높다면 처리하는데 버겁다는 것을 의미한다.

 

이렇게 버거워하는 서비스를 분산 시켜 로드를 균형(balance) 있게 맞춰준다면 사용자도 속이 후련하고 인프라 담당자도 속이 시원하게 된다.

 

만약에라도 하나의 웹 서버가 죽는다 하더라도, 죽은 서버로 패킷을 보내지 않고 살아 있는 서버들에게 잘 전달한다면, 사용자는 서비스를 연속성 있게 사용할 수 있게 된다.

 

이러한 기능을 로드 밸런서가 해주고 있다.

 

Legacy 시스템에서는 이를 물리적인 장비에서 처리해 왔다.

 

뭐 물론 물리적인 장비의 스펙에 영향을 받지만, 꽤 좋은 성능을 보장해준다.

 

그런데 이러한 물리적 장비를 제대로 사용하려면 네트워크의 L4의 개념부터, 명령어 또는 인터페이스, 관리 등등에 대해서 별도로 공부를 해야 한다.

 

이러한 물리 로드밸런서가 클라우드 라는 환경에서는 소프트웨어 적(SDN)으로 처리가 되는 것 같다.(뇌피셜)

 

물리적인 네트워크를 구매하고 관리하고 운영하는 수고를 네트워크 가상화(SDN)를 통해 처리하고 클라우드 서비스의 하나로서 제공받게 된다면, 사용자 입장에서는 로드 밸런서를 운영하고 관리하는 수고를 덜게 된다.

 

그냥 사용자는 부하 분산이 필요해, 내게 적당한 방식을 찾아서 선택해주면 쉽고 빠르게 적용할 수 있게 된다.

 

그래서 클라우드에서 우리가 로드 밸런서에 대해서 알게 될때에는 단지 어떻게 분산 시킬꺼야? 라는 개념만 알아도 어렵지 않게 사용할 수 있다.

(물론 SSL offloading 이라던가, SSL 인증서 라던가 등에 대해서도 알아야 겠지만, 그건 부하를 분산 시키자는 원초적인 기능은 아니다)

 

CSP 마다 조금씩 다를 수 있겠지만 대표적인 부하분산 방법으로는

 

Round Robin - 순차적으로 분산한다.(가장 대표적이다.) 서버가 1~10개 있고 10번의 요청을 보냈다면, 1~10까지 모두 한번씩 접근된다

IP hash - 그냥 쉽게 말해 나와 서버간에 연결되는 IP 정보를 토대로 hash 값을 만들고, 그 hash 값에 맞는 서버에 접근한다. (이렇게 되면 동일 IP는 기존에 접근했던 동일 서버에 접근하게 된다. 서버가 1~10개 있고 10번의 요청을 보냈는데 2번의 서버에 이 방법으로 접근했다면 10번 모두 2번에 접근한다)

least connection - 가장 부하가 적은 서버로 접근한다. 서버가 1~10개 있고 10번의 요청을 보냈는데, 다른 요인의 요청으로 인해 서버 1,2,3 이 부하가 증가 했다면, 10번의 요청은 부하가 적은 4~10 중에 부하가 적은 곳으로 연결된다, 그런데 이 알고리즘은 그냥 평소에 정상적으로 잘 사용될 때에는 잘 모르는데, 만약 1~10 서버가 50%의 부하를 모두 갖고 있어서, 골고루 서버들에게 일정한 양으로 분산이 될텐데, 갑자기 5번 서버가 어떤 요인으로 꺼졌다가 켜졌다고 가정해보자, 그러면 이 5번 서버는 켜지는 순간 부하가 0%일테니, 모든 요청들이 5번으로 한꺼번에 몰리게 된다. 이때 순간적으로 발생하는 로드를 처리하느라고, 5번 서버로 접속하는 성능이 저하되는 문제가 있을 수 있다.

 

뭐 어쨌든 기타 더 있겠지만 그렇게 큰 의미는 없을 것 같고, 부하를 분산처리하는 방법 말고도, L4 에서 자신이 관리하는 서버들이 잘 살아 있는지 죽어있는지를 확인하는 것을 헬스체크(health check)라고 한다. 

 

이 헬스체크를 통해서 죽은 서버로는 패킷을 보내지 않고 정상 서버로만 패킷을 분산하는 똑똑한 기능이 있다.