이전 포스팅에서 로깅을 활용해서 시스템 장애 시 데이터베이스를 어떻게 복구하는지 살펴봤습니다. 이번 포스팅에서는 분산 데이터베이스에 대해 살펴보겠습니다.
Distributed Database
데이터베이스 노드가 네트워크로 연결돼서 데이터베이스 기능을 제공하는 형태를 분산 데이터베이스라고 합니다. 노드 간 통신이 네트워크를 통해 이뤄지므로 통신 비용을 고려해야 합니다.
System Architecture
분산 데이터베이스는 다음과 같이 구성할 수 있습니다. 하나씩 살펴보겠습니다.
Shared Memory
데이터베이스 노드가 네트워크를 통해 하나의 메모리를 공유하는 형태입니다. 데이터베이스 노드는 하나의 메모리에 적재된 데이터를 공유합니다.
Shared Disk
네트워크를 통해 디스크를 공유하는 형태입니다. 공유 데이터 변경이 필요할 때 노드끼리 통신해서 공유 데이터를 조작합니다. 예를 들어 1번과 2번 데이터베이스 노드가 존재하고 각 노드의 메모리에 A라는 데이터가 적재됐다고 가정하겠습니다. 만약 A라는 데이터를 변경하는 요청이 1번 노드에 들어오면 1번 노드는 디스크에 저장된 A 데이터를 변경하는 동시에 2번 노드에 A라는 데이터가 변경됐음을 알려야 합니다.
Shared disk 구조를 활용하는 데이터베이스로는 Amazon Aurora, Amazon Redshift, HBase와 Google spanner가 있습니다.
Shared Nothing
모든 데이터베이스 노드는 독립적인 cpu, memory, disk를 소유합니다. 성능은 좋을지 몰라도 데이터의 일관성을 유지하는 게 쉽지 않습니다.
Shared nothing 구조를 활용하는 데이터베이스로는 Apache Cassandra, Cockroach DB, Redis, VoltDB와 MongoDB가 있습니다.
Database Design
데이터베이스 노드가 어떤 기능을 제공할 수 있는지에 따라 분류할 수 있습니다.
Homogenous Nodes
Homogenous(균질적인) nodes로 구성된 분산 데이터베이스의 노드는 모두 동일한 기능을 제공합니다. Heterogenous nodes에 비해 provisioning과 failover 기능을 비교적 쉽게 구현할 수 있습니다.
Heterogenous Nodes
Heterogenous(이질적인) nodes로 구성된 분산 데이터베이스는 각각의 노드가 서로 다른 기능을 제공합니다. 노드는 특별한 역할이 부여됩니다. 대표적인 예로 MongoDB가 있습니다.
MongoDB를 클러스터는 다음과 같이 구성됩니다.
- Primary node: 클라이언트로부터 쓰기 요청을 처리하는 노드입니다. MongoDB의 클러스터에는 오직 하나의 primary node만 존재할 수 있습니다.
- Secondary nodes: Primary node에 저장된 데이터를 복제하고 primary node 실패 시 back up으로 활용됩니다.
- Arbiter node: Primary node election에 활용되는 노드입니다.
- Config servers: 클러스터 메타데이터를 저장합니다. 클러스터가 정상적으로 동작하기 위해서 필수적입니다.
- Mongos: 클라이언트의 요청을 처리할 수 있는 클러스터 내 node로 요청을 라우팅 합니다.
Distributing Data
다음으로는 분산 데이터베이스 환경에서 데이터가 어떻게 분산되는지 살펴보겠습니다.
Horizontal/Vertical Partitioning
Horizontal/Vertical Partitioning은 하나의 테이블을 나누는 방법입니다. 이에 대한 자세한 설명은 이전 포스팅을 참고해주세요.
https://code-run.tistory.com/32#3.3.%20Partitioning%C2%A0
Sharding
Sharding이란 같은 테이블 스키마를 가진 데이터를 다수의 데이터베이스 노드에 수평 분할하여 저장하는 방식입니다. 샤딩 과정에서 데이터를 저장할 노드를 결정하기 위해 다양한 알고리즘을 사용하는데요, 각각 알고리즘에 대해 살펴보겠습니다.
Key Based Sharding
데이터와 연관된 특정 키에 해시값을 적용해서 데이터를 저장할 노드를 선택하는 방식입니다. 키를 활용한 데이터 검색 속도는 빠르지만 range 검색 속도는 느리다는 단점이 존재합니다.
Range Based Sharding
데이터의 특정 속성(attribute)을 기준으로 범위를 나눠서 데이터베이스 노드에 저장하는 방식입니다. Range 검색 속도가 빠르다는 장점이 있습니다. 만약 특정 범위에 데이터가 몰리게 되면 해당 범위의 데이터를 저장하는 노드에 데이터가 몰릴 가능성이 있습니다.
Hash Based Sharding
저장하고자 하는 데이터에 그 자체에 해시를 적용한 값을 활용해서 데이터를 저장할 노드를 선택하는 방식입니다.
Consistent Hashing
위에서 소개드린 sharding 방식의 단점은 새로운 노드가 추가되거나 제외되는 경우 re-sharding에 참여하는 노드의 수가 많다는 점입니다. 데이터의 양이 많으면 많을수록 re-sharding 작업에 소요되는 시간이 점차 증가합니다. Consistent hashing은 새로운 노드가 추가되거나 제외되더라도 re-sharding에 관여하는 노드를 최소화할 수 있는 sharding 방식입니다.
Consistent hashing을 이해하기 위한 비유를 들어보겠습니다. 8명의 종업원들이 원의 형태로 서있다고 생각해봅시다. 각각의 종업원은 시계방향을 바라보고 있습니다. 손님은 매장에 들어가 주문을 하려고 할 때 안내에 따라 특정 종업원 앞으로 갑니다. 손님은 마주 볼 수 있는 종업원 중 가장 가까운 종업원에게 주문을 하게 됩니다.
8명의 종업원 중 1명이 아파서 일을 못하게 되면 그 종업원의 반시계 방향에 서있는 종업원이 아픈 종업원이 담당할 손님의 주문을 받게 됩니다. 만약 새로운 종업원이 추가되면 새로운 종업원이 자신의 오른쪽에 위치한 손님의 주문을 처리합니다. 새로운 종업원은 (왼쪽에 위치한) 기존 종업원이 담당해야 하는 손님의 주문 수를 줄이게 됩니다.
Consistent hashing를 적용한 분산 데이터베이스에서 각각의 노드는 종업원에, 클라이언트는 손님에 그리고 종업원이 사라지거나 추가되는 경우는 데이터베이스 노드의 삭제와 추가에 비유할 수 있습니다. Consistent hashing을 활용하면 노드의 추가 또는 삭제가 발생하더라도 re-sharding이 필요한 데이터의 수나 노드를 한정시킬 수 있습니다.
Distributed Transaction
다음으로는 분산 데이터베이스 환경에서 트랜잭션을 어떻게 처리하는지 살펴보겠습니다.
Centralized Coordinator
첫 번째 방법은 centralized coordinator을 활용하는 형태입니다. Centralized coordinator을 활용한 분산 트랜잭션은 다음과 같이 동작합니다.
- 클라이언트는 coordinator에게 트랜잭션을 요청합니다.
- Coordinator는 트랜잭션 처리에 참여할 노드를 결정합니다.
- Coordinator는 트랜잭션에 참여하는 노드들에게 트랜잭션과 연관된 데이터에 적절한 잠금을 설정하라고 지시합니다.
- Coordinator가 트랜잭션에 참여하는 모든 노드로부터 트랜잭션 시작이 준비 완료됐음을 수신하면 각각의 노드에게 트랜잭션을 수행하라고 지시합니다.
- 트랜잭션에 참여하는 노드들은 트랜잭션에 필요한 작업을 수행합니다.
- 만약 참여하는 노드 중 하나라도 실패가 발생하면 coordinator는 모든 노드들에게 rollback을 지시합니다.
Decentralized Coordinator
첫 번째 방법과 달리 centralized coordinator 없이도 노드 간 통신을 통해서 트랜잭션을 처리하는 방법입니다. Decentralized transaction은 다음과 같이 동작합니다.
- 클라이언트는 클러스터에 트랜잭션 요청을 보냅니다.
- 트랜잭션에 참여할 노드들은 트랜잭션과 관련된 데이터에 잠금을 설정합니다.
- 모드 노드가 트랜잭션을 처리할 준비가 완료되면 트랜잭션과 관련된 작업을 수행합니다.
- 만약 노드 중 하나라도 실패가 발생하면 다른 노드들과 통신해서 rollback을 수행합니다.
마무리
이번 포스팅을 통해 분산 데이터베이스 시스템이 어떻게 구성되고 어떻게 동작하는지 간단하게 살펴봤습니다. 다음 포스팅에서도 분산 데이터베이스 시스템에 대해 조금 더 상세히 알아보겠습니다.
'Database > DBA급 개발자로' 카테고리의 다른 글
[Database] DBA급 개발자로 - #23 Distributed Database 3/3 (0) | 2022.12.16 |
---|---|
[Database] DBA급 개발자로 - #22 Distributed Database 2/3 (2) | 2022.12.10 |
[Database] DBA급 개발자로 - #20 Database Recovery (0) | 2022.12.05 |
[Database] DBA급 개발자로 - #19 Database Logging (0) | 2022.12.04 |
[Database] DBA급 개발자로 - #18 Mutli-Version Concurrency Control (0) | 2022.11.14 |