대규모 트래픽 환경에서의 데이터베이스 설계 전략: CQRS와 레플리카의 역할 분담

JuNo_12 2025. 6. 23. 23:36

들어가며

대규모 서비스를 운영하다 보면 필연적으로 데이터베이스 성능 병목 현상에 직면하게 됩니다. 이때 많은 개발자들이 CQRS(Command Query Responsibility Segregation)와 레플리카(Replica)라는 두 가지 해결책을 고려하게 되는데, 둘 다 "읽기와 쓰기를 분리"한다는 공통점 때문에 혼동하기 쉽습니다.

하지만 이 두 기술은 완전히 다른 레벨에서 다른 문제를 해결합니다. 본 글에서는 실제 대규모 트래픽 환경에서 이 두 기술을 언제, 어떻게 활용해야 하는지에 대한 실용적인 가이드를 제시하겠습니다.

레플리카와 CQRS: 근본적인 차이점 이해하기

레플리카: 인프라 레벨의 물리적 분산

레플리카는 동일한 데이터베이스를 물리적으로 복제하여 부하를 분산시키는 기술입니다.

Master DB (쓰기 전용) ──자동복제──► Replica DB (읽기 전용)
     │                                    │
동일한 스키마                        동일한 스키마
동일한 데이터                        동일한 데이터

핵심 특징:

데이터베이스 엔진 레벨에서 자동 동기화
애플리케이션 코드 변경 최소화
물리적 서버 분산을 통한 부하 분산

CQRS: 애플리케이션 레벨의 논리적 분리

CQRS는 명령(Command)과 조회(Query)를 위한 별도의 모델을 설계하는 아키텍처 패턴입니다.

-- Command Model (정규화된 구조)
CREATE TABLE users (id, name, email, created_at);
CREATE TABLE user_profiles (user_id, bio, avatar_url);
CREATE TABLE user_preferences (user_id, theme, language);

-- Query Model (비정규화된 구조)  
CREATE TABLE user_summary (
  id, 
  name, 
  email, 
  bio, 
  avatar_url, 
  theme, 
  language,
  created_at,
  last_updated
);

핵심 특징:

애플리케이션 레벨에서 명시적 분리
각각 다른 데이터 구조로 최적화 가능
개발자가 직접 동기화 로직 구현

대규모 트래픽에서의 문제 해결 방식

레플리카가 해결하는 문제: 물리적 성능 한계

일반적인 웹 서비스에서 읽기와 쓰기의 비율은 보통 9:1 또는 그 이상입니다.

// 전형적인 전자상거래 트래픽 패턴
일일 요청 분석:
- 상품 조회: 1,000만 건 (읽기)
- 주문 생성: 10만 건 (쓰기)

단일 DB 서버 처리 한계: 초당 1만 건
실제 요청: 초당 1만 1천 건 → 서버 과부하 발생

레플리카를 통한 해결:

// 읽기 부하 분산
app.get('/products', async (req, res) => {
  // 읽기 전용 레플리카에서 처리
  const products = await replicaDB.query('SELECT * FROM products');
  res.json(products);
});

app.post('/orders', async (req, res) => {
  // 쓰기는 마스터에서만 처리
  const order = await masterDB.query('INSERT INTO orders ...');
  res.json(order);
});

CQRS가 해결하는 문제: 복잡한 도메인 로직과 조회 최적화

레플리카만으로는 해결할 수 없는 구조적 문제들이 있습니다.

// 레플리카만 사용할 때의 한계
class UserService {
  async getUserDashboard(userId) {
    // 복잡한 조인과 집계 쿼리
    return await replicaDB.query(`
      SELECT 
        u.name,
        COUNT(o.id) as order_count,
        SUM(o.total) as total_spent,
        AVG(r.rating) as avg_rating,
        LAST(a.login_at) as last_login
      FROM users u
      LEFT JOIN orders o ON u.id = o.user_id  
      LEFT JOIN reviews r ON u.id = r.user_id
      LEFT JOIN activities a ON u.id = a.user_id
      WHERE u.id = ?
      GROUP BY u.id
    `, [userId]);
  }
  
  // 하나의 서비스가 너무 많은 책임을 가짐
  async createUser() { /* ... */ }
  async updateProfile() { /* ... */ }
  async getUserStats() { /* ... */ }
  async generateReport() { /* ... */ }
}

CQRS를 통한 해결:

// Command: 비즈니스 로직에만 집중
class UserCommandService {
  async createUser(command) {
    const user = new User(command);
    await this.userRepository.save(user);
    
    // 이벤트 발행으로 Query 모델 업데이트
    await this.eventBus.publish(new UserCreatedEvent(user));
  }
}

// Query: 조회에 최적화된 별도 서비스
class UserDashboardQueryService {
  async getUserDashboard(userId) {
    // 미리 계산된 대시보드 데이터 조회
    return await this.dashboardStore.findByUserId(userId);
  }
}

// 이벤트 핸들러로 Query 모델 업데이트
class UserDashboardHandler {
  async handle(event) {
    const dashboard = this.calculateDashboard(event.user);
    await this.dashboardStore.save(dashboard);
  }
}

언제 어떤 기술을 선택해야 할까?

단계별 적용 가이드

1단계: 소규모 서비스

권장사항: 단일 데이터베이스
이유: 복잡성 대비 이익이 적음

2단계: 중간 규모 서비스

권장사항: 레플리카 도입
조건: 읽기 트래픽이 쓰기의 5배 이상
효과: 즉각적인 성능 향상, 코드 변경 최소

// 간단한 읽기/쓰기 분산
const dbConfig = {
  master: { host: 'master-db.example.com' },
  replica: { host: 'replica-db.example.com' }
};

app.get('*', (req, res, next) => {
  req.db = dbConfig.replica; // 읽기 요청
  next();
});

app.post('*', (req, res, next) => {
  req.db = dbConfig.master; // 쓰기 요청  
  next();
});

3단계: 대규모 서비스

권장사항: CQRS 도입 고려
조건: 도메인 로직이 복잡하고 다양한 조회 패턴 존재
효과: 각 기능별 최적화, 팀 분업 용이

4단계: 초대규모 서비스

권장사항: CQRS + 레플리카 조합
이유: Query 모델도 분산이 필요한 수준

실제 사례: 전자상거래 플랫폼

Before: 단일 DB의 한계

// 모든 것을 처리하는 단일 서비스
class ProductService {
  async getProductDetail(productId) {
    // 복잡한 조인으로 인한 성능 저하
    return await db.query(`
      SELECT p.*, c.name as category, 
             AVG(r.rating) as avg_rating,
             COUNT(r.id) as review_count,
             i.quantity as stock
      FROM products p
      JOIN categories c ON p.category_id = c.id
      LEFT JOIN reviews r ON p.id = r.product_id  
      JOIN inventory i ON p.id = i.product_id
      WHERE p.id = ?
      GROUP BY p.id
    `, [productId]);
  }
}

// 성능 문제
// - 복잡한 조인으로 인한 느린 응답 (평균 500ms)
// - 재고 업데이트시 상품 조회도 영향받음
// - 하나의 서비스가 너무 많은 책임

After: CQRS + 레플리카 적용

// Command: 상품 관리 전용
class ProductCommandService {
  async updateProduct(productId, data) {
    await this.productRepository.update(productId, data);
    await this.eventBus.publish(new ProductUpdatedEvent(productId, data));
  }
}

// Query: 상품 조회 최적화
class ProductDetailQueryService {
  async getProductDetail(productId) {
    // 비정규화된 테이블에서 빠른 조회 (평균 50ms)
    return await this.productDetailStore.findById(productId);
  }
}

// 이벤트 기반 동기화
class ProductDetailHandler {
  async handle(event) {
    const detail = await this.buildProductDetail(event.productId);
    await this.productDetailStore.save(detail);
  }
}

-- 최적화된 Query 테이블
CREATE TABLE product_details (
  product_id INT PRIMARY KEY,
  name VARCHAR(255),
  description TEXT,
  price DECIMAL(10,2),
  category_name VARCHAR(100),
  avg_rating DECIMAL(3,2),
  review_count INT,
  stock_quantity INT,
  images JSON,
  last_updated TIMESTAMP
);

-- 인덱스 최적화
CREATE INDEX idx_category ON product_details(category_name);
CREATE INDEX idx_price ON product_details(price);

주의사항과 트레이드오프

CQRS 도입시 고려사항

복잡성 증가:

// 동기화 로직의 복잡성
class OrderEventHandler {
  async handleOrderCreated(event) {
    // 여러 Query 모델을 동시에 업데이트해야 함
    await Promise.all([
      this.updateUserStats(event.userId),
      this.updateProductStats(event.productId),  
      this.updateRevenueReport(event.amount),
      this.updateInventory(event.items)
    ]);
  }
}

일관성 문제:

// Eventually Consistent 모델
// Command 실행 후 Query 모델 반영까지 지연 발생
app.post('/orders', async (req, res) => {
  await orderCommandService.createOrder(req.body);
  res.json({ message: '주문이 접수되었습니다' });
  
  // 주문 내역 조회시 즉시 반영되지 않을 수 있음
});

레플리카 도입시 고려사항

데이터 지연:

// 레플리카 지연으로 인한 문제
app.post('/users/:id/profile', async (req, res) => {
  await masterDB.updateProfile(req.params.id, req.body);
  res.redirect(`/users/${req.params.id}`); 
  
  // 리다이렉트된 페이지에서 업데이트 전 데이터 조회 가능
});

실무 적용 가이드

점진적 도입 전략

1. 레플리카부터 시작

// 기존 코드 최소 변경으로 성능 향상
const readDB = createConnection(REPLICA_CONFIG);
const writeDB = createConnection(MASTER_CONFIG);

// 읽기 요청만 레플리카로 분산
app.get('/api/*', (req, res, next) => {
  req.db = readDB;
  next();
});

2. 성능 병목 지점 식별

// 느린 쿼리 식별
const slowQueries = [
  'SELECT * FROM orders WHERE user_id = ? ORDER BY created_at DESC',
  'SELECT COUNT(*) FROM products WHERE category_id = ?',
  'SELECT * FROM users u JOIN profiles p ON u.id = p.user_id'
];

// 이런 쿼리들을 CQRS로 최적화 대상으로 선정

3. 단계적 CQRS 적용

// 가장 복잡한 조회부터 CQRS 적용
class OrderHistoryQueryService {
  async getUserOrderHistory(userId) {
    // 기존 복잡한 조인 대신 비정규화된 테이블 사용
    return await this.orderHistoryStore.findByUserId(userId);
  }
}

모니터링과 측정

// 성능 지표 추적
const metrics = {
  readLatency: histogram('db_read_latency'),
  writeLatency: histogram('db_write_latency'),
  replicationLag: gauge('db_replication_lag'),
  queryOptimization: histogram('cqrs_query_performance')
};

// 임계값 설정
const thresholds = {
  readLatency: 100, // 100ms
  writeLatency: 500, // 500ms  
  replicationLag: 5000 // 5초
};

결론

대규모 트래픽 환경에서 데이터베이스 성능 최적화는 단순히 하나의 기술을 선택하는 문제가 아닙니다. 레플리카와 CQRS는 각각 다른 레벨에서 다른 문제를 해결하는 보완적 기술입니다.

레플리카는 물리적 성능 한계를 해결하는 즉효성 있는 솔루션이고, CQRS는 복잡한 도메인 로직과 다양한 조회 요구사항을 해결하는 구조적 솔루션입니다.

성공적인 대규모 시스템 설계의 핵심은 현재 상황을 정확히 파악하고, 단계적으로 적절한 기술을 도입하는 것입니다. 성급한 최적화보다는 실제 병목 지점을 측정하고, 비즈니스 요구사항에 맞는 솔루션을 선택하는 것이 중요합니다.

기술적 복잡성과 비즈니스 가치 사이의 균형을 잘 맞춘다면, 레플리카와 CQRS는 대규모 트래픽 환경에서 안정적이고 확장 가능한 시스템을 구축하는 강력한 도구가 될 것입니다.