OnuCloud 서버는 일본 도쿄에 구축되어 있습니다.
공유 디스크 변동이 쿼리에 영향을 주나요, 아니면 백업 작업 중 압축과 검증이 CPU를 점유하나요? 먼저 병목을 구분한 뒤 디스크, 메모리, 복구 대역폭을 계획하세요. 서버 단독 사용이 중복성 설계를 대신하지는 않습니다.
아래에서는 호스트, 데이터 서비스, 백업, 서비스 접속을 항목별로 살펴봅니다. 단일 사양만으로 워크로드를 판단하지 않습니다.
Proxmox VE는 여러 서비스를 한 대의 단독 사용 서버에서 장기간 운영하기에 적합합니다. 리소스 할당은 명확하지만 VM별 할당량, 네트워크 격리, 백업은 별도로 구성해야 합니다.
AMD EPYC 7543P는 32코어 64스레드를 제공하며 AMD-V와 NPT를 지원해 중첩 가상화를 사용할 수 있습니다. 중첩 환경은 가상화 구성을 검증하는 데 적합하지만, 계층이 늘면 오버헤드가 발생하므로 성능 저하가 없다는 뜻은 아닙니다.
128GB DDR4-3200 ECC는 리소스 규모가 명확한 호스트에 적합합니다. VM이 많거나 ZFS ARC에 더 많은 메모리를 할당하려면 256GB 구성을 검토할 수 있습니다. CPU 할당량, 호스트 여유분, 메모리 예산을 함께 계산하고 스레드 수만으로 인스턴스 수를 정하지 마세요.
메모리는 개통 후 같은 서버에서 업그레이드할 수 없습니다. 사양 변경 시 새 서버를 별도로 주문하고 서비스를 직접 이전해야 합니다.
VM 디스크는 기본 제공되는 2 × 1TB NVMe 직접 연결 디스크에 배치한 뒤, 복구 요구사항에 따라 각각 사용하거나 미러를 구성할 수 있습니다. 추가 2TB NVMe는 백업 볼륨으로 사용할 수 있으며, 최대 2개까지 추가할 수 있습니다. 각 디스크도 개별적으로 직접 연결됩니다.
같은 서버에 백업하면 일상적인 롤백은 편리하지만 서비스와 장애 범위가 같습니다. 중요한 사본은 별도로 원격지에 저장해야 합니다. 백업을 다른 VM에 넣어도 같은 물리 서버 안에 있다는 사실은 달라지지 않습니다.
가상화 호스트를 직접 관리할 수 있는 관리자에게 적합합니다. 사이트에서 VM, 백업 정책, 시스템 구성을 대신 관리하기를 원하는 프로젝트에는 적합하지 않습니다.
데이터베이스 쿼리, 인덱스 생성, 로그 쓰기, 캐시 영속화는 디스크 대기 시간에 대한 요구가 서로 다릅니다. NVMe가 공유 스토리지를 거치지 않고 각각 직접 연결되어 다른 고객과 공유 클라우드 디스크를 두고 경쟁하면서 생기는 변동을 피할 수 있습니다. 다만 애플리케이션의 잠금, 쿼리 계획, 같은 서버의 작업은 여전히 지연 시간에 영향을 줍니다.
데이터베이스와 미들웨어를 장기간 운영하고 CPU, 메모리, 디스크 할당을 명확히 해야 하는 경우 단독 서버의 리소스를 더 쉽게 배분할 수 있습니다. 메모리는 먼저 데이터베이스 버퍼와 캐시 작업 집합에 할당하고, 시스템·로그 처리·백업 압축을 위한 여유분을 남겨 두세요.
백업 스캔과 검증, 서비스 쿼리는 한 고객의 작업이라도 디스크와 CPU를 두고 경합할 수 있습니다. 단독 사용이라고 모든 작업을 동시에 최대 부하로 운영해도 된다는 뜻은 아니므로, 업무가 한산한 시간대에 작업을 예약하세요.
직접 연결된 디스크 2개가 RAID-1 어레이로 구성되어 제공되는 것은 아닙니다. 주·보조 전환, 미러링, 장비 간 복구가 필요한 서비스는 복제, 장애 감지, 복구 절차를 직접 설계해야 합니다. 같은 서버에서 디스크를 나누는 것만으로 고가용성을 확보할 수 없습니다.
하드웨어와 네트워크는 사이트에서 제공하며 데이터베이스 설정, 복제 구성, 데이터 백업은 고객이 관리합니다. 데이터센터에서 중복 구성을 작업하거나 데이터베이스를 관리해야 하는 프로젝트는 서비스 제공 범위에 포함되지 않습니다.
파일 스토리지는 사용 가능한 공간이 중요하고, 백업 서비스는 사본 격리와 복구 경로도 고려해야 합니다. 기본 제공되는 1TB NVMe 2개의 원시 용량은 총 2TB입니다. 두 디스크를 미러링하면 표시 용량은 약 1TB이며, 실제 사용 가능 공간은 포맷과 파일 시스템 오버헤드만큼 줄어듭니다.
| 디스크 구성 | 권장 용도 | 용량 기준 | 반드시 고려할 사항 |
|---|---|---|---|
| 기본 제공 2 × 1TB NVMe | ZFS 미러로 자주 사용하는 파일과 핫 데이터를 저장 | 원시 용량 총 2TB, 2디스크 미러 시 약 1TB | 미러링은 과거 버전을 보존하지 않으며, 동기화로 인한 실수 삭제도 방지하지 못합니다. |
| 추가 구성 2 × 2TB NVMe | 별도 백업 풀을 만들어 서비스 사본 저장 | 원시 용량 총 4TB, 2디스크 미러 시 약 2TB | 같은 서버 안의 사본입니다. 중요한 데이터는 별도로 원격지에 백업하세요. |
| 외부 원격지 사본 | 이 서버의 장애 범위 밖에 데이터 보관 | 직접 설정한 백업 대상의 용량에 따라 결정 | 읽기 가능 여부, 복구 순서, 필요한 시간을 정기적으로 확인 |
250 Mbps 기본 구성은 복구 시간에 여유가 있는 증분 동기화에 적합합니다. 대량 데이터 복구 시간을 줄여야 한다면 1 Gbps 또는 2 Gbps를 검토할 수 있습니다. 세 가지 모두 트래픽 제한이 없으며 전송량에 따른 추가 요금도 없습니다. 실제 복구 속도는 상대편 대역폭, 라우팅, 디스크 쓰기, 암호화 오버헤드에도 영향을 받습니다. 포트 속도는 종단 간 처리량을 보장하지 않습니다.
추가 구성 전에 복구 대상 데이터의 양, 허용 가능한 서비스 중단 시간, 백업 대상의 쓰기 성능을 먼저 추산하세요. 상대편 속도가 느린데 서버 포트만 높여도 전체 복구 시간은 줄어들지 않습니다.
고정 IP는 쇼핑몰 관리 페이지, 서비스 콜백, IP 허용 목록에 적합합니다. 독립 IPv4는 주소 소유와 할당 문제를 해결하지만, 주소 수가 늘어도 서비스가 자동으로 격리되거나 외부 플랫폼의 심사·위험 관리가 면제되지는 않습니다.
독립 IPv4 1개가 기본 포함되며 최대 255개를 추가할 수 있어 총 256개까지 사용할 수 있습니다. VM이나 서비스별로 주소, 용도, 연결 대상, 접근 규칙을 기록해 같은 주소가 중복 설정되지 않도록 관리하세요.
여러 주소는 시스템에서 직접 연결해야 합니다. 원격 관리는 제어판에 표시된 첫 번째 IPv4만 사용하고, 나머지 주소는 서비스 계획에 따라 사용하세요. 방화벽, 포트 포워딩, VM 네트워크는 고객이 설정해야 합니다.
같은 서버에 IPv4를 추가해도 지리적으로 분산되지 않으며 장비 단위의 장애 범위도 바뀌지 않습니다. 여러 도시에 배포하거나 지역 간 장애 전환이 필요하거나 각 지역 사용자와 가까운 접속이 필수인 아키텍처의 모든 역할을 단일 서버에 맡겨서는 안 됩니다.
여러 쇼핑몰 관리 페이지를 같은 서버에서 운영할 때는 계정, 자격 증명, 서비스 권한을 각각 관리해야 합니다. 네트워크 주소를 나눠도 시스템 권한과 규정 준수 요건은 별도로 충족해야 합니다.
Windows Server 기반 애플리케이션은 Standard 또는 Datacenter 라이선스를 선택할 수 있으며 월 단위로 과금됩니다. Windows 운영 경험이 있고 애플리케이션 설치와 시스템 관리를 직접 수행할 수 있는 업무에 적합합니다. 애플리케이션 호스팅이나 시스템 운영 대행 서비스는 아닙니다.
Windows Server 2019, 2022, 2025를 제공하며 영어, 번체 중국어, 간체 중국어 중 시스템 언어를 선택할 수 있습니다. 서버 제공 후 제어판에서 접속 정보를 확인하고 RDP로 접속하세요. IPv4가 여러 개 있는 경우에도 원격 접속에는 첫 번째 주소만 사용합니다.
업무 애플리케이션, 드라이버, 종속 구성 요소가 선택한 운영체제 버전과 호환되는지 먼저 확인하세요. 시스템 언어를 선택해도 애플리케이션의 현지화가 완료되는 것은 아니므로 앱 언어와 라이선스는 별도로 확인해야 합니다.
Standard와 Datacenter는 실제 라이선스 요구사항에 따라 선택해야 하며 메모리 용량만으로 판단할 수 없습니다. Windows와 Linux 업무를 가상화로 한 서버에서 함께 운영하려면 게스트 운영체제에 적용되는 라이선스 범위도 별도로 확인하세요.
독점 업무용 소프트웨어 사전 설치, 디렉터리 서비스 설정, 애플리케이션 계정 관리가 필요한 경우 표준 제공 범위에 포함되지 않습니다. 선택 전에 소프트웨어 종속성, 접근 권한, 백업 방식을 정리한 뒤 시스템과 하드웨어가 요구사항을 충족하는지 확인하세요.
OnuCloud 서버는 리소스를 지속적으로 사용하고 규모가 명확하며 시스템을 직접 관리할 수 있는 워크로드에 적합합니다. 병목이 단독 CPU 성능, 직접 연결 디스크, 고정 IP와 관련 없다면 서버 전체 임대는 유휴 비용과 운영 부담을 늘릴 수 있습니다.
연산량이 적고 디스크 사용이 많지 않으며 작업 종료 후 해제할 수 있는 테스트 환경은 범용 공유 VPS가 더 경제적인 경우가 많습니다. 32코어 64스레드 서버를 장기간 유휴 상태로 두면 단독 사용의 이점을 실질적인 가치로 이어가기 어렵습니다.
시간 단위로 인스턴스를 늘리거나 줄여야 하거나 이벤트에 맞춰 대량의 리소스를 임시 조정해야 한다면 탄력형 서비스를 먼저 검토하세요. 이 서비스는 메모리 사양 변경 시 새 서버를 주문해야 하므로, 기존 서버 확장을 갑작스러운 트래픽 대응 수단으로 삼기에는 적합하지 않습니다.
소프트웨어 RAID, ZFS, 가상화 네트워크, 데이터 복구는 지속적인 관리가 필요합니다. 시스템 설정과 백업 검증을 맡을 수 없다면 하드웨어 단독 사용을 관리형 서비스로 간주하지 말고 먼저 운영 책임을 정리해야 합니다.
온프레미스 대규모 언어 모델 추론, LoRA / QLoRA 미세 조정 실험, AI 애플리케이션 프로토타입 검증에는 DGX Spark도 검토할 수 있습니다. AMD 스토리지 서버의 가속 옵션은 아니므로 두 제품군 중 각각 선택해야 합니다.
모델 출력 비교, 추론 파이프라인 검증, 미세 조정 방식 실험, CUDA 프로그램 개발은 평가 목표와 결과 내보내기 방식을 먼저 정한 뒤 서버 환경의 적합성을 판단하는 것이 좋습니다. 모델과 개발 종속성은 직접 준비해야 합니다.
x86 프로그램, Windows 환경, 다중 서버 학습에 의존하는 프로젝트는 이 제품군으로 바로 이전해서는 안 됩니다. 아키텍처와 소프트웨어 호환성을 먼저 확인한 뒤 모델 실험을 계획해 환경 이전 비용을 빠뜨리지 않도록 하세요.
핫 데이터 용량, 사본 위치, 메모리 작업 집합, 복구 대역폭을 기록한 다음 실제 요구사항에 맞춰 OnuCloud 구성 페이지로 이동하세요. 이중화와 백업 계획은 서버 사양과 함께 결정해야 합니다.