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

 

 

1. 로드 밸런서 유의사항

 로드 밸런서는 서비스 트래픽의 효율적인 분산과 안정적인 운영을 위해 사용되지만, 구성 방식과 동작 모드에 따라 주의해야 할 점이 있다.

 

- 원암 구성에서 동일 네트워크 사용 시 문제점

 

 원암 구성은 특정 서비스 트래픽만 로드 밸런서를 경유하도록 설계되어 불필요한 트래픽을 차단하고, 로드 밸런서의 부하를 줄이는 장점이 있다. 그러나 서비스 IP(VIP)와 실제 서버 IP가 동일 네트워크에 존재할 경우 문제가 발생한다.

1. 사용자가 서비스 IP로 요청 → 로드 밸런서가 실제 서버 IP로 Destination NAT 후 전달.
2. 서버가 응답 시 로드 밸런서를 우회하여 직접 사용자에게 패킷 전송.
   • 사용자 요청은 서비스 IP에서 시작되었지만, 응답은 실제 서버 IP에서 오기 때문에 패킷이 폐기됨.
   • 사용자 입장에서는 요청하지 않은 IP에서 응답이 도착한 것으로 인식.

이 문제는 응답 트래픽이 로드 밸런서를 거쳐 사용자에게 전달되지 않기 때문에 발생한다.

 

- 문제 해결 방안

• 게이트웨이를 로드 밸런서로 설정 : 서버의 게이트웨이를 로드 밸런서로 지정하여 응답 트래픽이 항상 로드 밸런서를 경유하도록 한다. 그러나, 이 설정도 부하 분산이 필요한 서버만 게이트웨이를 로드 밸런서로 설정해야 하며, 부하 분산이 필요하지 않은 서버의 경우, 기존 게이트웨이(L3 스위치)를 유지하여 로드 밸런서의 부하를 감소 할 수 있다.

장점	모든 외부 호출 응답이 로드 밸런서를 통과하므로 정상적인 서비스 응답이 가능함
단점	물리적으로 원암 구조지만, 실제로는 로드 밸런서를 중심으로 트래픽이 흐르므로 부하 감소 효과가 줄어듦

 

• Source NAT 사용 : 로드 밸런서가 Destination NAT뿐만 아니라 Source NAT도 수행하여 출발지 IP를 로드 밸런서 IP로 변경한다.  Source NAT 사용에 따른 동작 방식은 사용자가 서비스를 요청하면, 로드 밸런서는 해당 요청을 실제 서버로 전달하며 이때 요청 패킷의 출발지 IP를 로드 밸런서의 IP로 변경한다. 이후, 서버는 요청을 처리한 후 응답을 로드 밸런서로 전달하며, 로드 밸런서를 요청자의 IP로 인식한다. 로드 밸런서는 응답 패킷의 출발지 IP를 서비스 IP로, 목적지 IP를 사용자 IP로 변경하여 최종적으로 사용자에게 응답을 전송한다.

장점	모든 응답 트래픽이 로드 밸런서를 통과하여 사용자 요청과 응답이 정상적으로 이루어짐.
단점	서버 입장에서 모든 요청이 동일한 IP에서 온 것으로 인식됨. 실제 사용자 구분이 어려울 수 있음. 이를 해결하기 위해 X-Forwarded-For(XFF) 헤더를 활용하여 원래 사용자의 IP 정보를 전달 가능함.

 

• DSR 모드 : 사용자의 요청 트래픽에 대해 Destination NAT를 수행하지 않고, 트래픽을 실제 서버로 전달하는 방식이다. 이 방식은 각 서버에는 서비스 IP를 루프백 인터페이스로 설정하여 구성한다. 이를 통해 서버는 클라이언트의 요청에 응답할 때, 루프백 인터페이스에 설정된 서비스 IP를 출발지 주소로 사용해 직접 사용자에게 응답을 보낼 수 있다.

장점	로드 밸런서를 거치지 않아 응답 속도 개선 및 로드 밸런서 부하 감소함
단점	서버 구성 복잡성 증가됨 (루프백 설정 필요). 일부 트래픽 모니터링 및 관리 기능 제한 가능.

 

 

- 동일 네트워크 내에서 서비스 IP(VIP) 호출 시 문제와 해결 방안

 동일 네트워크 내에서 로드 밸런서를 통해 서비스 IP(VIP)를 호출할 때 발생할 수 있는 문제와 이를 해결하기 위한 방법은 다음과 같습니다.

• 문제 발생 - 인라인 구성과 원암 구성 : 서버 #1이 로드 밸런서를 통해 부하 분산이 이루어지는 서버라고 가정할 때, 동일 네트워크에 있는 서버 #2가 서비스 IP(VIP)를 호출하면 로드 밸런서는 요청을 받아 목적지 IP를 서버 #1의 IP로 변환(Destination NAT)하여 서버 #1로 전달합니다. 그러나 서버 #1은 요청을 보낸 서버 #2의 IP가 동일 네트워크에 있음을 확인하고, 로드 밸런서를 거치지 않고 바로 서버 #2로 응답을 보냅니다. 이때 서버 #2는 요청을 보낸 서비스 IP가 아닌 서버 #1의 IP로 응답을 받게 되어 이를 정상적인 패킷으로 처리하지 않고 폐기하며, 그 결과 서비스 요청이 실패하게 됩니다.

 

• 해결 방안

Source NAT 사용	- 방법 : 로드 밸런서가 요청을 서버로 전달할 때, 출발지 IP를 요청을 보낸 서버의 IP가 아닌 로드 밸런서 자신의 IP로 변환함 - 효과 : 서버 #1은 요청의 출발지가 로드 밸런서 IP라고 인식하므로, 응답 패킷을 다시 로드 밸런서로 보내게 됨. 로드 밸런서는 이 패킷을 원래 요청한 서버 #2로 전달하므로 서비스가 정상적으로 이루어짐. - 제약 사항 : 서비스 요청량이 많을 경우, Source NAT에 필요한 포트 범위가 제한적일 수 있음. 이를 해결하려면 Source NAT에 사용되는 IP를 단일 IP가 아닌 여러 IP로 설정해야 함.
DSR(Direct Server Return) 모드 사용	- 방법 : 요청 트래픽을 로드 밸런서가 서버에 전달하되, 별도의 Destination NAT를 수행하지 않음. 대신 각 서버의 루프백 인터페이스에 서비스 IP를 설정하여 응답 시 루프백에 설정된 IP를 사용함. - 효과 : 서버가 직접 응답을 처리하므로 로드 밸런서를 경유하지 않으며, 동일 네트워크에서의 문제를 방지할 수 있음.
서버 직접 연결	- 방법 : 부하 분산 대상 서버를 로드 밸런서에 물리적으로 연결하여 모든 트래픽이 로드 밸런서를 반드시 경유하도록 설정함 - 효과 : 어떤 요청이든 로드 밸런서를 경유하게 되어 네트워크 충돌이 발생하지 않음. - 제약 사항 : 로드 밸런서 포트 수가 제한적이므로 서버 확장에 제약이 따르며, 포트 수가 많은 로드 밸런서는 비용이 매우 높아질 수 있음.

 

• 유의 사항 : 동일 네트워크 내에서 VIP 호출 문제를 해결하기 위해서는 상황에 따라 적절한 방법을 선택해야 하며, Source NAT를 사용하는 경우 서비스 트래픽 증가에 대비해 NAT 설정을 확장 가능하도록 설계해야 한다. 또한, 모든 해결 방법은 각각 장단점이 있으므로 네트워크 환경과 서비스 요구사항을 종합적으로 고려하여 최적의 구성을 선택하는 것이 중요하다.