티스토리 뷰

우리는 데이터 속에 살고 있다해도 과언이 아닐만큼 과거에 비해 다양한 데이터들이 기하급수적으로 늘어났으며, 데이터 하나하나가 기업이나 개인의 모두 소중한 자산 입니다. 우리는 데이터 없인 살 수 없고, 앞으로도 그럴 것입니다.

 

데이터가 방대해지면서 아무리 좋은 서버라고 해도 이를 수용하는데 있어 무리가 있습니다. 그에 따라 규모가 큰 서비스를 제공하는 회사의 경우 여러 대의 서버를 두고 동일한 데이터를 저장하여 수많은 트래픽을 효과적으로 분산합니다.

 

수 많은 트래픽을 여러 대의 서버로 분산해줄 수 있는 기술이 없다면 트래픽은 결국 한대의 서버로 집중 될 것입니다. 그렇게 된다면 서비스 속도가 엄청나게 느려질 것이고 최악의 경우 서버가 마비되어 서비스 자체를 제공할 수 없게 될 것입니다.

 

이러한 경우에 대비하여 여러 대의 서버로 트래픽을 분산 시켜줄 무엇인가가 필요한데 이 기술이 바로 로드 밸런서(Load Balancer)입니다.

 

 

로드밸런서는 서버에 가해지는 부하(=로드)를 분산(=밸런싱) 해주는 장치 또는 기술을 통칭합니다.

 

한 대의 서버에 부하가 집중되지 않도록 트랙픽을 관리해 각각의 서버가 최적을 퍼포먼스를 보여줄수 있도록 도와줍니다.

 


# 그럼 로드밸런서를 언제 필요할까요?

 

스타트업 기업이 서비스를 런칭했다고 해봅시다. 서비스 초창기에는 사용자가 적어 트래픽 관리가 수월하지만 시간이 흘러 규모가 커진다면 기존 서버로 서비스를 제공하기란 상당히 무리가 있을 것입니다. 따라서 기업은 다음 2가지 방법을 고려해 볼 수 있습니다.

 

scale-up과 scale-out입니다. 둘의 차이는 아래 사진을 보시면 확 와닿으실 겁니다.

 

scale-up

 

 

scale-up의 경우 예를 들어 현재 사용하는 컴퓨터가 i3라고 했을 때, i7으로 컴퓨터를 업그레이드 하는 것입니다.

즉, 기존의 서버보다 더 좋은 서버로 교체하는 것입니다. 사실 이때는 분산처리를 할 필요가 없어 로드밸런서가 필요없습니다. 

 

scale-up의 경우 로드밸런싱을 하지 않아도 되므로 어려운 기술을 요구하진 않지만, 비용이 상당히 비쌉니다.

 

scale-out

 

 

scale-out의 경우 현재 i3를 사용한다고 가정했을 때 같은 i3의 컴퓨터를 여러 대 구매해서 분산을 시켜주는 것입니다.

scale-up 과 다르게 로드밸런싱 기술을 요구합니다. 따라서 환경을 구축하기 어려울 수 있으나 비용면에서 scale-up보다 저렴합니다.

 


# 다양한 로드 밸런싱 알고리즘

 

로드 밸런싱에 관한 알고리즘은 다양하며 현재 상황에 맞게 잘 사용하여야 합니다.

라운드 로빈 방식(Round Robin Method)

 

서버에 들어온 요청을 순서대로 돌아가면서 배정해줍니다. 서버와의 연결(세션)이 오래 지속되지 않는 경우에 활용하기 적합합니다.

 

가중 라운드 로빈 방식(Weighted Round Robin Method)

 

각각의 서버마다 가중치를 매기고 가중치가 높은 서버에 클라이언트 요청을 우선적으로 배분합니다. 서버들의 처리능력이 상이할 경우 사용합니다.

 

예를 들어 A서버가 가중치 5, B 서버가 가중치 2라면 로드밸런서는 라운드 로빈 방식으로 A서버에 5개, B 서버에 2개의 요청을 전달합니다.

 

최소 연결 방식(Least Connection Method)

 

요청이 들어온 시점에 가장 적은 연결 상태를 보이는 서버에 우선적으로 트래픽을 배분합니다. 자주 세션이 길어지거나, 서버에 분배된 트래픽들이 일정하지 않은 경우에 적합합니다.

 

최소 리스폰 타임(Least Response Time Method)

 

서버의 현재 연결상태와 응답시간을 모두 고려하여 트랙픽을 분배합니다.

 

더 많은 로드 밸런싱 알고리즘이 존재하지만, 이번 글에서는 핵심이 되는 알고리즘만 알아보았습니다.  그럼 실제로 로드 밸런싱 기술은 어떻게 사용될까요? 라운드 로빈 방식을 이용하여 간단히 알아보겠습니다.

 

 


# 라운드 로빈 방식 

 

라운드 로빈 방식을 이용하여 www.john.com로 접속했을 때 브라우저가가 어떻게 응답할 것인지에 대해 알아보겠습니다.  (이것이 리눅스다 라는 도서를 참고하였습니다)

 

www.john.com에 해당하는 웹 서버를 3대 운영한다고 했을 때 각각의 서버 ip가 1.1.1.1, 1.1.1.2, 1.1.1.3 이라면 john.com의 네임서버는 라운드 로빈 방식에 따라 요청오는 순서대로 1.1.1.1, 1.1.1.2, 1.1.1.3을 차례대로 알려줄 것입니다.

 

여기서 네임서버 란 URL을 ip 형식으로 바꿔주는 정보를 가진 서버를 말합니다. 우리가 www.naver.com에 접속한다고 가정했을 때 브라우저는 사실 www.naver.com 을 192.168.111.100 형식의 ip로 변환해주어 접속하게 됩니다.

 

 

위에서 네이버, 한빛, 다나와는 각각 223.130.195.200 / 218.38.58.195 / 119.205.194.11 의 ip를 가지고 있고 이 ip를 앞에서 언급한 웹 서버 3대라고 가정해보겠습니다.

 

named.conf를 위와 같이 설정해주고 웹 브라우저에서 www.john.com로 접속하게 되면 번갈아가면서 네이버, 다나와, 한빛 사이트로 접속하시는 걸 보실수 있습니다.

위에서 네이버, 한빛, 다나와는 각각 223.130.195.200 / 218.38.58.195 / 119.205.194.11 의 ip를 가지고 있고 이 ip를 앞에서 언급한 웹 서버 3대라고 설정해주었기 때문에 네임서버는 이를 차례대로 응답해줍니다.

 

 

다같은 주소로 접속하였는데 다른 페이지가 로딩됩니다. 요청에 대해 네임서버가 각기 다른 ip주소를 알려주었기 때문입니다.

 

(VMware workstation를 이용하여 가상의 클라이언트로 접속하려 했는데 컴퓨터가 좋지 않아서 너무 느린 바람에 네이버까지는 띄울수 없었습니다... ㅜㅜ)

 

이상 로드밸런서에 대한 글이였습니다. 

 

 

댓글
댓글쓰기 폼
공지사항
Total
248,385
Today
760
Yesterday
1,065
링크
«   2022/10   »
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          
글 보관함