[Database] 트랜잭션의 개념 및 특성(ACID)

오늘은 데이터베이스 운용에 필수적인 개념인 트랜잭션과 ACID 특성을 알아보겠습니다.
은행 시스템으로 사례를 들어 누구든 흥미롭게(?) 느낄 수 있도록 설명해보겠습니다.

---

트랜잭션이란?

: DB의 상태를 변경시키는 작업 단위

조금 더 쉽게 말하면 트랜잭션(Transaction)은 DB에 저장하고(Create) 읽고(Read) 변경(Update)하고 삭제(Delete)하는 작업들의 집합 단위입니다. 이는 단순히 하나의 SQL이 아니라, 특정 작업을 수행하기 위해 모아놓은 SQL의 논리적 단위를 말합니다. CRUD...논리적...집합..? 백문이 불여일견..입니다. 예시를 보면 이해가 더 쉬울 것 같습니다.

---

(예시) 은행 송금 시스템

뱅킹 시스템에서 A가 B에게 송금하는 상황

1. A의 계좌에서 100원을 출금
2. B의 계좌에 100원을 입금

이 경우 두 동작을 묶어서 하나의 트랜잭션으로 처리합니다.
왜냐면, 출금만 처리되고 입금이 실패하면 A의 계좌에서 돈이 빠져나가고 B는 돈을 받지 못하는 데이터 불일치 문제가 발생하기 때문입니다. 트랜잭션은 일련의 동작을 묶어 처리함으로써 이런 문제를 방지하는 안정장치입니다.

---

트랜잭션의 특성, ACID

트랜잭션은 ACID라는 4가지 주요 특성을 만족해야 합니다. 아래에서 예시를 통해 하나씩 알아보겠습니다.

1. Atomicity (원자성)

트랜잭션은 쪼갤 수 없는 하나의 단위로 처리됩니다.
즉, 트랜잭션에 포함된 모든 SQL이 DB에 반영되거나 어떤 부분도 반영되지 않거나 이 둘 중 하나여야 합니다.

(예시)

• 성공 케이스: A의 계좌에서 100만 원 출금 → B의 계좌에 100만 원 입금
• 실패 케이스: 출금은 성공했지만 입금이 실패 → 트랜잭션 전체를 롤백(rollback) 하여 출금 전 상태로 복구

---

2. Consistency (일관성)

트랜잭션이 실행되기 전과 후의 데이터 상태는 일정한 규칙(무결성 제약 조건)을 만족해야 합니다.

(예시)

• 계좌 잔액은 음수가 될 수 없다.
• 송금한 금액 합계와 받은 금액의 합계가 일치해야 한다.

---

3. Isolation (격리성)

동시에 실행되는 트랜잭션은 서로 독립적으로 처리되어야 하며, 다른 트랜잭션의 중간 상태를 볼 수 없어야 합니다.

(예시)

A가 B에게 송금을 진행 중일 때, A의 계좌 잔액을 조회하면 송금이 진행되기 이전의 상태만 볼 수 있어야 합니다. 이는 Shared Lock(읽기 잠금)이나 Exclusive Lock(쓰기 잠금)과 같은 메커니즘으로 구현됩니다.

---

4. Durability (지속성)

트랜잭션이 성공적으로 완료된 후에는 어떠한 시스템 오류나 장애가 발생해도 작업 결과가 유지되어야 합니다.

(예시)

송금 트랜잭션이 성공적으로 끝난 뒤에는 데이터베이스 서버가 중단되더라도 A와 B의 계좌 상태는 변하지 않아야 합니다. 이를 위해 데이터를 비휘발성 메모리에 저장하고, 문제가 생기면 로그를 이용하여 복구합니다.

---

트랜잭션 상태

우선 ACID의 기술적인 측면을 살펴보기 전에 트랜잭션 상태와 commit, rollback에 대한 내용을 먼저 살펴보겠습니다.

트랜잭션은 실행부터 종료까지 아래의 상태를 가지며, Commit 또는 Rollback으로 종료가 됩니다

1. Active (활성): 트랜잭션이 실행 중인 상태
2. Partially Committed (부분 완료): 트랜잭션 작업이 끝났으나 최종 Commit 전 상태
3. Committed (완료): 트랜잭션이 성공적으로 끝난 상태
4. Failed (실패): 트랜잭션이 실패한 상태
5. Aborted (중단): 실패한 트랜잭션이 Rollback 된 상태

Commit

• 트랜잭션이 성공적으로 완료되었을 때 데이터를 영구적으로 저장하는 명령어입니다.

Rollback

• 트랜잭션 도중 문제가 발생했을 때 데이터를 이전 상태로 되돌리는 명령어입니다.

트랜잭션 동작 원리

내부적으로 ACID가 어떻게 지켜지는지 궁금해서 찾아본 내용

Atomicity (원자성)

1. 로그 작성: 트랜잭션이 실행되면 변경될 데이터를 기록한 redo 로그와 undo 로그를 생성합니다.
2. Commit 신호
   • 트랜잭션이 성공적으로 완료되면, redo 로그를 사용해 변경 사항을 실제 데이터베이스에 적용합니다.
   • 트랜잭션이 실패하면, undo 로그를 사용해 변경 사항을 취소하고 원래 상태로 복구합니다.
3. 트랜잭션 중단
   • 시스템 장애나 에러가 발생하면 rollback을 통해 트랜잭션 시작 이전의 상태로 복구합니다.

---

Consistency (일관성)

1. 무결성 제약 조건 확인
   • 조건은 다양합니다. Primary Key, Foreign Key, 데이터 타입 유효성 조건 등을 검증합니다.
   • 트랜잭션 실행 도중에 규칙을 위반하면 중단하고, 이전 상태로 복구합니다.

(예시)

A 계좌의 잔액이 음수가 될 수 없다는 규칙이 있을 때, 출금 요청을 처리하기 전 잔액을 확인합니다. 잔액이 부족하면 트랜잭션이 중단됩니다.

---

Isolation (격리성)

1. 잠금 메커니즘
   • 공유 잠금(Shared Lock): 데이터 읽기 중 다른 트랜잭션의 쓰기를 차단합니다.
   • 배타 잠금(Exclusive Lock): 데이터 수정 중 다른 트랜잭션의 읽기와 쓰기를 차단합니다.
2. 격리 수준(Isolation Level)

• 데이터베이스에서 트랜잭션의 격리 수준을 설정하여 동시성 수준을 조정합니다.
  대표적인 격리 수준 (간단하게만..)
  • Read Uncommitted - 다른 트랜잭션이 커밋하지 않은 데이터(중간 데이터)도 읽을 수 있음
  • Read Committed - 커밋된 데이터만 읽을 수 있
  • Repeatable Read - 트랜잭션이 시작되기 전의 상태를 복사 떠서, 하나의 트랜잭션 동안 같은 데이터를 여러 번 읽어도 결과가 동일하게 유지됨
  • Serializable - 트랜잭션을 무조건 순차적으로 실행되는 것처럼 해서 동일한 레코드에 접근할 일이 없음

---

Durability (지속성)

1. 로그 기록:
   • 트랜잭션 실행 과정에서 변경된 데이터를 로그 파일에 기록합니다.
2. 체크포인트:
   • 특정 시점에 데이터베이스 상태를 저장하여 장애 발생 시 복구 시간을 단축합니다.

---

💡 은행 점검 시간과 Consistency 💡

가끔 궁금해지는 “왜 은행은 점검 시간이 필요할까?”에 대해 이야기 해보겠습니다.

KB국민은행	매일 00:00 ~ 00:05
신한은행	매일 23:50 ~ 00:05
IBK기업은행	매일 23:50 ~ 00:10
NH농협은행	매일 23:55 ~ 00:30

Consistency를 위한 점검

은행 시스템은 매일 데이터의 무결성과 일관성을 유지하기 위해 점검 시간을 가집니다. 점검 시간에는 다음 작업을 포함한 다양한 작업들이 이루어집니다:

1. 하루 동안 처리된 모든 거래가 올바르게 반영되었는지 확인
2. 트랜잭션 누락이나 중복 기록 여부 점검
3. 중요한 데이터를 백업하여 장애 발생 시 복구 가능성을 보장