🏆 게임 리더보드 시스템

왜 이걸 만들까? — 1등이 누구인지 즉시 알고 싶다

여러분이 모바일 퍼즐 게임을 만들고 있다고 상상해 보세요.

플레이어들은 스테이지를 클리어할 때마다 점수를 얻고, "내가 전체 몇 등이지?"를 궁금해합니다. 100명 정도는 DynamoDB에서 Scan → 정렬로 충분하지만, 플레이어가 10만 명, 100만 명으로 늘어나면 어떻게 될까요?

DynamoDB에서 100만 건을 스캔하고 정렬하면 수 초~수십 초가 걸립니다. 게임 리더보드는 탭을 누르는 순간 바로 보여야 하는데, 매번 이렇게 느리면 유저는 떠나갑니다.

해답은 Redis의 Sorted Set 자료구조입니다.

Redis Sorted Set은 각 멤버에 점수(score)를 연결하여 항상 정렬된 상태를 유지합니다. 100만 명 중에서 특정 플레이어의 순위를 조회하는 데 걸리는 시간은 단 0.1ms — DynamoDB 스캔 대비 10,000배 이상 빠릅니다.

이 실습에서는:

• DynamoDB: 플레이어 프로필과 점수 이력을 영구 저장 (데이터 안전성)
• ElastiCache Redis: 실시간 순위 계산 전용 캐시 (초고속 조회)
• Lambda + API Gateway: 점수 등록/순위 조회 API

이 세 가지를 조합하여 대규모 실시간 리더보드를 만듭니다.

이 프로젝트를 통해 배우게 되는 것:

• Redis Sorted Set: 자동 정렬 자료구조의 원리와 활용법
• 인메모리 vs 디스크 DB: 속도와 영속성의 트레이드오프
• VPC 네트워킹: Lambda에서 ElastiCache에 접근하기 위한 VPC 구성
• Cache-Aside 패턴: 캐시와 데이터베이스를 함께 사용하는 아키텍처 패턴
• 성능 비교: DynamoDB Scan vs Redis Sorted Set의 응답 시간 차이 직접 체감

아키텍처 개요

데이터 흐름

비용 예측

Step 1: DynamoDB 플레이어 테이블 생성

DynamoDB는 플레이어의 영구 데이터를 저장합니다. 닉네임, 누적 점수, 게임 횟수, 최고 점수 등을 저장하여, Redis 데이터가 유실되더라도 복구할 수 있는 안전장치 역할을 합니다. 온디맨드 모드를 선택하면 트래픽에 따라 자동으로 용량이 조절되어, 실습에서 비용을 최소화할 수 있습니다.

aws dynamodb create-table \
  --table-name game-players \
  --attribute-definitions AttributeName=player_id,AttributeType=S \
  --key-schema AttributeName=player_id,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST \
  --region ap-northeast-2

Step 2: ElastiCache Redis 클러스터 생성

ElastiCache Redis는 인메모리 데이터 저장소로, 리더보드의 핵심 엔진입니다. Sorted Set이라는 자료구조가 내장되어 있어, 점수 등록과 동시에 자동 정렬이 유지됩니다. Lambda에서 Redis에 연결하려면 같은 VPC 안에 있어야 합니다.

중간 점검

여기까지 완료되었으면 아래를 확인하세요:

• DynamoDB game-players 테이블이 "활성" 상태인지
• ElastiCache Redis 클러스터/서버리스가 "사용 가능" 상태인지
• Redis 엔드포인트 주소를 메모했는지
• Lambda와 Redis가 같은 VPC에 있을 수 있도록 VPC/서브넷 정보를 확인했는지

다음 단계에서는 Lambda 함수를 작성하여 Redis와 DynamoDB를 모두 연결합니다.

Step 3: Lambda 함수 작성 (점수 등록 / 순위 조회)

이 Lambda 함수가 리더보드의 비즈니스 로직 전체를 담당합니다. Redis의 핵심 명령어 4가지(ZADD, ZREVRANK, ZREVRANGE, ZSCORE)를 사용하여 점수 등록과 순위 조회를 구현합니다. Lambda Layer로 redis-py 라이브러리를 추가해야 합니다.

Step 4: API Gateway 엔드포인트 설정

게임 클라이언트가 호출할 REST API를 구성합니다. 점수 등록(POST)과 순위 조회(GET) 두 가지 엔드포인트를 만듭니다. 개인 순위 조회는 URL 경로 변수({player_id})를 사용합니다.

Step 5: 성능 비교 테스트

리더보드의 핵심 가치는 속도입니다. Redis Sorted Set의 빠른 응답 시간을 DynamoDB 직접 조회와 비교하여 체감해 봅니다. 실제 게임에서는 이 차이가 사용자 경험에 큰 영향을 줍니다.

Lambda 핸들러 코드 핵심 구조

점수 등록과 순위 조회를 처리하는 Lambda 코드의 핵심 패턴입니다:

import json, os, boto3, redis
 
# 전역 스코프 — 웜 스타트 시 재사용
r = redis.Redis(host=os.environ['REDIS_HOST'], port=6379, decode_responses=True)
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('game-players')
 
LEADERBOARD_KEY = 'leaderboard'
 
def lambda_handler(event, context):
    path = event['path']
    method = event['httpMethod']
    
    if path == '/score' and method == 'POST':
        body = json.loads(event['body'])
        player_id = body['player_id']
        score = float(body['score'])
        
        # Redis에 점수 등록 (자동 정렬)
        r.zadd(LEADERBOARD_KEY, {player_id: score})
        # DynamoDB에 영구 저장
        table.put_item(Item={'player_id': player_id, 'score': int(score)})
        
        rank = r.zrevrank(LEADERBOARD_KEY, player_id)
        return response(200, {'rank': rank + 1})  # 0-based → 1-based
    
    elif path == '/ranking' and method == 'GET':
        top10 = r.zrevrange(LEADERBOARD_KEY, 0, 9, withscores=True)
        result = [{'player_id': p, 'score': s, 'rank': i+1} for i, (p, s) in enumerate(top10)]
        return response(200, result)

핵심 개념 확인

트러블슈팅 가이드

완성 후 테스트 가이드

전체 시스템이 올바르게 동작하는지 아래 체크리스트로 검증하세요:

1. 점수 등록: POST /score → {"player_id": "player_001", "score": 1500} → 200 응답 확인
2. Top 10 조회: GET /ranking → 점수 내림차순 10명 목록이 반환되는지 확인
3. 개인 순위 조회: GET /ranking/player_001 → 해당 플레이어의 순위 + 주변 5명이 반환되는지 확인
4. 점수 업데이트: 같은 player_id로 더 높은 점수를 등록 → 순위 자동 갱신 확인
5. DynamoDB 영구 저장: DynamoDB 콘솔에서 game-players 테이블에 데이터가 저장되었는지 확인
6. 동시 요청: 여러 플레이어의 점수를 빠르게 연속 등록 → 순위가 즉시 갱신되는지 확인
7. 엣지 케이스: 동일 점수의 플레이어 2명이 있을 때 순위가 어떻게 표시되는지 확인 (Redis는 사전순으로 처리)
8. 데이터 정합성: Redis의 Top 10과 DynamoDB의 데이터가 일치하는지 교차 검증

확장 아이디어

1. 주간/월간 리더보드: Redis에 leaderboard:weekly, leaderboard:monthly 키를 분리하고, EventBridge로 매주/매월 초기화하는 스케줄 구현
2. 친구 리더보드: 플레이어의 친구 목록을 DynamoDB에 저장하고, ZSCORE로 친구들의 점수만 모아서 별도 순위표 생성
3. 실시간 순위 변동 알림: 순위가 변경되면 WebSocket API Gateway + Lambda로 클라이언트에 실시간 푸시 알림
4. 리더보드 히스토리: DynamoDB에 일별 Top 100 스냅샷을 저장하여 "지난주 리더보드" 기능 구현
5. 치팅 방지: 점수 등록 시 Lambda에서 이전 점수 대비 비정상적 상승(예: 1분에 100만점 증가) 탐지 로직 추가

Redis 핵심 명령어 레퍼런스

리더보드에서 사용하는 Redis Sorted Set 명령어를 정리합니다. Lambda 코드에서 redis-py 라이브러리를 통해 호출합니다.

실습 후 사고 실험

실습에서는 100명의 플레이어를 테스트했지만, 실제 게임 서비스에서는 어떨까요?

플레이어 100만 명 시나리오:

• Redis Sorted Set은 100만 멤버에서도 ZREVRANK가 0.1ms — 체감 불가능한 속도
• 메모리 사용량: 100만 멤버 x (플레이어ID 20바이트 + 점수 8바이트) ≈ 약 30MB — cache.t3.micro(0.5GB)로 충분
• 초당 1만 건의 점수 업데이트도 단일 Redis 노드로 처리 가능

Redis 장애 복구 시나리오:

• Redis 서버가 재시작되면 메모리 데이터가 유실됨
• 복구 방법: DynamoDB에서 전체 플레이어 점수를 읽어 Redis에 ZADD로 재로드 (별도 Lambda 작성)
• 프로덕션에서는 Redis Multi-AZ 복제본을 설정하여 자동 장애 조치(Failover) 구성

학습 정리

리소스 정리