게임 서버 아키텍처

게임 서버 아키텍처

게임 서버 아키텍처는 게임의 종류, 유저 수, 실시간성과 확장성 등 다양한 요구사항에 따라 설계 방식이 달라집니다. 이번 글에서는 대표적인 게임 서버 아키텍처와 각각의 특징, 그리고 실제 게임 예시를 살펴보겠습니다.

 

1. 클라이언트-서버 아키텍처

• 구조:
  클라이언트는 사용자 인터페이스와 그래픽을 처리하며, 서버는 게임 로직, 데이터 동기화, 보안 등을 처리하는 중앙 시스템입니다.
• 특징:
  클라이언트는 최소한의 게임 상태를 관리하며, 모든 중요한 데이터는 서버에서 처리됩니다.
• 사용 예시:
  • MMORPG: 월드 오브 워크래프트
  • RTS: 스타크래프트
• 장점:
  1. 보안: 서버가 핵심 데이터를 관리하여 치트 방지에 유리.
  2. 일관성: 서버가 모든 클라이언트를 동기화하여 데이터 불일치 문제를 방지.
  3. 확장성: 서버를 증설하여 플레이어를 더 많이 수용 가능.
• 단점:
  1. 운영 비용: 서버 유지 비용이 높음.
  2. 단일 장애점: 서버가 다운되면 모든 플레이어가 영향을 받음.
  3. 지연 시간: 서버와의 거리 또는 부하로 인해 응답 시간이 길어질 수 있음.

---

2. 피어 투 피어(P2P) 아키텍처

• 구조:
  플레이어 간의 직접 통신으로 데이터를 교환하며, 중앙 서버는 없거나 최소한의 역할만 수행합니다.
• 특징:
  각 플레이어가 다른 플레이어와 동등한 권한으로 게임 상태를 유지 및 동기화합니다.
• 사용 예시:
  • Co-op 게임: 몬스터 헌터
  • 소규모 멀티플레이 FPS: 에이지 오브 엠파이어
• 장점:
  1. 비용 절감: 중앙 서버가 없으므로 유지 비용이 낮음.
  2. 낮은 지연 시간: 플레이어 간 직접 통신으로 빠른 응답 가능.
  3. 자율성: 서버의 개입 없이 플레이어가 세션을 쉽게 생성 가능.
• 단점:
  1. 보안 문제: 해킹 및 치트 방지에 취약.
  2. 동기화 어려움: 네트워크 상태가 다른 플레이어들 간의 데이터 불일치 발생 가능.
  3. 호스트 의존성: 호스트 플레이어가 접속 종료 시 세션 전체에 영향을 줄 수 있음.

---

3. 데디케이트 서버 아키텍처

• 구조:
  게임 회사가 관리하는 전용 서버가 각 게임 세션을 담당하며, 모든 데이터와 게임 상태를 서버에서 유지합니다.
• 특징:
  서버는 고성능 하드웨어를 기반으로 하며, 플레이어가 접속 종료하더라도 게임 세션이 유지됩니다.
• 사용 예시:
  • FPS: 카운터 스트라이크, 배틀필드
  • MOBA: 리그 오브 레전드
• 장점:
  1. 높은 성능: 최적화된 서버 환경으로 일관된 성능 제공.
  2. 안정성: 플레이어가 나가도 세션이 유지되므로 끊김 없는 게임 경험 제공.
  3. 보안 강화: 서버에서 데이터를 중앙 집중적으로 관리.
• 단점:
  1. 운영 비용: 고성능 서버 유지 및 네트워크 관리 비용이 높음.
  2. 지연 문제: 서버와의 물리적 거리가 멀면 응답 속도가 느려질 수 있음.

---

4. 분산 서버 아키텍처

• 구조:
  단일 서버가 아닌 여러 서버가 협력하여 데이터를 분산 처리하고, 게임 로직과 상태를 동기화합니다.
• 특징:
  특정 서버가 실패해도 다른 서버가 이를 대체하여 서비스 중단을 방지합니다.
• 사용 예시:
  • MMORPG: 검은사막, 이브 온라인
• 장점:
  1. 확장성: 대규모 플레이어 처리에 유리하며, 부하를 여러 서버로 분산 가능.
  2. 안정성: 특정 서버가 다운되더라도 전체 서비스는 유지.
  3. 글로벌 접근성: 지역별 서버 분산으로 낮은 지연 시간 제공.
• 단점:
  1. 복잡한 관리: 여러 서버 간 데이터 동기화 및 네트워크 트래픽 관리가 어려움.
  2. 높은 비용: 여러 서버 운영에 따른 인프라 및 유지 비용 상승.

---

5. 멀티 리전 기반 아키텍처

• 구조:
  중앙 서버(계정, 인증, 상점 등)를 기반으로 각 지역에 전진 배치된 서버가 게임 세션을 처리합니다.
• 특징:
  글로벌 플레이어를 위해 지역별 서버가 빠른 응답을 제공합니다.
• 사용 예시:
  • 글로벌 MMORPG: 파이널 판타지 XIV, 월드 오브 워크래프트
• 장점:
  1. 낮은 지연 시간: 각 지역 서버가 빠르게 게임 데이터를 처리.
  2. 유지보수 용이성: 중앙 서버와 지역 서버의 역할 분리가 관리 효율성을 높임.
  3. 글로벌 확장성: 전 세계적으로 게임 서비스를 제공 가능.
• 단점:
  1. 비용 증가: 여러 지역 서버 구축 및 운영 비용이 높음.
  2. 데이터 동기화: 지역 간 실시간 데이터 일관성을 유지하기 어려움.

---

6. 서버리스 아키텍처

• 구조:
  클라우드 서비스 제공업체의 동적 리소스를 사용하여, 서버를 직접 관리하지 않고 필요한 만큼 리소스를 소비합니다.
• 특징:
  서버가 자동으로 확장되거나 축소되며, 클라우드의 고가용성을 이용합니다.
• 사용 예시:
  • 모바일 게임: 포켓몬 고
  • HTML5 게임: 간단한 멀티플레이 브라우저 게임
• 장점:
  1. 운영 간소화: 서버 설정 및 유지보수 작업 감소.
  2. 비용 효율성: 사용한 만큼만 비용 지불.
  3. 자동 확장: 플레이어 수에 따라 리소스를 자동으로 조절.
• 단점:
  1. 제한된 제어: 서버 환경에 대한 세부적인 제어가 어려움.
  2. 지연 시간: 클라우드 서비스 제공업체의 네트워크에 의존하므로 예측이 어려운 지연 발생 가능.
  3. 비용 변동성: 트래픽 급증 시 비용이 예기치 않게 증가할 수 있음.

 

 

내가 게임 서버를 만든다면 어떻게 만들지 게임서버 아키텍처 다이어그램을 그리기

게임 기획

1. 게임 특징
   • 장르: 파밍형 생존 오픈월드
   • 플레이어 수: 2~8명
   • 주요 기능: 파밍, 협동/경쟁, 실시간 동기화
   • 네트워크 구조: 서버는 세션 관리만 담당, 방장은 호스트 역할
2. 필수 고려 요소
   • 세션 관리: 중앙 서버에서 방 생성, 입장, 삭제 관리
   • P2P 통신: 게임 진행은 방장이 호스트로서 데이터를 중계
   • 확장성: 서버 부하 최소화 및 안정적인 연결
   • 보안: 방장이 호스트일 경우 치트 방지 및 데이터 무결성 보장

아키텍처 설계

1. 중앙 서버

• 역할:
  • 사용자 인증 및 매치메이킹
  • 방 생성, 입장, 삭제 관리
  • 세션 정보 저장 (방장 정보, 참여자 리스트 등)
• 구성 요소:
  • REST API: 로그인, 방 생성/삭제, 세션 상태 관리
  • WebSocket: 실시간 알림 및 상태 업데이트 (예: 새로운 방 생성 알림)
  • 데이터베이스:
    • 유저 정보: ID, 닉네임, 진행 데이터
    • 방 정보: 세션 ID, 방장 ID, 참여자 리스트, 생성 시간 등

2. 클라이언트 (유저 측)

• 방장(호스트):
  • 게임 세션의 호스트 역할을 수행
  • 다른 플레이어의 요청을 받아 게임 상태 동기화 (P2P 통신)
  • 예: 월드 데이터 전송, 이벤트 처리, 유저 위치 동기화
• 일반 플레이어:
  • 방장과 통신하여 게임 데이터를 실시간으로 수신/전송

3. 통신 방식

• 중앙 서버와 클라이언트 간 통신:
  • 방 생성/입장/삭제: REST API 호출
  • 실시간 상태 업데이트: WebSocket 사용
• 클라이언트 간 통신:
  • P2P 방식:
    • 방장이 중계 서버 역할을 수행
    • 유저 간 데이터를 직접 전송 (WebRTC 사용 추천)
  • UDP 프로토콜: 실시간 성능 최적화

시스템 구성도

1. 클라이언트-서버 흐름
   • 클라이언트 → 중앙 서버:
     • 로그인, 방 생성 요청, 방 목록 요청
   • 중앙 서버 → 클라이언트:
     • 방 목록 전달, 입장 인증, 방 삭제 알림
   • 클라이언트 ↔ 클라이언트:
     • 방장(호스트)과 나머지 유저 간 데이터 전송 (P2P)
2. 데이터 흐름
   • 중앙 서버: 세션 데이터 관리
   • 방장: 게임 데이터를 관리 및 동기화 (월드 상태, 플레이어 위치 등)
   • 참여자: 게임 데이터를 수신 및 명령 요청

---

구현 계획

1. 중앙 서버

• 기술 스택:
  • Node.js + Express.js: API 서버
  • Redis: 세션 관리
  • WebSocket: 실시간 알림
  • PostgreSQL/MySQL: 유저 및 방 데이터 저장
• 주요 기능:
  • REST API:
    • /create-room: 방 생성
    • /join-room: 방 참가
    • /close-room: 방 삭제
  • WebSocket 이벤트:
    • room-update: 방 목록 변경 알림
    • session-sync: 실시간 상태 업데이트

2. 클라이언트

• 방장(호스트):
  • WebRTC로 방 참가자와 직접 통신
  • 월드 상태 동기화 및 유저 동작 처리
• 참여자:
  • WebRTC로 방장과 연결
  • 실시간 월드 정보 수신 및 로컬 반영

3. 보안 및 성능

• 보안:
  • 중앙 서버에서 유저 인증 토큰 발급
  • P2P 데이터 암호화 (DTLS 사용)
• 성능:
  • UDP 기반 통신 (빠른 데이터 전송)
  • 네트워크 레이턴시 보정 (예: Dead Reckoning)

 

 

하이브리드 아키택처를 선택한 이유

1. 중앙 서버의 역할 최소화 → 비용 절감

하이브리드 아키텍처에서는 중앙 서버가 주로 다음과 같은 역할만 수행합니다:

• 방 생성/삭제 관리
• 유저 인증 및 매치메이킹
• 세션 정보 저장

즉, 중앙 서버가 게임플레이 데이터를 처리하거나 실시간으로 게임 상태를 관리할 필요가 없습니다.
이는 서버 부하를 크게 줄이고 운영 비용을 절감할 수 있습니다.

예: 방장(호스트)이 각 방의 상태를 관리하므로 중앙 서버는 수많은 동시 접속을 효율적으로 처리 가능.

 

2. P2P로 실시간 성능 극대화

방장은 호스트로서 실시간 데이터를 직접 관리하고, 플레이어 간 통신은 P2P로 처리됩니다.
이는 실시간성과 빠른 응답속도가 중요한 오픈월드 게임에서 큰 장점입니다:

• 지연 시간 감소: 데이터를 중앙 서버를 거치지 않고 방장이 직접 처리.
• 실시간 동기화 효율: 방장과 클라이언트 간 빠른 데이터 전송.

예를 들어:

• 방장은 월드의 상태(아이템 위치, 몬스터 스폰)를 관리하며 클라이언트에게 전달.
• 각 클라이언트는 자신의 상태(위치, 액션)를 방장에게 전송.

3. 확장성 및 유저 수 증가에 대응 가능

하이브리드 구조에서는 중앙 서버가 "방 관리"만 담당하기 때문에, 유저 수가 늘어나더라도 서버 부하가 급격히 증가하지 않습니다.
새로운 방을 생성할 때 추가 서버 자원이 필요하지 않으므로, 확장성이 뛰어난 구조입니다.

예: 서버가 1,000개의 방을 관리하더라도 각 방의 게임 상태는 방장이 처리하므로 서버 부담은 최소화.

4. 오픈월드 게임의 특성과 잘 맞음

오픈월드 생존 게임은 다음과 같은 특성을 가집니다:

• 플레이어 간 비대칭성: 일부 유저는 주도적으로 게임 상태를 관리(방장), 나머지 유저는 단순히 참여.
• 월드 데이터의 동기화: 월드 상태(자원, 적 상태 등)를 지속적으로 관리하고 업데이트.
• 다수의 이벤트 처리: 플레이어 이동, 아이템 사용, 몬스터 스폰 등.

하이브리드 아키텍처는 방장이 월드 상태를 관리하는 방식으로 이런 특성에 잘 대응합니다.

5. 유저 경험 개선

방장이 호스트가 되면서 다음과 같은 유저 경험 개선 효과가 있습니다:

• 저지연 게임 환경: 방장과 가까운 유저는 낮은 핑으로 게임을 즐길 수 있음.
• 유연한 방 생성 및 관리: 유저가 원하는 설정(비밀번호, 플레이 규칙 등)으로 방을 쉽게 생성 가능.

6. 비용 효율성과 유지보수 용이

• 서버 비용 절감: P2P를 활용해 중앙 서버의 실시간 부하를 줄이고, 방장에게 작업을 분산.
• 유지보수 간소화: 서버는 세션 관리와 인증에만 집중하므로 시스템 복잡도가 낮아 유지보수가 쉬움.