홈서버 게임 서버 원격 관리: 모니터링 시스템 구축

홈서버에서 Minecraft Bedrock 서버를 운영하면서 가장 큰 과제 중 하나는 원격 관리와 모니터링이었습니다. 특히 물리적으로 서버에 접근할 수 없는 환경에서 발생하는 문제들과 이를 해결하기 위한 자동화 시스템 구축 과정을 정리했습니다.

서버 운영 환경

• Ubuntu 22.04 LTS 기반 홈서버
• Minecraft Bedrock Dedicated Server

 

프로세스 관리 솔루션 선택

서버 프로세스 관리를 위해 여러 옵션을 검토했습니다.

• systemd 서비스: 자동 재시작, 로그 관리 등 장점이 있지만, Bedrock 서버의 특성(관리 프로토콜 부재)상 실시간 콘솔 접근이 필수적이어서 부적합했습니다. RCON 프로토콜이 없는 상황에서 서버 명령어 실행, 플레이어 관리 등은 모두 콘솔을 통해서만 가능하기 때문입니다.
• 컨테이너화 (Docker): 당시에는 Docker에 대한 경험이 부족했고, 단순히 게임 서버 하나만 돌리는 상황에서 컨테이너화의 필요성을 느끼지 못했습니다. 복잡성을 추가할 이유가 명확하지 않았죠.
• Terminal Multiplexer: 세션 관리와 콘솔 접근을 모두 만족하는 솔루션으로 판단했습니다. 초기에는 레퍼런스를 따라 GNU Screen을 사용했고, 이후 더 현대적인 tmux를 도입해봤지만, 단순한 게임 서버 운영에는 Screen의 직관적인 사용법이 더 적합하다고 판단해 다시 돌아왔습니다.

screen -S MC ./bedrock_server
# Ctrl+A, D로 detach하여 백그라운드 실행

# 이후 ssh로 접속하여 아래 명령어로 콘솔 접근
screen -x MC

결과적으로 콘솔 접근 용이성과 운영 단순성 사이의 균형점으로 Screen을 선택하게 되었습니다.
 

기술적 제약사항과 운영 이슈

Bedrock 서버의 관리 인터페이스 부족

Minecraft Bedrock Dedicated Server는 Java Edition과 달리 RCON 프로토콜을 지원하지 않습니다. 이로 인해 원격 관리에 상당한 제약이 있습니다. 명령어 실행은 ssh를 비롯한 서버 자체에 무조건 접근해야만 가능했고 플레이어 관리도, 서버 상태 확인도 마찬가지입니다.

운영상 발생하는 주요 작업들

정기 재시작
메모리 누수로 인한 성능 저하 문제로 주기적인 재시작이 필수적입니다. 플레이어 수가 증가하거나 장시간 운영 시 명확한 성능 차이가 발생했습니다.
 
서버 업데이트
Bedrock 서버 업데이트는 완전한 수동 프로세스입니다:

1. 서버 프로세스 중지
2. 새 바이너리 다운로드 및 교체
3. 월드 데이터 무결성 확인
4. 재시작 

모든 단계에서 SSH 접근이 필요하며, 실수 시 데이터 유실이 있을 수 있습니다.
 
백업 관리
초기에는 수동으로 백업을 생성했지만, 이후 간단한 스크립트를 작성해 자동화했습니다.

DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR="~/minecraft/backups"
WORLD_DIR="~/minecraft/worlds"

mkdir -p $BACKUP_DIR
tar -czf "$BACKUP_DIR/backup_$DATE.tar.gz" -C "$WORLD_DIR" .

또한 cron을 통해 매일 자동 백업이 실행되도록 구성했습니다.

# 매일 새벽 3시에 백업 실행
0 3 * * * ~/minecraft/scripts/backup.sh

 

원격 접근의 한계: IP 변경으로 인한 서비스 중단

홈서버 환경의 네트워크 특성

일반 가정용 인터넷 환경에서는 ISP가 동적 IP(Dynamic IP)를 할당하는 것이 일반적입니다. 고정 IP 서비스와 달리 주기적으로 또는 특정 조건에서 IP 주소가 변경됩니다:

• DHCP 갱신: 일정 주기마다 자동으로 IP 재할당
• 모뎀/라우터 재부팅: 네트워크 장비 재시작 시 새로운 IP 할당 가능
• ISP 정책: 트래픽 관리나 유지보수 목적의 강제 IP 변경

홈서버로 외부 서비스를 제공하는 환경에서는 이러한 IP 변경이 직접적인 서비스 중단으로 이어집니다.  
문제는 군 복무 중 발생했습니다. 서버를 이용하는 멤버들에게 갑자기 오늘부터 접속이 불가능하다는 연락을 받았습니다. 당연히 그저 게임 서버 구동기가 다운된 줄 알고 ssh 접속을 시도하였으나, 전혀 접속이 불가능했습니다. 그제야 홈 서버의 공인 IP가 변경되었음을 추정할 수 있었습니다. 서버 자체는 정상 작동하고 있지만, 새로운 IP 주소를 아무도 모르니 플레이어들도 저도 모두 접속할 수 없는 상황이 된 거였죠. 

따라서 게임 클라이언트는 물론 관리를 위한 ssh 접속 등 모든 접속이 불가능한 상황까지 되었습니다.

그 때 생각할 수 있는 해결책으로는 DDNS 서비스 활용, 물리적 접근을 통한 서버 체크가 있었지만, 이미 IP가 바뀐 뒤에는 DDNS 세팅 자체가 불가능했고 군 복무 중인 특성상 물리적 접근 자체가 불가능했습니다. 

결과적으로 물리적 접근이 가능할 때까지 서비스 중단이 불가피했습니다.

 

모니터링 시스템 구축 결정

IP 변경 사건 이후, 동일한 상황의 재발을 방지하기 위한 여러 방안을 검토했습니다.

먼저 고정 IP 서비스의 경우 가장 근본적인 해결책이지만, 홈서버 운영에 비해 과도한 월 비용 발생. 비용 대비 효과가 떨어진다고 판단했습니다. DDNS는 기술적으로는 적합한 솔루션이지만, 유료 서비스가 많았고 무료 서비스의 경우 안정성에 대한 우려가 있었습니다.

따라서 서버가 직접 상태 정보를 외부로 전송하는 방식으로, 비용이 거의 들지 않으면서도 확장 가능성이 높은 방법을 도입하기로 결정했습니다.

능동적 모니터링 시스템을 선택한 핵심 이유는 IP 변경을 작업 가능한 시간대에 파악하여 가능한 가장 빠른 대응이 가능했습니다. 또한 비용 효율성도 큰 영향을 미쳤습니다. 추가 비용 없이 기존 인프라를 활용하여 구축할 수 있다는 점이 가장 큰 메리트였습니다. 추후 확장 시에도 IP 모니터링 외에도 다양한 서버 상태를 감시할 수 있다는 점도 있습니다.

특히 확장성 측면에서 중요한 고려사항이 있었습니다. 과거 백업 파일이 누적되면서 디스크 용량이 가득 차서 서버가 중단된 사건이 있었는데, 이런 문제들도 함께 감지할 수 있는 통합 모니터링 시스템이 필요했습니다.

 

이를 바탕으로 다음과 같은 시스템 요구사항을 도출했습니다.

1. 능동적 상태 보고: 서버가 자발적으로 상태 정보를 전송
2. 접근성: 제한된 환경에서도 정보 수신 가능
3. 신뢰성: 네트워크 변경 상황에도 동작
4. 확장성: 추가 모니터링 항목 수용 가능

Telegram Bot API 선택 근거

• python-telegram-bot 라이브러리를 활용한 간단한 구현
• 다양한 플랫폼에서 접근 가능 (모바일, 웹, 데스크톱)
• 외부 의존성 최소화
• 제한적 네트워크 환경에서도 사용 가능

import telegram
import asyncio
import requests

async def send_ip():
    bot = telegram.Bot(token="YOUR_BOT_TOKEN")
    ip = requests.get("https://ifconfig.me/ip").text.strip()
    await bot.send_message(chat_id="YOUR_CHAT_ID", text=ip)

asyncio.run(send_ip())

# 매일 17:00에 상태 보고
0 17 * * * /usr/bin/python3 ~/monitor.py

 

 

모니터링 시스템 확장

기본적인 IP 모니터링이 안정화된 후, 디스크 사용량 모니터링을 추가했습니다. 위에서 언급했던 대로 백업 파일이 과도하게 누적되어 서버가 다운된 적이 있었습니다. 따라서 이를 예방하고 시스템 리소스 현황을 먼저 파악할 필요가 있어 디스크 용량도 모니터링에 추가했습니다.

import shutil

def get_disk_usage(self, path="/"):
    try:
        total, used, free = shutil.disk_usage(path)
        return {
            'total_gb': round(total / (1024**3), 2),
            'used_gb': round(used / (1024**3), 2), 
            'free_gb': round(free / (1024**3), 2),
            'usage_percent': round((used / total) * 100, 1)
        }
    except Exception as e:
        return f"디스크 정보 확인 실패: {str(e)}"

이 모니터링 시스템 구축을 통해 디스크가 완전히 차기 전에 선제적 대응이 가능했고, 추가 모니터링 통합도 쉽게 가능함을 알 수 있었습니다.

향후 개선 계획

현재의 단순한 tar 기반 백업을 Restic 또는 Borg Backup 같은 오픈소스 솔루션으로 교체할 계획입니다. 이를 통해 Retention policy를 통한 오래된 백업 자동 삭제, 로컬 외에 클라우드 백엔드(AWS S3, Cloudflare R2 등)에 백업 등을 시도해 볼 계획입니다.

또한 현재의 정기적 상태 보고를 넘어서, 문제 상황을 즉시 감지하는 임계치 기반 알림 시스템으로 발전시킬 예정입니다. 

• 디스크 사용량 경고: 90% 초과 시 즉시 알림
• 서버 다운 감지: 일정 시간 응답 없을 시 자동 알림
• IP 변경 즉시 감지: 매일 정기 보고가 아닌 변경 시점 실시간 알림

또한 IP를 모니터링 후 직접 받아 A레코드를 직접 입력해주기보다 Cloudflare API를 이용한 업데이트를 도입하여 DDNS처럼 관리자의 개입 없이 업데이트할 수 있도록 개선할 계획입니다.

자동 복구 시스템

장기적으로는 컨테이너화를 통한 자동 복구 메커니즘 도입을 고려하고 있습니다.

• Docker Restart Policy: 프로세스 이상 종료 시 자동 재시작
• Kubernetes Self-Healing: 컨테이너 레벨에서의 자동 복구 및 스케일링
• Watchdog 서비스: 서버 상태 모니터링 및 자동 복구 액션