Nginx에서 제공하는 upstream 설정을 활용하여 웹 서버에 가해지는 부하를 분산하는 방법을 알아보겠습니다.
로드 밸런싱
로드 밸런싱은 애플리케이션을 지원하는 리소스 풀 전체에 네트워크 트래픽을 균등하게 배포하는 방법입니다. - AWS(로드 밸런싱이란 무엇인가요?)
단일 서버 구성 문제점
웹 서비스를 이용하는 사용자가 늘어날 수록 서버에 가해지는 트래픽이 증가하게됩니다. 서버가 감당할 수 없는 과도한 트래픽이 몰리게 된다면 장애가 발생하여 서비스 이용이 불가능하게 될 것입니다.
서버를 재부팅하게 된다면 인입되던 트래픽이 초기화되어 잠시나마 정상적으로 서비스가 이용 가능한 것처럼 보이겠지만, 이내 트래픽이 증가하면 동일한 장애가 발생하게 됩니다. 결국 장애를 해결하기 위해서는 인입되는 트래픽이 수용 가능한 정도의 PC자원을 증설하는 방식을 고려해보아야 합니다.
scale-out과 scale-up
사용 가능한 PC자원을 증설하는 방법은 Scale-out 과 Scale-up 두 가지 방식을 고려해 볼 수 있습니다. 그림과 함께 두 방식이 어떻게 차이가 나는지 알아보겠습니다.
-
Scale-out은 기존 서버와 동일한 스펙의 새로운 컴퓨팅 자원을 추가하는 방식입니다. 클라우드 컴퓨팅 서비스를 이용할 경우 사용 가능한 비용 안에서 무한대로 자원을 증설 할 수 있다는 장점이 있습니다. 하지만 새로운 PC 자원이 추가되는 방식인 만큼 서비스로 인입되는 트래픽을 어떤 방식으로 분산시켜줄 지에 대한 추가적인 작업이 필요합니다.
-
Scale-up은 기존 서버의 스펙을 상향시켜 적용하는 방식입니다. 이 방식의 경우 기존 단일 서버로 설계되었을 때와 구조상 차이는 존재하지 않기 때문에 자원 운영 측면에서는 out방식보다 간단하지만 컴퓨팅 자원을 무한대로 추가할 수 없는 한계점이 존재하며, 이후 트래픽이 줄어든 상황이 올 경우 필요 이상의 자원 사용료를 지불해야 한다는 문제점이 있습니다.
때문에 PC자원을 증설할 때에는 트래픽의 변화에 유동적으로 대응할 필요가 있다면 scale-out방식이 더욱 적절한 선택지가 될 수 있습니다. 그렇다면 scale-out으로 자원이 증설하였을 때 고려해야하는 사항에 대해 추가적으로 알아보겠습니다.
scale-out과 트래픽 관리
물리적으로 서버 자원을 추가하였기 때문에 기존과 동일한 트래픽에 대하여 처리 능력이 향상되었습니다. 하지만 서버 자원이 추가되며 각각의 서버는 고유의 네트워크 인터페이스를 갖게됩니다.
이 경우 사용자 단말과 서버 사이에서 요청된 트래픽을 적절한 서버로 분배시켜줄 필요가 있습니다.(만약 트래픽이 분배되지 않으면, 기존 구조와 동일하게 단일 서버로 트래픽이 몰리기 때문에 scale-out의 효과를 볼 수 없게됩니다.)
이러한 트래픽 분산의 역할을 하는 하드웨어 혹은 소프트웨어를 LB(Load Balancer, 로드 밸런서)라고 합니다.
로드 밸런서
네트워크 계층을 이야기할 때 거론되는 대표적인 모델인 OSI 7계층 모델이 있다. 로드벨런서는 L2(데이터링크), L3(네트워크), L4(전송), L7(애플리케이션) 계층에 적용할 수 있습니다. 이중 가장 범용으로 적용되는 L4계층과 L7계층의 로드밸런서에 대하여 알아보겠습니다.
L4 / L7 로드 밸런서
L4 Layer
-> L4 로드밸런서 역할
L7 Layer
-> L7 로드 밸런서 역할
nginx를 활용한 로드 밸런싱 예제
앞서 알아본 바와 같이 TCP/IP 정보만을 활용하여 nginx L4 로드 밸런서를 설정해보도록 하겠습니다. 실습 환경은 다음과 같이 virtualBox를 활용하여 구성하였습니다.
Host PC는 Load Balancer 역할을 하는 192.168.137.143으로만 요청을 전송하게됩니다. 요청을 받은 LB는 upstream으로 설정된 server 01과 server 02에 RR(Round Robin, 라운드로빈) 방식으로 응답을 받아 보여줍니다.
