AI 요약관련 정보

• 초기 서비스는 게임 상태를 단일 인스턴스 로컬 메모리에서 관리했으며, DB가 필요 없었습니다. 🎮
• 단일 인스턴스 환경에서 트래픽 병목은 비즈니스 로직보다 메시지 송수신 시 네트워크 대역폭 한계(5Gbps)로 인해 발생했습니다. 🚧
• 스케일업은 비용 문제(10Gbps NIC가 11-12배 비쌈)로 어려웠고, 스케일아웃 시 여러 인스턴스 간 게임 상태 및 유저 정보 불일치 문제가 발생했습니다. 🔄
• 스프링 웹소켓의 유저 정보는 인스턴스 로컬 메모리에서 관리할 수밖에 없었으며, 게임 상태 저장 방안이 핵심 과제였습니다. 🧑‍💻
• Redis는 원격 인메모리 Key-Value 서버로, RDBMS보다 빠르며 중앙 세션 저장소, 캐싱, 메시지 브로커 등으로 활용될 수 있습니다. ⚡
• 첫 번째 구조 (RDBMS + Redis 메시지 브로커): DB에 게임 상태 저장 후 Redis로 변경 이벤트 브로킹. 구현 용이, 데이터 안전성 높으나 DB의 디스크 I/O로 인해 느립니다. 📊
• 두 번째 구조 (Redis 중앙 게임 상태 + 메시지 브로커): Redis에 게임 상태 저장 및 변경 이벤트 브로킹. DB보다 빠르고 데이터 안전하나, 직렬화/역직렬화 수동 처리 및 Redis 병목(단일 스레드 내부 처리) 가능성이 있습니다. ⚙️
• 세 번째 구조 (로컬 캐시 + Redis 메시지 브로커): 각 인스턴스 로컬 메모리에 게임 상태 저장 후 Redis로 변경 이벤트(페이로드 포함) 브로킹. 로컬 접근으로 가장 빠르고 Redis 부하가 적습니다. 🏘️
• 실시간 게임 특성상 RDBMS의 Latency는 치명적이라 배제되었고, Redis 부하 테스트 결과 로컬 캐시 구조(세 번째)가 Redis CPU 사용률을 절반으로 줄여 채택되었습니다. ✅
• 세 번째 구조의 한계점으로는 fire-and-forget 방식의 메시지 유실 가능성 👻과 동시성 문제(요청 순서 보장 불가) 🚦가 여전히 존재합니다.
• 결론적으로, 도메인 특성과 현실적 제약을 고려한 인프라 디자인이 가장 중요합니다. 💡