로드 밸런서란 무엇입니까? 들어오는 트래픽을 효과적으로 분산하는 방법

로드 밸런서는 들어오는 네트워크 트래픽을 여러 백엔드 서버에 분산시키는 인프라 구성 요소입니다. 처리량을 높이고 중복성을 추가하여 서버 중 하나에 장애가 발생해도 서비스를 계속 사용할 수 있습니다.

로드 밸런서는 애플리케이션의 공개 게이트웨이 역할을 합니다. 이들은 각자의 역할에 특화되어 있어 트래픽 처리량을 최대화하도록 최적화될 수 있습니다. 로드 밸런서는 일반적으로 애플리케이션의 요구 사항에 맞게 여러 유형의 라우팅 알고리즘으로 구성됩니다.

이 기사에서는 로드 밸런서가 무엇이고 어떻게 작동하며 얼마나 복잡할 수 있는지 살펴보겠습니다. 또한 가장 일반적인 로드 밸런싱 알고리즘 간의 차이점에 대해서도 설명합니다.

로드 밸런서는 무엇을합니까

로드 밸런서는 애플리케이션 서버 앞에 역방향 프록시를 제공하는 역할을 합니다. 모든 클라이언트는 별도의 백엔드 인스턴스가 아니라 이 단일 프록시에 연결합니다. 로드 밸런서는 각 요청을 처리할 서버를 선택하는 역할을 합니다. 이것은 외부 클라이언트에게 보이지 않게 발생합니다.

로드 밸런서의 하드웨어 및 소프트웨어 구현을 모두 사용할 수 있습니다. 소프트웨어 측면에서 Apache 및 NGINX 와 같은 대부분의 웹 서버 가 이 역할을 수행할 수 있습니다. 하드웨어 로드 밸런서는 호스팅 공급자의 독립 실행형 인프라 구성 요소로 배포됩니다.

로드 밸런서는 일반적으로 백엔드 서버 풀의 인스턴스 상태를 모니터링합니다. 비정상 상태가 된 서버 부품은 새로운 트래픽 전송을 중지하여 서비스 변동성과 가동 중지 시간을 줄입니다. 마찬가지로 로드 밸런서는 일반적으로 언제든지 새 서버 인스턴스를 추가할 수 있도록 하므로 피크 시간 동안 추가 전력으로 서비스를 확장할 수 있습니다.

로드 밸런서의 주요 목표는 처리량을 최대화하고 사용 가능한 리소스를 가장 효율적으로 사용하는 것입니다. 물리적 서버 간에 확장하는 기능은 일반적으로 추가 프로세서 또는 메모리로 단일 노드를 확장하는 것보다 더 효율적입니다. 수평적 확장은 더 많은 중복성과 용량을 제공하지만 로드 밸런싱 수준과 관련된 오버헤드는 일반적으로 명목입니다.

부하 분산 알고리즘

로드 밸런싱의 목표는 항상 여러 서버에 트래픽을 분산하는 것이지만 이 목표를 달성하는 방법에는 여러 가지가 있습니다. 특정 전략을 살펴보기 전에 선택할 수 있는 두 가지 주요 알고리즘 유형을 식별하는 것이 중요합니다.

• 정적 균형. 이러한 메서드는 하드 코딩된 구성 값과 함께 작동하므로 동작을 완전히 예측할 수 있습니다. 이 유형의 알고리즘은 전달할 수 있는 내부 서버의 상태를 고려하지 않으므로 이미 오버로드된 인스턴스에 새 요청을 계속 보낼 수 있습니다.
• 동적 균형. 동적 알고리즘은 풀의 트래픽 흐름 및 서버 가용성에 따라 실시간으로 조정됩니다. 이러한 전략을 사용하면 이미 여러 요청을 처리하는 인스턴스를 자동으로 피할 수 있습니다. 동적 로드 밸런싱은 로드 밸런서가 각 요청의 실행 상태를 추적해야 하기 때문에 약간의 오버헤드를 추가할 수 있습니다.

정적 밸런싱 시스템은 일반적으로 설정, 테스트 및 확인하기가 더 쉽습니다. 동적 밸런싱은 훨씬 더 강력하며 일반적으로 프로덕션 애플리케이션에 선호되는 선택입니다. 이러한 각 클래스 내에서 선택할 수 있는 몇 가지 특정 라우팅 전략이 있습니다.

• 라운드 로빈은 요청을 각 서버에 차례로 라우팅하는 정적 균형 조정 기술입니다. 세 개의 서버 A, B, C가 있는 경우 첫 번째 들어오는 요청은 A로, 두 번째는 B로, 세 번째는 C로 전달됩니다. 로드 밸런서는 네 번째 요청에 대해 A에서 다시 시작됩니다.
• 가중 라운드 로빈은 관리자가 풀에 있는 각 서버의 상대적 우선 순위를 결정하는 라운드 로빈 알고리즘의 변형입니다. 가중치가 높은 서버는 더 자주 사용되어 더 많은 트래픽을 받습니다. 이 방법을 사용하면 서버 풀이 특성이 다른 서버로 구성된 경우 라운드 로빈 전략을 사용할 수 있습니다.
• 임의 선택 – 많은 로드 밸런서에는 대체 정적 선택으로 진정한 임의 선택이 포함됩니다.
• 해싱 – 이 정적 균형 조정 전략은 클라이언트의 IP 주소를 해싱하여 요청을 처리할 백엔드 서버를 결정합니다. 이렇게 하면 동일한 인스턴스가 해당 클라이언트에서 시작된 모든 연결에 서비스를 제공합니다.
• 최소 연결은 들어오는 요청을 항상 열린 연결이 가장 적은 서버로 라우팅하는 널리 사용되는 동적 알고리즘입니다. 많은 응용 프로그램에서 이것은 전체 성능을 최대화하는 가장 효율적인 방법입니다.
• 최대 사용 가능한 대역폭 – 이 방법은 사용 가능한 대역폭이 가장 높은 서버로 새 트래픽을 보냅니다. 이는 총 요청 수가 적은 경우에도 개별 요청이 대부분의 대역폭을 사용할 수 있는 상황에 이상적입니다.
• 사용자 정의 가능한 상태/로드 엔드포인트. 많은 로드 밸런서를 사용하면 백엔드 서버에서 제공하는 사용자 지정 메트릭을 기반으로 트래픽 분산 결정을 내릴 수 있습니다. SNMP 와 같은 메커니즘을 사용하여 CPU 사용량, 메모리 소비 및 기타 중요한 메트릭과 관련하여 쿼리할 수 있습니다 .

로드 밸런서의 기타 기능

로드 밸런서는 애플리케이션에 약간의 복잡성을 생성할 수 있습니다. 가장 일반적인 것 중 하나는 고정 서버 세션에 도달하는 문제입니다. 일반적으로 시스템은 서버에 상태를 저장하고 클라이언트 연결 간에 유지해야 합니다.

해시 균형 알고리즘 또는 유사한 클라이언트 측 옵션을 사용하여 이를 완화할 수 있습니다. 이렇게 하면 동일한 IP 주소의 연결이 특정 서버에서 종료됩니다. 대부분의 로드 밸런서는 HTTP 요청에서 지정된 헤더 또는 쿠키를 찾는 명시적 고정 세션 옵션도 제공합니다. 이 값은 클라이언트가 처음에 연결된 후 동일한 서버로 요청을 순차적으로 라우팅하는 데 사용할 수 있습니다.

로드 밸런서는 SSL을 복잡하게 만들 수도 있습니다. 많은 조직이 로드 밸런서에서 종료되도록 SSL을 구성합니다. 로드 밸런서와 백엔드 서버 간의 연결은 일반 HTTP 프로토콜을 사용하여 이루어집니다. 이는 일반적으로 설정이 더 쉽고 유지 관리 요구 사항이 줄어듭니다.

보안이 중요한 워크로드에 대해 정방향으로 HTTP 연결을 사용하는 것이 항상 허용되는 것은 아닙니다. SSL 통과가 가능한 로드 밸런서는 데이터를 먼저 해독하지 않고도 백엔드 서버로 트래픽을 직접 전달할 수 있습니다. 그러나 이것은 사용할 수 있는 라우팅 옵션을 제한합니다. 로드 밸런서는 수신 요청을 해독할 수 없기 때문에 헤더 및 쿠키와 같은 속성을 기반으로 일치시킬 수 없습니다.

레이어 4 및 레이어 7 로드 밸런서

로드 밸런싱은 종종 레이어 4(L4) 및 레이어 7(L7) 네트워크와 관련하여 논의됩니다. 이 용어는 로드 밸런서가 네트워크 요청의 수명 주기에서 트래픽을 지시하는 지점을 설명합니다.

계층 4 자원은 네트워크 전송 계층에서 작동합니다. 이러한 로드 밸런서는 사용 중인 TCP 또는 UDP 포트와 같은 요청 전송 특성을 기반으로 라우팅 결정을 내립니다. 요청 관련 데이터는 고려되지 않습니다.

레이어 7 로드 밸런서는 애플리케이션 레이어 옆에 있습니다. 이러한 로드 밸런서는 요청의 복잡한 데이터에 액세스하고 이를 사용하여 특정 워크로드에 대한 라우팅 규칙을 알릴 수 있습니다. HTTP 헤더 또는 쿠키의 세션 ID를 고려하여 로드 밸런싱이 수행될 수 있는 곳입니다.

레이어 7 로드 밸런싱은 강력하지만 상대적으로 리소스를 많이 사용합니다. 백엔드로 전달되기 전에 각 요청의 내용을 구문 분석하고 유효성을 검사해야 합니다. Layer 4 로드 밸런서의 버스트 특성은 제어를 덜 제공하지만 처리량에 미치는 영향은 적습니다. 레이어 4도 트래픽을 해독하지 않으므로 이 단계에서 로드 밸런서를 손상해도 요청 데이터가 노출되지 않습니다.

결론

로드 밸런서를 사용하면 서버 간에 들어오는 트래픽을 보낼 수 있습니다. 여러 서버 인스턴스를 투명하게 실행할 수 있는 고가용성 네트워크 아키텍처의 중요한 구성 요소입니다. 이렇게 하면 서비스 처리량이 증가하고 서버 중 하나가 다운될 경우 완전한 중단이 방지됩니다.

대부분의 로드 밸런서 구현에서는 정적 및 동적 옵션을 모두 포함하여 다양한 알고리즘을 선택할 수 있습니다. 많은 응용 프로그램은 “최소 연결” 또는 “라운드 로빈”과 같은 간단한 옵션으로 잘 제공되지만 특정 상황에서는 더 복잡한 옵션이 유용합니다.

로드 밸런서 뒤에서 각 프로덕션 애플리케이션을 실행하는 것이 좋습니다. 이를 통해 필요에 따라 확장하고 비정상 서버에 대응할 수 있는 유연성을 얻을 수 있습니다. 로드 밸런싱은 일반적으로 호스팅 스택 또는 클라우드 공급자 네트워크 인프라 내에서 쉽게 설정할 수 있습니다.