[게임 서버] 8.2 관계형 데이터베이스에서 확장성

이 글은 아래의 책을 자세히 정리한 후, 정리한 글을 GPT에게 요약을 요청하여 작성되었습니다.
게임 서버 프로그래밍 교과서, 배현직 저자

📦 8. NoSQL 기초

👉🏻 2. 관계형 데이터베이스에서 확장성

📌 상황

• 사용자가 많아, 게임 서버를 하드웨어 여러 대로 구성

---

📐 수직 분산

• 여러 테이블을 여러 데이터베이스 컴퓨터에 담는 것
• 한계점: 테이블이 10개, 데이터베이스 컴퓨터가 100개인 경우 90대가 남아돈다.

---

📊 수평 분산

• 테이블 한 개에 있는 레코드 1억 개를 데이터베이스 컴퓨터 100대에 분산시킨다.
• 분산된 테이블의 조각을 샤드라고 한다.

---
config:
  look: handDrawn
  theme: dark
  layout: dagre
---
flowchart TB

subgraph DB2["DB #2"]
    subgraph T1_2["테이블 T1"]
        M["Malte"]
    end
end

subgraph DB1["DB #1"]
    subgraph T1_1["테이블 T1"]
        J["John"]
        A["Alice"]
    end
end

John 샤드를 찾는 방법:

1. 해시 함수 사용: John 문자열로 해시 함수를 실행하고, 나온 정수 값을 샤드 넘버로 사용한다.
2. 로케이터 DB 사용: John → 샤드 위치를 알려주는 별도 테이블을 만들고 액세스한다.
   • 두 번째 방법을 사용한다.

---

🗺️ 로케이터 DB

---
config:
  look: handDrawn
  theme: dark
  layout: dagre
---
flowchart LR

APP["애플리케이션"]
COORD["DB 코디네이터"]

subgraph DB_CLUSTER["DB Cluster"]
    LOC["로케이터 DB"]
    DB1["DB #1"]
    DB2["DB #2"]
end

APP -->|① John의 Money를 5로 바꾸어라| COORD
COORD -->|② John이 어딨니?| LOC
LOC -->|③ John은 DB #1에 있다| COORD
COORD -->|④ John의 Money를 5로 바꾸어라| DB1
DB1 -->|⑤ OK!| COORD
COORD -->|⑥ OK!| APP

• 데이터에 변화가 생기면 로케이터 DB에도 변화가 있어야 하므로, 원자성과 일관성을 제공해야 한다.

---

🔐 분산 락

• 둘 이상의 기기에 저장된 데이터를 액세스하는 동안, 해당 데이터 액세스를 블로킹시켜주는 것
• 데이터베이스 일관성을 지킬 수 있지만, 처리 속도에 문제가 생긴다.
• 데이터베이스 샤드가 많을수록, 분산 처리 효과가 퇴색된다.

---

⚖️ 일관성과 원자성을 포기하는 경우

---
config:
  look: handDrawn
  theme: dark
  layout: dagre
---
flowchart LR

APP["애플리케이션"]
COORD["DB 코디네이터"]

subgraph DB_CLUSTER["DB Cluster"]
    LOC["로케이터 DB"]
    DB1["DB #1"]
    DB2["DB #2"]
end

APP --- COORD

COORD ---|② 여기는 액세스해도 OK!| LOC
COORD ---|① 여기서 John에 액세스하는 동안| DB1

• 락의 강도를 낮추면 수평 분산의 효과를 제대로 볼 수 있다.
• 락에 따른 처리 성능 하락이 발생하지 않는다.
• 하지만, 일관성을 보장할 수 없어진다.

GameServer 카테고리 내 다른 글 보러가기