−1. 실행 순서를 대상으로 삼다
동시에 시작한 두 작업도 읽기와 쓰기는 어떤 순서로 섞여 실행된다. 이 순서를 스케줄(schedule)이라고 부른다. 동시성 제어 이론은 가능한 스케줄 중 어느 것을 허용해야 개별 작업이 지키던 데이터 규칙을 전체에서도 유지할 수 있는지 묻는다.
Eswaran·Gray·Lorie·Traiger의 1976년 논문은 일관성과 트랜잭션, 잠금 프로토콜을 연결하고 조건식으로 지정한 데이터 집합을 보호하는 문제를 다뤘다. 데이터가 물리적으로 놓인 행만 보호할 것인지, “이 날짜에 예약된 모든 방”처럼 논리적 조건에 해당하는 집합을 보호할 것인지가 중요한 차이였다.[각주 1]
직렬가능성은 함께 실행해 성공한 트랜잭션들의 효과가 어떤 직렬 실행과 같도록 요구한다. 이를 얻는 구현은 하나가 아니다. 충돌을 먼저 막거나, 나중에 검증하거나, 여러 버전을 읽게 하면서 의존성을 검사할 수 있다.
2. 잠금과 2단계 잠금
잠금(lock)은 충돌하는 접근을 조정하는 권한이다. 읽기와 쓰기의 종류, 보호 단위에 따라 서로 함께 허용되는 잠금과 기다려야 하는 잠금이 달라진다. DB에서는 행·테이블·키 범위 등 여러 단위가 사용된다.
2단계 잠금(two-phase locking, 2PL)은 잠금을 획득하는 단계와 해제하는 단계를 나누는 규칙이다. 어떤 잠금을 해제한 뒤에는 새 잠금을 얻지 않는다. 적절한 잠금 모드와 보호 범위를 전제로 이 규칙은 충돌 직렬가능성을 얻는 데 쓰인다. strict 2PL은 쓰기 잠금을 트랜잭션 종료까지 유지해 미확정 쓰기와 복구의 관계도 다룬다.[각주 1]
여기서 두 단계는 분산 커밋의 2PC와 다른 구분이다. 2PL은 공유 데이터 접근의 순서를, 2PC는 여러 참여자의 커밋 결정을 조정한다.
서로 다른 작업이 상대가 가진 잠금을 기다리면 교착상태(deadlock)가 생길 수 있다. DB는 이를 감지해 한 작업을 중단하거나 타임아웃을 적용할 수 있다. PostgreSQL의 행 잠금도 충돌하는 쓰기를 기다리게 하지만 일반적인 스냅샷 읽기까지 일괄 중단시키지는 않는다.[각주 2]
3. 1981년 낙관적 검증
Kung과 Robinson은 1981년 「On Optimistic Methods for Concurrency Control」에서 읽기·검증·쓰기 단계를 구분하는 방법을 제시했다. 먼저 작업을 진행하고, 읽고 쓴 데이터의 관계를 검사해 허용할 수 있는 실행인지 결정하는 방식이다.[각주 3]
이 접근에서 낙관적이라는 말은 작업이 언제나 성공한다는 뜻이 아니라, 충돌을 미리 모두 막는 대신 검증 시점에 찾아내고 필요하면 작업을 취소한다는 뜻이다. 충돌이 드물면 기다림을 줄일 여지가 있고, 같은 데이터에 충돌이 집중되면 버려지는 작업이 늘어난다.
웹 편집기의 버전 검사는 이 생각을 좁은 범위에서 볼 수 있는 사례다. 읽어둔 글의 버전과 현재 버전이 같을 때만 저장한다. 논문의 읽기·쓰기 집합 검증 전체와 한 행의 버전 조건은 구분해서 이해해야 한다.
4. 여러 버전을 읽는 방법
MVCC는 쓰는 작업이 새 버전을 만들고, 읽는 작업이 자신에게 보이는 버전을 고르게 하는 방식이다. 이전 값을 필요한 독자에게 남겨둘 수 있어 읽기와 쓰기 사이의 대기를 줄이는 데 쓰인다.
그러나 버전이 여러 개라는 사실만으로 어떤 격리를 얻는지가 정해지지는 않는다. 문장마다 읽을 스냅샷을 바꾸는지, 트랜잭션 동안 유지하는지, 읽기와 쓰기의 의존성 순환을 검사하는지가 함께 작동한다. PostgreSQL도 MVCC를 사용하면서 Read Committed·Repeatable Read·Serializable에 다른 규칙을 둔다.[각주 4]
잠금·버전·검증은 배타적인 제품 분류표가 아니다. MVCC DB도 쓰기 충돌에 잠금을 사용하고, 애플리케이션이 낙관적 버전 검사를 해도 저장 문장 안에서는 DB의 동시성 규칙이 적용된다.
5. 한 행의 변경을 조건으로 표현하기
다음 PostgreSQL 예제의 목적은 “버전이 같을 때만 저장한다”는 판단을 읽기와 쓰기 사이에 흩어놓지 않고, 저장 문장에 포함하는 것이다.
+일관성을 스케줄과 잠금으로 설명하다 (1976)
공유 데이터를 여러 사용자가 다루는 DB에서는 작업의 읽기와 쓰기가 섞이는 순서를 분석해야 한다. 순서가 달라져도 무결성을 유지하려면 단순히 “여기에 잠금을 건다”를 넘어 잠금을 얻고 놓는 규칙이 필요하다.
Eswaran·Gray·Lorie·Traiger의 1976년 논문은 트랜잭션·일관성·스케줄을 정의하고 2단계 잠금의 관계를 분석했다. 잠금을 늘리는 단계에서 줄이는 단계로 넘어간 뒤에는 새 잠금을 얻지 않는 규칙이 핵심이다.[각주 1]
논문은 물리적인 레코드와 조건으로 선택한 데이터 집합의 차이도 다룬다. “이미 존재하는 예약 행”과 “이 날짜에 생길 수 있는 예약”은 같은 보호 대상이 아니다. 동시성 제어의 범위를 논리적 규칙에서 읽어야 한다는 문제가 이 시기에 분명하게 드러났다.
충돌을 뒤에서 검증하는 낙관적 접근 (1981)
Kung과 Robinson의 1981년 「On Optimistic Methods for Concurrency Control」는 먼저 작업을 진행하고 나중에 충돌을 검증하는 방법을 제시했다. 읽기·검증·쓰기 단계와 읽기·쓰기 집합의 관계를 통해 허용할 실행을 결정한다.[각주 2]
충돌이 드문 경우에는 미리 기다리는 비용을 줄일 여지가 있지만, 검증 실패로 버려지는 작업이 생긴다. 낙관적이라는 이름은 성공을 낙관적으로 가정해 검증 시점까지 진행한다는 운영 방식에 붙은 것이다.
웹 편집기의 버전 검사는 이 생각을 좁은 범위에서 보여준다. 저장하려는 행의 버전이 읽어둔 값과 같을 때만 변경한다. 한 행의 조건부 갱신과 논문의 전체 트랜잭션 검증 알고리즘을 같은 구현으로 부를 수는 없다.
여러 버전을 사용하는 기법의 이론화 (1983)
Philip A. Bernstein과 Nathan Goodman의 1983년 「Multiversion Concurrency Control—Theory and Algorithms」는 다중 버전 스케줄의 정확성을 설명하고 여러 알고리즘을 다룬다. 이는 MVCC의 최초 발명일을 확정하는 자료가 아니라, 여러 버전을 활용하는 실행을 공통된 이론으로 설명한 기록이다.[각주 3]
읽는 작업에 필요한 이전 버전을 남기면 쓰는 작업과 독자의 대기 관계가 달라진다. 하지만 어느 버전을 읽고 어떤 실행을 거절하는지는 별도의 규칙이다. 버전 보관과 직렬가능성의 조건을 구분하는 관점이 중요해진다.
오늘날의 제품도 여러 기법을 함께 쓴다. MVCC DB가 쓰기 충돌에 잠금을 사용하거나, 애플리케이션의 낙관적 검사가 DB 내부의 쓰기 잠금과 함께 작동할 수 있다.
스냅샷과 직렬가능성의 차이가 드러나다 (1995)
Berenson 등의 1995년 연구는 SQL 격리 수준의 정의와 스냅샷 격리를 분석했다. 두 작업이 같은 스냅샷을 읽어도 서로 다른 행을 바꾸며 전체 규칙을 깨뜨릴 수 있다는 쓰기 왜곡이 중요한 사례다.[각주 4]
이 구분은 한 행의 갱신 유실을 막는 일과 여러 행의 규칙을 지키는 일이 다름을 보여준다. 모든 행이 자기 버전 검사를 통과하더라도, 함께 읽은 조건이 더 이상 유지되지 않으면 업무의 결과가 달라질 수 있다.
따라서 잠금·검증·버전이라는 구현 이름보다 어떤 작업 집합의 결과를 어떤 직렬 실행과 같게 만들 것인지가 더 근본적인 질문으로 남는다.
읽은 버전을 HTTP 변경 조건으로 보내다 (1997~2022)
HTTP/1.1의 1997년 RFC 2068은 If-Match를 정의하고, 읽은 뒤 바뀐 자원을 잘못 수정하지 않도록 요청에 엔터티 태그를 넣는 용도를 설명했다. 2022년 RFC 9110도 이 조건의 의미를 규정한다.[각주 5][각주 6]
DB 내부의 동시성 이론과 HTTP 조건부 요청은 같은 프로토콜은 아니지만, 오래된 관찰에 근거한 쓰기를 막는 문제를 서로 다른 경계에서 다룬다. 서버는 요청의 조건을 실제 저장까지 연결해야 한다.
사람이 편집하는 시간 전체에 DB 잠금을 잡는 대신 저장 시점의 버전을 확인하는 UI도 이 관점으로 읽을 수 있다. 충돌 이후 기다릴지, 재조회할지, 사용자에게 병합을 요청할지는 애플리케이션의 결정이다.
현대 DB에서 남는 보호 범위의 문제
PostgreSQL의 SELECT ... FOR UPDATE는 선택한 행의 충돌하는 갱신을 조정하며 잠금을 트랜잭션 종료까지 유지한다. 일반 스냅샷 읽기까지 전부 막는 동작은 아니다. 서로 잠금을 기다리면 교착상태가 발생할 수도 있다.[각주 7]
예약이 없는 자원을 조회해 0행을 얻으면 잠글 예약 행도 없다. 고유 제약, 대표 자원 행의 잠금, 적합한 격리 규칙처럼 업무 조건에 맞는 보호가 필요하다. 현재 PostgreSQL도 MVCC 위에서 서로 다른 격리 수준을 제공한다.[각주 7][각주 8]
1976년의 잠금 규칙, 1981년의 검증, 1983년의 다중 버전 이론, HTTP의 사전조건은 모두 공유 상태의 관찰과 변경을 연결하는 문제를 다룬다. 보호 범위가 무엇인지가 각 기법의 계약을 읽는 기준이다.
한 행의 버전 조건을 보여주는 작은 예제
다음 PostgreSQL 코드는 “읽은 버전과 같을 때만 저장한다”는 조건을 저장 문장에 넣는다. 순서를 고정한 두 갱신으로 오래된 수정의 거절을 확인한다.
