위키원
데이터베이스 샤딩
데이터베이스 샤딩(Database Sharding)이란 하나의 거대한 데이터베이스 테이블을 수평 분할(Horizontal Partitioning)하여 여러 개의 작은 단위로 나눈 후, 물리적으로 다른 위치에 분산하여 저장·관리하는 기술이다. 여러 서버에서 대규모 데이터베이스를 위한 비공유 파티셔닝 체계로 간단히 정의할 수 있어 새로운 수준의 데이터베이스 성능과 확정성을 달성할 수 있다. 수평 분할된 1개의 작은 테이블을 샤드(Shard)라고 하는데, 이 샤드를 여러 분산 서버에 분산시킨다.
접근방식[편집]
데이터베이스 샤딩은 각각 자체 CPU, 메모리 및 디스크가 있는 독립 서버에서 확장성을 위한 방법을 제공한다. 이 기술을 사용하면 데이터베이스 크기와 시스템 리소스의 적절한 균형을 유지할 수 있으므로 주어진 애플리케이션의 성능과 확장성이 향상된다. 데이터베이스 샤딩의 접근 방식은 "아무것도 없는" 접근 방식이다. 데이터베이스 샤딩의 기본 개념은 매우 간단하다. 큰 데이터베이스를 사용하여 여러 서버에서 여러 개의 작은 데이터베이스로 나눈다. 각 샤드에는 원래 단일 데이터베이스의 일부가 포함되어 있으며 애플리케이션별 규칙에 따라 샤딩된다. 예를 들어 많은 조직이 고객별로 샤드하고 각 샤드에는 특정 고객 관련 정보 그룹이 포함되어 있다. 데이터베이스 쿼리 및 쓰기 작업은 다음 두 가지 모드 중 하나로 수행된다.[1]
- 단일 샤드 : 각 데이터베이스 작업은 단일 고객 트랜잭션과 같은 단일 샤드에 대해 수행된다.
- 다중 샤드 : 이는 일반적으로 하나 이상의 샤드에 대해 병렬로 수행되는 분석 쿼리에 적용되므로 인상적인 성능 결과를 얻을 수 있다.
데이터베이스 샤딩 처리 방법[편집]
- 알고리즘 샤딩(Algorithmic Sharding) : 알고리즘 샤딩 데이터베이스는 샤딩 기능을 사용하여 데이터를 찾는다. 이 방법에서는 샤딩 기능만으로 데이터가 분배된다. 이 방법의 문제점은 페이로드 크기나 공간 활용도를 고려하지 않는다는 것이다. 따라서 데이터를 균일하게 분배하려면 각 파티션의 크기가 비슷해야 한다. 이 방법의 또 다른 문제점은 파티션 키가 없는 쿼리는 모든 데이터베이스 노드를 검색해야 한다는 것이다. 알고리즘 샤딩은 데이터베이스에 새 노드/서버를 추가하려고 할 때 각 노드/서버가 해당 해시값을 필요로 하며 무엇보다도 다른 항목을 새 해시로 다시 대응해야 하므로 매우 까다로울 수 있다. 다른 항목들이 새로 추가된 서버로 마이그레이션되기 전에 그들의 새로운 해시값으로 다시 대응되어야 하므로 매우 까다로울 수 있다. 신중하게 하지 않으면 새로운 해싱 기능이나 오래된 해싱 기능도 유효하지 않을 것이다. 이렇게 하면 데이터베이스에 대한 새로운 데이터 쓰기가 중지된다.
- 동적샤딩(Dynamic Sharding) : 동적 샤딩은 외부 로케이터 서비스를 사용하여 입력 위치를 결정한다. 이것은 알고리즘 샤딩에서 발생하는 문제를 해결하는 데 도움이 된다. 외부 로케이터 서비스는 데이터가 있는 샤드의 위치를 제공한다. 이것은 핫스팟을 완화하기 위해 대규모 사용자 그룹과는 반대로 사용자를 하나의 샤드에서 다른 샤드로 개별적으로 재배치할 수 있는 능력을 제공한다. 로케이터 서비스는 하나의 논쟁점이 되고 실패한다. 모든 데이터베이스 운영은 그것에 접근해야 하므로 성능과 가용성은 필수적이다. 그러나 로케이터는 간단히 캐시되거나 복제될 수 없다. 오래된 로케이터는 작업을 잘못된 데이터베이스로 라우팅한다. 잘못 전달된 쓰기는 특히 좋지 않다. 라우팅 문제가 해결된 후 발견할 수 없게 된다.
- 디렉터리 기반 샤딩(Directory-Based Sharding) : 이 방법에서는 샤드 키를 사용하여 샤드 및 보유하는 데이터를 추적하는 조회 테이블을 작성한다. 조회 테이블에는 원하는 데이터를 찾을 수 있는 위치에 대한 정적인 정보 세트가 있다. 찾아보기 테이블의 샤드 키에는 데이터를 쓰거나 가져와야 하는 각 행의 값이 있다. 이 방법은 각 키가 자체 샤드에 직접 연결되므로 범위 기반 샤딩보다 효과적이고 빠르다. 이 방법을 다른 샤딩 기술과 비교하면 이 방법이 다른 방법보다 훨씬 우수하다는 것을 알 수 있다. 이 방법을 사용하면 샤딩을 원하는 동적 또는 알고리즘 시스템을 사용할 수 있으며 비교적 쉽다. 이 방법을 사용하는 것의 단점도 있다. 모든 쿼리 또는 쓰기 전에 룩업 테이블에 연결해야 할 경우 애플리케이션 성능에 부정적인 영향을 줄 수 있다. 조회 테이블의 취약성으로 인해 단일 실패 지점이 될 수 있다. 실패하면 새로운 데이터를 작성하거나 기존 데이터에 엑세스하는 능력에 영향을 줄 수 있다.
장점[편집]
- 데이터베이스 샤딩은 수평적 확장을 용이하게 하는 데 도움이 될 수 있다. 수평적 확장은 부하를 분산시키고 더 많은 트래픽과 더 빠른 처리를 위해 기존 스택에 더 많은 시스템을 추가하는 방식이다. 이것은 흔히 수직 스케일업과 대조되는데, 일반적으로 램(RAM)이나 CPU를 더 추가함으로써 기존 서버의 하드웨어를 업그레이드하는 것을 포함한다.
- 관계형 데이터베이스를 단일 시스템에서 실행하고 컴퓨팅 리소스를 업그레이드하여 필요에 따라 확장하는 것은 비교적 간단하다. 그러나 궁극적으로 비분산 데이터베이스는 스토리지 및 컴퓨팅 성능 측면에서 제한적이므로 수평으로 확장할 수 있는 자유를 가지면 설정이 훨씬 더 유연해진다.
- 일부 사람들이 더러워진 데이터베이스 아키텍처를 선택할 수 있는 또 다른 이유는 쿼리 응답 시간을 단축하기 위함이다. 데이터베이스에서 쿼리를 제출하면 원하는 결과를 찾기 전에 쿼리중인 테이블의 모든 행을 검색해야 할 수도 있다. 대규모의 단일 데이터베이스가 있는 애플리케이션의 경우 쿼리가 엄청나게 느려질 수 있다. 그러나 한 테이블을 여러 개의 테이블로 분할하면 쿼리의 행 수가 줄어들고 결과 집합이 훨씬 빠르게 반환된다.
- 샤딩은 운영 중단의 영향을 완화하여 애플리케이션의 안정성을 높이는 데 도움이 될 수 있다. 애플리케이션이나 웹 사이트가 샤딩되지 않은 데이터베이스를 사용하는 경우 운영 중단으로 인해 전체 애플리케이션을 사용할 수 없게 될 가능성이 있다. 그러나 데이터베이스가 엉망인 경우 운영 중단은 단일 샤드에만 영향을 미칠 수 있다. 이로 인해 일부 사용자가 애플리케이션 또는 웹사이트의 일부를 사용하지 못할 수는 있지만, 전체 데이터베이스가 손상된 경우보다 영향은 덜할 것이다.
단점[편집]
- 사용자들이 샤딩에 직면하는 첫 번째 어려움은 데이터베이스 샤딩 아키텍처를 올바르게 구현하는 것의 복잡성이다. 잘못 수행하면 샤딩 프로세스로 인해 데이터가 손실되거나 테이블이 손상될 수 있는 심각한 위험이 있다. 그러나 올바르게 수행하더라도 샤딩은 팀워크의 큰 영향을 줄 수 있다. 사용자는 단일 진입점에서 데이터에 엑세스하고 관리하는 대신 여러 샤드 위치에서 데이터를 관리해야 하므로 일부 팀에 지장을 줄 수 있다.
- 데이터베이스를 파쇄한 후 사용자가 겪게 되는 한가지 문제는 샤드의 균형이 맞지 않는다는 것이다. 예를 들어, 두 개의 별도 조각으로 된 데이터베이스를 가지고 있다고 가정해보면, 성이 하나는 A에서 M까지 시작하는 고객을 위한 것이고 다른 하나는 N에서 Z까지 시작하는 고객을 위한 것이다. 따라서 A-M 샤드는 N-Z 샤드보다 더 많은 데이터가 점차 누적되어 애플리케이션의 속도가 느려지고 사용자의 상당 부분이 중단된다. A-M 샤드는 데이터베이스 핫스팟으로 알려져 있다. 이 경우 데이터베이스 샤딩시 발생하는 모든 이점은 감속 및 충돌로 인해 상쇄된다. 더욱 균일한 데이터 분배를 위해 데이터베이스를 복구하고 다시 샤딩해야 한다.
- 샤딩이 모든 데이터베이스 엔진에서 기본적으로 지원되는 것은 아니다. 예를 들어 PostgreSQL은 자동 샤딩을 기능으로 포함되지 않지만 PostgreSQL 데이터베이스를 수동으로 샤딩할 수 있다. 자동 샤딩을 포함하는 많은 Postgres 포크가 있었지만 이들은 종종 최신 PostgreSQL 릴리스보다 뒤떨어져 있으며 다른 특정 기능은 없다. MySQL Cluster 또는 MongoDB Atlas와 같은 특정 서비스형 데이터베이스 제품과 같은 일부 특수 데이터베이스 기술에는 자동 샤딩 기능이 포함되어 있지만 이러한 데이터베이스 관리 시스템의 바닐라 버전에는 포함되지 않는다. 이 때문에 샤딩에는 종종 "자신의 롤" 접근방식이 필요하다. 이는 샤딩 문서 또는 해결을 위한 팁을 찾기가 어렵다는 것을 의미한다.
고려사항[편집]
- 신뢰성 : 무엇보다도 모든 프로덕션 비즈니스 애플리케이션은 신뢰할 수 있고 내결함성이 있어야 하며, 자주 중단돼서는 안 된다. 데이터베이스 계층은 안정성 설계에서 가장 중요한 요소인 경우가 많아 데이터베이스 샤딩 구현도 예외는 아니다. 실제로 여러 샤드 데이터베이스의 분산 특성으로 인해 잘 설계된 접근 방식의 중요성이 훨씬 더 크다. 내결함성과 신뢰성 있는 접근방식을 보장하려면 다음과 같은 항목이 필요하다.
- 개별 데이터베이스 샤드의 자동 백업
- 운영 중단 또는 서버 장애시 각 샤드의 최소 2개의 "라이브" 복사본을 사용할 수 있도록 데이터베이스 샤드 이중화
- 서버 내부 및 전체에서 비용 효율적인 하드웨어 이중화
- 재해 복구 사이트 관리
- 분산 쿼리 : 분산 쿼리를 사용하여 많은 유형의 쿼리를 훨씬 빠르게 처리할 수 있으므로 각 샤드 서버에서 중간 결과를 병렬 처리 할 수 있다. 이 기술은 많은 경우 10배 이상에서 성능의 질적 향상을 달성할 수 있다. 애플리케이션에 대해 원활한 방식으로 분산 쿼리를 사용하려면 개별 샤드에서 쿼리 세그먼트를 처리한 다음 결과를 애플리케이션 계층에 대한 단일 결과 집합으로 통합할 수 있는 기능을 갖추는 것이 중요하다. 분산 처리로 얻을 수 있는 일반적인 쿼리는 다음과 같다.
- 전체 시스템에 걸쳐 광범위한 데이터 스윕이 필요한 통계 집계.
- 마지막 날, 주 또는 월에 특정 제품을 구매한 모든 개별 고객 목록과 같은 포괄적인 보고서를 지원하는 쿼리
- 크로스 샤드 조인 방지 : 샤드 시스템에서 샤드에 걸쳐있는 내부 조인을 사용하는 쿼리 또는 기타 명령문은 매우 비효율적이고 수행하기가 어렵다. 대부분의 경우 올바른 기술이 적용되는 한 이러한 내부 조인은 실제로 애플리케이션에 필요하지 않은 것으로 나타났다. 기본 기술은 훨씬 큰 기본 테이블에 조인할 때 일반적으로 사용되는 상대적으로 정적 조회표인 글로벌 테이블의 복제다. 상대 코드, 국가, 유형 및 제품으로 값을 포함하는 테이블이 이 범주에 속한다. 글로벌 테이블의 값이 모든 샤드에서 동기화되어 샤드 조인의 필요성을 최소화하거나 없애는 자동화 된 복제 메커니즘이 필요하다.
- 자동 증분 키 관리 : 데이터베이스 관리 시스템에서 제공하는 일반적인 자동 증가 기능은 데이터베이스에 삽입된 각 새 행에 대한 순차 키를 생성한다. 이는 단일 데이터베이스 애플리케이션에는 괜찮지만, 데이터베이스 샤딩을 사용하는 경우 모든 샤드에서 키를 조정된 방식으로 관리해야 한다. 여기서 요구되는 것은 모든 영역 전체에 걸쳐 키가 고유한지 확인하면서 애플리케이션에 원활하고 자동화된 키 생성 방법을 제공하는 것이다.
- 여러 사드 체계 지원 : 데이터베이스 샤딩은 대규모 확장성 및 성능 향상을 위한 애플리케이션별 기술을 제공하기 때문에 효과적이다. 실제로 효과의 정도는 샤딩 알고리즘 자체가 현재의 애플리케이션 문제에 얼마나 잘 맞게 조정되었는지와 직접적으로 관련이 있다고 말할 수 있다. 필요한 것은 각각 특정 유형의 애플리케이션 문제를 해결하도록 설계된 여러 개의 유연한 샤드 체계이다. 각 체계는 특정 문제 영역에 적용될 때 고유한 성능 및 애플리케이션 특성 또는 장점이 있다. 실제로 잘못된 샤드 구성표를 사용하면 성능과 얻은 결과를 저해할 수 있다. 단일 애플리케이션이 하나 이상의 샤드 체계를 사용하는 경우도 드물지 않다. 각 애플리케이션 특정 부분에 적용되어 최적의 결과를 얻는다. 다음은 일반적인 사드 체계 목록이다.
- 세션 기반 샤딩 : 개별 사용자 또는 프로세스가 사용자 또는 프로세스 세션 기간 특정 샤드와 상호 작용한다. 이는 샤딩 결정이 세션 당 한 번만 이루어지기 때문에 구현하기 가장 간단한 기술이며 전체 성능에 제로 오버헤드(Zero Overhead)를 추가하지 않는다. 이 접근 방식의 이점을 누릴 수 있는 응용 프로그램은 종종 고객 중심이며 특정 고객의 모든 데이터가 단일 샤드에 포함되어 있으며, 그것이 고객이 필요로 하는 모든 데이터이다.
- 트랜잭션 기반 샤딩 : 주어진 데이터베이스 트랜잭션에서 첫 번째 SQL 문을 검토하여 샤드를 결정한다. 이는 보통 명세서에 사용된 "주문 키"값을 평가한 다음 트랜잭션의 다른 모든 명세서를 동일한 샤드로 보낸다.
- 명령문 기반 샤딩 : 모든 유형 중에서 가장 프로세스 집약적이며, 개별 SQL 문을 평가하여 해당 샤드를 지시할 적절한 샤드를 결정한다. 다시 샤드 키 값의 평가가 필요하다. 이 옵션은 종종 전화 통화 기록과 같은 대량의 세분된 트랜잭션에서 바람직하다.
파티션 옵션[편집]
- 마스터/슬레이브(Master/Slave) : 모든 쓰기(업데이트 또는 삭제 및 CRUD 생성) 작업을 위한 단일 마스터 서버와 읽기 전용 작업을 제공하는 하나 이상의 추가 슬레이브 서버와 함께 많은 조직에서 사용하는 가장 간단한 옵션이다. 마스터는 각 슬레이브 서버에 거의 실시간에 가까운 표준 데이터베이스 복제를 사용한다. 마스터/슬레이브 모델은 전체 성능을 어느 정도 가속하여 읽기 집약적인 처리를 슬레이브 서버로 오프로드 할 수 있지만, 이 방법에는 몇 가지 제한이 있다.
- 쓰기용 단일 마스터 서버는 확장에 분명한 한계가 있으며, 병목현상을 빠르게 일으킬 수 있다.
- 마스터/슬레이브 복제 메커니즘은 "거의 실시간에 가까운"이다. 즉, 슬레이브 서버는 마스터에 있는 데이터의 현재 그림을 보장할 수 없다. 일부 애플리케이션에서는 이 방법이 적합하지만, 애플리케이션에 최신 뷰(View)가 필요한 경우 이 방법을 사용할 수 없다.
- 많은 조직이 고가용성(High-Availability)에도 마스터/슬레이브 방식을 사용하지만, 슬레이브 서버가 마스터와 함께 최신 버전이 아니라는 점을 고려할 때 이와 동일한 제한이 적용된다. 마스터 서버에 치명적인 오류가 발생하면 복제 대기 중인 모든 트랜잭션이 손실되며 대부분의 비즈니스 트랜잭션 애플리케이션에서는 받아들일 수 없는 상황이 된다.
- 클러스터 컴퓨팅(Cluster Computing) : 클러스터 컴퓨팅은 그룹에서 작동하는 많은 서버를 사용하며 클러스터 노드 간에 메시징을 공유한다. 대부분, 이 시나리오는 중앙 집중식 공유 디스크 기능이며 일반적으로 SAN(Storage Area Network)에 의존한다. 클러스트의 각 노드는 데이터베이스 서버의 단일 인스턴스를 실행하여 다양한 모드에서 작동한다.
- 고가용성의 경우 클러스터의 많은 노드를 읽기용으로 사용할 수 있지만 쓰기(CRUD) 작업에는 하나만 사용할 수 있다. 이렇게 하면 읽기 속도가 빨자지지만 쓰기 트랜잭션에는 아무런 이점이 없다. 한 노드의 장애가 발생하면 클러스터의 다른 노드가 대신하여 공유 디스크 기능에 대해 계속 작동한다. 이 방식은 CRUD 작업의 단일 병목현상으로 인해 확장성이 제한된다. 중앙 집중식 공유 디스크 기능은 감소하는 리턴이 발생하기 전에 로드를 너무 많이 분산시킬 수 있으므로 읽기조차 결국 성능 한계에 부딪힌다. 읽기 제한은 애플리케이션에 복잡한 조인(Join)이 필요하거나 최적화되지 않은 SQL 문을 포함할 때 특히 명백하다.
- 테이블 파티셔닝(Tables Partitioning) : 대다수의 데이터베이스 관리 시스템은 테이블 파티셔닝을 지원한다. 테이블 파티셔닝은 단일 대형 테이블의 데이터를 여러 디스크로 분할하여 디스크 I/O 활용도를 향상할 수 있다. 분할은 일반적으로 수평으로 수행되며 일부 시스템에서도 수직이 될 수 있다. 이 방법을 사용하면 특정 테이블의 디스크 I/O 병목 현상을 줄일 수 있지만 조인 및 기타 작업 속도가 느려질 수 있다. 또한, 이 방식은 데이터베이스 관리 시스템의 단일 서버 인스턴스에 의존하기 때문에 다른 모든 CPU 및 메모리 경합 제한이 적용되어 확장성이 더욱 제한된다.
- 연합 테이블(Federated Tables) : 테이블 파티셔닝의 파생물은 여러 서버에서 테이블에 엑세스 할 수 있는 연합 테이블 접근 방식이다. 이 방식은 관리가 매우 복잡하며, 네트워크를 통해 엑세스 되어야 하므로 효율성이 떨어진다. 이 방식은 분석 업무에는 효과적일 수 있지만, 일반적인 읽기/쓰기 트랜잭션에는 적합하지 않다.
각주[편집]
- ↑ Cory Isaacson, 〈Database Sharding:The Key to Database Scalability〉, 《DBTA》, 2009-08-14
참고자료[편집]
- 〈DATABASE SHARDING〉, 《AgilData》
- Mark Drake, 〈Understanding Database Sharding〉, 《디지털오션》, 2019-02-07
- PSYCHZNetworks 공식 홈페이지 - https://www.psychz.net/client/kb/en/learn-all-about-database-sharding.html
- Cory Isaacson, 〈Database Sharding:The Key to Database Scalability〉, 《DBTA》, 2009-08-14
같이 보기[편집]
