로드밸런서(load balancer)와 고정세션(sticky session)

요즘 시스템은 다중화 설계에 대한 필요성이 중요해졌다.

다중화 설계할 때 가장 첫 번째로 고려해야 할 부분은 서버의 다중화이다. 서버를 여러 대로 구성했다면, 클라이언트의 요청을 해당 서버들에게 처리하도록 보내도록 로드 밸런서를 설정해야한다. 서버 다중화 + 로드 밸런서는 1 + 1 개념이라고 생각한다.

본 글에서는 로드 밸런서에 대해 알아보고 로드 밸런서에서 지원하는 기능 중 고정세션도 함께 알아보려고 한다.

---

로드 밸런서

둘 혹은 셋 이상의 중앙처리장치 또는 저장 장치와 같은 컴퓨터 자원에 트래픽을 분산하는 장치나 소프트웨어이다. 로드 밸런싱한다는 것은, 여러 서버나 리소스에 트래픽이나 작업을 분산한다는 것이다.

 

다음은 로드밸런서를 적용하지 않은 경우와 적용한 경우에 대한 그림이다.

https://www.geeksforgeeks.org/what-is-load-balancer-system-design/

서버는 여러 대로 구성은 하였지만, 로드 밸런서를 적용하지 않았을 때 사용자의 요청이 한 서버에 과도하게 몰리는 것을 볼 수 있다. 이렇게 되면 서버를 다중화 한 이유가 없을 뿐더러, 모든 요청을 다 받는 해당 서버는 과부하가 걸릴 수가 있다. 그렇기 때문에 우리는 로드 밸런서를 적용하여 사용자의 요청을 적절하게 분산시켜야 하는데 이에 대한 내용은 하기에 내용을 확인하자.

 

로드밸런서의 장점과 단점

장점

1. 가용성 : 로드 밸런서는 서버들을 모니터링 할 수 있기 때문에 서버 장애 또는 유지 관리로 인하여 서버의 사용이 불가능 하더라도 정상적인 서버로 요청을 라우팅하여 서비스 중단을 방지할 수 있다.

 

2. 확장성 : 트래픽의 변화에 따라 서버의 수를 동적으로 추가하거나 제거할 수 있기 때문에 시스템의 수평 확장을 유연하게 지원한다.

 

3. 보안 : SSL 종료와 같은 기능을 통해 트래픽을 암호화하여 보안을 강화할 수 있다. 웹 어플리케이션 방화벽(WAF), DDoS 방어 등의 보안 기능을 제공하여 악성 트래픽이나 공격으로부터 보호할 수 있다.

 

4. 성능 향상 : 로드 밸런서는 클라이언트의 요청을 여러 서버에 분배하기 때문에 서버의 처리 속도를 향상시킬 수 있다. 이는 어플리케이션의 성능을 최적화하고 응답 시간을 단축시킬 수 있다.

 

단점

1. 비용 : 로드밸런서를 도입하면 추가적인 비용이 발생한다. 고급 기능 제공 및 고가의 로드 밸런서를 사용하거나 고가용성을 위해 로드밸런서 이중화를 설정할 경우 인프라의 비용이 많이 증가하게 된다.

 

2. SPOF : 로드 밸런서 자체에 장애가 발생할 경우, 모든 서버로의 트래픽 분배가 중단되어 SPOF가 될 수 있다. 따라서 로드 밸런서를 이중화할 수 있도록 해야하는데 이는 비용이 증가할 수 있다.

 

3. 복잡성 : 로드 밸런서를 설정하고 관리하는 데 시간이 많이 소요될 수 있다. 로드 밸런싱 알고리즘, 세션 관리, 서버 모니터링 등 다양한 기능을 설정하고 유지보수할 때 관리는 복잡해질 수 있다.

 

로드 밸런서의 기능

트래픽 분산

위에 로드밸런서에 대한 내용과 동일하다. 

 

상태 모니터링

로드 밸런서는 서버 상태를 모니터링하여 서버의 장애 여부를 판단할 수 있다.

따라서 서버에 문제가 발생하거나, 서버를 업데이트 해야해서 사용할 수 없을 경우에 정상적으로 동작 중인 서버로 트래픽을 라우팅할 수 있도록 한다.

 

고정 세션(sticky session)

로드 밸런서가 동일한 클라이언트에서 들어오는 요청을 동일한 서버로 보내는 방법이다.

고정 세션은 상태(stateful) 아키텍처에서 주로 사용되는데, 이는 모든 사용자의 정보가 서버에 저장된다는 것을 의미한다. 고정 세션에 대한 내용은 밑에서 조금 더 자세하게 다룬다.

 

로드 밸런싱의 종류와 방법

로드 밸런서는 요청을 어떤 서버로 보낼 것인지를 결정하기 위해서는 다양한 방법이 존재하는데 한번 알아보자.

알고리즘

알고리즘은 정적 로드 밸런싱과 동적 로드 밸런싱으로 나뉜다.

정적 로드 밸런싱은 고정된 규칙을 따르며 서버 상태와 무관하며, 동적 로드 밸런싱은 트래픽을 분배하기 전에 서버의 상태를 검사하여 요청을 분배하는 방식이다.

 

정적 로드 밸런싱

1. 라운드 로빈 (Round Robin): 각 서버에 요청을 순차적으로 분배하는 알고리즘이다.

2. 가중 라운드 로빈 (Weighted Round Robin): 서버에 가중치를 설정하고 가중치에 따라 요청을 분배하는 알고리즘이다. 가중치가 높은 서버가 더 많은 요청을 받게 된다.

3. 소스 IP 해시 (Source IP Hash): 클라이언트의 IP주소를 기반으로 해시 값을 계산하여 특정 서버에 요청을 할당하는 알고리즘으로, 고정 세션을 유지할 때 유용하다.

 

동적 로드 밸런싱

1. 최소 연결 (Least Connections): 현재 연결 수가 가장 적은 서버에 요청을 분배하는 알고리즘이다. 

2. 가중 최소 연결 (Weighted Least Connections): 서버의 가중치를 설정하고, 각 서버의 연결수와 가중치를 고려하여 요청을 분배하는 알고리즘이다.

 

L4 로드 밸런싱

 

L7 로드 밸런싱

 

고정 세션의 동작 그리고 사용하면 안되는 상황

위에서 고정 세션은 로드 밸런서가 동일한 클라이언트에서 들어오는 요청을 동일한 서버로 보내는 방법이라고 설명하였다. 이해하기 쉽게 고정 세션을 사용하지 않았을 때 요청의 흐름을 보여주는 그림을 확인해보자.

먼저 User01 -> U1, User02 -> U2, Server01 -> S1, Server02 -> S2라고 표현하겠다.

로드 밸런서를 이용하여 사용자의 요청을 분산시켰다.

각 사용자의 요청이 들어올 때마다 로드 밸런서는 설정된 알고리즘에 따라 각 서버로 요청을 분산하여 처리하도록 보낸다.

이 과정에서 U1에 대한 세션과 상태 정보가 S1에 저장되어있고, U2에 대한 세션과 상태 정보는 S2에 저장되어있다고 해보자. U1이 다음 요청을 보내면 로드밸런서가 S2에 요청을 라우팅할 수 있다. 하지만 S2에는 U1의 세션 정보가 없기 때문에 요청이 실패하게 된다. U2에 대한 요청도 마찬가지로 요청이 S1으로 라우팅 되면 세션 정보를 찾을 수 없어 실패하게 된다.

 

위와 같이 동일한 클라이언트에서 들어오는 요청이 다른 서버로 라우팅될 수 있는 문제가 발생하기 때문에, 고정세션을 사용하여 문제를 해결한다. 다음은 고정 세션을 사용하였을 때 요청의 흐름을 보여주는 그림이다.

https://traefik.io/glossary/what-are-sticky-sessions/

처음에 U1이 서버에 요청을 보내면 로드밸런서가 알고리즘에 따라 S1으로 라우팅하고 S1은 해당 요청을 처리하게 된다. 그 후 U1이 또 다른 요청을 보낼 때, 로드밸런서는 고정 세션을 사용하여 S1으로 요청을 보낼 것이다. 이는 U2에 대한 요청도 동일하게 처리되며, 로드밸런서는 U2의 세션에 맞게 S2로 요청을 보내게 된다.

하지만 고정세션은 로드밸런서에 부담이 되는데 그 이유는 다음과 같다.

로드밸런서는 클라이언트와 서버의 매핑 정보를 유지해야 한다. 클라이언트의 요청을 특정 서버로 전달해야하기 때문에 각 클라이언트가 어느 서버와 연결되었는지에 대한 정보를 관리해야 한다. 클라이언트 수가 많을수록 가져야 할 매핑 정보가 많을테니 부담이 커진다.

 

상태(stateful) 아키텍처에서 고정 세션을 사용하는데, 고정 세션을 피해야 하는 상황은 언제일까?

1. 무상태(stateless) 아키텍처

 

2. 서버의 확장이 자주 일어나는 경우

서버가 제거되는 경우에는 해당 서버에서 처리하던 클라이언트의 요청이 다른 서버에서 처리하게 될 때 실패가 날 수 있다. 서버가 추가되는 경우에는 기존 클라이언트의 요청을 처리하지 못하며 해당 서버는 새로운 요청만 처리하게 된다. 이렇게 되면 트래픽 분배가 불균형해질 수 있다.

 

3. 단일 서버 어플리케이션

단일 서버 어플리케이션은 모든 요청이 해당 서버로 라우팅 되기 때문에 고정 세션을 사용할 필요가 없다.

 

4. DDoS 공격에 대한 취약성

DDoS는 고정세션을 사용하는 경우에 많이 발생할 수 있다. 공격자가 대량의 요청을 보내면 특정 서버에 집중되어 서버의 과부하나 장애가 발생하기 때문에, 서비스 중단을 초래할 수 있다.

---

참조

가상 면접 사례로 배우는 대규모 시스템 설계 기초

https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/classic/elb-sticky-sessions.html

Configure sticky sessions for your Classic Load Balancer - Elastic Load Balancing

https://traefik.io/glossary/what-are-sticky-sessions/

What Are Sticky Sessions | Traefik Labs