[DATABASE] 트랜잭션 ( Transaction )

데이터베이스

[DATABASE] 트랜잭션 ( Transaction )

program-yam 2024. 9. 11. 19:12

트랜잭션 ( Transaction )은 작업의 완전성을 보장해주기 위해 사용되는 개념이다.

특정한 작업을 전부 처리하거나, 전부 실패하게 만들어 데이터의 일관성을 보장해주는 기능이다.

트랜잭션 ( Transaction )을 사용하는 대표적인 이유는 작업의 단위를 하나의 쿼리에 종속하는 것이 아닌,

여러개의 작업 ( 쿼리 )을 묶어 하나의 작업 단위로 그룹화해 처리하는 작업을 뜻한다.

대부분의 데이터베이스가 트랜잭션의 특징을 이용하고 있으며, MySQL뿐만 아니라 AWS, MongoDB 등 다양한 데이터베이스에서도 트랜잭션의 개념을 확인할 수 있다.

트랜잭션의 사용 이유

트랜잭션을 이용해 다양한 문제 상황들을 해결할 수 있다.

예를 들어 은행에서 계좌이체를 하게 될 경우 아래와 같은 상황이 발생했다고 해보자.

계좌이체 비즈니스 로직

1. A 고객의 계좌에서 1000원을 차감한다.

2. B 고객의 계좌에서 1000원을 추가한다.

여기서 1번 작업 이후 2번 작업을 수행하던 중 에러가 발생하게 되면 A 고객의 계좌에서 1000원만 차감되기만 하는 문제가 생긴다. 만약 순서가 반대로 되면, B 고객의 계좌에만 1000원이 증가되는 문제가 발생한다.

이런 부분 업데이트 ( Partial Update ) 와 같은 상황을 방지하기 위해 트랜잭션 ( Transction )이라는 개념을 도입하게 됐다.

단순히 위와 같은 상황 외에도 작업한 내역을 저장하는 로깅작업, 영화관의 예매 시스템, 은행의 결제 시스템 등 데이터의 일관성을 유지해야하는 다양한 상황에서 사용한다.

결국, 트랜잭션 ( Transaction )을 이용하면 사용자가 항상 어플리케이션 실행을 완료하도록 구성할 수 있게되고, 실행을 중단할 만한 치명적인 오류가 발생하더라도, DB에 피해가 가지않아 더욱 안전하게 어플리케이션을 구성할 수 있게 된다.

트랜잭션의 특징 ( ACID )

트랜잭션의 특징 ( ACID )은 데이터베이스 트랜잭션이 안전하게 수행된다는 것을 보장하기 위한 특징들을 나열해 놓은 개념이다.

ACID는 트랜잭션을 이용해 데이터베이스를 더욱 안전하게 구성할 수 있게 도와주는 트랜잭션 특징 4가지의 맨 앞단어를 하나씩 가져와 만든 것이다.

ACID는 트랜잭션의 4가지 특징을 나타낸다.

원자성 ( Atomicity )
일관성 ( Consistency )
격리성 ( Isolation )
지속성 ( Durability )

원자성 ( Atomocity )

원자성 ( Atomocity )은 트랜잭션 내에서 실행되는 명령들을 하나의 묶음으로 처리해, 내부에서 실행된 명령들이 전부 성공하거나, 아니면 모두 실패해야한다는 특징을 말한다.

▶ 여기서, "원자성"이란, 나눠질 수 없는 단일 작업이라는 것을 의미한다.

원자성 ( Atomicity )은 트랜잭션의 가장 대표적인 특징이다. 트랜잭션에서 실행되는 쿼리마다 하나의 작업 단위로 보지않고, 여러개의 작업들을 묶어 하나의 작업단위로 보게된다.

트랜잭션을 사용하면 앞서 예시로 든 2단계로 구분된 비즈니스 로직인 고객의 계좌금액 차암과 금액 증가를 하나의 계좌이체라는 기능으로 묶어서 관리할 수 있게 되는 것이다.

결국, 원자성이라는 특징을 이용해 우리는 각각의 쿼리를 별도로 실행하는 것이 아니라, 동시에 실행해야하는 여러개의 쿼리를 묶어서 관리할 수 있게 되는 것이다. 이렇게 하면, 여러개의 비즈니스 로직을 상세하게 알지 않더라도 트랜잭션을 활용해 비즈니스 로직을 전체적으로 관리할 수 있게 된다.

일관성 ( Consistency )

일관성 ( Consistency )은 트랜잭션 내부에서 처리되는 데이터의 일관성을 유지해야하는 특징이다.

만약 작업이 성공할 경우 아무런 문제가 발생하지 않고, 실패하더라도 작업을 진행하던 도중 실패한 상태로 데이터를 방치하지 않는 특징을 지닌다.

일관성 ( Consistency )의 특징은 트랜잭션 내의 데이터는 일관되어야하며, 에러가 발생하더라도 데이터의 상태가 일관성을 유지해야 한다는 특징을 지닌다.

만약 일관성이 지켜지지 않을 경우 우리는 트랜잭션을 이용하더라도 언제 데이터가 파손될지 모르는 불안감을 가진 체 작업을 해야한다.

강의 등록의 비즈니스로직

강의 ( Coureses ) 테이블에서 강의를 생성한다.
생성된 강의 데이터를 참조하는 강의 목록 ( CourseUnit ) 테이블에 강의 영상을 업로드 한다.
강의 목록 ( CourseUnit ) 테이블에 모든 강의 영상을 업로드 했으면 COMMIT

첫번째 강의 테이블에 강의를 생성하는것은 성공했지만 두번째 강의 목록 테이블에서 모든 강의 영상을 삽입하는데 실패했다면, ROLLBACK이 실행되어 강의( Courses ) 테이블과 강의 목록 ( CourseUnit ) 테이블에는 트랜잭션 시작 전 상태로 복구된다.

이렇게, 데이터는 강의 자체가 생성되지 않거나, 모든 강의가 업로드 되는 상황이 발생하게 되어야, 일관성을 유지할 수 있을 것이고, 데이터베이스를 믿고 작업을 진행할 수 있게 된다.

격리성 ( Isolation )

격리성 ( Isolation )은 트랜잭션이 실행 중인 경우 다른 트랜잭션에 의해 데이터가 변경되는 것을 방지하는 특징이다.

트랜잭션이 완전히 수행되거나 완전히 수행되지 않은 상태를 외부에서 참조할 수는 있지만, 트랜잭션의 중간 과정이나 중간 결과를 볼 수 없도록 하는 특징이다.

격리성 ( Isolation )의 경우, MySQL에서는 사용중인 DB 오브젝트에 락 ( Lock )을 걸어 격리성을 구현하게 된다. 여기서 락 ( Lock )을 건 상태는 DB에 접속한 또다른 클라이언트가 해당 DB 오브젝트를 읽거나, 사용할 수 없도록 방지해, 데이터 무결성을 보장한다.

▶ 격리성이란 특징에서 동시성 ( Concurrency )과 격리 수준 ( Isolation Level )이라는 두 가지 중요한 개념이 나타났다.

동시성 ( Concurrency )이란 무엇일까?

동시성 ( Concurrency )은 여러 클라이언트가 동시에 하나의 데이터를 사용 및 공유 하는 것을 말한다.

동시성은 다수의 사용자가 동일한 시스템을 공유하면서 발생하는 동시 접근 문제를 해결해야 한다.

동시성 문제 ( Concurrency Issue )는 여러 클라이언트가 동시에 같은 데이터를 접근하려고 할때 발생한다.

예를 들어 2개의 계좌이체가 발생한다고 가정해보자.

1 트랜잭션에서 A 계좌에 천원을 차감해 10000 → 9000 으로 수정했다.
2 트랜잭션에서 아직 커밋 되지 않은 1 트랜잭션의 데이터를 바탕으로 A 계좌에서 천원을 차감해 9000 → 8000으로 수정했다.
1 트랜잭션에서 에러가 발생해, 트랜잭션을 ROLLBACK 하게 되었다. 따라서, A 계좌의 잔고는 원래대로 10000이 되었다.
그런데 2 트랜잭션에서 잘못된 데이터를 바탕으로 작업을 수행한 후 트랜잭션을 COMMIT 하게 되었다. 이로 인해 A 계좌의 잔고가 8000으로 잘못 표시되는 문제가 발생했다.

위 예시처럼 동시에 여러 트랜잭션이 동일한 데이터에 접근할 때는 데이터의 일관성을 유지하기 어려울 수 있다.

이러한 문제를 해결하기 위해, 자원을 사용하는 하나의 클라이언트만 해당 자원을 점유할 수 있도록 하여, 다른 사용자가 접근할 수 없도록 만들어 자원을 공유하는 원인을 제거하면 된다. 이것을 자원 잠금 ( Resource Locking )라고 부르며,

락 ( Lock )이라는 개념이 나오게 된다.

락 ( Lock )은 하나의 트랜잭션에서 사용중인 데이터를 잠그는 방식으로, 다른 트랜잭션들이 그 데이터에 접근하지 못하도록 한다. 이 방식을 사용하면, 어떤 트랜잭션도 다른 트랜잭션의 중간 상태를 볼 수 없게 되므로 데이터 일관성을 유지할 수 있게 된다.

지속성 ( Durability )

지속성 ( Durability )은 트랜잭션이 성공적으로 커밋된 후, 해당 트랜잭션에 의해 생성 또는 수정된 데이터가 어떠한 상황에서도 보존되는 특징이다. 다시 말해, 트랜잭션이 완료되면 결과는 데이터베이스에 영구적으로 저장되고, 이후 시스템에 어떠한 문제가 생기더라도 데이터는 손상되지 않는다.

지속성 ( Durability )은 트랜잭션의 안전성을 보장하며, 데이터 손실 없이 시스템의 안전성을 유지하는데 중요한 역할을 담당한다.

트랜잭션이 성공적으로 완료되면, 해당 트랜잭션에 의해 생성 또는 변경된 데이터는 데이터베이스에 COMMIT 명령을 통해 영구적으로 저장된다. 하지만, 트랜잭션 수행 도중 시스템이 비정상 종료되더라도,

시스템은 트랜잭션 로그 ( Transaction Log )를 통해 아직 커밋되지 않은 트랜잭션을 복구할 수 있다.

트랜잭션 실습

MySQL의 트랜잭션 살펴보기

MySQL에서 트랜잭션은 아래와 같은 명령어로 사용한다.

-- 트랜잭션을 시작합니다.
START TRANSACTION;

-- 성공시 작업 내역을 DB에 반영합니다.
COMMIT;

-- 실패시 START TRANSACTION이 실행되기 전 상태로 작업 내역을 취소합니다.
ROLLBACK;

트랜잭션을 사용하는 문법을 확인해봤으니,

MySQL에서 트랜잭션을 사용하기 위한 간단한 예시를 실행해보자.

MySQL의 트랜잭션 예시코드

-- SPARTA 테이블을 생성한다.
CREATE TABLE IF NOT EXISTS SPARTA
(
    spartaId      INT(11)      NOT NULL PRIMARY KEY AUTO_INCREMENT,
    spartaName    VARCHAR(255) NOT NULL,
    spartaAddress VARCHAR(255) NOT NULL
);

-- 1번째 트랜잭션을 실행한다.
START TRANSACTION;

-- SPARTA 테이블에 더미 데이터 3개를 삽입한다.
INSERT INTO SPARTA (spartaName, spartaAddress)
VALUES ('SPARTA1', 'SEOUL'),
       ('SPARTA2', 'BUSAN'),
       ('SPARTA3', 'DAEGU');

-- 1번째 트랜잭션을 DB에 적용한다.
COMMIT;


-- 2번째 트랜잭션을 실행한다.
START TRANSACTION;

-- SPARTA 테이블에 더미 데이터 3개를 삽입한다.
INSERT INTO SPARTA (spartaName, spartaAddress)
VALUES ('SPARTA4', 'SEOUL'),
       ('SPARTA5', 'BUSAN'),
       ('SPARTA6', 'DAEGU');

-- 2번째 트랜잭션을 롤백한다.
ROLLBACK;

-- 테이블의 상태를 확인한다.
SELECT * FROM SPARTA;

예시 코드를 실행하면, 2번째 트랜잭션에서 수행하는 INSERT INTO가 ROLLBACK 되었기 때문에 실제 SPARTA 테이블은 6개가 아닌, 3개의 데이터만 삽입되어 있는 상태로 존재한다.

위 예시코드는 단순히 트랜잭션의 COMMIT과 ROLLBACK이 어떤식으로 동작하는지를 확인하기 위해 사용해봤다.

락 ( LOCK )

락 ( Lock )은 동시성을 제어하기 위해 사용하는 기능이다. 해당하는 데이터를 점유해 다른 트랜잭션의 접근을 막아 동시성과 일관성의 균형을 맞추기 위해 사용한다.

하나의 데이터를 여러 사용자들이 동시에 변경하려고 할 때, 락이 존재하지 않다면, 한번에 여러 번의 수정이 발생하게되고, 최종 수정된 결과값을 인지할 수 없게 되는 상황으로 인해 데이터베이스의 일관성이 깨지게 된다. 이런 상황을 방지하기 위해 데이터베이스에서는 락 ( Lock )이라는 기능을 지원하게 되었다.

락 ( Lock )의 종류

● 공유 락 ( Shared Locks ) | 읽기 락 ( READ Locks )

다른 트랜잭션이 데이터를 읽는 것은 허용하지만, 수정하는 것을 금지한다.
READ 전용 락이라고 불리기도 하며, 해당 락을 사용하는 트랜잭션이 모든 작업을 수행했다면 공유 락은 해제된다.

예시 SQL

# 트랜잭션을 시작합니다.
START TRANSACTION;

# SPARTA 테이블을 조회할 때, 해당 데이터들에 공유 락을 설정합니다.
SELECT * FROM SPARTA LOCK IN SHARE MODE;

● 배타 락 ( Exclusive Locks ) | 쓰기 락 ( WRITE Locks )

다른 트랜잭션이 데이터를 읽거나, 수정하는 것을 금지한다.
WRITE 전용 락이라고 불리며, 트랜잭션이 해당하는 데이터를 점유한 후 다른 트랜잭션이 해당 데이터에 접근 할 수 없도록 만든다.

예시 SQL

# 트랜잭션을 시작합니다.
START TRANSACTION;

# SPARTA 테이블을 조회할 때, 해당 데이터들에 배타 락을 설정합니다.
SELECT * FROM SPARTA FOR UPDATE;

락킹 수준 ( Locking Level )

● 글로벌 락 ( Global Locks ) | 데이터베이스 락 ( Database Locks )

데이터베이스의 모든 테이블에 락을 걸어, 현재 트랜잭션을 제외한 나머지 트랜잭션들이 모든 테이블을 사용할 수 없도록 만든다.
가장 높은 수준의 락을 가지고 있으며, 가장 큰 범위를 가지고 있다.

예시 SQL

# 글로벌 락을 획득합니다.
# MySQL 서버에 존재하는 모든 테이블에 락을 겁니다.
FLUSH TABLES WITH READ LOCK;

● 테이블 락 ( Table Locks )

다른 사용자가 작업중인 테이블을 동시에 수정하지 못하도록 한다.

예시 SQL

# SPARTA 테이블에 테이블 락을 설정합니다.
LOCK TABLES SPARTA READ;

● 네임드 락 ( Named Locks )

테이블이나 테이블의 행과같은 DB 오브젝트가 아닌, 특정한 문자열을 점유한다.

예시 SQL

# sparta_name 문자열을 획득합니다.
# 만약, 10초 동안 획득 하지 못한다면, NULL을 반환합니다.
SELECT GET_LOCK('sparta_name', 10);

● 메타데이터 락 ( Metadata Locks )

다른 사용자가 작업중인 테이블의 동일한 행 및 동일한 데이터베이스의 객체를 동시에 수정하지 못하도록 한다.

예시 SQL

# 테이블 구조를 변경할 때, MySQL은 내부적으로 메타데이터 락을 설정합니다.
ALTER TABLE SPARTA ADD COLUMN Age Int;

락은 다양한 락킹 수준 ( Locking Level )을 가지고 있는데, 잘못된 락 설정을 하게 될 경우 우리는 모든 API가 동작하지 않는 교착 상태 ( Dead Lock )가 발생하게 되어, 프로그램이 멈춰버리는 문제가 발생하게 될 수 있다.

교착 상태 ( Dead Lock ) 예시

교착 상태 ( Dead Lock )는 여러 테이블에 락 ( Lock )을 적용해, 다른 작업이 처리되지 못하게 점유하고 있는 작업이 있을 때, 다른 작업을 끝나는 것을 무한정 기다리는 것을 나타낸다.

아래와 같은 2개의 트랜잭션이 동시에 실행된다고 가정해보자.

A ▶ B 테이블을 순차적으로 사용하는 트랜잭션
B ▶ A 테이블을 순차적으로 사용하는 트랜잭션

가장 먼저 1은 처음 A 테이블을 점유하기 위해 락을 건다. 그리고 동시에 2 또한 B 테이블을 점유하기 위해 락을 건다.

그러면 1은 B 테이블의 락이 풀리기를 기다리는 상태가 발생하고, 2 또한 A 테이블의 락이 풀리기를 기다리는 상태가 발생하게 된다. 이처럼 리소스를 접근하려고 할 때, 서로가 서로의 리소스를 점유하고 있을 때 발생하는 것을 교착 상태 ( Dead Lock )이라고 부른다.

해당하는 상황을 해결하기 위해 우리는 트랜잭션에서 사용하는 락 ( Lock )의 수준을 명확하게 이해하고, 적재적소에 필요한 락의 수준을 설정해 트랜잭션을 구성해야한다.

트랜잭션의 격리 수준 ( Isolation Level )

트랜잭션의 격리 수준 ( Isolaction Level )은 여러 트랜잭션이 동시에 처리될 때 다른 트랜잭션에서 변경 및 조회하는 데이터를 읽을 수 있도록 허용하거나 거부하는 것을 결정하기 위해 사용하는 것이다.

▶ 여기서, 중요한 점은 '데이터의 일관성'과 '동시성 처리 성능' 사이에서 균형을 잡는 것이다.

트랜잭션의 격리 수준은 대표적으로 4가지로 나타낸다.

READ UNCOMMITTED

커밋 되지 않은 읽기 ( Uncommitted Read )를 허용하는 격리 수준이다.
가장 낮은 수준의 격리수준이며, 락을 걸지 않아 동시성이 높지만 일관성이 쉽게 깨질 수 있다.

READ COMMITTED

커밋 된 읽기 ( Committed Read )만을 허용하고, SELECT 문을 실행할 때 공유락을 건다.
다른 트랜잭션이 데이터를 수정하고 있는 중에 데이터를 읽을 수 없어 커밋되지 않은 읽기현상이 발생하지 않는다.

REPEATABLE READ

읽기를 마치더라도 공유락을 풀지 않으며, 트랜잭션이 완전히 종료될 때 까지 락을 유지한다.
공유락이 걸린 상태에서 데이터를 수정하는 것은 불가능하지만, 데이터를 삽입하는 것이 가능해진다. 그로인해 팬텀 읽기가 발생할 수 있는 문제점이 있다.

SERIALIZABLE

데이터를 읽는 동안 다른 트랜잭션이 해당 데이터를 읽거나 삽입할 수 없고, 새로운 데이터를 추가하는 것 또한 불가능하다.
가장 높은 수준의 격리 수준이므로, 동시성이 떨어지는 문제점이 존재한다.

커밋되지 않은 읽기 ( Uncommitted Read )

커밋되지 않은 읽기 ( Uncommitted Read )는 다른 트랜잭션에 의해 작업중인 데이터를 읽게 되는 것을 나타낸다. 만약 커밋되지 않은 읽기가 발생할 경우, 의도치 않은 데이터를 참조하게 되어 데이터의 일관성이 깨지게 되는 상황이 발생하게된다.

팬텀 읽기 ( Phantom Read )

트랜잭션을 수행하던 중 다른 트랜잭션에 의해 삭제된 데이터를 팬텀행 ( Phantom Rows )이라고 한다. 여기서, 팬텀행에 해당하는 데이터를 읽는 것을 팬텀 읽기 ( Phantom Read )라고 부른다.