SSD Nodes Learn Hosting plans →
가이드 Matt Connor작성자 Matt Connor

게임 서버용 VPS 선택 가이드: 필수 사양과 주의사항

게임 서버 운영을 위한 VPS 선택 시 반드시 고려해야 할 CPU 단일 코어 속도와 RAM 용량을 분석합니다. GPU가 없는 VPS에서 게임 실행이 불가능한 이유와 지연 시간 문제, systemd를 활용한 서버 관리 및 백업 설정 방법을 상세히 설명합니다.

어떤 종류의 게임용 VPS를 의미하십니까?

게임 서버용 VPS는 한 가지 용도로는 훌륭한 선택입니다. 바로 여러분과 친구들이 각자의 컴퓨터에서 접속할 수 있는 전용 서버를 운영하는 것입니다. 반면, 사람들이 흔히 말하는 또 다른 의미인 원격 데스크톱을 통해 VPS에서 직접 게임을 플레이하는 용도로는 적합하지 않습니다. 이 두 가지 작업은 서로 상반된 하드웨어 사양을 요구합니다. 전용 서버는 빠른 CPU 코어 하나와 게임 월드를 유지할 충분한 RAM이 필요합니다. 반면 게임 플레이에는 GPU(그래픽 처리 장치)가 필요한데, 일반적인 VPS 요금제에는 GPU가 포함되어 있지 않습니다.

아래의 모든 내용은 첫 번째 용도에 관한 것입니다. 두 번째 용도에 대해서는 많은 사람이 잘못된 서버를 구매하곤 하므로, 시간을 내어 2분 정도 확인해 볼 가치가 있습니다.

VPS에서 게임을 실행할 수 없는 이유

일반적인 VPS는 가상 CPU 코어만 제공하며 그래픽 카드는 제공하지 않습니다. 물리적 호스트로부터 전달되는 하드웨어가 없으므로 게임이 사용할 수 있는 하드웨어 렌더러가 존재하지 않습니다. 다음 명령어로 현재 할당된 장치를 확인할 수 있습니다.

sudo apt install -y pciutils
lspci | grep -iE "vga|3d"

결과로 나타나는 것은 Cirrus Logic이나 virtio GPU 장치와 같은 가상 디스플레이 어댑터입니다. 이는 제공자의 웹 콘솔에서 화면을 보여주기 위한 용도일 뿐, 3D 가속 기능은 없습니다. 이 환경에 데스크톱 환경과 VNC 서버를 설치하고 glxinfo -B을 실행하면 렌더러가 llvmpipe로 표시되는데, 이는 CPU에서 구동되는 Mesa 소프트웨어 렌더러입니다. CPU로 렌더링하는 최신 3D 게임은 초당 프레임 수가 매우 낮아, 외부로 전송되기도 전에 이미 플레이가 불가능한 상태가 됩니다. Windows 인스턴스도 마찬가지입니다. 많은 게임이 실행 시 Direct3D 장치를 생성할 수 없다는 오류를 내며 종료되는데, 이는 장치를 생성할 디스플레이 어댑터 자체가 없기 때문입니다.

두 번째 문제는 원격지에서 사용자에게 도달하는 과정입니다. 원격 서버에서 게임을 플레이하면 모든 프레임이 비디오로 인코딩되어 인터넷을 통해 전송된 뒤, 사용자의 화면에서 디코딩되어야 합니다. 이 과정에서 게임 자체의 입력 지연에 인코딩 및 디코딩 시간이 추가됩니다. 또한 RDP와 VNC는 초당 60프레임의 움직임이 아닌 일반적인 데스크톱 작업을 위해 설계되었습니다. 클라우드 게임 서비스는 실제 GPU 하드웨어와 전용 스트리밍 프로토콜을 사용하여 이 문제를 해결합니다. 일반적인 VPS에는 이 두 가지가 모두 없습니다. 게임을 즐기고 싶다면 GPU 자원을 대여하십시오. 호스팅이 목적이라면 계속해서 읽어 주십시오.

전용 게임 서버의 실제 요구 사항

게임 서버는 시뮬레이션 루프입니다. 서버는 메모리에 월드 데이터를 유지하며 초당 고정된 횟수만큼 시뮬레이션을 진행합니다. 연결된 각 플레이어에게는 해당 플레이어가 볼 수 있는 월드의 일부 정보가 전송됩니다.

이러한 구조가 하드웨어 사양을 결정합니다. 시뮬레이션 루프는 대부분 단일 스레드로 동작하므로 코어 개수보다 코어 클럭 속도가 더 중요합니다. 월드 데이터는 메모리에 상주하므로 보통 RAM 용량이 가장 먼저 도달하는 한계점입니다. 디스크는 게임 플레이 중에는 거의 사용되지 않지만, 데이터를 불러오거나 저장할 때는 사용량이 많아집니다. 네트워크 경로는 핑(ping)을 결정하며, 어떤 요금제를 선택하더라도 이 물리적 경로는 변경되지 않습니다.

싱글 코어 속도가 코어 개수보다 중요합니다

대부분의 게임 서버는 하나의 메인 스레드에서 월드 상태를 업데이트합니다. Minecraft의 틱 루프와 Source 엔진의 서버 프레임이 모두 이런 방식으로 작동합니다. 각 틱에는 처리 제한 시간이 있습니다. Minecraft Java는 초당 20틱으로 실행되며, 각 틱에는 50밀리초의 예산이 주어집니다. 작업이 이 시간 내에 끝나지 않으면 서버는 정확히 다음과 같은 메시지를 출력합니다.

[12:04:51] [Server thread/WARN]: Can't keep up! Is the server overloaded? Running 2547ms or 50 ticks behind

이 줄은 하나의 스레드가 제한 시간을 초과했음을 의미합니다. 코어를 추가한다고 해서 해당 스레드에 더 많은 시간이 주어지지는 않습니다. 8개의 느린 vCPU를 가진 플랜보다 2개의 빠른 vCPU를 가진 플랜이 틱 레이트를 더 잘 유지합니다. 8개 중 단 하나만이 중요한 작업을 수행하기 때문입니다.

결정하기 전에 반드시 싱글 스레드 속도를 측정하십시오.

sudo apt install -y sysbench
sysbench cpu --cpu-max-prime=20000 --threads=1 run

events per second 줄을 확인하십시오. 이 숫자는 단독으로는 의미가 없으며 비교할 때 비로소 가치가 있습니다. 따라서 두 개의 후보 플랜에서 각각 실행한 뒤 결과를 나란히 놓고 비교하십시오. 전체 VPS 벤치마크 실행에서는 디스크와 네트워크도 동일한 방식으로 다룹니다.

물론 추가 코어에도 쓸모는 있습니다. 추가 코어는 틱 스레드의 시간을 뺏지 않으면서 두 번째 게임 서버, 데이터베이스, 야간 백업, 청크 사전 생성 작업을 처리합니다. 서버 소프트웨어들도 점차 분산 처리를 도입하고 있으며, 인기 있는 Minecraft 서버 포크인 Paper는 일부 작업을 메인 틱 스레드 밖으로 분리하기도 합니다. 따라서 구매할 때는 코어 개수가 많은 것보다 소수의 빠른 코어를 선택하는 것이 좋습니다.

플랜 페이지에는 절대 나오지 않지만, 비용을 지불한 빠른 코어가 실제로 온전히 내 것인지 결정하는 지표가 있습니다.

vmstat 1 5

st 열은 가상 CPU가 실행 준비를 마쳤음에도 물리 호스트가 해당 코어를 다른 사용자에게 할당하여 대기한 시간의 비율을 나타냅니다. st가 몇 퍼센트 이상으로 꾸준히 유지된다면 해당 호스트는 과도하게 할당(oversold)된 상태입니다. 서버의 top 수치는 유휴 상태를 나타내더라도, 그 유휴 시간은 사용자가 쓸 수 있는 것이 아니므로 플레이어는 끊김 현상을 느끼게 됩니다.

게임 서버에는 RAM이 얼마나 필요한가?

차트Common starting RAM per game server (published guidance, not a measurement)
이 차트의 데이터
[
  {
    "label": "Minecraft Java, vanilla",
    "players": 10,
    "ram_gb": 2
  },
  {
    "label": "Minecraft Java, large modpack",
    "players": 10,
    "ram_gb": 8
  },
  {
    "label": "Valheim",
    "players": 10,
    "ram_gb": 4
  },
  {
    "label": "Palworld",
    "players": 32,
    "ram_gb": 16
  }
]

이는 2026년 8월 기준으로 게임 및 modpack 문서에서 제시하는 시작 할당량이다. 특정 서버 1대에서 측정한 수치가 아니라 참고용 기준이다. Vanilla Minecraft Java는 약 10명의 플레이어를 수용할 때 2 GB의 heap이면 충분하다. 대형 modpack에서 같은 인원으로 운영하려면 8 GB가 필요하다. mod가 entity와 생성 구조물을 추가하며 이들이 모두 해당 heap을 사용하기 때문이다. Valheim이 자체적으로 제시하는 최소 요구량은 2 GB다. 하지만 작은 월드를 운영하는 관리자는 프로세스가 3 GB에 가까운 수준에서 안정되는 경우가 많다고 보고한다. 따라서 시작점으로는 4 GB가 적절하다. Palworld는 예외적으로 32명의 최대 플레이어 수에 16 GB를 요구하며, 이는 Pocketpair가 권장하는 값이다.

RAM 사용량은 연결 수에 따라 증가하지 않는다. 로드된 월드의 크기에 따라 증가한다. 각 플레이어 주변의 region이 로드된 상태로 유지되므로, 두 플레이어가 같은 장소에 서 있을 때는 맵의 서로 반대편을 탐험하는 두 플레이어보다 훨씬 적은 RAM을 사용한다. 따라서 "플레이어당 RAM"은 대략적인 기준일 뿐이며, 실제 사용량을 결정하는 요소는 "활성 영역당 RAM"이다. 이 때문에 탐험을 즐기는 소규모 그룹은 그 두 배 인원을 기준으로 책정한 요금제도 초과할 수 있다.

Java 서버에는 2가지 추가 규칙이 있다. JVM이 heap 크기를 조정하느라 일시 중지하지 않도록 최소 heap과 최대 heap을 같은 값으로 설정한다.

java -Xms4G -Xmx4G -jar server.jar nogui

그다음 여유 공간을 남겨 둔다. JVM은 할당한 heap 외에도 thread stack과 native buffer에 메모리를 사용한다. kernel도 월드 파일을 빠르게 읽기 위해 page cache가 필요하다. 6 GB 서버에서는 4 GB heap이 적절하며, 6 GB heap은 적절하지 않다.

두 메모리 장애는 증상이 완전히 다르므로 두 메시지를 모두 알아야 한다. heap이 너무 작으면 Java 내부에서 예외가 발생하지만, 서버 프로세스는 대개 계속 실행된다.

java.lang.OutOfMemoryError: Java heap space

서버 전체 RAM보다 heap이 크면 프로세스 전체가 외부에서 종료된다. 콘솔에는 Killed만 표시되고, 원인은 kernel log에서 확인할 수 있다.

sudo dmesg -T | grep -i "out of memory"

swap을 추가하면 프로세스 종료를 막을 수는 있지만 문제 자체가 해결되지는 않는다. tick loop가 swap에서 월드 데이터를 다시 읽어야 하면 모든 기한을 놓친다. 그 결과 서버가 crash하는 대신 플레이어에게 멈춘 서버로 보인다.

버전 관련 참고 사항이다. Mojang의 version metadata를 2026-10-11에 확인한 결과, Minecraft Java 1.20.5부터 1.21.11까지는 Java 21이 필요하다. 26.1 이상 버전은 현재 버전인 26.3을 포함해 Java 25가 필요하다. 이전 runtime은 시작한 뒤 unsupported class file version error로 실패한다. 이 메시지는 compiler 메시지처럼 보여 처음 접하면 혼동하기 쉽다. Ubuntu 22.04, 24.04, 26.04는 모두 standard archive에서 Java 25 runtime을 제공한다.

sudo apt install -y openjdk-25-jre-headless
java -version

게임 서버에서 디스크 속도가 중요한가요?

게임 플레이 중에는 예상보다 덜 중요하지만, 특정 두 시점에서는 매우 중요합니다. 서버가 시작될 때 월드 데이터가 메모리로 읽히고 자동 저장 시 다시 디스크에 기록되므로, 디스크 속도는 부팅 속도와 자동 저장 시 발생하는 일시적인 멈춤 현상으로 나타납니다. 그 사이의 대부분 읽기 작업은 RAM에서 처리됩니다.

이 요약보다 디스크가 더 중요하게 작용하는 두 가지 이유가 있습니다. 플레이어가 이동할 때 새로운 청크나 구역을 디스크에서 불러오는데, 이 읽기 작업은 틱(tick) 예산 내에서 이루어져야 합니다. 대규모 월드에서 자동 저장이 실행되면 한꺼번에 많은 양을 기록하게 되며, 속도가 느린 볼륨에서는 이 쓰기 작업이 루프를 차단하여 앞서 언급한 "Can't keep up" 경고를 발생시킵니다. 이는 처리량(throughput) 문제라기보다 지연 시간(latency) 문제이며, 이것이 바로 VPS에서 NVMe와 SATA SSD의 차이가 단순한 초당 메가바이트(MB/s) 수치보다 더 중요한 이유입니다. 여기서 중요한 것은 작은 작업 하나를 처리하는 데 걸리는 시간입니다.

볼륨 크기는 성장을 고려하여 설정하십시오. 누군가 새로운 곳을 탐험할 때마다 월드 데이터는 커지며, 백업본은 그 크기만큼 배가됩니다. 한 달 동안 매주 du -sh world를 실행해 보면 실제 증가율을 파악할 수 있습니다.

틱 속도, ping, 그리고 두 개의 차이

틱 속도는 서버가 초당 세계를 다시 계산하는 횟수다. Minecraft Java는 20으로 실행된다. Source engine 서버는 일반적으로 64로 실행된다. Minecraft에서는 20을 기준으로 게임이 설계되었다. /tick rate 명령으로 이 값을 변경할 수 있지만, 세계 전체의 속도가 빨라지거나 느려질 뿐 더 매끄럽게 만들지는 않는다. 더 큰 서버를 사용해도 틱 속도가 자동으로 높아지지 않는다. 따라서 목표는 20을 초과하는 것이 아니라 20을 유지하는 것이다.

ping은 한 플레이어와 서버 사이를 왕복하는 데 걸리는 시간이다. 이 두 문제는 서로 다른 증상을 일으키므로 비용을 지출하기 전에 구분해야 한다. 서버가 틱을 놓치면 모든 플레이어가 같은 순간에 rubber-band 현상을 겪으며, 서버 로그에도 일반적으로 그 원인이 평문으로 기록된다. 한 플레이어의 network path가 길면 그 플레이어만 지연되고 나머지 그룹은 정상적으로 플레이한다. CPU를 더 성능이 높은 것으로 교체해도 두 번째 문제는 해결되지 않는다.

지연 시간은 요금제가 아니라 물리적 거리에 좌우됩니다

광섬유 속 빛은 1밀리초당 약 200km를 이동합니다. 왕복 거리는 이동 거리의 두 배이므로, 플레이어와 서버 사이의 거리 100km당 최소 지연 시간은 약 1ms입니다. 어떤 서비스 제공업체도 이 물리적 한계를 넘을 수 없으며, 요금제 업그레이드로도 해결되지 않습니다.

차트Round trip floor by distance, fibre physics only
이 차트의 데이터
[
  {
    "label": "Toronto to New York",
    "distance_km": 550,
    "rtt_floor_ms": 5.5
  },
  {
    "label": "Dallas to Chicago",
    "distance_km": 1290,
    "rtt_floor_ms": 12.9
  },
  {
    "label": "Dallas to Los Angeles",
    "distance_km": 1990,
    "rtt_floor_ms": 19.9
  },
  {
    "label": "New York to London",
    "distance_km": 5570,
    "rtt_floor_ms": 55.7
  },
  {
    "label": "Los Angeles to Sydney",
    "distance_km": 12070,
    "rtt_floor_ms": 120.7
  }
]

위 수치는 대권 거리를 기준으로 계산한 이론적 최솟값입니다. 실제 광케이블은 직선으로 연결되지 않으며, 경로상의 모든 라우터가 지연 시간을 추가하므로 실제 환경에서는 이론적 최솟값의 약 2배 정도가 일반적인 결과입니다. 토론토에서 뉴욕의 서버에 접속하는 경우 거리는 550 km이며, 이론적 최솟값은 5.5 ms이지만 실제로는 10ms 중반대의 지연 시간이 나타납니다. 로스앤젤레스에서 시드니로 연결하는 구간의 최솟값은 120.7 ms이며, 비용을 아무리 지불해도 이 물리적 한계를 단축할 수는 없습니다.

따라서 서버는 사용자가 위치한 곳과 가까운 곳에 배치해야 합니다. 사용자가 대양을 사이에 두고 나뉘어 있다면 누군가는 긴 경로를 이용할 수밖에 없으며, 가장 공평한 해결책은 일반적으로 플레이어가 가장 많이 분포한 지역을 선택하는 것입니다.

추측하지 말고 경로를 직접 측정하십시오:

sudo apt install -y mtr-tiny
mtr -rwzc 100 203.0.113.10

마지막 줄부터 확인하십시오. 마지막 줄은 서버를 의미하며, 해당 지점의 패킷 손실과 지연 시간만이 게임 체감 성능을 결정합니다. 중간 홉에서 나타나는 패킷 손실은 마지막 홉이 정상이라면 대부분 해당 라우터의 ICMP 속도 제한 때문입니다. 라우터는 실제 트래픽을 정상적으로 처리하면서도 프로브 패킷에 대한 응답은 후순위로 미루기 때문입니다. 모든 플레이어는 각기 다른 경로를 거치므로, 각 플레이어가 직접 서버를 대상으로 측정하게 하십시오.

왕복 지연 시간 최솟값 계산 방법

유리 매질 내의 빛은 진공 상태 속도의 약 3분의 2로 이동하며, 이는 1밀리초당 약 200km에 해당합니다. 왕복은 거리를 두 번 이동하는 것이므로, 밀리초 단위의 최솟값은 편도 거리(km)를 100으로 나눈 값입니다. 뉴욕에서 런던까지는 5,570km이며, 5570을 100으로 나누면 55.7ms가 됩니다. 케이블은 해안선을 따라 설치되고 라우터의 처리 시간도 소요되므로, 실제 측정값은 항상 이보다 높게 나타납니다.

게임에 필요한 포트만 엽니다

게임 서버에는 일반적으로 포트 1~2개만 열면 되며, 그 외 포트는 열지 않아야 합니다. 일반적인 기본값은 다음과 같습니다.

  • Minecraft Java Edition: TCP 25565
  • Minecraft Bedrock Edition: UDP 19132
  • Valheim: UDP 2456 및 UDP 2457
  • Palworld: UDP 8211
  • Counter-Strike 2 같은 Valve의 Source 및 Source 2 게임: UDP 27015

일부 게임은 추가 query port를 사용하므로 해당 게임의 공식 문서를 확인해야 합니다. Valheim이 대표적인 예입니다. 2456은 게임 트래픽을 전달하고, 2457은 Steam server query에 응답하여 서버가 브라우저 목록에 표시되도록 합니다. Valheim은 UDP만 사용하므로 이 포트를 TCP로 열어도 아무 효과가 없습니다.

방화벽을 활성화하기 전에 SSH를 허용해야 합니다. 그렇지 않으면 자신의 서버에 접속하지 못하게 됩니다.

sudo ufw allow 22/tcp
sudo ufw allow 25565/tcp
sudo ufw enable
sudo ufw status verbose

많은 provider는 서버 자체의 방화벽과 별도로 control panel에서도 network firewall을 운영합니다. ufw에서 포트가 열려 있어도 해당 firewall에서 닫혀 있으면 연결이 거부됩니다. 외부에서 보면 증상이 동일하므로, config 파일을 수정하기 전에 두 곳을 모두 확인해야 합니다.

다른 시스템에서 TCP 포트를 확인하는 방법은 간단합니다.

sudo apt install -y netcat-openbsd
nc -vz 203.0.113.10 25565

UDP는 같은 방식으로 테스트할 수 없습니다. 닫힌 UDP 포트는 일반적으로 응답하지 않으므로, probe에 응답이 없다고 해서 확인된 내용은 없습니다. 대신 서버 측에서 확인하고, 예상한 포트에 game process가 bind되어 있는지 확인해야 합니다.

sudo ss -lunp | grep 2456

RCON은 원격 console protocol이므로 인터넷에 절대 노출하지 않아야 합니다. 기본적으로 port 25575에서 단일 password를 plaintext connection으로 전송합니다. RCON을 127.0.0.1에 bind하고 SSH tunnel을 통해 접속해야 합니다. 또한 game server는 별도의 unprivileged user로 실행해야 합니다. 그래야 mod의 버그가 시스템의 나머지 부분에 접근할 수 없습니다. 새 VPS에서 처음 10분에서는 이 section에서 이미 완료했다고 가정하는 user account 설정과 SSH hardening을 다룹니다.

systemd에서 서버를 실행하여 자동으로 다시 시작하기

SSH 세션에서 수동으로 시작한 서버는 세션이 종료되면 중단되고, 재부팅 후에도 다시 시작하지 않는다. systemd는 이 두 문제를 모두 해결한다. 이 unit은 서버를 자체 minecraft 사용자로 실행하며, 이 사용자는 /opt/minecraft만 소유하고 다른 항목은 소유하지 않는다.

sudo useradd --system --home-dir /opt/minecraft --shell /usr/sbin/nologin minecraft
sudo chown -R minecraft:minecraft /opt/minecraft

그런 다음 /etc/systemd/system/minecraft.service을 작성한다.

[Unit]
Description=Minecraft Java server
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=minecraft
WorkingDirectory=/opt/minecraft
ExecStart=/usr/bin/java -Xms4G -Xmx4G -jar server.jar nogui
Restart=on-failure
RestartSec=15
TimeoutStopSec=180

[Install]
WantedBy=multi-user.target

Restart=on-failure은 충돌 후 서버를 다시 시작하고 정상적으로 종료한 뒤에는 중단된 상태로 둔다. 이것이 원하는 동작이다. Restart=always은 서버를 의도적으로 중지할 때마다 이 동작을 방해한다. TimeoutStopSec=180은 보기보다 중요하다. systemctl stop는 SIGTERM을 전송한다. vanilla Minecraft server는 이 신호를 받으면 종료하기 전에 월드를 저장한다. 제한 시간이 만료되면 systemd가 대신 SIGKILL을 전송한다. 큰 월드를 디스크에 기록하는 데 기본값인 90초보다 오래 걸릴 수 있다. SIGKILL이 도착할 때까지 디스크에 기록되지 않은 데이터는 손실된다.

sudo systemctl daemon-reload
sudo systemctl enable --now minecraft
sudo journalctl -u minecraft -f

정상적으로 시작되면 Done (12.345s)! For help, type "help"과 같은 줄로 끝난다. unit이 activating과 failed 사이를 반복해서 전환하면 journalctl -u minecraft -n 50에 원인이 기록되어 있다. 일반적으로 WorkingDirectory의 경로가 잘못되었거나 시스템보다 큰 heap을 지정한 경우다.

이와 같은 systemd 서비스는 기본적으로 대화형 콘솔 없이 실행되므로 미리 이를 고려해야 한다. 명령에는 localhost의 RCON을 사용하거나, 서버를 tmux 세션 안에서 실행한다. 이는 로그인 사이에도 VPS에서 장시간 실행되는 Claude Code 세션을 유지하는 데 사용하는 방법과 같다.

Steam을 통해 배포되는 게임은 이 작업을 수행하기 전에 SteamCMD가 필요하다. Ubuntu 패키지는 32 bit 바이너리이므로 architecture 줄이 필요하다. 이 줄을 생략하면 apt이 설치 후보가 없다고 보고한다.

sudo add-apt-repository multiverse
sudo dpkg --add-architecture i386
sudo apt update
sudo apt install -y steamcmd

일부 게임 서버는 실행 시간이 길어질수록 메모리 사용량이 증가한다. 이 문제를 해결하지는 못하지만, 사용량이 적은 시간에 예약 재시작을 수행하는 것이 일반적인 우회 방법이다. systemctl restart을 호출하는 systemd timer는 cron 항목보다 동작을 파악하기 쉽다. systemctl list-timers을 사용하면 다음 실행 시점을 정확히 확인할 수 있기 때문이다.

일정 기반으로 월드 백업하기

게임 서버의 모든 데이터는 월드 디렉터리와 플레이어 데이터를 제외하면 언제든 다시 생성할 수 있습니다. 게임을 재설치하는 데는 몇 분이면 충분하지만, 그룹이 함께 건설한 결과물을 다시 만드는 데는 몇 달이 걸릴 수 있습니다.

가장 안전한 백업은 아무런 쓰기 작업이 일어나지 않을 때 수행하는 것입니다. 서버를 1분간 중단하는 것이 이를 보장하는 가장 간단한 방법입니다.

sudo systemctl stop minecraft
sudo tar czf /var/backups/mc-$(date +%F).tgz -C /opt/minecraft world world_nether world_the_end
sudo systemctl start minecraft

매일 밤 서버를 멈추는 것이 불가능하다면, 대신 월드 데이터를 먼저 플러시(flush)하십시오. Minecraft 콘솔에서 save-off는 자동 저장을 중지하고, save-all flush은 대기 중인 모든 데이터를 기록하며, save-on은 복사가 완료된 후 자동 저장을 다시 활성화합니다. 서버가 쓰기 작업을 수행하는 도중에 월드를 복사하면 절반만 기록된 리전 파일이 생성될 수 있으며, 이는 정작 복구가 필요한 시점이 되어서야 문제를 발견하게 됩니다.

최소한 한 개의 사본은 서버 외부 장치에 보관하십시오. 동일한 디스크에 저장된 백업은 디스크 장애 시 함께 소실됩니다. 제공업체의 스냅샷은 편리한 기능일 뿐 진정한 백업은 아닙니다. 동일한 계정 내에 존재하므로 계정 손실 시 함께 사라질 수 있기 때문입니다. 외부 저장소로의 정기적인 restic 백업은 보존 기간 설정과 중복 제거를 지원하므로, 매일 밤 월드를 복사하더라도 디스크 용량을 가득 채우지 않습니다.

그다음에는 반드시 복구를 시도해 보십시오. 한 번도 복구해 보지 않은 백업은 추측에 불과합니다. 어젯밤 생성된 아카이브를 별도의 디렉터리에 추출하고, 테스트 서버를 해당 경로로 지정하여 월드가 정상적으로 로드되는지, 건축물들이 그대로 남아 있는지 확인하십시오.

결정하기 전에 먼저 확인하십시오

1년 단위보다는 1개월 단위로 구매하여 실제 플레이어들과 함께 하룻밤 동안 테스트를 진행하십시오. 단일 스레드 sysbench 수치를 실행한 다음, 모든 플레이어가 서버를 향해 mtr을 실행하도록 하십시오. 전체 VPS 벤치마크 절차에서는 해당 도구들을 사용하는 방법을 단계별로 안내하며 잘못된 결과가 어떤 것인지 보여줍니다. 또한 VPS의 실제 월간 비용을 확인하면 요금제 페이지에 가장 크게 적힌 사양이 아니라, 실제로 서버 성능을 제한하는 자원에 대해 비용을 지불하고 있는지 검토할 수 있습니다.

이 글에서 다루지 않은 내용은 다음 두 게시물에서 이어집니다. VPS에서 Minecraft 서버 구축하기는 위에서 설명한 모든 과정을 가장 많은 사용자가 시작하는 게임을 예로 들어 단계별로 설명합니다. VPS로 운영 가능한 더 넓은 범위의 서비스는 게임을 즐기지 않는 시간에 서버를 유용하게 활용하고 싶다면 읽어볼 가치가 있습니다.

FAQ

게임용 PC를 구입하는 대신 VPS에서 게임을 실행할 수 있습니까?

아니요. 일반적인 VPS에는 GPU가 없고, 제공업체 콘솔용 가상 디스플레이 어댑터만 있습니다. 따라서 데스크톱을 설치하면 glxinfo -B에 소프트웨어 렌더러가 표시되고 llvmpipe, 3D 게임은 초당 몇 프레임으로만 실행됩니다. GPU를 연결하더라도 원격 플레이에서는 모든 프레임의 왕복 과정에 비디오 인코딩과 디코딩이 추가됩니다. RDP와 VNC는 애초에 이러한 용도로 설계되지 않았습니다. VPS는 그룹 구성원이 연결하는 전용 서버를 호스팅하는 용도입니다. 게임을 직접 플레이하려는 경우에는 GPU 시간을 임대하거나 클라우드 게임 서비스를 사용합니다.

게임 서버에 CPU 코어가 몇 개 필요합니까?

대부분의 게임에서는 느린 코어 8개보다 빠른 코어 2개가 낫습니다. 월드 시뮬레이션이 하나의 주 스레드에서 실행되므로 추가 코어가 해당 스레드의 50 ms 기한 준수에 도움을 주지 못하기 때문입니다. sysbench cpu --cpu-max-prime=20000 --threads=1 run을 사용해 후보 요금제를 비교하고 초당 이벤트 수를 확인합니다. 같은 서버에서 두 번째 서버나 데이터베이스도 실행한다면 추가 코어에 비용을 지불할 가치가 있습니다. 이러한 작업을 별도로 실행해 tick 스레드의 시간을 빼앗지 않을 수 있기 때문입니다.

Minecraft 서버에 RAM이 얼마나 필요합니까?

플레이어가 약 10명인 vanilla 월드에는 힙을 약 2 GB 할당하고, 같은 플레이어 수의 대규모 modpack에는 8 GB를 할당합니다. -Xms와 -Xmx을 같은 값으로 설정하고, 운영 체제가 사용할 수 있도록 시스템 메모리 1 GB에서 2 GB를 남겨 둡니다. JVM은 힙 외부에서도 메모리를 사용하고 커널에는 page cache가 필요하기 때문입니다. 서버의 메모리보다 큰 힙을 설정하면 커널이 프로세스를 종료합니다. dmesg에는 Java 오류가 아니라 out of memory 행으로 표시됩니다.

서버에 CPU와 RAM 여유가 있는데 플레이어가 지연을 겪는 이유는 무엇입니까?

이 설명에 해당하는 원인은 2가지입니다. 서버 로그에서 Can't keep up! Is the server overloaded?를 확인합니다. 이는 다른 코어가 유휴 상태인 동안 단일 주 스레드가 50 ms tick 예산을 초과했다는 뜻입니다. Paper에서는 bukkit.yml의 warn-on-overload: false로 해당 경고를 끌 수 있습니다. 따라서 경고가 표시되지 않는다는 사실을 신뢰하기 전에 아직 활성화되어 있는지 확인합니다. 경고가 활성화되어 있는데도 표시되지 않는다면 네트워크 경로를 확인합니다. 각 플레이어에게 서버 주소를 대상으로 mtr -rwzc 100 203.0.113.10을 실행하게 하고 마지막 행을 확인합니다. 또한 vmstat 1의 st 열을 확인합니다. 몇 퍼센트를 넘는 steal time은 호스트가 과다 판매되었다는 뜻이므로, 유휴 상태로 보이는 CPU를 실제로 사용할 수 없다는 의미입니다.

게임 서버에 어떤 포트를 열어야 합니까?

게임 자체의 포트와 SSH만 열면 됩니다. Minecraft Java는 TCP 25565, Minecraft Bedrock은 UDP 19132, Valheim은 UDP 2456 및 2457, Palworld는 UDP 8211을 사용합니다. ufw enable을 실행하기 전에 SSH 규칙을 추가해야 합니다. 그렇지 않으면 서버에 접근할 수 없게 됩니다. 많은 제공업체가 control panel에서 별도의 방화벽도 운영한다는 점을 기억해야 합니다. 포트는 두 방화벽 모두에서 열어야 합니다. RCON 포트 25575를 인터넷에 절대 노출하지 않습니다. 비밀번호 하나가 평문으로 전송되기 때문입니다.