treecode

트랜잭션의 격리 수준이란 여러 트랜잭션이 동시에 처리될 때 특정 트랜잭션이 다른 트랜잭션에서 변경하거나 조회하는 데이터를 볼 수 있게 허용할지 말지를 결정하는 것이다.

격리 수준

READ UNCOMMITTED

READ COMMITTED

REPEATABLE READ
SERIALIZABLE

(밑으로 갈수록 격리 수준이 높아지고, 처리 성능이 떨어지지만 SERIALIZABLE이 아니라면 크게 성능 개선, 저하는 발생하지 않는다)

READ UNCOMMITTED는 트랜잭션이 커밋되지 않은 상태에서도 조회가 가능하기 때문에 이상한 값이 읽힐 수 있고 이를 더티 리드라고 하는데 일반적인 데이터베이스에서는 거의 사용하지 않는다.

SERIALIZABLE도 동시성이 중요한 데이터베이스에서 거의 사용되지 않는다.

READ COMMITTED는 오라클에서 기본으로 사용되는 격리 수준으로 가장 많이 선택되는 단계인데 어떤 트랜잭션에서 데이터를 변경했더라도 COMMIT이 완료된 데이터만 다른 트랜잭션에서 조회할 수 있다. 만약 트랜잭션이 커밋되기 전에 다른 트랜잭션에서 조회를 한다면 언두 로그에 백업(복사)해둔 변경 전 데이터가 반환이 된다. 

READ COMMITTED는 NON-REPEATABLE READ라는 부정합의 문제가 남아있는데 처음 조회를 했을 때는 바뀌지 않은 데이터가 중간에 다른 트랜잭션에서 UPDATE를 하고 커밋을 한 뒤에 다시 조회를 했을 때 바뀐 데이터가 반환되는 것이다.

REPEATABLE READ는 MySQL의 InnoDB 스토리지 엔진에서 기본으로 사용되는 격리 수준으로 바이너리 로그를 가진 MySQL 서버에서는 최소 REPEATABLE READ 이상의 격리 수준을 사용해야 한다.

InnoDB 스토리지 엔진은 트랜잭션이 롤백될 가능성에 대비해 변경되기 전 레코드를 언두 공간에 백업해두고 실제 레코드 값을 변경하는데 이러한 변경 방식을 MVCC(Multi Version Concurrency Control)라고 한다.

[MVCC와 언두 로그]

REPEATABLE READ는 언두 영역에 백업된 이전 데이터를 이용해 동일 트랜잭션 내에서는 동일한 결과를 보여줄 수 있게 보장한다.

READ COMMITTED도 MVCC를 이용해 커밋되기 전의 데이터를 보여주는데 둘의 차이는 언두 영역에 백업된 레코드의 여러 개의 멀티 버전 가운데 몇번째 이전 버전까지 찾아 들어가느냐에 있다.

모든 InnoDB 트랜잭션은 순차적으로 증가하는 고유한 트랜잭션 번호를 가지며, 언두 영역에 백업된 모든 레코드에는 트랜잭션의 번호가 기록되어 있다. (언두 영역의 백업된 데이터는 InnoDB 스토리지 엔진이 불필요해지면 주기적으로 삭제)

REPEATABLE READ은 MVCC를 보장하기 위해 실행 중인 트랜잭션 가운데 가장 오래된 트랜잭션 번호보다 트랜잭션 번호가 앞선 언두 영역의 데이터는 삭제할 수 없다. 정확히는 특정 트랜잭션 번호의 구간 내에서 백업된 언두 데이터가 보존돼야 한다.

userB(tx_id: 10)이 트랜잭션을 시작하고 다음 트랜잭션인 userA(tx_id: 12)가 시작해서 값을 바꿔도 userB는 언두 로그에 백업해둔 자기보다 낮은 tx_id의 데이터가 보인다. 하지만 REPEATABLE READ도 SELECT ... FOR UPDATE로 조회를 할 경우 현재 레코드의 값을 가져오는 부정합의 문제가 있긴 하다. 이렇게 다른 트랜잭션에서 변경을 해서 레코드가 보였다 안 보였다 하는 현상을 PHANTOM READ라고 한다.

트랜젝션

데이터를 저장할 때 단순 파일이 아닌 데이터베이스에 저장하는 가장 큰 이유는 데이터베이스가 트랜젝션이라는 개념을 지원하기 때문이다.

트랜젝션은 데이터베이스에서 하나의 거래를 안전하게 처리하도록 보장해주는 것을 뜻하는데 트랜젝션 기능을 사용하면 중간에 문제가 생길 경우 시작 이전으로 되돌릴 수 있다. 작업이 완료되고 데이터베이스에 정상 반영되는 것을 커밋(Commit)이라 하고, 문제가 생겨서 작업 이전으로 되돌리는 것을 롤백(Rollback)이라 한다.

트랜젝션 ACID 

트랜젝션은 원자성(Atomicity), 일관성(Consistency), 격리성(Isolation), 지속성(Durability)를 보장해야 한다.

한 세션에서 트랜젝션을 시작하고 데이터를 수정하는 동안 다른 세션이 같은 데이터를 수정하게 되면 트랜젝션의 원자성이 깨지는데 이런 문제를 방지하려면 트랜젝션이 커밋이나 롤백을 하기 전까지 다른 세션에서 해당 데이터를 수정할 수 없도록 막아야 한다.

데이터베이스는 이런 문제를 해결하기 위해 락(Lock)이라는 개념을 제공하는데 세션은 트랜젝션을 시작하고 값을 변경하려는 데이터의 row에 대해 먼저 lock을 얻는데 락을 갖고 있는 동안 다른 세션은 해당 row의 데이터를 변경할 수 없다. 락을 획득한 세션이 트랜젝션을 종료하면 락이 반납되고 다른 세션은 대기하다가 락을 획득한 뒤에 데이터를 변경할 수 있으며 락 대기 시간이 넘어가면 타임아웃 오류가 발생한다.

데이터베이스마다 다르지만, 락이 걸린 동안에는 다른 세션에서 데이터를 변경하지 못하고 지연이 걸리기 때문에 일반적인 데이터베이스는 조회를 할 때는 락을 사용하지 않고 바로 데이터를 조회할 수 있도록 한다.  조회를 할 때도 락이 필요한 경우  'select for update' 구문을 사용하면 되는데 조회를 통해 중요한 계산을 수행하는 경우 조회 시점에 락을 획득하면 된다.

트랜젝션 적용

트랜젝션은 비즈니스 로직이 있는 서비스 계층에서 시작해야 한다. 비즈니스 로직이 잘못되면 문제가 되는 부분을 함께 롤백해야 하기 때문이다. 서비스 로직에서 트랜젝션을 시작하려면 먼저 커넥션을 획득하고 유지해야 하는데 애플리케이션에서 같은 커넥션을 유지하려면 커넥션을 파라미터로 전달해서 같은 커넥션이 사용되도록 유지해야 한다.

하지만 이러한 방법은 서비스 계층이 매우 복잡해지고 커넥션을 유지하기도 어려워지는데 스프링을 사용해서 트랜젝션을 편리하게 사용할 수 있다.

[참고]  인프런 김영한님 강의를 공부한 내용입니다.