[MongoDB] 잠금과 트랜잭션(1)

잠금

멀티 쓰레드의 동시 처리 중에 발생할 수 있는 쓰레드 간의 충돌 문제를 막기위해 데이터베이스와 컬렉션 그리고 도큐먼트들의 잠금을 사용한다.

여러 계층의 데이터베이스 오브젝트들에 대한 동시 처리를 위해서 인텐션 락과 다중 레벨의 잠금을 활용한다.

또한 MongoDB 잠금은 서버 차원에서 처리되는 잠금과 스토리지 엔진에서 처리되는 잠금으로 나누어 볼 수 있다.

 

MongoDB 엔진의 잠금

명시적 잠금과 묵시적 잠금으로 나눠볼 수 있는데, 명시적 잠금은 글로벌 잠금 뿐이며 나머지 모든 잠금은 묵시적 잠금이다.

데이터베이스나 컬렉션에 대한 잠금은 모두 묵시적이며, 이는 쿼리가 실행될 때 자동으로 획득했다가 해제되는 잠금이다.

 

글로벌 잠금

글로벌 잠금은 MongoDB 서버 인스턴스에 단 하나만 있는 잠금으로 인스턴스 잠금이라고도 한다.

db.fsyncLock({fsync:1, lock:true})

fsync 옵션을 1로 설정하면 MongoDB 서버는 디스크에 기록되지 못한 데이터를 모두 디스크로 플러시한다.

그리고 lock 옵션이 true 로 설정되면 글로벌 잠금을 획득한다.

만약 lock 옵션이 false 이면 데이터 파일만 디스크로 플러시하고 잠금을 걸지는 않는다.

fsyncLock 명령은 내부적으로 쓰기 잠금이 아닌 읽기 잠금에 해당한다.

 

그래서 MongoDB 서버의 데이터가 변경되는 것을 막는 용도의 잠금이고 다른 커넥션의 데이터 읽기를 막지는 않는다.

글로벌 잠금이 걸리면 db.currentOp 명령으로 글로벌 잠금의 상태를 확인할 수 있다.

 

데이터 변경과 읽기가 동시에 실행되는 커넥션의 경우,

변경에서 대기하게 되므로 읽기 또한 모두 멈추게 되므로 사용시 주의해야 한다.

 

글로벌 잠금은 fsyncUnlock 명령으로 잠금을 풀 수 있다.

다른 커넥션에서 실행해도 특이사항은 없으나 설정한 세션에서 풀도록 권고하고 있다.

 

오브젝트 잠금

S 잠금과 X 잠금에 더불어 IS 와 IX 잠금을 제공한다.

상호 호환 관계는 다음과 같다.

	Intent Shard	Intent Exclusive	Shared	Exclusive
Intent Shard	O	O	X	X
Intent Exclusive	O	O	X	X
Shared	X	X	O	X
Exclusive	X	X	X	X

 

MongoDB 는 여러 커넥션에서 요청하는 잠금을 적절한 동시성을 유지하면서 서로 문제를 일으키지 않도록 각 오브젝트 단위로 잠금 요청 큐를 관리한다.

하지만 MongoDB 잠금 큐는 먼저 들어온 잠금 대기가 잠금을 획득하지 못할 수도 있다.

 

IS IS X X S IS 일 때,  X 는 배타적이므로 어떤 잠금과도 호환되지 않기에 S IS 는 잠금획득을 기다려야 한다.

하지만 MongoDB 서버는 동시 처리 성능을 높이기 위해 큐에 있는 호환되는 잠금을 모두 동시에 허용해준다. 즉 IS IS 가 허용될 때 S IS 도 허용된다. 그리고 X 잠금은 호환되지 않으므로 마지막에 처리된다.

 

WiredTiger 스토리지 엔진의 잠금

도큐먼트 기반의 잠금을 사용한다.

하지만 다양한 레벨의 오브젝트에 대한 잠금을 위해 다중 레벨의 잠금 방식도 같이 사용한다.

 

WiredTiger 스토리지 엔진은 글로벌과 데이터베이스와 컬렉션 레벨의 인텐션 잠금을 활용하며

인텐션 잠금은 데이터베이스와 컬렉션 레벨의 명령과 도큐먼트 레벨의 명령이 최적의 동시성을 유지하면서 실행될 수 있게 해준다.

 

인텐션 잠금은 이름 그대로 특정 오브젝트에 대해 배타적 또는 공유 잠금에 대한 의도를 가지고 있다는 것을 의미하는데,

이는 현재 쓰레드가 특정 오브젝트에 대해 읽기 뿐 아니라 변경 의도를 가지고 있음에도 다른 변경 의도를 가진 쓰레드도 허용하는 형태의 잠금이다.

이런 형태의 요건은 주로 계층형 데이터 구조에서 사용되는데, 대표적으로 데이터베이스와 컬렉션 그리고 도큐먼트간의 관계이다.

 

각 계층 구조에서 하위 오브젝트에 대해 잠금을 획득하려면 상위 계층의 인텐션 잠금을 먼저 획득해야 한다.

특정 도큐먼트를 변경하려면 해당 도큐먼트에 대해 쓰기 잠금을 획득해야 하는데 이를 위해서 먼저 글로벌 인텐션 잠금과 데이터베이스 인텐션 잠금 컬렉션 인텐션 잠금을 가져야 한다.

도큐먼트를 읽기 위해서도 읽기 잠금을 획득해야 하는데 인텐션 잠금을 획득한다.

 

그런데 도큐먼트의 데이터를 변경할 때에는 해당 도큐먼트에 대해 쓰기 잠금을 획득해야 하지만,

읽기만 하는경우에는 WiredTiger 스토리지 엔진에서 별도의 잠금을 이용하지 않는다.

이를 MVCC 라 한다.

 

잠금 관리 주체를 보면 오브젝트 잠금은 MongoDB 서버가 담당하고, 도큐먼트 잠금만 WiredTiger 스토리지 엔진이 담당한다.

createIndex 는 컬렉션의 인덱스를 생성하는 명령으로 컬렉션의 메타 정보를 변경하므로 컬렉션에 대해 배타적 잠금을 걸게된다. 그런데 컬렉션의 인덱스 생성은 그 컬렉션을 포함하고 있는 데이터베이스의 변경과 충돌이 발생할 수 있다.

컬렉션의 인덱스 생성 작업은 그 컬렉션을 포함하는 데이터베이스에 대해 IX 잠금을 먼저 획득해야 한다.

또한 글로벌 IX 잠금도 기본적으로 획득해야 한다.

 

insert 나 update , remove 명령은 컬렉션의 개별 도큐먼트를 변경하므로 명령이 실행되는 동안 다른 커넥션에서 변경하지 못하도록 막으려면, 컬렉션과 데이터베이스, 글로벌에 대해 IX 잠금을 획득해야 한다.

그리고 실제 insert 나 update 명령이 변경하고자 하는 도큐먼트에는 X 잠금을 걸어야 한다.

데이터베이스나 다른컬렉션에 대해서 X 잠금을 걸지 않고 IX 잠금을 거는 이유는 다른 도큐먼트를 변경하고자 하는 다른 커넥션들도 처리를 수행해야 할 수 있기 때문이다.

IX 잠금은 서로 호환되므로 동시에 데이터 변경을 처리할 수 있음을 보여준다.

 

find 명령은 데이터 변경이 아니므로 IS 잠금을 획득하게 된다.

그러나 WiredTiger 스토리지 엔진은 find 쿼리가 조회하는 도큐먼트들에 대해서 아무런 잠금을 걸지 않는다.

이는 MongoDB 의 MVCC 덕분에 가능하다.

 

MongoDB 의 WiredTiger 스토리지 엔진은 도큐먼트를 변경할 때 기존 버전은 그대로 두고 새로운 버전을 추가한다.

즉 변경되는 내역을 모두 관리한다. 그래서 find 쿼리는 현재 트랜잭션에서 읽어야 할 도큐먼트의 버전을 찾아서 읽기만 하면 된다.

 

잠금 Yield

대부분의 RDBMS 는 한번 잠금을 획득하면 처리가 완료될때까지 잠금을 다시 해제하지는 않는다.

하지만 MongoDB 는 트랜잭션을 지원하지 않는 NoSQL 이었기 때문에 트랜잭션 요건이 크지 않았으며, 동시성 처리가 더 우선순위여서 설정된 조건보다 오랜 시간 실행되거나 많은 자원을 소모하는 경우에는 잠깐 쉬었다 다시 처리를 재개하도록 구현했다.

 

이렇게 쿼리를 실행하는 도중 잠깐 쉬었다 쿼리 실행을 재개하는 것을 Yield 라고 한다.

Yield 는 단순히 쿼리의 처리를 잠깐 쉬는것이 아닌, 처리 중인 쿼리를 위해 획득했던 잠금까지 모두 해제하고 지정된 시간동안 쉬게 된다.

 

예를들어 인덱스를 가지지 않는 필드에 대해 검색을 수행하면 전체 컬렉션을 모두 읽어야 한다.

이 쿼리를 처리하는 커넥션은 IS 잠금을 걸게 된다. 그런데 쿼리를 처리하는 도중 일정 규칙에 맞으면 가지고 있는 모든 잠금을 반납하고 일정시간동안 쉬게 된다.

- 쿼리가 지정된 건수의 도큐먼트를 읽은 경우

- 쿼리가 지정된 시간동안 수행된 경우

기본값은 128개 도큐먼트를 읽거나 10밀리초 이상 실행했을 때 Yield 가 수행된다.

변경은 파라미터를 조정하면 된다.

 

다만 이 Sleep 이 쿼리의 성능 저하가 많이 발생하게 되어

3.2 버전부터 Yield 과정이 특정 시간동안 쉬는형태가 아니라 가지고 있던 잠금을 해제하고 가지고 있던 CPU 점유권을 놓고 다시 운영 체제의 쓰레드 스케줄을 기다리는 형태로 처리된다.

 

잠금 진단

db.currentOp 명령으로 현재 실행 중인 명령들의 목록을 조회할 수 있다.

이 때 잠금표시에서 배타적 잠금은 W , 공유 잠금은 R 로 표시된다.

잠금 표기에서 대소문자는 서로 다른 의미를 가진다.

r : Intention Shared Lock

w : Intention Exclusive Lock

R : Shared Lock

W : Exclusive Lock

 

locks 필드에는 글로벌과 데이터베이스 컬렉션에 대해 보여준다.

lockStats 필드에서는 글로벌 데이터베이스와 컬렉션별로 인텐션 잠금을 획득한 횟수를 보여준다.

MongoDB 서버의 로그 파일에도 명령이 어떤 잠ㄱ므을 얼마나 획득했는지 보여준다.

 

 

트랜잭션

WiredTiger 스토리지 엔진이 제공하는 트랜잭션의 ACID 속성은 다음과 같은 특성이 있다.

- 최고 레벨의 격리 수준은 Snapshot (Repeatable-read )

- 트랜잭션의 커밋과 체크포인트 2가지 형태로 영속성 보장

- 커밋되지 않은 변경 데이터는 공유 캐시 크기보다 작아야 함

 

기존의 RDBMS 는 일반적으로 READ UNCOMMIT, READ COMMIT, REPEATABLE-READ , SERIALIZABLE 4가지 격리 수준을 제공하지만 WiredTiger 는 REPEATABLE-READ 격리수준이 최고 수준이다.

또 트랜잭션 로그 뿐만 아니라 체크포인트로 영속성이 보장된다.

즉 트랜잭션 로그가 없어도 마지막 체크포인트 시점의 데이터를 복구할 수 있다.

마지막으로 트랜잭션이 커밋되기 전에는 로그를 디스크로 기록하지 않는다.

그래서 트랜잭션이 변경할 수 있는 데이터 크기는 공유 캐시의 크기로 제한된다.

 

쓰기 충돌 ( Write Conflict )

데이터를 변경하는 도중 쓰기 충돌이 발생할 수 있다.

MongoDB 서버는 변경하고자 하는 도큐먼트가 이미 다른 커넥션에 의해 잠금이 걸려있으면 즉시 업데이트 실행을 취소한다.

이 때 WriteConflict Exception 을 반환한다.

그러면 업데이트 명령을 실행했던 세션은 메시지를 반환받고, 같은 업데이트 문장을 재실행한다.

이는 MongoDB 내부에서 실행되며 응용프로그램에서는 알지 못한다. 즉 응용프로그램에는 투명하게 작동한다.

 

이는 심각한 문제가 될 수 있는데, 하나의 도큐먼트에 많은 쓰레드가 동시에 변경하려고 하면 UPDATE 문장의 실행이 폭증하는 현상이 발생한다.

그래서 쓰기 충돌과 재처리 과정이 반복 실행되면서 CPU 사용량이 높아지지만 실제 사용자의 요청을 처리하는 성능은 떨어질 가능성이 높다.

WriteConflict Exception 이 얼마나 발생했는지는 serverStatus 명령으로 확인이 가능하다.

 

단일 도큐먼트 트랜잭션

단일 도큐먼트의 트랜잭션만 지원하고 이는 원자 단위의 처리가 보장된다는 것을 의미한다.

만약 데이터를 변경하면 실제 이 작업들은 잘게 쪼개진다.

 

예를들어 insert 를 실행하면 3개의 명령을 하나의 트랜잭션으로 실행한다.

1. 사용자 컬렉션 insert

2. 사용자 인덱스 insert

3. OpLog 컬렉션 insert

 

현재는 여러 도큐먼트간의 분산트랜잭션을 지원한다.

 

문장의 트랜잭션 처리

그럼 하나의 INSERT 문장에 여러 도큐먼트가 저장되는 배치 INSERT 와 한번에 여러 도큐먼트를 변경하는 업데이트 문장의 트랜잭션의 처리는 어떻게 될까?

 

실제 MongoDB 에서는 작은 트랜잭션으로 다시 조개져 실행된다.

따라서 업데이트 중간에 에러가 발생하면 에러가 발생한 시점부터는 작업이 무시되지만, 이전에 변경된 도큐먼트는 되돌려지지 않는다.

 

격리 수준

MMAPv1 스토리지는 기본적으로 Shared View 와 Private View 기능을 활용하기 때문에 READ COMMITED 격리 수준과 비슷하게 작동한다.

WiredTiger 스토리지 엔진은 자체적으로 데이터 변경 이력을 관리하기에 READ UNCOMMITTED 와 READ COMMITTED , SNAPSHOT 격리 수준을 지원한다.

하지만 MongoDB 서버에 내장되면서 SNAPSHOT 격리 수준만 지원하고 있다.

 

READ-COMMITTED

하나의 트랜잭션에서 같은 데이터를 여러 번 조회할 때, 다른 세션의 트랜잭션에서 변경하고 커밋한 데이터가 보이게 되는 격리수준이다.

 

SNAPSHOT ( REPEATABLE-READ )

하나의 트랜잭션에서 쿼리는 항상 같은 결과를 반환해야 한다.

 

MongoDB 서버의 격리 수준

데이터의 읽기와 변경이 서로 다른 격리 수준의 효과를 보여준다.

MongoDB 서버에서는 모든 데이터의 변경을 단일 도큐먼트 수준으로 트랜잭션을 제어한다.

 

예를들어 하나의 업데이트 문장으로 여러 도큐먼트를 변경하면

2건의 도큐넌트를 하나의 업데이트 명령으로 변경한다.

그런데 모든 데이터 변경이 도큐먼트 기반으로 트랜잭션을 생성하므로 다른 트랜잭션 범위 내에서 각 도큐먼트의 업데이트가 실행된다.

update 뿐 아니라 모든 데이터 변경은 하나의 도큐먼트를 변경할 때마다 내부적으로 트랜잭션이 커밋된다.

 

MongoDB 서버에서 사용자가 직접 트랜잭션을 제어할 수 없는 것은 상당히 불편하나 얻는 이익도 있다.

장시간 실행되는 트랜잭션이 존재할 수 없으며, 이로인한 성능저하도 발생하지 않는다.

 

 

그러나 읽기 쿼리는 데이터 변경 쿼리와는 다른 형태로 트랜잭션이 관리된다.

즉 데이터 읽기는 데이터 변경과는 달리 일정 단위로 트랜잭션을 시작하고 완료한다.

 

MMAPv1 스토리지 엔진을 사용하는 경우 트랜잭션 개념이 없지만

WiredTiger 스토리지 엔진을 사용하는 경우 특정 시점의 데이터를 읽게 되는데, 이를 스냅샷(Snapshot) 이라고 한다.

특정 시점의 데이터 상태를 그대로 유지할 수 있는 개념으로 원리는 특정 트랜잭션을 시작하고 그 태랜잭션에서 데이터를 읽는 것을 의미한다.

그리고 2가지 조건을 만족할 때까지 스냅샷을 유지한다.

- 쿼리가 지정된 건수의 도큐먼트를 읽은 경우

- 쿼리가 지정된 시간 동안 수행된 경우

 

일정 시간 또는 일정 개수 이상의 도큐먼트를 읽은 후에는 '잠금 Yield' 를 실행하는데 이 때 잠금뿐 아니라 스냅샷도 해제한다.

사실 잠금 Yield 과정의 스냅샷 해제는 쿼리의 일관성에 심각한 문제가 될 수도 있다.

이런 쿼리는 internalQueryExectieldIterations 이나 internalQueryExecTieldPeriodMS 옵션을 조정하여 Yield 주기를 조금 더 뜸하게 설정하여 빈도를 낮추는 방법도 생각해볼 수 있다.

 

MongoDB 서버의 격리 수준과 정렬

일정 건수 이상을 조회하면 스냅샷이 해제된다.

그런데 만약 실행한 쿼리가 정렬이 필요하면 다른 결과를 보여준다.

 

같은 격리 수준을 사용하지만 처리방식에 따라 쿼리 결과가 달라지는 것이다.

이는 정렬이 수반되는 경우 서버가 컬렉션의 데이터를 모두 가져와 메모리(정렬 버퍼)에 적재하고 정렬을 실행하여 클라이언트로 보내주기 때문이다.

실제 다른 세션에서 데이터를 삭제하거나 변경해도 정렬버퍼에 임시로 복사된 결과에는 적용되지 않기에 일관된 결과를 보여준다.