본문 바로가기

CS/데이터베이스

트래픽이 높아질 때, DB는 어떻게 관리를 할 수 있을까

트래픽이 높아질 때 DB가 겪는 문제

트래픽이 많아질수록 DB는 다음과 같은 부하를 받습니다.

 

1. 동시 커넥션 (Connection) 증가

  • 여러 클라이언트가 동시에 DB에 연결을 시도할 때 발생하는 문제
  • DB는 요청마다 세션과 스레드를 생성하여 요청을 처리한다.
  • 동시 사용자가 많아질수록 DB가 관리해야 할 세션/스레드가 기하급수적으로 늘어난다.
  • CPU 스레드 컨텍스트 스위칭이 잦아져 오버헤드 증가
  • 각 커넥션마다 메모리를 차지
  • 일정 커넥션 수가 넘으면 DB가 Connection Queue에 대기시킴 -> 지연 발생

2. 쓰기/읽기 I/O 부하

디스크와 메모리 간의 입출력 처리 속도가 한계에 부딪히는 현상. 트래픽이 폭주하면 디스크 I/O 큐가 꽉 차면서 병목이 생긴다.

  • HDD 환경에서는 랜덤 I/O 속도가 급격히 떨어진다.
  • 쓰기 트랜잭션이 많을수록 WAL 빈도 증가 -> 디스크 크기 지연
  • 읽기 부하는 캐시 미스와 연결되어 성능 저하를 유발한다.

 

3. 락 경합

여러 트랜잭션이 같은 자원을 동시에 접근하려 할 때 발생하는 대기 현상

  • DB는 데이터 무결성을 위해 동시 접근 시 Lock을 건다.
  • 트랜잭션이 많아질수록 락 대기 시간이 길어짐
  • 데드락 가능성 높아짐.

 

4. 캐시 미스

DB가 데이터를 메모리에서 디스크에서 직접 읽는 상황

  • 대부분의 DB는 최근 사용도니 데이터를 메모리에 캐싱함
  • MySQL의 InnoDB Buffer Pool, PostgreSQL의 Shared Buffer
  • 요청된 데이터가 캐시에 없으면 디스크에서 읽어야 하므로 지연 발생

 

5. 디스크/네트워크 병목 (DISK & Network BottleNeck)

DB 서버의 디스크 I/O 속도가 네트워크 대역폭이 처리 가능한 트래픽보다 느려지는 현상

  • 로그 쓰기, 데이터 페이지 등으로 디스크 I/O가 포화됨
  • WAL 로그가 flush 될때 마다 I/O Block 발생

DB 서버를 분산하지 않고 성능 높이는 방법

(1) 하드웨어 성능 향상(스케일 업)

  • 더 빠른 CPU, 코어
  • RAM 확장 -> 캐시 적중률 향상
  • NVMe SSD로 디스크 I/O 병목 제거
  • 네트워크 대역폭 증대 (10GbE 이상)

 

(2) DB 설정 튜닝

  • DB 내부 파라미터를 조정해서 효율을 높이는 방식

 

MySQL

  • innodb_buffer_pool_size → 전체 RAM의 70~80%로 설정 (캐시 효율↑)
  • innodb_flush_log_at_trx_commit → 2로 조정해 디스크 flush 부하↓
  • max_connections, thread_cache_size 조정
  • query_cache_size (MySQL 8.0 이전) 활성화

 

(3) 쿼리/인덱스 튜닝

  •  복잡한 조인이나 서브쿼리 -> 단순화
  •  불필요한 SELECT * -> 필요한 컬럼만 조회
  •  Slow Query Log / EXPLAIN 분석으로 병목 쿼리 찾기
  •  적절한 인덱스 생성
  •  Batch Insert/Bulk Update로 round-trip 최소화

 

(4) 애플리케이션 레벨 캐싱

DB로 직접 접근하는 빈도를 줄이는 방법

  • Redis / Memcached 같은 인메모리 캐시
  • 자주 조회되는 데이터 (예: 유저 프로필, 랭킹, 설정값 등) 캐싱
  • Read-Through / Write-Through / Write-Behind 전략 활용

 

(5) Connection Pool 최적화

  • 애플리케이션에서 DB 커넥션을 재활용 (HikariCP 등)
  • 커넥션 오버헤드를 최소화하고 TPS(초당 트랜잭션 수) 향상

 

(6) 비동기 처리 & 큐잉 (MQ 활용)

  • DB에 바로 쓰기 대신 RabbitMQ / Kafka 같은 메시지 큐를 사용
  • 트래픽이 몰릴 때 큐에 적재 → DB는 안정적인 속도로 소비(consume)
  • 예: 주문 이벤트 → DB에는 비동기로 저장

[한계점]

DB를 분산하지 않는 이상, 다음 한계는 피할 수 없습니다.

  • I/O 처리량은 단일 노드 한계에 묶임
  • 단일 장애점(SPOF)
  • 장애 복구/확장 어려움

 

'CS > 데이터베이스' 카테고리의 다른 글

레디스 - 캐시 전략 패턴  (0) 2025.11.04
Schema가 무엇인가요?  (0) 2025.11.03
DB Locking에 대하여  (0) 2025.11.01