로드 밸런싱(Load Balancing)

둘 이상의 CPU or 저장장치와 같은 컴퓨터 자원들에게 작업을 나누는 것

많은 사람들에 대해 모든 트래픽을 감당하기엔 1대의 서버로는 부족하다. 대응 방안으로 하드웨어의 성능을 올리거나(Scale-up) 여러대의 서버가 나눠서 일하도록 만드는 것(Scale-out)이 있다. 하드웨어 향상 비용이 더욱 비싸기도 하고, 서버가 여러대면 무중단 서비스를 제공하는 환경 구성이 용이하므로 Scale-out이 효과적이다. 이때 여러 서버에게 균등하게 트래픽을 분산시켜주는 것이 바로 로드 밸런싱이다.

로드 밸런싱은 분산식 웹 서비스로, 여러 서버에 부하(Load)를 나누어주는 역할을 한다. Load Balancer를 클라이언트와 서버 사이에 두고, 부하가 일어나지 않도록 여러 서버에 분산시켜주는 방식이다. 서비스를 운영하는 사이트의 규모에 따라 웹 서버를 추가로 증설하면서 로드 밸런서로 관리해주면 웹 서버의 부하를 해결할 수 있다.

로드 밸런서가 서버를 선택하는 방식

• 라운드 로빈(Round Robin) : CPU 스케줄링의 라운드 로빈 방식 활용
• Least Connections : 연결 개수가 가장 적은 서버 선택 (트래픽으로 인해 세션이 길어지는 경우 권장)
• Source : 사용자 IP를 해싱하여 분배 (특정 사용자가 항상 같은 서버로 연결되는 것 보장)

로드 밸런서 장애 대비

서버를 분배하는 로드 밸런서에 문제가 생길 수 있기 때문에 로드 밸런서를 이중화하여 대비한다.

Active 상태와 Passive 상태

로드 밸런서 이중화는 로드 밸런서의 가용성과 신뢰성을 높이기 위한 방법 중 하나입니다. 이중화는 메인 로드 밸런서와 백업 로드 밸런서를 구성하여, 메인 로드 밸런서에 장애가 발생한 경우에도 서비스에 영향을 미치지 않도록 하는 방식입니다.

로드 밸런서 이중화를 구현하는 방법으로는 다음과 같은 것들이 있습니다.

1. Active-Standby 방식: 메인 로드 밸런서와 백업 로드 밸런서 중 하나만 활성화되어 있는 방식입니다. 메인 로드 밸런서에 장애가 발생하면 백업 로드 밸런서가 활성화되어 서비스를 지속합니다. 이 방식은 구현이 간단하고, 대체 로드 밸런서가 실시간으로 서비스 요청을 처리하지 않기 때문에 비용이 낮습니다.

2. Active-Active 방식: 여러 대의 로드 밸런서가 모두 활성화되어 있는 방식입니다. 모든 로드 밸런서가 동시에 서비스 요청을 처리하며, 어느 하나의 로드 밸런서에 장애가 발생하면 다른 로드 밸런서들이 처리합니다. 이 방식은 대규모 서비스에서 많이 사용되며, 로드 밸런서가 여러 대인 만큼 확장성과 성능이 높습니다.

3. N+1 방식: 메인 로드 밸런서와 백업 로드 밸런서가 동시에 활성화되어 있는 방식입니다. 메인 로드 밸런서에 장애가 발생하면, 백업 로드 밸런서 중에서 하나를 대체 로드 밸런서로 선정하여 활성화합니다. 이 방식은 비용이 많이 들지만, 대규모 서비스에서는 신뢰성과 가용성을 높이기 위해 적극적으로 사용됩니다.

로드 밸런서 이중화를 구성하면, 메인 로드 밸런서에 장애가 발생했을 때도 서비스가 지속될 수 있어, 서비스 신뢰성과 가용성을 보장할 수 있습니다. 하지만, 로드 밸런서 이중화를 구성할 때는 구성 방식에 따라 비용, 구현 복잡도 등의 문제가 발생할 수 있으므로, 상황에 맞는 방법을 선택하여 구성해야 합니다.

N+1, Active-Active

"이중화"는 기본적으로 서버나 네트워크 구성 요소가 실패했을 때 백업 구성 요소가 동작을 이어받아 서비스 중단을 최소화하는 방법을 의미합니다. 여기서 N+1 기법과 Active-Active 기법은 이중화를 구현하는 두 가지 다른 전략입니다.

1. N+1 기법: 이 방식은 'N'개의 작동 중인 서버와 '1'개의 대기 중인 백업 서버로 구성됩니다. 즉, N+1 기법은 N개의 서버가 정상적으로 동작하고 있을 때, 어떤 문제가 생기면 추가로 준비된 1개의 백업 서버가 그 역할을 대신 수행합니다. 이 방식은 비용 효율적이며, 서비스를 중단 없이 유지할 수 있지만, 백업 서버가 동작하지 않는 동안에는 이용되지 않는 자원이 됩니다.

   N+1 기법에서 "N"은 작동 중인 서버(혹은 다른 장비)의 수를 나타내고, "+1"은 추가로 대기하고 있는 백업 장비를 나타냅니다.

   여기서 "메인 로드 밸런서와 백업 로드 밸런서가 동시에 활성화되어 있는 방식"은 일반적으로 Active-Standby 또는 Active-Passive라고 불립니다. 이 방식에서, 메인 로드 밸런서(Active)는 일반적으로 모든 트래픽을 처리하며, 백업 로드 밸런서(Standby 또는 Passive)는 메인 로드 밸런서가 실패했을 때 그 역할을 대체합니다.

   따라서, 서버에 장애가 발생하면, 백업 로드 밸런서가 활성화되어 서비스 중단 없이 트래픽을 처리하는 것은 N+1 이중화 전략의 일반적인 예입니다. 이 방법은 신뢰성과 가용성을 향상시키지만, 백업 로드 밸런서가 대기 상태로 있을 때는 이용되지 않는 자원이 될 수 있다는 단점이 있습니다.

2. Active-Active 기법: 이 방식은 모든 서버가 동시에 활성화되고, 모든 서버가 요청을 처리합니다. 즉, 모든 서버가 동일한 역할을 수행하며, 하나 또는 그 이상의 서버가 실패하더라도 남은 서버들이 요청을 계속 처리합니다. 이 방식은 리소스를 최대한 활용하고, 더 높은 가용성을 제공하지만, 이에 따른 비용이 더 많이 들 수 있습니다. 또한, 상태를 공유해야 하는 서비스에서는 동기화 문제를 해결하기 위한 추가적인 메커니즘이 필요할 수 있습니다.

따라서 두 기법은 각각의 장단점이 있으며, 사용하는 환경과 요구 사항에 따라 적합한 방법을 선택해야 합니다.

로드 밸런서 장애란?

로드 밸런서 장애는 대규모 서비스에서 매우 치명적인 문제가 될 수 있습니다. 로드 밸런서가 다운되면, 서버에 대한 요청 분배가 중단되므로 전체 서비스에 장애가 발생할 수 있습니다. 따라서 로드 밸런서 장애에 대비하여 적절한 대책을 마련해야 합니다.

로드 밸런서 장애에 대비하는 방법으로는 다음과 같은 것들이 있습니다.

1. 백업 로드 밸런서 구성: 메인 로드 밸런서에 문제가 발생한 경우, 대체할 수 있는 백업 로드 밸런서를 구성합니다. 이를 통해 서버 요청 분배 기능을 계속할 수 있습니다.

2. 로드 밸런서 클러스터 구성: 로드 밸런서 클러스터를 구성하여, 여러 대의 로드 밸런서가 서로 백업 서버 역할을 수행하도록 설정합니다. 이를 통해 로드 밸런서의 가용성과 신뢰성을 높일 수 있습니다.

3. DNS 라운드 로빈 설정: DNS 서버에서 라운드 로빈 방식을 이용하여 여러 대의 로드 밸런서 IP 주소를 반환하도록 설정합니다. 이를 통해 로드 밸런서 다운 시, DNS 서버가 다른 IP 주소를 반환하여 요청을 분배할 수 있습니다.

4. 클라우드 서비스 활용: 클라우드 서비스를 사용하면, 서버 인프라 관리와 로드 밸런싱 기능을 클라우드 업체가 대신 수행할 수 있습니다. 클라우드 서비스 업체는 자동으로 서버 스케일링과 로드 밸런싱 기능을 수행하므로, 로드 밸런서 장애 대비에 매우 유용합니다.

로드 밸런서 장애 대비는 서비스 신뢰성을 보장하기 위해 꼭 필요한 과제 중 하나입니다. 따라서 적극적으로 대비하고, 문제가 발생했을 때 빠르게 대처할 수 있는 시스템을 마련해야 합니다.

로드 밸런싱

• 로드 밸런싱은 네트워크 상에서 발생하는 트래픽 부하를 여러 대의 서버에 분산시켜 처리하는 기술입니다. 이를 통해 서버의 가용성과 성능을 높일 수 있으며, 단일 서버에서 처리하기 어려운 대규모 트래픽을 처리할 수 있습니다.

• 로드 밸런서는 네트워크 전면에 위치하며, 클라이언트 요청을 여러 대의 서버로 분산시킵니다. 이때 분산 알고리즘을 이용하여 각 서버에 할당되는 부하를 균등하게 분배하거나, 특정 서버에 대한 요청을 더 많이 분배할 수 있습니다. 또한, 로드 밸런서는 서버의 가용성을 체크하고, 문제가 발생한 서버에 대한 요청을 다른 서버로 자동으로 전달하는 기능도 가지고 있습니다.

• 로드 밸런싱은 서버 확장성과 가용성을 높이기 위한 기술로 널리 사용되고 있으며, 대규모 웹 사이트나 애플리케이션에서 필수적인 기술 중 하나입니다.

라운드 로빈, Least Connections, Source

• 라운드 로빈(Round Robin)은 로드 밸런싱 알고리즘 중 하나로, 각 서버에 동일한 수의 요청을 순차적으로 분배하는 방식입니다.

• 라운드 로빈 방식은 가장 간단하고 직관적인 방식 중 하나로, 모든 서버에 대한 부하 분배가 공평하게 이루어집니다. 예를 들어, 3대의 서버가 있다면, 첫 번째 요청은 첫 번째 서버로, 두 번째 요청은 두 번째 서버로, 세 번째 요청은 세 번째 서버로 분배되는 방식입니다.

• 라운드 로빈 방식은 구현이 간단하고, 각 서버에 대한 부하 분배가 균등하게 이루어지기 때문에 일반적으로 널리 사용됩니다. 그러나, 서버의 사양이나 성능 차이가 큰 경우, 라운드 로빈 방식은 비효율적일 수 있으며, 부하 분배가 공평하지 않을 수 있습니다. 이러한 경우에는 가중 라운드 로빈 방식 등 다른 로드 밸런싱 알고리즘을 고려해 볼 수 있습니다.

1. Least Connections와 Source 기반 로드 밸런싱은 둘 다 로드 밸런싱 알고리즘 중 하나입니다.

2. Least Connections 알고리즘은 현재 연결 수가 가장 적은 서버에 요청을 분배하는 방식입니다. 서버의 연결 수를 측정하여 가장 적은 연결 수를 가진 서버에 요청을 분배하기 때문에, 부하 분배가 균등하게 이루어질 수 있습니다. 그러나, 요청 처리 시간이 긴 경우, 연결 수가 적더라도 처리 시간이 길어질 수 있기 때문에, 이러한 상황에 대비하여 Timeout 값을 설정할 필요가 있습니다.

• Source 기반 로드 밸런싱은 클라이언트의 IP 주소나 포트 번호를 기반으로 분배하는 방식입니다. 각 클라이언트의 IP 주소나 포트 번호를 해시 함수에 적용하여, 고정된 범위의 서버에 요청을 분배하는 방식입니다. 이 방식은 특정 클라이언트가 항상 동일한 서버에 연결될 수 있도록 보장하며, 이를 통해 세션 유지 등과 같은 기능을 구현할 수 있습니다. 그러나, 클라이언트의 IP 주소나 포트 번호가 변경되는 경우, 부하 분배가 균등하지 않을 수 있습니다. 이러한 경우에는 Sticky Session 등 다른 방식을 고려해 볼 수 있습니다.

가중 라운드 로빈, Sticky Session

• 가중 라운드 로빈(Weighted Round Robin)은 라운드 로빈 방식의 변형 알고리즘으로, 서버의 가중치를 설정하여 요청을 분배하는 방식입니다. 서버의 성능이나 사양이 다른 경우, 각 서버에 가중치를 부여하여 부하 분배가 균등하게 이루어질 수 있습니다. 예를 들어, 가중치가 2, 3, 5인 3대의 서버가 있다면, 첫 번째 서버에는 2개의 요청을, 두 번째 서버에는 3개의 요청을, 세 번째 서버에는 5개의 요청을 분배하는 방식입니다.

• Sticky Session은 Source 기반 로드 밸런싱과 함께 사용되는 방식 중 하나로, 클라이언트의 요청이 항상 동일한 서버로 전달되도록 보장하는 방식입니다. 클라이언트의 요청에 따라 특정 서버에 세션 정보를 저장하고, 이후에 해당 클라이언트의 요청이 오면 저장된 세션 정보를 참조하여 항상 동일한 서버로 요청을 전달하는 방식입니다.

• Sticky Session은 로그인 상태 등의 세션 정보를 유지해야 하는 경우, 세션 정보를 동일한 서버에서 처리할 수 있도록 보장하는 기술로 많이 사용됩니다. 그러나, 서버 간 부하 분배가 균등하지 않을 수 있고, 서버의 장애 등으로 인해 세션 정보를 저장하고 있는 서버가 다운되는 경우 문제가 발생할 수 있으므로, 이러한 상황에 대비하여 적절한 대책을 마련해야 합니다.

적절한 대책이란?

서버 다운이 발생하는 경우에 대비하여 적절한 대책을 마련해야 합니다. 일반적으로는 다음과 같은 방법들이 사용됩니다.

1. 헬스 체크(Health Check) 기능 사용: 로드 밸런서는 일정한 간격으로 각 서버에 대해 헬스 체크를 수행하여 서버의 상태를 확인합니다. 만약 서버가 다운된 상태라면 해당 서버로의 요청을 차단하고, 다른 서버에게 요청을 분배합니다.

2. 재시작 자동화: 서버 다운이 발생하는 경우, 로드 밸런서는 자동으로 해당 서버를 재시작하거나 다른 서버에 대한 요청 분배를 조정합니다.

3. 백업 서버 구성: 로드 밸런서는 여러 대의 백업 서버를 구성하여, 메인 서버의 다운 시점에 대비할 수 있습니다. 메인 서버의 다운이 발생하면, 백업 서버 중 하나가 대신 요청을 처리하도록 설정할 수 있습니다.

4. 클라우드 서비스 활용: 클라우드 서비스를 활용하면 서버 인프라 구성과 관리가 쉬워집니다. 클라우드 서비스 업체는 자동으로 서버의 스케일링과 부하 분산을 수행하므로, 서버 다운에 대한 대비가 자연스럽게 이루어집니다.

이 외에도, 서버 다운 대비를 위해 서버 구성, 네트워크 구성, 모니터링, 로깅 등 다양한 방법들이 사용됩니다. 서버 다운 대비는 서비스 신뢰성과 가용성을 보장하기 위해 매우 중요한 과제 중 하나이며, 이를 위해 적극적으로 대비할 필요가 있습니다.

[참고자료]

• 링크

• 링크

출처

github gyoogle