본문 바로가기
💻 개발 이야기/DevOps(Infra)

[Infra] 분산 시스템에서의 일관성(Consistency) 이야기

by Jinseong Hwang 2024. 2. 18.

 
안녕하세요!!
 
최근 AWS Lambda와 DynamoDB에 대한 세션에 참여했는데, DynamoDB에 일관성 개념이 잘 이해되지 않아서 정리해 봤습니다. 뿐만 아니라 컴퓨터 시스템에서 일관성(Consistency)이 굉장히 중요한 개념이기 때문에 요리조리 알아보도록 하겠습니다.
 
 

이 글에서 얻을 수 있는 것

  • 분산 시스템 환경, 데이터 관점에서 일관성을 지키는 방법에 대해 이해할 수 있다.
  • CAP 이론에 대해 이해할 수 있다.
  • ACID, BASE 트랜잭션 모델에 대해 이해할 수 있다.
  • 3가지 일관성 모델에 대해 이해할 수 있다.

 
 

트랜잭션과 일관성

DB 트랜잭션을 공부해보신 분이라면 ACID라는 단어를 들어보신 적이 있을 것입니다. ACID의 C가 Consistency, 일관성을 의미합니다. 트랜잭션이 데이터를 변경할 때 트랜잭션 전, 후로 일관되고 유효한 상태를 유지해야 한다는 것을 의미합니다.
 
User 테이블에 age라는 컬럼이 있는데 이 컬럼은 항상 정수 값만 저장할 수 있다고 가정합시다. 트랜잭션을 통해 age 값을 변경하려 할 때, "스무살" 이라는 문자열 값으로 저장할 수 없습니다. 이는 트랜잭션의 기본 성질인 Consistency에 위배되기 때문입니다.
 
 

CAP 이론

우선 CAP 이론에 대해서 짚고 넘어갑시다.

위와 같이 데이터베이스 클러스터가 구성되어 있다고 가정합시다.
 

Consistency (일관성)

일관성이란 클러스터 내 모든 노드가 동일한 데이터를 가지고 있음을 의미합니다. 일관성을 만족하기 위해서는 데이터가 하나의 노드에 기록될 때마다 클러스터의 모든 노드로 데이터가 복제되어야 합니다. 따라서 트랜잭션이 끝나기 전에 모든 노드로 데이터의 전파가 이뤄져야 합니다.
 
일관성이 만족될 때 클러스터 내 모든 노드는 "언제나" 동일한 데이터를 가지고 있음이 보장되고, 클라이언트는 어떤 노드에 접근해도 일관된 데이터를 받을 수 있음이 보장됩니다.
 

Availability (가용성)

가용성이란 하나 이상의 노드가 작동을 멈춰도 응답을 받을 수 있음을 의미합니다.
 
Master 노드가 작동을 멈출 경우, 즉시 투표를 거쳐 Slave 노드 중 Master를 선출하고 승격하는 과정이 필요합니다. Slave 노드가 작동을 멈출 경우, 여분의 Slave 노드와 Master 노드가 그 역할을 대신할 수 있어야 합니다.
 
가용성이 만족될 때 클라이언트는 해당 클러스터에 믿고 요청을 보낼 수 있게 됩니다. 높은 신뢰도는 인프라 뿐만 아니라 비즈니스 측면에서도 굉장히 중요합니다. (넓은 범위에서) 서비스가 신뢰를 잃으면 비즈니스가 실패할 확률이 굉장히 높아집니다. (특히 금융 서비스..)
 

Partition tolerance (분할 내성)

분할 내성에서 말하는 분할은 분산 시스템 내에서 노드 간 연결이 끊기거나 지연되는 것을 의미합니다. 분할 내성이란 분산 시스템에서 분할이 발생해도 클러스터는 계속 작동하는 것을 의미합니다.
 
 
여기서 CAP 이론이란 3가지 특성을 모두 만족하는 것은 불가능하며, 2가지만 만족할 수 있음을 의미합니다.
각 경우에 대해 가볍게 살펴봅시다.
 

CP

가용성을 희생시키면서 일관성과 분할 내성을 만족합니다. 두 노드 간 분할이 발생하면 클러스터는 분할이 해소될 때까지 일관성을 잃은 노드를 종료해야 합니다. 즉, 연결이 복구되고 동기화가 완료되기 전까진 클러스터에 노드가 합류할 수 없음을 의미합니다. MongoDB는 CP 저장소입니다.
 

AP

일관성을 희생시키면서 가용성과 분할 내성을 만족합니다. 분할이 발생하면 일부 노드는 오래된 데이터를 가지고 있을 수 있습니다. 일반적으로 이 경우에는 분할이 해결됐을 때 노드를 동기화하는 과정을 거쳐서 일관성 문제를 만족시킵니다. CassandraDB는 AP 저장소입니다.
 

CA

분할 내성을 희생시키면서 일관성과 가용성을 만족합니다. 그러나 시스템에 있는 두 노드 사이에 분할이 생기면 일관성과 가용성 모두 만족할 수 없기 때문에 내결함성(Fault tolerance)을 만족할 수 없습니다.
 
결국 분산 시스템에서는 분할을 피할 수 없기 때문에 CA 타입은 존재할 수 없습니다. 이론상으로 가능하나 현실적으로 불가능합니다. 하지만 대부분의 관계형 데이터베이스는 일관성과 가용성을 만족하고, 복제(replication)를 통해 여러 노드에 배치할 수 있습니다. 이러한 방식으로 상호보완 할 수 있습니다.
 
 

BASE란?

https://velog.io/@issac/DB-트랜잭션-Transaction의-ACID-속성과-분산시스템-BASE-속성

 
분산 시스템에서는 엄격한 일관성보다는 가용성이 더 우선시됩니다. ACID가 엄격한 일관성을 지향하기 때문에 분산 시스템에 조금 더 적합한 트랜잭션 모델이 BASE입니다. BASE는 다음과 같이 구성됩니다.
 

Basically Available

Basically Available는 한국어로 "기본적인 가용성"이라고 부릅니다. HA(High Availability 고가용성)의 완화된 버전이라고 이해하시면 됩니다. 시스템이 장애 상황에서 가능한 한 많은 가용성을 유지하려고 노력하지만, 데이터가 모든 노드에서 항상 일관되지 않을 수 있음을 의미합니다.
 
예) 부분적으로 장애가 발생했지만, 장애가 발생하지 않은 노드는 사용 가능한 상황
 

Soft state

Soft state는 한국어로 "부드러운 상태(?)"라고 부릅니다. 부드러운 상태는 장애가 발생한 특정 시점에는 일관성이 보장되지 않지만, 시간이 지남에 따라 시스템이 결국 일관성을 회복할 수 있음을 의미합니다.
 
예) 동기화가 완료되지 않은 노드의 데이터가 시간이 지남에 따라 최신의 데이터로 덮어 쓰여지는 상황
 

Eventual Consistency

Eventual Consistency는 한국어로 "최종적 일관성"이라고 부릅니다. 최종적 일관성은 시스템의 모든 복제본이 결국 최종적으로 같은 값을 가지는 상태(동기화)가 될 것이지만, 시간이 얼마나 걸릴지 알 수 없는 것을 의미합니다. 장애 상황으로 인해 일시적인 불일치는 허용하지만, 최종적으로 일관성을 갖추게 되는 것을 의미합니다.
 
예) 네트워크 장애로 인해 일시적으로 특정 노드와 일관성이 깨지는 상황
 

다양한 일관성 모델

분산 시스템에서 활용되는 일관성 모델에도 여러 종류가 있습니다. 각 모델에 대해 알아봅시다.
 

Eventual Consistency (최종적 일관성)

최종적 일관성은 위에서 언급한 BASE의 구성 요소 중 하나입니다. 최종적 일관성 모델은 금융 시스템과 같이 엄격한 일관성이 요구되는 시스템에서 적합하지 않습니다. 단, 잔액 조회 등은 예외적으로 가능해도 무방할 듯합니다. AWS DynamoDB는 최종적 일관성 모델을 사용하는 대표적인 저장소입니다.

 

(2024-02-21 추가)

AWS DynamoDB는 강력한 일관성과 최종적 일관성 모두 지원합니다. 단, 강력한 일관성 읽기 모드를 사용할 경우 최종적 일관성 읽기보다 4배의 용량을 사용하기 때문에 비용도 4배 비쌉니다. Query API에서 ConsistentRead 파라미터에 Boolean 값을 넣어서 설정할 수 있습니다. Default 값은 False 입니다.

https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_Query.html


장점

  • 일부 복제본이 일시적으로 동기화되지 않는 경우에도 높은 가용성을 제공합니다.
  • 쓰기 작업에서 낮은 레이턴시를 보여줍니다.

단점

  • 일시적으로 일부 노드가 오래된 값을 반환할 수 있습니다. (일시적으로 일관성 깨짐)
  • 데이터 충돌 발생 시 복잡한 해결 전략으로 인해 충돌이 발생할 경우 데이터 손실이 발생할 수 있습니다.

 

Strong Consistency (강력한 일관성)

강력한 일관성은 읽기 작업이 실행되는 노드에 상관없이 모든 읽기 결과가 최신 데이터임을 보장합니다. 일반적으로 Paxos나 Raft와 같은 합의 알고리즘을 사용합니다.
 
장점

  • 애플리케이션 로직을 일관성 있고 간결하게 작성할 수 있습니다.
  • 모든 노드에서 최신 데이터를 읽는 것을 보장합니다.

단점

  • 가용성이 줄어들고 레이턴시가 늘어납니다.
  • 고가용성과 레이턴시를 낮추기 위해 더 많은 리소스가 필요할 수 있습니다.

 

Strong Eventual Consistency (강력한 최종적 일관성)

강력한 최종적 일관성은 모든 노드가 동일한 업데이트 요청을 받았을 때 동일한 상태가 되는 것을 보장합니다. 심지어 업데이트가 적용된 순서와 무관합니다. 이는 Conflict-free Replicated Data Types(CRDTs) 또는 Operational transformation(OT)을 통해 만족할 수 있습니다.
 
강력한 최종적 일관성 모델은 충돌 없이 복제, 병합할 수 있는 특정 데이터 타입에서만 작동합니다. Set이나 Counter 타입 등의 데이터에만 적용 가능합니다. 예를 들어, Riak는 CRDT를 통해 강력한 최종적 일관성을 만족합니다. 단, 데이터 노드 간 전파가 지연된다면 일시적으로 불일치 문제가 발생할 수도 있습니다.
 
장점

  • 고가용성을 만족하고 낮은 레이턴시를 보여줍니다.
  • 충돌 없이 데이터를 합칠 수 있습니다.

단점

  • 제한된 데이터 타입에서만 가능합니다.
  • CRDT 혹은 OT를 구현하는 것이 복잡합니다.

 
 

더 읽어보면 좋은 글

 
 

References

저작자표시

'💻 개발 이야기 > DevOps(Infra)' 카테고리의 다른 글

[Infra] UUID vs Snowflake ID : 분산 시스템에서 유일한 ID를 만들어보자  (3) 2023.09.10

관련글

티스토리툴바