[DB] 11. 데이터베이스 아키텍처

[DB] 11. 데이터베이스 아키텍처

1. 데이터베이스 아키텍처란?

데이터베이스 아키텍처는 DB를 하나의 서버로만 쓰지 않고, 서비스 규모에 맞게 어떻게 구성하고 운영할지를 정리한 구조다.

사용자가 늘어나고 데이터가 많아질수록, 단일 DB 구조는 성능과 안정성에서 한계가 드러난다.

DB 아키텍처는 이 문제를 해결하기 위한 현실적인 선택들의 집합이다.

2. 단일 DB 구조의 한계

초기 서비스는 보통 하나의 DB 서버로 시작한다.

• 구성이 단순하다
• 관리하기 쉽다

하지만 서비스가 성장하면 문제가 생긴다.

• 동시 접속 증가로 성능 저하
• 장애 발생 시 서비스 전체 중단
• 읽기/쓰기 요청이 한 서버에 집중

이 지점부터 아키텍처 분리가 필요해진다.

3. 커넥션(Connection)과 커넥션 풀(Connection Pool)

애플리케이션이 DB에 접근하려면 커넥션(Connection)을 생성해야 한다.

하지만 커넥션 생성과 종료는 비용이 크다. 요청마다 커넥션을 만들고 닫으면 성능이 급격히 떨어진다.

3-1. 커넥션 풀의 개념

커넥션 풀은 미리 여러 개의 커넥션을 만들어두고, 필요할 때 가져다 쓰는 방식이다.

• 커넥션 생성 비용 감소
• 동시 요청 처리 안정성 향상
• DB 과부하 방지

3-2. 커넥션 풀 크기의 중요성

커넥션 풀을 너무 크게 잡으면 DB가 동시에 처리해야 할 요청이 폭증한다.

반대로 너무 작으면 요청이 대기 상태에 빠질 수 있다.

그래서 커넥션 풀 크기는 DB 성능과 트래픽을 고려해 신중하게 설정해야 한다.

4. 읽기/쓰기 분리(Read / Write Separation)

대부분의 서비스에서는 쓰기보다 읽기 요청이 훨씬 많다.

이 특성을 활용해 쓰기용 DB와 읽기용 DB를 분리하는 구조가 등장했다.

4-1. 기본 구조

• Master DB: INSERT, UPDATE, DELETE 처리
• Replica DB: SELECT 처리

애플리케이션은 쓰기 요청은 Master로, 조회 요청은 Replica로 보낸다.

4-2. 이 구조의 장점

• 읽기 트래픽 분산
• 쓰기 성능 보호
• 조회 성능 안정화

4-3. 주의할 점

Replica DB는 Master의 데이터를 복제해 사용한다.

그래서 아주 짧은 시간 동안 데이터가 아직 반영되지 않은 상태를 조회할 수 있다.

이런 특성 때문에 “쓰기 직후 읽기”가 중요한 경우에는 Master DB를 조회하도록 설계해야 한다.

5. 복제(Replication)

복제는 한 DB의 데이터를 다른 DB로 복사해 유지하는 구조다.

읽기/쓰기 분리는 복제 구조를 기반으로 동작한다.

• Master → Replica 구조
• 데이터 안정성 향상
• 장애 대응 가능

Replica는 장애 발생 시 Master의 대체 역할로도 사용될 수 있다.

6. 샤딩(Sharding)

샤딩은 데이터를 여러 DB로 나누어 저장하는 방식이다.

단순히 읽기 트래픽을 분산하는 것이 아니라, 데이터 자체를 분산한다는 점이 다르다.

6-1. 샤딩이 필요한 상황

• 데이터 양이 단일 DB 한계를 넘을 때
• 테이블 크기가 지나치게 커질 때
• 쓰기 트래픽이 감당 안 될 때

6-2. 샤딩의 기준

보통 다음 기준으로 데이터를 나눈다.

• user_id 범위 기준
• 해시 기반 분산

샤딩은 성능을 크게 개선할 수 있지만, 설계와 운영 난이도가 매우 높다.

7. DB 아키텍처 선택의 기준

모든 서비스를 복제 + 샤딩 구조로 시작할 필요는 없다.

• 초기: 단일 DB + 커넥션 풀
• 성장: 읽기/쓰기 분리 + 복제
• 대규모: 샤딩 도입

DB 아키텍처는 미리 복잡하게 만드는 것이 아니라, 필요해질 때 단계적으로 확장하는 것이 중요하다.

8. 정리

• DB 아키텍처는 서비스 규모에 따라 변화한다
• 커넥션 풀은 성능과 안정성의 기본 장치다
• 읽기/쓰기 분리는 트래픽 분산을 위한 구조다
• 샤딩은 데이터 자체를 분산하는 고급 구조다