Amazon GameLift Servers 스팟 인스턴스 잘 활용하기

Amazon GameLift Servers는 세션형 게임 전용 게임 서버 호스팅 서비스로, 멀티플레이어 게임 서버의 배포, 운영, 확장 문제를 손쉽게 해결해줍니다. GameLift Servers는 게임 세션 관리, 플레이어 매칭, 자동 확장 등을 기본적으로 지원하며, 특히 전통적인 온프레미스나 자체 EC2 구축 대비 운영 효율성과 안정성이 크게 향상됩니다. 이로 인해 개발자는 서버 인프라 관리에 신경 쓰지 않고, 게임 로직 개발에 집중할 수 있습니다.

그림 1: Amazon GameLift Servers 개요

이 서비스는 게임서버 호스팅에 온디맨드 인스턴스와 함께 스팟 인스턴스도 활용 가능합니다. Amazon GameLift Servers의 스팟 인스턴스는 AWS의 유휴 EC2 인프라를 할인된 가격에 제공하는 방식으로 온디맨드 요금 대비 50%~85% 절감된 요금으로, 온디맨드 인스턴스와 동일한 고성능을 유지하면서도 게임 서버 운영 비용을 대폭 줄일 수 있는 장점이 있습니다. 개발자는 Amazon GameLift Servers의 스팟 인스턴스를 이용해 게임 세션 호스팅 비용을 크게 줄일 수 있습니다. 다만 스팟 인스턴스는 AWS 리소스 상황에 따라 회수될 수 있는데, 만약 스팟 인스턴스 중단 시 플레이 중인 세션이 존재한다면 게임 프로세스의 중단으로 사용자 경험에 악영향을 미칠 수 있습니다. 그러나 Amazon GameLift Servers는 독점 알고리즘을 사용해 스팟 인스턴스의 중단률을 최소화하여, 플레이어의 경험을 해치지 않으면서 비용 최적화를 도와줍니다.

이 글에서는 스팟 인스턴스를 활용할 때 사용자들이 일반적으로 겪는 다음 두 가지 사례를 통해, 스팟 인스턴스 관련 이슈가 발생했을 때 개발자들이 점검해야 할 사항들을 소개하고, 개발자들이 스팟 인스턴스를 효과적으로 활용할 수 있는 방법을 제시하겠습니다.

스팟 인스턴스의 중단율이 높은 경우
스팟 활용률이 낮은 경우

스팟 인스턴스의 중단율이 높은 경우

스팟 인스턴스는 AWS가 보유한 사용되지 않는 EC2 용량을 활용합니다. 그렇기 때문에 AWS의 잔여 용량이 부족할 경우 스팟 인스턴스는 회수될 수 있는데, 스팟 인스턴스가 회수되는 주요 사항은 다음과 같습니다.

회수(중단) 상황	설명
용량 부족	온디맨드 인스턴스나 예약 인스턴스에 자원을 우선 할당해야 할 경우, 기존에 할당된 스팟 인스턴스가 중단될 수 있음
가격 상승	수요 증가로 인한 스팟 인스턴스 가격 상승
제약 조건 미 충족	스팟 인스턴스 요청 시 특정 가용 영역이나 시작 그룹 등 추가 조건을 지정한 경우, 해당 조건을 더 이상 충족할 수 없게 되면 인스턴스가 중단될 수 있음
내부 인프라 이슈	유지 보수, 하드웨어 장애 등

표 1: 스팟 인스턴스가 회수되는 주요 사항

용량 부족: AWS의 온디맨드 수요가 증가할 때

스팟 인스턴스는 AWS에서 남는 용량을 저렴하게 임시로 제공하는 방식입니다. 그런데 동일한 인스턴스 타입을 온디맨드 고객이 요청하면, AWS는 그 수요를 우선시하고 스팟 인스턴스를 회수할 수 있습니다.

예시: 누군가 c5.large 인스턴스를 온디맨드로 대량 요청 → 해당 타입을 스팟으로 사용 중이던 GameLift Servers 의 인스턴스가 회수됨

스팟 가격이 변경되거나 수급이 부족해질 때

스팟 인스턴스는 가격 기반 우선순위 시스템에 따라 공급됩니다. 특정 인스턴스 타입이나 리전에서 스팟 가격이 상승하거나 여유 용량이 부족해지면 회수가 발생할 수 있습니다.

특정 인스턴스 타입에 요청이 집중될 때

많은 유저가 인기 있는 인스턴스(c5, m5 등)만 사용하면 해당 타입의 스팟 인스턴스는 공급 부족 상태가 되고, 이 경우 기존 사용자는 회수될 수 있습니다.

스팟 인스턴스 중단 확인 방법

Amazon CloudWatch를 사용하여 모니터링

개발자는 Amazon CloudWatch를 사용하여 Amazon GameLift Servers 서비스를 활용해 호스팅하는 게임서버가 어떻게 실행되고 있는지 모니터링할 수 있습니다. AWS/GameLift 네임스페이스에는 플릿 또는 플릿 그룹 활동과 관련된 지표가 포함되어 있으며, Amazon GameLift Servers 서비스는 매분마다 CloudWatch로 지표를 전송합니다. 전송된 지표는 15개월간 보관되며, 개발자는 InstanceInterruptions이나 GameSessionInterruptions 지표를 통해 단위 시간당 중단된 스팟 인스턴스의 수와 게임 세션의 수를 확인해 중단 비율을 계산할 수 있습니다. 그중에도 게임 세션의 중단을 위주로 확인하면 GameLift Servers가 얼마나 인스턴스의 중단을 회피하는지 확인할 수 있을 것입니다.

스팟 인스턴스 이벤트 확인

Amazon GameLift Servers는 스팟 인스턴스의 중단이 발생할 경우, 스팟 인스턴스 이벤트를 발생합니다. 개발자는 GameLift Servers의 이벤트 로그로 특정 스팟 플릿의 중단 이벤트를 확인할 수 있는데 이를 디버깅 용도 등으로 활용이 가능합니다.

스팟 인스턴스 중단시 발생하는 이벤트:

INSTANCE_INTERRUPTED: EC2에 의해 2분 알림과 함께 스팟 인스턴스가 중단되었습니다.

INSTANCE_INTERRUPTED 이벤트는 AWS에서 스팟 인스턴스를 회수할 때 발생하며, 이벤트 확인은 관리 콘솔과 CLI 등으로 가능합니다.

GameLift Servers 콘솔로 조회

GameLift Servers 콘솔의 Fleets를 선택 후 Events 탭을 선택해 이벤트를 확인합니다.

그림 2: GameLift Servers 콘솔내 이벤트 발생 예시

이벤트에 포함되는 내용은 다음과 같습니다.

EventId: 플릿 이벤트의 고유 식별자
ResourceId: 플릿 ID와 같은 이벤트 리소스의 고유 식별자
EventCode: 로깅된 이벤트 유형
Message: 이벤트와 관련된 추가 정보
EventTime: 이 이벤트가 언제 발생했는지를 나타내는 타임 스탬프.

AWS CLI 명령으로 조회

다음으로 AWS CLI 명령으로 플릿의 이벤트 로그 조회도 가능하며 명령은 다음과 같은 구조로 이루어집니다.

aws gamelift describe-fleet-events \
    --fleet-id <FLEET_ID> \
    --region <YOUR_REGION> \
    --query "Events[?EventCode=='INSTANCE_INTERRUPTED']"

> aws gamelift describe-fleet-events \
    --fleet-id fleet-29756331-d0d0-47bd-bde2-c14c1d3d214e \
    --region ap-northeast-1 \
    --query "Events[?EventCode=='INSTANCE_INTERRUPTED']"
[
    {
        "EventId": "ebe9d741-18cb-430c-8ed7-d6ccd5bbedc7",
        "ResourceId": "fleet-29756331-d0d0-47bd-bde2-c14c1d3d214e",
        "EventCode": "INSTANCE_INTERRUPTED",
        "Message": "Instance i-0555708117d1a5ab6 interrupted at Wed Jun 11 00:46:40 UTC 2025 in location ap-northeast-1",
        "EventTime": "2025-06-11T09:46:42.100000+09:00",
        "Count": 1
    },
    {
        "EventId": "0982d1c6-a1c5-4cce-8fac-a941ac1565fc",
        "ResourceId": "fleet-29756331-d0d0-47bd-bde2-c14c1d3d214e",
        "EventCode": "INSTANCE_INTERRUPTED",
        "Message": "Instance i-0c228a3f798b419b2 interrupted at Wed Jun 11 00:32:10 UTC 2025 in location ap-northeast-1",
        "EventTime": "2025-06-11T09:32:11.906000+09:00",
        "Count": 1
    }, ...skipping...

표 2: AWS CLI 를 활용한 이벤트 로그 조회 예시

`OnProcessTerminate` 콜백 함수를 활용한 중단 대응

또한 스팟 인스턴스가 중단된 시점이 아닌, 중단 전에 사전에 인지해 게임 세션 중단에 대비하는 것이 더욱 중요합니다. GameLift Servers는 스팟 인스턴스가 중단될 때 Amazon GameLift Server SDK의 OnProcessTerminate 콜백 함수를 호출합니다. OnProcessTerminate가 호출된 후 약 2분 이내에 인스턴스가 중단되므로 개발자는 이것을 통해 중단에 대비하는 사전 조치를 취할 수 있습니다. 예를 들면 사전에 사용자에게 안내를 전달한다든지, 영향 받는 사용자에게 자동화된 보상은 제공한다든지, 세션 데이터를 저장하여 중단 후 복구하는 로직을 구현하는 것들이 가능합니다.

스팟 중단율 개선 방안

다중 플릿 전략 사용

스팟 인스턴스만으로 구성된 플릿의 경우 중단율이 높은 상황에서는 AWS가 인스턴스를 회수하면 게임 세션이 강제로 종료되어 높은 중단율로 이어질 수 있습니다. 또한, 특정 리전에 여유 스팟 용량이 없으면 인스턴스가 할당되지 않을 수 있고, 탄력적인 수요 대응을 위해 Auto scaling을 구성해 놓아도 확장이 불가능한 상황이 발생할 수 있습니다. 그래서 온디맨드 플릿과 스팟 플릿을 함께 사용하는 다중 플릿 전략을 사용해야 합니다.

Amazon GameLift Servers의 경우 온디맨드 플릿을 스팟 플릿과 함께 사용하면 스팟 인스턴스의 중단율이 높은 상황에서는 스팟 플릿은 인스턴스 배정 시 제외되고 안정적인 온디맨드 플릿에 새로운 게임을 배정하게 됩니다. Amazon GameLift Servers 대기열은 하나의 대기열에 복수의 플릿 혹은 별칭(Alias)를 대상으로 지정할 수 있습니다. 대상 대기열에 스팟 플릿과 온디맨드 플릿을 함께 지정하고, 게임 세션 배치 우선순위 지정 시 비용의 우선 순위를 높이면 스팟 인스턴스가 우선 배정되고, 만일 스팟 인스턴스의 중단율이 높다면 새로운 게임의 배정은 온디맨드 인스턴스로 자동 대체가 가능합니다.

그림3: 하나의 대기열에 두 개의 별칭(Alias) 배치 예

스팟 인스턴스 활용률이 낮은 경우

스팟 인스턴스는 AWS 내부 여유 용량을 이용하므로 고객들의 수요 변화에 따라 가용량이 달라집니다. 따라서 리전, 가용영역 및 인스턴스 유형 등에 따라 중단 빈도는 다르며 중단 빈도가 높을 경우 대체할 수 있는 온디멘드 플릿이 있는 경우 Amazon GameLift Servers의 독점 알고리즘에 따라 스팟 플릿에 배정이 안 될 수도 있습니다. 경우에 따라서는 일주일 이상의 장기간 동안 스팟 플릿이 사용되지 않는 모습을 보실 수 있습니다. 이 경우 다음과 같은 방식으로 스팟 플릿을 조정하여 스팟 활용률을 높일 수 있습니다.

스팟 인스턴스 어드바이저 활용해 적절한 인스턴스 유형 선택

AWS는 스팟 인스턴스 어드바이저를 통해 각 리전의 인스턴스 유형별로 30일간 평균 중단 빈도와 온디맨드 요금 대비 절감액을 제공합니다. 개발자는 이 정보를 활용해 중단 빈도가 적은 유형의 인스턴스를 선택해 플릿을 구성함으로써 스팟 인스턴스의 배정 가능성을 높일 수 있습니다.

중단 빈도의 확인 방법은 브라우저를 통해 EC2 스팟 인스턴스 어디바이저 페이지 접속 후 리전, OS 등을 선택하면 인스턴스 유형별 중단 빈도를 확인할 수 있습니다.

그림4: Instance Advisor 예

Amazon GameLift Servers는 스팟 인스턴스를 사용할 때 “중단 빈도”을 고려해서 플릿 운영을 조절합니다. 스팟 인스턴스 회수율이 높은 경우, GameLift Servers는 해당 인스턴스 유형을 가능한 한 피하거나 배정을 지연시킵니다. 온디맨드 플릿이 있는 경우는 온디맨드 플릿을 사용하게 되지만 온디맨드 플릿의 여유 프로세스가 부족한 경우 GameLift Servers가 새 게임 세션을 배정하지 못하는 현상이 발생할 수 있습니다.

이런 경우 개발자에게는 마치 스팟 플릿이 활용되지 않는 것처럼 보일 수 있으니, 인스턴스 어드바이저의 중단 빈도를 확인해 가능한 중단 빈도가 낮은 인스턴스 유형 선택으로 스팟 활용률을 높일 수 있습니다. 또한, 여러 유형의 스팟 인스턴스 플릿을 함께 사용한다면 특정 유형의 스팟 인스턴스의 가용량 부족 시 다른 유형의 인스턴스가 배정될 수 있어 스팟 인스턴스 활용률을 높일 수 있습니다. 추가적으로 조금 더 상세한 현황을 원하신다면 GameLift Servers에 대한 기술 서포트를 통해서 적절한 인스턴스 타입을 권장받으실 수도 있습니다.

적절한 게임 유형에 스팟 인스턴스 사용

마지막으로 게임세션의 길이가 긴 경우는 그만큼 스팟 인스턴스의 중단에 따라 게임세션이 중단될 확률이 증가하게 됩니다. 세션을 배치하는 시점에는 스팟 플릿의 중단율이 낮아서 배치되었지만 세션이 유지되는 동안에 중단율의 변동이 발생하는 경우가 발생할 수 있고, 게임 세션의 지속시간이 길수록 중단 확률에 노출될 가능성이 증가합니다.

이는 플레이어 경험에 부정적인 영향을 줄 수 있으니 게임 세션이 비교적 짧은 게임에 스팟 인스턴스를 활용하는 것을 권고하며, 게임 운영사 측에서 내부적으로 정한 중단 허용치를 정하고 그 내에 있는 게임 모드의 경우 스팟 인스턴스 사용을 권장합니다. 따라서 스팟과 온디맨드를 같이 사용하는 다중 플릿 전략을 기본적으로 사용하고, 안정성이 중요하거나 세션의 길이가 긴 경우는 예외적으로 온디맨드만을 사용하는 것도 상황에 따라 필요합니다.

마치며

이 글에서는 스팟 인스턴스를 활용해 비용을 절감하면서도 안정적으로 게임 서비스를 운영할 수 있는 몇 가지 기법들을 소개했습니다. Amazon CloudWatch 지표 등을 통해 스팟을 사용한 게임 세션들의 정확한 중단률을 확인하고 스팟의 저렴한 가격과 온디맨드의 안정성을 함께 취하는 방안과 여러 유형의 스팟을 함께 사용하는 방안의 이용이 스팟의 가용성과 안정성을 높이는 데 도움이 된다는 것을 확인했습니다. Amazon GameLift Server SDK의 OnProcessTerminate 콜백 함수를 이용해 스팟 중단 시에도 자연스러운 대응 방안을 마련할 수 있었습니다. 온디맨드 플릿과 스팟 플릿을 함께 사용할 때 스팟 플릿이 사용되지 않을 경우에는 스팟 인스턴스 어드바이저에서 제공되는 정보를 활용해 안정적인 인스턴스 유형을 선택하고 스팟 인스턴스를 사용하기 적절한 게임 유형에 스팟 인스턴스를 사용해야 한다는 점도 살펴봤습니다. 이러한 내용들을 바탕으로 당신의 게임 서버가 Amazon GameLift Servers의 스팟 플릿과 함께 좀 더 비용 효율적으로 작동하길 바라며 이 글이 그 출발점이 되었기를 바랍니다.

AWS 기술 블로그