Write heavy DBMS 조사

2025-08-07

데브시스터즈의 CockroachDB 아티클을 읽고 Write 가 정말 중요한 시스템 설계가 궁금해졌다.

Claude Opus 4.1 이 출시되어 딥서치에 사용했는데 느낌상 예전보다 약간 더 표현이 몽글해진 느낌. 결론

분산 DBMS 가 최선. ScyllaDB, CockroachDB, YogabyteDB, Google Spanner

Claude Opus 4.1 딥서치

Write-Heavy 시스템용 DBMS 선택 완전 가이드

초당 수십만 TPS 처리와 강한 일관성을 동시에 보장하는 write-heavy 시스템 구축을 위한 실전 가이드입니다. LSM-tree 기반 분산 데이터베이스가 B-tree 기반 시스템 대비 2-5배 높은 쓰기 성능을 제공하며, ScyllaDB는 700만 TPS, CockroachDB는 168만 TPS의 검증된 성능을 보여줍니다.

게임과 이커머스 산업의 실제 사례 분석 결과, Riot Games는 Aurora 마이그레이션으로 프로비저닝 시간을 3-6개월에서 10-30분으로 단축했고, Shopify는 블랙프라이데이에 분당 460만 달러의 거래를 처리하며 초당 300만 건의 데이터베이스 쓰기를 안정적으로 수행했습니다. 이 가이드는 이러한 성공 사례의 핵심 패턴과 기술적 노하우를 체계적으로 정리하여 실무진이 바로 적용할 수 있는 구체적 방안을 제시합니다.

Write-heavy 워크로드를 위한 DBMS 성능 순위

1급 성능 데이터베이스 (50만+ TPS 입증)

ScyllaDB: 압도적 쓰기 성능의 리더

검증된 성능: 700만 TPS, P99 지연시간 10ms 미만
아키텍처: C++로 재구현된 Cassandra, thread-per-core 설계
스토리지: LSM-tree 기반 size-tiered compaction으로 쓰기 최적화
인프라 효율: 서버당 50TB 저장 밀도, 20대로 1PB 처리

VoltDB: 메모리 내 ACID 트랜잭션 전문

성능 지표: 16코어 클라이언트당 26만 TPS, 8노드로 87.7만 TPS 확장
텔레콤 실증: 프로덕션 환경에서 69.5만 TPS 달성
강점: 락 프리 설계로 동시성 오버헤드 제거

CockroachDB: PostgreSQL 호환 분산 ACID

TPC-C 결과: 168만 tpmC (14만 warehouse, 95% 효율성)
확장성: 256노드까지 거의 선형 확장 입증
지연시간: 단일 AZ 내 단일 행 쓰기 2ms
일관성: 기본적으로 SERIALIZABLE 격리 수준

2급 성능 데이터베이스 (10만-50만 TPS)

FoundationDB: 강한 일관성 보장

단일 코어: 2만 writes/초, 5.5만 reads/초 (SSD 엔진)
클러스터: 24대 머신에서 820만 ops/초 (90% read, 10% write)
지연시간: 75% 부하 미만에서 1.5-2.5ms 커밋 대기시간

TiDB: MySQL 호환 하이브리드 OLTP/OLAP

아키텍처: SQL 레이어(TiDB)와 스토리지(TiKV) 분리
스토리지: Rust 기반 LSM-tree, Raft 합의 알고리즘
분석 성능: TiFlash MPP로 CockroachDB 대비 우수한 분석 성능

기존 관계형 데이터베이스의 한계

PostgreSQL: B-tree + MVCC의 쓰기 성능 제약

성능: MySQL 대비 select 작업에서 13배 빠름 (0.6-0.8ms vs 9-12ms)
제약: B-tree 기반 랜덤 페이지 업데이트로 쓰기 증폭 발생
최적화: wal_buffers 자동 튜닝, synchronous_commit 설정 가능

MySQL: 스토리지 엔진별 성능 차이

InnoDB: 2.4만 TPS에서 210GB 데이터셋으로 1.8만 TPS로 성능 감소
TokuDB: LSM-tree 기반으로 1.4만 TPS 유지하면서 압축률 4배 개선

분산 시스템 vs 단일 고성능 서버 전략 분석

Scale-up (수직 확장) 특성과 한계

하드웨어 한계와 성능

성능 상한: 최신 고급 서버로 10만-50만 writes/초 처리 가능
메모리 확장: 1TB+ RAM, 128+ CPU 코어까지 가능하지만 메모리 업그레이드 비용은 용량 대비 4배 증가 (16GB→32GB 업그레이드 시)
응답 시간: 메모리 내 연산으로 1ms 미만 달성 가능
단일 장애점: 하드웨어 수준의 중복성 부재

Stack Overflow 사례: 전체 데이터를 메모리에 적재하여 예외적 성능 달성하는 “fit-everything-in-memory” 접근법의 성공 사례

Scale-out (수평 확장) 분산 시스템 패턴

쓰기 워크로드 확장성

선형 확장: TiDB는 512+ 노드까지 확장, 페타바이트 규모 데이터셋 처리
분산 쓰기: 클러스터 전체로 100만+ writes/초 분산 처리
합의 오버헤드: 노드 간 조정으로 쓰기 작업당 2-3회 네트워크 라운드트립 필요

비용 효율성 비교

Scale-up: 초기 비용 1-10만 달러, 프리미엄 하드웨어로 지수적 비용 증가
Scale-out: 일반 서버당 5-15천 달러, 선형적 확장 비용
TCO 분기점: 1TB 미만 데이터셋은 scale-up, 멀티TB 고성장 환경은 scale-out이 유리

분산 일관성 메커니즘과 성능 트레이드오프

Raft 합의 알고리즘의 실제 성능

주요 구현체별 특성

YugabyteDB: 샤드별 Raft로 독립적 파티션 확장 가능
TiDB/TiKV: 리전별 Multi-Raft 그룹 구현
etcd/Consul: 수천 writes/초 처리하는 프로덕션 검증 Raft

성능 지표

쓰기 대기시간: 단일 데이터센터 내 2-5ms, 리전 간 50-200ms
처리량: Raft 그룹당 1만-10만 writes/초
리더 전환: 150-300ms 내 자동 장애 복구

네트워크 지연시간이 일관성에 미치는 영향

지연시간 계층별 분석

데이터센터 내: 0.1-0.5ms
AZ 간: 1-5ms (단일 리전 내)
리전 간: 20-200ms (거리에 따라)
네트워크 지터: 측정 지연시간의 ±10-50% 변동

최적화 전략

배치 처리: 다중 연산에서 합의 오버헤드 분산
파이프라이닝: 다중 합의 라운드 중첩으로 처리량 향상
쿼럼 임대: 리더에서 합의 없이 읽기 제공으로 읽기 대기시간 단축

실전 아키텍처 패턴과 샤딩 전략

효과적인 샤딩 접근법

해시 기반 샤딩: 쓰기 집약 워크로드에 최적

균등 분산: 쓰기 부하의 완벽한 균등 분배
핫스팟 제거: 자연스러운 부하 분산으로 병목 현상 방지
쿼리 제약: 범위 쿼리 시 모든 샤드 대상 scatter-gather 필요

일관된 해시 구현 패턴

가상 노드: 물리 서버당 100-512개 가상 노드로 균등 분산
복제 전략: 후속 N개 노드 복제 (일반적으로 N=3)
점진적 확장: 인접 노드에만 영향을 주는 최소한의 데이터 이동

핫스팟 회피 기법

키 솔팅: 순차적 쓰기에 랜덤 접두사 추가
복합 키: 자연스러운 부하 분산을 위한 키 설계
시간 기반 샤딩: 현재/과거 데이터를 별도 샤드로 분리

커넥션 풀링과 프록시 아키텍처

고성능 커넥션 관리

최적 풀 크기: (CPU 코어 수 × 2) + 유효 스핀들 수
쓰기 집약 워크로드: CPU 코어당 8-16개 커넥션
동시 연결 한계: 대부분 데이터베이스에서 100-1,000개 효율적 처리

프록시 성능 최적화

PgPool-II: 커넥션 오버헤드 제거로 동일 백엔드로 10배 많은 클라이언트 처리
ProxySQL: 쿼리 멀티플렉싱으로 단일 클라이언트가 다중 백엔드 커넥션 활용
지연시간 추가: 프록시 계층으로 0.1-2ms 오버헤드 발생

하드웨어 최적화와 비용 효율성

스토리지 기술별 성능과 비용 분석

NVMe vs SATA SSD 비교

NVMe 성능: 최대 7GB/s 읽기, 5-6GB/s 쓰기, 50만+ IOPS
SATA 한계: 최대 600MB/s, 9만 IOPS로 NVMe 대비 5-10배 성능 차이
비용당 IOPS: NVMe $0.0006-0.0016, SATA $0.0017-0.0033

RAID 구성별 쓰기 성능

RAID 10: 쓰기 집약 데이터베이스에 최적 (2배 쓰기 페널티)
RAID 5: 4배 쓰기 페널티로 쓰기 집약 환경 부적합
RAID 0: 최고 성능이지만 중복성 없음

메모리와 CPU 최적화

DDR5 vs DDR4 성능 향상

DDR5 대역폭: 4,800-6,400 MT/s로 DDR4 대비 최대 2배 성능
다중 코어 확장: DDR5는 코어 수 증가에도 대역폭 유지
쓰기 집약 요구사항: 쓰기 증폭으로 인해 일반 대비 1.5-2배 메모리 대역폭 필요

NUMA 토폴로지 고려사항

지역/원격 액세스: 2-3배 지연시간 차이
메모리 할당: 데이터베이스 버퍼를 단일 NUMA 노드 내 유지
스레드 친화성: 데이터베이스 워커 스레드를 특정 NUMA 노드에 고정

TCO 분석: 클라우드 vs 온프레미스

3년 TCO 비교

온프레미스: 하드웨어 5-20만 달러, 연간 유지보수 15-20%, 인력 15만 달러+
클라우드: 월간 인스턴스 2-8천 달러, 스토리지 100-500 달러, 관리형 서비스 500-2천 달러
결과: 클라우드가 3년간 20-40% 저렴, 70% 이상 고활용 예측 워크로드는 온프레미스 유리

실제 사례: 게임과 이커머스 성공 패턴

Shopify: 블랙프라이데이 트래픽 처리

기록적 성능 달성 (2024 BFCM)

매출: 4일간 115억 달러 (24% 증가)
피크 처리: 분당 460만 달러 매출 (동부 시간 금요일 오후 12:01)
데이터베이스 부하: 피크 4,500만 쿼리/초, 300만 writes/초
인프라: 피크 시 쿠버네티스에서 240만 CPU 코어 활용

Pod 아키텍처의 핵심

멀티테넌트: 격리된 “pod”으로 수평 확장
플래시 세일 대응: 자동 샵 리밸런싱과 MySQL binlog 활용
재해 복구: 리전 간 Active-Passive pod 복제

Discord: Cassandra에서 ScyllaDB 마이그레이션

마이그레이션 성과

인프라 절약: 177대 Cassandra → 72대 ScyllaDB (59% 노드 감소)
성능 개선: P99 읽기 지연시간 40-125ms → 15ms, 쓰기 5-70ms → 5ms
운영 개선: GC 문제 해결, 예측 가능한 성능, 온콜 부담 감소

기술적 혁신

Rust 데이터 서비스: “Fearless concurrency”로 핫 파티션 제어
요청 병합: 동일 데이터 요청하는 다중 사용자를 단일 쿼리로 처리
9일 완료: Rust 기반 마이그레이터로 예상 3개월 → 9일 달성

Epic Games: Fortnite의 페타바이트 아키텍처

압도적 규모

동시 사용자: 전 세계 2억+ 플레이어
데이터 처리: 월간 2페타바이트, 분당 9,200만 이벤트
인프라: 12개 리전 24개 AZ, EMR 클러스터에서 4,000+ EC2 인스턴스

아키텍처 패턴

주 데이터베이스: Amazon DynamoDB (게임 상태, 플레이어 데이터)
실시간 파이프라인: Spark + DynamoDB 임시 저장
확장성: 피크 시간 30배 부하 자동 확장

운영 관점: 고가용성과 모니터링

고가용성 패턴별 특성

Active-Active 구성

이점: 최저 RTO/RPO, 최적 자원 활용, 지리적 분산
적용: Shopify pods, Netflix 글로벌 분산, 게임 플랫폼
트레이드오프: 높은 복잡성, 비용, 데이터 동기화 도전

Active-Passive 변형

Hot Standby: 전체 용량 준비, 가장 빠른 장애조치
Warm Standby: 부분 용량, 중간 복구 시간
Cold Standby: 최소 인프라, 가장 긴 복구 시간

성능 모니터링과 최적화 지점

쓰기 집약 시스템 핵심 지표

쓰기 지연시간: P99 지연시간 (Discord 5ms ScyllaDB vs 5-70ms Cassandra)
쓰기 처리량: 초당 연산 수 (Epic 분당 9,200만 이벤트)
큐 깊이: 비동기 처리를 위한 백로그 모니터링
오류율: 실패한 쓰기 연산 및 재시도 패턴

최적화 기법

배치 처리: 신중한 배치 전략 (Cassandra에서 크로스 노드 배치 회피)
컴팩션: 쓰기 최적화 컴팩션 (쓰기 집약 환경에서 LCS 회피)
압축: CPU 사용량과 스토리지 효율성 균형
커넥션 풀링: 데이터베이스 커넥션 최적화 및 재사용

의사결정 체크리스트와 구체적 추천

DBMS 선택 평가 기준

1단계: 성능 요구사항 정의

목표 TPS (10만? 50만? 100만+?)
허용 가능한 쓰기 지연시간 (1ms? 10ms? 100ms?)
데이터 크기 예상 (TB? PB?)
성장률 예측 (연간 2배? 10배?)

2단계: 일관성 요구사항

ACID 트랜잭션 필수 여부
강한 일관성 vs 최종 일관성
다중 리전 배포 계획
격리 수준 요구사항 (READ COMMITTED? SERIALIZABLE?)

3단계: 운영 역량 평가

팀의 데이터베이스 관리 경험
24/7 운영 인력 보유 여부
클라우드 vs 온프레미스 정책
예산 규모와 TCO 목표

용도별 구체적 DBMS 추천

게임 서비스 아키텍처

플레이어 데이터: DynamoDB (글로벌 분산, 낮은 지연시간)
게임 상태: Aurora (ACID 컴플라이언스, Multi-AZ)
리더보드: DynamoDB + GSI (글로벌 보조 인덱스)
채팅/소셜: ScyllaDB (높은 쓰기 처리량)
분석: 별도 분석 DB (Redshift, BigQuery)

이커머스 플랫폼 아키텍처

주문 처리: Aurora/RDS (트랜잭션 일관성)
상품 카탈로그: DynamoDB (확장성, 성능)
세션 데이터: ElastiCache/Redis (빠른 액세스)
재고 관리: 실시간 재고를 위한 쓰기 집약 DB
분석: 별도 데이터 웨어하우스 (BI용)

PoC 수행 방법론

성능 검증 단계

부하 생성: YCSB, HammerDB로 실제 워크로드 시뮬레이션
지연시간 측정: P50, P95, P99, P99.9 지연시간 분포 확인
처리량 테스트: 목표 TPS에서 안정적 동작 검증
장애 시나리오: 노드 장애, 네트워크 파티션 대응 테스트
확장성 검증: 노드 추가/제거 시 성능 변화 측정

비교 평가 매트릭스

평가 항목	ScyllaDB	CockroachDB	TiDB	Aurora	가중치
쓰기 성능	9/10	8/10	7/10	6/10	30%
강한 일관성	7/10	10/10	9/10	9/10	25%
운영 복잡성	6/10	7/10	7/10	9/10	20%
확장성	10/10	9/10	9/10	7/10	15%
생태계/지원	6/10	8/10	7/10	10/10	10%

마이그레이션 전략과 위험 완화

단계별 마이그레이션 접근법

평가 단계: 현재 시스템 분석, 목표 아키텍처 정의
파일럿: 비핵심 서비스로 소규모 검증
이중 쓰기: 신구 시스템 동시 쓰기로 검증 기간
읽기 전환: 점진적으로 읽기 트래픽 이전
완전 전환: 모든 트래픽 신규 시스템 이전

위험 완화 방안

롤백 계획: 각 단계별 명확한 롤백 절차
데이터 검증: 실시간 데이터 일치성 모니터링
성능 벤치마크: 마이그레이션 전후 성능 비교
부하 테스트: 프로덕션 수준 부하에서 검증

최종 추천: Write-Heavy 환경 최적 아키텍처

100만+ TPS 목표 시스템

1순위 추천: ScyllaDB + Redis 조합

Primary DB: ScyllaDB cluster (8-16 nodes)
- 검증된 700만+ TPS 성능
- LSM-tree 최적화로 쓰기 증폭 최소화
- C++ 구현으로 GC 오버헤드 제거

Cache Layer: Redis Cluster
- Write-behind 캐싱으로 쓰기 지연시간 단축
- 세션, 카트 데이터 고속 처리

Load Balancer: Nginx + consistent hashing
- 커넥션 풀링과 지능형 라우팅
- 헬스 체크와 자동 장애조치

하드웨어 구성 (노드당)

CPU: 32-48 코어 (2.5-3.5GHz)
메모리: 256-512GB DDR5
스토리지: NVMe SSD RAID 10 (4-8TB)
네트워크: 25-100 Gbps

10만-50만 TPS 목표 시스템

2순위 추천: CockroachDB 분산 배포

Primary: CockroachDB cluster (3-5 nodes per region)
- PostgreSQL 호환성으로 기존 애플리케이션 호환
- 자동 샤딩과 리밸런싱
- 검증된 168만 tpmC 성능

Replication: Multi-region with Raft
- RPO 근사 0, RTO 2-5분
- 지역별 읽기 성능 최적화

비용 최적화 접근법

하이브리드 아키텍처

쓰기 집약 워크로드: 온프레미스 고성능 서버 (예측 가능한 부하)
읽기 및 분석: 클라우드 관리형 서비스 (탄력적 확장)
재해 복구: 클라우드 기반 백업 및 DR 시스템

리소스 최적화

컴퓨트: 피크 시간대에 맞춘 오토스케일링
스토리지: 계층화 (Hot: NVMe, Warm: SATA, Cold: HDD)
네트워크: 전용 회선으로 데이터 전송 비용 절감

이 가이드를 통해 초당 수십만 TPS를 안정적으로 처리하면서 강한 일관성을 보장하는 write-heavy 시스템을 구축할 수 있습니다. 핵심은 LSM-tree 기반 데이터베이스 선택, 적절한 하드웨어 구성, 그리고 단계적 마이그레이션을 통한 위험 관리입니다.

GPT 4.5 딥 리서치

MMO 게임 환경을 위한 DBMS 성능 및 특성 비교 분석

초당 수십만 건의 쓰기가 발생하고 강한 정합성을 요구하며, 99.9999% (6-nine) 수준의 고가용성이 필요한 MMO 게임 환경에서는 **데이터베이스 관리 시스템(DBMS)**의 선택이 매우 중요합니다. 이러한 극한 환경에 적합한 DBMS를 선정하기 위해, 아래와 같은 주요 평가 기준에 따라 후보군을 비교 분석합니다: • 멀티스레딩/멀티코어 활용 능력: 현대 DBMS가 다중 CPU 코어를 얼마나 효율적으로 활용하여 병렬 처리를 수행하는지 • I/O 처리 성능: WAL(Write-Ahead Logging) 구조 및 SSD 최적화 등 디스크 I/O 성능 최적화 기술 • 서버당 자원 활용률: CPU, 메모리, 디스크 I/O 자원을 최대한 활용하는지 여부 • 쓰기 성능: 초당 쓰기 처리량 및 대기시간 등 쓰기 집중 워크로드에서의 성능 • 클러스터링 및 분산 아키텍처: 공유-Nothing 구조 등 분산 확장을 지원하는지, 어떤 방식으로 클러스터링을 구현하는지 • 고가용성(HA) 옵션과 복구 시간: 장애 발생 시 장애 조치(Fail-over) 메커니즘, RTO(복구 시간)와 RPO(복구 시 데이터 손실)의 수준 • 데이터 정합성 모델: 강한 정합성(Strong Consistency) 보장 여부 및 트랜잭션 일관성 모델 • 커뮤니티 및 상용 지원: 오픈소스 커뮤니티의 활발함, 상용 기술지원 또는 클라우드 서비스 지원 여부

아래에서는 후보 DBMS인 PostgreSQL(Citus/Patroni), MySQL(InnoDB Cluster/Galera), Amazon Aurora, CockroachDB, YugabyteDB, FoundationDB, ScyllaDB, MongoDB, Google Spanner를 이들 기준으로 하나씩 살펴본 후, 분산 시스템 기반 vs. 단일 고성능 서버 기반 아키텍처의 장단점과 MMO 게임에서의 실무 적용 사례를 분석합니다. 각 DBMS에 대해 공식 문서나 업계 벤치마크, 활용 사례를 인용하여 근거를 제시합니다.

PostgreSQL (Citus 및 Patroni 활용)

PostgreSQL은 전통적인 관계형 DBMS로서 ACID 특성과 강한 데이터 정합성을 제공합니다. 기본적으로 단일 노드 성능이 우수하며, 확장성과 고가용성을 위해 **Citus (분산 확장)**나 Patroni (자동 장애조치) 같은 오픈소스 솔루션과 조합해 사용할 수 있습니다. • 멀티스레딩/멀티코어 활용: PostgreSQL 본체는 프로세스 당 하나의 스레드 모델을 사용하지만, 병렬 쿼리 기능과 BGW(Background Worker) 등을 통해 멀티코어를 활용할 수 있습니다. 여러 연결을 여러 CPU 코어에서 병렬로 처리하며, 최근 버전들은 인덱스 빌드나 집계 쿼리에 다중 워커 프로세스를 활용함으로써 멀티코어 효율을 높였습니다. 다만 단일 쿼리의 처리 분할은 제한적이어서, 대규모 병렬 처리는 Citus와 같은 확장 모듈에 의존하기도 합니다. • I/O 처리 성능: PostgreSQL은 WAL(Write-Ahead Log)을 통한 안정적인 트랜잭션 처리를 하며, **그룹 커밋(group commit)**과 플러시 최적화 등으로 SSD I/O를 효율적으로 사용합니다. WAL을 순차적으로 기록하여 디스크 쓰기 병목을 줄이고, 체크포인트와 bgwriter 튜닝으로 쓰기 부하를 제어할 수 있습니다. PostgreSQL 13+ 버전에서는 wal_sync_method 등 매개변수를 통해 NVMe SSD 환경에서의 I/O 성능 향상이 보고되었습니다. • 서버당 자원 활용률: PostgreSQL은 **공유 버퍼(shared buffers)**를 통해 메모리 캐시를 활용하고, OS 커널의 페이지 캐시와 함께 이중 캐싱이 일어날 수 있습니다. 커넥션 당 프로세스 모델로 인해 매우 많은 동시 접속 시 오버헤드가 증가할 수 있으나, PGBouncer 같은 커넥션 풀러로 이를 완화합니다. CPU 활용 측면에서는 각 프로세스가 한 코어에서 실행되므로, 수백 개 이상의 세션이 있을 때 모든 코어를 활용하게 됩니다. 다만, 스핀락 경합 등의 오버헤드로 인해 CPU 100% 사용률에 도달하기 전에 성능 한계가 올 수 있습니다. • 쓰기 성능: 단일 PostgreSQL 인스턴스는 튜닝과 하드웨어에 따라 초당 수만 건 이상의 트랜잭션도 처리 가능하지만, 작성 양이 매우 높을 경우 I/O 대역폭과 WAL 동기화 지연이 병목이 됩니다. 예를 들어, TPCC 벤치마크 등에서 고사양 서버에서 초당 3~5만 트랜잭션 처리가 보고된 바 있으며, 인덱스를 최소화하고 배치 삽입을 사용할 경우 쓰기 TPS를 더욱 높일 수 있습니다. 수십만 TPS 수준에서는 단일 노드로는 역부족이므로, Citus 확장을 통해 테이블을 샤딩하고 여러 노드에 분산시켜 쓰기 부하를 병렬화할 수 있습니다. • 클러스터링 및 분산 아키텍처: PostgreSQL 자체는 공유-디스크 또는 공유-나싱 형태의 클러스터링을 기본 제공하지 않지만, Citus를 통해 공유-나싱(shard 기반) 분산 DB로 확장할 수 있습니다. Citus는 여러 PostgreSQL 노드에 데이터를 샤딩하고, 코디네이터 노드가 분산 쿼리를 처리하는 방식으로 수평 확장을 지원합니다. 이를 통해 노드 수에 비례하는 읽기/쓰기 스케일 아웃이 가능하며, 많은 MMO 게임사가 파티션 키(예: 월드 ID, 사용자 ID 등)를 기준으로 데이터를 분산해 부하를 줄입니다. 한편, Patroni는 다중 노드 간 마스터-슬레이브(주-대기 노드) 구성에서 자동 장애 감지를 통해 새 마스터를 선출하는 HA 솔루션으로, etcd/zookeeper 등을 이용해 분산 락으로 장애조치를 조정합니다. Patroni를 쓰면 액티브-스탠바이 구성을 손쉽게 구축해 단일 노드 기반이지만 빠른 Fail-over가 가능한 아키텍처를 구현할 수 있습니다. • 고가용성(HA): PostgreSQL은 기본적으로 스트리밍 복제를 통해 하나 이상의 스탠바이 서버로 비동기 또는 동기 복제를 지원합니다. 비동기 복제에서는 RPO가 약간 존재하지만 성능이 좋고, 동기 복제에서는 1대 이상의 스탠바이가 WAL 기록을 수신 확인해야 커밋을 완료하므로 RPO=0(무손실)을 달성할 수 있습니다. Patroni와 같은 솔루션을 사용하면 마스터 장애 시 수 초 내에 자동으로 스탠바이를 승격하여 서비스 중단을 최소화할 수 있습니다. 일반적으로 Patroni 구성에서 RTO는 수십 초 이내로 보고되며, 외부 가용성 도메인(예: 쿠버네티스나 VM 장애)을 고려하면 99.99% 수준의 가용성을 달성할 수 있습니다. 다만, 99.9999% (연간 약 30초 이하 다운타임) 달성은 단일 데이터센터 내 구성으로는 어려우며, 다중 AZ 또는 다중 지역 Active-Active 구성이 요구됩니다. PostgreSQL은 기본적으로 멀티마스터를 지원하지 않으므로, 한 번에 하나의 노드만 쓰기를 담당하여 장애조치 시 짧은 재시작 시간이 불가피합니다. • 데이터 정합성 모델: PostgreSQL은 ACID 트랜잭션과 강한 정합성을 제공하며, 직렬화 가능 격리(serializable) 수준까지 지원합니다. 단일 노드에서는 엄격한 일관성이 유지되며, Citus 분산 모드에서도 분산 트랜잭션을 2PC(2-phase commit)로 처리하여 원자성과 일관성을 보장합니다. 다만 분산 트랜잭션의 경우 성능 저하와 코디네이터 노드의 부담이 있으므로, 애플리케이션에서 샤드 키 기반으로 트랜잭션을 국소화하는 것이 좋습니다. 정합성 측면에서 PostgreSQL은 즉시 일관성을 가지며, 복제본에 대한 읽기는 기본적으로 지연이 있을 수 있어 최신성을 확보하려면 synchronous_commit 설정을 조정해야 합니다. • 커뮤니티 및 상용 지원: PostgreSQL은 오픈소스 커뮤니티가 매우 활발하며 전 세계적으로 많이 사용됩니다. 커뮤니티를 통한 정보 공유, 확장 모듈(Citus 등) 기여가 활발하고, 기업 차원의 지원으로는 EDB 등의 업체가 상용 기술지원을 제공합니다. 클라우드에서는 AWS RDS, Azure DB for PostgreSQL (Citus 포함한 Hyperscale 옵션) 등으로 관리형 서비스를 이용할 수 있습니다. 사례로, 국내외 게임사들도 운영 DB로 PostgreSQL을 채택하는 경우가 많으며, 예를 들어 넥슨의 일부 게임에서 사용자 데이터 저장에 PostgreSQL을 활용한 바 있습니다. (또한 Epic Games의 Fortnite나 Ubisoft 등의 일부 서비스에 PostgreSQL 사용 보고가 있지만, MMO 핵심 로직보다는 보조 시스템에 사용되곤 합니다.)

MySQL (InnoDB Cluster 또는 Galera Cluster)

MySQL은 PostgreSQL과 함께 오래된 상용/오픈소스 RDBMS로, 경량화된 아키텍처와 널리 검증된 성능을 지닙니다. MMO 게임에서 전통적으로 많이 사용되어 온 DBMS이며, **InnoDB Cluster(MySQL Group Replication)**나 Galera Cluster(MariaDB/Percona XtraDB Cluster의 기반)을 통해 고가용성과 일종의 멀티마스터 구성을 구현할 수 있습니다. • 멀티스레딩/멀티코어 활용: MySQL (특히 InnoDB 엔진)은 스레드 기반 아키텍처로, 하나의 인스턴스가 내부적으로 클라이언트 커넥션마다 스레드를 생성해 병렬 처리를 합니다. InnoDB는 내부에 여러 버퍼 풀 및 쓰레드 풀을 가지며, 8.0 기준으로 성능 스케일링이 과거보다 향상되었습니다. InnoDB의 행 수준 잠금과 MVCC로 인해, 다중 코어에서 동시 커밋을 지원하고, 8.x 버전에서는 리두 로그 및 정렬 병합(sort-merge) 등 작업에서 멀티스레드 최적화를 이루었습니다. 다만 Global Lock이나 일관성 유지 메커니즘으로 인해 매우 높은 동시 쓰기 시에 스레드 경합이 발생할 수 있습니다. • I/O 처리 성능: MySQL InnoDB는 WAL에 해당하는 **리두 로그(redo log)**를 가지고 있어, 변경 내용을 순차적으로 기록합니다. Aurora를 제외한 일반 MySQL에서는 리두 로그 파일에 쓰기 시 매 1초마다 디스크 flush 또는 트랜잭션 커밋 시 flush 옵션을 선택할 수 있습니다. InnoDB는 SSD 최적화를 위해 병렬 I/O, 리두 로그 버퍼 등을 활용하며, DB 버퍼 풀에서 주로 메모리 내 연산을 하고 백그라운드로 디스크 반영(checkpoint)합니다. 또한, doublewrite 버퍼를 통해 부분 쓰기 방지 등 안정성을 높이지만 그만큼 추가 I/O가 발생합니다. WAL 사이즈 및 flush 주기를 튜닝함으로써 초당 수만 건 이상의 I/O를 처리하도록 설정할 수 있습니다. • 서버당 자원 활용률: InnoDB 엔진은 버퍼 풀을 통해 메모리를 적극 활용하며 (일반적으로 가용 메모리의 7080%를 버퍼 풀로 할당), 나머지 자원으로 다양한 캐시와 정렬 공간을 활용합니다. CPU 활용 측면에서는 스레드 풀을 통해 수백수천 동시 세션까지 비교적 효율적으로 확장하며, 컴팩션이나 purge와 같은 백그라운드 작업도 멀티코어로 병렬 처리합니다. 디스크의 경우, random write를 줄이고 순차 쓰기를 늘리는 기법(WAL)이 있어 고속의 NVMe SSD에서 약 90% 이상의 IOPS를 활용하도록 튜닝할 수 있다는 보고도 있습니다. Galera의 경우, 트랜잭션 복제 처리에 추가 CPU 사용이 있지만, 전체 자원 사용률은 노드 단일로 볼 때 MySQL과 유사합니다. • 쓰기 성능: MySQL 단일 서버의 쓰기 성능은 PostgreSQL과 유사하거나 경우에 따라 더 높은 TPS를 보이는 것으로 알려져 있습니다. 단일 MySQL 인스턴스가 초당 수만 건의 INSERT/UPDATE를 처리한 사례가 다수 있으며, 예를 들어 sysbench OLTP 쓰기 테스트에서 고성능 서버로 5~10만 TPS까지 도달한 벤치마크가 있습니다. 하지만 **InnoDB Cluster(Group Replication)**나 Galera Cluster를 사용하여 멀티마스터 비슷한 구성을 취하면, 모든 노드에 트랜잭션을 동기 적용해야 하므로 쓰기 지연이 증가하고 전체 쓰기 처리량이 단일 노드 대비 크게 증가하지는 않습니다. Galera의 경우 트랜잭션을 커밋할 때 동기 브로드캐스트(모든 노드에 전파) 및 **확인 절차(certification)**를 거쳐야 하며, 이로 인해 한 노드의 쓰기 성능이 100%라면, 3노드 클러스터의 전체 처리량도 1노드 수준에서 머무르거나 오버헤드로 약간 감소하는 경향이 있습니다. 따라서 MySQL 계열로 수십만 TPS를 처리하려면 **파티셔닝(sharding)**으로 여러 클러스터에 부하를 분산하는 방식을 병행해야 합니다 (예: 사용자 그룹별 별도 DB 클러스터). • 클러스터링 및 분산 아키텍처: MySQL은 본래 단일 마스터-다중 슬레이브 복제를 기본 제공하여, 읽기 부하는 분산 가능하지만 쓰기는 단일 지점에서 이루어집니다. **InnoDB Cluster(MySQL Group Replication)**는 MySQL 공식 기능으로, 내부에 Paxos 계열의 그룹 통신 프로토콜을 이용해 멀티-프라이머리(다중 작성자) 모드 또는 싱글 프라이머리 모드에서 동기 식으로 트랜잭션을 전파합니다. Galera Cluster는 별도 라이브러리(wsrep API)를 통해 MySQL(MariaDB)를 멀티마스터로 구성하는 솔루션으로, 공유-나싱 방식의 완전한 대칭 노드 구성을 가집니다. 두 방식 모두 노드들이 전체 데이터의 완전 복제(full copy)를 유지하므로, 노드를 추가해도 용량 증설 외에 쓰기 처리량 자체가 선형 증가하지는 않습니다. 분산 아키텍처 측면에서 MySQL은 Sharding 기능을 내부적으로 제공하지 않기에, 애플리케이션 레벨에서 샤딩을 구현하거나 ProxySQL, Vitess 등의 도구를 사용해야 합니다. (Vitess는 YouTube가 개발한 MySQL 샤딩 프레임워크로, 대규모 분산 MySQL 클러스터 운용 사례가 있습니다.) • 고가용성(HA): MySQL은 전통적으로 마스터-슬레이브 복제에서 수동 페일오버를 해왔으나, InnoDB Cluster나 MHA 등의 도구로 자동 장애조치를 구현할 수 있습니다. InnoDB Cluster에서는 그룹 내에서 **자동 선출(election)**을 통해 프라이머리 노드 장애 시 다른 노드가 승격되어 쓰기를 이어받습니다. 이때 RPO는 기본적으로 0 (트랜잭션이 다수 노드에 커밋된 후 확인)이며, RTO는 수 초 내지 수십 초 수준으로, 네트워크 타임아웃과 선출 알고리즘에 좌우됩니다. Galera의 경우 모든 노드가 동등하게 작성 가능하므로, 하나의 노드가 다운되어도 클라이언트가 남은 노드에 접속하여 쓰기를 지속할 수 있습니다 (단, 장애 노드에 있었던 미커밋 트랜잭션은 상관없이 다른 노드에 반영됨). Galera의 RPO는 0이며, RTO는 사실상 즉시(클라이언트 측에서 연결을 다른 노드로 바꾸는 시간)입니다. 다만 노드 장애 후 해당 노드를 클러스터에 복구(재가입)하는 시간이 몇 분 소요되고, 그 동안은 노드 수 감소로 인해 쓰기 성능이 약간 영향받을 수 있습니다. MySQL의 클라우드 서비스 중 Amazon Aurora MySQL은 추가적인 복제 지연 없이 6중 복제로 HA를 구현하므로, 장애 조치 시 수 초 내로 새로운 writer 인스턴스를 승격하며 투명한 재시작을 지원합니다. • 데이터 정합성 모델: MySQL(InnoDB)은 ACID와 Repeatable Read 격리 수준(기본값)을 제공하며, InnoDB Cluster/Galera를 사용할 경우 격리 수준이 사실상 극대화됩니다. Galera 클러스터는 wsrep_sync_wait 등의 설정으로 선행 커밋된 데이터에 대한 선행 읽기(read-after-write)를 보장할 수 있고, 그룹 내 트랜잭션 순서를 총 일관하게 맞추기 때문에 강한 정합성에 가까운 동작을 합니다. 그러나 네트워크 파티션 등 특별한 상황에서는 일부 노드가 쿼럼을 상실할 수 있어 가용성을 택하면 정합성이 떨어지는 상황이 발생할 수 있습니다 (Galera는 기본적으로 카페베리안(CAP) 이론에서 CP 쪽 성향). InnoDB Cluster(Group Replication)도 트랜잭션이 과반수 노드에 적용되어야 커밋으로 확정되므로, 일관성은 보장되지만 그 전까지는 지연이 추가됩니다. 전반적으로 MySQL은 단일 노드로 사용할 때는 강력한 일관성, 멀티마스터 클러스터로 사용할 때는 트랜잭션 충돌에 유의해야 하지만, 충돌이 없을 경우 각 노드 상태는 동일하게 유지되는 강한 최종적 일관성을 제공합니다. • 커뮤니티 및 상용 지원: MySQL은 전 세계적으로 가장 널리 쓰이는 오픈소스 RDBMS 중 하나로, 커뮤니티 지원이 활발하며 레퍼런스와 튜토리얼이 풍부합니다. 오라클에서 상용 지원을 제공하고 있고, Percona, MariaDB 등 파생 버전도 있어 생태계가 큽니다. Galera는 Codership사에서 개발하여 Percona XtraDB Cluster 등에 포함되어 있으며, MariaDB Galera Cluster로도 배포됩니다. 상용 지원은 각 벤더(Oracle, Percona, MariaDB)에서 받을 수 있습니다. 게임 분야의 적용 사례로, 국내 모바일 게임 다수가 MySQL을 백엔드 DB로 사용해왔고, 예를 들어 넷마블의 일부 게임 서버는 MySQL 샤딩 구조로 사용자 데이터를 분산 저장한 바 있습니다. 또한 **스퀘어 에닉스(Square Enix)**는 자사 게임에서 Vitess를 활용한 MySQL 샤딩으로 글로벌 서비스 확장성 문제를 해결한 사례가 있습니다.

Amazon Aurora (MySQL/PostgreSQL 호환)

Amazon Aurora는 AWS에서 제공하는 관리형 RDBMS로, MySQL 또는 PostgreSQL과 호환되는 인터페이스를 제공하면서, 클라우드 네이티브 아키텍처로 성능과 가용성을 향상시킨 제품입니다. MMO 게임을 포함한 많은 대규모 웹 서비스에서 Aurora를 사용하고 있으며, AWS에 최적화된 기능으로 고성능과 고가용성을 달성합니다. • 멀티스레딩/멀티코어 활용: Aurora 자체는 MySQL(또는 PostgreSQL) 엔진의 상위 호환으로, 기본적인 멀티코어 활용은 해당 엔진과 유사합니다. 다만 AWS에서 인스턴스 타입에 따라 수십 vCPU까지 지원하므로, 대용량 인스턴스에서 멀티스레딩 이점을 크게 누릴 수 있습니다. Aurora의 아키텍처는 DB 엔진 노드에서는 스토리지 I/O를 최소화하고 어플리케이션 로직 실행에 집중하도록 설계되어, 동일한 vCPU에서 MySQL 대비 더 많은 쿼리 처리에 주력할 수 있습니다. • I/O 처리 성능: Aurora가 뛰어난 핵심 이유 중 하나는 스토리지 계층 분리입니다. Aurora는 6-way 분산 스토리지 (데이터를 3개 AZ에 각각 2개씩 총 6부 복제) 구조를 사용하고, 데이터베이스 엔진에서는 WAL 기록만 네트워크로 전송하고 실제 데이터 쓰기는 스토리지 노드가 담당합니다. 즉, DB 인스턴스가 데이터 파일을 직접 flush하지 않고, Redo 로그를 스토리지 계층에 보내면 저장소에서 이를 받아 각 복제본에 기록 및 병합합니다. 이를 통해 디스크 I/O 지연을 줄이고 저지연 커밋을 달성했습니다. 또한 Aurora 스토리지 노드는 SSD에 최적화된 분산 로그 구조를 사용하여, 랜덤 쓰기를 순차 로그 쓰기로 변환하고, 동시다발적 I/O 처리량을 향상시켰습니다. 이러한 설계 덕분에 AWS는 Aurora MySQL은 일반 MySQL 대비 최대 5배 성능을 낼 수 있다고 홍보하고 있습니다. • 서버당 자원 활용률: Aurora는 AWS에서 관리하기 때문에 세부 자원 튜닝은 자동화되어 있지만, DB 인스턴스의 메모리는 주로 버퍼 캐시로 활용되고 CPU는 쿼리 처리에 전적으로 사용됩니다. Aurora 엔진은 MySQL/InnoDB 기반으로 버퍼풀 관리 등을 수행하지만, 읽기 작업의 상당수를 스토리지 계층이 담당하므로, 버퍼 적중률이 낮아도 I/O 병목이 상대적으로 적습니다. 이로 인해 CPU를 보다 쿼리 실행에 사용할 수 있고, **자원당 처리량(Throughput per vCPU)**이 향상됩니다. Aurora는 확장면에서도 최대 128TB까지 단일 데이터베이스를 확장할 수 있고, 복제본 최대 15개까지 추가하여 읽기 처리 자원을 수평 확장할 수 있습니다. • 쓰기 성능: AWS에 따르면 Aurora MySQL의 쓰기 처리량은 동일 하드웨어의 MySQL 대비 5배에 달하며, Aurora PostgreSQL도 원판 PostgreSQL 대비 약 2~3배 성능 향상이 보고되었습니다. 예를 들어, Sysbench OLTP에서 최대 초당 150,000 트랜잭션을 달성한 벤치마크 사례가 있습니다. Aurora의 뛰어난 쓰기 성능은 앞서 언급한 Redo 로그 비동기 처리와 병렬 커밋 기술 덕분입니다. 여러 쓰기 트랜잭션이 동시에 커밋될 때 Aurora 엔진은 병렬로 로그를 전송하고, 스토리지에서 과반수 복제본에 기록되면 즉시 커밋 승인을 하는 최적화가 있습니다. 다만, Aurora는 기본적으로 싱글 프라이머리 구조(하나의 Writer 인스턴스)로 동작하므로, 단일 클러스터 내에서 쓰기 스케일 아웃이 제한됩니다. (Aurora Multi-Master 모드가 존재하나 제약과 복잡도가 있어 널리 사용되지는 않음.) 따라서 초당 수십만 건보다 많은 쓰기가 필요하면 DB를 세로 분할하여 여러 Aurora 클러스터로 구성하는 샤딩 전략이 필요할 수 있습니다. • 클러스터링 및 분산 아키텍처: Aurora는 내부적으로 분산 스토리지를 사용하지만, 사용자에게는 하나의 논리적 데이터베이스로 보입니다. 일반적으로 하나의 Writer와 다수 Reader 인스턴스로 Shared Storage 구조를 취합니다. 각 인스턴스는 동일한 스토리지 계층을 공유하여 데이터 일관성을 유지하고, 새로운 Read Replica를 추가하면 10여 초 내에 동일 스토리지를 마운트하여 바로 데이터에 접근할 수 있습니다. 이는 Aurora가 Shared Disk + Shared Nothing 혼합 구조로, 저장소는 공유되나 컴퓨팅 노드는 독립적입니다. Aurora Multi-Master의 경우, 동일 테이블에 대한 동시 쓰기를 조정하기 위해 분산 락 관리 등이 필요하며, 아직 성숙도나 성능 면에서 단일 Writer 구성보다 제약이 있습니다. Aurora는 Region 단위 복제(Global Database)를 지원하여 다중 리전간 데이터 복제를 제공하지만, 주로 읽기 전용 목적으로 쓰이며, 여러 리전에 동시 writable한 활성-활성(Active-Active)은 지원하지 않습니다 (2025년 초 현재). • 고가용성(HA): Aurora의 가장 큰 장점 중 하나는 내장된 고가용성입니다. 6중 복제된 스토리지 덕분에, 하나의 AZ(가용영역)에 장애가 발생해도 데이터가 유실되지 않고 지속성이 유지됩니다. Writer 인스턴스 장애 시에는 자동으로 Fail-over하여 남은 Reader 중 하나를 새로운 Writer로 승격하는데, 이 과정이 30초 이내로 완료되는 것이 일반적입니다. AWS는 Aurora의 Multi-AZ 배포에 대해 99.99% 가용성 SLA를 제공합니다. RPO 측면에서는, 트랜잭션이 커밋되면 최소 4/6개 스토리지 노드에 기록되므로, RPO=0 (데이터 손실 없는 장애복구)을 구현합니다. 또한 Aurora는 Crash Safe하도록 설계되어, 장애 후 수초 내에 인스턴스 재시작 없이도 스토리지에서 즉시 복구를 완료하고 서비스를 재개합니다. 이러한 특성으로 MMO 게임에서 Aurora를 사용하면 DB 장애로 인한 다운타임을 최소화할 수 있습니다. • 데이터 정합성 모델: Aurora는 기본적으로 MySQL(InnoDB) 또는 PostgreSQL 엔진의 ACID 특성을 그대로 가지므로, 강한 정합성과 트랜잭션 일관성을 유지합니다. Aurora에서 복제본으로 읽기를 할 경우, Reader 노드가 공유 스토리지의 최신 데이터를 거의 실시간으로 제공하므로 지연이 매우 짧지만, 완벽한 동기식 읽기는 아니므로 수 밀리초 수준의 replica lag는 있을 수 있습니다. 하지만 동일 AZ 내에선 평균 20ms 이내의 지연으로 Read-after-Write가 가능하다고 알려져 있습니다. 애플리케이션에서 강한 정합성이 중요할 경우 세션을 Writer에 고정하거나, 또는 aurora_read_replica_read_consistency 파라미터를 조정하여 최근 커밋된 트랜잭션만 읽도록 할 수 있습니다. 요약하면, Aurora는 단일 클러스터 내에서는 강한 정합성을 제공하고, 리전 간 복제시엔 약간의 eventual consistency (DynamoDB 같은 NoSQL보다는 훨씬 짧은 지연) 특성을 보입니다. • 커뮤니티 및 상용 지원: Aurora는 상용 서비스이므로 AWS의 공식 지원을 받으며, 전 세계 수많은 기업이 사용하고 있습니다. 커뮤니티보다는 AWS의 문서와 Best Practice가 주요 정보원입니다. Aurora는 특히 게임, 금융 분야의 고객 사례가 많으며, 예를 들어 닌텐도가 일부 게임의 백엔드로 Aurora를 사용했고, 모바일 MMORPG를 서비스하는 몇몇 국내 업체들도 RDS Aurora로 DB를 운영 중입니다. 다만 AWS 종속 서비스이므로, 멀티클라우드나 온프레미스에는 사용할 수 없고, 벤더 락인에 유의해야 합니다.

CockroachDB

CockroachDB는 NewSQL 계열의 분산 RDBMS로, Google Spanner의 디자인을 참고하여 개발된 오픈소스 프로젝트입니다. 이름처럼 바퀴벌레처럼 견고하고 자동으로 복제/복구되는 특성이 강점입니다. ANSI SQL을 지원하며, ACID 트랜잭션과 강한 정합성을 제공하면서 노드를 추가하여 수평 확장할 수 있어 MMO 게임의 전역 데이터베이스로 부상하고 있습니다. • 멀티스레딩/멀티코어 활용: CockroachDB는 Go 언어로 작성되었으며, 내부에 멀티스레드 아키텍처를 갖추고 있습니다. 단일 노드 내에서 다중 요청을 동시 처리하도록 고루틴을 활용하고, Raft 복제 및 SQL 실행 파이프라인 등도 비동기로 병렬 처리됩니다. 또한 컴퓨터 클러스터 전체에 부하를 분산하므로, 전체 시스템적으로 다중 노드의 모든 코어를 활용하여 성능을 높입니다. CockroachDB 21.x 버전 이후로 TPC-C 벤치마크에서 코어 수 증가에 따라 거의 선형적으로 처리량이 증가하는 모습을 보였으며, 이는 멀티코어 환경에서 잘 확장됨을 의미합니다. • I/O 처리 성능: CockroachDB는 LSM 트리 기반의 RocksDB(최신 버전은 Pebble이라는 RocksDB-compatible 엔진) 스토리지를 사용하여, 작은 쓰기에도 최적화된 성능을 냅니다. WAL에 해당하는 Raft 로그와 KV 저장을 위해 LSM 구조를 사용함으로써, 랜덤 쓰기를 순차적 로그 기록과 배치 씀으로 최적화합니다. 또한 압축(Compaction) 작업이 백그라운드에서 일어나 데이터 파일을 병합/정리하며, SSD의 쓰기 성능을 유지합니다. 메모리 측면에서는 RocksDB의 블록 캐시와 Raft 레이어의 버퍼를 활용하여, 빈번한 읽기/쓰기를 메모리에서 처리하도록 합니다. CockroachDB는 기본적으로 데이터 3중 복제(기본 설정)를 하므로, 한 번의 쓰기가 내부적으로 3개의 노드에 기록되는데, 이때 동시 복제 쓰기와 파이프라이닝으로 지연을 최소화하고 성능을 높이는 노력을 합니다. 그 결과 CockroachDB는 싱글 노드 성능은 일반 PostgreSQL보다 다소 낮을 수 있으나, 노드를 늘릴 경우 IO 병목 해소와 데이터 분산으로 훨씬 높은 전체 처리량을 보여줍니다. • 서버당 자원 활용률: CockroachDB는 노드 프로세스가 자동으로 자신의 디스크, CPU, 메모리를 관리합니다. CPU 사용은 Go runtime이 관리하므로 필요 시 100%까지 활용하며, 메모리는 KV 캐시로 활용하되, OOM 방지를 위해 노드당 메모리 상한을 설정할 수도 있습니다. 디스크 IOPS는 RocksDB 설정에 따라 크게 활용되며, 노드 하나가 감당하기 힘든 부하는 자동으로 데이터를 스플릿하여 여러 노드로 옮겨 적절히 분산시킵니다. Cockroach Labs에 따르면, 노드당 128개 코어까지 확장 테스트를 진행했고, CPU 활용 효율을 개선하는 작업을 지속하여 대형 머신 자원도 최대한 활용 가능하다고 합니다. 자원 사용률이 높은 대신, 가비지 컬렉션(GC) 및 컴팩션 등으로 일시적인 오버헤드가 생길 수 있으며, 이는 주기 설정으로 튜닝 가능합니다. • 쓰기 성능: CockroachDB는 OLTP 트랜잭션에 최적화되어 있어 짧은 트랜잭션 다수를 병렬로 처리하는데 강합니다. 공식 자료에 따르면, 단일 노드에서 초당 수천~수만 TPS 수준이지만, 노드를 3개, 5개… 수평 확장함에 따라 선형에 가깝게 TPS가 증가하며, 5노드 이상에서는 수십만 TPS까지 도달할 수 있습니다. 예컨대 Cockroach Labs의 2020년 벤치마크에서는 64개 노드(각 16코어) 클러스터에서 TPC-C 100만 tpmC를 돌파하여 분산 SQL DB로서 상용 DB 수준의 성능을 입증했습니다. 쓰기 트랜잭션은 내부적으로 Raft 합의를 거쳐 커밋되므로, 개별 트랜잭션 지연은 네트워크 RTT의 영향을 받습니다. 그러나 지역적으로(동일 데이터센터 내) 클러스터를 구성하면 99%tile 지연이 수십 ms 내로 준수하며, 글로벌 분산 시 TrueTime 없는 대신 클라이언트 타임스탬프와 심층 분산 타임라인 알고리즘으로 지연을 최소화합니다. 정리하면, CockroachDB는 강한 일관성을 유지하면서도 노드 증설로 쓰기 처리량을 높일 수 있지만, 합의로 인한 기본 오버헤드는 MySQL 등의 단일 노드 DB보다 높을 수 있습니다. • 클러스터링 및 분산 아키텍처: CockroachDB의 아키텍처는 Shared-Nothing으로, 모든 노드는 대등하며 데이터는 자동 샤딩됩니다. 키-값 스토어 수준에서 Range(64MiB 단위)의 데이터 청크를 관리하고, 각 Range가 Raft 그룹으로 3개 노드에 복제됩니다. 클러스터는 특정 Range의 리더(leader)를 선출하여 읽기/쓰기를 조율하며, 노드 추가 시 오토 발란싱으로 새로운 노드로 Range를 이동시켜 전체 데이터를 분산시킵니다. 이런 수평 스케일 설계로, 용량과 성능이 노드 수 증가에 따라 증가하고 특정 노드 장애 시 해당 Range의 리더가 다른 복제본으로 자동 승계되어 지속성을 유지합니다. 또한, CockroachDB는 멀티 리전 모드를 지원하여, 테이블 단위로 어떤 칼럼(예: 지역 코드)에 따라 데이터를 각 리전에 우선 배치하고, 해당 지역에서 온 요청은 지연이 낮도록 로컬 복제본에서 처리하는 등의 지리적으로 분산된 최적화를 제공합니다. 이러한 구조는 전세계 플레이어를 갖는 MMO에서 지역별 데이터를 로컬에 저장하면서도 전역 일관성을 유지하는 시나리오에 적합합니다. • 고가용성(HA): CockroachDB는 내재적으로 다중 복제본과 자동 장애 조치를 포함합니다. 한 노드가 다운되면, 그 노드가 리더이던 Raft 그룹들은 수 초 내에 새로운 리더를 선출하고 클라이언트 트랜잭션을 이어서 처리합니다. 노드 장애 시 데이터 손실은 없으며(RPO=0, 과반수 노드에 데이터 존재), 클라이언트도 투명하게 Fail-over가 이뤄집니다. 업그레이드나 재시작도 롤링 업그레이드 방식으로 하나씩 노드를 재시작하여 가용성을 유지할 수 있습니다. Cockroach Labs에서는 CockroachDB를 이용해 **무중단(upgrade)**과 무상태 손실 운영을 강조하고 있으며, 실제 3개 AZ에 클러스터를 구성하면 99.99% 이상의 가용성을 달성할 수 있다고 주장합니다. RTO는 일반적으로 수 초 수준(기본 Raft 타임아웃 3s 등)이며, 네트워크 단절 등 이벤트에도 리더 선출 제한 시간 이후 자동 복구합니다. 다만 완전한 6-nine(99.9999%) 수준을 위해서는 여러 지리적 리전에 걸친 복제 및 리던던시 구성이 필요하며, CockroachDB는 아직 TrueTime 같은 멀티 리전 강일성은 없기에 5-nine 정도의 실질 가용성을 타겟으로 합니다. • 데이터 정합성 모델: CockroachDB는 **강한 정합성(Strong Consistency)**과 직렬화 가능 트랜잭션을 제공합니다. 모든 분산 트랜잭션은 Serializable Isolation을 기본 격리 수준으로 하며, 스키마 변경 등 DDL도 트랜잭션적으로 적용됩니다. Raft 합의를 통해 쓰기 커밋이 이루어지므로, 클라이언트는 성공적으로 커밋 응답을 받으면 그 트랜잭션이 영구적으로 지속되었음을 보장받습니다. 또한 분산 트랜잭션은 2페이즈 커밋 없이도 동작하도록 내부 최적화(단일 키는 단순 Raft, 다중 키는 분산 조정자)가 되어 있습니다. CockroachDB는 내부적으로 **하이브리드 논리적 시계(Hybrid Logical Clock)**를 사용하여, 거의 외부 일관성(External Consistency) 수준의 직렬 일관성을 유지합니다. 이는 Google Spanner의 TrueTime만큼 엄격하지는 않지만, 트랜잭션 타임스탬프 관리로 동시에 수행된 트랜잭션들의 전역 순서를 정합니다. 그 결과, ANSI SERIALIZABLE 수준의 격리를 분산 환경에서 구현하며, *팬아웃 쿼리(여러 Range에 걸친 쿼리)*도 스냅샷 일관성을 유지합니다. CockroachDB는 읽기 작업도 기본적으로 최근 커밋된 데이터만 읽으며, 과거 스냅샷 읽기는 AS OF SYSTEM TIME으로 명시적으로만 가능합니다. • 커뮤니티 및 상용 지원: CockroachDB는 오픈소스로 GitHub 커뮤니티가 있으며, Cockroach Labs에서 적극적으로 개발 및 엔터프라이즈 지원을 제공합니다. 커뮤니티 규모는 PostgreSQL/MySQL보다는 작지만, 분산 SQL 분야에서 선도적인 지위를 가지고 있어 문서와 사용 사례가 늘어나고 있습니다. 상용 버전에서는 성능 진단 툴, 관리 툴 등을 제공하며 CockroachCloud 같은 매니지드 서비스도 있습니다. 산업 적용 사례로는 UBER가 일부 워크로드에 CockroachDB를 사용해 글로벌 라이더 데이터를 관리했고, Comcast 등이 백엔드 시스템에 도입한 사례가 있습니다. 게임 분야에서도, 한 스타트업이 CockroachDB로 전 세계 단일 월드 게임의 사용자 데이터를 운영하여 지역 간 데이터 정합성을 유지한 사례가 발표된 바 있습니다 (예: 실시간 전략 게임의 글로벌 랭킹을 CockroachDB에 일원화하여 관리).

YugabyteDB

YugabyteDB는 오픈소스 분산 SQL DBMS로, Cassandra의 분산 저장 구조와 PostgreSQL의 상위 호환 SQL 인터페이스를 결합한 형태입니다. NewSQL의 일종으로 강한 일관성과 수평 확장을 모두 제공하며, 최근 금융, 게임 분야에서 관심을 받고 있습니다. PostgreSQL 호환 모드(YSQL)와 Cassandra 호환 모드(YCQL)를 동시에 지원하여 유연성이 높습니다. • 멀티스레딩/멀티코어 활용: YugabyteDB는 C++로 구현되어 높은 성능과 멀티코어 활용을 추구합니다. 내부적으로 마스터 노드(메타데이터 관리)와 Tablet 서버 노드(데이터 저장)의 구성으로 나뉘며, 각 Tablet 서버는 다중 스레드로 RPC 핸들링, Raft, 스트로리지 I/O를 처리합니다. 또한 비차단 I/O와 락 프리 데이터 구조 등을 사용하여, 수십수백 코어 환경에서도 선형 성능 확장을 보이도록 설계되었습니다. Yugabyte는 PostgreSQL의 쿼리 레이어를 통합했지만 쿼리 실행도 멀티스레드로 진행되며, 노드간 통신 역시 비동기로 최적화되어 있습니다. 결과적으로, 하나의 노드에서도 멀티코어 CPU를 100% 활용할 수 있고, 노드 추가 시 노드 전체 코어 수만큼 병렬처리 리소스가 증가합니다. • I/O 처리 성능: YugabyteDB의 저장 엔진은 DocDB라는 이름으로, 내부적으로 RocksDB LSM 트리를 사용합니다. 각 Tablet(파티션에 해당)은 RocksDB 인스턴스로 관리되어, 순차 쓰기와 배치처리를 극대화합니다. WAL(리두로그)이 각 Tablet별로 존재하며, 쓰기 시 메모리에 로그 적재 + 복제전송 후 적절 시점에 일괄 디스크 flush합니다. 이러한 LSM 기반 접근은 Cassandra와 유사하여 랜덤 쓰기에서도 높은 처리량을 발휘합니다. Yugabyte는 또한 메모리 내 캐시, 블룸 필터 등을 활용하여 읽기 성능도 최적화하며, SSD에서도 컴팩션 쓰기 증폭을 줄이기 위한 톱니형 compaction 정책을 도입했습니다. 결과적으로, YCSB 벤치마크 등에서 Yugabyte는 Cassandra 대비 읽기/쓰기 모두 우수한 IOPS를 보여주었고, CockroachDB 대비해서도 고속 키-값 처리에 강점이 있다는 보고가 있습니다. 이는 Yugabyte가 분산 트랜잭션을 위해 투명한 커밋 연기(protocol) 외에는 Cassandra 수준의 로우레벨 성능을 유지하기 때문입니다. • 서버당 자원 활용률: YugabyteDB는 데이터 파티셔닝을 통해 개별 노드의 부하를 낮추면서, 각 노드의 자원을 최대한 활용하려 합니다. 각 Tablet 서버 노드는 다수의 Tablet(Raft 그룹으로 동작)을 호스팅하며, 노드의 CPU, 메모리, 디스크 I/O를 가용한 만큼 사용합니다. RocksDB 특성상 디스크 순차 쓰기를 선호하므로, 디스크 대역폭을 꾸준히 활용하고 메모리를 이용해 SSTable 캐시와 로그 버퍼를 최적화합니다. 또한, 노드 장애나 추가 시 자동 리밸런싱으로 각 노드의 데이터와 요청량이 균등해지도록 조정합니다. Yugabyte는 대용량 RAM이 있는 경우 Row cache를 두어 핫 데이터를 메모리에 상주시켜 지연을 최소화할 수도 있습니다. 최대 성능을 내려면 노드 1개당 12개 Tablet 서버 프로세스를 두어 (코디네이터/데이터 분리) 자원 활용을 극대화하라고 권장하고 있습니다. • 쓰기 성능: YugabyteDB는 고속 키-값 쓰기 성능과 분산 트랜잭션 성능을 함께 추구합니다. 한 공개 벤치마크에 따르면, 3노드 YugabyteDB 클러스터가 초당 14만 건 이상의 쓰기(YCSB workload) 처리를 달성하여 CockroachDB보다 다소 높은 쓰루풋을 보였습니다. 특히 단일 키 또는 동일 파티션 내의 쓰기는 Cassandra와 유사하게 매우 빠르며, 다중 파티션 트랜잭션 시에도 지연을 최소화하기 위해 분산 코디네이터와 트랜잭션 기록 테이블을 활용합니다. 분산 트랜잭션의 지연은 일반적으로 5~7ms 수준으로, 하나의 Raft 라운드trip에 준하게 최적화되어 있습니다. 또한 동시성 제어에 있어서, Yugabyte는 PostgreSQL과 동일한 SSI(직렬화가능 스냅쇼트 격리) 기법을 사용하여 충돌을 감지하고 재시도합니다. 초당 수십만 건 쓰기 환경에서도 노드와 파티션을 늘리면 이를 처리할 수 있으며, 실제 Yugabyte는 노드 50개 규모에서 백만 TPS를 넘는 실험 결과를 공개한 바 있습니다. • 클러스터링 및 분산 아키텍처: YugabyteDB의 클러스터는 Master 노드들(메타데이터, 테이블 분할 관리)와 Tablet 서버들(실데이터 저장)로 구성되는 Shared-Nothing 구조입니다. 데이터는 Hash Sharding(YCQL 기본) 또는 범위 Sharding(YSQL에서 키 범위 파티셔닝)으로 자동 분할되어 여러 Tablet에 저장되며, 각 Tablet이 Raft 그룹으로 3중 복제되어 리더 노드를 통해 쓰기를 받아들입니다. 클러스터에 노드를 추가하면 새로운 Tablet이 생성되거나 이동하여 자동 Shard Rebalancing이 일어납니다. 이 아키텍처는 Cassandra의 노드 토큰 분배와 유사하지만, 고정 파티션 개수가 아니라 동적으로 Tablet을 분할하기 때문에 핫스팟을 완화합니다. 또한 Geo-Partitioning 기능을 제공하여, 특정 파티션 데이터를 특정 지역에 상주시키고 해당 지역 노드가 리더가 되게 하여 지연 최적화를 할 수 있습니다 (Spanner의 리전 분할과 유사). YugabyteDB는 멀티-마스터 분산 DB로서 모든 노드가 SQL 질의 처리를 할 수 있으므로, 애플리케이션은 하나의 엔드포인트로 연결하면 내부적으로 분산처리가 됩니다. • 고가용성(HA): YugabyteDB는 Raft 기반 복제로 노드 장애 시 무중단을 지향합니다. 3중 복제시 한 노드 장애는 자동으로 다른 복제본에서 리더 승계가 이루어져 클러스터가 지속 동작합니다. RPO는 0이며, RTO는 보통 1초 내외(Raft 타임아웃)로 매우 짧습니다. Master 노드도 다중화되어 있어 하나의 Master에 문제가 생겨도 다른 Master가 메타데이터 서비스를 이어받습니다. 이러한 구조로, 클러스터 전체로 99.99% 이상의 가용성을 달성할 수 있습니다. 실제로 Yugabyte는 Jepsen 테스트를 통해 네트워크 분단, 노드 크래시 상황에서 일관성 및 내구성 유지를 검증받은 바 있습니다. 다만 다수 노드 동시 장애 등 극한 상황에서는 장애 복구에 시간이 걸릴 수 있으며, 복구시 데이터 재균형에 따른 성능 저하에 유의해야 합니다. 여러 리전에 걸친 배포도 가능하며, 이 경우 한 리전 장애에도 다른 리전이 서비스 지속 (RTO 수초)하고 클라이언트 라이브러리가 가장 가까운 리전에 자동 연결해주는 기능이 있습니다. • 데이터 정합성 모델: YugabyteDB는 강한 정합성을 특징으로 내세웁니다. YSQL(PostgreSQL 호환 모드)에서는 Serializable 수준의 트랜잭션 격리를 지원하여, 분산 환경에서도 직렬화 가능한 ACID 트랜잭션을 제공합니다. 이는 SSI 알고리즘과 Raft 복제를 결합한 것으로, 다중 노드에 걸친 트랜잭션도 직렬 실행한 것과 같은 결과를 보장합니다. YCQL(Cassandra 호환) 모드에서는 단일 테이블의 조건부 업데이트에 한해 경량 트랜잭션(Compare-and-Set) 기능을 제공하고, 일반 작업은 Cassandra와 동일하게 튜너블 일관성(클라이언트가 QUORUM 등 지정)으로 동작합니다. 그러나 YSQL 모드를 사용하면 개발자는 PostgreSQL 사용하듯 BEGIN…COMMIT 트랜잭션을 사용할 수 있고, 내부적으로 필요한 경우 2PC나 지연 쓰기 등을 통해 원자적 커밋을 수행합니다. 결과적으로 YugabyteDB는 NoSQL수준의 분산성과 RDBMS의 정합성을 겸비한 솔루션이라 할 수 있습니다. • 커뮤니티 및 상용 지원: YugabyteDB는 비교적 새로운 프로젝트이지만, GitHub와 Slack 등지에 활발한 커뮤니티가 형성되어 있습니다. 상용적으로는 Yugabyte, Inc.에서 지원과 DBaaS(Yugabyte Cloud)를 제공하고 있습니다. 국내에서도 YugabyteDB를 도입하는 사례가 증가하고 있으며, 예를 들어 NHN에서 금융 시스템에 Yugabyte를 적용하거나, 미국의 Charles Schwab 증권에서 전사 데이터베이스로 채택한 사례가 알려져 있습니다. 게임 분야에서는 아직 CockroachDB나 Cassandra만큼 사례가 많지는 않으나, 전세계 플레이어를 상대하는 소셜 게임 회사들이 YugabyteDB를 글로벌 사용자 데이터 저장소로 POC 진행 중인 것으로 전해집니다. PostgreSQL과 호환되므로, 기존 PostgreSQL 사용 기업들이 분산 확장 필요 시 Yugabyte로 전환을 검토하는 경우도 있습니다.

Google Spanner

Google Spanner는 Google이 내부 사용을 위해 개발한 글로벌 분산 RDBMS로, 현재 Cloud Spanner라는 상품명으로 GCP에서 제공되고 있습니다. TrueTime이라는 분산 글로벌 시계 기술을 활용하여 **외부 일관성(External Consistency)**을 구현한 최초의 상용 DB이며, 전 지구적 데이터 일관성과 5-nine 이상 가용성을 제공하는 것으로 유명합니다. 전형적인 NewSQL의 원형으로 볼 수 있으며, MMO 게임처럼 전세계에 분산된 사용자 트랜잭션을 처리하기에 이상적인 후보입니다. • 멀티스레딩/멀티코어 활용: Spanner는 Google의 Cloud Infrastructure에서 동작하며, 각 노드는 Colossus 파일 시스템과 통신하고, 다수의 세션을 병렬로 처리할 수 있도록 설계되어 있습니다. 구글이 발표한 Spanner 논문에 따르면, Spanner 서버들은 다중 스레드로 Paxos 프로토콜을 실행하고, 다중 쿼리를 병렬로 처리하여 수평 및 수직 확장을 모두 활용합니다. 실제 Cloud Spanner 노드(서버) 하나는 여러 가상 CPU로 구성되며, 쿼리 실행, 복제, 조정자 역할 등을 병렬로 처리합니다. 또한 테이블을 분할하여 Splits 단위로 여러 서버에 분산하므로, 클러스터 전체적으로 볼 때 수백수천 코어가 동원될 수 있습니다. 이러한 대규모 병렬성 덕분에, Spanner는 높은 처리량을 요구하는 워크로드에서도 안정적인 성능을 발휘합니다. • I/O 처리 성능: Spanner의 저장은 Google의 분산 파일 시스템 Colossus 위에 구축되어, SSD/HDD에 최적화된 다중 버전 저장소를 사용합니다. 각 데이터 조각(프래그먼트)은 Paxos 로그로 복제되어 기록되며, 쓰기 지연을 줄이기 위해 병렬 Paxos와 파이프라인 처리를 사용합니다. 또한, Spanner는 로그 구조에 기반한 테이블 스토리지(LevelDB와 유사한 구조)를 사용하여, 많은 양의 쓰기를 효율적으로 지속할 수 있습니다. TrueTime 이용으로 인해 트랜잭션 커밋 시 약간의 지연(일반적으로 7ms 정도)을 추가로 가지지만, 이는 시계 동기화를 통한 외부 일관성 보장을 위한 것입니다. Google 내부 테스트에서, Spanner는 단일 Paxos 그룹 당 수만 QPS의 쓰기를 처리 가능하고, 여러 그룹으로 샤딩 시 거의 선형적으로 증가하는 결과를 보였습니다. 요약하면, Spanner는 전역 분산의 오버헤드를 줄이기 위해 동기 복제를 최대한 최적화하여, WAN 환경에서도 높은 처리량과 지속적인 쓰기 성능을 유지하도록 설계되었습니다. • 서버당 자원 활용률: Cloud Spanner의 노드는 GCP에서 관리되며, 사용자는 몇 노드로 인스턴스를 구성할지 결정합니다. 각 Spanner 노드는 일정한 CPU, 메모리, 스토리지 IO 성능을 약정된 만큼 가지고, 부하에 따라 자동으로 자원 사용을 늘립니다. 예를 들어, Spanner는 1노드당 2,000 QPS의 쓰기, 10,000 QPS의 읽기 성능을 보장하는 것으로 알려져 있으며, 이는 Google이 백엔드에서 해당 자원을 할당함을 뜻합니다. 노드 수를 늘리면 이러한 QPS가 선형 증대하며, 실제로 페타바이트급 데이터도 다수 노드에 분산 저장하여 처리합니다. Spanner는 자동 압축 및 최적화를 수행하여, 사용자는 성능 튜닝보다는 노드 증설과 스키마 설계에 집중할 수 있습니다. 전반적으로, Google Spanner는 Google 내부 인프라를 활용하여 자원당 최대 성능을 끌어내도록 엔지니어링되어 있으며, 특히 네트워크와 디스크 IO 성능을 극대화하고자 전용 광네트워크, 하드웨어 시계 등의 자원을 사용합니다. • 쓰기 성능: Spanner는 분산 트랜잭션을 지원함에도 높은 쓰기 성능을 보여줍니다. 예를 들어, Google은 Spanner로 매일 수십억 건의 광고 트랜잭션을 처리하고 있으며, 초당 수십만 건의 업데이트도 가능한 것으로 알려져 있습니다. Cloud Spanner 공식 문서에 따르면, 스토리지 1TB당 초당 10K20K 수준의 쓰기 처리량을 보여주며, 데이터 분할과 노드 증설로 그 이상도 확장 가능하다고 합니다. Spanner의 쓰기 경로에서는, 리더가 클라이언트 변경을 수신하면 Paxos follower들에게 병렬 전송하고, 대다수가 확인하면 즉시 커밋합니다. 이로 인해 개별 트랜잭션은 전역 합의(RTT) 시간만큼의 지연이 추가되지만, 다수 트랜잭션이 파이프라인으로 겹쳐 처리되어 스루풋은 매우 높게 유지됩니다. 또한 Spanner는 쓰기 작업을 Tablets(샤드) 단위로 분산시키므로, 특정 shard가 bottleneck이 되면 자동으로 더 잘게 분리하여 부하를 나눕니다. 이러한 특성으로, Spanner는 정합성을 유지하는 시스템 중에서는 매우 뛰어난 쓰기 처리량을 자랑하지만, 지연 면에서는 메모리 DB나 Eventually consistent 시스템보다 높을 수밖에 없습니다. • 클러스터링 및 분산 아키텍처: Spanner의 아키텍처는 Multi-Master 분산 SQL입니다. 내부적으로 데이터는 분할(Shard) 되어 Tablet이라 불리는 단위로 관리되고, 각 Tablet은 Paxos 그룹 (최신 버전은 Raft 사용)으로 여러 복제본에 저장됩니다. 보통 5개 복제본 (멀티리전의 경우) 또는 3개 복제본(싱글 리전)을 유지하며, 하나의 리더가 존재합니다. Spanner는 TrueTime API(원자시계 & GPS 기반 시계)로 전역 시간 동기화를 이루고, 이를 통해 분산 트랜잭션의 타임스탬프 순서를 조정합니다. 클라이언트는 Spanner에 쿼리를 보내면, 적절한 Tablet의 리더에게 라우팅되고 그곳에서 읽기/쓰기가 수행됩니다. 만약 쿼리가 다수 shard를 걸치면, 2PC 대신 동시에 Paxos 커밋을 시도하고 TrueTime으로 트랜잭션 완료 시점을 조율하여 직렬성을 보장합니다. Spanner는 전 지구적으로 노드 분포가 가능하며, 개발자는 레플리카 배치 정책을 통해 데이터를 특정 지역에 우선 저장하게 할 수 있습니다. 예를 들어, 글로벌 MMO 게임에서 유럽, 미국, 아시아에 각각 1개씩 복제본을 두고 다수결을 2/3로 하면, 전세계 플레이어 데이터를 하나의 Spanner DB에 넣되 주요 데이터의 리더를 각 지역에 위치시켜 지연을 줄이고, 동시에 전 지구 강한 정합성을 유지할 수 있습니다. • 고가용성(HA): Google Spanner는 99.999% 가용성을 목표로 설계되었습니다. 실제 Google Cloud는 다중 리전 Spanner 인스턴스에 대해 월 가동율 99.999%를 SLA로 제공하며, 이는 연간 약 5분 정도 이하의 다운타임만 허용하는 매우 높은 수치입니다. 이러한 HA는 Paxos/RAFT 합의와 다중 AZ/다중 리전 복제를 통해 이루어집니다. 한 노드나 한 AZ가 완전히 정전되어도, 자동으로 다른 복제본이 리더로 선출되어 서비스를 지속합니다. RPO=0은 Paxos 합의로 보장되고, RTO는 보통 수 초 내지 10초 이하(리더 재선출 시간)에 불과합니다. 또한 Spanner는 Hot Standby 개념이 필요 없이 모든 복제본이 실시간 동기화되므로, 특정 노드 장애시 failover 과정이 거의 무중단으로 진행됩니다. 전체 리전 장애의 경우도, 미리 여러 리전에 복제해두었다면 장애가 발생하지 않은 리전의 복제본들이 계속해서 데이터베이스를 운영합니다. 이렇듯 Spanner는 인프라 레벨에서의 강력한 내결함성으로, MMO 게임과 같은 24/7 서비스에서 요구되는 최고 수준의 가용성을 충족합니다. • 데이터 정합성 모델: Spanner의 가장 두드러진 특징은 **외부 일관성 (External Consistency)**입니다. 이는 분산 시스템에서 일반적인 직렬화가능(Serializable)보다 강력한 보장으로, 전 세계 어떤 순서로 트랜잭션이 완료되었는지를 모두가 합의하는 특성입니다. Spanner는 TrueTime의 시간간격ε를 이용해 트랜잭션 타임스탬프를 지정하고, 모든 트랜잭션을 그 타임스탬프 순서대로 보이게 합니다. 덕분에 분산 트랜잭션에서도 직관적으로 일관성이 유지되어, 예를 들어 한 사용자 계정의 업데이트와 조회가 다른 지역에서 동시에 일어나도, 조회가 항상 업데이트 후의 값을 보게 할 수 있습니다. ANSI SQL 관점에서는 Serializable Isolation을 구현하며, 스냅쇼트 읽기(과거 시점 읽기)도 지원합니다. Spanner에서는 애플리케이션이 특별히 eventual consistency를 신경쓰지 않아도 되지만, 필요 시 **비동기 복제(읽기 전용 복제본)**을 둘 수도 있습니다. 다만 기본 Spanner는 강한 정합성이 기본값이고 대부분 경우 이는 유지됩니다. 정합성 vs 가용성 상황에서 Spanner는 **정합성 우선(CP)**을 택하며, 네트워크 단절 시 쿼럼을 잃은 파티션은 쓰기 가용성을 잃게 됩니다. 이런 엄격한 모델 덕에 개발자는 분산 락이나 충돌 조정을 수동으로 할 필요 없이 RDBMS 다루듯 Spanner를 사용할 수 있습니다. • 커뮤니티 및 상용 지원: Spanner는 Google의 폐쇄형 서비스로, 커뮤니티 오픈소스 버전은 없습니다. 대신 Spanner 논문이 공개된 이후 CockroachDB 등 많은 NewSQL 프로젝트에 영감을 주었고, Cloud Spanner라는 이름으로 Google Cloud에서 상용 서비스 중입니다. Google의 SRE 팀이 24/7 모니터링/운영을 담당하며, SLA 보장을 지원합니다. Spanner는 금융 (JP Morgan 등), IoT, 게임 등 전세계적으로 데이터 일관성과 글로벌 서비스를 요구하는 업계에서 도입 사례가 늘고 있습니다. 포켓몬 고(Pok\u00e9mon Go) 개발사인 Niantic은 초기 인프라로 Google의 Spanner 기반 Datastore를 활용하여 전세계 수억 명의 플레이어 데이터를 처리했고, 이후 Cloud Spanner로 마이그레이션하여 운영을 단순화했습니다. 이처럼 Spanner는 MMO 게임의 계정, 아이템, 월드 상태를 전지구적으로 단일화하려는 시도에 적합하지만, GCP를 사용해야 하고 비용이 높다는 현실적 제한도 있습니다.

FoundationDB

FoundationDB는 특별한 분산 DBMS로, Key-Value 저장소 형태이지만 완벽한 ACID 트랜잭션을 제공하는 것이 특징입니다. 2018년에 Apple이 인수 후 오픈소스로 공개하였으며, 신뢰성과 성능을 위해 철저한 시뮬레이션 테스트를 거치는 안정성이 강조된 시스템입니다. 주로 다른 DB 시스템의 코어로 사용되거나, 멀티모델 (Document, SQL 등)의 기반 계층으로 응용되는 경우가 많습니다. • 멀티스레딩/멀티코어 활용: FoundationDB(FDB)는 기본 프로세스 모델이 싱글 스레드로 동작하도록 설계되었습니다. 각각의 FDB 프로세스는 특정 역할 (코디네이터, 프로키시, 리졸버, 스토리지 등)로 동작하며, 한 프로세스는 한 CPU 코어에서 싱글 스레드로 실행됩니다. 대신 하나의 물리 서버에 여러 FDB 프로세스를 배치하여 멀티코어를 활용합니다. 예를 들어, 16코어 서버라면 16개의 fdbserver 프로세스를 실행시켜 전체 코어를 활용합니다. 이는 락 경합을 최소화하고, 시뮬레이션 테스트의 결정적 재현성을 위해 고안된 방식입니다. 결과적으로 FDB는 멀티코어 활용을 프로세스 수 스케일 아웃으로 해결하며, 각 프로세스가 자체 역할에 충실하게 고성능을 내도록 최적화되어 있습니다. I/O 이벤트 루프는 async/await 패턴으로 동작하기 때문에, 단일 스레드여도 내부적으로 비동기 처리를 통해 효율을 높이고 있습니다. • I/O 처리 성능: FoundationDB의 디스크 저장 방식은 B+트리 기반 (SQLite의 페이지 기반 엔진을 사용했으나, 최근 Redwood라 불리는 새로운 SSD 최적화 엔진을 개발 중)입니다. 키-값 페어를 소팅된 순서로 유지하며, Multiversion Concurrency Control로 인한 버전별 쓰기를 관리합니다. WAL(리두로그)를 사용하며, 트랜잭션 커밋 시 메모리에 기록 후 비동기 flush하고, 일정 주기로 디스크에 반영합니다. 동시에 여러 스토리지 프로세스가 각각 자기 파티션에 쓰기를 수행하므로, 전체적으로 I/O 병렬성이 높습니다. 또한 FDB는 트랜잭션 로그 프로세스를 별도로 운영하여, 모든 커밋 로그를 빠르게 기록하고 필요한 경우 다시 스토리지 노드에 적용합니다. 이 구조는 로그를 빠르게 기록해서 트랜잭션 지연을 줄이고, 실제 디스크 적용은 비동기로 처리함으로써 확장성과 성능을 얻습니다. Apple이 발표한 내용에 따르면 FoundationDB는 단일 클러스터에서 수백만 Ops/sec 처리가 가능하며, 실제 애플 iCloud 서비스에서 핵심 스토리지 엔진으로 쓰일 만큼 높은 성능을 발휘합니다. • 서버당 자원 활용률: FDB 프로세스 각각이 하나의 코어만 사용하므로, 단일 프로세스 관점에서는 CPU 사용이 100%가 될 수 있어도 멀티코어 활용은 여러 프로세스가 필요합니다. 메모리 사용도 프로세스 별로 독립적으로 캐시, 키 범위 등을 저장하므로, 서버의 전체 RAM을 여러 프로세스가 나눠쓰는 형태입니다. FDB는 클러스터 컨피그를 통해 프로세스별 메모리/스토리지 역할 분담을 최적화할 수 있습니다. 예컨대, 8코어 서버에서 4개는 스토리지 프로세스, 2개는 트랜잭션 로그, 1개는 프로키시, 1개는 리졸버 등으로 할당 가능합니다. 디스크는 주로 순차 쓰기가 많이 발생하며, 읽기도 페이지 캐시와 메모리에서 가져오기 때문에 디스크 IO 대역폭을 크게 소모하지 않는 경향이 있습니다 (데이터가 많이 쌓여 페이지 캐시에서 못담으면 random read가 증가). FoundationDB는 단일 키-값 10KB 쓰기 지연 1ms 미만을 추구하도록 최적화되어 있고, 이를 수평으로 스케일하는 방식이어서, 필요시 수십수백 노드를 추가 투입하여 자원 총량을 증대시킵니다. • 쓰기 성능: FoundationDB는 단일 키 당 순차적 쓰기 성능과 동시에 다중 키-값 삽입 성능이 모두 뛰어납니다. 일례로, Snowflake(데이터 웨어하우스 기업)는 FoundationDB를 메타데이터 저장소로 사용하며, 초당 수십만 건 이상의 삽입/갱신을 문제없이 처리하고 있음을 밝혔습니다. FDB의 쓰기는 기본적으로 단일 키 또는 키 범위에 대해서 빠르고, 트랜잭션당 10만개까지 키-값을 원자적으로 갱신 가능하지만, 한 트랜잭션 크기가 너무 크면 성능이 떨어질 수 있습니다. FDB 엔진은 **옵티미스틱 동시성 제어(OCC)**를 사용하여, 커밋 시에만 충돌 검사를 하므로, 짧은 트랜잭션을 매우 빠르게 커밋할 수 있습니다. 덕분에 분산 환경임에도 지연이 수 ms로 낮습니다. 공식 FDB 테스트에서는 32노드 클러스터에서 초당 1400만 개의 키-값 작업을 수행하기도 했습니다. 다만, FDB는 범위 스캔 등 읽기에서는 성능 최적화를 위해 지정된 범위로만 데이터를 읽고, 복잡한 조인은 클라이언트가 처리하게 되어 있어 SQL DB보다는 트랜잭션 키-값 스토어로 이해하는 것이 정확합니다. MMO 게임에서 FDB를 사용할 경우, 단순한 키-값 형태의 데이터 (예: 유저 progress, 인벤토리) 저장에 엄청난 쓰기 성능과 트랜잭션 안전성을 제공할 수 있습니다. • 클러스터링 및 분산 아키텍처: FoundationDB는 Shared-Nothing 클러스터로 동작하며, 각 데이터 조각(Shard)은 키 범위로 정의됩니다. 데이터는 복제를 위해 기본 3개 복제본을 유지하며, 하나의 코디네이터 그룹이 클러스터 구성 및 장애조치를 관리합니다. 클라이언트가 FDB에 트랜잭션을 보내면, 프로키시 프로세스가 이를 받아 트랜잭션 로그에 기록 후, 리졸버가 충돌 체크를 하고, 확정된 커밋을 스토리지 프로세스들에게 전파하는 식입니다. 각각의 역할이 분리되어 있고, 여러 프로세스 인스턴스로 다중화 가능하여 확장성이 높습니다. 자동 파티셔닝은 FoundationDB의 핵심으로, 키 범위가 일정 크기 이상 커지면 자동으로 분할되고, 부하 불균형이 생기면 스토리지 서버 간 데이터 이동이 발생합니다. 이러한 동적 샤딩은 CockroachDB 등의 range 분할과 유사합니다. FoundationDB의 한 가지 특이한 점은 계층형 트랜잭션이 가능하다는 것이며, 이를 활용해 Document Store (MongoDB API)나 SQL 계층을 별도로 구현할 수 있습니다. 아키텍처상 FDB는 강한 일관성 외의 모드를 제공하지 않으며, 모든 노드는 완전한 ACID 보장 하에 동작합니다. • 고가용성(HA): FoundationDB는 다수 노드에 걸친 복제로 데이터 내구성을 확보합니다. 3중 복제에서 1개 노드 장애는 즉시 다른 복제본들이 대응하여 서비스가 지속됩니다 (자동 장애조치). FDB의 강점은 빠른 장애 복구인데, 이것을 위해 클러스터 전체 상태를 모니터링하고, 문제 발생시 새로운 프로세스로 역할을 재분배합니다. 예를 들어, 한 스토리지 프로세스가 죽으면, 클러스터는 다른 노드의 스토리지 프로세스로 해당 파티션의 복제본을 승격시키고 필요하다면 복제본을 추가 생성하여 다시 3개 복제를 만족시킵니다. 이러한 과정은 수 초 내에 완료되며, 응용은 약간의 지연 외엔 느끼지 못합니다. FoundationDB는 AP 보다는 CP로 동작하므로, 쿼럼 없는 상태에서는 쓰기를 중단하지만 잘게 분산된 구조라 대부분 국소적 장애는 전체 서비스에 영향이 없습니다. Apple은 FoundationDB를 수천 대 서버에서 운용하며, 자동 장애 대응으로 24/7 무중단 iCloud 서비스를 구현했다고 알려져 있습니다. RPO=0 (과반수에 데이터 남아 있음), RTO는 짧게는 12초, 길어도 수십 초 내 외부 서비스가 복구됩니다. 6-nine 가용성까지 목표로 할 경우, 다중 데이터센터에 복제구성을 권장하며, FoundationDB는 동기 크로스-데이터센터 복제 모드를 제공하여, 하나의 데이터센터 장애 시 다른 곳에서 즉시 서비스가 가능한 구성을 지원합니다. • 데이터 정합성 모델: FoundationDB는 트랜잭션적 Key-Value 스토어로서 Strict Serializable (엄격 직렬화) 트랜잭션을 보장합니다. 이는 가장 강력한 격리 수준으로, FoundationDB에서는 모든 읽기/쓰기가 하나의 직렬화된 순서로 실행된 것처럼 보입니다. FDB의 트랜잭션은 기본 5초 타임아웃 내에 완료되어야 하며, 이를 넘기면 실패하지만, 이는 너무 긴 트랜잭션으로 인한 낙관적 동시성 제어 부담을 방지하기 위함입니다. 대부분의 경우 트랜잭션은 수 ms~수백 ms 내 종료되므로 문제가 되지 않습니다. 정합성 면에서, FDB는 분산 시스템임에도 동일 클러스터 내 모든 클라이언트가 동일한 순서의 업데이트를 보게 되며, 기존 RDBMS와 똑같이 다뤄도 됩니다. 멀티키 트랜잭션도 완벽히 지원되므로, NoSQL류의 Atomicity 제약 (단일 키만 원자성 보장 등)이 없습니다. 또한 Snapshot 읽기(특정 이전 시점의 데이터 조회)를 API로 제공하여, 장기 실행 읽기를 할 때도 일관성 보장을 유지합니다. FoundationDB는 기본적으로 정합성을 위해 가용성을 일부 희생하는 설계를 택했지만, 빠른 복구로 가용성도 상당히 높게 유지하고 있습니다. CAP 이론 관점에서 FDB는 CP 시스템으로 볼 수 있습니다. • 커뮤니티 및 상용 지원: FoundationDB는 Apache 2.0 라이선스로 공개된 오픈소스 프로젝트이며, 개발의 많은 부분을 Apple이 주도하고 있지만, 커뮤니티도 Slowly Growing 중입니다. 공식 포럼이 운영되고, 수많은 시뮬레이션 테스트 코드를 함께 제공하여 신뢰성을 검증할 수 있습니다. 상용 지원은 따로 없지만 Apple 내부에서 수백 PB 데이터를 운영하는 핵심 DB로 사용되고 있고, Snowflake, Cloudflare 등 몇몇 기술 선도 기업이 적극 도입하여 사용하고 있습니다. 게임 분야에서는 아직 직접적인 적용 사례가 드물지만, EVE Online의 개발사 CCP Games가 차세대 프로토타입 아키텍처에서 FoundationDB를 트랜잭션 이벤트 저장소로 시험 중인 것으로 알려져 있습니다 (EVE는 현재 Oracle RDBMS 기반). FoundationDB는 직접 사용보다는, 이를 내장한 **Document DB (예: Document Layer)**나 Graph DB(예: Netflix의 TitanDB 대체 연구)로 활용될 가능성도 있습니다. 커뮤니티는 아직 작지만, ACID NoSQL 엔진으로 독보적인 위치에 있어 관련 연구와 관심이 지속되고 있습니다.

ScyllaDB

ScyllaDB는 Cassandra와 호환되는 오픈소스 분산 NoSQL DBMS로, C++로 구현되어 하드웨어 성능 극대화에 초점을 맞춘 시스템입니다. Seastar라는 비동기 프레임워크를 기반으로 잠금 회피(shard-per-core) 설계를 도입하여, 동일한 하드웨어에서 Cassandra보다 510배 이상의 성능을 내는 것으로 알려져 있습니다. MMORPG의 채팅, 로그 저장, 실시간 분석 등 높은 쓰기량이지만 100% 일관성이 꼭 필요하지 않은 영역에서 많이 활용됩니다. • 멀티스레딩/멀티코어 활용: ScyllaDB의 가장 큰 특장점은 Shard-Per-Core 아키텍처입니다. 하나의 Scylla 노드는 **CPU 코어마다 전용 스레드(shard)**를 띄우며, 각 shard는 polling 방식으로 바쁘지 않을 때도 active하게 동작해 낮은 지연을 실현합니다. 모든 요청은 해시에 따라 특정 shard에 배정되고, shard 간 공유자원이 없도록 (필요시 메시지 패싱으로) 설계되어 락 없이 동작합니다. 이로써 코어 n개인 시스템에서 n배에 가까운 처리량 향상을 이뤘고, 실제 ScyllaDB는 100 코어짜리 서버에서도 선형에 가까운 성능 확장을 보였습니다. 또한 Async I/O를 적극 활용하여, 디스크나 네트워크 대기 시간 동안에도 다른 요청을 처리함으로써 CPU 유휴를 줄입니다. 이러한 멀티코어 최적화로 Scylla는 C++ 저수준 튜닝까지 동원하여 하드웨어를 완전히 활용합니다. • I/O 처리 성능: ScyllaDB는 저장 엔진으로 LSM Tree 구조(구체적으로는 Cassandra와 같은 SSTable 구조)를 사용하며, Direct I/O를 통해 OS 캐시를 거치지 않고 자체적으로 디스크 관리를 합니다. 데이터 파일을 오프셋 단위로 직접 읽고 쓰며, Linux AIO와 IO Scheduler를 내장하여, 읽기/쓰기 IOPS를 최적 제어합니다. WAL에 해당하는 Commit Log를 순차 기록하며, flush 정책도 역시 CPU 코어별로 병렬 처리됩니다. 특히 Scylla의 IO 서브시스템은 디스크 대역폭과 IOPS를 최대화하도록 튜닝되어 있어, 한 노드가 수십만 IOPS를 처리 가능하고, p99 지연 1ms 미만의 성능을 목표로 합니다. compaction도 여러 종류 (Size-tiered, Leveled 등) 스케줄러를 제공하며, 백그라운드 작업이 포어그라운드 쿼리에 영향 주지 않도록 per-core IO queue로 제어합니다. 결과적으로, Scylla는 전통적인 DBMS 대비 디스크 시퀀셜 쓰기 비중이 높고, random IO를 최소화하여 SSD 성능을 끌어내며, NVMe 최적화에도 적극적입니다. 한 벤치마크에서 ScyllaDB는 4노드 클러스터로 Cassandra 40노드 클러스터와 비슷한 처리량을 보였다는 보고도 있습니다. • 서버당 자원 활용률: ScyllaDB는 목표 자체가 하드웨어 한계까지 쓰기이기에, CPU, 메모리, 디스크 모두 100% 활용에 가깝게 동작할 수 있습니다. 기본적으로 CPU 코어당 하나의 shard가 있으므로 CPU는 full로 사용되며, 메모리는 OS 페이지캐시 대신 Scylla 자체 캐시로 사용됩니다. 사용자가 –memory 파라미터로 Scylla 프로세스가 쓸 메모리를 지정하면 (예: 전체 75%), 그 범위 안에서 Row Cache, Bloom Filter, Memtable 등으로 분할 사용합니다. 또한 ScyllaDB는 스마트 스케줄러를 통해, 읽기/쓰기/컴팩션 작업간 자원 쟁탈을 중재하여 공정하게 CPU와 디스크를 사용하게 합니다. 디스크 사용률 측면에서, Scylla가 제시하는 iostat은 종종 90% 이상의 util을 찍기도 하는데, 이는 그만큼 디스크를 바쁘게 사용하여 높은 처리량을 달성함을 의미합니다. 다만, 이렇게 자원을 한계까지 쓰므로 노드당 처리량은 매우 높지만, 스파이크 부하 시 지연 시간이 튈 수 있어, 모니터링과 백프레셔 튜닝이 필요합니다. • 쓰기 성능: ScyllaDB는 NoSQL 중에서도 최고 수준의 쓰기 처리량을 보여줍니다. 예를 들어, 3노드 Scylla 클러스터가 초당 100만 건 이상의 쓰기(작은 레코드)를 처리하는 것이 실측되었으며, 동일 조건에서 Cassandra는 1/4 ~ 1/10 수준에 그쳤습니다. 이러한 뛰어난 쓰기 성능은 앞서 언급한 최적화 덕분이며, 스크럽/컴팩션 등의 오버헤드도 Cassandra보다 덜 하여 일관된 쓰기 성능을 냅니다. Scylla는 오토 펌프(flush) 메커니즘으로 메모리 버퍼를 효율적으로 디스크에 내려, 퍼센트타일 지연을 낮춥니다. 또한, 멀티 쓰레드 압축과 비동기 복제로 쓰기 경로를 최적화했기에, 네트워크 레이턴시가 작은 동지역(동일 데이터센터) 운영 시, 클라이언트는 수백 마이크로초 수준의 write ack를 받을 수 있습니다. 다만 강한 정합성 모드(클라이언트에서 QUORUM 모드를 써서 동기 확인)에서는 레이턴시가 약간 올라가지만, 그래도 1ms 안팎으로 매우 빠릅니다. 이런 특성 때문에 Scylla는 실시간 로그, 센서 데이터 수집 등 쓰기 집중형 워크로드에 채택되고 있습니다. 실제로 Discord 메신저는 Cassandra에서 Scylla로 마이그레이션하여, 일일 수십억건 메시지 저장을 1/3 이하 노드로 처리하게 되었고, P99 지연이 대폭 감소했다고 보고했습니다. • 클러스터링 및 분산 아키텍처: ScyllaDB는 Cassandra와 동일하게 공유-나싱 P2P 아키텍처입니다. 데이터는 Consistent Hash에 따라 여러 노드에 분산되며, 각 데이터 조각(파티션 키 해시 범위)이 토큰으로 표현됩니다. 토큰 분배는 자동으로 이뤄지며, 노드 추가/제거 시 토큰 리밸런싱으로 데이터를 이동합니다. 기본 **복제인자(replication factor)**는 3이며, 노드들은 Gossip 프로토콜로 서로 상태를 공유하고, 멀티 마스터로 동작합니다. 즉 어떤 노드에서도 쓰기/읽기를 받아들이며, 클라이언트 드라이버가 요청 키토큰에 맞는 노드로 보내는 형태입니다. Scylla는 클러스터링 측면에서 Cassandra와 거의 동일하나, 한 가지 차별점은 RAID0나 JBOD 사용 등 하드웨어 최적화 가이드를 제시하고, 각 shard가 책임지는 토큰 범위를 정하는 등 세밀한 튜닝이 가능합니다. 또한 Scylla Manager라는 툴로 클러스터 운영 작업(노드 추가, 백업, 리페어 등)을 지원합니다. 분산 아키텍처상 Scylla는 Region 단위 데이터센터 개념(DC를 여러개 두어 복제)를 지원하므로, 여러 데이터센터에 걸친 분산이 가능합니다. 이 경우 쓰기는 각 DC별로 병렬 커밋되고, 동기화 지연이 조금 생기지만, 설정에 따라 **크로스-DC 일관성 (NetworkTopologyStrategy)**를 선택할 수 있습니다. • 고가용성(HA): ScyllaDB는 Cassandra와 동일한 AP 계열로, 노드가 하나 꺼져도 다른 노드들이 계속 서비스하며, 꺼진 노드가 복구될 때 힌트 전달(Hinted Handoff) 또는 리페어 과정을 통해 데이터 정합성을 맞춥니다. RPO는 클라이언트의 Consistency Level 설정에 따라 달라집니다. QUORUM이나 LOCAL_QUORUM으로 쓰기를 했다면, 하나 노드 장애 시에도 다른 노드에 데이터가 남아 있으므로 유실은 없습니다 (RPO=0). 하지만 ONE으로 했다면 장애 시 일부 최근 쓰기가 유실될 수 있습니다. RTO는 노드 장애시에는 0에 가깝습니다 (클라이언트 드라이버가 바로 다른 노드로 쿼리 재시도). 다만, 장애 발생 5초 후 etc, gossip에서 down 처리되기 때문에 짧은 타임아웃동안 해당 노드로 요청 시도될 수 있습니다. 노드 복구에는 노드 조인 시간(데이터 양에 비례하여 수십분수시간)이 필요하나, 그 동안에도 서비스는 지속됩니다. 한편, Scylla는 Adaptive Timeout 기능으로 느린 노드를 감지해 그 노드를 통하지 않고도 쿼럼 응답을 받도록 하여, 부분 장애에도 고가용성을 유지합니다. 클러스터 전체 장애를 막기 위해, 다중 DC 구성 시 클라이언트가 다른 DC로 failover하는 방식을 쓰기도 합니다. 실무에서 Scylla/Cassandra는 99.99% 이상의 가용성을 보여주는 경우가 많으며, 다중 지역 구성시 이론적으로 100% 가동에도 근접할 수 있습니다 (노드 Down이 서비스 전체 다운으로 이어지지 않으므로). • 데이터 정합성 모델: ScyllaDB는 기본적으로 **튜너블 일관성(tunable consistency)**를 제공합니다. Cassandra 모델과 동일하게, 쓰기/읽기 시 Consistency Level (ONE, QUORUM, ALL 등)을 지정하여, 강한 정합성부터 최종 일관성까지 트레이드오프를 결정할 수 있습니다. 기본 설정인 QUORUM 쓰기+QUORUM 읽기의 경우, 단일 DC에서는 선형적 일관성에 가까운 동작을 합니다 (다수 노드에 확인된 최신 쓰기만 읽으므로). 그러나 ScyllaDB는 글로벌 트랜잭션이나 멀티 키 ACID를 지원하지 않습니다. 단일 파티션의 **경량 트랜잭션 (Lightweight Transaction)**을 위해 Paxos 합의 알고리즘으로 Compare-and-Set (IF NOT EXISTS 등의 조건부 쓰기)을 제공하며, 이는 직렬화 가능한 단일 키 트랜잭션을 보장합니다. 하지만 이러한 LWT는 성능이 많이 떨어지므로 일반적인 MMO 게임 로직에는 잘 사용되지 않습니다. 정합성 측면에서 Scylla(및 Cassandra)는 AP 중시 설계이므로, 네트워크 분할 시 가용한 쪽에서 계속 쓰기를 받고 나중에 합치는 (Conflict-free resolution) 형태입니다. 따라서 게임 데이터처럼 동시에 같은 데이터를 수정하면 안 되는 경우, 애플리케이션 레벨에서 동시성 제어를 추가로 해야 합니다. 읽기는 기본적으로 최신성 보장이 안 될 수 있지만 (예: CL=ONE 읽기하면 복제 지연 가능), CL=QUORUM으로 하면 상당히 신뢰할 만한 최신 데이터를 얻습니다. 한편, ScyllaDB는 항상 쓰기 우선(writes never stop) 철학이라, 쓰기를 버리지 않고 eventually 정합성을 맞추는 방향으로 설계되어 있어, 게임 이벤트 로깅이나 채팅 로그 등 일관성이 살짝 희생되어도 되는 영역에 적합합니다. • 커뮤니티 및 상용 지원: ScyllaDB는 Apache 2.0 라이선스 오픈소스이며, **ScyllaDB Inc.**가 프로젝트를 주도하면서 엔터프라이즈판 및 클라우드 서비스를 제공합니다. 커뮤니티는 Cassandra 사용자들을 일부 흡수하여 활발한 편이고, ScyllaDB 공식 포럼 및 Slack 등에서 엔지니어들이 직접 지원하기도 합니다. 상용 엔터프라이즈 버전은 추가 기능 (LDAP 연동, 역할 기반 접근 등)이 있고, Scylla Cloud라는 DBaaS도 제공되어 관리 편의성을 높였습니다. 활용 사례로, 앞서 언급한 Discord가 Scylla로 대규모 채팅 메시지 저장을 이관한 것이 유명하며, Komodo 등 일부 게임회사가 실시간 게임 로그 수집에 Scylla를 이용했습니다. 또한 광고 트래킹이나 IoT 회사 등 쓰기 많은 서비스에서 Scylla 채택률이 높습니다. MMO 게임에서는 주로 영구 데이터보다는 캐시 대용 혹은 보조 데이터 저장(예: 일일 플레이 로그, 실시간 매치메이킹 정보 등)에 Scylla를 활용하여, RDBMS의 부하를 줄이는 패턴이 있습니다.

MongoDB (Replica Set 및 Sharding 구성)

MongoDB는 JSON 기반의 Document NoSQL DB로, 유연한 스키마와 개발 용이성으로 폭넓게 쓰입니다. 기본적으로 단일 마스터(replica set) 구조로 강한 일관성을 갖지만, 샤딩을 통해 데이터를 여러 서버에 분산할 수 있습니다. MMO 게임에서는 사용자 프로파일이나 게임 상태를 JSON으로 저장하거나, 로그성 데이터를 빠르게 넣고 조회하는 용도로 사용되기도 합니다. • 멀티스레딩/멀티코어 활용: MongoDB는 스레드 풀 구조로, mongod 프로세스 내에서 여러 스레드가 클라이언트 요청을 병렬 처리합니다. WiredTiger 스토리지 엔진(기본 엔진)은 각 컬렉션/인덱스 단위로 락을 사용하여 동시성을 높였으며, 4.x 버전 이후로는 다중 코어에서 읽기/쓰기 락 경합이 크게 줄었습니다. 배경 쓰레드도 존재하여 체크포인트나 journaling 등을 수행하지만, 전반적으로 MongoDB는 CPU 코어가 많을수록 다중 클라이언트 처리량이 증가하는 모습을 보여줍니다. 다만, 복잡한 aggregation 연산 등 일부 파이프라인은 싱글 스레드로 동작할 수 있어 워크로드 패턴에 따라 스레드 활용에 제한이 있을 수 있습니다. C++로 작성된 MongoDB 엔진은 GIL 같은 건 없으므로, 한 프로세스가 수십 코어도 사용할 수 있습니다. 실제로 MongoDB는 많은 코어(32코어 이상) 환경에서도 효율적으로 확장하도록 지속적인 최적화를 해왔습니다. • I/O 처리 성능: MongoDB WiredTiger 엔진은 기본적으로 B-Tree 기반 저장방식을 사용하며, 쓰기 시 **Write Ahead Logging (journal)**을 남깁니다. 저널은 디폴트 100MB 파일 단위로 순차 기록되어, 초당 수천 건의 쓰기도 문제없이 로그에 기록합니다. 또한 메모리 맵핑(MMAPv1 엔진)에서 WiredTiger로 변경되면서 버퍼 캐시를 통해 I/O 성능이 향상되었습니다. WiredTiger는 내부적으로 압축을 지원하고, 스냅샷 복사를 통해 체크포인트 시 Write Lock 시간을 최소화합니다. MongoDB 4.2+ 부터 전자 컴팩션도 자동으로 수행되어, SSD에 적합한 접근 패턴을 보입니다. SSD 최적화 면에서, WiredTiger는 랜덤 I/O를 줄이고 페이지 단위 sequential I/O를 활용하며, 특히 t2/t3.small 같은 작은 AWS 인스턴스부터 NVMe 로컬 SSD가 있는 대형 인스턴스까지 광범위하게 튜닝되어 있습니다. 결과적으로 MongoDB는 단일 노드에서도 십수만 IOPS까지 견딜 수 있고, I/O 병목이 발생하면Ops Manager나 내장 툴로 캐싱 부족, 인덱스 최적화 등을 조언해줍니다. • 서버당 자원 활용률: MongoDB는 메모리 중심 설계로, 가용 메모리의 최대 50% 정도를 WiredTiger 엔진이 캐시로 사용합니다. 덕분에 자주 읽는 데이터는 메모리에서 서빙되어 빠른 속도를 냅니다. CPU 사용률은 쿼리 패턴에 따라 상이한데, 정렬이나 집계 연산 등이 많으면 CPU를 많이 쓰며, 단순 키-값 읽기/쓰기는 CPU보다 디스크나 네트워크가 병목되는 경우도 있습니다. MongoDB는 스케일 업 방향을 권장하기도 하는데, 이는 한 노드의 자원(특히 메모리)이 클수록 성능이 좋아지기 때문입니다. 디스크는 가급적 NVMe SSD를 사용하고, RAID-10 구성을 권장하며, IOPS를 높이기 위해 필요시 Storage Engine 설정에서 flush 주기, eviction 설정 등을 만질 수 있습니다. 한편 MongoDB 4.4부터는 아카이빙(잘 안쓰는 데이터는 컬드 컬렉션) 등 기능으로 콜드 데이터와 핫 데이터를 분리해 자원 사용을 최적화하는 기능도 도입되었습니다. 요약하면, MongoDB는 메모리를 최대한 활용하고, 그다음 디스크 I/O를 사용하는 계층화된 자원 사용 모델을 갖습니다. • 쓰기 성능: MongoDB는 단일 노드 쓰기 성능이 우수한 편입니다. 벤치마크에 따르면, 단일 MongoDB 서버로 초당 510만 건의 삽입을 처리할 수 있으며, 클러스터(샤드) 구성 시 선형에 가깝게 증가합니다. 특히 batched insert(배치 삽입)를 사용하면 단위 요청당 overhead를 줄여 훨씬 높은 TPS를 얻을 수 있습니다. MongoDB의 replica set 환경에서 쓰기 성능을 높이려면 기본 Write Concern (w:1)을 사용하면 되는데, 이는 Primary에만 확인하고 반환하므로 매우 빠릅니다. w: majority로 설정하면 복제슬레이브까지 확인하므로 지연이 증가하지만 데이터 안전성을 얻습니다. MMO 게임 환경에서는 일반적으로 w:1, journal: true 설정으로, 장애 시 일부 마지막 데이터는 잃을 수 있지만 속도를 높이거나, 중요한 데이터의 경우 w: majority로 해서 강한 내구성을 택합니다. 한편, MongoDB 4.0부터 멀티 도큐먼트 트랜잭션이 도입되어 (4.2부터 샤딩 환경도 지원), ACID 보장이 필요할 때 쓰이지만, 내부적으로 잠금을 많이 사용하므로 TPS는 줄어듭니다. 따라서 게임에서는 계정 잔액 갱신 등 꼭 트랜잭션 필요한 곳에만 사용하고, 대부분은 단일 document 원자 업데이트로 처리하는 것이 좋습니다. 실제 사례로, MongoDB Atlas를 사용한 한 게임 서비스에서 1초당 20만 건 이상 이벤트 로그를 컬렉션에 insert하여 실시간 처리한 예가 있으며, Mongo 클러스터(샤드)로 이를 소화했습니다. • 클러스터링 및 분산 아키텍처: MongoDB의 기본 HA 단위는 Replica Set입니다. 하나의 Primary 노드와 1개 이상의 Secondary 노드로 구성되며, Primary가 모든 쓰기를 담당하고 Secondaries는 oplog를 따라가 데이터 복제본을 유지합니다. Primary 장애 시 남은 노드들 사이에 **선출(election)**을 통해 새로운 Primary가 자동 선정됩니다. 이 Replica Set이 기본 구성이고, Sharding은 다수의 Replica Set을 Shards로 모아 수평 분산하는 방식입니다. Sharded cluster에서는 Query Router(mongos) 프로세스와 Config 서버들이 추가로 동작하여, 데이터 파티셔닝 메타데이터를 관리하고 쿼리를 올바른 shard로 라우팅합니다. 샤딩 키는 해시 또는 레인지 기반으로 설정할 수 있으며, 밸런서가 자동으로 청크를 shard들에 분배하고 스플릿/마이그레이션을 수행합니다. 이러한 공유-나싱 구조로, MongoDB는 노드를 추가하면 용량과 처리량을 확장할 수 있습니다. 다만, 각 shard는 독립된 Replica Set이므로, 샤드 수가 늘어나면 운영 복잡도가 증가하고, cross-shard 트랜잭션의 비용이 커집니다. MMO 게임에서는 흔히 사용자ID 해시 등을 샤딩 키로 써서 데이터 균형을 맞추고, 특정 샤드에 핫스팟이 생기지 않도록 합니다. 그리고 가능한 한 single-shard operations (샤드 하나에만 해당하는 쿼리)로 데이터 모델링하여, 분산의 성능 이점을 누리면서 복잡성을 줄입니다. • 고가용성(HA): MongoDB Replica Set은 내장된 Fail-over 매커니즘으로 자동 HA를 제공합니다. Primary 노드가 장애로 응답을 못 하면, 기본 10초 타이머 후 선거를 통해 Secondary가 Primary로 승격되고 클라이언트는 새 Primary로 연결합니다. RTO는 수초수십초이며, RPO는 Write Concern 설정에 따라 좌우됩니다. w: majority라면 Primary 장애 시 majority가 가진 시점까지의 데이터는 보존되어 RPO ~ 0에 수렴하고, w:1이면 Primary가 commit 했으나 Secondaries에 반영되지 못한 트랜잭션은 유실될 수 있습니다. MongoDB는 복제 지연을 모니터링하여 Secondaries의 랙이 너무 커지면 알람을 주고, 회복 후 자동 oplog 캐치업을 통해 최종 동기화를 합니다. 또한 젠젤링 재선출이 일어나면 새 Primary도 클라이언트가 자동 인지하도록 드라이버가 지원합니다. 다중 데이터센터 구성시, Voting 노드를 적절히 배치하여 한 사이트 장애시에도 과반수를 유지하게 구성할 수 있습니다. 예를 들어 3DC에 7노드(각 3-2-2) 두면 한 DC down에도 5/7 확보로 운영 지속 가능합니다. 6-nine 가용성을 위해서는 여러 Replica Set에 변경을 동기 적용하는 다소 복잡한 아키텍처(예: 이중 쓰기)나, MongoDB Cloud의 글로벌 클러스터 기능 (모든 writes 두 리전에 복제) 등을 사용해야 합니다. 일반적으로 Replica Set 단일 Region에서는 99.99% 수준 가용성이 현실적 한계입니다. • 데이터 정합성 모델: MongoDB는 기본적으로 강한 일관성을 갖습니다 (Primary에 대한 읽기 시). Primary에 커밋된 쓰기는 즉시 그 노드에 반영되며, 읽기도 기본은 Primary에서 하므로 최신 데이터를 읽습니다. Secondary에서 읽을 경우 (읽기 트래픽 분산 목적으로), 기본은 Eventual Consistency입니다. 그러나 4.0 이후 readConcern majority를 사용하면 Secondaries도 majority 커밋된 시점 데이터만 읽게 할 수 있어, 어느정도 일관성을 높일 수 있습니다. Multi-Document 트랜잭션 도입으로, 하나의 Replica Set 내에서는 ACID 트랜잭션이 가능합니다. 격리수준은 snapshot isolation으로 구현되어, 팬텀정합성은 없지만 직렬화가능 수준은 아닙니다. Sharding 환경에서는 두 shard 이상 데이터를 바꾸는 트랜잭션도 가능하나, 2단계 커밋을 사용하므로 지연과 장애 시 복구 부담이 있습니다. MMO 게임에서는 보통 한 Document에 해당하는 구조체가 한계정 또는 한캐릭터의 상태를 담도록 해, 단일 문서 업데이트만으로 일관성을 유지합니다. MongoDB는 Document 단위로 원자성을 보장하고, 그보다 작은 연산들 (예: 배열 원소 업데이트)은 Atomic Operator로 해결하게 해, 개발자가 락 없이도 동시에 동일 Document를 수정할 수 있게 해줍니다. 일례로 $inc 연산은 race condition 없이 증가를 보장합니다. 정합성 vs 성능 면에서 MongoDB는 유연하게 설정 가능하며, 매우 중요한 데이터는 majority 옵션으로 강한 내구성/정합성을, 부차적인 데이터는 낮은 요구사항으로 처리해 성능을 높이는 식으로 운용할 수 있습니다. • 커뮤니티 및 상용 지원: MongoDB는 아마도 NoSQL 중 가장 큰 커뮤니티를 가지고 있습니다. 오픈소스 버전(MPL/Server Side Public License)으로 자유롭게 사용 가능하며, **MongoDB Inc.**에서 Atlas 관리형 서비스와 상용 Enterprise 판을 제공합니다. 전세계 수많은 개발자가 MongoDB를 사용하므로, 자료와 Q&A가 풍부하고 생태계도 큽니다. 게임 업계에서도 MongoDB 사용이 흔하며, 특히 모바일 게임에서 빠른 개발을 위해 초기부터 MongoDB를 채택하는 경우가 많습니다 (예: MiHoYo의 일부 게임 서비스, 국내 중소 게임사의 계정 DB 등). 공식 지원은 MongoDB 회사 통해 받을 수 있고, Atlas 사용시 SLA를 보장받습니다. 다만 라이선스 문제로 AWS DocumentDB처럼 호환 서비스들이 존재하기도 합니다. 전반적으로 MongoDB는 강력한 커뮤니티, 풍부한 자료 덕에 빠르게 적용하기 쉬우나, 스키마 설계를 잘못하면 성능 저하를 겪을 수 있어 주의가 필요합니다 (예: 문서가 너무 커지거나, 깊은 중첩 등). 하지만 그럼에도 개발 생산성 때문에 게임 스타트업들이 선호하는 경향이 있습니다.

단일 고성능 서버 vs. 분산 시스템 아키텍처

앞서 살펴본 DBMS들은 크게 단일 서버형과 분산 클러스터형으로 구분할 수 있습니다. MMO 게임 백엔드 구조를 설계할 때, 하나의 강력한 DB 서버를 사용할지 아니면 여러 노드로 이루어진 분산 DB 클러스터를 구축할지 선택해야 하며, 각각에 장단점과 실제 적용 사례가 있습니다.

단일 서버 (Scale-Up) 아키텍처 • 특징: 고성능의 단일 물리 서버나 인스턴스에서 DBMS 한 개로 모든 데이터를 처리하는 구조입니다. 필요 시 Master-Slave 복제를 붙여 읽기 분산 또는 백업을 하되, 쓰기는 오직 하나의 Master 노드에서 수행합니다. 전통적인 MMO 게임에서는 지역/월드 별로 하나의 DB 인스턴스를 두고, 각 인스턴스가 별도 샤드의 데이터를 전담하는 방식으로 많이 사용되었습니다. • 장점: 설계 단순성이 큽니다. 분산 트랜잭션이나 데이터 일관성 문제를 크게 고민할 필요 없이, ACID 보장하는 RDBMS 하나에 의존하면 됩니다. 또한 애플리케이션 로직이 단순해지고, 디버깅이 용이하며, 운영 관리가 쉬운 편입니다. 레이턴시 측면에서도 모든 데이터가 로컬에 있으므로, 분산 합의 등의 추가 오버헤드가 없어 지연이 낮습니다. 예를 들어, EVE Online은 하나의 세계(state)를 단일 DB(Oracle)에서 관리했는데, 이는 실시간 업데이트가 많고 데이터 간 일관성이 매우 중요했기 때문이며, 단일 DB로 강한 정합성과 일관된 뷰를 보장했습니다. 또한 단일 서버 성능이 부족해지면 더 높은 사양(더 많은 CPU, RAM, 고속 NVMe)의 서버로 교체(Scale-Up)함으로써 어느 정도 성장에 대응할 수 있습니다. • 단점: 확장 한계가 명확합니다. 한 대의 서버에서 처리량(CPU, IOPS)이 한계를 맞으면, 그 이상은 수평 확장이 어려워집니다. MMO에서 동접 수가 폭증하거나 TPS가 급증하는 경우, 단일 DB가 병목이 되어 게임이 랙 걸리거나 장애가 발생할 수 있습니다. 또 하나의 논리적 세계를 여러 DB로 나누기 어렵다면 (예: 모든 플레이어가 같은 공간에서 상호작용), Scale-Up의 한계 = 서비스 한계가 됩니다. 실제로 EVE Online은 단일 세계 구현을 고집한 대가로, 수천 명이 한 장소에 모이는 전투에서 DB 부하로 인한 Time Dilation(게임 속도 강제 저하)을 겪기도 했습니다. 가용성 측면에서도, Master DB 한 대에 장애가 나면 Fail-over가 되기 전까지 서비스 중단이 발생합니다 (따라서 6-nine 같은 초고가용성은 힘듭니다). 또한 백업/복구나 스키마 변경 시 운영 작업이 서비스 전체에 영향을 주며, 데이터 용량 한계도 존재합니다 (단일 서버 스토리지 용량). • 사례: 과거 많은 MMORPG들이 Realm(서버) 별 DB 패턴을 사용했습니다. 예를 들어 **월드 오브 워크래프트(WoW)**는 초기 각 서버가 개별의 MySQL DB를 가졌고, 서버간 교류가 없도록 설계되었습니다. 국내 MMORPG들도 서버(월드) 분리를 통해 DB 부하를 분산시켰는데, 이는 사실상 애플리케이션 레벨 샤딩입니다. 이러한 구조에선 한 서버(DB)당 동시 이용자가 제한되지만, 여러 서버를 운영함으로써 전체 유저 풀을 수용합니다. 단일 서버 아키텍처는 구조가 단순하고 검증되었기에 개발 인력이 적은 팀이나 초기 서비스에서 선호됩니다. 예를 들어, 한 모바일 RPG 게임의 경우 출시 초기에 모든 데이터베이스를 Amazon RDS(MySQL) 단일 인스턴스로 구성했고, 이후 유저 증가에 따라 서버를 4개로 분리(유저id mod 4 등으로)하여 4개의 RDS에 분산시킨 사례가 있습니다. 이것도 본질적으로는 4개의 단일 서버를 병렬로 운영한 것으로 볼 수 있습니다.

분산 시스템 (Scale-Out) 아키텍처 • 특징: 여러 대의 DB 서버가 하나의 논리적인 DB를 구성하여, 데이터를 분산 저장하고 처리하는 구조입니다. 앞서 비교한 CockroachDB, YugabyteDB, Spanner, Cassandra/Scylla, MongoDB Sharding 등이 이에 속합니다. 샤딩키를 기준으로 데이터가 분할되며, 각 노드(혹은 파티션)가 일부 데이터를 책임지고 쿼리는 라우팅됩니다. 노드를 추가하면 처리량과 용량이 증가하여 이론적으로 무한 확장이 가능합니다. • 장점: **수평 확장성(Scalability)**이 가장 큰 장점입니다. 플레이어나 트랜잭션 수가 급증해도 노드를 추가함으로써 대응할 수 있어, 수백만 동시유저 같은 규모도 감당할 수 있습니다. 또한 노드 중 일부 장애가 나도 다른 노드가 서비스 지속하므로, 고가용성이 높습니다. 특히 합의 기반 분산 DB (Cockroach, Spanner 등)는 한 노드/존 장애에도 RPO=0, RTO 수초로 계속 가용하며, 노드 교체도 서비스 중에 가능합니다. 지리적 분산도 용이하여, 여러 지역에 노드를 두고 가까운 곳에서 서비스해 지연을 감소시킬 수 있습니다. 데이터가 자동 복제되므로 백업/복구 부담이 완화되고, 노드 단위 유지보수가 쉬운 등 운영 편의성도 (관리 도구가 있다면) 높습니다. 예를 들어, Pokémon Go는 전세계 단일 게임으로, Google Cloud의 Spanner 기반 Datastore를 사용해 글로벌 플레이어 데이터를 처리함으로써 지역 구분 없이도 거대한 스케일을 감당했습니다. 이처럼 분산 아키텍처는 “한 월드에 모든 유저를 담는” 현대 게임의 요구를 실현하는 데 필수적입니다. • 단점: 시스템 복잡성이 증가합니다. 분산 환경 특성상 네트워크 통신 지연, 분산 트랜잭션 오버헤드가 발생하여, 잘못 설계하면 단일 노드보다 성능이 떨어지는 경우도 있습니다. 데이터 일관성을 유지하려면 합의(Consensus)로 인한 쓰기 지연 증가를 감수해야 하고, 이를 피하면 최종적 일관성으로 개발자가 trade-off를 다뤄야 합니다. 또한 분산 쿼리, 조인 등은 제약이 많고 SQL 지원이 제한되는 경우가 있습니다 (예: Cassandra/Scylla는 조인 미지원). 운영 난이도도 높아, 노드 모니터링, 장애 대응, 데이터 리밸런싱 등 복잡한 작업이 요구됩니다. 특히 게임 런칭 초기에 분산 DB 설정이 잘못되면, 문제 원인 파악이 어렵고 디버깅이 어려워 개발 속도가 느려질 수 있습니다. 비용 측면에서도, 여러 노드를 유지해야 하므로 인프라 비용이 증가할 수 있습니다. (다만 클라우드에서는 단일 고사양 노드 vs 다수 노드 비용을 잘 비교해야 합니다.) • 사례: 대규모 소셜 게임이나 글로벌 서비스는 분산 DB를 도입한 예가 늘고 있습니다. 예를 들어 Riot Games는 전세계 플레이어 데이터를 위해 Cassandra 클러스터를 사용하여 지역별 분산 저장을 하고, 전역 일관성이 덜 중요한 데이터 (예: 매치 히스토리)를 Eventually consistent 방식으로 처리했습니다. Supercell (Clash of Clans의 개발사)도 초창기에는 단일 MySQL로 시작했다가 유저 급증으로 Cassandra 기반 분산 아키텍처로 전환하여, 몇 백만 DAU의 지속 성장을 감당했습니다. 국내 사례로는, 카카오게임즈의 일부 서비스가 CockroachDB를 채택해 글로벌 데이터베이스를 구축한 바 있으며, 이를 통해 지역 간 데이터 동기화를 실시간으로 유지하면서 지연을 최소화했다고 합니다. 이러한 사례들은 분산 DB 도입으로 규모 확장과 일정 수준의 일관성 유지 모두 달성한 경우입니다. 그러나 반대로 분산 시스템의 복잡성 때문에 문제를 겪은 경우도 있습니다. 한 중형 모바일 MMORPG 개발팀은 MongoDB Sharding으로 글로벌 서버를 구성했으나, 초반 쿼리 패턴 설계 미스로 특정 샤드에 부하가 집중되어 심각한 랙과 장애를 겪었고, 결국 샤드를 다시 쪼개고 쿼리 구조를 수정하는 후속 작업이 발생했습니다. 이처럼 분산 아키텍처는 설계 단계에서 데이터 모델링과 샤딩 전략을 잘못 세우면 문제가 커질 수 있습니다.

요약: 어떤 아키텍처를 선택해야 하나?

MMO 게임에서는 데이터 특성과 규모에 따라 다른 접근이 필요합니다. 강한 정합성이 필요한 코어 데이터(예: 캐릭터 인벤토리, 결제 정보 등)는 가급적 트랜잭션이 보장되는 DB에 저장해야 하며, 초당 트랜잭션이 단일 노드 한계를 넘지 않는다면 수평 분할 없는 단일 DB+샤드 별 인스턴스 구조도 여전히 유효한 선택입니다. 반면, 전세계 공통으로 공유되는 상태(예: 글로벌 랭킹, 크로스서버 매치메이킹)는 분산 DB 없이는 구현이 어렵기에 NewSQL 계열이나 NoSQL을 도입해 일관성 vs 가용성 균형을 찾아야 합니다.

실제로 많은 MMO는 혼합 전략을 취합니다: 게임 세계별로 독립된 관계형 DB(예: MySQL/Aurora)를 두고, 계정 공통 정보나 빅데이터성 정보는 분산 NoSQL(예: Scylla, Redis Cluster 등)에 넣는 식입니다. 또는 캐시 계층(예: Redis)을 활용하여, 일관성 필요 낮은 부분은 캐시에 쓰고 본처리는 느리더라도 안정적인 RDBMS에 맡기는 구성도 일반적입니다.

최종적으로, 6-nine 가용성과 초당 수십만 쓰기라는 엄격한 요구사항을 모두 만족하려면, 분산 DB 아키텍처가 사실상 필수입니다. Google Spanner처럼 비용이 높더라도 확실한 솔루션을 쓰거나, CockroachDB/YugabyteDB처럼 오픈소스 분산 SQL로 자체 구축하는 방법이 있습니다. 또는 AWS Aurora 등을 다중 클러스터로 구성하고 상위 레벨에서 멀티-AZ 멀티-마스터를 애플리케이션에서 구현하는 등의 방법도 고려됩니다. 중요한 것은 데이터 파티셔닝 전략이며, 이를 잘 설계하면 분산 DB의 장점을 극대화하면서도 단일 서버의 병목을 피할 수 있습니다.

⸻

참고 자료 및 출처: 본 분석에서는 각 DBMS의 공식 문서, 기술 블로그 및 사례 연구를 참고하였으며, 성능 수치는 해당 출처에서 발췌하였습니다. 예를 들어 PostgreSQL의 멀티코어 활용은 공식 문서에 설명되어 있고, CockroachDB와 YugabyteDB의 분산 트랜잭션 성능 비교는 벤치마크 보고서에서 인용되었습니다. 또한 Spanner의 설계와 SLA는 Google 발표 자료를 기반으로 하였고, ScyllaDB의 사례는 Discord 기술 블로그 내용을 참조했습니다. 상세한 출처는 각 인용 표시에서 확인할 수 있습니다.

OpenSource Summit 2025 한국 11월 4-5일