병행제어

왜 배우는가: 병행제어는 여러 사용자가 같은 데이터를 동시에 갱신할 때 데이터 일관성이 깨지는 것을 막는 기본 메커니즘이다. 실무에서는 은행 송금, 예매, 재고 관리처럼 동시 접근이 많은 시스템의 정합성을 좌우한다. 시험에서는 정의, 기법 종류, 문제점을 묶어 반복해서 출제된다.

출제 이력: 제130회 1교시 2번, 제128회 4교시 5번

1. 한 줄 정의와 핵심 키워드

병행제어는 다수 트랜잭션이 동시에 실행될 때 데이터 일관성과 고립성(Isolation)을 보장하는 DBMS 메커니즘이다.

• 병행제어, 직렬 가능성(Serializability), 고립성(Isolation)
• 갱신 분실, 모순성, 연쇄 복귀, 비완료 의존성
• 로킹(Locking), 2단계 잠금(2PL), 타임스탬프 순서, 다중 버전 동시성 제어(MVCC)

답안 첫 줄에는 위 정의 문장을 그대로 쓰고, 키워드는 기법과 문제점 항목에서 차례로 풀어 쓴다. 키워드 중 기법 이름은 2절과 3절에서 다시 정의한다.

2. 개념 풀이

쉬운 말로 하면, 여러 사람이 한 장부를 동시에 고치더라도 결과가 한 사람씩 차례로 고친 것과 같아야 한다는 뜻이다. 이때 장부 결과가 틀어지지 않도록 순서를 조정하는 장치가 병행제어다.

정식 정의는 다음과 같다. 병행제어는 데이터베이스 트랜잭션 스케줄을 직렬 가능한 순서로 제약하여 고립성을 보장하는 동시성 제어 기법의 총체이다. 트랜잭션의 ACID 특성 중 고립성(Isolation)을 실현하는 것이 핵심 목표이며, 원자성·일관성·지속성 중 고립성과 직접 관련된 것이 바로 이 부분이다.

병행제어에서 말하는 직렬 가능성(Serializability)은 동시에 실행된 트랜잭션의 결과가 어떤 순서로든 하나씩 차례로 실행한 결과와 같다는 성질이다. 이 성질을 만족하는 스케줄을 직렬 가능 스케줄이라 한다.

회복 가능성(Recoverability)도 함께 보장해야 한다. 커밋한 트랜잭션이 나중에 취소되어야 하는 상황을 막는 성질이다. 영어 위키백과 설명에 따르면 직렬 가능성은 성능을 위해 완화될 수 있지만, 회복 가능성은 완화하면 무결성 위반으로 이어지므로 완화할 수 없다.

병행제어가 필요한 이유는 동시 실행 중 생기는 이상 현상을 막기 위해서다. 이 이상 현상의 정의와 방지 방법은 3절에서 다룬다.

3. 등장 배경과 필요성

다수 사용자가 같은 DB 자원을 공유하면서 처리량을 높이려면 트랜잭션을 동시에 실행해야 한다. 그러나 동시 실행은 인터리빙된 연산 순서에 따라 결과를 틀리게 만든다. 병행제어 없이 동시에 실행하면 다음 문제가 생긴다.

• 갱신 분실(Lost Update): 두 트랜잭션이 같은 값을 읽고 각각 갱신하여 한쪽 갱신 결과가 사라진다.
• 비완료 판독(Dirty Read): 아직 커밋되지 않은 값을 다른 트랜잭션이 읽는다.
• 비반복 가능 판독(Non-repeatable Read): 같은 트랜잭션 안에서 같은 행을 두 번 읽을 때 값이 달라진다.
• 팬텀(Phantom Read): 같은 조건으로 조회할 때 행의 개수가 달라진다.

기출 답안에서 자주 쓰는 표현으로는 갱모연비가 있다. 이는 갱신 분실, 모순성, 연쇄 복귀, 비완료 의존성의 첫 글자를 딴 것이다. 이 네 가지가 병행제어를 하지 않을 때 나타나는 문제점이다.

병행제어의 필요성은 두 가지로 요약된다. 첫째, 데이터 무결성과 일관성을 유지한다. 둘째, 동시 처리 성능을 높이되 그 결과가 신뢰할 수 있도록 한다. 실제로 은행 계좌 이체, 예매 좌석 배정, 재고 차감은 모두 병행제어가 없으면 중복 차감이나 초과 판매가 발생하는 예이다.

4. 구성요소·원리·절차

병행제어는 잠금 관리자, 타임스탬프 관리자, 버전 관리자, 교착 탐지기가 역할을 나눠 맡는다. 잠금 관리자는 데이터 항목마다 잠금 상태를 기록하고 요청의 허용 여부를 판단한다. 타임스탬프 관리자는 트랜잭션에 순서값을 부여하고 항목별 읽기·쓰기 시각을 관리한다. 버전 관리자는 다중 버전 기법에서 데이터의 여러 버전을 보관하고 골라 준다. 교착 탐지기는 대기 그래프의 순환을 찾아 희생 트랜잭션을 고른다.

표의 구성요소는 기법마다 조합이 다르다. 잠금 기반 기법은 잠금 관리자와 교착 탐지기를 쓰고, 다중 버전 기법은 버전 관리자를 추가로 쓴다.

병행제어의 원리는 직렬 가능성(Serializability)이다. 동시 실행 결과가 어떤 직렬 실행 순서의 결과와 같으면 올바른 스케줄로 본다. 두 연산이 충돌(Conflict)하려면 같은 데이터를 대상으로 서로 다른 트랜잭션이 수행하고, 그중 하나 이상이 쓰기여야 한다. 읽기끼리는 충돌하지 않는다.

병행제어의 목표는 동시 실행 결과를 어떤 직렬 실행 결과와 같게 만드는 것이다.

잠금의 호환성은 다음과 같다. 공유 잠금(S)끼리는 호환되고, 배타 잠금(X)은 다른 모든 잠금과 호환되지 않는다. 호환되지 않는 요청은 해당 잠금이 풀릴 때까지 대기한다.

2단계 잠금 프로토콜(2PL)의 절차는 다음과 같다.

• 트랜잭션이 데이터를 읽기 전 공유 잠금(S)을, 쓰기 전 배타 잠금(X)을 요청한다.
• 잠금 관리자가 호환 여부를 판정한다. 호환되면 잠금을 주고 연산을 실행하며, 호환되지 않으면 대기 큐에 넣는다.
• 확장 단계에서는 잠금을 얻기만 하고 해제하지 않는다.
• 트랜잭션이 처음으로 잠금을 해제하면 축소 단계로 들어간다. 이후에는 새 잠금을 얻을 수 없다.
• 커밋 또는 중단 후 남은 잠금을 모두 해제한다. 엄격 2PL(Strict 2PL)은 커밋 시점까지 배타 잠금을 보유한다.
• 대기 그래프에 순환이 생기면 교착으로 보고, 희생 트랜잭션을 롤백한 뒤 재실행한다.

2단계 잠금은 잠금의 획득과 해제 순서를 나누어 직렬성을 보장한다. 대기와 교착 비용이 따르는 것이 단점이다.

타임스탬프 순서(Timestamp Ordering) 기법은 잠금 없이 시각표로 순서를 맞춘다. 트랜잭션 T가 데이터 x를 읽을 때 TS(T)가 x의 쓰기 시각 write_TS(x)보다 작으면 거부하고 롤백한다. 쓰기는 TS(T)가 read_TS(x)보다 작으면 거부한다. 이 기법은 교착이 없지만 롤백이 잦을 수 있다.

낙관적 병행제어(OCC)는 실행 중에는 검사하지 않고, 커밋 전에 읽기·쓰기 집합의 충돌을 검증한다. 충돌이 없으면 변경을 반영하고, 있으면 롤백한다. 충돌이 드문 읽기 중심 작업에 적합하다.

다중 버전 병행제어(MVCC)는 데이터마다 여러 버전을 두어 읽기가 쓰기를 막지 않게 한다. 읽기 트랜잭션은 자기 시작 시점에 맞는 버전을 본다.

5. 관련 법령·기준·표준

병행제어 자체를 직접 규정하는 법령 조문은 확인되지 않는다. 기준은 격리 수준의 구분과 학계의 직렬 가능성 이론이다. 격리 수준은 허용하는 동시성 현상의 종류로 구분한다. 개발자는 업무 요구에 맞는 수준을 고르고, 수준이 낮을수록 성능은 높아지고 정합성 위험은 커진다.

위 표는 격리 수준별 허용·방지 현상을 요약한 것이다. 갱신 분실은 표준 표에 없는 현상이므로 잠금 규칙으로 따로 막는다. 즉 격리 수준만으로 갱신 분실을 막았다고 답하면 감점된다.

직렬 가능성은 가장 강한 격리 기준이다. 그러나 구현 비용이 크므로 실무에서는 Read Committed를 기본값으로 쓰는 DBMS가 많다. 격리 수준은 동시성 현상의 허용·방지 범위를 구분하는 기준이다.

교착 처리에 대한 수치 기준은 표준에 없다. 대기 시간 제한값과 탐지 주기는 DBMS 설정값이며, 설계 시 운영 조건에 따라 정한다.