내 컴퓨터는 끄고, Minecraft 서버는 GCP로

Windows PC에서 시작한 Minecraft 월드가 친구들과 함께 클라우드 서버로 이어지는 장면

처음에는 약속한 시간에 내 Windows PC로 Minecraft 서버를 열었다. 친구 몇 명이 함께 접속하고 모두 나가면 서버도 껐다. 같은 시간에 모여 잠깐 놀 때는 이 방법으로 충분했다. 문제가 생기면 바로 화면을 보고 다시 켰고, 설정을 바꾸고 싶으면 같은 컴퓨터에서 파일을 열었다.

월드에서 보낸 시간이 늘자 친구들이 들어오는 시간도 흩어졌다. 어제 짓다 만 건물을 다음 날 이어 만들고, 먼저 들어온 친구가 남긴 흔적을 다른 친구가 나중에 발견했다. 늦은 밤 혼자 건축하고 싶은 친구도 생겼다.

내가 PC로 다른 작업을 하거나 전원을 끄면 친구들의 월드도 닫혔다. 서버를 열어 달라는 연락을 받고 컴퓨터를 켜는 일도 생겼다. 내가 자리에 없어도 어제 하던 월드에 들어갈 수 있어야 했다. 서버를 내 생활 시간에서 떼어 놓기로 했다.

하루마다 멈추는 VM을 고른 이유

Minecraft 전용 호스팅과 별도 장비, Oracle Cloud 무료 플랜도 살펴봤다. 당시에는 몇 명이 얼마나 자주 접속할지, 플러그인을 얼마나 쓰게 될지, 월드가 얼마나 커질지 알지 못했다. 정해진 사양을 고르기보다 직접 돌려 보면서 CPU와 메모리를 바꿔 보고 싶었다. 당시 90일 체험 크레딧을 제공하던 GCP Compute Engine을 선택했다.

필요한 사양을 모르는 상태에서 Minecraft 서버를 실행할 클라우드 VM을 고르는 장면

크레딧을 오래 쓰려고 구형 선점형 VM을 골랐다. 일반 VM보다 저렴한 대신 GCP가 자원을 회수할 수 있었고, 실행한 지 24시간이 지나면 반드시 멈췄다. 언제든 접속할 서버를 만들면서 하루를 넘겨 켜 둘 수 없는 컴퓨터를 선택한 셈이었다.

VM을 고른 순간부터 매일 멈춘 뒤 다시 켜는 방법도 함께 만들어야 했다. Terraform으로 VM과 네트워크 구성을 남겼고, 종료 이벤트가 발생하면 VM 밖의 함수가 시작을 요청하도록 만들었다. 부팅 뒤 Minecraft를 실행하는 일은 VM 안의 systemd가 맡았다. 꺼진 VM 안의 코드는 아무것도 할 수 없어서 전원을 켜는 일과 게임 서버를 띄우는 일을 나눴다.

대부분의 날에는 함수가 VM을 다시 켰고 systemd가 Minecraft를 올렸다. 잠시 뒤 친구들이 같은 월드에 접속했다. 적어도 매일 관리 화면에 들어가 시작 버튼을 누르는 일은 없어졌다.

GCP 선점형 VM 자동 복구 구조

월드는 옮겼는데 열리지 않는 서버

Windows의 월드와 설정 파일을 VM으로 복사한 날, 건물과 아이템, 친구들의 진행 상황은 모두 옮겨져 있었다. Java도 실행됐지만 Minecraft는 접속을 받지 못했다.

원인은 이전 컴퓨터에서 가져온 server-ip 값이었다. 친구들이 접속할 때 쓰는 외부 주소와 Minecraft가 VM 안에서 기다릴 주소를 같은 것으로 생각했다. 새 VM이 소유하지 않은 주소가 설정에 남아 있어 Minecraft가 접속을 기다릴 포트부터 열리지 않았다. 값을 비우고 프로세스, 로컬 포트, 외부 IP와 방화벽을 차례로 살핀 뒤에야 친구들이 다시 접속했다.

월드는 건너편에 온전히 옮겨졌지만 잘못 연결된 주소 때문에 진입로가 막힌 장면

월드 파일은 그대로 가져왔지만 운영체제의 경로와 네트워크 설정은 새 VM에 맞춰 다시 정해야 했다. server-ip 한 줄도 그중 하나였다.

서버 이전 뒤 외부 접속 경로

다시 접속한 월드에서 사라진 블록

재시작은 늘 성공하지 않았다. 가끔은 서버가 열리지 않는다는 친구의 연락을 받고 나서야 실패를 알았다. 그때는 GCP 관리 화면에서 VM 시작 버튼을 직접 눌렀다. Minecraft는 부팅 과정에서 따라 올라왔기 때문에 서비스를 따로 실행할 필요는 없었다.

더 곤란한 날도 있었다. 서버는 다시 열렸고 친구들도 접속했지만, 조금 전까지 놓은 블록이나 모은 아이템이 이전 상태로 돌아가 있었다.

자동 재시작 뒤 서버에는 다시 접속했지만 최근에 만든 블록이 사라진 장면

월드 전체가 깨지거나 사라지지는 않았다. 마지막 저장 이후의 일부 플레이가 되돌아가는 백섭을 여러 번 겪었다. 당시에는 복구 성공률과 실패 시각, 저장 시점을 함께 기록하지 않았다. 남은 자료만으로 자동 재시작 실패와 백섭의 원인을 하나로 묶을 수는 없다.

VM 화면에 RUNNING이 떠도 Minecraft가 접속을 받고 최근 플레이를 그대로 불러와야 친구들이 게임을 이어 갈 수 있었다. VM을 다시 켜는 일은 자동화했지만, 사라진 블록과 아이템까지 되돌리지는 못했다.

VM 재시작과 Minecraft readiness 검증

백섭을 겪고 만든 하루 한 번의 백업

최근 플레이가 사라지는 일을 겪은 뒤 하루에 한 번 월드와 설정을 백업했다. 접속자가 없을 때 저장 명령을 보내고 파일을 압축했다. 날짜와 시각을 붙인 결과물을 VM 밖의 Cloud Storage에 올리고 Discord로 성공 알림을 보냈다.

이 백업은 VM이나 디스크를 잃었을 때 월드 전체를 되찾기 위한 것이었다. 하지만 내가 실제로 겪은 문제는 VM이 갑자기 멈추면서 마지막 저장 이후의 플레이가 사라지는 일이었다. 하루에 한 번 남기는 백업으로는 방금 놓은 블록을 되살릴 수 없었다. 오히려 오래된 백업으로 돌아가면 그 뒤에 이어진 플레이까지 포기해야 했다.

백업 상자는 계속 쌓이지만 복원 서버로 향하는 마지막 선로가 끊긴 장면

백섭을 막으려면 VM이 멈추기 전에 최근 플레이를 디스크에 남겨야 했다. 백업은 그 저장본까지 잃었을 때 돌아갈 곳을 하나 더 만드는 일이었다. 당시에는 둘을 구분하지 않은 채 백업 파일이 Cloud Storage에 올라갔다는 Discord 알림을 보고 안심했다.

그래도 월드의 유일한 복사본이 매일 멈추는 VM 안에만 있던 때보다는 나았다. 친구들이 쌓아 온 시간을 전부 잃을 가능성은 줄였지만, 그날 사라진 블록 몇 개까지 지켜 주는 장치는 아니었다.

Minecraft 월드 백업과 격리 복원

관리 화면에서 Discord로

개인 PC에서 서버를 열 때는 문제가 생기면 바로 화면을 볼 수 있었다. GCP로 옮긴 뒤에는 VM이나 로그를 살필 때마다 관리 화면이나 SSH를 열어야 했다. 서버가 닫힌 사실을 친구의 연락으로 먼저 알게 되는 날도 있었다.

친구들이 이미 모여 있던 Discord로 서버 시작과 종료, 백업 결과를 보내기 시작했다. 나중에는 서버 상태와 접속자를 조회하고 whitelist 같은 제한된 관리 작업도 Discord 채널에서 처리했다.

멀리 있는 서버에서 온 Discord 알림을 마을 맞은편 옥상에서 확인하는 장면

관리 화면을 여는 횟수는 줄었지만 내가 봇에 넘긴 권한은 커졌다. RCON은 Minecraft 콘솔에 가까운 권한을 가진다. Discord 채널에 들어와 있다는 이유만으로 사용자가 보낸 문자열을 그대로 전달할 수는 없었다. 조회와 변경 명령을 나누고 봇이 실행할 작업을 제한했다.

Discord 봇은 Minecraft와 같은 VM에서 실행됐다. VM이 꺼지면 봇도 함께 멈췄다. 실행 중인 서버를 보고 조작할 수는 있었지만, 꺼진 VM은 계속 바깥의 함수가 다시 켰다.

Discord·RCON 서버 운영 경계

156만 청크와 15시간 53분

친구들이 처음 가는 지역을 탐험할 때 지형 생성 때문에 끊기는 일을 줄이려고 Chunky로 반경 10,000블록을 미리 생성했다. 왜 그 반경을 골랐는지는 기록에 남아 있지 않다.

청크 사전 생성으로 비어 있던 지형과 완성된 숲의 경계를 확인하는 장면

완료 로그에는 1,565,001개 청크와 15시간 53분 18초가 기록됐다. 같은 구간에는 Can't keep up 경고 649번과 플레이어 접속 3번도 있었다. 경고를 모두 Chunky 탓으로 돌릴 근거는 없다. 다만 아무도 없는 시간에 끝내려던 작업 중 플레이어가 세 차례 접속했다.

작업은 100% 완료됐다. 하지만 친구들이 이후 미리 생성한 지역을 탐험할 때 얼마나 덜 끊겼는지, 월드와 백업 파일이 얼마나 커졌는지는 측정하지 않았다. 완료 로그와 큰 숫자는 남겼지만 작업 전후의 플레이 경험은 기록하지 못했다.

청크 사전 생성과 VM 용량 산정

VM보다 먼저 정할 것

선점형 VM 덕분에 체험 크레딧 안에서 여러 사양을 시험하고 GCP의 네트워크, VM, 권한과 자동화를 직접 다뤄 봤다. 서버 운영 자체를 배우고 싶었던 당시에는 좋은 실험장이었다.

서버 크기를 고르기 전에 중단 시간과 월드 보존, 비용과 관리 시간을 탁자에 펼쳐 둔 장면

Minecraft를 편하게 하는 데만 관심이 있었다면 전용 호스팅이나 별도 장비를 골랐을 수도 있다. 어느 쪽을 고르느냐에 따라 내가 직접 맡을 전원, 네트워크, 백업과 자격정보가 달라진다. 당시 청구 자료와 복구 성공률을 남기지 않아 GCP가 최종적으로 더 저렴했다고 계산할 근거도 없다.

다시 시작한다면 VM 크기보다 먼저 서버가 닫혀도 괜찮은 시간, 잃어도 감당할 수 있는 최근 플레이의 범위, 장애를 확인하고 다시 열 사람, 한 달에 쓸 비용과 관리 시간을 정할 것이다. 그 조건을 만족하는 데 필요한 자동화만 붙일 것이다.

처음에는 내 컴퓨터가 켜져 있으면 서버도 열려 있다고 생각했다. 월드가 친구들의 공용 공간이 된 뒤에는 서버가 켜졌는지뿐 아니라 친구들이 그 안에 쌓은 시간이 남아 있는지도 살펴야 했다.

GCP Minecraft 서버 운영 구조