백엔드 아키텍처 기초 6 - DB 규모 확장

• 백엔드 아키텍처 기초 1
• 백엔드 아키텍처 기초 2 - 응답시간 개선
• 백엔드 아키텍처 기초 3 - 웹 계층 수평적 확장
• 백엔드 아키텍처 기초 4 - 데이터 센터
• 백엔드 아키텍처 기초 5 - 메시지 큐, 로그, 메트릭, 자동화

 

서비스 규모가 커지면 DB 부하도 같이 증가한다.

그렇기에 DB 확장에 대한 다음 2가지 방법을 생각해야 한다.

1. 수직적 규모 확장 (scale up)
2. 수평적 규모 확장 (scale out)

수직적 규모 확장과 수평적 규모 확장

🚀 수직적 확장

• 기존 서버의 자원(CPU, RAM 등)을 고사양 or 더 많이 증설하는 방법
• 하드웨어의 한계로 무한 증설 X
• 서버 1대로 모든 트래픽 감당 X
• SPOF(Single Point of Failure) 위험성 증가
• 고성능 자원일수록 비용 증가

 

🚀 수평적 확장

• DB의 수평적 확장은 샤딩(sharding)이라고 부름
• 더 많은 서버 추가로 성능 향상시키는 방법
• 샤딩은 대규모 DB를 샤드(shard)라고 부르는 작은 단위로 분할하는 기술
• 모든 샤드는 같은 스키마를 사용하지만 샤드에 보관되는 데이터에는 중복 X

샤드로 분할된 DB 예시

• 위 예시는 id % 4 조건을 해시 함수로 사용하여 데이터가 보관될 샤드를 정함

DB에 들어가는 데이터 예시

• 샤딩 전략 구현 시 샤딩 키(sharding key) 정의가 중요함
  • 샤딩 키는 파티션 키(partition key)라고 부름
  • 데이터가 어떻게 분산될지 정하는 하나 이상의 컬럼으로 구성됨
  • 위 그림 예시에서는 샤딩 키는 id
  • 샤딩 키로 데이터 조회나 변경을 처리하므로 효율 높일 수 있음
  • 샤딩 키는 데이터를 고르게 분할할 수 있도록 하는게 중요함

 

😈 샤딩 도입 시 생길 수 있는 문제

🎯 데이터의 재 샤딩(resharding)

1. 데이터가 너무 많아져서 하나의 샤드로 감당 못할 때
2. 샤드 간 데이터 분포가 균등하지 못하여 특정 샤드만 공간 소모가 심할 때

• 위 2가지 상황을 샤드 소진(shard exhaustion)이라고 부르며, 이 때 재 샤딩 발생
• 샤드 소진 시, 샤드 키를 계산하는 함수를 변경하고 데이터를 재배치 해야함
• 안정 해시(consistent hashing) 기법 활용하여 문제 해결 가능

 

🎯 유명인사(celebrity) 문제

• 핫스팟 키(hotspot key) 문제라고도 부름
• 특정 샤드에 질의가 집중되어 서버에 과부하 생기는 문제
• 해결하려면 특정 샤드 데이터를 분산시키거나 더 잘게 쪼개야 함

 

🎯  조인과 비정규화(join and de-normalization)

• 하나의 DB를 여러 샤드 서버로 쪼개면 데이터 조인이 힘들어짐
• 해결하려면 DB 비정규화하여 하나의 테이블에서 질의가 수행되도록 하는 것

 

🚀 DB 샤딩을 적용한 아키텍처 구조

데이터베이스 샤딩을 적용한 아키텍처 구조

 

🚀 지금까지 아키텍처 구조 정리

• 웹 계층은 무상태 계층으로
• 모든 계층에 다중화 도입
• 접근이 많은 데이터는 가능한 많이 캐시할 것
• 여러 데이터 센터를 지원하여 지리적 라우팅 할 것
• 정적 콘텐츠는 CDN 서비스할 것
• 데이터 계층은 샤딩을 통해 규모 확장
• 각 계층은 독립적 서비스로 분할할 것
• 시스템을 지속적으로 모니터링하고, 자동화 도구 활용할 것