https://www.microsoft.com/en-us/research/wp-content/uploads/2011/10/ConsistencyAndBaseballReport.pdf
"데이터 중심 애플리케이션 설계" 5장(복제)을 공부하던 중 복제된 storage 환경에서의 읽기 일관성 보장(Read Consistency Gearantees)을 어떻게 달성할 수 있는지에 대해서 더 궁금해졌습니다.
래퍼런스 23번에 해당하는 "Replicated Data Consistency Explained Through Baseball" 내용에 대해서 더 읽어보고, 책 5장 내용을 합쳐서 정리해보았습니다.
개요
일관성 보장, consistency gearantees이란 개념을 주로 최종적 일관성, eventual consistency 라는 단어로 많이 접했을 수 있습니다. 최종적 일관성이란 읽기 확장, read scaling 아키텍처에서 확장을 위해 비동기식 복제로 팔로워를 추가하게 되면, 쓰기에 대한 반영이 각 팔로워마다 비동기 방식으로 전파되기 때문에, 일시적으로 동일한 질의에도 팔로워마다 다른 결과를 얻을 수 있지만 최종적으로는 모든 팔로워가 리더와 동일한 데이터를 가지게 된다는 효과입니다.
해당 강의에서는 이런 데이터를 복제하여 저장하고 있는 상황에서, 읽기 일관성 보장을 위해 어떤 선택을 할 수 있는지와 상황에 따라 어떤 선택이 좋은지를 야구 경기에 빗대어 설명해주고 있습니다.
읽기 일관성 보장을 위한 6가지 방법
1. 강한 일관성 Strong Consistency
읽기 작업시 과거에 쓰여진 모든 write 에 대한 읽기를 보장합니다.
- 읽기 작업시 반환될 수 있는 점수
- 2-5
- 가장 마지막에 업데이트된 점수를 반환
- 달성 방법
- primary에서만 읽기 작업
- Quorum base scheme 사용
- 2-phase commit, update multiple site
- 동기식 복제
- 장단점
- 구현이 쉽다. 가장 높은 일관성을 제공한다
- 성능이 좋지 않다
- 단일 노드 장애나 네트워크 중단이 전체 시스템의 장애를 유발할 수 있다
2. 최종적 일관성 Eventual Consistency
읽기 작업시 과거에 쓰여진 write 중 일부가 반영된 읽기를 보장합니다. 최종적으로는 모든 write 에 대한 읽기를 보장합니다.
- 읽기 작업시 반환될 수 있는 점수
- 0-0, 0-1, 0-2, 0-3, 0-4, 0-5, 1-0, 1-1, 1-2, 1-3, 1-4, 1-5, 2-0, 2-1, 2-2, 2-3, 2-4, 2-5
- 일부만 업데이트된 점수를 반환 가능
- 달성 방법
- primary 에 write 하고, read 작업은 replica 에서 수행
- 비동기식 복제
- 장단점
- 가장 약한 일관성을 제공한다. 일시적으로 데이터 불일치가 발생할 수 있다
- 성능이 가장 좋다
- 일부 노드 장애가 생겨도 다른 노드가 쉽게 대체 가능하다
3. 일관된 순서로 읽기 Consistent Prefix Read
읽기 작업시 과거에 쓰여진 write 중 일부가 반영되고, 그 순서가 보장되는 읽기를 제공합니다.
파티셔닝(샤딩)된 데이터베이스에서 발생하는 특징적인 문제입니다. 데이터베이스가 항상 같은 순서로 쓰기를 적용한다면 읽기는 항상 일관된 순서를 보기 때문에 이런 현상이 발생하지 않을테지만, 많은 분산 데이터베이스에서 서로 다른 파티션은 독립적으로 동작하므로 쓰기의 전역 순서를 알 수는 없습니다.
- 읽기 작업시 반환될 수 있는 점수
- 0-0, 0-1, 1-1, 1-2, 1-3, 2-3, 2-4, 2-5
- 달성 방법
- 서로 인과성이 있는 쓰기는 동일한 파티션에 기록되게끔 한다
- 장단점
- 구현이 어렵다
4. 제한된 부실 Bounded Staleness
읽기 작업시 Old write 에 대한 읽기를 보장합니다.
- 읽기 작업시 반환될 수 있는 점수
- 1-3, 1-4, 1-5, 2-3, 2-4, 2-5
- 달성 방법
- secondary server 의 primary 와의 마지막 sync time 이 time bound 를 벗어나면 읽기 작업을 실패 시킨다
- 클라이언트에서 가장 최근 쓰기의 타임스탬프를 기억하고, 복제 서버가 아직 최신 내용이 아닌 경우에는 다른 복제 서버가 읽기를 처리하거나 복제 서버가 따라잡을 때까지 질의를 대기시킬 수 있다
- 장단점
- 보장하는 범위에 따라서 강한 일관성 혹은 최종적 일관성과 동일하게 동작한다
5. 단조 읽기 Monotonic Reads
읽기 작업시 이미 읽은 write 이후의 일부 write 에 대한 읽기를 보장합니다.
각기 다른 복제 서버에서 여러 읽기를 수행할 때, 첫번째 질의는 모든 write 가 반영된 서버에서 읽었지만, 두번째 질의는 write 중 일부가 누락된 서버에서 읽으면 첫번째 질의에서 읽은 값이 사라지는 현상이 발생할 수 있습니다.
- 읽기 작업시 반환될 수 있는 점수
- after reading 1-3: 1-3, 1-4, 1-5, 2-3, 2-4, 2-5
- 달성 방법
- 클라이언트에서 읽은 데이터를 기록한다
- 각 사용자의 읽기가 동일한 복제 서버에서 수행되도록 보장한다
- 장단점
- 강한 일관성보다는 덜한 보장이지만 최종적 일관성보다는 더 강한 보장이다
6. 자신의 쓰기 읽기 일관성 Read My Writes
읽기 작업시 자신의 write 는 모든 write 를 읽는 것을 보장하지만, 자신의 write 가 아니라면 모든 write 의 일부를 읽는 것을 보장합니다.
페이지를 재로딩시에 자신의 write 가 반영되지 않은 서버에 질의시 자신의 write 가 보이지 않을 수 있습니다.
- 읽기 작업시 반환될 수 있는 점수
- for the writer: 2-5
- for anyone other than the writer: 0-0, 0-1, 0-2, 0-3, 0-4, 0-5, 1-0, 1-1, 1-2, 1-3, 1-4, 1-5, 2-0, 2-1, 2-2, 2-3, 2-4, 2-5
- 달성 방법
- 자신의 write 는 primary 에서 읽는다
- 클라이언트에서 마지막 갱신 시각을 기록하고, 갱신 후 1분 동안은 primary 에서 읽는다
- 동일한 사용자가 여러 디바이스로 서비스에 접근할 때
- cross-device 쓰기 후 읽기 일관성
- 사용자의 마지막 갱신 타임스탬프를 기억하는 방식은 어렵다. 한 디바이스에서의 갱신 타임스탬프를 다른 디바이스에서 알기 위해서는 이 메타데이터를 중앙집중식으로 관리해야한다
- 복제 서버가 여러 데이터센터 간에 분산돼 있다면, 리더에서 읽어야 할 필요가 있는 접근법이라면 먼저 사용자 디바이스의 요청을 동일한 데이터센터로 라우팅 해야 한다
- 장단점
- 리더가 제공해야 하는 모든 요청은 리더가 포함된 데이터센터로 라우팅돼야 한다
야구 경기 참가자들의 읽기 일관성
야구 경기에 등장하는 참가자들의 입장에서 야구 점수가 저장된 key-value store 가 어떠한 읽기 일관성을 보장해야 하는지를 설명합니다.
Official scorekeeper
점수를 기록하는 사람은 존재할 수 없는 점수를 기록해서는 안되고, 점수가 줄어들어서도 안되고, 정확한 점수를 기록해야 합니다.
강한 일관성이 제공되어야 할 것 같지만, 점수 기록관은 점수를 업데이트하는 유일한 사람이고, 읽기 성능이 필요하지 않습니다. 그는 자신이 기록한 점수를 읽고 다시 기록하는 정도의 일관성이 필요합니다.
"read my writes"
Umpire
심판은 현재 점수가 몇점인지 신경쓰지 않아도 됩니다. 유일하게 점수가 필요한 순간은 9회말에 홈팀의 점수가 더 높다면, 더 이상 경기를 지속할 필요가 없기 때문에 경기 종료를 선언하는 순간입니다. 9회 초가 끝났을때 현재의 정확한 점수가 필요합니다.
점수 기록관과 다르게 심판은 점수를 기록하지 않기에 읽는 작업만 수행합니다.
"strong consistency"
Radio reporter
라디오 리포터는 주기적으로 점수를 읽어서 시청자들에게 제공해줍니다. 이때 시청자들은 조금 예전 점수를 제공해주어도 큰 문제가 없습니다. 최종적 일관성을 제공할 수 있을 것 같지만, 30분전에 제공한 점수보다 현재 더 낮은 점수를 주는 상황이 일어나서는 안됩니다.
"monotonic reads" + "consistent prefix" or "monotonic reads" + "bounded staleness"
Sportswriter
스포츠기자는 경기 중에는 맥주를 마시거나 경기를 즐기며, 경기가 끝나면 저녁을 먹고 그 이후에 기사를 쓰기 시작할 겁니다. 그들은 경기의 정확한 마지막 점수를 한번 조회하는게 필요합니다. 강한 일관성을 제공하기에는 비용이 크기 때문에, 한시간 정도 전의 정확한 점수를 주는 것 정도면 기사를 쓰는 시점에는 충분할 겁니다.
"bounded staleness"
Statistician
그들은 시즌의 팀 통계를 기록하는 업무를 합니다. 팀의 점수를 조회한 뒤 seacon-runs 점수를 업데이트 합니다. 경기 중에 점수를 조회한다면 strong consistency, 경기 종료 후에 조회한다면 bounded staleness 가 동일한 역할을 수행할 겁니다. 통계를 기록하는 사람이 1명이라면 read my writes 역시 동일한 역할을 수행합니다.
"strong consistency" or "bounded staleness" or "read my writes"
Stat watcher
가끔 점수 통계를 보고 친구와 토론을 하는 정도의 사람이라면 season-runs 점수에 대해 eventual consistency 정도면 충분할 겁니다.
"eventual consistency"
결론
상황과 역할에 따라서 필요로 하는 읽기 일관성이 다를 수 있습니다. 또한 한가지 일관성만을 제공해야 하는 것은 아닙니다.
- 6가지 일관성 보장 방법은 모두 유용합니다.
- 같은 데이터라도 클라이언트에 따라 다른 일관성을 필요로 할 수 있습니다.
- 심지어 간단한 데이터베이스라도 다양한 사용자에게 다른 일관성이 필요할 수 있습니다.
- 클라이언트는 그들이 원하는 일관성을 선택할 수 있어야 합니다.
읽기 일관성을 보장할 수 있는 여러가지 이론적인, 실질적인 방법들을 배웠고, 실제로 apache cassandra, azure cosmos DB 에서는 consistency level 을 설정할 수 있다. 애플리케이션의 요구사항에 따라서 적절한 일관성 보장을 사용할 수 있어야 한다.
'database' 카테고리의 다른 글
| 결합 인덱스와 단일 칼럼 인덱스 (Oracle) (0) | 2020.05.31 |
|---|
