[CloudComputing] Review_Eventually Consistent: Building reliable distributed systems at a worldwide scale demands trade-offs?between consistency and availability

또 결국은 일관성, 가용성을 비즈니스 로직에 따라 지식을 기반으로 지혜롭게 조정해나가야 하는 내용이 나오는구나 싶었다. 이래서 이러니저러니 해도 CS지식이 중요한건가 싶기도 하다. 받아들이는 시야가 달라지니.

그러나 이밖에도..

좋은 정보란 무엇인가.. 어려운 용어 섞어가면 다인가..?
고급 정보라고 하더라도 내 수준이 아직 그에 못미친다면 나는 어떻게 대처해야하는가..
챗지피티를 써야하나.. 그렇다면 효율적으로 이 자료를 흡수하기 위해서 챗지피티를 난 어떻게 써야할까..
프롬프트 엔지니어링에 대해 찾아봐야하나.. 아니 영어부터 공부해야하나.. 등등

많은 생각이 들게 해주는 글이었다.. = 힘들었다는 뜻..

---

 

1. 2008년 자료라는 것이 놀랍다.
2. replication techinques가 어떻게 consistent performance&high availabilty를 보장하는 걸까?
   1. One of the ways in which this manifests itself is in the type of data consistency that is provided, particularly when many widespread distributed systems provide an eventual consistency model in the context of data replication.
3. CAP Theorem의 partition tolerance
   1. 더 찾아보니 Gilbert와 Lynch가 CAP Theorem에 대한 증명에 사용한 명제에 대한 새로운 정의가 있었는데 그것이 더 와닿았다.
      1. The network will be allowed to lose arbitrarily many messages sent from one node to another.
      2. 분할 용인이라고 번역하면 이해가 쉽다.
      3. 네트워크가 임의의 메시지 손실을 할 수 있다는 것을 허용하느냐인 것.
4. 그런데 사실 절대로 장애가 나지 않는 네트워크는 이 세상에 존재하지 않는다. 따라서 원하든 원하지 않든 larger distributed-scale system에서 Network Partition은 주어질 수밖에 없다.
   1. 따라서 consistency와 availabilty가 동시에 달성될 수 없다. 둘 중 하나만 선택되어야 한다.
      1. 이성원 교수님께서도 풀스택서비스네트워킹 수업에서 에러 없는 통신은 존재하지 않는다고 하셨던게 생각난다.
      2. consistency에 대한 기준을 완화하면 partitionable condition의 system에서 highly available할 것이고, consistency를 우선시하면 특정 condition의 system에서는 available하지 않는 상황이 나타날 수 있다는 것이다.
5. 그렇다면 개발자(클라이언트 개발자)가 system이 강조하는 내용에 따라 고려해야할 내용은 무엇인가?
   1. consistency > availability
      1. system에서 쓰기 작업을 수행할 수 없다는 사실을 처리해아한다.
      2. 쓰기 작업을 실패하면 기록할 데이터를 어떻게 해야할지 처리해야한다.
   2. availability > consistency
      1. 항상 쓰기 작업을 허용할 수 있지만
      2. 특정 조건에서는 최근에 읽기작업이 완료된 쓰기 결과는 반영하지 않아야 한다.
      3. 클라이언트가 항상 최신 업데이트에 엑세스해야 하는지의 여부를 결정해야한다.
         1. 오래된 데이터를 처리할 수 있는 다양한 애플리케이션을 이 모델에 적용하는 방법이 있다.
6. CAP Theorem에서의 consistency와 ACID 속성에 정의된 트랜잭션 시스템의 consistency 속성은 서로 다르다.
   1. ACID의 consistency
      1. 트랜잭션이 완료될 때 데이터베이스가 일관된 상태에 있다는 보장
7. consistency를 보기 위한 두 가지 방법
   1. developer/client point of view : how they(clients) observe data updates
      1. 데이터 업데이트가 클라이언트 측에서 어떻게 보이는지 고려한다.
         1. ex : 데이터 업데이트가 즉시 반영되는지 또는 어떤 조건을 만족해야만 새로운 값을 볼 수 있는지
   2. server side : how updates flow through the system and what guarantees systems can give with respect to updates
      1. 업데이트(시스템의 구성요소나 소프트웨어의 변경사항)가 시스템을 통해 흐르는 방식, 이러한 변경사항이 시스템 내에서 어떻게 처리되고 전달되는지, 시스템이 업데이트에 관한 어떤 보장을 제공할 수 있는지(강한/약한 일관성 수준을 어떻게 제공하는지)에 대한 이해가 중요하다.
8. client side consistency
   1. 동시 프로그래밍 영역(ex : 분산공유메모리, 분산트랜잭션 등)에서 사용되는 일관성 모델
   2. strong consistency
      1. 병렬 프로세스에서 엑세스는 순차적으로 표시된다.
      2. 선형화 가능성 보장을 제공한다.
         1. 선형화 가능성 : 요청을 동시에 처리하는 것
      3. 읽기를 통해 항목의 최신 커밋된 버전 반환이 보장된다. 클라이언트는 커밋되지 않은 쓰기 또는 부분 쓰기를 볼 수 없다.
   3. weak consistency
      1. 시스템이 후속 엑세스가 업데이트된 값을 반환하는 것을 보장하지 않는다.
      2. inconsistency window
      3. 가용성이 일관성보다 더 중요한 경우
   4. eventual consistency
      1. storage system에 새로운 업데이트가 없을경우, 언젠가는 동기화가 된다는 것(모든 접근이 마지막 업데이트된 값을 반환함)을 보장한다. 이때, inconsistency window는 통신 지연, 시스템 부하, 복제본 수 등을 고려하여 결정된다.
      2. ex : DNS(Domain Name System)
         1. DNS에서는 도메인 이름과 IP 주소의 매핑 정보를 여러 서버에 분산하여 저장한다. 이러한 서버는 캐시된 데이터를 사용하여 도메인 이름 조회를 수행하고, 필요에 따라 업데이트된 정보를 다른 서버에 복제하여 일관성을 유지한다.
         2. 따라서 DNS에서는 새로운 도메인 이름에 대한 업데이트가 발생하면 이 변경사항이 서버 간에 전파되는 시간이 일정할 수 없다.
         3. 그러나 특정 시간 간격 내에 모든 복제본이 최신 정보를 수신할 수 있도록 구성되어 있다. 즉, 지연은 있지만 결국 모든 클라이언트가 최신 정보를 보게 될 것을 보장한다.
         4. 예전에 github.io 도메인을 적용할 때나 내가 구매한 도메인을 적용하려고 할 때 시간이 좀 걸릴 수 있다고 봤던 것이 생각났다.
      3. eventual consistency를 유지하기 위한 다양한 방법 : causal consistency(인과 일관성), read-your-writes consistency(자신이 쓴 것을 읽는 일관성), session consistency(세션 일관성), monotonic read consistency(단조적 읽기 일관성), monotonic write consistency(단조적 쓰기 일관성)
         1. 세션 일관성이 궁금해져서 더 검색해보았다.
            1. 단일 클라이언트 세션 내의 읽기에서 쓰기 읽기 및 읽기 후 쓰기 보장을 적용하도록 한다.
            2. 이러한 보장은 작성자 세션을 위한 세션 토큰 공유를 가정한다.
            3. 모든 쓰기 작업 후에 클라이언트는 서버에서 업데이트된 세션 토큰을 받는다. 클라이언트는 토큰을 캐시하고 지정된 지역에서 읽기 작업을 위해 서버로 보낸다. 읽기 작업이 실행되는 복제본에 지정된 토큰에 대한 데이터가 포함된 경우 요청된 데이터가 반환된다. 복제본에 해당 세션에 대한 데이터가 없는 경우 클라이언트는 해당 지역의 다른 복제본에 대해 요청을 계속 다시 시도한다.
            4. 클라이언트 세션 토큰을 사용하면 이전 세션에 해당하는 데이터를 절대 읽지 않도록 보장할 수 있다. 즉, 세션토큰은 최소 버전 장벽으로 사용되는 것이다.
         2. 이러한 속성들은 결합될 수 있다.
         3. 분산 프로토콜을 실행하는 서버에 대한 클라이언트의 고착성에 따라 달라진다.
   5. RDBMS가 primary-backup relability를 제공하는 replication기술을 구현하는 방법
      1. 동기모드 : 복제본 업데이트가 트랜잭션의 일부로 처리된다. 즉, 원본 데이터베이스에 대한 변경이 완료되기 전에 복제본에 대한 업데이트가 완료되는 것이다.
         1. 자바스크립트의 콜백함수와 promise를 공부하면서도 동기와 비동기가 자꾸 헷갈려서 계속 공부했었다. 그 때, 동기는 먼저 수행되고 나중에 수행되는 것들이 명확하여 흐름을 예측하기 쉽다라는 것이 직관적으로 잘 와닿았었다. 그 내용을 상기하니 동기 복제의 개념을 이해하는 것에 도움이 되는 것 같다.
      2. 비동기모드 : 업데이트가 지연된 채로 백업된다. 로그를 이용한다.
   6. 동기 모드에서 복제본 업데이트는 트랜잭션의 일부이다.
      1. 원본 데이터
   7. 비동기 모드에서 업데이트가 로그 전달을 통해 지연된 방식으로 백업에 도착한다.
9. server side consistency
   1. 업데이트가 완료되기 전에 업데이트 수신을 확인해야 하는 복제본 수(W) + 읽기 작업을 통해 데이터 개체에 엑세스할 때 연결되는 복제본 수(R) > 데이터 복제본을 저장하는 노드수(N) 이면 쓰기 세트와 읽기 세트가 항상 겹치며 강력한 일관성을 보장할 수 있다.
   2. 동기식 복제를 구현하는 기본 백업 RDBMS 시나리오
      1. 데이터 복제본을 저장하는 노드수 2개, 업데이트 완료 전 업데이트 수신을 확인해야 하는 복제본 수 2개, 읽기작업을 통해 데이터 개체에 엑세스할 때 연결되는 복제본 수 1개
      2. 원본 데이터베이스과 복제본 업데이트가 한 트랜잭션에 있으므로
      3. N < W+R이므로 일관된 응답
   3. 비동기 복제에서는 주 복제본의 데이터 변경 사항이 즉시 보조 복제본으로 전파되지 않을 수 있다.
      1. 백업 읽기가 활성화 되어있다. 즉, 보조 복제본(backup replica)에서 데이터를 읽을 수 있는 기능이 활성화 되어 있다. 읽기 작업의 성능을 향상시키기 위해서이다.
      2. 데이터 복제본을 저장하는 노드수 2개, 업데이트 완료 전 업데이트 수신을 확인해야 하는 복제본 수 1개, 읽기작업을 통해 데이터 개체에 엑세스할 때 연결되는 복제본 수 1개
      3. N = W+R이므로 일관성을 보장할 수 없다.
10. 결론적으로 N, W, R은 어떤 성능에 집중할 것이냐에 따라 다르다.
    1. R = 1, N=W하여 읽기 사례에 맞게 최적화하거나
    2. W = 1, R=N하여 쓰기 사례에 맞게 최적화하거나
11. 이러한 모든 특징은 Amazon Dynamo의 애플리케이션 아키텍처에서 고려된 것들이다.

https://queue.acm.org/detail.cfm?id=1466448

https://jvns.ca/blog/2016/11/19/a-critique-of-the-cap-theorem/