[자습시간! DataBase] 트랜잭션에 대해 알아보자

트랜잭션이란?

트랜잭션은 하나의 논리적 작업 단위를 구성하는 일련의 연산들의 집합이다.

 

다시 말해 '여러 읽기/쓰기를 논리적으로 하나로 묶은 것'을 말한다고 표현할 수 있다.

(위 표현은 https://www.youtube.com/watch?v=urpF7jwVNWs 링크의 영상을 참고하였음)

 

트랜잭션의 가장 큰 특징은 진행 과정에 있다.

 

트랜잭션 진행 과정

 

여기서 커밋은 데이터베이스에 결과를 반영하는 것이고, 롤백은 결과를 반영하지 않는 것을 말한다.

 

만약 트랜잭션이 없다면 문제가 발생하더라도 데이터베이스가 데이터 일관성을 보장할 수 없기 때문에 소프트웨어가 데이터 일관성을 보장해야 하는 문제가 생긴다.

(이와 관련하여 자세한 사항은 이전에 작성한 https://study0304.tistory.com/3 글에서 참고하길 바란다.)

 

지금부터 자세히 알아보자

 

영어 단어 Transaction은 거래를 뜻한다.

 

예를 들어 돈을 줬는데 물건을 받지 못한다면,

 

그 거래는 이루어지지 못하고 원상태로 복구되어야 한다.

 

쪼갤 수 없는 하나의 처리 행위를 원자적 행위라고 한다.

 

여기서 쪼갤 수 없다는 말의 의미는 실제로 쪼갤 수 없다기보다는

 

만일 쪼개질 경우 시스템에 심각한 오류를 초래할 수 있다는 것이다.

 

이러한 개념의 기능을 ATM 또는 데이터베이스 등의 시스템에서 제공하는 것이 바로 트랜잭션이다.

 

우리는 은행에서 송금하는 상황을 생각해보자.

 

친구와 함께 식당에 가서 맛있는 밥을 먹고 계산을 하려는데 잔액이 부족한 것이다!

 

그래서 어쩔 수 없이 친구에게 대신 돈을 내달라고 하고, 월급이 들어오는 일주일 후에 돈을 다시 돌려주겠다고 약속한 것이다.

 

일주일이 흘러 월급이 들어왔고, 친구에게 돈을 갚기 위해 자동이체 서비스를 이용하기로 했다.

 

이 상황에서 일어날 수 있는 일들에 대해 살펴보도록 하자.

 

보통 서버에 무언가를 요청하는 요청자를 클라이언트라고 지칭하므로 지금부터 돈을 갚기로 한 친구를 클라이언트라고 부르도록 하겠다.

('사람'이 아니라 '요청자'라고 하는 이유는 사람이 아니어도 요청자가 될 수 있기 때문이다.)

 

클라이언트가 송금을 하기 위해서는 데이터베이스에 요청할 필요가 있다.

 

이때, 클라이언트는 직접 요청을 하지 않고 서버를 거친다.

 

 

이 상황을 좀 더 자세히 살펴보도록 하자.

 

 

 

 

• 요청
  • 서버에 송금 요청
• 트랜잭션
  • 트랜잭션 시작
  • 정보 요청
    • 클라이언트의 잔액이 얼마인지 조회하는 것
    • 만약 송금하고자 하는 금액보다 더 낮다면 송금할 수 없도록 하기 위함
    • 월급날이었으므로 클라이언트의 잔액은 당연히 송금해야 할 금액보다 높은 수준이었음
  • 정보 수정
    • 잔액 정보를 수정하는 것
      • 밥값이 8,000원이었다면 기존 잔액에서 8,000원을 뺀 금액이 잔액이 됨
    • 상대방의 잔액도 수정이 되어야 함
      • 위와 동일하게 밥값이 8,000원이었다면 기존 잔액에서 8,000원을 더한 금액이 잔액이 됨
                                 
  • 정보 삽입
    • 이후, 클라이언트의 DB에 송금한 정보가 삽입됨
    • 더해 상대방의 계좌에도 입금된 정보가 삽입됨
  • 트랜잭션 종료
• 요청한 작업 완료
  • 송금 완료

 

 

위와 같은 작업이 순차적으로 이뤄지는 것이다.

 

그런데 클라이언트의 잔액은 수정이 되었는데, 도중에 문제가 생겨 상대방의 잔액은 바뀌지 않았다면?

 

 

분명히 송금을 했는대도 불구하고, 상대방은 돈을 받지 못했다고 하니 중간이 돈이 공중에서 사라지게 되는 것이다!

 

 

이러한 상황을 방지하기 위해 트랜잭션이라는 개념이 등장하게 된 것이다.

 

여기서 트랜잭션의 정의를 다시 한 번 떠올려보자.

 

여러 읽기/쓰기를 논리적으로 하나로 묶은 것

이것이 바로 트랜잭션의 정의였다.

 

여기서 우리는 논리적으로 하나로 묶은 것이 무엇인지 이해할 수 있을 것이다.

 

논리적으로 묶은 것이 아니라면, 정보 요청과 정보 수정, 정보 삽입이 각자의 작업일 수 있을 것이다.

 

하지만 논리적으로 하나로 묶게 된다면 송금할 때 일어날 수 있는 치명적인 상황을 예방하기 위해 정보 요청부터 정보 삽입까지의 과정을 하나로 묶게 된다.

 

따라서 트랜잭션 범위 내에서 문제가 발생하게 되면 트랜잭션 내에서 진행하던 모든 작업들을 초기화하게 되는 것이다.

 

이 과정이 바로 위에서 설명했던 롤백이다.

 

지금까지 다뤘던 개념을 'All OR Nothing', 즉 원자성이라고 부른다.

 

 

 

 

트랜잭션에는 앞서 소개한 원자성 이외에도 3가지 특징이 더 있는데, 이것을 줄여 ACID라고 부른다.

 

ACID는 트랜잭션이 안전하게 수행된다는 것을 보장하기 위한 성질이다.

 

• Atomicitiy(원자성) : All or Nothing, 트랜잭션은 모두 반영되거나 모두 반영되지 않아야 함
• Consistency(일관성) : 트랜잭션 작업처리결과는 항상 일관성 있어야 함
• Isolation(독립성) : 둘 이상의 트랜잭션이 동시 실행되고 있을 때, 어떤 트랜잭션도 다른 트랜잭션 연산에 끼어들 수 없음
• Durability(지속성) : 트랜잭션이 성공적으로 완료되었으면 결과는 영구히 반영되어야 함

 

---

트랜잭션의 범위와 트랜잭션 전파, 글로벌 트랜잭션

 

그렇다면 트랜잭션은 어디서부터 어디까지인지 어떻게 범위를 정할 수 있는 것일까?

 

트랜잭션의 범위는 커넥션 기준이다. 즉, 한 커넥션이 시작하는 시점부터 끝나는 시점까지를 한 트랜잭션이라고 보는 것이다.

 

이때 주의해야 할 점은 '메소드에 따라 달라지는 커넥션'이다. 만약 메소드가 달라짐에 따라 커넥션이 달라지게 된다면 한 트랜잭션으로 처리할 수 없기 때문이다.

 

이것이 문제가 되는 이유는 메소드에 따라 달라지는 커넥션으로 트랜잭션이 나뉘게 되고, 나뉜 트랜잭션을 한 상황에서 함께 사용할때 롤백이 필요한 상황이 온다면 다른 매소드의 롤백까지 해야하는 상황임에도 한 트랜잭션이 아니기 때문에 한 번에 롤백을 할 수 없다는 것이다.

 

따라서 트랜잭션 전파라는 것이 생겨났다.

 

트랜잭션 전파는 여러 메소드 호출이 한 트랜잭션에 묶이도록 하기 위해 필요한 것이다.

 

트랜잭션 전파는 보통 소프트웨어 프레임워크에서 제공하는데, 그 중 스프링 프레임워크가 대표적이라고 할 수 있다.

 

스프링 프레임워크에서 제공하는 트랜잭션 전파는 매소드 간에 커넥션 객체를 전달하지 않아도 한 트랜잭션으로 묶어서 실행할 수 있는 아주 좋은 친구이다.

 

트랜잭션 전파까지 잘 고려하였더라도 외부 연동이 추가적으로 들어가게 되면 다시 문제가 생길 우려가 있다.

 

외부 연동에서 처리가 되었다면 롤백을 하여도 외부 연동에서 처리된 것은 롤백 되지 않는다는 것이 대표적 우려이다.

 

따라서 글로벌 트랜잭션을 사용하기도 한다.

 

2PC(Two-Phase Commit)라고도 하며, 두 개 이상의 자원을 한 트랜잭션으로 처리하기 때문에 위와 같은 상황에 대비할 수 있게 된다.

 

하지만 성능이 떨어지기 때문에 거의 사용하지 않는다.

 

따라서 다중 자원에 대한 데이터 처리가 필요하다면 비동기 메시징을 하는 등 다른 수단을 이용하는 것이 일반적이다.

 

 

---

트랜잭션의 성질에 따른 성능 문제

 

앞서 우리는 트랜잭션의 성능에 대해 알아보았다.

 

트랜잭션의 성능에 따라 다양한 문제가 발생할 수 있고, 이를 해결하기 위해 트랜잭션 격리 수준을 크게 4단계로 나누어 관리하게 한다.

 

트랜잭션 격리 수준은 동시에 DB에 접근할 때 그 접근을 어떻게 제어할지에 대한 설정이다.

 

아래는 격리 레벨에 따라 순차적으로 특징을 나열한 것이다.

 

• READ-UNCOMMITTED
  • 격리 레벨이 가장 낮음
  • 커밋 전의 트랜잭션의 데이터 변경 내용을 다른 트랜잭션이 읽는 것을 허용함
  • Dirty Read, Non-Reapeatable Read, Phantom Read(Non-Reapeatable Read의 한 종류) 발생 가능
• READ_COMMITTED
  • 커밋이 완료된 트랜잭션의 변경사항만 다른 트랜잭션에서 조회 가능
  • Non-Reapeatable Read, Phantom Read(Non-Reapeatable Read의 한 종류) 발생 가능
• REPEATABLE-READ
  • 트랜잭션 범위 내에서 조회한 내용이 항상 동일함을 보장
  • Phantom Read(Non-Reapeatable Read의 한 종류) 발생 가능
• SERIALIZABLE
  • 한 트랜잭션에서 사용하는 데이터를 다른 트랜잭션에서 접근 불가
  • 트랜잭션의 ACID 성질이 엄격하게 지켜지나, 성능이 가장 떨어짐

READ-UNCOMMITTED 쪽으로 올라갈수록 동시성을 보장하고, 아래쪽으로 내려올 수록 데이터 적합성을 보장한다는 특징이 있다.

 

아래는 위에서 언급했던 문제를 설명한 것이다.

 

• Dirty Read
  • 데이터 캐시에는 변경이 되었지만, 아직 커밋되지 않은 데이터를 읽는 행위
• Non-repeatable Read
  • 트랜잭션 내에서 한 번 읽은 데이터가 트랜잭션이 끝나지 전에 변경되었다면, 다시 읽었을 때 새로운 값이 읽히는 것
• Phantom Read
  • 공유 잠금 상태의 데이터 변경 불가가 보장된 것을 가정함
  • 위 데이터 변경만 불가능할 뿐, 새로운 데이터 추가/삭제 가능
  • 트랜잭션 중에 없던 행이 추가되어 새로 입력된 데이터를 읽는 것 혹은 트랜잭션 중에 데이터가 삭제되어 다음 읽기 시 이전에 존재하던 행이 사라지는 것 가능

 

---

참고자료

https://coding-factory.tistory.com/226

[DB기초] 트랜잭션이란 무엇인가?

https://mommoo.tistory.com/62

트랜잭션(Transaction)이란?

https://y00ns00.tistory.com/123

트랜잭션과 트랜잭션의 특징

 

https://www.youtube.com/watch?v=e9PC0sroCzc 

https://www.youtube.com/watch?v=urpF7jwVNWs 

https://devuna.tistory.com/30

[DB]트랜잭션(Transaction)이란?/트랜잭션의 개념,특징, 연산과정/savepoint

https://terms.naver.com/entry.naver?docId=796643&cid=42347&categoryId=42347 

트랜잭션

https://k39335.tistory.com/28

[Database] Transaction(트랜젝션) 이란?

http://wiki.hash.kr/index.php/%ED%8A%B8%EB%9E%9C%EC%9E%AD%EC%85%98

트랜잭션 - 해시넷

https://www.letmecompile.com/database-transaction-isolation-level/

DB 트랜잭션 격리 수준

http://egloos.zum.com/sweeper/v/3005129

트랜잭션과 잠금

https://bactoria.tistory.com/entry/%ED%8A%B8%EB%9E%9C%EC%9E%AD%EC%85%98-4%EA%B0%80%EC%A7%80-%ED%8A%B9%EC%A7%95-ACID

트랜잭션 4가지 특징 (ACID)