스케일 업과 스케일 아웃

로드 밸런싱을 이해하기 위해서는 스케일 업과 스케일 아웃에 대해서 먼저 인지해야 한다.

스케일 업

만약 서비스에 사용자가 몰려들어 현재 내 서버에 부하가 크게 왔다고 생각해 보자. 그렇다면 먼저 들 수 있는 생각은 “서버의 하드웨어 성능을 높이면 되지 않을까?” 와 같은 것이다.

따라서 단순히 서버의 하드웨어 성능을 높이는 것을 “스케일 업” 이라 한다. cpu나 램 등의 리소스를 추가해서 더 좋은 서버를 구매해 쓰는 것이다.

스케일 아웃

하지만 서버의 성능은 무한으로 확장시킬 수 없고 분명 한계가 존재한다. 스케일업을 때려박아서 람보르기니같은 고급서버를 가져도 유입자가 죽 늘어단다면 한계점을 견디지 못하고 터질 수 밖에 없다.

하지만 서버를 여러 대 증설해서 부하를 분산할 수는 있을 것이다. 이처럼 여러 대의 서버를 증설시키는 방법이 “스케일 아웃”이다.

로드 밸런싱이란?

로드 밸런싱과 로드 밸런서

결국 스케일 아웃을 통해 서버의 부하를 나누는 것이 “로드 밸런싱”이다. 그런데 서버를 대충 늘려놓기만 한다고 능사가 아니라, 무언가가 그 서버들이 각 요청을 나눌 수 있도록 지정하는 역할을 해줘야 할 것이다. 이 역할을 하는 것이 로드밸런서이다. 로드밸런서에는 여러 종류가 있지만 크게 하드웨어를 사용하는 방법과 소프트웨어를 사용하는 방법으로 나눌 수 있다.

하드웨어를 통한 로드 밸런싱

하드웨어를 통한 방법에는 L4 스위치와 L7 스위치가 대표적으로 존재한다. L4 스위치와 L7 스위치의 이름이 왜 L4 스위치와 L7 스위치일까? 걍 단순하게 생각하면 된다. 4계층(전송 계층)에서 사용되니까 L4 스위치고, 7계층(애플리케이션 계층)에서 쓰니까 L7 스위치다.

L4 스위치

방금 4계층(전송 계층)에서 사용하는 스위치라고 표현했음을 기억하자. 전송 계층에서 무엇을 하는가? ip와 포트 번호를 기준으로 패킷의 목적지를 판단한다.

따라서 ip와 포트 레벨을 기준으로 로드밸런싱을 수행하는 스위치가 L4 스위치다. 예를 들어 80포트의 요청을 8080과 8082 포트로 나눠서 처리한다던지, www.naver.com에 대한 요청을 두 개의 ip서버가 나눠서 처리한다던지와 같은 동작이다. (후자는 L3 스위치로도 처리할 수 있을 것이다.)

하지만 L4 스위치는 IP 주소와 포트 번호만을 보고 트래픽을 분산하기 때문에, 요청의 내용에는 직접적으로 접근하지 않는다. 따라서 만약 특정 요청의 내용을 기준으로 서버로의 분배를 조절할 수 없다.

L7 스위치

L7 스위치 역시 7계층(애플리케이션 계층)에서 사용하는 스위치라고 언급했다. 애플리케이션 계층은 http와 같은 프로토콜을 사용하여 데이터를 전송한다. 따라서 L7 스위치는 로드밸런싱 또한 http 프로토콜을 활용하여 수행할 수 있다.

L7 스위치는 아래와 같이 요청의 특정 내용을 기반으로 서버 분배를 조절할 수 있다는 장점이 있다.

1. URL 기반 분배: 특정 URL 패턴을 가진 요청은 특정 서버 그룹으로 보내기
2. 도메인 기반 분배: 서로 다른 도메인을 사용하는 요청은 서로 다른 서버로 보내기
3. 쿠키 기반 분배: 특정 쿠키 값을 가진 요청은 해당 쿠키를 처리하는 서버로 보내기
4. 헤더 기반 분배: 요청의 특정 헤더 값을 기준으로 서버로 보내기

소프트웨어를 활용한 로드 밸런싱

리버스 프록시를 활용하면 소프트웨어를 활용하여 로드 밸런싱을 수행할 수 있다. 리버스 프록시인 nginx를 로드밸런서로 활용한 로드 밸런싱이 대표적인 소프트웨어를 활용한 로드 밸런싱이다. nginx 역시 l4 스위치와 l7 스위치의 기능을 모두 제공할 수 있다.

Nginx vs Switch

nginx는 소프트웨어이므로 설치가 쉽고 비용적으로 저렴하다. 또 설정 변경도 쉬워서 유연하게 로드 밸런싱과 리버스 프록시 설정을 조절할 수 있다. http https 등 다양한 프로토콜을 지원하는 장점도 있다.

하지만 하드웨어 기반의 스위치보다 성능이 제한적이라 대규모 트래픽 처리에는 스위치가 더 적합할 수 있다. 스위치가 가용성과 안정성 측면에서 더 낫다고 볼 수 있다. 또 nginx는 결국 백엔드 서버를 활용하는데, 스위치는 네트워크 스위치 자체에서 로드 밸런싱을 수행해 서버의 부담이 덜하다고 한다.

로드밸런싱 방법

• Round Robin
  • 모든 서버에 균일한 시간 만큼 부하를 분산한다.
  • 그러나 서버의 성능별로 다르게 부하를 분산할 수 없는 단점이 있다.
  • 따라서 특정 서버에는 가중치를 주는 Weighted round-robin 방식도 존재한다
• Least Connections
  • 여러 서버 중에 가장 연결이 적은 서버로 부하를 분산한다.
  • 효율적이지만 서버의 연결상태를 계속 체크하는 리소스가 들며, 신규 서버가 생겨날 때 과도하게 몰려들 수 있다.
• Source
  • 사용자 ip를 해싱하여, 특정 사용자가 지정된 서버로만 오도록 한다. 세션을 유지해야 하는 사이트에서 주로 사용한다.
  • 특정 서버의 사용자만 많이 접속해 부하 분산이 제대로 안 될 수 있다.

궁금한 점

• ip처럼 다른 서버로 요청을 분산하는 것이 아닌, 같은 서버의 다른 포트로 요청을 분산하면 결국 같은 서버의 리소스를 사용하는데 부하 분산 효과가 있을까?
  • 물론 같은 서버의 리소스를 사용하게 되지만, 서로 다른 포트를 사용하는 클라이언트 요청은 서버 내부에서 다른 프로세스로 처리되기 때문에 분리된 상태로 동시에 작업을 처리할 수 있어 성능상 효과가 존재한다고 볼 수 있다고 생각이 든다
• 결국 L4 스위치의 모든 기능은 L7 스위치에서도 사용할 수 있다. 그렇다면 그냥 L7 스위치만 사용하는게 더 좋지 않을까?
  • 그러나 각 스위치를 사용하는 것의 장단점은 명확히 존재한다. L4 스위치를 사용하면 딱 4계층까지의 정보, 그러니까 ip와 포트번호만 보고나서 곧바로 로드밸런싱을 수행하는데, L7 스위치를 사용하면 일단 응용 계층의 데이터까지 다 분석한다(쿠키, 세션, 헤더, url…). 따라서 cpu 처리가 고비용이라 오버헤드가 더 많이 일어나며 성능 저하 이슈가 일어날 수 있다. 따라서 내용에 따라 요청을 분산할 일이 없을 때는 L4 스위치를 사용하는 것이 더 바람직할 것이다.