AWS GameLift와 Serverless로 구현하는 매칭 백엔드 아키텍처 (1부)

개요

이번 글에서는 Wild Bowl : Zooports에서 게임 내 매칭 시스템을 AWS의 서버리스 아키텍처를 통해 구현한 사례를 간단히 소개하려고 합니다. 특히 마블 스냅(Marvel Snap)에서 사용된 매칭 시스템을 참고하여, 저희 게임 Wild Bowl에 적용한 경험을 바탕으로 작성했습니다.

매칭 시스템은 짧은 시간 안에 매칭 큐에 들어온 플레이어들을 빠르고 안정적으로 연결해줘야 합니다. 또한 매칭이 진행되는 동안, 사용자(클라이언트)에게 끊임없이 매칭 상태 정보를 알려줘야 하는데요. RESTful API 방식으로는 지속적인 연결을 통해 이벤트를 전달하기가 쉽지 않기 때문에, 이번에는 WebSocket을 적극 활용하기로 결정했습니다.

어떻게 매칭 아키텍쳐를 구현할 것인가

1. WebSocket API (WSS) 이용

• 매칭 로직을 구현하기 위해 가장 중요한 부분은 게임 클라이언트에게 지속적으로 매칭 상태를 전달해야 한다는 점입니다. RESTful API 방식은 클라이언트에서 백엔드로 요청을 보낼 때만 응답을 받기 때문에, 매칭이 진행되는 동안 클라이언트가 연속적으로 상태를 받기가 어렵습니다.
• WebSocket(특히 HTTPS 보안 채널 위에서 동작하는 WSS)은 서버와 클라이언트 간의 연결을 계속 유지합니다. 이로써 매칭 큐에 들어간 이후부터 매칭 성공 여부, 상태 변화 등을 바로바로 클라이언트에 전달할 수 있게 됩니다.

2. ConnectionId 관리

• WebSocket을 통해 지속적으로 상태를 전송하기 위해서는, ConnectionId를 관리할 필요가 있었습니다.
• 처음에는 별도의 캐시 DB나 Redis 등을 고려했지만, 당장 소프트런칭 당시에 관리 오버헤드가 커질 것을 우려해 간단히 유저 데이터를 저장하던 DynamoDB를 사용하기로 했습니다.
• 유저 테이블에 매칭 정보와 함께 ConnectionId를 저장해두고, 해당 유저에게 이벤트를 보낼 때는 ConnectionId를 참조해 메시지를 전송하는 방식으로 구성했습니다.

3. GameLift FlexMatch

• 매칭의 상세 로직 구현을 직접 하기보다는, AWS GameLift에서 제공하는 FlexMatch를 활용했습니다.
• 이미 전용 서버(데디케이티드 서버) 호스팅을 GameLift로 운영하고 있었기 때문에, GameLift의 큐에 유저를 넣고 FlexMatch로 매칭 로직을 처리하는 것이 자연스럽고 편리했죠.
• 또한 FlexMatch에서 매칭이 성사되었을 때 SNS, SQS를 통해 이벤트 콜백을 받을 수 있어, 이를 Lambda로 연결해 효율적으로 상태를 업데이트하고 필요한 후속 처리를 진행했습니다.

마치며

이번 글에서는 서버리스 방식으로 매칭 기능을 구성하기 위해 왜 WebSocket과 FlexMatch를 선택했는지, 그리고 ConnectionId 관리는 어떻게 했는지 등 아키텍처 전반을 소개해드렸습니다.

다음 글에서는 각 파트별로 좀 더 세밀하게 들어가 보려 합니다. 예를 들어, WebSocket API Gateway 설정, Lambda 로직 구조, FlexMatch 대기열(큐) 설정과 SNS/SQS 연동 등에 대해 구체적인 예제와 함께 다룰 예정입니다.

다음 포스트 : AWS GameLift와 Serverless로 구현하는 매칭 백엔드 아키텍처 (2부) — WSS연결로 매칭 요청/취소 처리하기