데이터베이스 샤딩이란 무엇입니까?
데이터베이스 샤딩은 대규모 시스템에서 수평적 확장성을 구현하는 데 필수적인 기술입니다.
실제 대부분의 시스템은 상당한 읽기 요청과 무시할 수 없는 쓰기 요청을 처리하는 데이터베이스 서버로 구성됩니다. 이러한 상황은 서버 과부하를 초래하고 시스템 성능 저하의 원인이 될 수 있습니다.
이러한 문제점을 완화하고 시스템 성능을 향상시키기 위해 데이터베이스 복제 및 데이터베이스 샤딩과 같은 접근법이 사용됩니다. 이 가이드에서는 시스템 성능 향상 기술을 먼저 살펴봅니다. 여기에는 다음이 포함됩니다.
- 데이터베이스 서버 성능 향상
- 데이터베이스 복제
- 수평 분할
이러한 기술을 분석한 후, 데이터베이스 샤딩이 실제로 어떻게 작동하는지, 그리고 이 방식의 이점과 한계는 무엇인지 알아보겠습니다.
시작해 볼까요?
시스템 성능 향상 기술
데이터베이스 서버로 인한 병목 현상 발생 시 시스템 성능을 개선하는 방법에 대한 논의로 시작해 보겠습니다.
#1. 데이터베이스 서버 성능 강화
데이터베이스 서버 인스턴스의 성능을 향상시키는 것은 시스템 성능을 개선하는 간단한 방법처럼 보일 수 있습니다. 여기에는 처리 능력 증강, RAM 추가 등이 포함됩니다.
하지만 이 기술에는 분명한 한계가 있습니다. 우리는 무한한 저장 공간과 처리 능력을 갖춘 서버를 구축할 수 없습니다. 또한 특정 한도를 초과하면 투자 대비 효율이 감소합니다.
#2. 데이터베이스 복제
수신되는 요청으로 인해 데이터베이스 서버 인스턴스가 과부하되면 데이터베이스 복제를 고려할 수 있습니다.
데이터베이스 복제는 일반적으로 쓰기 요청을 처리하는 하나의 마스터 노드와 여러 개의 읽기 전용 복제본으로 구성됩니다.
이는 시스템 가용성을 높이고 서버 과부하를 줄이는 데 도움이 됩니다. 읽기 요청을 읽기 복제본 중 하나로 보낼 수 있으므로 여러 쿼리를 동시에 처리할 수 있습니다.
그러나 이 방식 역시 문제를 야기합니다. 마스터 노드에 대한 쓰기 요청은 데이터를 변경할 수 있으며, 이러한 업데이트는 주기적으로 읽기 전용 복제본에 전파됩니다.
마스터 노드에서 쓰기 작업이 진행되는 동시에 읽기 복제본 중 하나에 대한 읽기 요청이 있다고 가정해 봅시다.
마스터 노드의 변경 사항이 아직 읽기 전용 복제본으로 전파되지 않았을 수 있습니다. 이 경우 오래된 데이터를 읽게 될 수 있습니다.
#3. 수평 분할
수평 분할은 시스템 성능을 최적화하는 또 다른 기술입니다. 예를 들어, 수십억 개의 행을 포함하는 하나의 큰 테이블(예: 고객 및 거래 데이터 테이블)이 있을 수 있습니다.
이러한 데이터베이스 테이블에 대한 읽기 작업은 속도가 느립니다. 하지만 수평 분할을 사용하면 하나의 큰 테이블이 여러 파티션(또는 더 작은 테이블)으로 나뉘어 데이터 읽기 속도가 향상됩니다. PostgreSQL과 같은 관계형 데이터베이스는 기본적으로 파티셔닝을 지원합니다.
그러나 모든 파티션은 여전히 단일 데이터베이스 서버 인스턴스 내에 존재합니다. 유일한 차이점은 이제 하나의 큰 테이블 대신 파티션에서 데이터를 읽는다는 점입니다.
따라서 들어오는 요청 수가 증가하면 서버가 증가된 요구를 감당하지 못할 수 있습니다.
데이터베이스 샤딩은 어떻게 작동하는가?
시스템 성능 개선을 위한 다양한 접근 방식과 그 한계를 살펴보았으므로 이제 데이터베이스 샤딩이 어떻게 작동하는지 이해해 보겠습니다.
샤딩은 하나의 큰 데이터베이스를 여러 개의 작은 데이터베이스로 분할하며, 각 데이터베이스는 독립적인 서버 인스턴스에서 실행됩니다. 이러한 각 작은 데이터베이스를 샤드라고 합니다. 각 샤드는 전체 데이터 중 일부만을 포함합니다.
그렇다면 데이터베이스를 어떻게 샤드로 분할해야 할까요? 어떤 데이터 행이 어떤 샤드에 저장되는지 어떻게 결정할까요?
🔑 여기서 샤딩 키가 중요한 역할을 합니다.
샤딩 키 이해
샤딩 키의 역할에 대해 좀 더 자세히 알아봅시다.
일반적으로 샤딩 키는 데이터베이스 테이블의 특정 열(또는 열 조합)로, 데이터가 여러 샤드에 균등하게 분산되도록 신중하게 선택해야 합니다. 특정 샤드가 다른 샤드보다 훨씬 커지는 것을 방지하기 위해서입니다.
고객 및 거래 데이터를 저장하는 데이터베이스에서는 'customer_ID'가 적절한 샤딩 키가 될 수 있습니다.
샤딩 키가 결정되면, 특정 데이터 행이 어떤 샤드에 저장될지 결정하는 해시 함수를 정의할 수 있습니다.
이 예에서는 데이터베이스를 'customer_ID'를 샤딩 키로 사용하여 5개의 샤드(샤드 #0 ~ 샤드 #4)로 분할해야 한다고 가정합니다. 이 경우 간단한 해시 함수는 'customer_ID % 5'가 될 수 있습니다.
5로 나눈 나머지가 0인 모든 'customer_ID' 값은 샤드 #0에 매핑됩니다. 나머지가 1부터 4까지인 'customer_ID' 값은 각각 샤드 #1부터 샤드 #4까지 매핑됩니다.
데이터베이스 샤딩을 구현한 후에는, 수신되는 요청을 올바른 데이터베이스 샤드로 라우팅하는 라우팅 계층을 갖추는 것이 중요합니다.
데이터베이스 샤딩의 장점
다음은 데이터베이스 샤딩의 주요 장점입니다.
#1. 높은 확장성
더 큰 데이터베이스를 여러 개의 작은 부분으로 나누는 것이 항상 가능합니다. 따라서 데이터베이스 샤딩은 수평적으로 확장하는 데 매우 효과적입니다.
#2. 높은 가용성
수신되는 모든 요청을 처리하는 단일 데이터베이스 서버 인스턴스는 단일 실패 지점이 됩니다. 데이터베이스 서버가 다운되면 전체 애플리케이션이 다운됩니다.
데이터베이스 샤딩을 사용하면 특정 시점에 모든 데이터베이스 샤드가 동시에 다운될 확률이 상대적으로 낮습니다. 특정 샤드가 다운되더라도 해당 샤드에 대한 읽기 요청만 처리할 수 없게 되며, 다른 샤드는 여전히 요청을 처리할 수 있습니다. 결과적으로 가용성이 높아지고 시스템의 내결함성이 향상됩니다.
데이터베이스 샤딩의 한계
이제 데이터베이스 샤딩의 몇 가지 단점을 살펴보겠습니다.
#1. 복잡성
샤딩은 확장성 및 내결함성 측면에서 많은 이점을 제공하지만, 시스템의 복잡성을 증가시킵니다.
레코드를 파티션에 매핑하는 것부터 시작하여, 라우팅 계층을 구축하여 각 쿼리를 적절한 샤드로 라우팅하는 것에 이르기까지 샤딩된 데이터베이스는 상당한 복잡성을 수반합니다.
#2. 리샤딩
샤딩의 또 다른 단점은 리샤딩이 필요할 수 있다는 점입니다.
데이터 레코드의 균등한 분포를 위해 해시 함수를 사용하지만, 특정 샤드가 다른 샤드보다 훨씬 커지거나 빨리 용량이 부족해질 수 있습니다. 이러한 경우 리샤딩(또는 재분배)을 고려해야 하며, 이는 상당한 오버헤드를 유발할 수 있습니다.
#3. 복잡한 쿼리 실행
조인이 필요한 분석 쿼리를 실행해야 하는 경우, 단일 데이터베이스가 아니라 여러 샤드의 레코드를 사용해야 합니다. 따라서 너무 많은 분석 쿼리를 실행해야 하는 경우 문제가 될 수 있습니다. 이 문제는 데이터베이스를 비정규화하여 해결할 수 있지만, 여전히 추가적인 노력이 필요합니다.
결론
이제 논의한 내용을 요약하면서 결론을 내리겠습니다.
하드웨어 성능 향상이 항상 최적의 해결책은 아니므로, 서버 인스턴스의 성능을 무작정 강화하는 것은 권장되지 않습니다. 우리는 또한 데이터베이스 복제, 수평 파티셔닝 기술과 이 기술들이 갖는 한계를 살펴보았습니다.
이후, 데이터베이스 샤딩이 어떻게 작동하는지, 즉 대규모 데이터베이스를 더 작고 관리하기 쉬운 샤드로 분할하는 방법에 대해 알아보았습니다. 또한 균등한 파티션을 얻기 위해 샤딩 키를 신중하게 선택하는 방법과 수신되는 요청을 올바른 데이터베이스 샤드로 라우팅하기 위한 라우팅 계층의 필요성에 대해 논의했습니다.
데이터베이스 샤딩은 높은 가용성 및 확장성과 같은 이점을 제공합니다. 하지만 단점 중 하나는 샤드 중 하나 이상이 용량이 부족해질 때 샤딩 및 리샤딩을 설정하는 데 필요한 복잡성입니다.
따라서 샤딩으로 인한 복잡성보다 이점이 크다고 판단될 때 샤딩을 고려해야 합니다. 다음으로, 다양한 AWS 관계형 데이터베이스의 비교 정보를 확인해 보세요.