트랜잭션과 격리 레벨

트랜잭션이란 ?

 

소프트웨어 세계에서의 트랜잭션을 살펴보기 앞서서 실생활에서 흔히 있는 이야기를 예로 들어보려고 한다.

만약 친구가 당신에게 자신의 계좌에 20만원을 보내주려고 한다.

 

 

이 경우 작업의 단위는 어떻게 될까?

자세히 파해치면 더 많은 단위가 있을 수 있겠지만 크게 두 가지로 볼 수 있을 것이다.

 

1. 친구 A의 계좌에서 20만원을 뺀다.

2. 친구 B의 계좌에 20만원을 추가한다.

 

이 상황에서 발생할 수 있는 문제들은 여러가지가 있는데 대표적으로 4가지만 알아보자

 

만약, 송금 도중 A의 계좌에는 돈이 빠졌는데 B의 계좌에 돈이 그대로라면?

만약, A의 계좌에 돈이 부족한 상태인데 송금이 되었다면?

만약, 송금 도중 친구C가 송금을 보내서 서로의 데이터가 엇갈린다면?

만약, 송금을 잘 마쳤음에도 데이터가 날아가 버린다면..?

 

그렇다면 친구가 보내준다고 했던 20만원은 증발해버린 것이고 이는 곧 대형 사고로 이어진다.

이런 현상을 방지하기 위해 사용하는 것이 트랜잭션이다.

 

트랜잭션은 위에서 말한 작업 단위들을 묶음으로 인해 일부만 성공해서 DB에 반영되는 일이 없도록 도와준다.

즉 데이터베이스의 상태를 변화시키기 해서 수행하는 논리적인 작업의 단위이다.

 

그리고 트랜잭션의 성질이 위에서 말한 여러 문제상황들을 방지해준다.

 

트랜잭션의 성질

위에서 말한 4가지 문제들은 트랜잭션의 성질에 정의되어 있다.

그리고 이 성질들을 ACID 라고 부른다.

 

A : Atomicity (원자성)

C : Consistency (일관성)

I : Isolation (독립성)

D : Durability (지속성)

 

앞선 사례들을 하나씩 보면서 각각 어떤 성질과 대비되는 지 살펴보자 !

 

만약, 송금 도중 A의 계좌에는 돈이 빠졌는데 B의 계좌에 돈이 그대로라면?

이 예시는 원자성(Atomicity)을 지키지 못한 것이다.

 

하나의 작업이 성공하고 하나의 작업이 실패했는데 결과가 DB에 반영된 것이다.

원자성은 지킨다는 것은 모든 작업이 모두 성공하거나 아니면 모두 실패해야한다.

 

만약, A의 계좌에 돈이 부족한 상태인데 송금이 되었다면?

이 예시는 일관성(Consistency)을 지키지 못한 것이다.

 

DB에는 잔액은 마이너스가 될 수 없다는 제약이 있음에도 이를 어긴 채 송금을 진행한 것이다.

일관성을 지킨다는 것은 트랜잭션 이전,이후에도 데이터베이스의 제약이나 규칙을 만족한다는 것이다.

 

만약, 송금 도중 친구C가 송금을 보내서 서로의 데이터가 엇갈린다면?

 

이 예시는 독립성(Isolation)을 지키지 못한 것이다.

 

친구C와의 트랜잭션이 동시에 실행됨으로써 영향을 미친것이다.

(친구C가 보낸 돈에 더해지지 않고 기존 금액에 더해짐으로써 잔액이 그대로)

독립성을 지키기 위해서는 트랜잭션들이 동시에 실행될 때에도 혼자 실행되는 것처럼 동작해야한다.

 

만약, 송금을 잘 마쳤음에도 데이터가 날아가 버린다면..?

이 예시는 지속성(Durability)을 지키지 못한것이다.

 

당연한 말이지만 저장된 데이터는 영구적으로 DB에 남아있어야한다.

영구성을 지키기 위해서는 DB에 문제가 발생하더라도 커밋된 트랜잭션이 DB에 남아있어야한다.

여기까지가 트랜잭션의 ACID 성질이다.

 

이렇듯이 트랜잭션은 ACID 성질을 유지해줌으로써 데이터의 정합성을 지켜준다.

 

🧐 정합성이 뭐지?

데이터 정합성은 데이터가 서로 모순 없이 일관되게 일치해야 함을 의미한다 !

믿을 수 있는 데이터를 위해선 정합성이 보장되어야한다.

 

지금까지 트랜잭션의 역할과 ACID 성질에 대해 알아보았다 !

이제 트랜잭션이 뭔지 감이 오는가?

트랜잭션은 알겠는데 ... 격리 수준은 뭐지?

트랜잭션은 데이터의 정합성을 지켜줄 수 있는 좋은 장치이다.

하지만 트랜잭션끼리 접촉하다 보면 여러 문제가 발생할 수 있다.

 

대표적으로 크게 3가지 문제가 있는데

 

1. dirty read

2. non repeatable read

3. phantom read

 

하나하나 알아보자 !

고려해봐야 할 문제점들

위에서 언급한 3가지의 이상 현상들을 하나씩 알아보면서 격리레벨이 왜 필요한 지 생각해보자 !

아래에서 설명하는 상황들은 모두 트랜잭션 A,B가 하나의 데이터 베이스에 접근하고 가정한다.

dirty read

쉽게 말해서 , 커밋되지 않은 변화를 읽는 것이다.

트랜잭션 A와 B가 각각 다른 데이터에 접근해서 데이터베이스를 변화시키는 상황을 생각해보자

트랜잭션 A는 x를 변화시키고 , 트랜잭션 B는 y를 변화시킨다.

어떤 문제가 발생할까?

뭔가 이상하지 않은가?

x에 더한 y의 값 10은 더 이상 유효하지 않은 값이다.

즉, 위에서 말했다시피 커밋되지 않은 변화를 읽어서 문제가 생긴것이다.

non repeatable read

같은 데이터를 조회했을 때 값이 다르게 나오는 것이다.

트랜잭션 A가 x의 값을 처음 읽었을 때는 50이었다.

그 사이에 트랜잭션 B가 x의 값을 10으로 변경했고 , 다시 트랜잭션 A가 x를 읽었을 때는 x의 값은 10이 나온다.

값은 x라는 데이터의 값을 조회했지만 조회할때마다 값이 다르게 나오는 것이다.

이는 곧 isolation 관점에서 바람직하지 못하다.

 

🧐isolation 위에서 배웠는데 .. !

여러 개의 트랜잭션들이 동시에 수행될 때, 각 트랜젝션은 고립(격리)되어 있어 연속으로 실행된 것과 동일한 결과를 나타낸다.

phantom read

없던 데이터가 생기는 것이다.

이 상황도 마찬가지로 똑같은 조건으로 데이터를 검색했는 데 결과가 다르게 나온다.

이 역시 isolation 원칙에 위배된다고 할 수 있다.

지금까지 소개한 3가지가 대표적으로 나타나는 문제점들이다.

 

🧐 아 그럼 해결책은 간단하네요 ! 다 막아버리면 되는 거죠?

 

물론 극도의 안정적인 환경을 위해서라면 그렇게 할 수도 있지만 이는 좋은 방법이 아니다.

코로나 거리두기 단계를 떠올려보자

 

사실 코로나 확진자가 안나오게 하는 방법은 어떻게 보면 매우 간단할 수 있다.

아무것도 하지 못하게하면 코로나 확진자는 안나왔을 것이다.

 

 

근데 현실은 다르다.

거리두기 단계에 따라서 허용되는 것이 있고 금지되는 것들을 정해놓았다.

 

왜일까?

너무나 당연한 얘기이지만, 모든 것을 금지시켜 버리면 사회는 돌아가지 않기 때문이다.

그래서 단계에 따라 준수사항들을 조정함으로써 관리했던 것이다.

 

트랜잭션에도 비슷한 개념이 적용된다.

격리레벨이 올라갈 수록 안정성은 높아지지만 데이터 처리량이 저하된다.

 

그리고 이것에 대해 정해놓은 표준 SQL 기준을 알아보려고 한다.

SQL 표준 격리 레벨

SQL 표준에서는 위에서 말한 문제들을 어디까지 허용할 지 구분하는 격리레벨을 지정하였다.

 

Read uncommitted

Read uncommitted 레벨은 커밋되지 않은 변화도 다른 트랜잭션이 읽을 수 있다.

아래 예시를 보자, 트랜잭션1이 새로운 데이터를 넣고 커밋을 하지 않은 상태이지만 트랜잭션2는 이것을 읽을 수 있다.

사실상 격리가 아예 없는 거나 마찬가지이므로 최소한 Read committed 이상 레벨의 사용을 권장한다.

 

Read uncommitted 레벨에서 발생할 수 있는 문제점

- 이 레벨에서는 많은 문제들이 발생할 수 있지만 대표적으로 Dirty Read 에 대해 다뤄보고자 한다.

 

위에서 dirty read는 커밋되지 않은 변화를 읽음으로써 나타나는 문제라고 하였는데 Read uncommitted 에서 그 문제가 그대로 발생한다.

 

 

트랜잭션 B는 데이터베이스로 부터 Y를 읽기로 하였다.

하지만 B가 데이터를 읽는 도중 트랜잭션A가 Y의 데이터를 변경하였고 B는 격리레벨 특성상 커밋되지 않은 데이터를 읽게 되었다.

 

 

하지만 A가 변경한 데이터가 커밋되지 않고 롤백된다면 어떻게 될까?

트랜잭션B가 읽은 Y의 데이터는 더 이상 유효한 값이 아니게 된다.

이 현상을 dirty read 라고 부른다.

즉, 트랜잭션에서 처리한 작업이 완료되지 않았음에도 불구하고 다른 트랜잭션에서 볼 수 있게 되는 현상이다.

 

Read committed

Read committed 단계에서는 커밋된 데이터만 읽기 때문에 dirty read 와 같은 현상은 발생하지 않는다.

어떻게 이것을 구현할 수 있었을까?

 

바로 undo 영역을 따로 만들어줌으로써 백업된 데이터만을 가져오기 때문이다.

밑에 그림을 보면 트랜잭션1에서 데이터를 변경하기 전에 테이블을 백업한다.

 

그리고 테이블에 변경된 데이터가 반영된다.

트랜잭션2에서는 undo 영역에서 데이터를 가져오기 때문에 이전에 커밋된 데이터만 볼 수 있는 것이다 !

 

 

Read committed 발생할 수 있는 문제점

- 이 레벨에서는 non repeatable read 문제가 발생한다.

 

무엇이 문제일까? 다시 예시를 보자

 

트랜잭션B가 Y를 두번 조회한다고 가정하자

첫번째로 조회했을 때는 Y가 50이 나왔지만 두번째로 조회했을 땐 70이 나왔다.

얼핏 생각하면 크게 문제될게 없어보이는 데 , 이는 ACID 속성 중 독립성에 어긋난다.

 

🧐 독립성 벌써 몇번째야 ..

동시에 여러 개의 트랜잭션들이 수행될 때, 각 트랜젝션은 고립(격리)되어 있어 연속으로 실행된 것과 동일한 결과를 나타낸다.

 

Repeatable read

어떻게 하면 트랜잭션 내에서 특정 행을 조회할 때 마다 항상 같은 데이터를 나오도록 할 수 있을까?

Repeatable read 에서는 이를 트랜잭션 ID 를 통해 해결한다.

 

이렇게 부여된 트랜잭션 ID보다 작은 트랜잭션 번호에서 변경한 것만 읽게 된다.

 

그리고 undo 로그가 많아지면 데이터베이스의 성능이 떨어질 수 있기때문에 DB엔진에서는 불필요한 undo 로그를 주기적으로 삭제한다.

 

Repeable read에서 발생할 수 있는 문제점

- 이 레벨에서는 phantom read 라는 문제가 발생할 수 있다.

 

예시를 살펴보자

 

맨처음 데이터행을 조회했을 때 1개가 나왔지만 나중에 한번 더 조회했을 때 하나가 추가된 2가 나왔다.

 

이는 undo 테이블에 쓰기 잠금을 할 수 없기 때문에 발생하는데 결국 현재 데이터의 값을 가져오게 된다.

(innoDB에서는 팬텀 리드가 발생하지 않는다고 한다!)

 

Serializable

특정 트랜잭션이 사용중이면 다른 트랜잭션은 일체 접근할 수 없다.

데이터의 안정성(정합성)은 높으나 처리량은 떨어진다.

 

발생할 수 있는 문제점

- 없음

 

다시 표로 정리해보자

이처럼 격리 단계에 따라 허용하는 오류들이 정해져있다.

각각의 용도에 맞게 적절하게 격리 레벨을 지정하는 것이 중요하다.

 

결론

데이터의 정합성을 보장해주기 위해서 트랜잭션을 사용해야한다.

 

하지만 트랜잭션끼리 동시에 실행되다 보면 여러 문제들이 발생하는 데

SQL 표준에서 이를 어디까지 허용할 것인지에 대한 격리 단계를 지정해놓았다.

 

각자 상황에 따라 적절한 격리 단계를 선택해야한다.

 

참고 자료

[MySQL] - 트랜잭션의 격리 수준(Isolation level)

[MySQL] - 트랜잭션의 격리 수준(Isolation level)

트랜잭션 격리 수준

트랜잭션 격리 수준

[데이터베이스] 트랜잭션의 ACID 성질 - 하나몬

[데이터베이스] 트랜잭션의 ACID 성질 - 하나몬

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

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

https://www.youtube.com/watch?v=bLLarZTrebU&t=397s

https://www.youtube.com/watch?v=sLJ8ypeHGlM&t=144s