월 요금 지불을 멈추기 위해 AWS Fargate에 온‑디맨드 마인크래프트 호스트를 만들었습니다

Source: Dev.to

위 링크에 포함된 글의 본문을 제공해 주시면, 해당 내용을 한국어로 번역해 드리겠습니다. (코드 블록이나 URL은 그대로 유지됩니다.)

소개

대부분의 마인크래프트 서버 호스팅 업체는 근본적인 결함이 있습니다: 서버가 비어 있는 90 % 시간에 대해 월 구독료를 청구합니다.

나는 아이들과 내가 주말마다 몇 시간만 플레이하는 서버에 €20 / 월을 지불하고 있다는 것을 깨달았습니다. 이것이 ERGamesPRO의 시작이었습니다 – AWS 위에 구축된 주문형 마인크래프트 호스팅 플랫폼으로 목표는 간단합니다:

아무도 플레이하지 않으면, 나는 비용을 지불하지 않아야 합니다.
(“서버리스”란 항상 켜져 있는 컴퓨팅이 없다는 의미입니다: 패치할 EC2 인스턴스가 없으며, 서버가 꺼져 있을 때 CPU/RAM 요금이 중단됩니다. 스토리지/미션‑컨트롤 비용은 남지만, 24/7 컴퓨팅에 비해 작습니다.)

아키텍처: 왜 Fargate?

저는 AWS Fargate (ECS) 를 선택하여 인스턴스를 관리하지 않고 scale‑to‑zero 동작을 구현했습니다.

• Start – 대시보드에서 “Start” 를 클릭하면 해당 서버 전용의 새로운 Fargate 작업이 프로비저닝됩니다.
• Stop – “Stop” 을 클릭하면 작업이 종료되고 컴퓨팅 비용이 0으로 떨어집니다.

고수준 스택

안정적인 접속 주소 (로드 밸런서 없음)

저는 NLB/ALB 또는 Cloud Map을 사용하지 않습니다. ECS 작업은 public subnets에서 실행되며 퍼블릭 IP를 받습니다.

서버가 시작될 때, 제어 플레인은 도메인 ergamespro.click 아래에 있는 Route 53 레코드를 자동으로 업데이트하여 커스텀 호스트명(예: myserver.ergamespro.click)을 해당 작업의 퍼블릭 IP에 매핑합니다.

• TTL: 60 초
• Connection method: 플레이어는 항상 호스트명을 통해 연결하며, 재시작 시 기본 IP가 변경될 수 있습니다.

“Scale to Zero” 문제

온‑디맨드 호스트에서 가장 어려운 부분은 언제 안전하게 전원을 끌지 아는 것입니다.

저는 AWS Lambda + EventBridge를 이용해 조정 루프를 만들었습니다:

1. Watchdog Lambda가 몇 분마다 실행됩니다.
   • 각 실행 중인 서버에 TCP 기반 Minecraft Server List Ping을 보내 현재 플레이어 수를 읽어옵니다.
2. 플레이어 수 > 0 → 서버를 계속 실행합니다.
3. 플레이어 수가 = 0인 상태가 10 분 지속 → 종료 이벤트를 트리거합니다.

Ping이 실패하거나 타임아웃될 경우, watchdog은 열린 상태로 실패하고 재시도하여 잘못된 종료를 방지합니다. 종료 이벤트가 발생하면 Fargate 작업이 중지되고 컴퓨팅 요금이 즉시 종료됩니다. 휴일 세션처럼 사용량이 적은 경우, 24시간 운영 대비 ~70–80 % 정도 비용을 절감할 수 있습니다.

Source: …

진행 중 겪은 도전 과제

1️⃣ 500‑리소스 제한 (CDK)

• 문제: AWS CDK (Python)를 사용할 때 CloudFormation의 스택당 500개 리소스라는 하드 제한에 걸렸습니다.
• 해결책: 모놀리스를 7개의 독립 스택(Foundation, Data, Compute 등)으로 분할했습니다. 배포 속도가 빨라지고, 안전해지며, 이해하기도 쉬워졌습니다.

2️⃣ 시작 시간 및 골든 이미지

• 문제: Fargate는 즉시 시작되지 않습니다. 런타임에 ~1 GB 이미지를 풀링하면 콜드 스타트 지연이 크게 발생합니다.
• 해결책: 각 Minecraft 버전(Vanilla, Paper, Forge)별로 **ARM64 (Graviton)용 “골든 이미지”**를 미리 빌드하는 파이프라인을 구축했습니다.
  • Graviton은 비용이 저렴합니다.
  • 일반적인 Java 기반 Minecraft 워크로드에서는 성능이 매우 뛰어납니다.

참고: 100개 이상의 모드를 사용하는 무거운 모드 서버는 고클럭 x86이 유리할 수 있지만, Vanilla 및 가벼운 모드팩에서는 ARM이 훌륭합니다.

3️⃣ EFS를 이용한 영구 스토리지

• 문제: Fargate 작업은 일시적이며, 작업이 중지되면 컨테이너 파일 시스템이 사라집니다.
• 해결책: Amazon EFS와 전용 Access Point를 사용합니다. 각 서버는 /data에 마운트된 격리된 디렉터리를 받아, 월드, 설정, 백업이 재시작 시에도 유지됩니다.
  • EFS는 기본적으로 버스팅 처리량으로 동작하며(Elastic 또는 Provisioned 로 설정 가능).
  • 버스팅은 소규모에서는 매우 적합하고, 프로비저닝된 처리량은 비용이 크게 증가할 수 있어 기본값으로 유지합니다.

4️⃣ 일시적인 환경에서 파일 접근 (SFTP)

• 문제: VPS에서는 SSH로 접속해 모드를 업로드하지만, Fargate에서는 서버가 중지될 때 “SSH 할 대상”이 없습니다.
• 해결책: 사이드카 패턴 – 사용자가 서버를 시작하면 Minecraft 컨테이너와 함께 SFTP 사이드카를 실행합니다.

클라이언트 IP가 예측 불가능하기 때문에 SFTP는 소스‑IP 허용 목록에 포함되지 않습니다. 단시간 유효 자격 증명과 잠금‑다운 SFTP 설정을 통해 파일 관리를 편리하게 유지하면서 온‑디맨드 모델을 깨지 않도록 합니다.

5️⃣ 실시간 콘솔 스트리밍

• 문제: 웹 대시보드에 실시간 로그를 표시하고 싶었지만, Kinesis Data Streams는 초기 프로젝트에 비용이 너무 많이 들었습니다.
• 해결책: CloudWatch Logs + WebSockets
  1. Fargate가 로그를 CloudWatch Logs에 스트리밍합니다.
  2. Lambda가 새로운 로그 항목을 폴링합니다.
  3. 프론트엔드에 API Gateway WebSocket 연결을 통해 업데이트를 푸시합니다.

지연 시간은 약 1–2 초로, 큰 비용 절감 효과를 고려하면 충분히 만족스럽습니다.

오늘날의 플랫폼

결과는 프리미엄 호스트처럼 느껴지지만 클라우드‑네이티브 앱처럼 동작합니다:

• 시작 시간: 가벼운 서버는 클릭 후 ~50–90 초에 접속 가능; 무거운 모드팩은 ~3–4 분.
• 격리: 각 서버는 자체 Fargate 태스크에서 실행됩니다(소음이 나는 이웃 없음).
• 비용 모델: 서버가 실행되는 시간만큼만 비용을 지불합니다.

다음 단계는?

• 멀티‑리전 지원 – 플레이어에 가깝게 배포합니다.
• 서버당 다중 월드 – EFS에 여러 월드 디렉터리를 저장하고 사용자가 부팅할 월드를 선택하도록 합니다.

문서 끝.

ETA는 ergames.pro 에서 라이브됩니다.

아키텍처를 스트레스 테스트하고 싶은 개발자와 게이머를 위해 초대 코드를 몇 개 남겨두었습니다 — 솔직한 피드백을 환영합니다.

AWS CDK 구조, Lambda 로직, 또는 Fargate 튜닝에 대한 자세한 내용이 필요하면 댓글로 질문해주세요.