Last Updated on 6월 9, 2024 by Jade(정현호)
안녕하세요
이번 글은 MongoDB에서의 Read and Write Concerns와 연관된 Causally consistent session 에 대해서 확인해보도록 하겠습니다.
해당 내용은 이전 MongoDB의 Write Concern 와 Read Concern에 대한 포스팅에서 이어지는 글입니다.
causally consistent session
작업이 논리적으로 이전 작업에 종속되는 경우 작업 간에 인과 관계가 있다고 할 수 있습니다.
예를 들어, 지정된 조건에 따라 모든 문서를 삭제하는 쓰기 작업과 삭제 작업을 확인하는 후속 읽기 작업은 인과관계가 있습니다.
MongoDB는 causally consistent session을 통해 인과 관계를 존중하는 순서로 인과관계 작업을 실행하고 클라이언트는 인과 관계와 일치하는 결과를 관찰합니다.
즉, 클라이언트의 작업이 시간적인 순서에 따라 일관성 있게 실행되도록 보장하는 세션입니다.
이는 데이터베이스에서 발생하는 여러 작업들 사이의 원인과 결과 관계를 유지하면서 일관성을 보장합니다.
이러한 causally consistent은 분산 데이터베이스 환경에서 중요한 역할을 합니다. 데이터가 여러 노드에 분산되어 있을 때, 각 노드는 독립적으로 작업을 처리하므로 작업의 순서를 보장하기 어렵습니다.
하지만 causally consistent session을 사용하면, 클라이언트는 작업의 순서를 보장받을 수 있습니다.
causally consistent session은 MongoDB 3.6 버전부터 도입되었습니다.
세션을 시작할 때 causally consistent session을 활성화하면, 해당 세션에서 실행되는 모든 작업은 원인적 일관성을 유지하게 됩니다.
Read and Write Concerns 와 Causal Consistency
MongoDB에서 causally consistent는 클라이언트 세션이 수행하는 작업 간의 인과 관계를 유지하는 것을 의미합니다.
다시 말해, 작업의 순서가 유지되어야 하며, 인과 관계에 따른 읽기 및 쓰기 작업 순서를 보장하는 모델입니다.
MongoDB의 causally consistent 클라이언트 세션을 사용하면 읽기 및 쓰기 concerns의 다양한 조합에 따른 다양한 인과적 일관성을 보장합니다.
다음 표에는 다양한 조합이 제공하는 구체적인 보장이 나열되어 있습니다.
| Read | Write | Read | Monotonic | Monotonic | Writes |
| Concern | Concern | own writes | reads | writes | follow reads |
|------------|------------|------------|-----------|-----------|--------------|
| "majority" | "majority" | O | O | O | O |
| "majority" | { w: 1 } | | O | | O |
| "local" | { w: 1 } | | | | |
| "local" | "majority" | | | O | |
4개의 읽기와 쓰기에 대한 인과적 일관성 보장에 설명은 다음과 같습니다.
- Read your writes : 읽기 작업은 이전 쓰기 작업의 결과를 반영합니다.
- Monotonic reads: 읽기 작업은 앞선 읽기 작업보다 더 이전 상태의 데이터에 해당하는 결과를 반환하지 않습니다.
예를 들어, 세션에서 쓰기 1이 쓰기 2보다 앞서고, 읽기 1이 읽기 2보다 앞서며, 읽기 1이 쓰기 2를 반영하는 결과를 반환한다면, 그렇다면 읽기 2는 쓰기 1의 결과를 반환할 수 없습니다. - Monotonic Writes: MongoDB는 기본적으로 독립 실행형(standalone) mongod 인스턴스 및 Replica Set에 대해 Monotonic Writes 보장을 제공합니다. 다른 쓰기 작업보다 먼저 실행되어야 하는 쓰기 작업은 그 다른 쓰기 작업보다 먼저 실행됩니다.
예를 들어, 세션에서 쓰기 1이 쓰기 2보다 앞서야 하는 경우, 쓰기 2의 데이터 상태는 쓰기 1 후의 데이터 상태를 반영해야 합니다. 다른 쓰기 작업들은 쓰기 1과 쓰기 2 사이에 교차(interleave)하여 발생할 수 있지만, 쓰기 2는 쓰기 1보다 먼저 발생할 수 없습니다. - Writes follow reads: 읽기 작업 이후에 발생해야 하는 쓰기 작업은 해당 읽기 작업 이후에 실행됩니다. 즉, 쓰기 작업 시점의 데이터 상태는 이전 읽기 작업의 데이터 상태를 반영해야 합니다.
데이터 내구성과 인과적 일관성을 원하는 경우 표에서 볼 수 있듯이 "majority" 읽기 Concern 와 "majority" 쓰기 Concern 사용하는 경우에만 네 가지의 인과적 일관성 보장을 모두 보장할 수 있습니다.
즉, 인과적 일관성을 보장하기 위해서는 인과적으로 일관된 클라이언트 세션은 다음과 같은 작업에 대해만 인과적 일관성을 보장할 수 있습니다
- "majority" read concern 을 통한 읽기 작업: 대다수의 Replica Set 멤버가 승인하고 내구성이 있는 데이터를 반환하는 읽기 작업입니다.
- "majority" write concern 을 통한 쓰기 작업: 해당 작업이 Replica Set의 투표 멤버 대부분에 적용되었다는 확인을 요청하는 쓰기 작업입니다.
데이터 내구성 없이 인과적 일관성을 원하는 경우(즉, 쓰기가 롤백 될 수 있음을 의미) { w: 1 } Write Concern를 갖는 쓰기 작업도 인과적 일관성을 제공할 수 있습니다.
Note
읽기 및 쓰기 concern의 다른 조합도 일부 상황에서는 네 가지 인과적 일관성 보장을 모두 충족할 수 있지만 모든 상황에서 반드시 그런 것은 아닙니다.
다음은 아래 시나리오에서 사용할 현재 MongoDB Replica Set의 네트워크가 분할된 상황을 설명합니다.
read concern majority 과 write concern majority는 Replica set의 두 구성원(member)이 일시적으로 기본 구성원(primary)이라고 믿는 상황(예: 네트워크 파티셔닝/네트워크 분할과 같은)에서도 네 가지 인과 일관성 보장이 유지되도록 보장합니다.
두 기본(primary) 멤버 모두 { w: 1 } Write Concern로 쓰기를 완료할 수 있지만, 오직 하나의 기본(primary)만이 majority write concern 으로 쓰기를 완료할 수 있습니다.
예를 들어, 5명의 멤버로 이루어진 Replica Set을 네트워크가 분할 되는 상황을 고려해 보겠습니다.
위의 네트워크 분할 상황을 생각해보면
- "majority" write concern로 쓰기로 P new에서 완료될 수 있지만 P old에서는 "majority" write concern로 완료될 수 없습니다.
P old 에서는 통신이 가능한 멤버(구성원)이 다수가 없기 때문입니다.(5개중 2개만 통신가능) - { w: 1 } Write concern로 쓰기는 P old 와 P new에서 둘 다 완료될 수 있습니다. 그러나 P old로의 쓰기(S1로 복제된 쓰기)는 이러한 멤버가 나머지 Replica Set 멤버와의 통신을 재개하면 롤백됩니다.
- P new에서 "majority" write concern로 쓰기가 성공적으로 완료된 후, "majority" read concern로 인과적 일관성 읽기를 하면 해당 쓰기 작업에 대한 결과를 P new, S 2 및 S 3에서 확인할 수 있습니다.
읽기 작업 역시도 Replica Set의 다른 구성원과 통신이 가능하고 다른 Replica Set의 멤버로부터 데이터를 동기화할 수 있게 되면 P_old와 S_1에서도 쓰기 작업에 대한 결과를 확인할 수 있습니다.
다만 네트워크가 분할된 중에 P_old에 쓰인 데이터 또는 S_1에 복제된 모든 쓰기 작업은 롤백 됩니다.
Scenarios
클라이언트가 Replica set 환경에서 다음과 같은 다양한 조합으로 read 및 write concern 을 구성하여 사용할 수 있으며 다양한 조합을 통해서 read 와 write concern의 요구 사항을 설명 및 이해할 수 있습니다.
다음과 같은 다양한 읽기와 쓰기 concern 의 조합이 있을 수 있습니다.
- Read Concern "majority" and Write concern "majority"
- Read Concern "majority" and Write concern {w: 1}
- Read Concern "local" and Write concern "majority"
- Read Concern "local" and Write concern {w: 1}
글에서는 Read Concern "majority" and Write concern "majority" 에 대해서 우선 중점적으로 살펴보도록 하겠습니다.
인과적으로 일관된 세션에서 Read Concern "majority" 및 Write concern "majority" 를 사용하면 다음과 같은 인과적 일관성이 보장됩니다.
- Read own writes
- Monotonic reads
- Monotonic writes
- Writes follow reads
Scenario 1
위에서 설명하고 제시된 Replica Set의 네트워크 분할 상황을 생각해보면 두 개의 기본(primary) 멤버가 있는 일시적인 기간 동안, P new만이 { w: "majority" } 쓰기 우선순위로 쓰기를 수행할 수 있기 때문에 클라이언트 세션은 다음과 같은 작업 순서를 성공적으로 실행할 수 있습니다.
Sequence 및 설명
- "majority" write concern로 P new에 쓰기 1을 수행합니다.
item A의 수량(qty)을 50으로 업데이트합니다. - "majority" read concern로 S2 구성원에서 읽기 1을 수행합니다.
item A를 읽습니다. - "majority" write concern로 P new에 쓰기 2를 수행합니다.
수량이 50 이하인 item의 재고 보충 여부를 true로 업데이트합니다. - "majority" read concern로 S3 구성원에서 읽기 2를 수행합니다.
item A를 읽습니다.
- Read own writes: 읽기 1은 쓰기 1 이후의 상태를 반영한 데이터를 S2에서 읽습니다.
읽기 2는 쓰기 1과 쓰기 2 이후의 상태를 반영한 데이터를 S3에서 읽습니다. - Monotonic reads: 읽기 2는 읽기 1 이후의 상태를 반영한 데이터를 S3에서 읽습니다.
- Monotonic writes: 쓰기 2는 쓰기 1 이후의 상태를 반영한 데이터를 P new에 업데이트합니다.
- Writes follow reads: 쓰기 2는 읽기 1 이후의 데이터 상태를 반영한 데이터를 P new에 업데이트합니다 (이는 이전 상태가 Read 1에서 읽은 데이터를 반영한다는 것을 의미합니다).
읽기 concern과 쓰기 concern을 모두 majority로 수행시 이와 같이 4가지 상황 모두에서 일관성 있는 트랜잭션 처리가 가능해집니다.
Scenario 2
read concern "majority"를 가진 Read 1이 S1 구성원으로 라우팅 되는 대체 순서에 대한 고려입니다.
Sequence 및 설명
- "majority" write Concern 로 P new에 쓰기 1을 수행합니다.
item A의 수량(qty)을 50으로 업데이트합니다. - "majority" read concern으로 S1 구성원에서 읽기 1을 수행합니다.
item A를 읽습니다. - "majority" write concern로 P new에 쓰기 2를 수행합니다.
수량이 50 이하인 item들의 재고 보충 여부를 true로 업데이트합니다. - "majority" read concern로 S3 구성원에서 읽기 2를 수행합니다.
item A를 읽습니다.
이 시퀀스에서 다수 커밋 포인트가 P old에서 진행될 때까지 읽기 1은 반환될 수 없습니다. 이는 P old와 S1이 나머지 Replica Set과 통신할 수 있을 때까지 발생하지 않습니다.(읽기 1이 반환되지 않습니다)
이 시점에서 P old는 (이미 그렇지 않다면) 주(primary)에서 내려오게 되며(stepped down), 두 멤버는 다른 Replica Set 멤버들로부터 동기화됩니다.(쓰기 1 포함)
- Read own writes: 읽기 1은 네트워크 분할이 해결되고 해당 구성원이 Replica set의 다른 구성원들로부터 동기화된 후에도 쓰기 1 이후의 데이터 상태를 반영합니다.
읽기 2는 쓰기 1 이후와 쓰기 2 이후의 상태를 반영하는 S3 구성원의 데이터를 읽습니다. - Monotonic reads: Read 2는 Read 1 이후의 상태를 반영한 S3 구성원의 데이터를 읽습니다. (즉, 읽기 1에서 읽은 데이터의 이전 상태가 반영됩니다)
- Monotonic writes: 쓰기 2는 쓰기 1 이후의 상태를 반영하는 P new의 데이터를 업데이트합니다.
- Writes follow reads: 쓰기 2는 읽기 1에서 읽은 데이터를 반영하는 P new의 데이터 상태를 업데이트합니다. (즉, 이전 상태가 읽기 1에서 읽은 데이터를 반영합니다)
이와 같이 MongoDB에서는 세션에서의 read concern 과 write concern 에 따라서 보장받을 수 있는 causally consistent가 다를 수 있다는 것을 알 수 있으며 위에서 한번 언급된 표의 내용과 같이 설정한 concern에 따라서 다음과 같이 보장받을 수 있는 인과적 일관성을 정리해볼 수 있습니다.
| Read | Write | Read | Monotonic | Monotonic | Writes |
| Concern | Concern | own writes | reads | writes | follow reads |
|------------|------------|------------|-----------|-----------|--------------|
| "majority" | "majority" | O | O | O | O |
| "majority" | { w: 1 } | | O | | O |
| "local" | { w: 1 } | | | | |
| "local" | "majority" | | | O | |
결론적으로 majority 읽기 및 쓰기 concern을 사용하였을 때 다양한 상황에서는 인과적 데이터 일관성을 보장받을 수 있음을 확인할 수 있습니다. 다만 이전글에서도 설명한 것처럼 트레이드 오프 관계로 다른 concern 비해 처리 속도 또는 응답 속도는 느릴 수 있습니다.
그 외 다양한 concern 의 조합에 따른 인과적 일관성에 대한 시나리오는 도큐먼트에서 확인할 수 있습니다.
different combinations of read and write concerns provide different
causal consistency guarantees.
긴 글 읽어 주셔서 감사합니다. 이번 글은 여기서 마무리하도록 하겠습니다.
Reference
Reference URL
• mongodb/read-isolation-consistency-recency
• mongodb/causal-consistency-read-write-concerns
연관된 다른 글
Principal DBA(MySQL, AWS Aurora, Oracle)
핀테크 서비스인 핀다에서 데이터베이스를 운영하고 있어요(at finda.co.kr)
Previous - 당근마켓, 위메프, Oracle Korea ACS / Fedora Kor UserGroup 운영중
Database 외에도 NoSQL , Linux , Python, Cloud, Http/PHP CGI 등에도 관심이 있습니다
purityboy83@gmail.com / admin@hoing.io
