부하 분산 알고리즘

부하 분산의 주요 목적은 단일 서버나 자원에 집중되는 부하를 여러 서버나 자원으로 분산시켜 전체 시스템의 성능, 안정성, 효율성을 향상시키는 것이다. 이는 단일 장애점을 제거하고 가용성을 높이며, 사용자에게 일관된 서비스 품질을 제공하는 데 기여한다.

부하 분산을 통해 얻는 핵심 이점은 다음과 같다. 첫째, 확장성이 향상된다. 트래픽 증가에 맞춰 서버를 추가함으로써 시스템의 처리 능력을 수평적으로 확장할 수 있다. 둘째, 내결함성이 강화된다. 한 서버에 장애가 발생하더라도 다른 정상 서버로 트래픽을 전달하여 서비스 중단을 방지한다. 셋째, 응답 시간을 단축하고 처리량을 증가시켜 사용자 경험을 개선한다. 마지막으로, 자원 활용을 최적화하여 하드웨어 비용을 절감하고 운영 효율성을 높일 수 있다.

따라서 부하 분산은 현대의 웹 서비스, 클라우드 컴퓨팅, 마이크로서비스 아키텍처에서 시스템의 핵심 요구사항인 성능, 안정성, 경제성을 동시에 충족시키기 위한 필수적인 기법이다.

부하 분산의 기본 작동 구조는 일반적으로 로드 밸런서라는 중개 장치 또는 소프트웨어를 중심으로 구성된다. 클라이언트로부터 들어오는 모든 요청은 먼저 로드 밸런서에 도달한다. 로드 밸런서는 미리 정의된 또는 실시간으로 수집된 정보를 바탕으로 특정 부하 분산 알고리즘을 적용하여, 요청을 처리할 하나의 백엔드 서버를 선택한다. 이후 로드 밸런서는 해당 요청을 선택된 서버로 전달(포워딩)한다. 서버가 응답을 생성하면, 그 응답은 다시 로드 밸런서를 거쳐 최초의 클라이언트에게 전송되거나, 경우에 따라 로드 밸런서를 우회하여 직접 전송되기도 한다[2].

이 구조에서 핵심 구성 요소는 로드 밸런서, 서버 풀(또는 팜), 그리고 분산 알고리즘이다. 서버 풀은 실제 워크로드를 처리하는 동일한 애플리케이션을 실행하는 여러 서버 인스턴스로 구성된다. 로드 밸런서는 이 풀의 구성원을 알고 있으며, 각 서버의 상태(예: 온라인/오프라인, 현재 부하)를 주기적으로 확인하는 헬스 체크 메커니즘을 운영한다. 이를 통해 장애가 발생한 서버는 풀에서 자동으로 제외되어 서비스의 전반적인 가용성을 유지한다.

작동 구조는 네트워크 계층에 따라 크게 L4 로드 밸런싱과 L7 로드 밸런싱으로 구분된다. L4(전송 계층) 로드 밸런싱은 IP 주소와 포트 번호 같은 네트워크 패킷 정보만을 보고 결정을 내린다. 반면, L7(애플리케이션 계층) 로드 밸런싱은 HTTP 헤더, URL, 쿠키 정보 등 애플리케이션 데이터의 내용까지 분석할 수 있어 더 세밀한 라우팅이 가능하다. 예를 들어, /images/ 경로로 오는 요청은 이미지 서버 그룹으로, /api/ 경로의 요청은 애플리케이션 서버 그룹으로 분기할 수 있다.

라운드 로빈(Round Robin)은 가장 기본적이고 널리 사용되는 정적 부하 분산 알고리즘이다. 이 방식은 들어오는 요청을 미리 정의된 서버 목록에 순차적으로 할당한다. 첫 번째 요청은 목록의 첫 번째 서버로, 두 번째 요청은 두 번째 서버로 전달되며, 마지막 서버에 요청을 보낸 후에는 다시 목록의 처음으로 돌아가 순환한다.

이 알고리즘의 핵심은 단순성과 공정성에 있다. 별도의 복잡한 로직이나 서버 상태 확인 없이도 각 서버에 균등하게 요청을 분배할 수 있다. 따라서 모든 서버의 사양과 처리 능력이 동일한 환경에서 효과적이다. 구현이 간단하여 오버헤드가 적고, 결정론적이어서 특정 클라이언트의 요청이 항상 같은 순서로 서버에 할당되는 패턴을 예측하기 쉽다.

그러나 서버의 실제 처리 능력이나 현재 부하 상태를 고려하지 않는다는 근본적인 한계가 있다. 예를 들어, 서버 간 하드웨어 성능 차이가 크거나, 일부 서버에서 장시간 실행되는 작업으로 인해 부하가 높은 경우에도 무조건 순서대로 요청을 전달한다. 이로 인해 응답 시간이 길어지는 서버로도 요청이 계속 들어와 전체 시스템 성능이 저하될 수 있다.

라운드 로빈의 변형으로는 가중치를 부여한 가중치 기반 알고리즘이 있다. 이는 서버의 처리 능력에 비례하여 가중치를 설정하고, 그 비율에 따라 더 많은 요청을 할당하는 방식이다. 예를 들어, 성능이 두 배인 서버에는 가중치를 2로 설정하여 일반 서버보다 두 배 많은 요청을 받게 할 수 있다.

가중치 기반 알고리즘은 라운드 로빈 알고리즘의 단순한 균등 분배 방식을 보완한 정적 부하 분산 방식이다. 각 서버에 사전에 정의된 가중치를 할당하고, 이 가중치에 비례하여 연결 요청을 분배한다. 가중치는 일반적으로 서버의 처리 능력, 하드웨어 사양(예: CPU 코어 수, 메모리 용량), 또는 네트워크 대역폭을 반영하여 설정된다.

이 알고리즘의 작동 방식은 다음과 같다. 가중치가 3인 서버 A와 가중치가 1인 서버 B가 있다면, 로드 밸런서는 A에게 B보다 약 3배 많은 트래픽을 전달한다. 구체적인 구현 방식은 가중치 라운드 로빈과 가중치 최소 연결 등으로 나뉜다. 가중치 라운드 로빈은 각 서버가 자신의 가중치 수만큼 연속적으로 요청을 받은 후 다음 서버로 순회하는 방식이다.

이 방법은 이기종 환경에서 효과적이다. 고성능 신규 서버에는 높은 가중치를, 구형 또는 성능이 낮은 서버에는 낮은 가중치를 부여함으로써 리소스를 효율적으로 활용할 수 있다. 그러나 가중치 기반 알고리즘도 정적 알고리즘의 공통적인 한계를 지닌다. 서버의 실시간 부하 상태(예: CPU 사용률, 메모리 사용량)나 현재 연결의 응답 시간은 고려하지 않는다. 따라서 서버의 성능이 예상과 다르거나 장애가 발생했을 때는 관리자가 수동으로 가중치를 조정해야 한다.

IP 해시 알고리즘은 클라이언트의 IP 주소를 기반으로 특정 서버로 연결을 고정시키는 정적 부하 분산 방식이다. 이 알고리즘의 핵심은 해시 함수를 사용하여 클라이언트의 IP 주소 (일반적으로 출발지 IP)를 입력값으로 받아, 그 결과를 서버 풀의 인덱스로 매핑하는 것이다. 동일한 클라이언트 IP에서 발생하는 요청은 항상 동일한 해시 값을 생성하므로, 일정 기간 동안 같은 백엔드 서버로 라우팅된다.

이 방식의 주요 목적은 세션 지속성을 보장하는 것이다. 사용자 세션 데이터가 특정 서버의 메모리에 저장되는 상태 저장 애플리케이션에서 유용하게 적용된다. 클라이언트의 요청이 매번 다른 서버로 분산될 경우, 세션 정보를 찾을 수 없는 문제가 발생할 수 있다. IP 해시를 사용하면 클라이언트가 연결을 유지하는 동안 동일한 서버와 상호작용할 수 있어, 이러한 문제를 해결한다.

그러나 이 알고리즘에는 몇 가지 주의할 점이 존재한다. 첫째, 클라이언트가 NAT 게이트웨이 또는 프록시 서버 뒤에 다수 존재할 경우, 여러 최종 사용자가 동일한 공인 IP 주소로 나타난다. 이는 모든 사용자 트래픽이 단일 서버로 향하게 되어 부하 분산이 제대로 이루어지지 않고 특정 서버에 과부하가 걸릴 수 있다. 둘째, 서버 풀의 구성이 변경되면 (예: 서버 추가 또는 제거) 해시 함수의 결과 분포가 크게 바뀌어 대부분의 클라이언트 연결이 다른 서버로 재할당될 수 있다. 이는 세션 일관성을 깨뜨릴 위험이 있다.

일반적으로 IP 해시는 서버 수가 안정적이고, 클라이언트가 직접적인 IP를 사용하는 내부 네트워크 환경 또는 세션 일관성이 매우 중요한 특정 애플리케이션에서 선택된다.

최소 연결 알고리즘은 동적 부하 분산 방식의 대표적인 예시이다. 이 알고리즘은 클라이언트의 새로운 요청을 처리할 서버를 선택할 때, 현재 활성화된 연결 수가 가장 적은 서버를 선택하는 방식을 취한다. 이는 각 서버의 실시간 부하 상태를 간접적으로 반영하여, 처리 능력이 다른 서버들 간에 부하를 보다 공정하게 분배하는 것을 목표로 한다.

기본 원리는 단순하다. 로드 밸런서는 백엔드 서버 풀에 속한 각 서버가 현재 처리 중인 연결(예: TCP 연결 또는 HTTP 세션) 수를 지속적으로 추적한다. 새로운 요청이 들어오면, 로드 밸런서는 이 연결 카운트를 확인하여 가장 낮은 수치를 가진 서버로 요청을 전달한다. 이 방식은 이미 많은 요청을 처리 중인 서버에 추가 부담을 주지 않으면서, 상대적으로 한가한 서버를 효율적으로 활용하도록 설계되었다.

최소 연결 알고리즘은 서버의 처리 능력이 균일하지 않은 환경에서 특히 유용하다. 예를 들어, 서버의 사양이 다르거나 동일한 서버라도 백그라운드 작업으로 인해 일시적으로 처리 용량에 차이가 생길 수 있다. 이 알고리즘은 단순히 요청 횟수만을 고정적으로 나누는 라운드 로빈 방식보다 이러한 실시간 상태 차이를 고려할 수 있다. 또한, 장시간 지속되는 연결(예: 파일 전송, 실시간 스트리밍)이 많은 경우, 각 연결이 서버에 미치는 부하가 크므로 연결 수를 기준으로 분산하는 것이 합리적이다.

성능과 한계 측면에서, 최소 연결 알고리즘은 일반적으로 정적 알고리즘보다 더 균형 잡힌 부하 분산을 달성한다. 그러나 이 알고리즘은 단순히 '연결 수'만을 기준으로 삼기 때문에, 연결당 실제 소모되는 CPU나 메모리 사용량 같은 세부적인 리소스 지표는 고려하지 않는다. 따라서 모든 연결이 동일한 부하를 생성한다는 가정 하에 최적의 성능을 발휘한다. 이 한계를 보완하기 위해, 서버의 성능 가중치를 연결 수에 반영하는 '가중 최소 연결' 알고리즘 같은 변형이 사용되기도 한다.

최소 응답 시간 알고리즘은 동적 부하 분산 알고리즘의 한 종류로, 클라이언트 요청을 처리하는 데 가장 짧은 시간이 걸릴 것으로 예상되는 서버로 트래픽을 전달하는 방식을 말한다. 이 알고리즘의 핵심 목표는 사용자가 체감하는 서비스 응답 속도를 최적화하여 전반적인 사용자 경험을 향상시키는 것이다. 이를 위해 로드 밸런서는 각 서버의 실시간 성능 메트릭, 특히 과거 응답 시간이나 현재 연결의 처리 상태를 지속적으로 모니터링하고 분석한다.

알고리즘의 구체적인 동작 방식은 구현에 따라 다르지만, 일반적으로 로드 밬런서는 각 서버에 대한 헬스 체크 요청을 주기적으로 보내 응답 시간을 측정한다. 또는 실제 애플리케이션 요청이 처리되는 데 걸린 시간을 샘플링하여 기록하기도 한다. 새 요청이 들어오면, 로드 밸런서는 이 성능 데이터를 기반으로 가장 빠르게 응답할 가능성이 높은 서버를 선택한다. 이 과정은 시스템 부하가 변함에 따라 동적으로 이루어지므로, 일시적으로 높은 부하를 받아 응답이 느려진 서버는 자동으로 트래픽 배분에서 제외되는 효과가 있다.

최소 응답 시간 알고리즘의 효과는 워크로드의 특성에 크게 의존한다. 서버 간 성능 차이가 크거나, 처리하는 요청의 유형(예: 간단한 API 호출 vs. 복잡한 보고서 생성)에 따라 소요 시간이 극명하게 다른 환경에서 특히 유용하다. 또한, 서버의 하드웨어 사양이 다른 이기종 환경에서도 공정한 부하 분산을 달성하는 데 도움을 준다.

하지만 이 방식은 로드 밬런서가 각 서버의 성능을 지속적으로 추적하고 계산해야 하므로 추가적인 오버헤드가 발생한다. 또한, 매우 짧은 시간 안에 서버 응답 시간이 급변하는 경우 알고리즘이 이를 즉시 반영하지 못해 최적이 아닌 라우팅 결정을 내릴 수도 있다. 이러한 특성으로 인해, 이 알고리즘은 실시간 성능 모니터링 인프라가 잘 구축된 환경에서 가장 효과적으로 작동한다.

리소스 기반 분산은 서버의 실시간 시스템 리소스 사용량을 기준으로 부하를 할당하는 동적 알고리즘이다. 이 방식은 서버의 CPU 사용률, 메모리 사용량, 활성 연결 수, 네트워크 대역폭 등 다양한 성능 메트릭을 지속적으로 모니터링하여 가장 여유 리소스가 많은 서버로 새 요청을 전달한다. 단순히 연결 수만 고려하는 최소 연결 알고리즘보다 더 정교하게 서버의 실제 부하 상태를 반영한다는 점이 특징이다.

이 알고리즘의 핵심은 에이전트나 모니터링 도구를 통해 각 서버로부터 리소스 데이터를 주기적으로 수집하고, 이를 가중치로 변환하여 의사 결정에 활용하는 것이다. 예를 들어, CPU 사용률이 20%인 서버 A와 80%인 서버 B가 있을 경우, 새 클라이언트 요청은 상대적으로 한가한 서버 A로 우선적으로 라우팅된다. 리소스 지표는 단독으로 또는 조합되어 사용될 수 있으며, 시스템 관리자가 각 지표에 대한 중요도(가중치)를 설정할 수 있다.

이 방법은 서버의 성능 이질성이 크거나, 요청의 처리에 필요한 리소스가 크게 변동하는 환경에서 특히 효과적이다. 그러나 지속적인 모니터링으로 인한 오버헤드가 발생하며, 리소스 데이터를 수집하고 분석하는 데 약간의 지연이 생길 수 있다. 따라서 매우 빠른 단위 시간 내에 수많은 요청이 들어오는 환경에서는 다른 동적 알고리즘과 함께 혼용되거나, 모니터링 주기를 신중하게 조정해야 한다.

콘텐츠 기반 라우팅은 애플리케이션 계층에서 HTTP 요청의 내용을 분석하여 특정 조건에 맞는 백엔드 서버로 트래픽을 전달하는 부하 분산 방식이다. 이 방식은 요청의 URL 경로, 쿼리 문자열, HTTP 헤더, 또는 요청 본문의 데이터와 같은 애플리케이션 수준의 정보를 기반으로 라우팅 결정을 내린다. 예를 들어, /images/ 경로로 시작하는 요청은 이미지 전용 서버 풀로, /api/v1/ 경로의 요청은 특정 버전의 API 서버 풀로 보낼 수 있다.

이 알고리즘의 주요 장점은 요청의 특성에 따라 최적의 서버를 선택할 수 있어 효율성을 높인다는 점이다. 특정 유형의 콘텐츠를 처리하도록 최적화된 서버에 해당 요청을 집중시킴으로써 캐시 적중률을 높이고, 서버의 전문성을 활용할 수 있다. 또한, 마이크로서비스 아키텍처에서 특정 서비스의 엔드포인트로 요청을 라우팅하는 데 필수적으로 사용된다.

구현 방식은 일반적으로 다음과 같은 조건부 규칙을 설정하는 형태를 취한다.

이 방식은 더 복잡한 로직을 구현할 수 있지만, 요청 내용을 분석해야 하므로 정적 부하 분산 알고리즘에 비해 약간의 오버헤드가 발생할 수 있다. 또한, 규칙 설정이 복잡해질수록 관리 부담이 증가하고, 잘못된 구성은 특정 서버에 과부하를 초래하거나 라우팅 오류를 일으킬 수 있다.

세션 지속성은 동일한 클라이언트의 요청을 일정 시간 동안 동일한 백엔드 서버로 연결하는 기법이다. 이를 통해 클라이언트의 상태 정보를 유지하거나, 특정 서버에 캐시된 데이터를 효율적으로 활용할 수 있다. 이 기법은 라운드 로빈이나 최소 연결과 같은 일반적인 알고리즘과 함께 사용되며, 주로 온라인 쇼핑 카트, 로그인 정보, 게임 진행 상태 등 상태 유지가 필요한 애플리케이션에서 중요하게 적용된다.

세션 지속성을 구현하는 주요 방법은 다음과 같다.

이러한 지속성은 설정된 타임아웃 시간 동안 유지되며, 서버 장애 시 로드 밸런서는 새로운 서버를 선택하고 세션 정보를 이전해야 하는 과제를 안게 된다. 따라서 세션 지속성은 애플리케이션의 일관성과 사용자 경험을 보장하는 핵심 기능이지만, 서버의 자원 사용을 고르게 분산시키는 데는 제약이 될 수 있다.

자동 확장은 클라우드 환경에서 부하 분산의 핵심적인 동반자 역할을 한다. 부하 분산기가 트래픽을 여러 서버 인스턴스에 분배하는 동안, 자동 확장 정책은 실시간 부하 지표를 모니터링하며 백엔드 리소스 풀의 크기를 동적으로 조정한다. 이 두 메커니즘이 긴밀하게 연동되어 애플리케이션의 성능 목표를 유지하면서도 인프라 비용을 최적화한다.

일반적인 연동 방식은 다음과 같다. 부하 분산기는 CPU 사용률, 네트워크 트래픽, 초당 요청 수 등의 메트릭을 수집한다. 이 데이터는 자동 확장 그룹의 정책 엔진으로 전달된다. 사전에 정의된 임계값을 기준으로, 예를 들어 평균 CPU 사용률이 70%를 초과하면 새로운 가상 머신 인스턴스를 생성하여 풀에 추가한다. 반대로 부하가 일정 수준 이하로 떨어지면 인스턴스를 순차적으로 종료하여 불필요한 비용을 절감한다. 이 과정에서 부하 분산기는 새로 생성된 인스턴스를 자동으로 백엔드 대상으로 등록하고, 종료되는 인스턴스는 연결을 드레이닝한 후 풀에서 제거한다.

주요 클라우드 제공업체들은 이 연동을 위한 통합 서비스를 제공한다. AWS의 경우 Elastic Load Balancing (ELB)과 Auto Scaling Group (ASG)이, Google Cloud에서는 Cloud Load Balancing과 Instance Group의 자동 확장 기능이, Microsoft Azure에서는 Azure Load Balancer 또는 Application Gateway와 Virtual Machine Scale Sets가 대표적인 조합이다. 이러한 통합은 관리 콘솔이나 IaC 도구를 통해 정책을 설정함으로써 구현된다.

효과적인 연동을 위해서는 몇 가지 고려 사항이 있다. 첫째, 인스턴스의 부트스트랩 시간을 고려한 확장 정책이 필요하다. 새 인스턴스가 완전히 애플리케이션을 로드하고 서비스를 시작할 때까지는 부하 분산 풀에 추가하지 않도록 헬스 체크를 구성해야 한다. 둘째, 급격한 트래픽 증가 시 인스턴스 생성 속도가 수요를 따라가지 못하는 '확장 지연'을 방지하기 위해 예측적 확장이나 충분한 최소 인스턴스 수를 설정한다. 셋째, 애플리케이션의 상태를 저장하지 않는 Stateless 설계가 선호되는데, 이는 어떤 인스턴스로든 요청이 라우팅되어도 무관하게 하기 위함이다.

서버리스 아키텍처에서는 전통적인 서버 인스턴스의 개념이 사라지거나 추상화된다. 따라서 부하 분산의 대상이 고정된 가상 머신이나 컨테이너가 아니라, 개별 함수 실행이나 이벤트 트리거가 된다. 로드 밸런서의 역할은 주로 클라우드 제공자가 관리하는 플랫폼 자체에 내장되어, 들어오는 요청이나 이벤트를 자동으로 여러 함수 인스턴스로 분산시킨다.

부하 분산의 핵심은 자동 확장과 긴밀하게 연동된다. 트래픽이 증가하면 플랫폼은 새로운 함수 실행 환경(컨테이너)을 즉시 생성하여 부하를 분담한다. 반대로 트래픽이 줄어들면 유휴 상태의 환경을 제거한다. 이 과정에서 사용자는 인프라 용량을 프로비저닝하거나 관리할 필요가 없다. 알고리즘은 일반적으로 요청을 사용 가능한 실행 환경에 최대한 빠르게 전달하는 것을 목표로 하며, 지연 시간을 최소화하는 데 중점을 둔다.

서버리스 환경에서의 부하 분산은 몇 가지 고유한 특징을 가진다.

• 콜드 스타트: 함수가 오랫동안 호출되지 않아 실행 환경이 종료된 후, 새로운 요청이 들어올 때 발생하는 초기화 지연이다. 부하 분산기는 콜드 스타트를 최소화하기 위해 자주 호출되는 함수의 환경을 미리 준비해 두거나, 요청을 이미 실행 중인 '따뜻한' 환경으로 우선 라우팅할 수 있다.

• 동시성 제한: 각 함수는 일반적으로 동시에 실행할 수 있는 인스턴스 수에 제한이 있다. 부하 분산기는 이 제한을 초과하는 요청이 발생하면 큐에 대기시키거나 오류를 반환해야 한다.

• 이벤트 소스 통합: 요청은 API 게이트웨이, 메시지 큐, 객체 저장소 이벤트 등 다양한 소스에서 발생한다. 각 이벤트 소스는 내부적으로 트래픽을 함수로 분산시키는 자체적인 메커니즘을 갖는다.

결국 서버리스에서의 부하 분산은 개발자에게서 인프라 관리 부담을 거의 완전히 제거하고, 플랫폼 공급자에게 그 책임을 이전한다. 사용자는 함수 코드와 원하는 확장 제한 설정에만 집중하면 되며, 나머지 분산 및 확장 작업은 AWS Lambda, Azure Functions, Google Cloud Functions 같은 관리형 서비스가 처리한다.

처리량은 단위 시간당 시스템이 성공적으로 처리하는 요청의 수를 의미한다. 일반적으로 초당 요청 수(RPS) 또는 초당 트랜잭션 수(TPS)로 측정된다. 높은 처리량은 시스템이 많은 동시 사용자를 효율적으로 수용할 수 있음을 나타내며, 이는 부하 분산 알고리즘의 주요 목표 중 하나이다. 알고리즘의 효율성, 백엔드 서버의 성능, 네트워크 대역폭 등이 처리량에 영향을 미치는 주요 요소이다.

지연 시간은 클라이언트가 요청을 보낸 시점부터 응답을 받을 때까지 걸리는 총 시간을 말한다. 이는 네트워크 왕복 시간, 서버 처리 시간, 로드 밸런서의 큐잉 및 라우팅 지연을 모두 포함한다. 사용자 경험에 직접적인 영향을 미치는 핵심 지표이며, 특히 실시간 애플리케이션에서는 매우 중요하게 고려된다.

두 지표는 일반적으로 트레이드오프 관계에 있다. 무작위 또는 간단한 라운드 로빈 알고리즘은 결정 속도가 빨라 지연 시간을 줄일 수 있지만, 서버의 실제 부하 상태를 고려하지 않아 처리량이 저하될 수 있다. 반면, 최소 연결이나 최소 응답 시간 같은 동적 알고리즘은 서버 상태를 모니터링하고 계산하는 추가 오버헤드로 인해 약간의 지연을 유발할 수 있지만, 더 균형 잡힌 분산을 통해 전체 시스템의 처리량을 최대화할 수 있다.

성능 평가는 다양한 부하 조건 하에서 이 두 지표를 종합적으로 측정하여 이루어진다. 일반적인 평가 방법은 다음과 같다.

따라서 효과적인 부하 분산 전략은 애플리케이션의 특성과 서비스 수준 목표에 맞춰 처리량과 지연 시간 사이의 최적의 균형점을 찾는 것이다.

가용성은 시스템이 정상적으로 서비스를 제공할 수 있는 시간의 비율을 의미한다. 일반적으로 퍼센트로 표현되며, 99.9%의 가용성은 연간 약 8.76시간의 다운타임을 허용한다는 것을 뜻한다. 부하 분산은 가용성을 높이는 핵심 메커니즘으로, 하나의 서버에 장애가 발생하더라도 다른 정상 서버로 트래픽을 자동으로 전환하여 서비스 중단을 방지한다. 이를 위해 헬스 체크는 정기적으로 서버의 상태를 모니터링하여 실패한 인스턴스를 풀에서 제외하는 역할을 한다.

내결함성은 시스템의 일부 구성 요소에 결함이 발생했을 때 전체 서비스가 중단되지 않고 정상적으로 운영될 수 있는 능력을 말한다. 부하 분산 알고리즘은 내결함성을 구현하는 데 필수적이다. 예를 들어, 동적 부하 분산 알고리즘 중 하나인 최소 연결 알고리즘은 실시간으로 서버의 부하 상태를 고려하므로, 특정 서버의 성능 저하나 부분적 장애 시 해당 서버로의 새 연결을 최소화하는 효과가 있다. 이는 장애를 회피하는 능동적인 내결함 메커니즘으로 작동한다.

가용성과 내결함성을 보장하기 위한 일반적인 부하 분산 전략은 다음과 같다.

궁극적으로, 효과적인 부하 분산은 단순한 트래픽 분배를 넘어 시스템의 전반적인 신뢰성을 구성하는 기반이 된다. 가용성과 내결함성 목표를 달성하기 위해서는 알고리즘 선택, 헬스 체크 정책, 장애 복구 절차가 통합적으로 설계되어야 한다.

하드웨어 로드 밸런서는 부하 분산 기능을 수행하는 전용 네트워크 장비이다. 이 장치는 일반적으로 ASIC이나 FPGA와 같은 특수 목적 집적 회로를 사용하여 네트워크 트래픽을 처리한다. 주요 목적은 고성능, 저지연, 그리고 높은 신뢰성을 제공하는 것이며, 특히 초당 수백만 건의 연결을 처리해야 하는 대규모 데이터 센터나 엔터프라이즈 환경에서 널리 사용된다.

하드웨어 로드 밸런서는 일반적으로 OSI 모델의 4계층(전송 계층)과 7계층(응용 계층)에서 동작한다. 4계층 로드 밸런싱은 IP 주소와 포트 번호 같은 네트워크 정보를 기반으로 트래픽을 분산하는 반면, 7계층 로드 밸런싱은 HTTP 헤더, URL, 쿠키와 같은 애플리케이션 데이터의 내용을 검사하여 더 정교한 라우팅 결정을 내릴 수 있다. 이는 콘텐츠 기반 라우팅이나 SSL/TLS 종료와 같은 고급 기능을 가능하게 한다.

주요 장점은 다음과 같다.

* 고성능: 전용 하드웨어로 최적화되어 매우 높은 처리량과 낮은 지연 시간을 제공한다.

* 보안: 내장된 방화벽, DDoS 공격 방어, 침입 탐지 시스템 등의 보안 기능을 통합하는 경우가 많다.

* 안정성: 이중화 구성과 자동 장애 조치 기능을 통해 높은 가용성을 보장한다.

하지만 초기 구매 비용이 높고, 유연성이 상대적으로 떨어지는 단점이 있다. 새로운 기능이나 프로토콜을 지원하려면 펌웨어 업그레이드나 때로는 하드웨어 교체가 필요할 수 있다. 주요 공급업체로는 F5 Networks, 시트릭스 시스템즈, 라드웨어 등이 있다.

소프트웨어 로드 밸런서는 전용 하드웨어 장비가 아닌 범용 서버 하드웨어 위에서 소프트웨어 형태로 실행되는 부하 분산 솔루션이다. 주로 가상 머신이나 컨테이너 환경에서 애플리케이션으로 배포되어 운영된다. 이 방식은 x86 아키텍처와 같은 표준 서버와 리눅스 또는 윈도우 서버 운영체제를 기반으로 하여, 네트워크 트래픽을 백엔드 서버 풀에 분배하는 기능을 제공한다.

주요 구현 방식으로는 애플리케이션 내에 라이브러리 형태로 임베드되는 방식, 독립적인 프록시 서버로 동작하는 방식, 그리고 리눅스 커널의 넷필터나 IPVS 같은 기능을 활용하는 방식이 있다. 대표적인 오픈소스 소프트웨어 로드 밸런서로는 Nginx, HAProxy, Apache HTTP Server의 mod_proxy_balancer 모듈, 그리고 리눅스 가상 서버가 있다. 상용 제품으로는 F5 Networks의 BIG-IP 소프트웨어 에디션이나 VMware의 NSX 로드 밸런서 등이 존재한다.

소프트웨어 로드 밸런서의 주요 장점은 다음과 같다.

단점으로는 전용 하드웨어에 비해 절대적인 성능과 처리량에서 제한이 있을 수 있으며, 소프트웨어의 안정성과 보안 패치를 직접 관리해야 하는 운영 부담이 발생한다. 또한, 고가용성을 위해 액티브-스탠바이 또는 액티브-액티브 클러스터 구성이 필요하며, 이는 추가적인 설정 복잡성을 유발한다.