로드밸런싱 기본

로드밸런싱은 서버에 트래픽이 몰릴 경우 서버 부하가 커지는 것을 방지하기 위해 트래픽을 분산하는 것을 말한다. 
서비스 규모가 커지고 요청이 많아지거나 장애 상황에 대응하기 위해, 또는 다운타임을 없애기 위해 서버 다중화는 거의 필수 전략이다. 서버 여러 개가 실행되고 있다면, 트래픽을 어떤 서버로 전송해야 할지 정해야 하는데 이것을 정하는 것이 로드밸런싱 전략이다.

로드밸런싱 전략에 어떤 종류가 있는지, 로드밸런싱은 네트워크 상의 어떤 계층에서 동작하는지를 알아보고, 실제 사용되는 로드밸런서에는 어떤 것들이 있는지 알아보자.

 

로드밸런싱 전략

로드밸런싱 전략은 들어온 트래픽을 어떤 서버로 보낼지 정하는 규칙이다. 로드밸런싱 전략에는 대표적으로 다음과 같은 것들이 있다.

• 라운드 로빈(Round Robin)
  가장 기본적인 알고리즘으로, 요청을 단순히 순차적으로 각각의 서버에 균등하게 분배한다. 여러 로드밸런서에서 기본 규칙으로 사용하는 전략이다.
• 최소 연결(Least Connections)
  현재 연결 수가 가장 적은 서버로 요청을 보낸다. 연결된 요청 수를 균등하게 유지하는 데 적합하다.
• IP 해싱
  IP 를 해싱한 값을 가지고 서버에 요청을 분배하는 방식이다. 사용자 세션을 유지해야 하는 경우에 적합하다.
  (동일 IP 사용자는 동일한 서버에 요청하게 되므로)
  

요구사항에 따라 적절한 로드밸런싱 전략을 선택할 수 있다.

 

L4/L7 로드밸런싱

L4/L7 로드밸런싱이란 로드밸런싱에 필요한 정보에 따라 로드밸런싱이 어디에서(어떤 계층에서) 동작하는지 나누어짐을 말한다. 정확하게는, [로드밸런싱에 필요한 정보를 얻기 위해 어떤 계층의 패킷을 까봐야 하는가] 로 L4 로드밸런싱인지 L7 로드밸런싱인지 구분할 수 있다.

예를 들어, 로드밸런싱을 하는데 IP주소나 포트 번호같은 정보만 필요하다면, TCP/IP 헤더 로부터 이러한 정보를 얻을 수 있으므로 L4 계층의 로드밸런싱이라고 할 수 있을 것이다. 만약 로드밸런싱에 Http 요청 경로나 헤더 안의 정보가 필요하다면, 이는 L7 로드밸런싱으로 구분할 수 있다. 예를 들어, https://.../../images 요청은 이미지 서버로 보내야 하는 로드밸런싱 규칙이 있다면, 이를 위해 L7 계층의 정보가 필요하므로 L7 로드밸런서가 필요하다. 

L4/L7 로드밸런서를 나누는 이유가 무엇일까?

L7 로드밸런싱을 위해서는 많은 정보가 필요하고, 많은 패킷을 열어봐야 하며 그만큼 L4 로드밸런싱에 비해(비교적)무거운 작업이다.
반대로 L4 로드밸런싱은 TCP/IP 헤더의 IP주소, 포트넘버 등 간단한 정보만 가지고 빠르게 수행하는 가벼운 작업이므로, 로드밸런싱에 이러한 정보만 필요하다면 L4 로드밸런싱이 적합할 것이다.

또한, 네트워크 계층의 상위 계층에서 사용하는 장비는 할 수 있는 일이 많고 그만큼 비용이 크다. 예를 들어 L7 계층에서 Http 프로토콜을 사용한다면, Http 프로토콜은 4계층의 TCP 프로토콜을 사용하므로 이를 이해해야 한다. 즉, 상위 수준 계층은 하위 수준 계층의 프로토콜, 헤더를 이해하고 사용할 줄 알아야 하며 그만큼 할 수 있는 일이 많다는 뜻이다. L4 계층의 장비는 Http 헤더에 담긴 내용을 이해할 수 없고, 자신보다 하위 계층의 정보만 이해하고 제어할 수 있다. 

따라서 로드밸런싱 규칙이 낮은 계층의 정보(IP/포트넘버)만 필요로 한다면 L4 로드밸런서를 선택함이 적절하다. 로드밸런싱 규칙이 어플리케이션 계층의 정보를 필요로 한다면, L7 로드밸런서를 선택해야 한다.

실제로 로드밸런싱이 동작하는 계층은?

실제로 어떤 계층에서 로드밸런싱이 동작하는지는 로드밸런싱에 어떤 계층의 정보가 필요한지보다, 어떤 로드밸런서를 선택했는가에 따라 달라진다. 예를 들어, 라운드 로빈 전략의 로드밸런싱을 한다면 기본적으로는 IP 주소, 포트넘버만 필요하기 때문에 L4계층에서 동작한다고 생각할 수 있지만 실제로 nginx나 aws ELB 에서는 기본 설정이 라운드 로빈 전략이지만 L7계층에서 로드밸런싱이 동작한다. 이는 별도 설정으로 4계층에서 동작할 수 있도록 변경할 수 있다.

즉 선택한 전략에 따라 로드밸런싱이 어디서 동작하는지 정해지는 것이 아니고, 전략에 따라 어떤 로드밸런서를 사용할지 선택함으로서 로드밸런싱 동작 계층이 정해진다.

 

주로 사용하는 로드밸런서는 어떨까?(Nginx, Asw ELB)

Nginx 는 설정 파일 구성으로 트래픽을 분산하는 기능을 추가할 수 있는 경량 웹 서버다. 기본적으로 라운드 로빈 방식으로 동작하며, 최소 연결, IP 해싱 등으로 설정을 바꿀 수 있다. 설정 파일 구성에 따라 L4 에서 동작게 할 수도 있지만 기본적으로 L7 에서 동작한다. 로드밸런서는 기능 중 하나이기 때문에 로드밸런싱 외에도 캐싱, 리버스 프록시 등 다양한 기능과 상세한 설정을 할 수 있는 것이 장점이지만, 그만큼 러닝 커브가 있는 것이 단점이다.

• 장점: 유연한 설정, 강력한 성능(이벤트 기반), 캐싱/압축/리버스 프록시 등 다양한 기능 통합, 비용 효율적(오픈소스), 고급 로깅 제공
• 단점: 설치, 구성, 업데이트, 관리에 대한 전문 지식과 노력이 필요
• 주요 사용처: 클라우드 환경 외, 자체 서버, 복잡한 라우팅 규칙, 웹서버 기능 통합이 필요할 때

Asw ELB 는 Aws 에서 지원하는 보다 높은 추상화를 제공하는 로드밸런서이다. 마찬가지로 기본 L7 에서 동작하며, 라운드 로빈, IP 해싱 등의 기본 알고리즘을 어플리케이션 레이어에 맞게 발전된 형태로 제공한다.(컨텐츠 기반 라운드 로빈 알고리즘, IP 해싱 대신 StickySession 지원) Aws에 종속된 환경 내에서 강력한 확장성과 고가용성을 제공하지만, 높은 추상화로 인해 편리한 만큼 세세한 설정은 제한적일 수 있다.

• 장점: AWS 관리형 서비스로 자동 확장 및 고가용성, 손쉬운 SSL/TLS 종단 처리(ACM 연동), 관리 용이성, 통합된 로깅
• 단점: AWS 종속적, NGINX 대비 기능 커스터마이징 제한적, 별도 로드밸런서 인스턴스가 필요할 수 있음
• 주요 사용처: AWS 환경에서 애플리케이션의 가용성과 확장성이 중요하고, 관리 부담을 줄이고 싶을 때