AWS Serverless Architecture를 사용한 새로운 포커 변형 구축

Source: Dev.to

코딩 전에 설계하기

코드를 작성하기 전에 36페이지 분량의 Low‑Level Design (LLD) 문서를 만들었습니다. LLD는 모든 엣지 케이스, 상태 전이, 그리고 실패 모드를 사전에 고려하도록 강제했으며—이는 실제 운영 시스템이 구축되는 방식과 정확히 일치합니다.

수치로 보는 현황

• 7개의 AWS 서비스
• 8개의 DynamoDB 테이블
• 36페이지 LLD
• 관리할 서버 0대

아키텍처

Point Game은 완전 서버리스이며 이벤트 기반 시스템입니다. 클라이언트는 계정 및 테이블 작업을 위해 REST API를 사용하고 실시간 게임 플레이를 위해 WebSocket을 사용합니다.

인프라 개요

핵심 인사이트: DynamoDB는 단일 진실 소스입니다. 모든 게임 상태, 액션 로그, 연결 매핑은 DynamoDB에 저장됩니다. Lambda 함수는 무상태이며—상태를 읽고, 액션을 처리하고, 상태를 기록하고, 브로드캐스트합니다. 이는 시스템을 수평 확장 가능하고 장애에 강하게 만듭니다.

Client Action → API Gateway → Lambda → DynamoDB → Broadcast

데이터 모델

어려운 문제들

도전 과제 1: 낙관적 동시성 제어

동시에 발생하는 플레이어 행동이 상태를 손상시킬 수 있습니다. 나는 시퀀스 기반 버전 관리를 구현했습니다: 각 상태 변형에는 예상 시퀀스 번호가 포함됩니다. 번호가 일치하지 않으면 쓰기가 실패하고 클라이언트가 재동기화되어 경쟁 조건과 손실된 행동을 없앱니다.

도전 과제 2: 턴 타이머 시스템

Lambda 함수는 “대기”할 수 없습니다. 나는 EventBridge 예약 이벤트를 사용했습니다: 턴이 시작될 때 타이머 시퀀스를 가진 미래 이벤트를 예약합니다. 타임아웃 Lambda는 시퀀스가 아직 현재인지 확인합니다; 플레이어가 이미 행동했으면 타이머를 무시하고, 그렇지 않으면 플레이어를 자동으로 폴드합니다.

도전 과제 3: 프라이버시 필터링 방송

각 플레이어는 개인화된 뷰(자신의 홀 카드와 상대의 카드 뒷면)를 봐야 합니다. 방송자는 권위 있는 상태를 로드하고, 수신자별로 개인 정보를 필터링한 뒤 맞춤형 WebSocket 메시지를 보냅니다.

도전 과제 4: 라운드 간 액션 큐

플레이어는 핸드 진행 중에 참여하거나 떠나거나 설정을 변경할 수 있습니다. 이러한 액션은 큐에 저장되고 핸드 사이에 원자적으로 처리되어, 실제 플레이어 행동을 수용하면서 게임 상태 일관성을 유지합니다.

도전 과제 5: 복잡한 게임 규칙

포인트 게임은 많은 엣지 케이스를 포함합니다—특히 사이드 팟, 분할 팟, 다중 승자와 관련된 쇼다운 로직이 그렇습니다. 이러한 규칙을 신뢰할 수 있는 코드로 옮기기 위해서는 동시 부하 하에서 신중한 상태 관리가 필요했으며, 전용 서버 없이 구현했습니다.

Why This Exceeds Industry Standard

Most hobby projects are simple CRUD apps or static pages. Point Game demonstrates:

• A real‑time distributed system with WebSocket state synchronization
• Event‑driven architecture with scheduled triggers and async processing
• Production‑grade consistency guarantees via optimistic concurrency
• Domain‑specific game logic handling complex state machines for multiple simultaneous players and games

I designed, documented, and built the entire platform and can explain every architectural decision.

직접 체험해 보세요

게임을 플레이하세요:
커뮤니티에 참여하세요: