Consistency Model의 종류

🕓 4 mins read

# Consistency

분산 시스템 환경에서 consistency는 여러 가지 의미를 가질 수 있습니다. 한 가지는 각 레플리카 노드가 특정 시간에 항상 동일한 데이터 view를(동일한 read 결과를 내뱉는 것) 가지는 것을 의미하는걸 수 있죠. 또 다른 의미로는 여러 read request에 대해서 가장 최근에 write 된 값을 리턴하는 것을 의미할 수 있고요. Consistency를 보장하는 방법도 다양하기 때문에 이 두 가지 외에도 consistency에 대한 정의가 달라질 수 있습니다.

일반적으로 consistency model은 추상화된 개념으로 분산 시스템 내에서 read, write, modification등에 대해 어떤 동작이 적합한지 따져 볼 수 있도록 정의 됩니다.

어플리케이션을 설계 할때 구성요소로 별도의 저장소 내지는 DB를 이용하게 되는데 어떤 consistency 모델이 있고 어떤 상황에 적합한지를 알아 둬야합니다.

Consistency 모델의 양 극단에는 아래 그림과 같이 강도에 따른 분류가 있고 양 극단 사이에서 타협한 모델들이 존재합니다.

[주의1] ACID 와 CAP theorem은 서로 비슷한듯 하나, 다른 정의입니다.
[주의2] 위의 4가지 모델 이외에도 다양한 모델이 있는데, 대표적인 것들만 나열했습니다.

요약하자면,

• ACID 는 개별 노드에서의 데이터 consistency를,
• CAP은 전체 클러스터내에서의 consistency를 의미합니다.

즉, ACID는 데이터베이스에서 특정 operation이 처리 되는 동안의 consistency를 보장하는 방법을 이야기하는것이고, CAP은 분산 시스템내에서 여러 replica 노드들 간의 consistency를 보장하는 방식에 대해서 이야기 하는것입니다.

 

1. Eventual Consistency

먼저 가장 약한 consistency 레벨인 eventual consistency는, 단어 그대로, 시간이 충분히 흐른 뒤에는 전체 시스템(클러스터 내의 노드들간의) 데이터 일관성을 유지한다는것입니다.

즉, read 동작에서 항상 최신 값을 보장할 필요가 없는 경우에 적합한 모델인거죠.

어쨋거나, 모든 read request에 대해서 어떤 replica 노드에서 응답을 내려주든 동일한 값을 내어주기만 한다면, consistent 하긴 한것이죠. 다만, 값이 실시간으로 최신이 아닐 수 있다는것만 빼고 말이죠.

아래의 테이블을 통해 분산 시스템내에서 시스템의 상태에 따라 값이 변경되는 과정과, read 결과를 보시죠.

Time	Value	Operation	Read result
t1	x = 2	-	2
t2	x = 2 15	write ( x = 15 )	2  : 아직 값을 저장하고 replica에 전파 중 인 상태
t3	x = 15	read ( x )	15 : 값이 모든 replica에 갱신 된 상태

대표적으로 이런 동작이 적당한 경우는  DNS 서버 (도메인 네임 관리 시스템)가 있겠죠?
- 최신성이 동작에 치명적인 영향을 미치진 않을테니까 말이죠.

 

2. Causal Consistency

Eventual consistency 모델 보다 약간 더 최신성을 유지하는 방향으로 변형을 하면, causal consistency 모델이 있는데, 여기선 데이터 operation을 의존성 유무에 따라 두가지로 나누어 처리 하는 방식입니다.

의존성이 있는 operation을 dependent 혹은 causally-related operation이라 부르는데요, 말 그대로 의존성이 있는 명령들을 순차적으로 처리 하는것을 보장합니다.

위의 예시에서 두 프로세스 p1 과 p2 는 causally related operation을 수행합니다.
p1의 작업이 선행되어야 b가 존재하고 b를 y에 write 할 수 있기 때문이죠.

대표적인 경우로, SNS나 커뮤니티 게시판 등에서 사용되는 댓글 시스템이 있습니다. 답댓글을 달기 위해서는 댓글이 먼저 저장 된 다음에 해당 댓글에 대한 답댓글을 저장 할 수 있으니까요. 일련의 동작이 선행 되어야 하는 경우 사용된다고 합니다.

- 가령 특정 댓글이 클러스터 내의 한 노드 a에는 저장되었는데 전체 replica에 전파 되기 전에 해당 댓글에 대한 답댓글이 저장되면, 아직 a 이외의 노드에는 첫번째 댓글이 저장되지 않았으니, 답댓글에 대한 정보가 먼저 저장되어선 안된다는 것이죠. (각 노드 단위로 선행 댓글이 저장 된 다음에 답댓글이 저장되어야하는 구조)

 

3. Sequential Consistency

한 단계 더 나아가서 조금 더 strict한 시스템으로는 시스템에서 정의한 특정 순서가 보장되도록 하는 consistency 모델입니다. 여전히 global clock에 대한 실시간 최신성을 보장하진 않지만, 특정 조건하에 정의된 순서는 반드시 보장되도록 하는것입니다.

예를 들면 좀 더 설명이 와 닿을텐데요, SNS 내에서 이용자 입장에서 전체 피드의 실시간 순서는 정확하지 않아도 되지만, 특정 친구/계정이 업로드한 포스팅은 반드시 해당 유저가 업로드한 순서를 보장해야 하겠죠. 따라서 이런 경우에 sequential consistency를 이용하게 됩니다.

4. Strict Consistency

마지막으로 strict consistency 모델은 다른 말로 linearizability 라는 속성으로도 부르는데 가장 강력한 수준의 일관성을 보장하는 모델입니다. 그 어떤 replica 노드가 read 요청을 받더라도 반드시 최신값으로 갱신된 결과만을 읽을 수 있도록 보장하는 모델입니다. Write 나 modification이 수행된다면, 해당 작업이 완료 되었다는 ack가 확인 될때만 해당 값에 대한 read를 수행하게 됩니다.

이런식으로 전체 클러스터 노드에 최신 값이 갱신이 완료 되었을때만 ack를 발생시켜서 클라이언트가 항상 시스템의 최신 값을 읽도록 하는경우는 은행 계좌 시스템같은 곳에서는 반드시 최신 갱신된 state로만 동작 해야하기 때문에 중요한 기능입니다. 또는 패스워드 정보를 관리해야하는 계정 서버의 경우에도 반드시 최신 값 하나만으로 상태가 유지되어야겠죠?

하지만, strictness가 강할 수록 전체 클러스터에 최신 정보가 갱신되어야 하므로 시스템의 응답시간이 느려질 수 있습니다. 그래서 최신성을 최대한 유지하되, 항상 이런 동기화를 요구하지 않는 경우에는 어느정도 비동기성을 갖춰 응답시간을 확보하기도 합니다.

## Quorum based Consistency

투표 방식의 quorum 방법론인데 간단히 표현하면, 

w + r > n
 w : minimum write nodes
  r : minimum read nodes
  n : nodes in the quorum group

즉, 노드를 묶어서 총 n 개의 노드가 있다고 하면, w, r 을 정의 해둡니다.
클러스터에 요청이 들어왔을때 최소 값에 해당하는 w / r 만큼의 노드가 동일한 응답을 할 경우에만 operation을 수행하는것이죠.
따라서, 이 경우에는 3개의 노드가 있고 w, r = 2 라고 가정하면, 최소 2개의 노드가 같은 값을 가지고 있으면 해당 값이 최신값이라 생각하겠다는 것입니다. (대게 클러스터는 홀수개의 노드라고 가정하고 w = r= (n+1)/2 룰을 많이 사용합니다.)

- 하지만 이런 방식에는 리스크가 따르는데, 최신값이 대세가 아닐 경우에는 시스템의 availability를 희생하거나 최신성을 희생하게 됩니다.

이런식으로 비동기성을 가지는 시스템은 완전히 strict한 consistency를 보장할 필요는 없을때에만 사용해야겠죠? 

오늘 살펴본 내용을 보면, consistency 강도에 따라 시스템의 최신성과 응답 속도는 서로 trade off관계에 있는걸 알 수 있습니다.
따라서 시스템을 구현할때 어떤 모델이 적합한 기능인가를 잘 판단해서 설계해야겠죠.