현재 대부분의 서비스들은 데이터 집약적인 환경을 가지고 있고 이에 따라 데이터베이스의 성능이 서비스의 중요한 요소가 됩니다.
관계형 데이터베이스는 트랜잭션의 ACID를 보장하면서 데이터의 일관성과 신뢰성을 보장하고 있지만, 이로 인한 트레이드 오프로 성능상 의 이슈가 발생합니다.
또한 조인이 포함된 복잡한 쿼리 처리로 단일 서버의 처리로는 데이터베이스 성능의 한계에 다다르는 경우가 많습니다.
해결책
첫 번째 해결책으로 스케일 업을 생각할 수 있습니다. 스케일 업(수직확장)은 서버의 CPU, 메모리, 스토리지 등 하드웨어 성능을 높여 처리 성능을 강화하는 방법입니다. 단순하지만 비용이 많이 들고 무한정 스케일 업할 수 없다는 단점이 존재합니다.
두 번째 해결책은 스케일 아웃을 통한 수평 확장입니다. 관계형 데이터베이스에서는 NoSQL에 비해 스케일 아웃이 어려운편입니다.
아래에서 관계형 데이터베이스에서의 스케일 아웃의 주요 방법에 대해 소개해 드리겠습니다.
데이터 복제 (Replication)
첫 번째 스케일 아웃(Scale-Out)을 구현하는 방법은 마스터-슬레이브(Master-Slave Replication)로 불리는 복제본(Replica)를 만드는 방법입니다. 마스터(Master) 데이터베이스에 대한 복제본(Slave)을 만들게 됩니다.
이를 통해 마스터(Master) 데이터베이스를 통해 쓰기 요청을 처리하고 슬레이브(Slave=Replica) 를 통해 읽기 요청을 처리하는 방식입니다. 여러개의 복제본을 만들어 읽기 부하를 줄이고 성능을 높일 수 있습니다.
단점
읽기 작업이 많은 서비스에 활용하면 효과적이지만, 쓰기 작업에 대한 확장을 불가능 하다는 단점이 존재합니다.
또한 마스터에서 슬레이브로 데이터가 전파되기 까지 지연시간이 발생하며 데이터 일관성 문제가 발생할 수 있습니다.
마스터-슬레이브의 단점을 극복하기 위해 Multi-Master 방법을 사용해 여러 마스터 서버를 구성할 수 있지만 이번 포스팅에서는 샤딩에 대해 알아보겠습니다.
샤딩 (Sharding)
샤딩은 데이터들을 여러개의 독립적인 데이터베이스(샤드)로 나누어 분산 저장하는 방식입니다. 각각의 샤드는 독립적인 데이터베이스처럼 작동하며, 특정 데이터가 어떤 샤드에 저장될지 규칙을 통해 데이터를 분산시킵니다.
각 샤드가 독립적으로 처리하기 때문에 데이터베이스 부하를 분산할 수 있어 성능과 확장성을 높이는데 효과적입니다. 또한 샤드 중 일부 서버에 장애가 발생해도 나머지 샤드가 작동해 서비스 연속성을 유지할 수 있다는 장점이 있습니다.
샤딩 방식
샤딩은 데이터를 어떤 기준으로 나눌지에 따라 여러 방식으로 구분됩니다.
- 범위 샤딩 (Range Sharding)
- 범위 샤딩은 데이터의 값의 범위에 따라 샤드를 나누는 방식입니다. 예를들어 쇼핑몰의 경우 상품 10000개 마다 다른 샤드에 배치할 수 있습니다.
- 장점으로는 특정 범위의 데이터를 빠르게 조회할 수 있지만 특정 데이터 범위만 자주 사용되는 경우 샤드 부하가 몰리는 문제가 발생할 수 있습니다.
- 해시 샤딩 (Hash Sharding)
- 해시 샤딩은 데이터 값을 해시함수로 변환하여 결정하는 방식입니다. 데이터베이스 키에 해시 함수를 적용한 값에 따라 특정 샤드에 저장하게 됩니다.
- 데이터가 균등하게 분산되므로 범위 샤딩에 비해 특정 샤드에 부하가 집중될 위험이 덜하지만, 샤드 추가/제거시 데이터 재분배 관리가 어렵다는 단점이 있습니다.
- 지역 기반 샤딩 (Geo-Partitioning)
- 지역 기반 샤딩은 지리적 위치에 따라 데이터를 나누어 저장하는 방식입니다. 한국 유저의 데이터는 샤드X에, 일본 유저의 데이터는 샤드y에 저장하는 방식입니다.
- 지리적으로 가까운 서버에 해당 데이터를 저장하여 네트워크 지연시간을 줄일 수 있지만, 특정 지역에서의 트래픽 증가로 부하가 불균형해질 수 있습니다.
샤드 간 조인 문제
하지만 샤딩된 데이터베이스에서는 샤드 간 조인이 불가능하거나 성능에 큰 영향을 미치게됩니다. 따라서 여러 샤드에 걸쳐 있는 데이터를 동시에 조회할 경우, 애플리케이션 레벨에서 조인을 구현하거나 샤딩 전 데이터 모델을 설계할 때 조인을 최소화해야합니다.
단점
이미 운영중인 서비스라면 수 많은 데이터를 샤딩하는 것이 상당히 어려울 수 있으며, 핫스팟 키(hotspot key) 문제라고 불리는 특정 샤드에 질의가 집중될 수 있는 문제점이 있습니다.
이렇게 샤딩을 통해 DB 스케일 아웃을 실현할 수 있지만 완벽하지 않기 때문에 잘 고려해 설계해야 합니다.
NoSQL
이러한 관계형 데이터베이스의 수평적 확장이 어려운 한계을 극복하기 NoSQL을 사용하여 해결할 수 있습니다. Not Only SQL의 약자로 비정형 데이터를 지원하고 유연한 스키마를 가져 확장에 유연합니다. 또한 여러 노드에 데이터를 분산 저장하고 처리해 스케일 아웃이 가능합니다.
'컴퓨터공학 > DATABASE' 카테고리의 다른 글
ORACLE을 기반으로하는 데이터베이스 배움터 (스스로 해보는 실습문제 1번 ~ 23번) [523P] (0) | 2022.12.05 |
---|---|
COMPANY SQL EXAMPLE (BY oracle) (0) | 2022.12.05 |