워크로드 예산으로 SaaS VPS 크기 결정

호스트를 선택하기 전에 작업을 명명하세요

요청 경로를 그리세요: 역방향 프록시, API 프로세스, 데이터베이스 및 외부 서비스. 비동기 경로를 추가하세요: 대기열, 워커 및 내보내기 대상. 어떤 구성 요소가 호스트를 공유하는지, 누가 동시성을 제어하는지, 재구축 후에도 어떤 데이터가 유지되어야 하는지 기록하세요. 애플리케이션 지표와 대표 데이터가 있는 비프로덕션 워크로드가 필요합니다. 이 가이드는 프로비저닝된 PrivacyNodes 인스턴스를 가정하지 않습니다.

예시적인 보고 API의 경우, HTTP 요청이 계정 설정을 읽고 내보내기를 대기열에 넣습니다. 워커가 행을 스캔하고 파일을 작성합니다. 빠른 대기열 응답은 피크 트래픽 중에 내보내기가 완료될 수 있음을 증명하지 않습니다. 테스트 계획에 예약된 정리 및 배포 중복을 포함하세요.

메모리 워크시트에 중복을 포함하세요

이는 MiB 단위의 가상 계획 입력이며, PrivacyNodes에 대한 측정 또는 약속이 아닙니다. 관찰된 애플리케이션 요구 사항으로 대체하세요. RSS는 상주 공유 매핑을 포함합니다. 모든 프로세스의 RSS를 더하면 메모리가 이중 계산될 수 있습니다. 호스트의 사용 가능한 메모리는 모든 파일 시스템 캐시를 영구적으로 사용할 수 없는 것으로 취급하는 것보다 더 유용합니다.

기술 참조: Linux 프로세스 메모리 회계.

이는 편안한 용량을 가정하기에는 명목 4 GB 범위에 너무 근접합니다. 호스트에서 보고된 실제 메모리와 피크가 겹치는지 확인하세요. 동시성을 줄이거나, 구성 요소를 이동하거나, 메모리를 추가하세요. 테이블을 맞추기 위해 예약을 제거하지 마세요.

PostgreSQL work_mem 는 작업당 허용량이며 총 데이터베이스 제한이 아닙니다. 동시 세션과 작업이 그 효과를 배가할 수 있습니다. Docker 컨테이너는 기본적으로 CPU 또는 메모리 제약이 없습니다. 이미지는 리소스 정책이 아닙니다.

기술 참조: PostgreSQL 리소스 소비 · Docker 리소스 제약.

대기열 수명과 함께 CPU를 측정하세요

일반 요청, 가장 느린 유용한 보고서, 실패한 종속성 및 내보내기를 함께 실행하세요. 동일한 간격 동안 지연 백분위수, 오류, 호스트 CPU, 워커 동시성 및 가장 오래된 작업 수명을 기록하세요. 대기열 증가와 함께 나타나는 CPU 압박은 긴 데이터베이스 대기와 낮은 CPU와는 다른 조치를 시사합니다.

예제를 진행 중인 내보내기 하나로 시작하세요. 워커가 외부 스토리지에서 대기하면 추가 CPU는 거의 변화를 주지 않을 수 있습니다. API 지연이 증가하면서 코어를 반복적으로 포화시키면 더 작은 내보내기 배치 또는 별도의 워커 예산을 테스트하세요. 용량을 구매하기 전에 하나의 요소를 변경하고 동일한 시나리오를 반복하세요.

다음 유지 관리 작업 예산을 책정하세요

데이터베이스 파일 및 인덱스, 업로드, 로그, 임시 내보내기, 릴리스 아티팩트 및 유지 관리를 위한 여유 공간을 나열하세요. 주당 증가량과 예약이 소진되는 시점을 기록하세요. 20 GB 데이터 세트와 20 GB 임시 복사본은 일반 애플리케이션 트래픽이 조용하더라도 20 GB 이상이 필요합니다.

로그 회전 및 내보내기 만료를 할당하세요. 호스트의 실패 경계 외부에 복구 복사본을 유지하세요. 추가 VPS 스토리지는 작업 할당을 확장합니다. 동일 디스크의 복사본은 독립적인 백업이 아닙니다. 정상 작동과 백업 또는 내보내기와 함께 실행되는 릴리스를 모두 테스트하세요.

다시 검토할 수 있는 결정을 작성하세요

출력은 워크시트, 워크로드 설명 및 검토 트리거입니다: 대표 테스트 중 가장 오래된 작업 수명 증가, 유지 관리 공간 축소 또는 현재 프로세스와 공존할 수 없는 릴리스. 보편적인 CPU 백분율 임계값을 만들어내는 대신 관찰을 기록하세요.

비교 App 2 및 Scale 4 해당 제약 조건에 대해. 결과가 여전히 놀랍다면, 하나의 느린 요청을 스택을 통해 추적하세요. 이 연습은 워크로드를 추정합니다. 공급업체 벤치마크, 트래픽 용량 또는 가용성을 설정하지 않습니다.