들어가며
CAP Theorem 에서 말하는 Consistency 는 모든 노드에서 볼 수 있는 읽기/쓰기 연산은 원자적(atomic)이거나 선형적으로 일관성 있는지 (linearizability) 를 중점으로 본다.
우리가 현재 마주하는 대부분의 네트워크 시스템은 불안정함을 가지고 있다. 패킷은 중간에 사라질 수도 있고 늦게 도착할 수도 있다. 이는 바꾸기 어려운 사실이기 때문에 어쩔 수 없이 CAP 에서 P(partition tolerance) 를 강제로 선택하게 된다. 그렇다면 남은 C(Consistency)와 A(Availability) 사이에서 어떤 것을 중점으로 할 지 선택을 내려야만 한다.
분산 시스템에서 데이터를 저장하고 관리하는 일련의 기술(방식)을 consistency pattern (혹은 consistency model)이라 한다.
매우 다양한 종류가 존재하지만 일반적으로 널리 사용되는 패턴은 다음 세 가지로 분류 할 수 있다.
- Strong consistency
- Weak consistency
- Eventual consistency
consistency pattern 은 시스템 내에서 데이터가 어떻게 전파되어야 하는가를 결정하는 중요한 요소이기 때문에 분산 시스템에서 확장성과 안정성에 큰 영향을 주게 된다. 따라서 분산시스템을 설계할 때 각각의 장단점을 파악하고 적용하는 것이 필요하다.
Strong consistency
After a write, reads will see it
모든 Read 연산은 항상 가장 최근에 발생했던 Write 연산의 결과를 반영한다.
일관성을 지키기 위해 가장 쉽게 떠올릴 수 있는 방식이라고 생각된다.
모든 서버, 즉 모든 유저가 동일한 시점에는 동일한 데이터를 보게 함으로써 시스템에 대한 일관성 있는 뷰를 보여줄 수 있게된다.
이는 보통 다음과 같이 동기적(synchronously)으로 모든 서버에 데이터를 동기화 함으로 구현하게 된다.
- 클라이언트는 쓰기 연산을 primary DB 에 요청한다.
- primary DB 는 replica DB 로 데이터를 전파한다.
- replica DB 는 쓰기 작업을 완료한 뒤 primary DB 에 ack signal 을 보낸다.
- primary DB 는 이제 클라이언트에게 ack signal 을 보내 요청한 작업이 완료되었음을 알린다.
매우 단순해 보이는 구현 방식이기 때문에 잘 사용되지 않을 것 같다는 생각이 들었지만 나름의 사용 용도가 있다.
data consistency 를 가장 강하게 지키는 모델이기 때문에 consistency 가 최우선인 시스템에 주로 사용된다.
- File system
- RDBMS
- financial system (e.g. banking)
- 예를 들어 계좌 잔고에 대한 갱신은 곧바로 복제되어서 모두 동일한 값을 보는 것이 필수적이다.
Weak consistency
After a write, reads may or may not see it
Best effort only
Read 연산은 가장 최신의 결과를 반영할 수도 있고, 아닐수도 있다.
OSI 7 계층을 공부하면서 IP 프로토콜은 "best effort" 로 패킷을 전달한다고 말하는 것을 본 적이 있다.
이 말은 패킷을 전달하기 위해 최선을 다하지만, 실패할 수도 있다는 뜻이다.
마찬가지로 Weak consistency 는 한 서버에 전달된 쓰기 연산을 다른 서버에 빠르게 전파해서 모든 서버에 대한 읽기 연산이 최신의 결과를 반영할 수 있도록 노력하지만 실패할 수도 있다라고 볼 수 있다.
최신의 결과가 반영되기 위해 할 수 있는 노력 중 가장 쉬운 일은 기다리는 것, 즉 시간이 지나서 결과가 반영되길 바라는 것이다. 쓰기 연산으로 인해 발생한 갱신 요청 시점부터 모든 서버에서 갱신된 결과를 볼 수 있게 되는 시점까지의 기간을 "inconsistency window" 라고도 부른다.
weak consistency 를 구현한 예시 중 하나는 다음과 같이 write-behind(write-back) cache 를 사용하는 것이다.
- 쓰기 연산을 캐시 서버에 요청한다.
- 캐시는 이 요청을 메시지 큐에 넣어둔다.
- 2번 작업을 완료한 후 캐시 서버는 클라이언트에게 쓰기 연산이 완료되었음을 알린다.
- 메시지 큐의 워커가 메시지를 보고 비동기적으로 데이터베이스에 해당 연산을 반영한다.
이렇듯 weak consistency 는 우리의 연산이 정확히 반영될 수도 아닐수도 있다. 정확히 반영되었다면 좋겠지만 그렇지 않은 경우라도 정상적으로 동작할 수 있는 시스템에 적용할 수 있는 방식이라고 할 수 있는데 대표적으로 다음과 같은 상황이 있다.
- real time multiplayer game
- VoIP
- Live stream
- 네트워크 연결이 불안정할 때 놓친 프레임을 다시 전송하지 않는다.
Eventual consistency
After a write, reads will eventually see it
Read 요청은 반드시 최신의 데이터를 반환하는 것은 아니지만, 시스템은 최종적으로는 최신의 데이터를 반환한 것과
같은 상태로 귀결된다.
Weak consistency 의 특별한 형태라고 할 수 있다.
만약 추가적인 새로운 write 요청이 없다면, 결국에는 모든 Read 요청은 최신의 데이터를 반환하게 된다.
- 클라이언트는 primary DB 에 쓰기 요청을 한다.
- primary DB 는 클라이언트에게 ack signal 을 전달함으로써 완료를 알린다.
- primary DB 는 replica DB 로 데이터를 전달함으로써 최종적으로 전파시킨다.
가장 대표적인 eventual consistency 를 사용하는 시스템은 DNS (Domain Name System) 이다.
특정한 name 에 대한 갱신은 곧바로 모든 노드에 반영되지 않고 캐시에 저장된 값이 사용된 뒤 결국에는 갱신된다.
eventual consistency 에는 다양한 변형 버전이 존재한다.
- Causal consistency
- 클라이언트 A 가 B에게 값의 갱신을 알려주면 이후의 B 의 접근은 갱신된 값을 보도록 보장해준다.
만약 그와 관련없는 C 가 접근한다면 일반적인 eventual consistency rule 을 따른다.
- 클라이언트 A 가 B에게 값의 갱신을 알려주면 이후의 B 의 접근은 갱신된 값을 보도록 보장해준다.
- Read-your-writes consistency
- causal consistency 의 특별한 케이스로 만약 클라이언트가 값을 갱신(write) 했다면, 해당 클라이언트는 절대 그 이전 값을 보지 못함을 보장하는 방식.
- Session consistency
- read-your-writes consistency 의 적용 방식으로 세션을 사용하는 방법이다.
세션이 존재하는 동안은 read-your-write 와 같이 동작하고, 만약 세션이 종료된다면 이와 겹치지 않는 새로운 세션이 생성되도록 한다.
- read-your-writes consistency 의 적용 방식으로 세션을 사용하는 방법이다.
- Monotonic read consistency
- 한 클라이언트가 객체에 대한 특정 값을 읽었다면 이후에 발생하는 모든 접근은 해당 값 이전의 값을 보지 못하도록 보장하는 방식
생각해볼 만한 점
안드로이드 개발을 주로 해오던 내가 바뀐 업무를 하면서 가장 주의해야 하는 부분 중 하나는
바로 내가 작성하는 코드들이 분산 시스템 환경에서 동작한다는 가정을 해야한다는 점이다.
모바일 개발에서는 모든 컴포넌트들이 하나의 물리적인 단말에 존재한다.
따라서 CAP 이론에서 말하는 network partition 이 절대로 발생하지 않는다고 볼 수 있다.
그렇기에 Sqlite 와 같은 데이터베이스와 통신하는 작업을 했더라도 별도의 trade-off 없이 C(Consistency)와
A(Availability) 를 모두 달성할 수 있었을 것이고, 그로 인해 크게 고민할 필요가 없었던 것 같기도 하다.
앞으로 마주하게 될 시스템의 대부분이 이러한 분산 시스템 환경이며 eventual consistency model 을 적용하고
있을 것 같은데, 한번 쯤은 이런 제약사항들에 대해서 고민해보고 어떤식으로 문제를 해결해 나갈 것인지
다양한 기법들을 찾아보는 것도 좋은 공부가 될 수 있을 것 같다는 생각이 들었다.
