Published 2022. 12. 10. 09:54

[Database] DBA급 개발자로 - #22 Distributed Database 2/3

728x90

이전 포스팅에서 분산 데이터베이스에 대해 간략히 살펴봤습니다. 이번 포스팅에서는 분산 트랜잭션 커밋을 어떻게 atomic 하게 처리할지, 복제는 어떻게 하는지 그리고 CAP 이론에 대해 살펴보겠습니다.

Atomic Commit Protocol

분산 트랜잭션을 커밋하기 위해서는 모든 노드가 작업을 정상적으로 처리했는지 확인해야 합니다. 분산 환경에서 atomic 한 커밋을 보장하기 위한 프로토콜에는 two phase commit, three phase commit, paxos, raft, ZAP(apache zookeeper)과 viewstamped replication 등이 존재합니다. 이번 포스팅에서는 two phase commit과 paxos에 대해 살펴보겠습니다.

Two Phase Commit

Two phase commit은 이름에서 볼 수 있듯 트랜잭션 커밋 과정을 크게 두 과정, prepare(준비) phase와 commit phase로 구분합니다. Two phase commit protocol은 다음과 같이 동작합니다.

클라이언트가 데이터베이스 노드에 트랜잭션 처리를 요청합니다.
데이터베이스 노드는 자신이 coordinator인 경우 해당 요청을 처리할 준비를 하고 coordinator이 아닌 경우 coordinator에게 요청을 라우팅 합니다.
Coordinator은 prepare 단계를 시작합니다. Prepare 단계에서는 트랜잭션 처리에 필요한 모든 노드에게 prepare 메시지를 송신합니다.
Prepare 메시지를 수신한 노드는 트랜잭션에 의한 변경사항을 각각의 로컬 저장소(log 또는 journal)에 저장합니다. 변경사항 저장을 완료하면 coordinator에게 성공 응답을 반환합니다.
Coordinator가 관련된 노드로부터 받은 응답이 모두 성공이라면 다음 단계를 준비합니다. 만약 하나라도 실패하는 경우 관련된 모든 노드에게 roll back 메시지를 송신합니다.
Coordinator은 관련된 모든 노드에게 commit 메시지를 송신합니다.
Commit 메시지를 수신한 각각의 노드는 변경사항을 반영합니다. 성공적으로 데이터를 반영하면 성공 응답을 coordinator에게 반환합니다.
Coordinator가 모든 노드로부터 성공 응답을 받게 되면 최종적으로 commit 메시지를 한번 더 보내게 됩니다. 해당 메시지를 수신한 노드는 log 또는 journal에 임시로 저장했던 데이터를 삭제할 수 있습니다.

Two phase commit 과정에서 coordinator 또는 참여하는 노드에 장애가 발생하는 경우 데이터의 일관성을 유지하기 위해 대체적으로는 진행 중인 트랜잭션을 rollback 시킵니다.

Paxos

Paxos는 분산 환경에서 특정 값에 대한 consensus(합의)를 도출해내기 위한 프로토콜입니다. Paxos 프로토콜에는 acceptor와 proposer 유형의 참여자가 존재합니다. Acceptors는 proposers에 의해 제안된 값들 중 하나의 값을 결정합니다. Paxos는 이러한 합의 과정을 다음과 같은 단계로 나눠서 진행합니다.

Proposer	Acceptor
Prepare 단계입니다. Proposer이 모든 acceptor에게 prepare 메시지를 송신합니다. Prepare 메시지는 proposer가 acceptor에게 특정 값(value)을 제안(propose)하기 위해서 보내는 메시지입니다.
	Promise 단계입니다. 각각의 acceptor는 prepare 메시지를 수신했고 수신된 값이 (합의에 의해) 선택된다면 해당 값을 사용할 것을 약속하는 단계입니다. Acceptor는 promise 메시지를 반환합니다.
Accept 단계입니다. Promise 메시지를 수신한 proposer는 acceptor들에게 자신이 보낸 값을 accept 하라고 accept 메시지를 송신합니다.
	Accepted 단계입니다. Accept 메시지를 수신한 acceptor가 해당 proposer이 제안한 값을 승인하기로 결정했다면 acceptor은 accepted 메시지를 proposer에게 반환합니다.
Proposer가 대다수의 acceptor들로부터 accepted 메시지를 수신했다면 해당 값이 합의가 된 값으로 인식합니다.

그럼 분산 데이터베이스 환경에서 paxos를 적용하면 어떻게 동작하는지 살펴보겠습니다.

Coordinator	Node
클라이언트는 데이터 변경 요청을 보내면 해당 요청은 coordinator에게 전달됩니다.
Coordinator는 클러스터의 노드들에게 제안된 변경사항을 반영할 준비를 하라고 prepare 메시지를 송신합니다.
	Prepare 메시지를 수신한 노드들은 제안된 변경사항을 받아들일 준비가 되면 promise 메시지를 반환합니다.
Coordinator는 노드들이 제안된 변경 요청을 accept 하도록 accept 메시지를 송신합니다.
	각 노드는 coordinator의 accept 요청을 받고, 요청된 변경사항을 accept 한다면 accepted 메시지를 반환합니다.
Coordinator가 대다수(majority)의 노드로부터 accepted 메시지를 수신하면 coordinator가 제안한 변경사항을 최종 반영할 준비를 합니다. Coordinator는 각 노드들이 변경사항을 로컬 저장소에 반영하도록 commit 메시지를 송신합니다.
	Commit 메시지를 수신한 노드는 각각의 로컬 저장소에 변경사항을 반영합니다. 로컬 저장소에 변경사항을 반영한 노드는 최종적으로 coordinator에 committed 메시지를 반환합니다.

Paxos 프로토콜의 장점은 몇몇 acceptor에 장애가 발생하더라도 합의과정을 진행할 수 있다는 점입니다. Paxos 프로토콜을 활용하는 대표적인 예시로는 Apache Cassandra, Google Cloud Bigtable, Zookeeper, Amazon DynamoDB, Microsoft Azure Cosmos DB 등이 있습니다.

Replication

데이터의 복제를 통해 DBMS의 고가용성을 보장할 수 있습니다. 그럼 데이터 복제를 어떻게 수행하는지 살펴보겠습니다.

Replica Configuration

복제를 위해서 클러스터를 어떻게 설정하는지에 따라 primary-replica, multi-primary 방식으로 구분할 수 있습니다.

Primary Replica

변경 요청은 primary 노드만 처리할 수 있습니다. Primary 노드에서 처리한 변경사항은 replica에게 전달됩니다. Replica 노드는 오직 읽기 요청만 처리할 수 있습니다.

Multi-Primary

변경 요청을 클러스터 내 모든 노드에서 처리할 수 있습니다. 모든 노드에서 변경 요청을 처리할 수 있기 때문에 수정된 데이터에 대한 동기화가 필요합니다.

K-Safety

분산 데이터베이스 환경에서 최대 k개의 노드에 장애가 발생하더라도 정상적으로 동작할 때 "k-safe"하다고 간주됩니다. K값은 해당 데이터베이스를 활용하는 애플리케이션의 요구사항에 맞춰 설정됩니다. 만약 고가용성을 보장해야 하는 상황이라면 높은 K값이 책정됩니다(많은 수의 노드에 장애가 발생하더라도 정상적으로 동작하기 때문입니다).

Propagation Timing

Primary에 반영된 변경사항을 복제 데이터베이스에 어느 시점에 전달하는지를 기준으로 다음과 같이 구분할 수 있습니다.

Continuous

Continuous propagation은 primary 노드에서 변경사항이 반영되는 즉시 복제 데이터베이스로 변경사항을 전송합니다. Abort와 commit 과정에도 생긴 로그도 복제 데이터베이스로 전송합니다.

On Commit

Primary는 커밋 시점에 변경사항을 전송합니다. Continuous propagation과 달리 트랜잭션 abort의 경우 복제 데이터베이스로 변경사항을 전송할 필요가 없습니다.

Propagation Scheme

요청된 변경사항을 복제 데이터베이스에 반영되는 것을 기다릴지 또는 기다리지 않을지에 따라 분류할 수 있습니다.

Synchronous

Primary 노드는 클라이언트 요청에 의한 변경사항이 복제 데이터베이스에 반영이 됐는지 확인하고 응답을 반환합니다. 클라이언트가 응답을 반환받은 시점에는 모든 노드에 변경사항이 반영됐기 때문에 strong consistency를 보장한다고 볼 수 있습니다.

Asynchronous

Primary 노드는 클라이언트 요청에 의한 변경사항이 복제 데이터베이스에 반영됐는지 확인하지 않고도 응답을 반환합니다. 클라이언트가 응답을 반환받은 시점에 모든 노드에 변경사항이 반영된 것이 아니기 때문에 eventual consistent 하다고 볼 수 있습니다.

Active VS Passive

Active - Active

모든 복제 데이터베이스에서 트랜잭션이 각각 실행됩니다. 트랜잭션에 의한 변경사항이 모든 노드에서 동일한지 확인하는 과정이 필요합니다.

Active - Passive

트랜잭션의 실행은 하나의 노드에서만 실행되고 트랜잭션에 의한 최종 결과가 복제 데이터베이스로 전송됩니다.

CAP theorem

CAP 이론은 분산 환경이 다음과 세 가지 특징을 동시에 만족할 수 없음을 주장합니다.

Consistency: 노드에 저장된 모든 데이터는 consistency를 유지합니다. 특정 데이터가 변경됐다면 모든 노드에 해당 데이터를 요청했을 때 동일한 값을 반환해야 합니다..
Availability: 몇몇 노드에 장애가 발생하더라도 클라이언트의 요청을 처리할 수 있어야 합니다.
Partition tolerance: 네트워크 장애로 인해 노드 간 통신이 불가능하더라도 시스템이 정상적으로 동작할 수 있어야 합니다.

CAP 이론에 따르면 위 세 가지 조건을 동시에 만족하는 건 불가능합니다. 따라서 분산 시스템의 설계할 때 용도나 요구사항에 맞게 위 특징을 적절히 조합하여(trade-off를 고려해서) 설계해야 합니다.

예를 들어보겠습니다. 돈을 거래하는 시스템의 경우 consistency가 매우 중요합니다. 각각의 노드에서 서로 다른 금액을 저장하면 비정상적인 금융 거래가 발생할 수 있기 때문입니다. 하지만 강한 consistency를 유지하기 위해서는 모든 노드에 변경사항이 제대로 반영됐는지 확인해야 합니다. 만약 몇몇 노드에 장애가 발생해서 consistency를 유지할 수 없으면 해당 시스템은 사용할 수 없습니다. 즉 강한 consistency를 유지하기 위해서 availability를 어느 정도 타협하는 형태로 시스템을 설계하게 됩니다.

마무리

이번 포스팅을 통해 분산 시스템에서 활용하는 다양한 프로토콜과 복제 방법, 그리고 분산 시스템 설계의 토대가 되는 이론인 CAP 이론에 대해 살펴봤습니다. 다음 포스팅에서는 분산 환경에서의 OLAP 시스템에 대해 살펴보겠습니다.