네, 반갑습니다. 오늘은 락을 사용해서 컨커런시 컨트롤을 어떻게 구현할 수 있는지를 살펴보도록 하겠습니다.

그럼 오늘도 고고싱. 자, 여기 데이터베이스에 10이라는 값을 가지는 x라는 데이터가 있습니다.

이제 x를 20으로 바꿔주는 트랜잭션 1번이 시작을 한다고 했을 때 그러면 이 트랜잭션은 이렇게 x를 20으로 라이트를 해주게 되겠죠.

그런데 실제로 이렇게 라이트를 하는 과정은 지금은 쉽게 설명을 하려고 이렇게 간단하게 표시를 한 거지만 사실은 단순히 값 하나 바꾸는 것보다 더 복잡한 과정이에요.

라이트를 하게 되면 만약에 인덱스가 걸려 있다면 인덱스에 대한 처리를 해줘야 될 수도 있고요.

그리고 이 데이터가 실제로 저장되는 파일에 대해서도 이런저런 처리를 해줘야 될 수도 있어요.

그래서 이렇게 라이트를 한다는 게 그냥 값 하나 바꾸는 것처럼 그렇게 단순하지만 않은 작업인 거죠.

그렇기 때문에 만약에 x를 90으로 바꿔주는 트랜잭션 2번이 이렇게 동시에 실행이 된다고 해볼게요.

그러면은 같은 데이터에 대해서 이렇게 둘 다 라이트를 동시에 실행을 하는 거니까 어쩌면 이 x에 대한 처리가 깔끔하게 되지 않아서 예상치 못한 동 결과가 발생할 수도 있습니다.

그래서 지금 예제는 이렇게 같은 데이터를 y2 하는 건데 꼭 그게 아니더라도 이렇게 라이트를 하고 있을 때 동시에 같은 데이터에 또 다른 리드나 라이트가 있다면 예상치 못한 동작이 발생할 수 있는 거죠.

그러면 이 문제를 어떻게 해결할 수 있냐, 바로 락을 써서 해결할 수가 있습니다.

이 락은 우리가 운영체제에서 배우는 그 락과 같다고 보시면 돼요.

이 락에 대해서 간단하게 설명하면 데이터마다 락이 있어서 그 데이터를 변경하거나 읽으려면 그 락을 취득을 해야 돼요.

만약에 락을 취득하지 못하면 그 락을 취득할 때까지 기다려야 되는 겁니다.

그러면 이 락을 써서 방금이 두 개의 트랜잭션을 처리를 해보도록 하겠습니다.

자, 트랜잭션 1번이 이렇게 먼저 시작을 했다면 지금이 트랜잭션은 x를 20으로 바꿔주는 트랜잭션이기 때문에 데이터 x에 대해서 라이트 락, 그러니까 쓰기 락을 먼저 획득을 해야 됩니다.

그래서 이렇게 라이트 락을 획득을 했어요. 그런데 이 타이밍에서 트랜잭션 2번이 시작을 한 거예요.

그러면 이 트랜잭션은 x를 90으로 바꿔주는 트랜잭션이기 때문에 얘도 먼저 x에 대해서 이 라이트 락을 획득하려고 시도를 합니다.

하지만 이미 이 x에 대한 라이트 락은 트랜잭션 1번이 쥐고 있기 때문에 그러면 이 트랜잭션 2번은 더 이상 진행하지 못하고 이 lock이 풀릴 때까지 기다리게 됩니다.

그러면 트랜잭션 2번은 락이 풀릴 때까지 기다리게 되고, 그러니까 블락이 되는 거죠.

그렇게 블락이 되고 트랜잭션 1번은 계속해서 이어서 진행을 합니다.

그래서 얘는 x를 20으로 라이트를 하고요.

그러면 이제 이 값이 이렇게 20으로 바뀌게 되겠죠. 그리고 나서 락을 해제를 합니다.

그러면 이 락을 획득하려고 기다리고 있던 트랜잭션 2번이 이제 이렇게 락을 획득하게 되는 거죠.

그러면 이제 주주적 진행을 하면 됩니다.

x를 90으로 이렇게 라이트를 해 주고요. 그러면 여기가 이제 이렇게 90으로 바뀌게 됩니다.

이제 x에 대한 처리는 끝이 났으니까 락을 해제를 해줘야 되겠죠.

그래야 또 다른 트랜잭션이 이 x에 대해서 읽기나 쓰기를 하려면 이어서 처리를 할 수 있으니까요.

그래서 이렇게 x에 대해서 언락을 수행을 합니다.

그러면 이 락은 이제 반환이 되는 거죠. 또 다른 예를 하나 살펴보겠습니다.

이번에는 트랜잭션 1번은 똑같아요. x를 20으로 바꿔주는 건데 트랜잭션 2번 x를 읽는 트랜잭션입니다.

이번에도 트랜잭션 1번이 먼저 시작을 했다고 해볼게요.

그러면 쓰기를 할 목적으로 락을 취득을 합니다.

그래서 이렇게 락을 획득을 했고요. 그리고 이 타이밍에 트랜잭션 2번이 시작을 해요.

그러면 x를 읽기 위해서, 읽기 위한 목적으로 락을 획득하려고 시도를 해요.

하지만 이 경우에도 이미 트랜잭션 1번이 x에 대해서 쓰기를 할 목적으로 이렇게 락을 이미 취득을 한 상태였기 때문에 그러면 트랜잭션 2번은 이 락을 취득하기 위해서 계속 기다리게 됩니다.

더 이상 진행을 하지 못하는 거예요.

하지만 트랜잭션 1번은 계속 진행을 할 수 있겠죠. 그래서 이렇게 x는 20으로 라이트를 해주고요.

그러면 x값은 이렇게 업데이트가 되겠죠.

그리고 나서 이제 x에 대한 처리가 끝이 났으니까 이렇게 x에 대해서 언락을 해주는 겁니다.

그러면 이제 이 락을 해제가 되고, 이 락이 해제되기를 기다리고 있었던 트랜잭션 2번이 x에 대해서 읽기 목적으로 사용될 락을 이렇게 취득할 수 있게 되는 거죠.

그리고 나서 트랜잭션 2번도 주주적 진행을 하게 됩니다.

그래서 x의 값이 20이라고 읽게 되고요 이어서 x에 대한 락을 이렇게 판단을 하게 됩니다.

자, 그러면 여기까지의 내용을 정리를 하면 먼저 우리는 라이트락이라는 것을 배웠어요.

이 라이트락은 또 다른 말로는 익스클루시브 락이라고도 합니다.

얘는 자, 이름은 라이트락이지만 사실은 라이트 용도뿐만 아니라 리드를 할 때도 사용을 할 수 있어요.

핵심은 익스클루시브라는 겁니다. 무슨 말이냐면 라이트락을 획득을 하게 되면 다른 트랜잭션이 같은 데이터에 대해서 동시에 리드나 라이트 하는 것을 허용하지 않게 되는 거죠.

자, 다시 강조하고 싶은 것은 라이트락이라고 해서 무조건 라이트 할 때만 사용해야 되는 것은 아닌 거예요.

이 라이트락은 익스클루시브 형태로 쓸 때 사용되는 거라서 일단 라이트 락을 획득한 뒤에는 라이트로 쓸 수도 있고 리드로 쓸 수도 있고 리드 라이트를 둘 다 할 수도 있고 그것은 자유롭게 쓸 수 있는 겁니다.

대신에 익스클루시브한 형태, 그러니까 다른 트랜잭션은 같은 데이터에 동시에 리드 락, 라이트 락을 할 수 없다, 그렇게 이해를 하시면 되고요.

그 다음에 리드 락이 있습니다.

쉐어드 락이라고도 하는데요. 얘는 락을 획득하는 이유가 읽기를 위한 목적으로 획득을 하는 거예요.

그렇기 때문에 얘는 리드할 때 사용을 해야 됩니다.

라이트 할 때는 이 리드 락이 되지 않고요.

리드할 때 사용이 되는 거예요. 그래서 얘는 특징이 뭐냐면 또 다른 이름이 쉐어드 락이라고 했잖아요.

이게 무슨 의미냐면 다른 트랜잭션이 같은 데이터에 대해서 동시에 리드하는 것은 허용한다라는 의미인 거예요.

이 부분은 직관적으로 생각해 봐도 당연한 얘기겠죠.

읽기를 하는 것은 데이터를 바꾸는 것은 아니기 때문에 같은 데이터에 동시에 아무리 여러 개가 읽어도 그것은 전혀 문제될 것이 없으니까 리드 락 같은 경우에는 또 다른 트랜잭션이 같은 데이터에 대해서 리드를 하려고 할 때는 그것은 허용을 하는 겁니다.

대신에 이미 내가 리드 락을 가지고 읽고 있는데, 같은 데이터에 대해서 다른 트랜잭션이 라이트를 하려고 한다, 즉 쓰기를 하려고 한다면 이때는 이 리드를 보호를 해야 되기 때문에 그때는 이 리드 락이 안전하게 데이터를 읽을 수 있도록 보호하는 역할을 하는 거죠.

자, 그러면 이 라이트 락과 리드 락을 잘 이해하기 위해서 두 가지 예제를 추가로 살펴볼게요.

트랜잭션 1번은 x를 20으로 바꾸는 거고요, 트랜잭션 2번은 x를 읽는 거예요.

그런데 이번에는 트랜잭션 2번이 먼저 시작을 한 겁니다.

그러면 얘는 x를 읽기 위해서 먼저 락을 획득을 해야 되는데, 리드 하기 위한 목적으로 락을 획득을 하는 거예요.

자, 그래서 이렇게 락을 획득을 했고요. 이어서 이 타이밍에 트랜잭션 1번이 시작을 했어요.

얘는 x를 20으로 바꾸는 트랜잭션이기 때문에 x에 대해서 쓰기를 위한 목적으로 락을 획득하려고 시도를 합니다.

하지만 이미 트랜잭션 2번이 x에 대해서 리드 목적의 락을 획득한 상태이기 때문에 트랜잭션 1번은 이 락을 획득할 수가 없고요.

대신에 이 락이 해제될 때까지 기다려야 됩니다. 그래서 트랜잭션 1번은 더 이상 진행하지 못하고 블락이 되는 거죠.

대신에 트랜잭션 2번은 주저 없이 진행을 합니다.

그래서 이렇게 x에 대해서 10이라는 값을 읽은 뒤에 x에 대한 락을 이렇게 반환을 하는 거죠.

그러면 이렇게 반환을 하게 되면 여기서부터 락을 획득하려고 기다리고 있던 트랜잭션 1번이 이제 쓰기 락을 이렇게 획득하게 되고요.

그러면 이어서 진행을 하면 되니까 이렇게 x를 20으로 쓴 뒤에 그 락을 반환하게 됩니다.

그래서 이렇게 락이 해제되는 거죠.

이해가 되시나요? 그래서 지금 이 예제는 트랜잭션 2번이 x를 먼저 읽게 됐을 때 리드 락을 획득하게 되면서 그 리드 락이 다른 인젝션이 같은 데이터에 대해서 라이트를 하려고 할 때 읽기를 이렇게 보호하는 역할을 하게 됐다 이것을 확인해 볼 수 있는 예제였고요.

또 다른 예제를 하나 살펴보겠습니다. 이번에는 1번 트랜잭션도 x를 읽는 거고 2번 트랜잭션도 x를 읽는 거예요.

자, 만약에 2번 트랜잭션이 먼저 시작을 했다면 x를 읽기 위해서 읽기 목적의 락을 획득하려고 하겠죠.

그래서 이렇게 락을 획득을 했습니다. 자, 이 타이밍에 트랜잭션 1번도 시작을 했어요.

그러면 얘도 마찬가지로 x를 읽어야 하기 때문에 x에 대해서 읽기 목적으로 락을 획득하려고 해요.

자, 그런데 아까 앞에서 살펴봤던 것처럼 리드 락 같은 경우에는 다른 트랜잭션이 같은 데이터에 대해서 읽으려고 한다면 그때는 그것을 허용한다고 했잖아요.

그래서 이 트랜잭션 1번도 이렇게 리드 락을 획득할 수 있습니다.

그러면 이렇게 둘 다 리드락을 획득을 했으니까 둘 다 이렇게 데이터를 읽을 수가 있어요.

서로가 서로에게 영향을 주지 않고 둘 다 이렇게 읽을 수 있기 때문에 이렇게 동시에 같은 라인으로 표현을 해봤습니다.

그리고 나서 둘 다 이렇게 언락을 하게 되면 이렇게 읽기를 하기 반환이 되는 거예요.

이해가 되시죠? 자, 그래서 지금까지의 내용을 정리를 해보면 서로에 대해서 호환성이 있어요.

그래서 어떤 트랜잭션의 리드락을 쥐고 있는데 같은 데이터에 대해서 또 다른 트랜잭션이 리드락을 획득하려고 한다면 그때는 허용이 됩니다.

하지만 그 외에 모든 경우, 예를 들어서 어떤 트랜잭션이 라이트락을 쥐고 있는데 같은 데이터에 대해서 리드락을 주려고 한다면 얘는 그게 허용되지 않고 이 라이트락이 해제될 때까지 기다려야 됩니다.

반대로 이미 어떤 트랜잭션이 리드락을 쥐고 있는데 같은 데이터에 대해서 다른 트랜잭션이 라이트락을 주려고 한다면 이 또한 허용되지 않고요 이 리드 락이 해제될 때까지 기다려야 됩니다.

마찬가지로 어떤 트랜잭션이 라이트 락을 쥐고 있는데 같은 데이터에 대해서 다른 트랜잭션이 라이트 락을 주려고 한다면 얘도 또한 허용되지 않고 먼저 쥐고 있던 라이트 락이 해제될 때까지 기다려야 됩니다.

그래서 이런 호환성이 있다라는 것을 잘 기억을 해주시면 좋을 것 같고요.

자, 그러면 이제 우리가 락에 대해서 살펴봤으니까 실제로 락을 통해서 컨커런시 컨트롤이 어떻게 구현될 수 있는지, 그러니까 어떻게 하면 시리얼라이저빌리티를 보장할 수 있는지, 트랜잭션의 아이솔레이션이 보장될 수 있는지 이런 것을 살펴보도록 하겠습니다.

자, 락이 있다고 해서 락을 사용하는 것만으로는 트랜잭션의 시리얼라이저빌리티를 보장할 수가 없거든요.

그래서 락을 사용했음에도 이상한 현상이 발생할 수 있는 그 예를 하나 살펴보도록 하겠습니다.

자, 데이터베이스에 이렇게 xy가 있습니다.

x는 100이라는 값을 가지고 있고 y는 200이라는 값을 가지고 있어요. 이 상황에서 두 개의 트랜잭션이 실행을 할 건데요.

1번 트랜잭션은 x와 y의 합을 구해서 x에 저장을 하는 거고요.

2번 트랜잭션은 x와 y의 합을 구해서 y에 저장을 하는 트랜잭션입니다.

자, 그러면 각각의 트랜잭션을 어떻게 실행할 수 있냐, 그것부터 살펴볼게요.

트랜잭션 1번은 x와 y의 합을 구해서 x에 저장을 하는 거니까, 그러면 일단은 y는 읽기만 하면 되는 거잖아요.

BJ.45 LOCK을 활용한 concurrency control 기법을 배워봅니다. 2PL(two-phase locking)도 같이 설명드려요~

8년차 백엔드 개발자가 배워서 남주려고 만든 채널이에요

알기 쉽게 설명합니다

함께 성장했으면 좋겠어요 :)


#컴공맛집 #백엔드전문채널


쉬운코드

락을 사용하여 동시성 제어를 구현하는 방법과 2PL 프로토콜을 소개하며, 2PL은 트랜잭션의 직렬화 가능성을 보장한다.

다양한 2PL 프로토콜(Conservative, Strict, Strong Strict)을 설명하고, 특히 Strict 2PL과 Strong Strict 2PL이 복구 가능성을 보장하여 많이 사용됨을 강조한다.

초기 RDBMS에서는 2PL이 많이 사용되었으나, MVCC (Multi-Version Concurrency Control)와 혼용하여 성능을 향상시키는 방식으로 발전되었다.

💡 락을 활용한 동시성 제어의 기초

데이터베이스에서 여러 트랜잭션이 동시에 실행될 때, **예상치 못한 결과가 발생하는 것을 막기 위해 동시성 제어(Concurrency Control)가 필요**합니다. 특히, 같은 데이터에 대해 동시에 쓰기(Write) 작업을 하거나, 쓰기 중 읽기(Read) 작업이 발생할 경우 데이터 불일치 문제가 생길 수 있습니다.

이러한 문제를 해결하기 위한 강력한 도구 중 하나가 바로 **락(Lock)**입니다. 락은 특정 데이터에 대한 접근 권한을 제어하여, 한 번에 하나의 트랜잭션만 데이터를 조작하거나 읽을 수 있도록 합니다. 락을 획득하지 못한 트랜잭션은 락이 해제될 때까지 기다리게 됩니다.

락은 크게 두 가지 종류로 나뉩니다: **라이트 락(Write Lock, 또는 Exclusive Lock)**과 **리드 락(Read Lock, 또는 Shared Lock)**. 라이트 락은 데이터를 변경할 목적으로 획득하며, 일단 라이트 락이 설정되면 다른 어떤 트랜잭션도 해당 데이터에 대해 읽기나 쓰기 락을 동시에 획득할 수 없습니다. 즉, **라이트 락은 다른 모든 종류의 락과 호환되지 않습니다.**

반면, 리드 락은 데이터를 읽을 목적으로 획득합니다. 리드 락의 가장 큰 특징은 **다른 트랜잭션이 같은 데이터에 대해 동시에 리드 락을 획득하는 것을 허용**한다는 점입니다. 여러 트랜잭션이 동시에 데이터를 읽는 것은 데이터 변경을 유발하지 않으므로 문제가 되지 않습니다. 그러나 리드 락이 설정된 상태에서 다른 트랜잭션이 해당 데이터에 대해 라이트 락을 획득하려고 하면, 리드 락이 해제될 때까지 기다려야 합니다. 이는 읽고 있는 데이터의 일관성을 보호하기 위함입니다.

🔄 2단계 잠금(2PL) 프로토콜로 직렬성 보장

단순히 락을 사용하는 것만으로는 트랜잭션의 직렬성(Serializability)이 항상 보장되지는 않습니다. 이를 해결하기 위해 **2단계 잠금(Two-Phase Locking, 2PL) 프로토콜**이 고안되었습니다. 2PL은 모든 락 획득(익스펜딩 페이즈)이 락 해제(슈링킹 페이즈)보다 먼저 일어나도록 강제하는 규칙입니다.

**2PL은 트랜잭션 내에서 새로운 락을 취득하는 모든 연산이 최초의 락 해제 연산 이전에 발생**해야 합니다. 즉, 한번 락을 해제하기 시작하면 더 이상 새로운 락을 취득할 수 없다는 의미입니다. 이 프로토콜을 따르면 트랜잭션의 직렬성이 보장되어, 동시성으로 인한 데이터 불일치 문제를 방지할 수 있습니다.

⚠️ 2PL의 한계: 데드락 발생 가능성

2PL 프로토콜은 직렬성을 보장하지만, **상황에 따라 데드락(Deadlock)이 발생할 수 있습니다.** 데드락은 두 개 이상의 트랜잭션이 서로가 쥐고 있는 락을 기다리면서 영원히 진행되지 못하는 상태를 의미합니다. 예를 들어, 트랜잭션 1이 X에 대한 라이트 락을 기다리고 있고 트랜잭션 2가 Y에 대한 라이트 락을 기다리는데, 동시에 트랜잭션 1이 Y에 대한 리드 락을 쥐고 있고 트랜잭션 2가 X에 대한 리드 락을 쥐고 있는 경우 데드락이 발생할 수 있습니다.

2PL은 여러 종류로 발전했는데, 주요한 두 가지는 **Strict 2PL (S2PL)**과 **Strong Strict 2PL (SS2PL)**입니다. S2PL은 롤백 상황에서도 데이터 복구 가능성(Recoverability)을 보장하는 스케줄인 스트릭트 스케줄(Strict Schedule)을 따릅니다. 이는 **쓰기 락을 획득한 트랜잭션이 커밋되거나 롤백되기 전까지는 다른 트랜잭션이 해당 데이터에 접근하지 못하도록 합니다.** S2PL은 쓰기 락만 트랜잭션의 커밋 또는 롤백 시점에 해제하는 반면,

**SS2PL(Rigorous 2PL)은 읽기 락과 쓰기 락 모두 트랜잭션이 커밋되거나 롤백될 때까지 해제하지 않습니다.** SS2PL은 구현이 S2PL보다 쉽다는 장점이 있지만, 락을 더 오래 쥐고 있기 때문에 다른 트랜잭션의 대기 시간을 늘려 전체 처리량을 저하시킬 수 있다는 단점도 있습니다.

🚀 락의 한계를 넘어: MVCC의 등장

초창기 RDBMS에서 2PL, 특히 S2PL이나 SS2PL은 동시성 제어의 표준적인 구현 방식이었지만, **리드-리드를 제외한 대부분의 경우 트랜잭션이 블락되어 전체 처리량(Throughput)이 좋지 않다는 문제**가 있었습니다. 특히 읽기 작업이 쓰기 작업을, 또는 그 반대로 블락하는 상황은 성능 저하의 주된 원인이었습니다.

이러한 한계를 극복하고 성능을 개선하기 위해 개발된 것이 바로 **MVCC(Multi Version Concurrency Control, 다중 버전 동시성 제어)**입니다. MVCC는 오늘날 많은 RDBMS에서 락과 함께 혼용되어 사용되며, 다음 영상에서 더 자세히 다룰 예정입니다.

데이터베이스 트랜잭션에서 동시성 제어가 필요한 주된 이유와 락이 이 문제를 어떻게 해결하는지 설명해 주세요.

라이트 락(Exclusive Lock)과 리드 락(Shared Lock)의 주요 차이점은 무엇이며, 각 락이 데이터 접근을 어떻게 제어하는지 구체적인 예시를 들어 설명해 주세요.

2PL(Two-Phase Locking) 프로토콜이 시리얼라이저빌리티를 보장하는 원리는 무엇이며, 컨저버티브 2PL, 스트릭트 2PL, 스트롱 스트릭트 2PL은 각각 어떤 특징을 가지고 있나요?

2PL 프로토콜을 따를 때 발생할 수 있는 데드락 문제는 무엇이며, 이를 해결하기 위한 기본적인 접근 방식은 무엇인가요?

초창기 RDBMS에서 2PL 프로토콜의 한계점은 무엇이었으며, 이를 극복하기 위해 등장한 MVCC(Multi-Version Concurrency Control)는 어떤 역할을 하는지 설명해 주세요.

Concurrency Control using Locks: Basic Concepts

Introduction of a database scenario with data 'x' and transactions modifying it.

Explanation of the complexity of write operations beyond simple value changes.

Problem of concurrent transactions writing to the same data, leading to unexpected results.

Introduction of locks as a solution to concurrency control problems.

Explanation of lock mechanism: acquiring locks before reading or writing data.

Write Locks (Exclusive Locks) and Read Locks (Shared Locks)

Transaction 1 acquires a write lock on 'x' before modification.

Transaction 2 attempts to acquire a write lock on 'x', but it's blocked.

Scenario where Transaction 1 writes and Transaction 2 reads 'x'.

Summary of write locks (exclusive) and read locks (shared).

Explanation of read locks and their behavior with concurrent reads and writes.

Implementing Concurrency Control with Locks and the Two-Phase Locking (2PL) Protocol

Discussion on how locks ensure serializability and transaction isolation.

Example scenario with transactions involving 'x' and 'y'.

Demonstration of a potential concurrency issue leading to incorrect results.

Solution: Reordering lock acquisition to resolve the concurrency issue.

Two-Phase Locking (2PL) Protocol and its Variations

Explanation of the 2PL protocol: all locking operations before the first unlock operation.

Discussion on potential deadlocks in 2PL.

Introduction of different types of 2PL protocols.

Conservative 2PL: acquiring all locks before starting the transaction.

Strict 2PL (S2PL): releasing locks only at commit or rollback.

Strong 2PL (SS2PL): releasing all locks (read and write) at commit or rollback.

Limitations of 2PL and Introduction to Multi-Version Concurrency Control (MVCC)

Discussion on performance limitations of 2PL due to blocking.

Introduction of MVCC as a solution to improve concurrency.

Many modern RDBMS use a combination of locks and MVCC.

Modern RDBMS use MVCC to enhance performance.

BJ.45 LOCK을 활용한 concurrency control 기법을 배워봅니다. 2PL(two-phase locking)도 같이 설명드려요~

BJ.45 LOCK을 활용한 concurrency control 기법을 배워봅니다. 2PL(two-phase locking)도 같이 설명드려요~

스크립트