데이터베이스 샤딩 이해

소개

상당한 성장을 보이는 애플리케이션이나 웹사이트는 결국 트래픽 증가를 수용하기 위해 확장해야 합니다. 데이터 기반 애플리케이션 및 웹 사이트의 경우 데이터의 보안 및 무결성을 보장하는 방식으로 확장이 수행되는 것이 중요합니다. 웹사이트나 애플리케이션이 얼마나 인기를 얻게 될지 또는 얼마나 오래 그 인기를 유지할지 예측하기 어려울 수 있습니다. 그래서 일부 조직에서는 데이터베이스를 동적으로 확장할 수 있는 데이터베이스 아키텍처를 선택합니다.

이 개념 문서에서는 이러한 데이터베이스 아키텍처 중 하나인 분할된 데이터베이스에 대해 설명합니다. 샤딩은 최근 몇 년 동안 많은 관심을 받았지만 많은 사람들이 그것이 무엇인지 또는 데이터베이스를 샤딩하는 것이 타당할 수 있는 시나리오에 대해 명확하게 이해하지 못하고 있습니다. 샤딩이 무엇인지, 몇 가지 주요 장점과 단점, 그리고 몇 가지 일반적인 샤딩 방법에 대해 살펴보겠습니다.

샤딩이란 무엇입니까?

샤딩은 수평 분할과 관련된 데이터베이스 아키텍처 패턴으로, 한 테이블의 행을 파티션이라고 하는 여러 개의 서로 다른 테이블로 분리하는 방식입니다. 각 파티션에는 동일한 스키마와 열이 있지만 완전히 다른 행도 있습니다. 마찬가지로 각각에 보관된 데이터는 고유하며 다른 파티션에 보관된 데이터와 독립적입니다.

수평 분할이 수직 분할과 어떻게 관련되어 있는지 생각하는 것이 도움이 될 수 있습니다. 세로로 분할된 테이블에서는 전체 열이 분리되어 새롭고 고유한 테이블에 배치됩니다. 하나의 수직 파티션에 있는 데이터는 다른 모든 데이터와 독립적이며 각각 고유한 행과 열을 모두 보유합니다. 다음 다이어그램은 테이블을 수평 및 수직 분할하는 방법을 보여줍니다.

샤딩은 데이터를 논리적 샤드라고 하는 두 개 이상의 작은 청크로 나누는 것입니다. 그런 다음 논리적 샤드가 여러 논리적 샤드를 보유할 수 있는 물리적 샤드라고 하는 별도의 데이터베이스 노드에 분산됩니다. 그럼에도 불구하고 모든 샤드 내에 보관된 데이터는 집합적으로 전체 논리적 데이터 세트를 나타냅니다.

데이터베이스 샤드는 비공유 아키텍처의 예입니다. 이는 샤드가 자율적임을 의미합니다. 동일한 데이터나 컴퓨팅 리소스를 공유하지 않습니다. 그러나 경우에 따라 특정 테이블을 각 샤드에 복제하여 참조 테이블로 사용하는 것이 합리적일 수 있습니다. 예를 들어 무게 측정을 위한 고정 전환율에 의존하는 애플리케이션용 데이터베이스가 있다고 가정해 보겠습니다. 필요한 전환율 데이터가 포함된 테이블을 각 샤드에 복제함으로써 쿼리에 필요한 모든 데이터가 모든 샤드에 보관되도록 하는 데 도움이 됩니다.

종종 샤딩은 애플리케이션 수준에서 구현됩니다. 즉, 애플리케이션에는 읽기 및 쓰기를 전송할 샤드를 정의하는 코드가 포함됩니다. 그러나 일부 데이터베이스 관리 시스템에는 샤딩 기능이 내장되어 있어 데이터베이스 수준에서 직접 샤딩을 구현할 수 있습니다.

샤딩에 대한 일반적인 개요를 바탕으로 이 데이터베이스 아키텍처와 관련된 몇 가지 장점과 단점을 살펴보겠습니다.

샤딩의 이점

데이터베이스 샤딩의 주된 장점은 수평 확장이라고도 하는 수평 확장을 촉진하는 데 도움이 될 수 있다는 것입니다. 수평 확장은 로드를 분산하고 더 많은 트래픽과 더 빠른 처리를 허용하기 위해 기존 스택에 더 많은 시스템을 추가하는 방법입니다. 이는 일반적으로 더 많은 RAM 또는 CPU를 추가하여 기존 서버의 하드웨어를 업그레이드하는 확장이라고도 하는 수직적 확장과 대조되는 경우가 많습니다.

관계형 데이터베이스를 단일 시스템에서 실행하고 필요에 따라 컴퓨팅 리소스를 업그레이드하여 확장하는 것은 비교적 간단합니다. 그러나 궁극적으로 비분산 데이터베이스는 스토리지 및 컴퓨팅 성능 측면에서 제한되므로 수평으로 확장할 수 있는 자유가 있으면 설정이 훨씬 더 유연해집니다.

일부 사람들이 샤딩된 데이터베이스 아키텍처를 선택하는 또 다른 이유는 쿼리 응답 시간을 단축하기 위해서입니다. 샤딩되지 않은 데이터베이스에서 쿼리를 제출하면 원하는 결과 집합을 찾기 전에 쿼리 중인 테이블의 모든 행을 검색해야 할 수 있습니다. 대규모 모놀리식 데이터베이스가 있는 애플리케이션의 경우 쿼리가 엄청나게 느려질 수 있습니다. 그러나 하나의 테이블을 여러 테이블로 샤딩하면 쿼리가 더 적은 수의 행을 거쳐야 하고 결과 집합이 훨씬 더 빨리 반환됩니다.

샤딩은 또한 중단의 영향을 완화하여 애플리케이션을 보다 안정적으로 만드는 데 도움이 될 수 있습니다. 애플리케이션이나 웹 사이트가 샤딩되지 않은 데이터베이스에 의존하는 경우 중단으로 인해 전체 애플리케이션을 사용할 수 없게 될 가능성이 있습니다. 그러나 샤딩된 데이터베이스에서는 중단이 단일 샤드에만 영향을 미칠 수 있습니다. 이로 인해 일부 사용자가 애플리케이션 또는 웹 사이트의 일부를 사용할 수 없게 되더라도 전체적인 영향은 여전히 전체 데이터베이스가 충돌하는 경우보다 적습니다.

샤딩의 단점

데이터베이스를 샤딩하면 확장이 더 쉬워지고 성능이 향상될 수 있지만 특정 제한 사항이 부과될 수도 있습니다. 여기서는 이들 중 일부와 샤딩을 모두 피해야 하는 이유에 대해 논의할 것입니다.

샤딩에서 사람들이 직면하는 첫 번째 어려움은 샤딩된 데이터베이스 아키텍처를 적절하게 구현하는 데 따르는 순전히 복잡성입니다. 잘못 수행하면 샤딩 프로세스로 인해 데이터가 손실되거나 테이블이 손상될 수 있는 상당한 위험이 있습니다. 하지만 올바르게 수행된 경우에도 샤딩은 팀의 워크플로에 큰 영향을 미칠 수 있습니다. 사용자는 단일 진입점에서 데이터에 액세스하고 관리하는 대신 여러 샤드 위치에서 데이터를 관리해야 하며, 이는 일부 팀에 잠재적으로 혼란을 줄 수 있습니다.

사용자가 데이터베이스를 샤딩한 후 때때로 직면하는 한 가지 문제는 결국 샤드의 균형이 맞지 않는다는 것입니다. 예를 들어, 두 개의 개별 샤드가 있는 데이터베이스가 있다고 가정해 보겠습니다. 하나는 성이 A에서 M까지의 문자로 시작하는 고객을 위한 것이고 다른 하나는 이름이 N에서 Z까지의 문자로 시작하는 고객을 위한 것입니다. 성이 문자 G로 시작하는 사람들의 수입니다. 따라서 A-M 샤드는 점차 N-Z 샤드보다 더 많은 데이터를 축적하여 애플리케이션 속도가 느려지고 상당 부분의 사용자에게 중단됩니다. A-M 샤드는 데이터베이스 핫스팟으로 알려진 것이 되었습니다. 이 경우 데이터베이스 샤딩의 모든 이점은 속도 저하 및 충돌로 인해 상쇄됩니다. 보다 고른 데이터 배포를 위해 데이터베이스를 복구하고 리샤딩해야 할 수 있습니다.

또 다른 주요 단점은 일단 데이터베이스가 샤딩되면 샤딩되지 않은 아키텍처로 되돌리기가 매우 어려울 수 있다는 것입니다. 샤딩되기 전에 만들어진 데이터베이스의 백업에는 파티셔닝 이후에 기록된 데이터가 포함되지 않습니다. 결과적으로 원래의 샤딩되지 않은 아키텍처를 재구축하려면 새 분할 데이터를 이전 백업과 병합하거나 분할 DB를 다시 단일 DB로 변환해야 합니다. 두 작업 모두 비용과 시간이 많이 소요됩니다.

고려해야 할 마지막 단점은 샤딩이 모든 데이터베이스 엔진에서 기본적으로 지원되지 않는다는 것입니다. 예를 들어 PostgreSQL은 PostgreSQL 데이터베이스를 수동으로 샤딩할 수 있지만 자동 샤딩을 기능으로 포함하지 않습니다. 자동 샤딩을 포함하는 많은 Postgres 포크가 있지만 이러한 포크는 종종 최신 PostgreSQL 릴리스보다 뒤처지고 다른 특정 기능이 부족합니다. MySQL Cluster 또는 MongoDB Atlas와 같은 서비스로서의 특정 데이터베이스와 같은 일부 특수 데이터베이스 기술에는 기능으로 자동 샤딩이 포함되어 있지만 이러한 데이터베이스 관리 시스템의 바닐라 버전에는 포함되어 있지 않습니다. 이 때문에 샤딩에는 \자신만의\ 접근 방식이 필요한 경우가 많습니다. 즉, 샤딩에 대한 설명서나 문제 해결 팁을 찾기가 어려운 경우가 많습니다.

물론 이것들은 샤딩 전에 고려해야 할 몇 가지 일반적인 문제일 뿐입니다. 사용 사례에 따라 데이터베이스 샤딩에 더 많은 잠재적인 단점이 있을 수 있습니다.

이제 샤딩의 몇 가지 단점과 이점을 다루었으므로 샤딩된 데이터베이스에 대한 몇 가지 다른 아키텍처를 살펴보겠습니다.

샤딩 아키텍처

데이터베이스를 샤딩하기로 결정했다면 다음으로 알아내야 할 것은 샤딩 방법입니다. 쿼리를 실행하거나 수신 데이터를 샤딩된 테이블 또는 데이터베이스에 배포할 때 올바른 샤드로 이동하는 것이 중요합니다. 그렇지 않으면 데이터가 손실되거나 쿼리가 매우 느려질 수 있습니다. 이 섹션에서는 각각 약간 다른 프로세스를 사용하여 샤드 간에 데이터를 배포하는 몇 가지 일반적인 샤딩 아키텍처를 살펴보겠습니다.

키 기반 샤딩

해시 기반 샤딩이라고도 하는 키 기반 샤딩은 새로 작성된 데이터(예: 고객의 ID 번호, 클라이언트 애플리케이션의 IP 주소, ZIP)에서 가져온 값을 사용합니다. 코드 등 — 해시 함수에 연결하여 데이터를 어느 샤드로 보내야 하는지 결정합니다. 해시 함수는 데이터(예: 고객 이메일)를 입력으로 받아 해시 값이라고 하는 개별 값을 출력하는 함수입니다. 샤딩의 경우 해시 값은 수신 데이터를 저장할 샤드를 결정하는 데 사용되는 샤드 ID입니다. 전체적으로 프로세스는 다음과 같습니다.

항목이 올바른 샤드에 일관된 방식으로 배치되도록 하려면 해시 함수에 입력된 값이 모두 동일한 열에서 나와야 합니다. 이 열을 샤드 키라고 합니다. 간단히 말해서 분할 키는 개별 행의 고유 식별자를 설정하는 데 사용되는 열이라는 점에서 기본 키와 비슷합니다. 대체로 샤드 키는 정적이어야 합니다. 즉, 시간이 지남에 따라 변경될 수 있는 값을 포함해서는 안 됩니다. 그렇지 않으면 업데이트 작업에 들어가는 작업량이 증가하고 성능이 느려질 수 있습니다.

키 기반 샤딩은 상당히 일반적인 샤딩 아키텍처이지만 데이터베이스에 추가 서버를 동적으로 추가하거나 제거하려고 할 때 까다로울 수 있습니다. 서버를 추가할 때 각각 해당하는 해시 값이 필요하고 기존 항목의 전부는 아니더라도 많은 항목을 올바른 새 해시 값으로 다시 매핑한 다음 적절한 서버로 마이그레이션해야 합니다. 데이터 재조정을 시작하면 새 해싱 함수와 이전 해싱 함수가 모두 유효하지 않습니다. 결과적으로 서버는 마이그레이션 중에 새 데이터를 쓸 수 없으며 애플리케이션이 가동 중지될 수 있습니다.

이 전략의 주요 매력은 핫스팟을 방지하기 위해 데이터를 고르게 분배하는 데 사용할 수 있다는 것입니다. 또한 알고리즘 방식으로 데이터를 배포하기 때문에 범위 또는 디렉토리 기반 샤딩과 같은 다른 전략에서 필요한 것처럼 모든 데이터가 있는 위치의 맵을 유지할 필요가 없습니다.

범위 기반 샤딩

범위 기반 샤딩에는 주어진 값의 범위를 기반으로 데이터를 샤딩하는 작업이 포함됩니다. 설명을 위해 소매업체 카탈로그 내의 모든 제품에 대한 정보를 저장하는 데이터베이스가 있다고 가정해 보겠습니다. 다음과 같이 몇 가지 다른 샤드를 생성하고 해당 가격 범위에 따라 각 제품의 정보를 나눌 수 있습니다.

범위 기반 샤딩의 주요 이점은 구현이 상대적으로 간단하다는 것입니다. 모든 샤드는 서로 다른 데이터 세트를 보유하지만 원본 데이터베이스뿐만 아니라 서로 동일한 스키마를 가집니다. 애플리케이션 코드는 데이터가 어느 범위에 속하는지 읽고 해당 샤드에 씁니다.

반면에 범위 기반 샤딩은 데이터가 고르지 않게 분산되는 것을 보호하지 못하여 앞서 언급한 데이터베이스 핫스팟으로 이어집니다. 예제 다이어그램을 보면 각 샤드가 동일한 양의 데이터를 보유하더라도 특정 제품이 다른 제품보다 더 많은 관심을 받을 가능성이 있습니다. 차례로 각각의 샤드는 불균형한 수의 읽기를 받게 됩니다.

디렉토리 기반 샤딩

디렉토리 기반 샤딩을 구현하려면 샤드 키를 사용하여 어느 샤드가 어떤 데이터를 보유하고 있는지 추적하는 조회 테이블을 만들고 유지 관리해야 합니다. 조회 테이블은 특정 데이터를 찾을 수 있는 위치에 대한 정적 정보 세트를 보유하는 테이블입니다. 다음 다이어그램은 디렉터리 기반 샤딩의 단순한 예를 보여줍니다.

여기서 Delivery Zone 열은 샤드 키로 정의됩니다. 샤드 키의 데이터는 각각의 행이 기록되어야 하는 샤드와 함께 조회 테이블에 기록됩니다. 이는 범위 기반 샤딩과 유사하지만 샤드 키의 데이터가 속하는 범위를 결정하는 대신 각 키가 고유한 샤드에 연결됩니다. 디렉터리 기반 샤딩은 샤드 키의 카디널리티가 낮고(즉, 가능한 값의 수가 적고) 샤드가 키 범위를 저장하는 것이 이치에 맞지 않는 경우 범위 기반 샤딩보다 좋은 선택입니다. 또한 해시 함수를 통해 샤드 키를 처리하지 않는다는 점에서 키 기반 샤딩과 구별됩니다. 조회 테이블과 비교하여 키를 확인하여 데이터를 작성해야 하는 위치를 확인합니다.

디렉터리 기반 샤딩의 주요 매력은 유연성입니다. 범위 기반 샤딩 아키텍처는 값의 범위를 지정하도록 제한하는 반면, 키 기반 아키텍처는 앞에서 언급한 것처럼 나중에 변경하기가 매우 어려울 수 있는 고정 해시 함수를 사용하도록 제한합니다. 반면에 디렉터리 기반 샤딩을 사용하면 데이터 항목을 샤드에 할당하려는 모든 시스템이나 알고리즘을 사용할 수 있으며 이 접근 방식을 사용하여 샤드를 동적으로 추가하는 것이 상대적으로 쉽습니다.

디렉터리 기반 샤딩은 여기에서 논의된 샤딩 방법 중 가장 유연한 반면 모든 쿼리 또는 쓰기 전에 조회 테이블에 연결해야 하는 필요성은 애플리케이션의 성능에 해로운 영향을 미칠 수 있습니다. 또한 조회 테이블은 단일 실패 지점이 될 수 있습니다. 테이블이 손상되거나 실패하면 새 데이터를 쓰거나 기존 데이터에 액세스하는 능력에 영향을 미칠 수 있습니다.

샤딩해야 할까요?

샤딩된 데이터베이스 아키텍처를 구현해야 하는지 여부는 거의 항상 논쟁거리입니다. 어떤 사람들은 샤딩이 특정 크기에 도달하는 데이터베이스에 대한 불가피한 결과라고 보는 반면, 다른 사람들은 샤딩이 추가하는 운영 복잡성으로 인해 절대적으로 필요한 경우가 아니면 피해야 하는 골칫거리라고 생각합니다.

이렇게 추가된 복잡성으로 인해 샤딩은 일반적으로 매우 많은 양의 데이터를 처리할 때만 수행됩니다. 다음은 데이터베이스를 샤딩하는 것이 도움이 될 수 있는 몇 가지 일반적인 시나리오입니다.

• 애플리케이션 데이터의 양이 증가하여 단일 데이터베이스 노드의 스토리지 용량을 초과합니다.
• 데이터베이스에 대한 쓰기 또는 읽기 볼륨이 단일 노드 또는 해당 읽기 복제본이 처리할 수 있는 양을 초과하여 응답 시간 또는 시간 초과가 느려집니다.
• 애플리케이션에 필요한 네트워크 대역폭이 단일 데이터베이스 노드 및 모든 읽기 전용 복제본에서 사용할 수 있는 대역폭을 초과하므로 응답 시간 또는 시간 초과가 느려집니다.

샤딩하기 전에 데이터베이스 최적화를 위한 다른 모든 옵션을 소진해야 합니다. 고려할 수 있는 몇 가지 최적화는 다음과 같습니다.

• 원격 데이터베이스 설정. 모든 구성 요소가 동일한 서버에 있는 모놀리식 애플리케이션으로 작업하는 경우 데이터베이스를 자체 시스템으로 이동하여 데이터베이스의 성능을 향상시킬 수 있습니다. 이것은 데이터베이스의 테이블이 그대로 유지되기 때문에 샤딩만큼 복잡하지 않습니다. 그러나 나머지 인프라와 별도로 데이터베이스를 수직으로 확장할 수 있습니다.
• 캐싱 구현. 애플리케이션의 읽기 성능이 문제의 원인이라면 캐싱은 이를 개선하는 데 도움이 될 수 있는 전략 중 하나입니다. 캐싱에는 메모리에 이미 요청된 데이터를 임시로 저장하여 나중에 훨씬 더 빠르게 액세스할 수 있습니다.
• 하나 이상의 읽기 전용 복제본 생성. 읽기 성능을 향상시키는 데 도움이 될 수 있는 또 다른 전략은 하나의 데이터베이스 서버(주 서버)에서 하나 이상의 보조 서버로 데이터를 복사하는 것입니다. 그런 다음 모든 새 쓰기는 보조 서버로 복사되기 전에 기본 서버로 이동하고 읽기는 보조 서버로만 이루어집니다. 이와 같이 읽기 및 쓰기를 분산하면 한 시스템이 너무 많은 부하를 받지 않도록 하여 속도 저하 및 충돌을 방지할 수 있습니다. 읽기 전용 복제본을 생성하려면 더 많은 컴퓨팅 리소스가 필요하므로 비용이 더 많이 들기 때문에 일부에게는 상당한 제약이 될 수 있습니다.
• 더 큰 서버로 업그레이드. 대부분의 경우 데이터베이스 서버를 더 많은 리소스가 있는 시스템으로 확장하는 데 샤딩보다 노력이 덜 듭니다. 읽기 전용 복제본을 생성할 때와 마찬가지로 리소스가 더 많은 업그레이드된 서버는 비용이 더 많이 듭니다. 따라서 실제로 크기 조정이 최선의 선택인 경우에만 크기 조정을 진행해야 합니다.

응용 프로그램이나 웹 사이트가 특정 지점을 넘어 성장하면 이러한 전략 중 어느 것도 자체적으로 성능을 향상시키기에 충분하지 않다는 점을 명심하십시오. 이러한 경우 샤딩이 실제로 최선의 선택일 수 있습니다.

결론

샤딩은 데이터베이스를 수평으로 확장하려는 사람들에게 훌륭한 솔루션이 될 수 있습니다. 그러나 그것은 또한 많은 복잡성을 추가하고 응용 프로그램에 더 많은 잠재적 실패 지점을 생성합니다. 일부에게는 샤딩이 필요할 수 있지만 샤딩된 아키텍처를 만들고 유지 관리하는 데 필요한 시간과 리소스가 다른 사람들에게는 이점보다 클 수 있습니다.

이 개념 문서를 읽으면 샤딩의 장단점을 더 명확하게 이해할 수 있습니다. 앞으로 이 통찰력을 사용하여 샤딩된 데이터베이스 아키텍처가 애플리케이션에 적합한지 여부에 대해 더 많은 정보에 입각한 결정을 내릴 수 있습니다.