웹소켓을 사용하여 게시/구독 서비스를 설정하려고 합니다. 내가 알 수 있는 바에 따르면 확장성 병목 현상은 주로 메모리와 관련이 있으며 이는 한 번에 열 수 있는 소켓 수에 영향을 미치므로 이를 API와 같은 서비스를 실행하는 다른 서버와 분리하는 것이 현명하다고 생각합니다. 이 올바른지? 호스팅의 경우 메모리가 컴퓨팅 성능보다 더 비싸다고 생각합니다. 확장성과 비용을 위해 이러한 유형의 서버를 최적화하는 모범 사례가 있습니까?
목표는 정기적으로 백엔드를 폴링할 필요 없이 현장에서 시스템이 새로운 데이터를 체크인할 때 이 웹 애플리케이션 사용자에게 실시간 업데이트를 제공하는 것입니다. 하지만 우리는 서버 비용을 두 배로 늘리고 싶지 않습니다. 그렇지 않으면 그럴 가치가 없을 수도 있습니다. 우리는 현재 API 서버에 대한 로드 밸런싱 및 자동 확장 기능이 있는 AWS EC2를 사용하고 있습니다.
답변1
단일 소켓의 실제 메모리 사용량은 그다지 많지 않습니다.
메모리를 소모하는 것은 어떤 클라이언트가 어떤 업데이트에 관심이 있는지, 어떤 클라이언트가 이미 특정 업데이트를 받았는지와 관련된 상태입니다.
기본 구현(예: OS 네트워크 스택 사용)에서 후자의 상태는 나가는 버퍼의 형태로 유지됩니다. 따라서 업데이트가 10,000개의 클라이언트에 전송되면 데이터는 10,000번 복사되고 각 복사본은 나가는 대기열(연결별 상태를 포함하는) 필수 헤더로 보강된 다음 헤더와 페이로드를 연결한 패킷을 보내도록 하드웨어에 지시하는 설명자가 구축됩니다.
페이로드의 클라이언트별 복사본은 클라이언트가 승인할 때까지 메모리에 보관되며, 여기서 메모리 요구 사항이 발생합니다. 이 메모리는 페이지 아웃할 수 없으므로 다른 애플리케이션에 메모리와 캐시 압력을 발생시킵니다.
서버 프로그램 자체 내부에 네트워크 스택의 일부를 구현하는 구현이 있으며, 이는 참조 계산을 통해 복사본을 피하거나 필요에 따라 페이로드를 다시 생성하여 훨씬 적은 메모리 사용량으로 벗어날 수 있지만 많은 작업이 필요합니다. 진정한 확장성을 위한 까다로운 코딩, 특히 다중 소켓 서버는 OS 네트워크 스택이 해결 방법을 이미 알고 있는 몇 가지 흥미로운 문제를 제기합니다.
당신이 가지고 있는 옵션
- 앱과 동일한 서버에서 게시/구독 서비스 실행
- OS 네트워킹을 갖춘 전용 서버에서 게시/구독 서비스 실행
- 커스텀 네트워킹을 사용하여 전용 서버에서 게시/구독 서비스 실행
- 여러 전용 서버에서 게시/구독 서비스 실행
서비스 성장에 따른 에스컬레이션 전략입니다. 공유에서 전용으로 전환하는 데는 많은 계획이 필요하지 않으며 필요에 따라 수행할 수 있습니다. 그런 일이 발생했다면 이제 다음 단계를 준비할 차례입니다.
여러 서버로 확장하면 클라이언트가 다른 순서로 업데이트를 받을 수 있으므로 시스템에 비결정성이 도입됩니다. 따라서 이 확장 단계가 성공하려면 클라이언트가 이를 인식하고 일관된 보기를 제공할 수 있어야 합니다. 그것이 사소하거나 어려운지는 실제 애플리케이션에 따라 다릅니다.
tl;dr:조기에 최적화할 필요가 없습니다. 첫 번째 확장 단계가 간단한 구성 변경이 되도록 서비스를 분할하고 변경이 발생하는 즉시 최적화를 시작하세요.