지금까지 면접을 많이 봤는데 대규모 트래픽시 어떻게 해야할건지 라는 질문을 많이 받았다
그래서 오늘 이거에 대해 정리해보겠다
1. 데이터가 많아지면 발생하는 문제
백엔드 개발을 하다 보면 처음엔 빨랐던 서비스가 데이터가 쌓일수록 느려지는 걸 경험하게 된다. 작년에 진행한 상담 예약 시스템처럼 예약 기록이나 AI 리뷰 요약 데이터가 조 단위로 쌓인다면, 단순한 쿼리로는 한계가 온다. 이때 효과적으로 데이터를 관리하기 위해 인덱스, 파티셔닝, 샤딩 같은 전략이 필요하다.
2. 인덱스(Index) 이해하기
인덱스는 책의 맨 뒤에 있는 **'색인'**과 같다. 테이블 전체를 다 뒤지지 않고도 원하는 정보가 있는 위치로 바로 점프하는 기술이다.
- 원리: B-Tree 구조를 사용해 검색 속도를 높인다.
- 장점: 특정 상담사 예약 현황을 조회하거나 날짜별로 정렬할 때 성능이 비약적으로 좋아진다.
- 주의점: 데이터가 추가되거나 수정될 때마다 인덱스도 갱신해야 하므로 쓰기 성능은 조금 떨어진다. 꼭 필요한 컬럼에만 전략적으로 걸어야 한다.
3. 파티셔닝(Partitioning)으로 쪼개기
인덱스만으로 감당이 안 될 정도로 테이블이 무거워지면, 테이블을 물리적으로 나누는 파티셔닝을 고려해야 한다.
- 방식: 보통 '연도별'이나 '월별'로 데이터를 나눈다.
- 핵심 (Partition Pruning): "2026년 3월 예약"을 조회하면 DB는 2024, 2025년 데이터 파티션은 아예 무시하고 해당 파티션만 뒤진다.
- 장점: 오래된 상담 이력을 백업하거나 삭제할 때, DELETE 문 대신 파티션 자체를 날려버리면 되기 때문에 부하가 거의 없다.
4. 샤딩(Sharding)으로 서버 분산하기
파티셔닝이 한 컴퓨터 안에서 구역을 나누는 거라면, 샤딩은 데이터를 여러 대의 서버에 나눠 담는 수평 확장(Scale-out) 전략이다.
- 원리: '샤드 키(Shard Key)'를 기준으로 데이터를 분산한다.
- 예시: 서울 지역 상담 데이터는 A 서버, 부산 지역은 B 서버에 저장.
- 장점: 단일 서버의 하드웨어 한계를 넘어서서 이론적으로 무한한 확장이 가능하다.
- 단점: 서버가 여러 대라 데이터를 한꺼번에 조인(Join)하기 어렵고 시스템 복잡도가 올라간다.
5. DB 최적화 구조도
Plaintext
[사용자 요청] (예: 특정 상담사 예약 조회)
│
▼
┌─────────────┐
│ Query Optimizer │ ← 인덱스가 있는지 확인
└─────────────┘
│
├─ [Index 활용] ──▶ B-Tree 탐색 후 데이터 즉시 반환
│
└─ [데이터가 너무 많다면?]
│
▼
┌──────────────────────────┐
│ Partitioning │ ← 테이블을 날짜별로 분할
│ (2025 파티션 | 2026 파티션) │
└──────────────────────────┘
│
▼
┌────────────────────────────────┐
│ Sharding │ ← 서버 자체를 여러 대로 분산
│ [Shard 1 (서울)] [Shard 2 (부산)] │
└────────────────────────────────┘
6. 요약 및 결론
무조건 최신 기술을 쓰는 게 답은 아니다. 서비스의 규모에 맞춰서 단계적으로 접근해야 한다.
- Index: 조회 조건이 명확하고 특정 컬럼 검색이 잦을 때 기본으로 설정.
- Partitioning: 대규모 예약 이력처럼 시간순 데이터 관리가 힘들 때 도입.
- Sharding: 서비스가 전국 단위로 커져서 단일 서버 리소스가 부족할 때 최종 단계로 고려.
결론: 예약 시스템처럼 데이터 정합성과 속도가 모두 중요한 도메인에서는 이 세 가지를 적재적소에 배치하는 아키텍처 설계 능력이 중요하다.
'중앙정보기술인재개발원 > DB' 카테고리의 다른 글
| [데이터베이스] | ERD, 개념 모델링, 논리적 모델링, 물리적 모델링 (0) | 2025.04.16 |
|---|---|
| [데이터베이스] | 기초 정리, 개발 환경 세팅 (0) | 2025.04.16 |