로드 밸런싱이란 무엇인가?

소개

로드 밸런싱은 웹 사이트, 애플리케이션, 데이터베이스 및 기타 서비스의 성능과 신뢰성을 향상시키기 위해 일반적으로 사용되는 고가용성 인프라의 주요 구성 요소입니다. 이는 작업 부하를 여러 서버에 분산하여 사용자의 워크로드를 분산함으로써 달성됩니다.

A web infrastructure with no load balancing might look something like the following:

이 예에서 사용자는 직접 웹 서버인 yourdomain.com에 연결합니다. 이 단일 웹 서버가 다운되면 사용자는 웹 사이트에 더 이상 액세스할 수 없게 됩니다. 또한 많은 사용자가 동시에 서버에 액세스하려고 하고 이를 처리할 수 없는 경우, 서버에 대한 연결이 느려지거나 아예 연결할 수 없을 수 있습니다.

이 단일 장애 지점은 로드 밸런서를 도입하고 백엔드에 최소한 하나의 추가 웹 서버를 두어 완화할 수 있습니다. 일반적으로 백엔드 서버는 모두 동일한 콘텐츠를 제공하여 어떤 서버가 응답하더라도 사용자가 일관된 콘텐츠를 받을 수 있도록 합니다.

위에서 설명한 예에서 사용자는 로드 밸런서에 액세스하고, 로드 밸런서는 사용자의 요청을 백엔드 서버로 전달하고, 그런 다음 백엔드 서버가 사용자의 요청에 직접 응답합니다. 이러한 시나리오에서 단일 장애 지점은 이제 로드 밸런서 자체입니다. 이를 완화하려면 두 번째 로드 밸런서를 도입할 수 있지만, 이에 대해 논의하기 전에 로드 밸런서가 작동하는 방식을 알아보겠습니다.

로드 밸런서는 다음과 같은 유형의 트래픽을 처리할 수 있습니다:

로드 밸런서 관리자는 네 가지 주요 유형의 트래픽에 대한 전달 규칙을 작성합니다:

HTTP – 표준 HTTP 균형 조정은 표준 HTTP 메커니즘을 기반으로 요청을 보냅니다. 로드 밸런서는 백엔드에게 원래 요청에 대한 정보를 제공하기 위해 X-Forwarded-For, X-Forwarded-Proto, 및 X-Forwarded-Port 헤더를 설정합니다.
HTTPS – HTTPS 균형 조정은 HTTP 균형 조정과 동일하게 작동하지만 암호화가 추가됩니다. 암호화는 두 가지 방법 중 하나로 처리됩니다: 백엔드까지 암호화를 유지하는 SSL 패스스루 또는 로드 밸런서에게 복호화 부담을 두는 SSL 종료이 있습니다. 이 경우 트래픽은 암호화되지 않은 채로 백엔드로 전송됩니다.
TCP – HTTP 또는 HTTPS를 사용하지 않는 응용 프로그램의 경우 TCP 트래픽도 균형 조정될 수 있습니다. 예를 들어, 데이터베이스 클러스터로의 트래픽을 모든 서버에 분산시킬 수 있습니다.
UDP – 최근에는 일부 로드 밸런서가 UDP를 사용하는 DNS 및 syslogd와 같은 핵심 인터넷 프로토콜의 균형 조정 지원을 추가했습니다.

이러한 전달 규칙은 로드 밸런서 자체의 프로토콜 및 포트를 정의하고, 백엔드에서 트래픽을 경로 설정할 로드 밸런서가 사용할 프로토콜 및 포트로 매핑합니다.

로드 밸런서는 백엔드 서버를 어떻게 선택합니까?

로드 밸런서는 두 가지 요소의 조합을 기반으로 요청을 전달할 서버를 선택합니다. 먼저 선택할 수 있는 모든 서버가 실제로 요청에 적절하게 응답하는지 확인한 다음 건강한 풀에서 선택하도록 사전 구성된 규칙을 사용합니다.

상태 확인

로드 밸런서는 “건강한” 백엔드 서버로만 트래픽을 전달해야 합니다. 백엔드 서버의 상태를 모니터링하기 위해 상태 확인은 정기적으로 포워딩 규칙에서 정의한 프로토콜과 포트를 사용하여 백엔드 서버에 연결을 시도하여 서버가 수신 대기 중인지 확인합니다. 서버가 상태 확인에 실패하면 즉시 풀에서 자동으로 제거되고, 해당 서버가 다시 상태 확인에 응답할 때까지 트래픽이 해당 서버로 전달되지 않습니다.

로드 밸런싱 알고리즘

사용되는 로드 밸런싱 알고리즘은 백엔드에서 사용 가능한 건강한 서버 중 어떤 것을 선택할지를 결정합니다. 일반적으로 사용되는 알고리즘 몇 가지는 다음과 같습니다:

라운드 로빈 – 라운드 로빈은 서버가 순차적으로 선택됩니다. 로드 밸런서는 첫 번째 요청에 대해 목록에서 첫 번째 서버를 선택한 다음, 목록을 순서대로 아래로 이동하여 마지막에 도달하면 다시 맨 위에서 시작합니다.

최소 연결 – 최소 연결은 로드 밸런서가 연결이 가장 적은 서버를 선택합니다. 트래픽으로 인해 세션이 길어지는 경우 권장됩니다.

소스 – 소스 알고리즘을 사용하면 로드 밸런서는 요청의 소스 IP의 해시를 기반으로 사용할 서버를 선택합니다. 이 방법을 사용하면 특정 사용자가 항상 같은 서버에 연결됩니다.

관리자가 사용할 수 있는 알고리즘은 사용 중인 특정 로드 밸런싱 기술에 따라 다양합니다.

로드 밸런서는 상태를 어떻게 처리합니까?

일부 응용 프로그램은 사용자가 계속해서 동일한 백엔드 서버에 연결되어야합니다. 소스 알고리즘은 클라이언트 IP 정보를 기반으로 친밀도를 생성합니다. 웹 응용 프로그램 수준에서 이를 달성하는 또 다른 방법은 로드 밸런서가 쿠키를 설정하고 해당 세션의 모든 요청을 동일한 물리적 서버로 보내는 스티키 세션입니다.

중복 로드 밸런서

싱글 포인트 오브 페일러로서의 로드 밸런서를 제거하기 위해, 두 번째 로드 밸런서를 클러스터를 형성하기 위해 첫 번째에 연결할 수 있으며, 각각이 다른 것들의 건강을 모니터링합니다. 각각은 고장 검출 및 복구에 대해 동등하게 능력을 가지고 있습니다.

주 로드 밸런서가 실패하는 경우, DNS는 사용자를 두 번째 로드 밸런서로 이동시켜야 합니다. DNS 변경 사항이 인터넷에서 전파되는 데 상당한 시간이 소요될 수 있고 이같은 장애 조치를 자동화하기 위해 많은 관리자들이 유연한 IP 주소 재매핑을 허용하는 시스템을 사용할 것입니다. 예를 들어 예약된 IP. 요청에 따른 IP 주소 재매핑은 필요할 때 쉽게 재매핑할 수 있는 정적 IP 주소를 제공함으로써 DNS 변경 사항에 내재된 전파 및 캐싱 문제를 해결합니다. 도메인 이름은 동일한 IP 주소와 연관되어 유지되며, IP 주소 자체는 서버 간에 이동됩니다.

이것이 예약된 IP를 사용하는 고가용성 인프라의 모습입니다: