8개의 코어가 있는 서버를 프로비저닝했으며 네트워크 서비스 배포를 계획하고 있습니다. 요청 로드를 분산시키기 위해 서비스 인스턴스를 8개 실행하고 싶습니다. 여기에는 충격적인 것이 없습니다. 하드웨어 부하 분산 장치에 액세스할 수 없습니다. 현재 5개의 공용 IP 주소를 할당했다는 점을 언급하고 싶습니다(그러나 더 많은 것을 할당할 수 있습니다).
따라서 소프트웨어 부하 분산 솔루션 구성에 대한 귀하의 권장 사항을 듣고 싶습니다.
확실한 선택은 다음 중 하나입니다.
- HAProxy를 사용합니다. 또는
- 내 애플리케이션을 미리 포크합니다(Facebook Tornado 및 Unicorn 둘 다 수행함).
- 여기에 당신의 아이디어를 삽입하세요.
내 목표는 다음과 같습니다.
- 서비스 인스턴스 간에 요청 로드를 분산시킵니다. 그리고
- 내 서비스의 순차적 재시작을 허용합니다(코드 업그레이드).
이것은 HTTP 기반 서비스가 아니므로 NGiNX 등은 존재하지 않는다는 점을 언급하고 싶습니다.
나는 메모리 요구 사항 때문에 HAProxy를 좋아하지 않습니다. 클라이언트 연결당 읽기 및 쓰기 버퍼가 필요한 것 같습니다. 따라서 커널 수준, HAProxy 및 내 애플리케이션에 버퍼가 있게 됩니다. 점점 바보같아지고 있어! 아마도 나는 이와 관련하여 뭔가를 놓치고 있는 것일까요?
감사해요!
답변1
솔루션이 무엇이든 스트림 데이터를 전달하는 프로세스를 설치하는 경우 연결별 버퍼가 필요합니다. 항상 받은 것을 모두 보낼 수는 없기 때문에 초과분을 버퍼에 보관해야 합니다. 즉, 메모리 사용량은 동시 연결 수에 따라 달라집니다. 한 대규모 사이트는 150000 동시 연결(4GB RAM)의 기본 설정으로 haproxy를 성공적으로 실행하고 있습니다. 그 이상이 필요한 경우 버전 1.4를 사용하면 다시 컴파일하지 않고도 버퍼 크기를 조정할 수 있습니다. 그러나 소켓당 커널 버퍼는 방향당 및 소켓당 4kB 미만으로 떨어지지 않으므로 연결당 최소 16kB가 된다는 점을 명심하세요. 즉, 버퍼당 8kB 미만으로 haproxy를 실행하는 것은 의미가 없습니다. 이미 커널보다 적게 소비하기 때문입니다.
또한, 귀하의 서비스가 순수 TCP이고 프록시에 부가 가치가 없다면 LVS와 같은 네트워크 기반 솔루션을 살펴보십시오. 패킷을 처리하고 버퍼를 유지할 필요가 없으므로 훨씬 저렴하므로 소켓 버퍼는 패킷이 가득 차면 패킷을 삭제하고 서비스와 동일한 시스템에 설치할 수 있습니다.
편집하다: Javier, 로드 밸런싱을 수행하기 위해 OS에 의존하는 사전 포크된 프로세스는 전혀 확장되지 않습니다. OS가 깨어난다모든연결되면 프로세스를 완료하면 그 중 한 명만 연결되고 다른 모든 사람은 다시 잠자기 상태가 됩니다. 다중 프로세스 모드의 Haproxy는 4개 프로세스 주변에서 최고의 성능을 보여줍니다. 8개 프로세스에서는 이미 성능이 떨어지기 시작합니다. Apache는 이에 대해 좋은 트릭을 사용합니다. 즉, 단 하나의 프로세스만 승인을 기다리도록 accept()를 잠그는 것입니다. 그러나 이는 OS의 로드 밸런싱 기능을 종료하고 1000~2000개 프로세스 사이의 확장을 중지합니다. 몇 개의 프로세스가 깨어나도록 몇 개의 잠금 배열을 사용해야 하지만 그렇게 하지 않습니다.
답변2
귀하의 서비스에 대한 세부 정보 없이는 말하기가 매우 어렵습니다. 하지만 일반적으로 나는 프리포킹을 선호합니다. 이것은 시도되고 진정한 서버 전략입니다(일부 사람들이 토네이도/유니콘 팬 사이트를 읽은 후 생각하는 것처럼 새로운 기술은 아닙니다).
그 외에도 몇 가지 팁:
각 사전 포크 프로세스는 최신 비
select전략(주로 libevent)을 사용하여 엄청난 양의 클라이언트를 처리할 수 있습니다.코어와 프로세스 간의 1:1 관계가 최적의 성능을 제공하는 경우는 매우 드뭅니다. 일반적으로 로드에 대한 동적 적응성을 수행하는 것이 훨씬 좋습니다.