들어가며

안녕하세요. 백엔드 엔지니어로 일을하다보면 우리가 가장 많이 사용하는 것 중 하나가 바로 데이터베이스인데, 우리는 주로 온라인 트랜잭션을 위한 용도로 데이터 베이스를 많이 사용합니다. 그래서 데이터베이스가 동시성 처리를 어떻게 처리하는지 잘 하는 것도 중요하기때문에, DBMS에서 동시성 처리를 동시성 처리를 위해 어떠한 방식이 존재하는지 알아보도록 하겠습니다.

DBMS에서 동시성 제어는 왜 필요할까?

트랜잭션을 동시에 실행하지 않고 순차적으로 실행하면, 동시에 트랜잭션이 실행되서 발생하는 문제에 대해서 우리가 이렇게 고민하지 않을텐데 동시성 제어가 필요한 이유가 무엇일까요?

그 이유는, 시스템의 성능 요구 사항을 충족시키기 위해서 DBMS에서 동시에 트랜잭션을 실행시킬 수 있어야 한다고 저는 생각합니다. 만약 DBMS에서 트랜잭션이 순차적으로 실행된다고 가정하면, 우리가 사용하는 모든 서비스에서 무언가를 할때마다 맛집에 가서 웨이팅하듯이 기다리고 있게될거라고 생각됩니다.

즉, 수많은 트랜잭션을 동시에 실행시켜서 대기시간을 줄이고 작업의 처리량을 늘리는게 DBMS의 동시성 제어의 목적이라고 할 수 있습니다.

아무런 제약없이 트랜잭션을 동시에 실행해도 괜찮을까?

트랜잭션에서 서로 연관이 없는 데이터를 수정하거나 할때는 문제가 발생하지 않을 수도 있습니다. 하지만, 각 트랜잭션이 동일한 자원을 동시에 수정하려고할 때 문제가 발생하기 시작합니다.

수많은 트랜잭션을 랜덤한 방식으로 동시에 실행할 때 발생하는 여러가지 문제를 Concurrency Control Problems 라고 부르는데요. 아래서 각각의 문제에 대해 알아보고 해당 문제들을 DBMS는 어떻게 해결했을지에 대해서 알아보도록 하겠습니다.

Dirty Read Problem

이 문제는 다른 트랜잭션에서 커밋을 하지 않았는데 변경된 사항을 참조할 수 있는 문제입니다.

아래 아메리카노 한잔의 가격을 업데이트하는 예시와 함께 어떠한 문제가 발생하는지 알아보도록 하겠습니다.

1. 트랜잭션 A에서 아메리카노 한잔의 가격을 조회합니다. 이때, 가격은 5000원 이였습니다.
2. 트랜잭션 A에서 물가상승으로 인해, 아메리카노 한잔의 가격을 1,000원 올렸습니다.
3. 트랜잭션 B가 아메리카노 한잔가격을 조회합니다. (이때는, 트랜잭션 A에서 변경한 6,000원)
4. 트랜잭션 B가 아메리카노 한잔가격을 1,000원 더 올려서 7,000원이 되었습니다.
5. 트랜잭션 A가 마음을 바꿔서 1,000원을 올리지 않아버렸습니다.

이상한 상황이 발생했습니다. 트랜잭션 A는 1,000원을 올리지 않고, 트랜잭션 B는 1,000원을 올렸을 뿐인데 아메리카노 한잔 가격이 7,000원이 되어버렸습니다. 이렇게 되면은 트랜잭션 A의 수정사항이 롤백되지않고 그대로 반영된 것처럼 보일 수도 있습니다.

다른 트랜잭션이 수정한 값을 읽을 수 있게된다면, 이처럼 의도하지 않은 업데이트 동작이 나오게 될 수 있습니다.

Unrepeatable Read Problem

이번 문제는

Phantom Read Problem

Lost Update Problem

동시성 제어 프로토콜

위와 같은 문제들을 피하고, 동시 트랜잭션을 실행하는 동안 일관성과 직렬성을 유지하기 위해 몇 가지 규칙이 만들어지는데요. 이러한 규칙을 동시성 제어 프로토콜이라고 합니다!

잠금 기반 프로토콜 (Locking-Based Protocols)

일관성을 유지하기 위해서는 트랜잭션 간의 격리가 가장 중요한 도구입니다. 읽기/쓰기 작업을 수행하기 위해

잠금 기반 프로토콜에 사용되는 두 가지 종류의 잠금이 있습니다.

1. 공유 잠금 (shared lock)

공유 잠금은 데이터에 대한 읽기 작업은 허용하지만 쓰기 작업을 막는 잠금입니다. 읽기 전용 잠금이라고도 부르며, 공유의 맨 앞 알파벳을 따서 S-lock 이라고 표기도 합니다.

2. 배타적 잠금 (exclusive lock)

다른 트랜잭션이 배타적 잠금이 걸린 데이터에 대한 쓰기 및 읽기 작업을 모두 비활성화하는 잠금을 배타적 잠금이라고 합니다. 배타적 잠금은 x-lock라고 합니다.

=> exclusive lock에 걸리면 shared lock을 걸 수 없다. => exclusive lock에 걸린 테이블, 레코드 등의 자원에 대해 다른 트랜잭션이 exclusive lock을 걸 수 없다.

Simplistic Lock Protocol

• 데이터를 업데이트 하려고할 때, 데이터에 대한 다른 모든 연산을 잠금하라고 지시한다.
• 모든 트랜잭션은 쓰기 연산 후 데이터에대한 모든연산이 잠금이 해제된다.

Pre-claiming Lock Protocol

• 초기 pre-claiming Lock protocl에 따르면
• 이름 그대로 사전 요구 잠금 프로토콜
• 트랜잭션이 작업을 실행하기 전에 시스템에 모든 잠금을 요청한다.
• 모든 잠금이 제공되면 트랜잭션의 작업이 원활하게 실행되고 완료 시 잠금이 반환된다.
• 모든 잠금이 제공되지 않으면 트랜잭션이 롤백된다.

Two-phase Locking Protocol

• 2단계 잠금이지만 3단계로 구성되있다.
  1. 트랜잭션은 잠금을 요청하는 첫 번째 단계에서 실행
  2. 잠금이 부여되면 트랜잭션이 모든 잠금을 포함하는 두 번째 단계가 실행
  3. 트랜잭션이 첫 번째 잠금을 해제하면 트랜잭션의 모든 작업이 실행된 후 모든 잠금이 해제되는 세 번째 단계가 시작

Strict Two-Phase Locking Protocol

• 위와 비슷하지만 작업 실행 직후 잠금 해제를 허용하지 않지만 모든 잠그을 수행하고 커밋이 트리거될 때 잠금을 해제한다.
• 조금 더, 엄격하다는 의미로 트랜잭션 내에서 작업을 완료 한 직후, 바로 잠금을 해제하는 것이 아닌 커밋이 되기 직전에 잠금을 해제.
• https://study.com/cimages/multimages/16/0c149095-fa66-4c78-9413-45a3d178480d_diagram01.png

타임스탬프 기반 프로토콜 (Timestamp-Based Protocols)

Timestamp Ordering Protocol

• 각 트랜잭션은 타임스탬프를 발행한다. 트랜잭션이 시스템에 진입할 때.
  • 더 오래된 트랜잭션 T_i는 새로운 트랜잭션 T_j 보다 더 작은 타임 스탬프를 가진다.
  • TS(Ti) < TS(Tj)

Validation Based Protocol

• Optimistic Concurrency Control Technique. 라고도 부른다.

• 이 프로토콜은 DBMS에서 트랜잭션 내의 동시성 문제를 피하기 위한 것

• 트랜잭션 동안에는 검사를 하지 않는다.

• 트랜잭션의 끝에 도달했을 때, 트랜잭션의 업데이트가 데이터베이스에 직접 적용되지 않는다.

• 모든 업데이트는 로컬에 데이터의 카피로 적용된다.

• 트랜잭션의 실행 끝에, validation phase에서 트랜잭션 업데이트가 직렬성을 위반하는지 아닌지를 검사한다.

• 직렬성의 위반이 없다면, 트랜잭션은 커밋되고 데이터베이스는 업데이트된다. 그렇지 않다면, 트랜잭션은 업데이트되고 재시작된다.

• 낙관적인 동시성 제어는 3단계 국면의 프로토콜로 구성되어있다.

  1. Read Phase (읽기 단계)
  2. Validation Phase (검증 단계)
  3. Write Phase (쓰기 단계)

이러한 방식의 유효성 검사 기반의 프로토콜은 충돌이 자주 발생하지 않는 경우에 유용하다. 이 방법은 충돌이 발생할 가능성이 더 높고 짧은 트랜잭션하고 계속해서 충돌이 일어나 반복적으로 롤백이 될 수 있으므로 긴 트랜잭션에서는 사용하기에 적합하지 않다.

• 장점

  1. 캐스케이딩 롤백 방지: 줄줄이 롤백..?
  2. 교착 상태 방지 : 트랜잭션의 특정 순서를 유지하기 위해 엄격한 타임 스탬프 기반 기술이 사용, 그래서 이 방식에서는 교착 상태가 불가능

• 단점

  1. 기아(Starvation): 장기 트랜잭션의 재시작 등을 반복하는 일련의 충돌하는 단기 트랜잭션으로 인해 장기 트랜잭션이 기아가 될 가능성이 있다. 기아상태가 되지 않기 위해서는 충돌하는 트랜잭션을 잠시 동안 일시적으로 차단해서 장기 트랜잭션을 완료해야한다.

참고자료

• https://sis.binus.ac.id/2018/08/30/why-is-concurrency-control-needed/
• https://www.guru99.com/dbms-concurrency-control.html
• https://www.scaler.com/topics/dbms/concurrency-control-in-dbms/
• https://velog.io/@moonyoung/%ED%8A%B8%EB%9E%9C%EC%9E%AD%EC%85%98-%EA%B2%A9%EB%A6%AC-%EB%A0%88%EB%B2%A8
• https://steady-coding.tistory.com/562
• https://jeong-pro.tistory.com/94#:~:text=Exclusive%20lock%20(%EB%B0%B0%ED%83%80%EC%A0%81%20%EC%9E%A0%EA%B8%88)&text=%EC%93%B0%EA%B3%A0%EC%9E%90%20%ED%95%A0%20%EB%95%8C)%20%ED%95%B4%EB%8B%B9,%ED%8A%B8%EB%9E%9C%EC%9E%AD%EC%85%98%EC%9D%84%20%EC%A7%84%ED%96%89%EC%8B%9C%ED%82%A4%EB%8A%94%20%EA%B2%83%EC%9D%B4%EB%8B%A4.
• https://www.geeksforgeeks.org/validation-based-protocol-in-dbms/
• https://miet.ac.in/assets/uploads/cs/Monograph_Swati%20Jain.pdf
• https://www.cs.purdue.edu/homes/bb/cs542-11Spr/cc.pdf