이는 독립적인 빌더를 위한 예시적 계획 시나리오이며, 고객 사례나 측정된 용량 결과가 아닙니다. 이 애플리케이션은 소규모 클럽의 장비 대여를 기록합니다: 인증된 회원은 사용 가능한 항목을 보고, 대여를 생성하고 반납할 수 있습니다. 화려한 배포 다이어그램보다 기록이 더 중요하므로, 첫 설계는 실패한 쓰기와 손실된 데이터를 쉽게 조사할 수 있도록 해야 합니다.
최소한의 유용한 아키텍처 선택
하나의 API 프로세스, 하나의 데이터베이스, 그리고 공용 HTTPS 엔드포인트를 위한 역방향 프록시를 사용하세요. 데이터베이스는 의도된 로컬 또는 비공개 경로를 통해서만 접근 가능하게 유지하세요. 애플리케이션에 자체 운영 체제 ID를 부여하고 필요한 파일에 접근할 수 있게 하세요. 배포 파일을 영구 데이터와 분리하여 릴리스가 데이터베이스나 업로드를 대체하지 않도록 하세요.
인스턴스를 공유하면 첫 배포에서 구성과 조사를 관리 가능하게 유지할 수 있습니다. 또한 구성 요소를 동일한 재시작, 디스크 및 장애 경계에 묶습니다. 이 트레이드오프를 의도적으로 받아들이세요. 애플리케이션이 독립적인 복구를 요구하거나 데이터베이스가 API와 지속적으로 경쟁한다면, 모든 것을 한꺼번에 늘리기 전에 분리를 고려하세요.
바쁜 순간을 위한 예산
유휴 프로세스만을 위해 크기를 정하지 마세요. 아래 워크시트는 계산을 시연하기 위해 가상의 계획 허용치를 사용합니다. 이는 이 애플리케이션의 측정값, 벤치마크 또는 최소 요구 사항이 아닙니다. 대표적인 배포를 포함하여 런타임과 데이터베이스에서 관찰한 값으로 대체하세요.
| 인스턴스 공유 작업 | 계획 여유분 | 관찰할 항목 |
|---|---|---|
| 운영 체제 및 프록시 | 300 MiB | 일반적인 백그라운드 활동 및 로깅 |
| API 프로세스 | 350 MiB | 시작뿐 아니라 대표적인 요청 |
| 데이터베이스 | 400 MiB | 연결, 쿼리 및 유지 관리 작업 |
| 배포 여유 공간 | 450 MiB | 겹치는 프로세스 또는 빌드 단계 |
| 총 계획 범위 | 1,500 MiB | 실제 사용 가능한 메모리와 비교 |
The 빌드 시작 계획 현재 2 vCPU, 2 GB RAM 및 50 GB SSD를 지정합니다. 이 수치는 이 워크시트에서 조사할 구성임을 나타낼 뿐, 스택이 적합하다는 증거는 아닙니다. 카탈로그의 GB와 도구의 MiB 판독값은 서로 다른 단위이므로 실제 시스템 총량을 확인하세요. Linux의 사용 가능 메모리 추정치는 관련 회수 가능 메모리를 고려하므로, 여유 메모리가 낮다는 것만으로는 사이징 판단이 될 수 없습니다. 참조: MemAvailable에 대한 커널 설명 그리고 측정 가이드.
CPU와 디스크는 별도로 결정해야 합니다. vCPU를 추가하기 전에 요청 지속 시간과 데이터베이스 대기 시간을 기록하세요. 운영 체제, 보관된 릴리스, 데이터베이스 증가, 로그 및 임시 복구 작업을 고려하여 디스크 예산을 책정하세요. 업로드 기능은 작은 구조화된 레코드와는 다른 저장 문제를 야기하므로 크기 제한과 보존 결정을 내려야 합니다.
초기 비용 파악
다음 예는 기본 리소스와 추가 정기 옵션 없이 Build를 사용합니다. 월간 소계는 $14.00 USD입니다. 값은 현재 구성기 카탈로그에서 생성되므로 가격 표는 결제를 따릅니다.
| 서비스 기간 | 저장 전 | 저장됨 | 일시불 결제 |
|---|---|---|---|
| 1개월 | $14.00 | $0.00 (0%) | $14.00 USD |
| 3개월 | $42.00 | $0.00 (0%) | $42.00 USD |
| 6개월 | $84.00 | $23.52 (28%) | $60.48 USD |
| 12개월 | $168.00 | $84.00 (50%) | $84.00 USD |
6개월 또는 연간 기간은 동일한 개월 수에 대해 할인되지 않은 월간 소계를 지불하는 것보다 이 카탈로그의 선불 총액을 낮춥니다. 이는 리소스를 추가하거나 갱신 가격을 확정하거나 검증되지 않은 아키텍처를 적합하게 만들지 않습니다. 약정할 수 있는 기간을 선택하고, 서비스 및 청구 세부 정보를 검토하고, 도메인, 외부 서비스 및 네트워크 요금을 별도로 고려하세요.
하나의 완전한 요청 확인
애플리케이션을 의도된 사용자에게 공개하기 전에 서버 액세스와 복구 액세스를 확인하고, 지원되는 런타임을 설치하고, 배포하는 릴리스를 기록하세요. 서비스 정의는 실행 파일, 작업 디렉터리 및 런타임 사용자를 식별해야 합니다. Systemd의 Restart= 설정은 지정된 실패 동작을 제어합니다. 재시작 루프는 여전히 진단이 필요합니다. 참조 서비스 매뉴얼 그리고 배포 안내.
먼저 로컬에서 테스트한 다음 다른 연결에서 실제 HTTPS 이름을 통해 테스트하세요. Caddy에서 자동 인증서 관리는 유효한 이름 구성과 작동하는 검증 방법에 따라 달라집니다. 일반적인 HTTP 및 TLS-ALPN 챌린지는 각각 접근 가능한 인바운드 포트 80와 443이 필요합니다. 참조 Caddy HTTPS 필수 조건. 로컬 성공이 DNS나 프록시 문제를 배제할 수는 없습니다. 요청 경로 가이드 에서 설명합니다.
애플리케이션 검사를 구체적으로 만드세요. 일회용 장비 항목을 만들고, 대여하고, 두 번째 요청이 저장된 결과를 보는지 확인한 다음 반환하세요. 간단한 상태 엔드포인트뿐만 아니라 권한 부여도 확인하세요. 테스트 전에 예상 응답을 기록하고, 문제 해결을 위해 공유하는 로그에 자격 증명과 회원 데이터를 포함하지 마세요.
소규모 복구 증명
엔진과 복구 목표에 적합한 방법으로 데이터베이스를 백업하세요. PostgreSQL은 논리적, 파일 시스템 및 연속 아카이빙 접근 방식을 별도로 문서화합니다. 올바른 선택은 복구해야 하는 방식에 따라 달라집니다. 참조 백업 개요. 항목 사진이 업로드되는 경우 해당 파일과 데이터베이스 레코드와의 관계를 포함하세요.
별도의 테스트 데이터베이스와 디렉터리로 복원 연습을 실행하세요. 알려진 항목과 해당 파일을 찾은 다음 애플리케이션이 둘 다 읽을 수 있는지 확인하세요. 선택한 백업, 데이터 타임스탬프, 필요한 단계 및 실제 결과를 기록하세요. 첫 번째 복원 가이드 에서 이 연습을 발전시킵니다. 선택적 카탈로그 백업 선택은 이 애플리케이션 수준 복구가 작동함을 증명하지 않습니다.
증거를 바탕으로 다음 결정 내리기
측정된 동작과 복구 요구 사항이 맞는 동안 간단한 설계를 유지하세요. 더 큰 요금제가 답이라고 가정하기 전에 중지된 애플리케이션 또는 리소스 경고 를 조사하세요. 서버로 말레이시아, 루마니아 또는 스위스를 선택한 다음 리소스 할당, 백업 위치 및 서비스 범위를 확인하세요. 이 시나리오는 시설, 요청 용량 또는 제공 시간을 설정하지 않습니다.
빌드 구성 및 모든 옵션 검토. 링크는 시작 요금제를 엽니다. 계속하기 전에 선택한 기간과 저장된 선택 사항을 확인하세요. 결제 세부 정보를 받는 것이 장비 대여 애플리케이션을 설치하지는 않습니다.
사용된 문서
이 페이지의 기본 참조. 자체 환경에 설치된 버전의 문서를 확인하세요.