[안정성을 위한 기술] 로드 밸런서(2)

 

 

1. 부하 분산 알고리즘

 로드 밸런서는 트래픽을 여러 서버에 분산하여 시스템 성능을 최적화하고 안정성을 유지한다. 이를 위해 다양한 부하 분산 알고리즘이 사용되며, 서비스의 특성과 환경에 따라 적절한 방식을 선택해야 한다. 

라운드 로빈 (Round Robin)	현재 구성된 장비에 부하를 순차적으로 분산함. 총 누적 세션 수는 동일하지만 활성화된 세션 수는 달라질 수 있음
최소 접속 방식 (Least Connection)	현재 구성된 장비 중 가장 활성화된 세션 수가 적은 장비로 부하를 분산함
가중치 기반 라운드 로빈 (Weighted Round Robin)	라운드 로빈 장식과 동일하지만 각 장비에 가중치를 두어 가중치가 높은 장비에 부하를 더 많이 분산함. 처리 용량이 다른 서버에 부하를 분산하기 위한 분산 알고리즘
가중치 기반 최소 접속 방식 (Weighted Least Connection)	최소 접속 방식과 동일하지만 각 장비에 가중치를 부여해 가중치가 높은 장비에 부하를 더 많이 분산함. 처리 용량이 다른 서버에 부하를 분산하기 위한 분산 알고리즘
해시(Hash)	해시 알고리즘을 이용한 부하 분산

 

 이 외에도 기본적인 부하 분산 알고리즘을 응용한 다양한 분산 알고리즘이 사용되지만 라운드 로빈, 최소 접속 방식, 해시가 가장 많이 사용된다.

 

- 라운드 로빈

 

 라운드 로빈 방식은 서버에 순차적으로 트래픽을 분산하는 기본적인 부하 분산 알고리즘이다. 요청은 순차적으로 서버 1 → 서버 2 → 서버 3 순으로 분배되며, 다시 서버 1로 돌아가는 식으로 순환한다. 

장점	간단하고 구현이 쉬우며, 모든 서버에 동일한 누적 요청 수를 분배할 수 있어 작은 환경에서 효과적임
단점	활성 세션 수는 서버마다 다를 수 있어 서버 간 부하가 균등하지 않을 가능성이 있음

 

- 최소 접속 방식

 

 최소 접속 방식은 활성 세션 수가 가장 적은 서버에 트래픽을 분산하는 알고리즘이다.  로드 밸런서는 각 서버의 활성 세션 수를 실시간으로 모니터링하고, 가장 적은 세션을 가진 서버로 요청을 전송한다.  

장점	서버 간 부하를 더욱 균등하게 분산할 수 있어 효율적인 리소스 활용이 가능함.
단점	세션 수가 적은 서버에 트래픽이 집중될 가능성이 있으며, 세션 유지가 중요한 서비스에서는 적합하지 않을 수 있음.

 

- 가중치 기반 라운드 로빈

 라운드 로빈 방식에 서버 성능에 따라 가중치를 부여해, 성능이 높은 서버가 더 많은 트래픽을 처리하도록 설계되었다. 처리 용량이 다른 서버 간 트래픽을 효율적으로 분배할 때 적합하다.

 

- 가중치 기반 최소 접속 방식

 최소 접속 방식에 가중치를 적용하여, 처리 용량이 큰 서버가 더 많은 요청을 처리할 수 있도록 설계되었다. 서버 성능 차이가 큰 환경에서 리소스의 효율성을 극대화할 수 있다.

 

- 해시

 

 해시 알고리즘을 기반으로 요청을 특정 서버로 분배한다. 클라이언트의 출발지 IP, 목적지 IP, 포트 번호 등의 값을 해시 알고리즘으로 계산해 특정 서버로 트래픽을 전달한다.

장점	동일한 클라이언트 요청은 항상 동일한 서버로 전달되므로 세션 유지가 필요한 서비스에 적합함.
단점	해시 결과가 특정 값으로 편향되면 트래픽이 일부 서버에 집중될 수 있음

 

 

- 부하 분산 알고리즘의 특성과 활용

라운드 로빈이나 최소 접속 방식은 부하를 비교적 균등하게 분산시킬 수 있다는 장점이 있다. 그러나 동일한 클라이언트에서 로드 밸런서를 통해 전송된 요청이 서로 다른 서버로 분산될 가능성이 있다. 이로 인해, 각 서버에서 세션을 유지해야 하는 서비스에서는 문제를 초래할 수 있다. 예를 들어, 사용자가 로그인한 상태에서 지속적인 세션이 필요하다면 요청이 다른 서버로 전달되면서 로그인이 해제될 수 있다.

 

 반면, 해시 방식은 특정 알고리즘을 사용해 요청을 항상 동일한 서버로 분산시킨다. 이를 통해 세션 유지가 중요한 서비스에 적합하다. 예를 들어, 장바구니 서비스에서 동일한 서버로 요청이 유지되어야 장바구니에 담긴 상품 정보를 안정적으로 처리할 수 있다. 하지만 해시 알고리즘이 특정 값에 치우치는 경우, 특정 서버에 과도한 부하가 발생할 수 있다는 단점도 존재한다. 이러한 문제는 서버 애플리케이션이 여러 서버 환경을 고려하지 않고 설계된 경우 종종 발생한다.

 

 스티키(Sticky) 옵션을 활용하면, 해시 방식의 세션 유지 장점과 라운드 로빈 또는 최소 접속 방식의 균등 분산 효과를 결합할 수 있다. 이 기법은 초기 요청에 대해 생성된 세션 테이블에 따라 동일한 클라이언트 요청을 동일한 서버로 유지하도록 한다. 그러나 세션 테이블에 타임아웃이 설정되어 있어 일정 시간이 지나면 다른 서버로 분산될 가능성이 있다는 점도 고려해야 한다. 따라서 스티키 옵션을 사용할 때는 애플리케이션의 세션 유지 시간 및 사용자 행동 패턴을 충분히 분석하고 설정해야 한다.

 

- 알고리즘 선택의 중요성

 부하 분산 알고리즘을 선택할 때는 제공되는 서비스의 특성을 우선적으로 고려해야 한다. 세션 유지가 필요한 서비스는 해시 방식이 유리하며, 부하를 균등하게 분산시키는 것이 중요하다면 라운드 로빈이나 최소 접속 방식을 선택할 수 있다. 또한, 각 알고리즘의 성능과 서버 환경에 맞는 설정 값을 정확히 조정해야만 효과적인 부하 분산이 가능하다.

 

2. 로드 밸런서 구성 방식

 로드 밸런서는 구성 위치에 따라 원암(One-Arm)과 인라인(Inline) 방식으로 구분된다. 이 구분은 서버로 가는 트래픽이 모두 로드 밸런서를 경유하는지 여부에 따라 결정된다.

 

 

이런 구성 방식에 따라 앞에서 말한 트래픽이 흐르는 경우, NAT 설정, 로드 밸런서의 동작 모드가 달라질 수 있다.

 

- 원암 구성

 

 원암 구성 (One-arm Configuration)은 로드 밸런서가 네트워크의 중간에 위치하는 형태로, 트래픽 흐름에서 부하 분산이 필요한 트래픽만 로드 밸런서를 거쳐 서비스에 분배되며, 그 외의 트래픽은 서버와 직접 통신할 수 있도록 구성된다.

• 원암 구성의 주요 특징

로드 밸런서의 위치	로드 밸런서는 네트워크의 중간 스위치 옆에 위치함. 이때, 네트워크 상에서 로드 밸런서가 하나의 경로로만 트래픽을 처리하며, 클라이언트의 요청을 서버로 전달하는 역할을 함.
부하 분산이 필요한 트래픽만 로드 밸런서 경유	로드 밸런서는 부하 분산이 필요한 트래픽만 처리하고, 기타 트래픽은 로드 밸런서를 거치지 않고 서버와 직접 통신할 수 있음. 이를 통해 네트워크 리소스를 보다 효율적으로 활용하고, 필요할 때만 로드 밸런서를 통한 부하 분산을 수행할 수 있음.
트래픽 흐름	클라이언트 → 로드 밸런서 → 서버 (부하 분산 트래픽) 클라이언트 → 서버 (부하 분산이 필요 없는 트래픽)
원암 구성에서의 문제점	원암 구성에서는 응답 트래픽이 클라이언트로 돌아가는 경로에 문제가 발생할 수 있음. 특히, 로드 밸런서가 클라이언트의 IP 주소를 변경하고 나서 응답이 원래 클라이언트로 돌아가지 않는 상황이 발생할 수 있음. 이를 해결하기 위해 Source NAT (SNAT)가 필요하며, 로드 밸런서는 클라이언트의 출발지 IP 주소를 자신으로 변환하여 응답 트래픽이 올바른 경로로 돌아가도록 함.

 

• 원암 구성에서 사용되는 기술

Source NAT (SNAT)	로드 밸런서는 트래픽의 출발지 IP 주소를 변경하여 응답이 올바르게 돌아가도록 보장함. 클라이언트의 요청이 로드 밸런서를 거쳐 서버로 전달된 후, 응답이 클라이언트로 돌아갈 때 로드 밸런서가 중간에서 출발지 IP를 처리함.
트래픽 분배	로드 밸런서는 4계층 이상의 트래픽에 대해서만 부하 분산을 수행하며, 부하 분산이 필요 없는 트래픽은 직접 서버로 전달되도록 설정함.

 

• 원암 구성의 장단점

장점	간편한 설치: 네트워크 구조가 변경되지 않고, 기존에 사용하던 네트워크 대역을 그대로 사용하기 때문에 설치가 간편하고 기존 시스템과의 호환성이 좋음. 트래픽 효율성: 부하 분산이 필요한 트래픽만 로드 밸런서를 경유하게 되어 불필요한 트래픽 부담을 줄일 수 있음.
단점	응답 경로 문제: 클라이언트로 돌아가는 응답 트래픽이 올바르게 처리되지 않으면, NAT 설정이 필요하고, 이를 통해 문제를 해결해야 함.

 

 

 원암 구성에서는 로드 밸런서와 스위치가 단일 인터페이스 또는 여러 인터페이스를 통해 연결될 수 있다. 물리적으로 인터페이스가 하나뿐이라는 의미가 아니라, 로드 밸런서가 네트워크의 중간에 위치하고, 부하 분산이 필요한 트래픽만 처리하는 구조임을 의미한다.

• 원암 구성에서의 인터페이스 활용

단일 인터페이스 연결	로드 밸런서가 단일 네트워크 인터페이스를 통해 스위치와 연결되는 경우, 로드 밸런서는 해당 인터페이스를 통해 트래픽을 수신하고 처리함. 이는 간단한 형태의 원암 구성임.
LACP(Link Aggregation Control Protocol) 활용	여러 개의 네트워크 인터페이스를 결합하여 LACP를 사용하면, 로드 밸런서와 스위치 간에 다중 링크를 통해 연결할 수 있음. 이 경우에도 로드 밸런서가 중간 위치에서 트래픽을 처리하고, 트래픽의 흐름에 따라 부하 분산이 이루어지므로 여전히 원암 구성에 해당함. LACP는 여러 인터페이스를 하나의 논리적 인터페이스로 묶어 트래픽 처리의 성능을 향상시킬 수 있음.
서로 다른 네트워크로의 다중 인터페이스 연결	로드 밸런서와 스위치 간에 두 개 이상의 인터페이스를 사용하되, LACP를 사용하지 않고 서로 다른 네트워크에 연결된 경우에도 원암 구성으로 간주될 수 있음. 실무에서 "투암 구성"이라는 용어가 사용되지 않는 경우가 많지만, 이 역시 넓은 의미에서 원암 구성이며, 다양한 네트워크 대역을 통한 연결을 가능하게 함.

 

 따라서, 로드 밸런서와 스위치 간의 연결 방식에 관계없이, 부하 분산이 필요한 트래픽만 로드 밸런서를 경유하고 그 외 트래픽은 서버와 직접 통신할 수 있는 구성이면 원암 구성으로 분류할 수 있다.

 

 원암 구성에서 트래픽이 로드 밸런서를 경유할지 여부는 부하 분산을 적용하는지에 따라 달라진다. 즉, 트래픽이 부하 분산이 필요한 경우 로드 밸런서를 반드시 경유하고, 그렇지 않으면 로드 밸런서를 우회하여 서버와 직접 통신할 수 있다.

• 부하 분산 트래픽의 흐름 : 부하 분산이 적용된 트래픽은 서비스 IP(VIP) 주소를 기반으로 로드 밸런서를 먼저 거쳐, 로드 밸런서에서 각 서버로 트래픽이 분배된다. 그 후, 서버는 응답 트래픽을 생성하여 다시 로드 밸런서를 거쳐 클라이언트에게 전달한다. 이때, 패킷 처리 과정에서 SNAT(Source NAT)와 DNAT(Destination NAT) 설정이 필요하다.

DNAT (Destination NAT)	요청 트래픽이 로드 밸런서를 경유할 때, 로드 밸런서는 트래픽의 목적지 IP를 서버 IP로 변환함.
SNAT (Source NAT)	서버에서 생성한 응답 트래픽이 클라이언트로 돌아갈 때, 응답 트래픽의 출발지 IP를 로드 밸런서의 IP 주소로 변환함.

 

• DSR(Direct Server Return) 모드 사용 : 만약 DSR 모드를 사용한다면, SNAT를 생략할 수 있다. DSR 모드는 로드 밸런서가 요청을 처리하는 것과 달리, 서버가 직접 응답을 클라이언트에게 전달할 수 있게 하는 방식이다. 이때는 서버의 응답이 클라이언트에게 직접 전달되므로, 로드 밸런서를 경유하지 않고 응답이 돌아간다. DSR 모드를 사용하면 SNAT 설정이 필요 없으며, 네트워크 효율성을 향상시킬 수 있다.
• 부하 분산이 필요 없는 트래픽 : 반면, 부하 분산이 필요 없는 트래픽은 로드 밸런서를 거치지 않고 서버와 직접 통신한다. 이 경우, 트래픽의 목적지 IP는 서버의 실제 IP로 설정되어 있으므로, 로드 밸런서를 거치지 않고 바로 서버와 연결된다.

 

 

 원암 구성은 로드 밸런서를 활용하는 부하 분산 서비스 트래픽만 로드 밸런서를 거치도록 설정할 수 있어, 여러 가지 장점이 있다.

불필요한 트래픽 차단 및 로드 밸런서 부하 절감	부하 분산 기능을 사용하지 않는 트래픽은 로드 밸런서를 거치지 않고 서버와 직접 통신하게 되므로, 로드 밸런서의 부하를 효과적으로 줄일 수 있음. 또한, 네트워크 대역폭이 부족한 경우, 로드 밸런서와 스위치 간의 연결 대역폭만 증설하면 되므로 확장성이 뛰어나며, 인라인 방식보다 유연하게 대처할 수 있음.
대역폭 소모 최소화	원암 구성에서는 로드 밸런서를 거치는 트래픽만 처리하므로, 스위치와 로드 밸런서 간의 대역폭 소모를 최소화할 수 있음. 이는 네트워크 자원을 효율적으로 사용할 수 있게 함.
장애 내성 향상	로드 밸런서에 장애가 발생하더라도, 부하 분산이 필요 없는 일반 트래픽은 로드 밸런서를 우회하여 서버와 직접 통신할 수 있기 때문에, 시스템 전체의 장애 내성이 향상됨. 이로 인해 서비스 중단을 최소화할 수 있음.
혼합된 트래픽 처리	원암 구성은 부하 분산 트래픽과 일반 트래픽을 구분하여 처리할 수 있어, 두 가지 트래픽이 혼합된 환경에서 매우 유용함. 로드 밸런서를 거쳐야 하는 트래픽은 부하 분산 처리하고, 그렇지 않은 트래픽은 로드 밸런서를 우회하여 직접 처리할 수 있음.

※ 참고 : 원암 구성에서의 대역폭 원암 구성에서의 대역폭은 로드 밸런서가 처리해야 하는 트래픽 용량이 줄어들기 때문에 로드 밸런서를 경유하는 트래픽이 감소하는 효과가 있다. 그러나 로드 밸런서와 스위치 간 연결된 인터페이스는 인바운드와 아웃바운드 트래픽을 모두 처리해야 하므로, 이 인터페이스의 대역폭을 충분히 고려하여 산정해야 한다. 즉, 로드 밸런서와 스위치 간 인터페이스의 대역폭은 단순히 로드 밸런서가 처리하는 트래픽 용량만을 고려하는 것이 아니라, 양방향 트래픽을 모두 수용할 수 있도록 설정해야 한다.

 

- 인라인 구성

 

 인라인 구성은 네트워크 트래픽이 반드시 로드 밸런서를 경유하도록 설계된 구성으로, 모든 트래픽이 부하 분산을 거쳐 서버로 전달된다.

• 인라인 구성의 장단점

장점	- 단순하고 직관적인 트래픽 경로 : 모든 트래픽이 동일한 경로를 통해 흐르기 때문에 네트워크의 설정과 운영이 비교적 간단함. 트래픽이 항상 로드 밸런서를 거쳐가므로, 트래픽 흐름이 명확하고 예측 가능함. - 부하 분산의 일관성 : 트래픽이 로드 밸런서를 반드시 경유하기 때문에, 부하 분산 알고리즘에 따라 서버에 균등하게 트래픽이 분배됨. 예를 들어, 서버가 하나만 부하 분산을 받더라도 다른 서버로 향하는 트래픽도 일관되게 로드 밸런서를 경유하므로, 부하 분산의 효과를 일정하게 유지할 수 있음.
단점	- 로드 밸런서의 부하 증가 : 모든 트래픽이 로드 밸런서를 경유하기 때문에, 로드 밸런서에 부하가 집중될 수 있음. 특히 L4 이상의 데이터를 처리해야 하는 로드 밸런서의 경우 처리 성능에 한계가 있을 수 있음. 이러한 부하는 고성능 로드 밸런서를 필요로 하며, 이에 따라 비용이 증가할 수 있음. - 트래픽 성능과 패킷 처리 성능 구분 필요 : 로드 밸런서에서 트래픽을 처리하는 성능과 패킷 스루풋 성능을 명확히 구분하여 설계하는 것이 중요함. 처리 성능이 부족할 경우, 네트워크 성능에 문제가 발생할 수 있으며, 이는 서비스의 응답 속도나 안정성에 영향을 미칠 수 있음.

 

• 응답 트래픽 문제와 해결책

응답 트래픽의 경유 문제	인라인 구성에서도 서버로부터의 응답 트래픽이 로드 밸런서를 경유하지 않는 문제가 발생할 수 있음. 예를 들어, 서버가 응답을 직접 클라이언트로 전달할 경우 로드 밸런서를 거치지 않게 됨. 이는 원암 구성에서와 동일한 방식으로 해결할 수 있으며, 응답 트래픽을 처리하는 방법을 명확히 설정하여 부하를 분산시킬 수 있음.
원암 구성과의 유사성	원암 구성에서는 특정 트래픽만 로드 밸런서를 거치도록 설정할 수 있는 유연성이 있지만, 인라인 구성에서는 모든 트래픽이 반드시 로드 밸런서를 통과함. 따라서 로드 밸런서에서 처리하지 않는 트래픽이 발생하지 않도록 설정하거나, 로드 밸런서의 부하를 관리할 수 있는 방안을 추가적으로 고려해야 함.

 

• 설계 시 고려 사항

로드 밸런서 성능	트래픽의 양과 성격에 맞춰 로드 밸런서의 성능을 적절하게 선택해야 함. 고성능의 로드 밸런서를 선택하는 것이 중요하지만, 그에 따른 비용 상승을 고려해야 함.
확장성	부하가 증가하면 인라인 구성이 부하를 더 많이 받을 수 있으므로, 확장성 있는 로드 밸런서 구성이나 추가적인 로드 밸런서 도입을 고려할 수 있음.
응답 트래픽 관리	서버에서 발생하는 응답 트래픽이 로드 밸런서를 거치지 않도록 하는 설정도 중요하며, 이를 위해 응답 트래픽 처리 방안을 잘 설정해야 함.

※ 참고 : 물리적 원암, 논리적 인라인 물리적 원암과 논리적 인라인 구성을 구분할 때, 물리적인 구성이 원암을 따르더라도 실제로는 인라인 방식으로 작동하는 경우가 존재한다. 예를 들어, 로드 밸런서와 연결된 스위치에서 VRF(Virtual Routing and Forwarding)와 같은 가상화 기술을 이용해 논리적으로 장비를 분리할 수 있다. VRF를 사용하지 않더라도 VLAN을 활용하여 인라인 방식처럼 구성이 가능하다. 이 경우, 물리적 구성만으로 원암과 인라인을 구분하는 것은 적합하지 않으며, 장비의 논리적 구성에 따라 인라인 방식으로 동작한다고 이해해야 한다. 따라서 원암과 인라인을 구분할 때, 물리적 구성뿐만 아니라 논리적인 구성도 함께 고려해야 한다.

 

3. 로드 밸런서 동작 모드

 로드 밸런서의 구성 방식과 동작 모드는 서로 밀접하게 연관되어 있으며, 이를 함께 이해하는 것이 중요하다. 로드 밸런서의 동작 모드는 네트워크 트래픽을 어떻게 처리하고 분배할지에 대한 방식으로, 이를 통해 서비스의 성능, 장애 대응, 보안, 트래픽 흐름 방식 등이 달라진다.

 

-트랜스패런트(Transparent, TP) 모드

 트랜스패런트(Transparent, TP) 모드는 로드 밸런서가 OSI 2계층(데이터 링크 계층) 스위치처럼 동작하는 구성 방식입니다. 이 모드의 주요 특징은 네트워크의 구조를 변경하지 않고도 부하 분산을 적용할 수 있다는 점입니다. 

 

• 트랜스패런트 모드 적용 이유

네트워크 구조 변경 없음	트랜스패런트 모드는 기존 네트워크 대역을 그대로 사용하면서 로드 밸런서를 도입할 수 있어 IP 네트워크 재설계 없이 쉽게 적용할 수 있음. 이는 기존의 서버 네트워크 대역에 그대로 VIP(가상 IP)를 매핑하여 사용하기 때문에, 기존 네트워크 환경을 변경하지 않고 로드 밸런싱을 구현할 수 있음.
L2 스위치처럼 동작	로드 밸런서는 L2 스위치처럼 동작하여, 네트워크에서 IP 패킷을 전달하고 목적지 서버로 트래픽을 전달함. 이때, 트래픽이 로드 밸런서를 거치게 되지만 로드 밸런서가 OSI 2계층에서 스위칭 기능만 수행하기 때문에, 부하 분산이 필요하지 않은 트래픽은 기존 트래픽 흐름을 그대로 유지함.
부하 분산을 위한 4계층 이상의 기능 수행	로드 밸런서는 부하 분산이 필요한 트래픽에 대해서만 4계층 이상(전송 계층) 기능을 수행함. 예를 들어, 서비스 요청이 로드 밸런서를 거쳐 여러 서버로 분배될 때만 부하 분산 기능이 활성화됨. 부하 분산이 필요하지 않은 트래픽은 기존 L2 스위치처럼 단순히 스위칭하여 서버로 전달됨.

 

• 트랜스패런트 모드 장점

간편한 구현	기존의 네트워크 대역을 그대로 사용하면서 부하 분산을 구현할 수 있어, 네트워크 변경 없이 빠르고 쉽게 적용할 수 있음.
네트워크 영향 적음	트랜스패런트 모드는 네트워크 전반에 미치는 영향이 적어, 기존 네트워크 환경을 크게 변경할 필요가 없으며, 네트워크 구조를 그대로 두고 부하 분산을 적용할 수 있음.
비용 절감	새로운 IP 네트워크 설계를 하지 않아도 되므로, 추가 비용이 발생하지 않음.

 

트랜스패런트 모드는 단순한 부하 분산을 원하며, 네트워크 변경이 필요 없는 환경에서 주로 사용된다.

 

 

 트랜스패런트(Transparent, TP) 모드는 로드 밸런서의 동작 방식에 따라 원암(One-arm) 구성과 인라인(Inline) 구성 모두에서 적용될 수 있다. 

• 원암 구성 : 원암 구성에서는 로드 밸런서가 네트워크의 한쪽 끝에 위치하고, 트래픽은 로드 밸런서를 거쳐 전달된다. 이 방식에서 클라이언트와 서버 간의 트래픽 흐름은 사용자가 요청을 보내면, 로드 밸런서가 요청을 받아서 서버로 전달한다. 서버는 응답을 로드 밸런서를 경유하지 않고 직접 클라이언트로 보내는 경로를 사용한다.

문제점	응답 트래픽이 클라이언트로 돌아가지 않을 수 있음. 이는 로드 밸런서가 네트워크의 한쪽 끝에 위치하므로, 응답이 잘못된 경로로 돌아갈 위험이 있음. 예를 들어, 응답이 로드 밸런서를 우회하거나 잘못된 IP로 전송될 수 있음.
해결책	이를 해결하기 위해 Source NAT가 필요함. 로드 밸런서는 클라이언트의 IP 주소를 대신하여 자신의 IP 주소로 응답 트래픽의 출발지 IP를 변환함. 이를 통해 응답 트래픽이 올바른 경로를 통해 클라이언트로 돌아가게 할 수 있음.

 

• 인라인 구성 : 인라인 구성에서는 로드 밸런서가 네트워크의 중간에 위치하여, 트래픽이 로드 밸런서를 통해 직통으로 전달된다. 즉, 클라이언트와 서버가 로드 밸런서를 경유하여 서로 통신하는 구조이다. 클라이언트는 요청을 보내면 로드 밸런서를 거쳐 서버에 전달하고, 서버는 응답을 로드 밸런서를 거쳐 다시 클라이언트로 보낸다.

문제점 없음

인라인 구성에서는 응답 경로에 문제가 발생하지 않음. 트래픽이 로드 밸런서를 경유하므로 응답 트래픽도 정상적으로 클라이언트에게 돌아감. 응답이 올바른 경로로 돌아가므로 Source NAT가 필요 없음.

 

• Source NAT의 필요성
  • 원암 구성에서는 응답 트래픽 경로 문제가 발생할 수 있기 때문에, Source NAT가 필수적이다. 로드 밸런서는 응답 트래픽의 출발지 IP 주소를 자신의 IP 주소로 변경하여, 클라이언트가 응답을 받을 수 있도록 보장한다.
  • 인라인 구성에서는 응답 트래픽이 로드 밸런서를 거쳐 클라이언트로 바로 돌아가기 때문에, Source NAT가 필요하지 않다.

 

 

 트랜스패런트 모두에서 부하 분산 트래픽 흐름은 다음과 같다. 

서비스 요청	사용자는 서비스 IP인 로드 밸런서의 VIP 주소(예: 10.10)로 서비스를 요청함
패킷 처리	로드 밸런서로 들어온 패킷은 목적지 IP 주소를 로드 밸런서의 VIP에 바인딩된 실제 서버 IP 주소로 변경(Rewrite)함. 즉, 패킷의 목적지 IP 주소는 10.10에서 실제 서버의 IP인 10.11로 변경됨.
MAC 주소 변경	패킷의 목적지 MAC 주소도 실제 서버의 MAC 주소(C)로 변경됨. 로드 밸런서와 실제 서버가 동일한 네트워크 대역에 있기 때문에, L3 장비를 거치지 않으며 출발지 MAC 주소는 변경되지 않음.
패킷 전달	목적지 정보가 변경된 패킷은 실제 서버로 전달됨

 

 이 과정에서 로드 밸런서는 서비스 요청을 처리하는 동안 VIP 주소를 실제 서버의 IP 주소로 변경하여 패킷을 전달하는데, 이때 목적지(Destination) NAT가 적용되었다고 한다. 즉, 로드 밸런서가 목적지 IP와 MAC 주소를 변경하여 트래픽을 적절한 서버로 유도하는 방식이다.

 

 

트랜스패런트 모드에서 서버가 사용자에게 응답할 때의 트래픽 흐름은 다음과 같다.

응답 트래픽 흐름	서버가 응답을 보낼 때, 출발지 IP 주소는 실제 서버의 IP에서 로드 밸런서의 VIP 주소로 변경됨. 이는 로드 밸런서가 트래픽을 처리하는 방식에 따른 결과임. 하지만, 목적지 MAC 주소는 변경되지 않습니다. 서버에서 응답할 때, 이미 목적지 MAC 주소는 로드 밸런서의 MAC 주소가 아닌 게이트웨이의 MAC 주소로 설정되어 있기 때문임. 이는 로드 밸런서와 서버가 동일한 네트워크 대역에 있기 때문에 발생하며, 응답 패킷은 게이트웨이를 통해 사용자에게 전달될 수 있음.
인라인 구성의 문제	인라인 구성에서는 로드 밸런서가 네트워크의 중간에 위치하여 서비스 요청을 처리할 때 문제가 발생하지 않음. 그러나, 동일 네트워크 내에서 서비스 요청이 있을 경우, 응답 패킷이 로드 밸런서를 거치지 않고 직접 사용자에게 전달될 가능성이 있음. 이는 로드 밸런서가 동일 네트워크 내에서 응답 트래픽의 경로를 변경할 수 없기 때문에 발생할 수 있음.
원암 구성에서의 문제	원암 구성에서도 응답 패킷이 로드 밸런서를 거치지 않을 수 있으며, 이 경우에도 서비스 응답이 제대로 처리되지 않을 수 있음. 응답 패킷은 로드 밸런서를 통해 역변환(Reverse NAT)되어야만 정상적인 부하 분산이 이루어지기 때문에, 응답 패킷이 로드 밸런서를 거치지 않으면 부하 분산이 제대로 작동하지 않게 됨.

 

 따라서, 인라인 구성과 원암 구성에서 트래픽 흐름을 제대로 관리하려면 응답 패킷이 로드 밸런서를 거쳐 역변환되도록 하는 추가적인 설정이나 고려가 필요하다.

※ 참고 : 트랜스패런트 모드 구현 방식: 프록시 ARP vs 순수 트랜스패런트 모드 트랜스패런트 모드를 구현할 때, 과거에는 프록시 ARP를 이용한 방식이 사용되기도 했다. 이 방식에서는 MAC 주소를 변경하는 방식으로 트랜스패런트 모드를 구현했다. 그러나 최근에는 프록시 ARP 방식보다 순수 트랜스패런트 모드가 더 많이 사용되고 있다. 순수 트랜스패런트 모드는 MAC 주소를 변경하지 않고, 네트워크 상에서 장비가 투명하게 동작할 수 있도록 지원한다. 따라서 현재 대부분의 경우, MAC 주소 변경 없이 순수 트랜스패런트 모드가 선호된다.

 

- 라우티드(Routed) 모드

 라우티드(Routed) 모드는 로드 밸런서가 라우팅 역할을 수행하는 구성 방식이다. 이 모드에서는 로드 밸런서를 기준으로 사용자 방향(Client Side)과 서버 방향(Server Side)이 서로 다른 네트워크로 분리되어 구성된다. 로드 밸런서는 이 두 네트워크를 라우팅을 통해 연결하여, 사용자와 서버 간의 트래픽을 전달하는 역할을 한다.

서로 다른 네트워크	라우티드 모드에서는 로드 밸런서가 두 개의 별도 네트워크를 연결하는 역할을 하므로, 사용자 네트워크(Client Side)와 서버 네트워크(Server Side)는 서로 다른 서브넷에 위치할 수 있음. 로드 밸런서는 이들 네트워크를 라우팅하여 트래픽을 처리함.
라우팅	로드 밸런서가 사용자 네트워크와 서버 네트워크를 라우팅하는 방식으로 동작함. 즉, 로드 밸런서는 IP 라우팅을 통해 트래픽을 전달하며, Layer 3(L3) 장비로서의 역할을 함. 이는 OSI 3계층(네트워크 계층)에서의 기능으로, 패킷의 라우팅을 담당함.
구성 가능성	라우티드 모드는 원암(One-arm) 구성과 인라인(Inline) 구성 모두에서 사용할 수 있음. 네트워크 구성에 따라 적절한 방식으로 적용할 수 있음.

 

 

 

 라우티드(Routed) 모드는 보안 강화 목적으로도 자주 사용된다. 이 구성에서 로드 밸런서는 사용자 네트워크와 서버 네트워크 간의 트래픽을 라우팅하여 연결하지만, 서버 네트워크는 사설 네트워크로 구성될 수 있다. 이를 통해 서버에 직접 접속하는 것을 막는 보안적인 장점을 제공한다.

 

 

라우티드 구성에서 로드 밸런서를 통한 트래픽 흐름은 다음과 같다.

사용자의 요청	사용자는 서비스 IP(VIP)인 10.10 주소로 서비스를 요청함
로드 밸런서에서의 변경	로드 밸런서로 들어온 패킷은 목적지 IP 주소가 VIP(10.10)로 설정되어 있으므로, 로드 밸런서는 이 목적지 IP를 실제 서버 IP(20.11)로 변경함. 이 과정에서 Destination NAT가 발생함.
MAC 주소 변경	로드 밸런서가 라우팅 역할을 하면서, 패킷의 출발지 MAC 주소와 목적지 MAC 주소도 변경됨. - 출발지 MAC 주소 : 사용자 측의 MAC 주소 A에서, 로드 밸런서의 MAC 주소 D로 변경됨. - 목적지 MAC 주소 : 로드 밸런서가 결정한 실제 서버의 MAC 주소 C로 변경됨.
라우팅 및 전송	변경된 목적지 IP(20.11)와 목적지 MAC(C)를 가진 패킷은 로드 밸런서의 라우팅 테이블을 확인하여, 실제 서버로 전송됨. 이때 출발지 MAC 주소와 목적지 MAC 주소가 라우팅 과정에서 변경되어, 네트워크 내에서 올바른 경로를 따라 패킷이 전달됨.
최종 목적지	이 과정에서 로드 밸런서는 VIP에서 실제 서비스의 IP 주소로 패킷을 변경해 전송하므로, Destination NAT가 발생하게 됨. 이로 인해 트래픽은 로드 밸런서를 거쳐 실제 서버로 정확히 전달됨

 

 서버에서 사용자로 전달되는 응답 패킷 흐름은 다음과 같다.

서버에서 응답 생성	서버는 사용자에게 응답 패킷을 전송할 때, 출발지 IP는 실제 서버의 IP(20.11)가 됨. 목적지 IP는 원래 사용자의 IP 주소가 됨.
목적지 MAC 주소 변경	이 응답 패킷이 외부 네트워크로 나가야 하므로, 목적지 MAC 주소는 외부로 나가는 게이트웨이(로드 밸런서)의 MAC 주소가 됨. 이는 서버가 직접 외부 네트워크로 나갈 수 없기 때문임. 따라서 응답 패킷은 로드 밸런서를 향해 전송됨.
로드 밸런서에서 처리	로드 밸런서에 도달한 응답 패킷은 출발지 IP(20.11)에서 VIP(10.10)로 변환됨. 이는 Source NAT 과정에 해당하며, 응답 패킷이 사용자에게 전달될 수 있도록 IP 주소를 변환함.
MAC 주소 변경	로드 밸런서는 출발지 MAC 주소를 서버의 MAC 주소에서 로드 밸런서의 MAC 주소로 변경하고, 목적지 MAC 주소는 사용자의 MAC 주소로 변경함. 이렇게 변경된 패킷은 사용자에게 전송됨.
응답 패킷 전달	최종적으로 응답 패킷은 사용자의 MAC 주소로 전송되며, 이 과정에서 로드 밸런서가 출발지와 목적지 IP 및 MAC 주소를 적절히 변경하여 사용자에게 정상적으로 응답이 전달됨.

 

※ 참고 : 인라인 모드의 라우티드 구성과 L3 장비의 역할 인라인 모드의 라우티드 구성에서는, 로드 밸런서가 서버의 게이트웨이 역할을 하거나, 로드 밸런서와 서버 사이에 다른 L3 장비가 존재하는 경우 해당 L3 장비가 게이트웨이 역할을 할 수 있다. 이 경우, 로드 밸런서는 트래픽을 처리하고 라우팅하는 역할을 하며, 추가적인 L3 장비가 트래픽의 경로를 제어하거나 보안을 강화하는 기능을 수행하게 된다. 따라서, 라우티드 모드의 구성에서 L3 장비의 역할을 적절히 설정하여 네트워크 경로와 트래픽 흐름을 효율적으로 관리해야 한다.

 

- DSR(Direct Server Return) 모드

 DSR(Direct Server Return) 모드는 사용자가 요청한 트래픽이 로드 밸런서를 통해 서버로 유입된 후, 응답은 다시 로드 밸런서를 거치지 않고 서버가 직접 사용자에게 전달되는 방식이다. 이 방식은 로드 밸런서가 요청 패킷에만 관여하고, 응답 트래픽은 서버가 직접 사용자에게 보내기 때문에 로드 밸런서에 부하를 줄여주는 효과가 있다.

• DSR 모드 구성

요청 트래픽 흐름	사용자가 서비스 IP(VIP)로 요청을 보냄 로드 밸런서는 이 요청을 받아 실제 서버로 전달함 로드 밸런서는 Destination NAT(DNAT)를 통해 실제 서버의 IP로 트래픽을 전달함
요청 트래픽 흐름	서버는 로드 밸런서를 거치지 않고 직접 사용자에게 응답을 보냄 응답 트래픽은 로드 밸런서를 통하지 않기 때문에, 로드 밸런서는 요청 트래픽만 처리하고 응답은 서버에서 직접 처리하게 됨

• 모드 유형

L2 DSR	실제 서버의 네트워크 대역을 로드 밸런서가 가지고 있는 경우임 로드 밸런서와 서버 간의 통신은 Layer 2 통신(즉, 같은 서브넷 내에서의 통신)임
L3 DSR	실제 서버의 네트워크 대역을 로드 밸런서가 가지지 않는 경우임 로드 밸런서와 서버 간의 통신이 Layer 3 통신(즉, 서로 다른 서브넷 간의 통신)으로 이루어짐

 

 

 

DSR(Direct Server Return) 모드는 트래픽 부하를 줄이는 데 매우 효과적이지만, 몇 가지 단점도 존재한다.

문제 확인 어려움	DSR 모드에서는 응답 트래픽이 로드 밸런서를 거치지 않기 때문에, 만약 서비스에 문제가 발생했을 때, 트래픽 흐름을 추적하고 원인을 분석하는 것이 어려워질 수 있음. 로드 밸런서가 응답 트래픽을 처리하지 않으므로, 문제 발생 시 로드 밸런서에서 제공하는 로그나 트래픽 정보를 이용할 수 없고, 서버 쪽에서의 진단이 필요함.
서버 설정 필요	DSR 모드에서는 로드 밸런서뿐만 아니라 서버에서도 추가 설정이 필요함. 예를 들어, L2 DSR 및 L3 DSR은 로드 밸런서에서만 설정하는 것이 아니라, 서버 네트워크 설정과 관련된 부분도 조정해야 함. 이로 인해 서버의 네트워크 설정을 신경 써야 하며, 서버 측의 설정이 제대로 이루어지지 않으면 서비스가 제대로 동작하지 않을 수 있음.
L3 DSR의 제한	L3 DSR 모드는 윈도우 서버에서 지원하지 않음. 윈도우 서버 환경에서 L3 DSR을 구현하려면, 서버의 네트워크 설정이 로드 밸런서와 맞지 않아 서비스가 정상적으로 작동하지 않을 수 있음. 특히, 윈도 서버가 서버팜에 포함된 경우에는 L3 DSR을 사용할 수 없다는 제약이 존재함.

 

 

 L2 DSR (Direct Server Return) 모드에서 서버가 추가 설정이 필요한 이유는 트래픽 흐름과 관련된 몇 가지 중요한 특성 때문이다. 이 모드는 로드 밸런서를 통한 응답 경유 없이, 서버가 직접 사용자에게 응답하는 방식이기 때문에, 로드 밸런서를 통하지 않고 직접 응답하는 과정에서의 IP 주소와 MAC 주소의 처리 방식을 신경 써야 한다.

 

• L2 DSR 모드의 트래픽 흐름 및 서버 설정 필요성

서비스 요청 및 패킷 전달	사용자는 서비스 IP인 VIP로 서비스 요청함. 로드 밸런서는 해당 요청을 받아 실제 서버 IP로 목적지 IP 주소를 변경하지 않고, 목적지 MAC 주소만 서버의 MAC 주소로 변경하여 서버로 전송함.
응답 처리	서버는 요청을 받은 후, 응답을 직접 사용자에게 전달함. 그러나, 서버에서 응답을 보낼 때, 일반적인 상황에서는 출발지 IP 주소를 VIP로 변경하는 Source NAT 처리가 필요하지만, DSR 모드에서는 응답이 로드 밸런서를 경유하지 않기 때문에 이 과정이 불가능함.
서버 측 추가 설정 이유	목적지 IP 주소가 서버의 실제 IP와 일치하지 않으면 패킷을 폐기하므로, 서버는 루프백 인터페이스를 생성해 VIP 주소를 할당해야 함. 이로써 서버가 VIP 주소를 인식할 수 있도록 설정하여 패킷을 수신할 수 있게 함. - 루프백 인터페이스 설정: 루프백 인터페이스에 VIP 주소를 할당하면, 서버는 요청이 VIP로 들어올 때 이를 정상적으로 처리할 수 있음. 이 과정에서 VIP 주소가 실제 서버의 IP 주소와 동일하게 설정되므로, 패킷을 수신할 수 있게 됨.
ARP 관련 설정	ARP 광고가 되지 않도록 설정해야 함. 이는 VIP 주소가 로드 밸런서와 동일한 IP 주소이므로, 서버가 ARP 프로토콜을 사용하여 MAC 주소를 갱신하지 않도록 설정해야 함. 이를 통해 서버는 VIP에 대한 MAC 주소를 변경하지 않고, 로드 밸런서의 MAC 주소를 그대로 유지하도록 함.

 

 

DSR 모드에서의 실제 패킷 흐름은 다음과 같습니다:

사용자의 서비스 요청	사용자는 서비스 IP인 VIP 주소를 통해 서비스를 요청함
로드 밸런서의 역할	로드 밸런서는 요청 패킷의 목적지 IP를 변경하지 않고, VIP 주소 그대로 유지함. 목적지 MAC 주소만 변경하여 실제 서버의 MAC 주소로 설정하고, 이 패킷을 실제 서버로 전송함.
서버의 패킷 수신	실제 서버는 루프백 인터페이스에 VIP 주소를 동일하게 설정함. 로드 밸런서에서 전달된 패킷의 목적지 IP가 서버의 루프백 인터페이스에 설정된 VIP 주소와 일치하면, 서버는 해당 패킷을 수신함.

 

 이 과정에서 중요한 점은 출발지 IP의 변경 없이 목적지 MAC 주소만 변경하여 패킷을 서버로 전송하며, 서버는 루프백 인터페이스를 사용해 VIP 주소를 인식하고 패킷을 처리할 수 있게 된다는 것이다. 응답 패킷은 로드 밸런서를 통하지 않고 서버에서 직접 사용자에게 전달된다.

 

 DSR 모드에서 서버의 응답 패킷 흐름은 로드 밸런서를 경유하지 않기 때문에 응답이 로드 밸런서를 거치지 않고 직접 사용자에게 전달된다. 이 때, 중요한 점은 출발지 IP가 서버의 인터페이스 IP 주소가 아닌 루프백 인터페이스의 IP 주소(즉, VIP 주소)로 설정된다는 것이다.

 

DSR 모드에서 서버에서 필요한 추가 설정은 다음과 같다.

루프백 인터페이스	서버는 루프백 인터페이스를 생성하여, 이 인터페이스에 VIP 주소를 할당해야 함. 이 루프백 인터페이스는 서버가 사용자 요청을 받을 때 사용하는 가상 IP (VIP) 를 설정하는 데 사용됨. 이 설정을 통해, 서버가 VIP 주소로 패킷을 처리할 수 있도록 함
리눅스 커널 파라미터 수정	리눅스에서는 sysctl을 사용하여 커널 파라미터를 조정해야 할 수 있음. 특히, 소스 IP 변경을 허용하는 등의 파라미터 조정이 필요함. 예를 들어, net.ipv4.conf.all.route_localnet 값을 1로 설정하면, 로컬 네트워크의 패킷이 루프백 인터페이스로 전달될 수 있음.
네트워크 설정 변경	윈도 서버에서는 VIP 주소를 루프백 인터페이스에 설정해야 하며, 이 설정을 통해 서버는 로드 밸런서를 경유하지 않고 직접 응답을 보낼 수 있음 또한, 윈도 서버는 네트워크 대역과 관련된 소스 IP 주소 수정을 위한 설정이 필요할 수 있음.

 

 이러한 설정을 통해 DSR 모드가 활성화되며, 서버는 서비스 요청에 대한 응답을 로드 밸런서를 거치지 않고 직접 사용자에게 전송할 수 있게 된다.