트랜잭션과 ACID: 데이터베이스 무결성을 지키는 처리 단위

여러 데이터 변경을 하나의 결과로 묶는 단위

트랜잭션은 데이터베이스에서 함께 수행돼야 하는 Read와 Write 연산을 묶은 논리적 작업 단위다. 데이터 상태를 바꾸는 여러 작업을 하나로 취급해, 데이터의 일관성과 무결성을 유지한다.

데이터베이스에는 무결성 보장 장치로 작동하고, 시스템에는 장애 이후에도 데이터 손실 없이 복구할 수 있는 안전장치가 된다. 업무 관점에서는 하나의 프로세스를 원자적으로 끝내는 경계이기도 하다.

은행 계좌 이체를 생각하면 분명하다. A 계좌 출금과 B 계좌 입금은 모두 성공해야 하며, 중간에 오류가 나면 어느 한쪽만 반영된 상태가 남아서는 안 된다.

ACID가 보장하는 데이터 상태

트랜잭션은 원자성, 일관성, 격리성, 지속성으로 구성된 ACID 특성을 만족해야 한다.

원자성은 중간 결과를 남기지 않는다

원자성(Atomicity)은 트랜잭션 안의 모든 연산이 완료되거나 전혀 실행되지 않아야 한다는 전부 또는 무 원칙이다. 따라서 중간 상태는 남지 않는다. 로그 기반 복구와 섀도우 페이징이 이를 구현하는 메커니즘이다.

인터넷 뱅킹에서 1백만원을 이체할 때 A 계좌 출금과 B 계좌 입금은 함께 성공해야 한다. 오류가 발생하면 원래 상태로 되돌아가야 한다.

일관성은 제약조건을 지킨다

일관성(Consistency)은 실행 전후 데이터베이스가 일관된 상태를 유지한다는 뜻이다. 기본키, 외래키, 도메인 같은 무결성 제약조건은 항상 만족해야 하며, 트랜잭션은 하나의 일관된 상태를 다른 일관된 상태로 바꾼다.

재고관리 시스템의 판매 처리는 재고 수량을 줄이면서 판매 내역을 기록한다. 이 과정 뒤에도 재고는 항상 0 이상이어야 한다.

격리성은 동시에 실행되는 작업을 분리한다

격리성(Isolation)은 동시에 실행되는 트랜잭션이 서로에게 영향을 주지 않도록 하는 성질이다. 구현 강도는 격리 수준에 따라 달라진다.

• READ UNCOMMITTED
• READ COMMITTED
• REPEATABLE READ
• SERIALIZABLE

항공권 예약에서 같은 좌석을 동시에 예약하려는 사용자가 있다면, 한 트랜잭션이 끝날 때까지 다른 트랜잭션은 해당 데이터에 접근할 수 없어야 한다.

지속성은 완료 결과를 장애 뒤에도 보존한다

지속성(Durability)은 성공적으로 끝난 트랜잭션 결과가 시스템 장애 이후에도 영구적으로 반영돼야 한다는 요구다. 로그와 체크포인트를 통해 구현하며, 하드웨어 또는 소프트웨어 장애 후에도 데이터를 복구할 수 있어야 한다.

온라인 쇼핑몰에서 주문이 완료된 뒤 시스템 장애가 발생하더라도 주문 내역은 남아 있어야 한다.

실행부터 완료 또는 취소까지의 상태

트랜잭션은 실행 중인 상태에서 성공적으로 커밋되거나, 오류로 실패한 뒤 취소된다.

⤢✕

• Active: 트랜잭션이 실행 중인 상태
• Partially Committed: 마지막 연산까지 실행했지만 아직 데이터베이스에 반영되지 않은 상태
• Committed: 성공적으로 끝나 데이터베이스에 영구 반영된 상태
• Failed: 실행 중 오류가 발생한 상태
• Aborted: 트랜잭션이 취소되고 데이터베이스가 원래 상태로 복구된 상태

동시 실행과 작업 범위를 다루는 방법

여러 트랜잭션이 함께 실행될 때는 데이터 일관성을 유지할 동시성 제어가 필요하다. 대표적인 방식으로 공유 락과 배타적 락을 사용하는 락킹, 타임스탬프 기반 프로토콜, 낙관적 동시성 제어, 다중 버전 동시성 제어가 있다.

대규모 전자상거래 플랫폼에서 수천 명의 사용자가 동시에 상품을 주문하면 재고 정보에 대한 동시 접근을 제어해야 한다. 이때 락킹 기법을 활용할 수 있다.

트랜잭션의 범위는 가능한 짧게 잡는다. 긴 트랜잭션은 다른 트랜잭션의 대기 시간을 늘리고 메모리와 락을 오래 점유한다. 논리적 작업 단위로 분할하고, 읽기 전용 작업과 쓰기 작업을 나누며, 배치 처리를 최적화하는 방식이 사용된다.

사용자 프로필을 바꿀 때 시간이 걸리는 프로필 이미지 업로드와 빠르게 처리되는 기본 정보 업데이트를 별도 트랜잭션으로 분리하는 것이 한 사례다.

용량 계획과 성능 조정에 쓰이는 트랜잭션 패턴

트랜잭션 분석은 시스템 용량을 산정하는 근거가 된다. 초당 처리 가능한 트랜잭션 수인 TPS, 피크 시간대 처리량, 읽기와 쓰기의 트랜잭션 유형별 비율, 트랜잭션 복잡도와 자원 사용량을 함께 본다.

금융 시스템에서 일일 평균 100만 건의 거래와 피크 시간대 초당 500 TPS를 예상한다면, 이 값을 데이터베이스 서버 용량 산정에 활용할 수 있다.

하드웨어 요구사항도 트랜잭션 패턴에서 나온다. CPU 코어 수는 트랜잭션 복잡도와 동시 처리량에 따라 결정하고, 메모리는 활성 트랜잭션 수·캐시 크기·버퍼 풀 크기를 기준으로 계산한다. 디스크 I/O는 트랜잭션 로그 기록과 데이터 페이지 읽기·쓰기 속도를, 네트워크는 분산 트랜잭션 처리에 필요한 대역폭을 고려한다.

대형 전자상거래 플랫폼은 블랙프라이데이 기간에 평소보다 10배 많은 트랜잭션을 처리하기 위해 클라우드 자원 자동 확장 정책을 세울 수 있다.

성능을 조정할 때는 트랜잭션 패턴에 맞춰 인덱스를 설계하고, 트랜잭션 지역성(locality)을 고려해 데이터를 파티셔닝한다. 자주 접근하는 데이터는 메모리에 캐싱하며, 요구사항에 따라 격리 수준을 완화할 수 있다. 소셜 미디어 플랫폼에서 사용자 타임라인 데이터를 샤딩하고 읽기 작업에 REPEATABLE READ 대신 READ COMMITTED를 적용하는 방식이 이에 해당한다.

여러 서비스에 걸친 일관성

분산 트랜잭션은 여러 데이터베이스 또는 서비스에 걸쳐 하나의 처리를 조정한다. 2단계 커밋(2PC: Two-Phase Commit) 프로토콜, 마이크로서비스 환경에서 활용하는 사가(Saga) 패턴, 이기종 시스템 간 조정을 위한 XA 트랜잭션이 대표적이다.

⤢✕

항공권 예약 시스템에서 좌석 예약, 결제 처리, 마일리지 적립이 각각 다른 서비스라면 사가 패턴으로 일관성을 보장할 수 있다.

운영에서 지킬 설계 원칙

트랜잭션에는 필요한 최소한의 작업만 포함한다. 읽기 전용 트랜잭션은 별도로 분리하고, 일시적 오류에는 자동 재시도 메커니즘을 둔다. 트랜잭션 관리는 비즈니스 로직과 분리하며, 비즈니스 요구사항에 맞는 격리 수준을 선택한다.

데드락을 줄이려면 일관된 순서로 리소스에 접근하고 타임아웃을 설정해야 한다. 트랜잭션 성능과 실패율도 계속 모니터링 대상이 된다.

전통적인 ACID 트랜잭션은 현대적인 분산 시스템과 마이크로서비스 아키텍처에서 적용이 어려워지고 있다. BASE(Basically Available, Soft state, Eventually consistent) 모델과 사가 패턴 같은 분산 트랜잭션 처리 방식까지 함께 이해해야 한다.