트랜잭션 격리 수준(isolation level)이란?

트랜잭션의 격리 수준(isolation level)에 대해서 정확하게 이해하는 것은 애플리케이션 로직을 정확하게 제어하는 것에 있어서 중요합니다. 하지만 격리 수준이 구체적으로 어떻게 동작하는지 정확하게 모르고 있었던 사실을 발견해서 재학습을 위해 내용을 정리합니다.

이 글은 MySQL 기준으로 작성합니다.

트랜잭션 격리 수준

격리 수준은 크게 다음과 같이 4가지로 다음과 같이 나뉘게 됩니다.

1. READ UNCOMMITTED
2. READ COMMITTED
3. REPEATABLE READ
4. SERIALIZABLE 

1번에서 4번으로 갈수록 트랜잭션 간의 데이터 격리 수준이 높아지며, 동시 처리 성능이 떨어지는 것이 일반적입니다.
그리고 보통 SERIALIZABLE 정도가 아니면 크게 성능의 개선이나 저하는 발생하지 않습니다.

일반적인 온라인 서비스 용도의 데이터베이스에서는 READ COMMITTED와 REPEATABLE READ 중 하나를 사용합니다.

실제로 오라클에서는 READ COMMITTED 수준을 많이 사용하며, MySQL에서는 REPETABLE READ를 주로 사용합니다.
SQL-92 또는 SQL-99 표준에 따르면 REPETABLE READ를 사용하면 데이터 부정합 문제가 있을 수 있지만, MySQL InnoDB의 경우는 언두 로그 등 독특한 특성으로 인해 부정합 문제가 발생하지 않고 안전하게 사용 가능합니다.

 

트랜잭션 격리 수준과 데이터 부정합 문제

트랜잭션 격리 수준을 이야기하면 데이터 부정합 문제도 같이 이해하고 있어야 합니다.
이를 잘 이해하면 우리는 사용자에게 의도한대로 데이터를 보여주도록 애플리케이션 로직을 안전하게 제어할 수 있습니다.

대표적인 부정합 문제는 다음과 같이 3가지가 존재합니다.

1. DIRTY READ
2. NON-REPEATABLE READ
   
3. PHANTOM READ
   

 

트랜잭션 격리 수준에 대해 자세히 알아보기 전에 데이터 정합성 문제를 먼저 자세하게 알아봅시다.

 

DIRTY READ

DIRTY READ는 어떤 트랜잭션이 처리한 작업이 완료되지 않았는데도 다른 트랜잭션에서 볼 수 있는 현상을 말합니다.
말 그대로 정상적이지 않고 오염된 데이터를 읽을 수 있다는 의미입니다.

• 트랜잭션이 실패할 수도 있으므로 송금과 같은 데이터 정합성이 중요한 도메인에서는 DIRTY READ는 심각한 문제입니다.
• READ UNCOMMITTED 격리 수준에서는 DIRTY READ가 허용되며 RDBMS 표준에서는 READ UNCOMMITTED를 트랜잭션의 격리 수준으로 인정하지 않을 정도로 정합성에 문제가 많다고 판단하고 있습니다.

 

NON-REPEATABLE READ

NON-REPEATABLE READ는 말 그대로 한 트랜잭션에서 같은 SELECT 쿼리로 데이터를 반복적으로 읽었을 때 데이터가 달라지는 부정합 문제를 말합니다.
즉, 한 트랜잭션 내에서는 똑같은 SELECT 쿼리를 실행했을 때 항상 같은 결과를 가져와야한다는 REPETABLE READ 정합성에 어긋나는 현상입니다.

 

 

PHANTOM READ

PHANTOM READ는 다른 트랜잭션이 수행한 변경 작업에 의해 레코드가 보였다 안 보였다하는 현상을 지칭합니다.
즉, 한 트랜잭션에서 같은 쿼리로 데이터를 다시 조회했을 때 기존과 다른 결과가 나올 수 있는 데이터 부정합입니다.
NON-REPEATABLE READ와 같은 거 아닌가? 하는 생각이 들지만 구체적으로 조금 다릅니다.
PHANTOM READ 부정합은 "SELECT ... FOR UPDATE" 쿼리 실행 시에 대표적으로 발생합니다.

MySQL에서는 REPEATABLE READ 격리 수준을 보장하기 위해 언두 로그에서 현재 트랜잭션 번호보다 이전에 실행된 언두 로그를 기반으로 데이터를 조회하는 구조를 가지고 있습니다.
그리고 MySQL의 "SELECT ... FOR UPDATE" 쿼리는 SELECT 하는 레코드에 쓰기 잠금을 걸어야 하는데,
언두 로그는 구조적으로 append only만 가능하게 구성되어 있어서 언두 로그에는 잠금을 걸 수 없다. 그래서 쿼리 시에 언두 로그가 아닌 실제 레코드에서 값을 가져오게 됩니다.

따라서 "SELECT ... FOR UPDATE" 쿼리가 "SELECT * FROM users WHERE age > 20"과 같이 범주형으로 데이터를 가져오는 경우라면 데이터가 보였다 안 보였다하는 PHANTOM READ 현상이 발생할 수 있는 구조입니다.

 

정합성 문제를 먼저 살펴봤으니 이제 각 격리 수준에 대해서 알아봅시다.

 

READ UNCOMMITTED

READ UNCOMMITTED는 이름에서 알 수 있듯이 커밋되지 않은 내용을 읽을 수 있습니다.
즉, 트랜잭션에서의 변경 내용을 COMMIT이나 ROLLBACK 여부에 상관없이 다른 트랜잭션에서 볼 수 있는 격리 수준입니다.

위에서 부정합 문제와 함께 알아봤듯이 READ UNCOMMITTED 격리 수준에서는 DIRTY READ가 허용되며 RDBMS 표준에서는 READ UNCOMMITTED를 트랜잭션의 격리 수준으로 인정하지 않을 정도로 정합성에 문제가 많다고 판단하고 있습니다.

 

READ COMMITTED

READ COMMITTED는 이름 그대로 다른 트랜잭션에서 커밋이 완료된 데이터만 읽을 수 있는 격리 수준입니다.
오라클 DBMS에서 기본으로 사용되는 격리 수준이며, 온라인 서비스에서 가장 많이 선택하고 있습니다.
READ UNCOMMITTED와 달리 DIRTY READ 부정합이 발생하지 않습니다.

MySQL에서는 현재 트랜잭션이 데이터를 변경하면 변경 전 데이터를 언두 로그에 백업 데이터로 쌓습니다. 그리고 만약 다른 트랜잭션에서 해당 데이터를 조회하고 싶다면 해당 언두 로그에서 데이터를 조회하여 READ COMMITTED를 보장합니다.

하지만 READ COMMITTED에서는 NON-REPEATABLE READ 부정합 문제가 발생할 수 있습니다.
A 트랜잭션에서 특정 데이터를 조회했을 때 데이터가 없었지만 B 트랜잭션에서 새로운 데이터를 추가 후 커밋했다면, A 트랜잭션에서 다시 데이터를 조회 시 데이터가 존재할 수도 있습니다. 이는 트랜잭션 격리 수준이 완전한 잠금의 기능을 하는 건 아니기 때문에 가능한 현상으로 보입니다. 

NON-REPEATABLE READ 부정합은 REPEATABLE READ 격리 수준을 사용하면 해결할 수 있습니다. 

 

REPEATABLE READ

REPEATABLE READ는 NON-REPEATABLE READ 부정합이 발생하지 않는 트랜잭션 격리 수준입니다.
MySQL의 InnoDB에서 기본으로 사용되는 격리 수준이고 바이너리 로그를 가진 MySQL 서버에서는 최소 REPEATABLE READ 격리 수준 이상을 사용해야 합니다.

InnoDB에서는 트랜잭션이 rollback될 가능성에 대비하기 위해 변경되기 전 데이터를 언두 로그에 백업해두고 실제 레코드 값을 변경합니다. 이러한 방식을 MVCC(Multi version Concurrency Control)이라고 하며 언두 로그에 백업해둔 데이터를 활용해 같은 트랜잭션 내에서는 동일한 결과를 볼 수 있도록 보장합니다.

InnoDB의 트랜잭션은 순차적으로 증가하는 고유한 트랜잭션 번호를 가지며 언두 로그에도 트랜잭션 번호가 포함되고 이 트랜잭션 번호를 기준으로 데이터의 시점을 보장합니다.

하지만 REPEATABLE READ 격리 수준에서도 위에서 알아봤던 PHANTOM READ 부정합이 발생할 수 있으니 주의해야 합니다.
PHANTOM READ 부정합을 방지하기 위해서는 락(lock) 기능을 사용해야 하며 InnoDB에서는 갭 락과 넥스트 키 락 덕분에 REPEATABLE READ 격리 수준에서도 PHANTOM READ 부정합을 방지할 수 있습니다.

트랜잭션 유무에 따른 SELECT의 차이

"트랜잭션 내에서" 실행되는 SELECT와 "트랜잭션 없이" 실행되는 SELECT는 READ COMMITTED 격리 수준에서는 차이가 별로 없습니다. 하지만 REPEATABLE READ에서는 기본적인 SELECT 쿼리 문장도 트랜잭션 범위 내에서만 작동합니다.

즉, 트랜잭션을 한 번 시작했으면 그 트랜잭션에서는 SELECT 시 동일한 결과만 보게 되므로 돈이 오가는 요구사항 등 전체적으로 봤을 때 데이터의 정합성이 중요한 경우는 위험할 수 있으니 이 차이를 잘 이해하고 있어야 합니다.

이런 문제로 데이터의 정합성이 깨지고 애플리케이션에서 버그가 발생하면 찾아내기 쉽지 않으니 주의해야 합니다.

 

SERIALIZABLE

읽기 작업도 공유 잠금을 획득해야만 하는 가장 단순하면서 가장 업격한 격리 수준입니다.
SERIALIZABLE 격리 수준은 잠금을 이용해 데이터의 일관성을 보장합니다. 하지만 이에 따라 동시 처리 성능은 다른 트랜잭션 격리 수준보다 떨어지게 됩니다.

SERIALIZABLE에서는 PHANTOM READ 부정합이 발생하지 않습니다. 
그러나 위 REPEATABLE READ에서 알아봤듯이 InnoDB에서는 갭 락과 넥스트 키 락 덕분에 REPEATABLE READ 격리 수준에서도 PHANTOM READ 부정합을 방지할 수 있으므로 SERIALIZABLE을 굳이 사용할 필요성은 없습니다.

 

격리 수준과 데이터 부정합 정리

격리 수준과 일어날 수 있는 데이터 부정합을 표로 정리하면 다음과 같습니다.