Load Balancer 정의 및 정리

이번에 배포하면서 느낀점이 Load Balancer 에는 여러 종류가 있던걸 이번에 프로젝트를 하면서 배웠습니다. 어떤걸 언제 사용하면 좋을지에 대해, 또 load balancer 의 원리에 대해 알면 좋을꺼 같아서 정리했습니다.

 

 

---

1.Load Balancer?

1) load balancer란?

 

현재 모든 정보는 인터넷을 통해 연결되어 있습니다. 이를 통해 트래픽의 폭발적인 증가로 이어지는데, 아무리 성능이 뛰어난 서버라 해도 이 모든 트래픽을 감당할 수 없게 됩니다. 이에 따라 기업들은 서버를 여러 개를 구축하고 여러 개에 동일한 데이터를 저장해 수많은 트래픽을 효과적으로 분산하게 됩니다.

근데 단순히 다수의 서버를 구축해 운영한다고 해서 모든 클라이언트의 요청에 일관성 있게 응답하는게 아니라 쏟아지는 트래픽을 여러 대의 서버로 분산해주는 기술이 없다면 한 곳의 서버에 모든 트래픽이 몰리는 상황이 발생합니다. 이 때 필요한 기술이 Load balancer 입니다.

 

2)Scale up & out

 

Scale up & out 방식은 서버가 부하를 감당하지 못한다고 판단할때 부하를 줄이기 위해서 필요한 방법입니다.

Scale Up은 기존 서버의 성능을 향상시키는 방법으로 CPU나 메모리를 업그레이드 하는 것과 같은 작업을 포함합니다.

Scale out은 트래픽이나 작업을 여러 대의 컴퓨터나 서버에 분산시켜 처리하는 방법입니다 Scale out 을 하게 되면 서버가 여러대가 되기 때문에 로드밸런싱이 필수적으로 동반해야합니다.

 

각각의 방법은 장단점이 있어 어떤 방법이 적합한지 판단해야합니다.

	Scale up	Scale out
확장성	성능 확장에 한계 존재	지속적 확장 가능
서버 비용	성능 증가에 따른 비용증가 폭 큼 일반적으로 비용 부담이 큰 편	비교적 저렴한 서버를 사용하므로, 일반적으로 비용 부담이 적음
운영 비용	스케일 업에 따른 큰 변화 없음	서버 대수가 늘어날 수록 관리 운용 비용 증가
관리 편의성	스케일 업에 따른 큰 변화 없음	서버 대수가 늘어날수록 관리 편의성 떨어짐
장애 영향	한 대의 서버에 부하가 집중되므로 장애시 다운타임 발생	부하가 여러 서버에 분산되어 처리됨으로 장애시 전면 장애 가능성 적음

 

 

3)load balancing 장점

 

애플리케이션 가용성

서버 장애 또는 유지 관리로 인해 애플리케이션 가동 중지 시간이 늘어 방문자가 애플리케이션을 사용할 수 없게 될 수 있습니다. 로드 밸런서는 서버 문제를 자동으로 감지하고 클라이언트 트래픽을 사용 가능한 서버로 리디렉션하여 시스템의 내결함성을 높입니다. 로드 밸런싱을 사용하여 다음 태스크를 더 쉽게 수행할 수 있습니다.

• 애플리케이션 가동 중지 없이 애플리케이션 서버 유지 관리 또는 업그레이드 실행
• 백업 사이트에 자동 재해 복구 제공
• 상태 확인을 수행하고 가동 중지를 유발할 수 있는 문제 방지

애플리케이션 확장성

로드 밸런서를 사용하여 여러 서버 간에 네트워크 트래픽을 지능적으로 전달할 수 있습니다. 로드 밸런싱이 다음을 수행하므로 애플리케이션에서 수천 개의 클라이언트 요청을 처리할 수 있습니다.

• 한 서버에서 트래픽 병목 현상 방지
• 필요한 경우 다른 서버를 추가하거나 제거할 수 있도록 애플리케이션 트래픽을 예측합니다.
• 안심하고 조정할 수 있도록 시스템에 중복성을 추가합니다.

애플리케이션 보안

로드 밸런서에는 인터넷 애플리케이션에 또 다른 보안 계층을 추가할 수 있는 보안 기능이 내장되어 있습니다. 이는 공격자가 서버 장애를 일으키는 수백만 개의 동시 요청으로 애플리케이션 서버를 가득 채우는 분산 서비스 거부 공격을 처리하는 데 유용한 도구입니다. 로드 밸런서는 다음을 수행할 수도 있습니다.

• 트래픽 모니터링 및 악성 콘텐츠 차단
• 공격 트래픽을 여러 백엔드 서버로 자동으로 리디렉션하여 영향 최소화
• 추가 보안을 위해 네트워크 방화벽 그룹을 통해 트래픽 라우팅

애플리케이션 성능

로드 밸런서는 응답 시간을 늘리고 네트워크 지연 시간을 줄여 애플리케이션 성능을 향상시킵니다. 다음과 같은 몇 가지 중요한 태스크를 수행합니다.

• 서버 간에 로드를 균등하게 배포하여 애플리케이션 성능 향상
• 클라이언트 요청을 지리적으로 더 가까운 서버로 리디렉션하여 지연 시간 단축

• 물리적 및 가상 컴퓨팅 리소스의 신뢰성 및 성능 보장

 

 

 

4)load balancing 알고리즘

로드 밸런싱 알고리즘에는 다양한 알고리즘이 있길래 조사해봤습니다.

 

 

• 라운드 로빈 (Round Robin)
  서버에 순차적으로 요청을 분배하는 가장 간단한 방식입니다. 각 서버가 동일한 수의 요청을 처리하도록 순서대로 요청을 전송합니다. 서버 간 자원이 균등한 경우에 효과적이지만, 자원 차이가 있을 때는 비효율적일 수 있습니다.
• 가중 라운드 로빈 (Weighted Round Robin)
  각 서버에 가중치를 부여하여 자원에 맞게 요청을 분배합니다. 자원이 강력한 서버는 더 높은 가중치를 받아 더 많은 요청을 처리하고, 약한 서버는 적은 요청을 처리하게 됩니다. 서버의 성능 차이가 있을 때 유용합니다.
• 최소 연결 (Least Connection)
  현재 가장 적은 연결 수를 가진 서버에 요청을 분배합니다. 요청이 많은 서버에 부하가 집중되지 않도록 하고, 각 서버가 최적의 성능을 발휘할 수 있게 도와줍니다. 세션이 긴 요청이 많을 때 특히 유용합니다.
• 최소 응답 시간 (Least Response Time)
  응답 시간이 가장 짧은 서버로 요청을 보냅니다. 현재 로드 상태를 고려하므로, 사용자가 빠르게 응답을 받을 수 있습니다. 다만 응답 시간 모니터링이 필요하므로 구현이 조금 복잡할 수 있습니다.
• IP 해시 (IP Hash)
  요청의 IP 주소를 해싱하여 특정 서버에 할당합니다. 같은 IP에서 오는 요청은 항상 같은 서버로 가도록 설정되며, 사용자 세션을 유지하는 데 효과적입니다. 주로 클라이언트의 상태 정보를 유지해야 하는 경우 사용합니다.
• 임의 선택 (Random Choice)
  무작위로 서버를 선택하여 요청을 분배합니다. 구현이 매우 간단하지만, 서버의 상태나 로드를 고려하지 않으므로 비효율적일 수 있습니다. 요청이 적고 단순한 서비스에 적합합니다.
• 컨시스턴트 해싱 (Consistent Hashing)
  서버를 특정 해시 링에 배치하고 요청을 해당 해시에 맞는 서버로 전송합니다. 서버가 추가되거나 제거될 때 기존의 요청 분배에 영향을 최소화할 수 있습니다. 대규모 분산 시스템에서 많이 사용됩니다.

 

 

 

---

2.Load Balancer 의 유형

load balancer 가 트래픽을 리디렉션 하기 위해 클라이언트 요청에서 확인하는 콘텐츠에 따라 AWS에서는 3가지 방식으로 로드 밸런싱을 3가지 주요 범주로 분류 할 수 있습니다.저는 2가지 ALB와 NLB에 대해 찾아봤습니다.

 

 

 

1) 애플리케이션 로드 밸런서(Application Load Balancer) 

 

ALB는 웹 서비스에 걸리는 부하를 분할해주는 로드밸런서로, OSI Layer7인 애플리케이션 계층에서 동작하는 로드밸런서로, 로드밸런서는 요청을 받으면 우선순위에 따라 리스너 규칙을 평가하여 적용할 규칙을 결정한 다음, 규칙 작업의 대상 그룹(Target Group)에서 대상을 선택합니다.

 

다른 로드밸런서와 달리 HTTP , HTTPS, WebSocket 을 활용하는 로드밸런서라는 것이 가장 큰 특징입니다. ALB는 HTTP의 header , 요청 method 등에 기준을 적용하여 기준에 맞는 적절한 대상그룹으로 라우팅 할 수 있는 로드밸런서입니다.

 

L7(application lyr)에서 동작한다. HTTP/HTTPS 의 헤더를 사용해서 라우팅할 수 있다.  SSL 적용이 가능하다. 고정 IP를 제공하지 않는다. 라운드 로빈 알고리즘을 통해 라우팅한다. health check 기능이 존재 IP,instance , AWS Lambda를 대상으로 지정할 수 있다.

 

 

2) NLB(Network Load Balancer)

NLB는 Transport layer 에서 작동하며 TCP 와 UDP를 사용하는 요청을 받아들여 부하분산을 실시합니다. 단 , HTTP 가 아닌 하위 layer 인 TCP에서 처리하므로 HTTP 헤더를 해석하지 못합니다. Load Balancer 가 연결 요청을 받으면 기본 규칙의 대상 그룹에서 대상을 선택하고 리스너 구성에 지정된 포트에서 선택한 대상에 대한 TCP 연결을 열려고 시도합니다. 고성능을 요구하는 환경에서의 부하 분산에 적합합니다.

L4(transport layer)에서 동작한다. TCP/UDP 헤더를 사용해서 라우팅한다. 정적 IP 주소를 제공해서 클라이언트가 항상 동일한 IP로 접근하게 할 수 있다. 리스너 설정에서 ALB와는 다르게 프로토콜(TCP or UDP)와 포트번호만 설정 가능하다. IP, 인스턴스 ALB를 대상으로 지정할 수 있다. 플로우 해시 알고리즘을 통해 라우팅한다.