증가하는 클라이언트를 지원하고 로드 밸런싱 및 고가용성을 위해 HAproxy 및 Keepalived를 배포하기 위해 더 많은 웹 애플리케이션 서버를 추가할 계획입니다.
내 서버 사용량에는 다음과 같은 특징이 있습니다.
- 작업은 CPU를 많이 사용하지 않습니다. 메시지는 100자 미만의 JSON 텍스트입니다.
- 사용자는 클라이언트 장치 Y를 통해 서버에 메시지를 보냅니다. 일반적으로 하루에 4-5개의 메시지
- 클라이언트 장치 X는 서버로부터 메시지를 계속 기다리고 있습니다. 서버에서 메시지를 사용할 수 있는 경우 클라이언트 장치 X는 2초 이내에 해당 메시지를 받을 수 있어야 합니다. 그렇지 않으면 이 메시지는 오래된 것입니다.
이런 이유로,
- 클라이언트 장치 X가 사용 중인긴 폴링 HTTP 연결대응하기 위해서입니다. 각 연결은 5초 동안 지속된 후 다시 연결됩니다.
- 클라이언트 장치 X와 클라이언트 장치 Y는 동일한 서버에 연결되어 있으므로 X와 Y가 쉽게 메시지를 보낼 수 있습니다.
질문
60,000개가 넘는 클라이언트 장치 X가 서버에 연결되어 있는 경우 내 로드 밸런서 또는 라우터에 TCP 포트가 부족해집니다. 예를 들어 20,000명의 사용자를 대상으로 확장하는 가장 좋은 방법은 무엇입니까?
내 서버는 Tomcat과 Java Servlet을 사용하여 Ubuntu 서버에서 실행되고 있습니다.
답변1
나는 당신의 60,000명의 고객이 실제 문제라고 생각하지 않습니다. 파일 설명자가 충분하지 않으면 문제가 발생할 가능성이 높지만 OS 구성의 일부로 쉽게 해결할 수 있습니다.
연결이 문제가 되지 않는 이유는 다음과 같습니다. 각 연결은 소스 IP 주소, 소스 포트, 대상 IP 주소 및 대상 포트로 특성화됩니다. 네트워크 스택 내에서 이 4배는 패킷을 파일 설명자(각 파일 설명자는 연결을 나타냄)와 일치시키는 데 사용됩니다. 귀하의 서버에는 고정된 대상 IP 주소와 대상 포트가 있지만(귀하의 서버는 클라이언트의 대상임) 소스 IP 주소와 소스 포트는 가변적입니다. 포트는 16비트 숫자이므로 한 클라이언트의 최대 연결 수는 64K입니다. IPv4 주소는 4,294,967,296개의 가능한 소스 주소를 제공하는 32비트 숫자입니다. 몇 가지 기본적인 계산을 수행하면 서버는 단일 소스 IP 및 포트에 매핑된 64K * 4,294,967,296개의 연결을 가질 수 있습니다.
이것이 클라이언트 수보다 최대 열린 파일 설명자 수에 문제가 발생할 가능성이 더 높은 이유입니다.
답변2
가장 간단한 접근 방식은 DNS 수준에서 로드 밸런싱을 구현하는 것입니다.
의미: 2개, 3개 이상의 물리적 로드 밸런서로 균형을 맞추는 라운드 로빈 DNS 항목이 있습니다.