ACID Properties
ACID(Atomicity, Consistency, Isolation, Durability) 는 1983 년 Andreas Reuter 와 Theo Härder 가 정의한 데이터베이스 트랜잭션의 4 대 핵심 특성으로, 데이터 무결성과 신뢰성을 보장한다.
- 원자성 (Atomicity) 은 트랜잭션이 전부 실행되거나 전혀 실행되지 않음을,
- 일관성 (Consistency) 은 데이터 제약과 규칙 준수를,
- 격리성 (Isolation) 은 동시 실행 간 간섭 방지를,
- 지속성 (Durability) 은 커밋된 결과의 영구 보존을 의미한다.
이 원칙은 은행 거래, 재고 관리, 의료 기록 등 오류와 장애에 강한 시스템에서 필수적이다. 현대의 분산·클라우드 환경에서는 CAP 정리와의 균형 속에서 2PC, 합의 알고리즘 (Paxos, Raft) 등으로 ACID 를 구현하며, NewSQL 및 클라우드 네이티브 DBMS 에서도 표준 설계 지침으로 적용된다.
핵심 개념
개념 | 설명 |
---|---|
Atomicity | 트랜잭션 내 모든 작업이 완전 수행되거나 전혀 수행되지 않음. 실패 시 Undo 로그를 통해 롤백. |
Consistency | 트랜잭션 전후 데이터베이스가 항상 유효 상태 유지. 제약조건 및 비즈니스 규칙 만족 필수. |
Isolation | 동시에 실행되는 트랜잭션이 서로 영향을 주지 않도록 격리. 격리 수준에 따라 성능과 일관성 균형 조절. |
Durability | 커밋된 데이터는 장애 이후에도 보존. WAL·Redo 로그·복제를 통한 보장. |
ACID 는 데이터베이스 트랜잭션 신뢰성을 보장하는 핵심 원칙으로, Atomicity, Consistency, Isolation, Durability 네 가지 속성을 기반으로 한다.
이론적으로는 트랜잭션 처리 모델과 동시성 제어 메커니즘, 장애 복구 구조로 설명되며, 실무에서는 제약조건 설계·트랜잭션 관리·격리 수준 선택·장애 복구 체계로 구현된다.
분산 환경과 마이크로서비스 아키텍처에서는 100% ACID 보장보다 성능·가용성과의 균형을 위해 변형된 패턴 (SAGA, Outbox, 2PC 등) 을 채택하는 경우가 많다.
핵심 개념의 실무 구현 연관성 및 적용 방식
개념 | 실무 구현 방식 | 적용 사례 |
---|---|---|
Atomicity | 트랜잭션 로그, ARIES Undo/Redo, Savepoint, Rollback | 계좌 이체, 주문 처리 |
Consistency | DB 스키마 제약 (FK, UNIQUE, CHECK), 트리거, 애플리케이션 검증 로직 | 재고 관리, 데이터 검증 |
Isolation | Lock(Latch, Row/Table), MVCC, 격리 수준 설정 | 동시 결제 처리, 리포트 생성 |
Durability | WAL, Redo 로그, 체크포인트, 동기 복제 | 금융거래 기록, 로그 감사 |
기초 이해 (Foundation Understanding)
개념 정의 및 본질
ACID 는 데이터베이스 트랜잭션이 안전하고 예측 가능하며 신뢰성 있게 처리되도록 보장하는 네 가지 핵심 속성
- Atomicity(원자성)
- Consistency(일관성)
- Isolation(격리성)
- Durability(지속성)
의 약자이다.
- 트랜잭션은 하나의 논리적 작업 단위로, 여러 데이터 조작 연산이 포함될 수 있으며, ACID 속성을 준수할 때만 무결성과 신뢰성을 확보할 수 있다.
- 원자성은 트랜잭션 내 모든 작업이 전부 수행되거나 전혀 수행되지 않음을 의미하며, 실패 시 롤백된다.
- 일관성은 트랜잭션 전후에 데이터베이스가 항상 유효 상태를 유지하도록 보장한다.
- 격리성은 동시에 실행되는 트랜잭션이 서로 간섭하지 않도록 하며, 격리 수준 설정을 통해 성능과 일관성 간 균형을 맞춘다.
- 지속성은 커밋된 결과가 시스템 장애 이후에도 유지되도록 보장한다.
이 네 속성은 전통적인 단일 DB 환경에서 필수적이며, 분산 시스템에서는 CAP 이론 및 BASE 모델과의 균형 속에서 적용된다.
등장 배경 및 발전 과정
1970~80 년대 다중 사용자 환경에서 데이터 손실·불일치 문제를 해결하고, 시스템 장애 시에도 데이터 무결성을 보장하기 위한 필요성이 커졌다.
IBM System R 과 INGRES 프로젝트에서 트랜잭션 개념이 구체화되었고, Jim Gray 가 로그 기반 복구와 동시성 제어 이론을 발전시켰다.
이러한 흐름 속에서 1983 년 Andreas Reuter 와 Theo Härder 가 ACID라는 용어를 제안하며, 데이터베이스 트랜잭션의 신뢰성과 무결성을 보장하는 표준 원칙으로 자리 잡았다.
발전 과정
시기 | 주요 사건 및 발전 | 영향 |
---|---|---|
1970 년대 | IBM System R, INGRES 프로젝트에서 트랜잭션 개념 정립 | 동시성 제어와 복구 필요성 부각 |
1970~80 년대 | Jim Gray 의 트랜잭션 처리 이론과 로그 기반 복구 메커니즘 연구 | ACID 기반 기술 토대 마련 |
1983 년 | Reuter & Härder, ACID 용어 최초 제안 | 트랜잭션 신뢰성 표준화 |
1990 년대 | 분산 DB 확산, 2PC·Paxos·Raft 등 합의 알고리즘 결합 | 글로벌 트랜잭션 지원 |
2000 년 | Eric Brewer, CAP 정리 발표 | BASE 모델과 ACID 대안 부각 |
2010 년대~ | NoSQL·CloudDB 확산, ACID 일부 완화 또는 재도입 | 분산·클라우드 환경 적용 |
현재 | NewSQL·분산 트랜잭션 프레임워크에서 ACID 유지·최적화 | 고성능·고일관성 DB 구현 |
timeline title ACID 발전 과정 1970 : IBM System R, INGRES 프로젝트 → 트랜잭션 개념 정립 1975 : Jim Gray, 트랜잭션 처리·복구 이론 연구 1983 : Reuter & Härder, ACID 용어 최초 제안 1990 : 분산 DB 확산, 2PC·합의 알고리즘 결합 2000 : Eric Brewer, CAP 정리 발표 → BASE 모델 부각 2010 : NoSQL·CloudDB 확산, ACID 완화·재도입 2020 : NewSQL·분산 트랜잭션 프레임워크에서 ACID 최적화
목적 및 필요성
ACID 의 목적은 장애, 동시성, 오류 상황에서도 데이터 무결성과 일관성을 유지하고, 핵심 비즈니스 운영의 신뢰성을 보장하는 것이다. 이를 통해 데이터 손상·불일치를 방지하며, 금융·의료 등 법적 규제 준수와 감사 가능성을 확보한다. 또한 트랜잭션 단위로 개발 로직을 단순화하고 예외 처리 복잡성을 줄여 개발 생산성을 높인다. 분산 환경에서도 안정적인 동작을 위한 설계 기반을 제공하여, 확장성과 안정성을 동시에 추구한다.
카테고리 | 목적/가치 | 설명 |
---|---|---|
데이터 무결성 보장 | 정확성·일관성 유지 | 장애·동시성·오류 상황에서도 데이터 정합성 확보 |
비즈니스 신뢰성 확보 | 핵심 서비스 안정성 | 금융·전자상거래·의료 등 크리티컬 업무의 안정 운영 |
시스템 복구 능력 | 데이터 손실 방지 | 예기치 못한 장애에도 안전한 데이터 복구 가능 |
동시성 문제 해결 | 다중 사용자 환경 지원 | 동시 트랜잭션 처리 시 일관성 유지 |
표준화된 트랜잭션 처리 | 개발 단순화 | 트랜잭션 단위 모델 제공, 예외 처리 복잡성 감소 |
규제·감사 대응 | 법적 요건 충족 | 규제 산업에서 감사 추적성과 정합성 보장 |
분산 환경 설계 기반 | 확장성·안정성 확보 | CAP 이론 고려한 분산 트랜잭션 설계 지원 |
주요 특징
ACID Properties 는 네 가지 속성이 상호 보완적으로 동작하여 트랜잭션의 무결성과 신뢰성을 보장한다. 각 속성은 특정 기술을 통해 구현되며, 이로 인한 성능·확장성·복잡성의 트레이드오프가 존재한다.
- 원자성: 모든 연산이 전부 성공하거나 전부 실패하도록 보장. Undo/Redo 로그, ARIES 알고리즘으로 구현.
- 일관성: 트랜잭션 전후에 모든 데이터 제약조건 유지. DB 스키마 제약, 트리거, 애플리케이션 검증 로직 사용.
- 격리성: 동시 실행되는 트랜잭션 간 간섭 방지. ANSI SQL 격리 수준, MVCC, 2PL, SSI 로 구현.
- 지속성: 커밋된 데이터는 장애 후에도 영구 저장. WAL, 체크포인트, 복제·백업으로 구현.
ACID 의 네 속성은 각각 독립적인 기능이지만, 실제 DBMS 에서는 로그 기반 복구와 동시성 제어 메커니즘이 결합되어 동작한다.
원자성·지속성은 주로 저장소와 로그 시스템에서, 일관성·격리성은 동시성 제어와 제약 조건 관리에서 보장된다.
분산 환경에서는 네 속성을 모두 만족시키는 것이 어렵기 때문에, 성능·가용성과의 균형을 고려한 설계가 필수이다.
핵심 이론 (Core Theory)
핵심 설계 원칙
ACID 를 구현하는 설계 원칙은 다음과 같이 요약할 수 있다.
트랜잭션은 분할 불가능한 단일 단위로, 항상 유효한 상태 간 전이만 허용하며, 동시 실행 시 간섭이 없어야 하고, 커밋된 결과는 장애에도 유지된다.
이를 위해 WAL 기반 처리, 일관성 검증 경계, 격리 수준 설계, 복구 메커니즘이 결합된다.
설계 원칙 | 설명 | 구현/기술 근거 |
---|---|---|
Single Unit of Work (원자성) | 트랜잭션은 분할 불가능한 단일 작업 단위로 처리 | 트랜잭션 관리기, Undo 로그 |
Valid State Transitions (일관성) | 유효한 상태에서 다른 유효한 상태로만 전환 | FK, Check, Trigger, App Validation |
Concurrent Independence (격리성) | 동시 실행 트랜잭션 간 간섭 없이 독립 실행 | Isolation Level, MVCC, 2PL |
Permanent Commitment (지속성) | 커밋된 변경사항은 장애 후에도 영구 보존 | WAL, Commit Flush, Replication |
WAL 기반 처리 | 로그를 먼저 기록하여 원자성·내구성 보장 | Write-Ahead Logging, ARIES |
일관성 경계 관리 | 데이터 무결성을 DB 제약과 App 경계에서 보장 | 스키마 제약, 비즈니스 규칙 |
ACID 내장 로직 | 트랜잭션 시스템에 ACID 준수 메커니즘 포함 | DBMS 아키텍처 설계 |
ACID 설계 원칙은 원자성·일관성·격리성·지속성 네 속성을 구체적인 기술로 구현하는 방법론이다.
핵심은 WAL 기반 복구, 격리 수준 설계, 일관성 검증 경계 설정이며, 장애와 동시성 환경에서도 데이터 무결성과 안정성을 보장하는 구조를 만드는 것이다.
분산 환경에서는 성능·가용성과의 균형을 고려해 설계 원칙을 일부 조정할 수 있다.
단일 DB ↔ 분산 DB 환경 ACID 설계 원칙 비교
속성 | 단일 DB 설계 원칙 | 분산 DB 설계 원칙 | 전환 시 고려해야 할 변화 | 대안 패턴 / 기술 |
---|---|---|---|---|
원자성 (Atomicity) | WAL 기반 원자성 보장, Undo/Redo 로그 처리 | 글로벌 트랜잭션 합의 필요 | 네트워크 장애 시 원자성 손실 가능, 다중 노드 간 상태 불일치 위험 | 2PC/3PC, SAGA 패턴(보상 트랜잭션), TCC(Try-Confirm-Cancel) |
일관성 (Consistency) | 스키마 제약조건, 트리거, FK 등으로 강한 일관성 유지 | 글로벌 스키마 제약·검증 부담 큼 | 노드·리전 간 데이터 전파 지연으로 일관성 깨짐 | Eventual Consistency, Causal Consistency, 중앙 제약 서비스 |
격리성 (Isolation) | MVCC, 2PL, Serializable 로 트랜잭션 간 독립성 보장 | 글로벌 MVCC, 분산 락 필요 | 글로벌 락으로 인한 성능 저하, 노드 간 시차 문제 | 분산 MVCC, Vector Clock, CRDT |
지속성 (Durability) | Commit 시 디스크 flush, 로컬 백업·동기 복제 | 다중 리전/노드에 데이터 복제 | 비동기 복제 시 장애 발생 시점 데이터 손실 가능성 | Raft/Paxos 합의, Quorum Write/Read, 동기 멀티 리전 복제 |
복구 메커니즘 | 단일 노드 WAL 복구, 체크포인트 기반 | 분산 합의 로그 복구, 리더 재선출 | 장애 복구 시 글로벌 상태 일관성 회복 필요 | Consensus 기반 로그, Incremental Backup |
동시성 제어 | 로컬 락 매니저, 단일 MVCC 로 처리 | 분산 락 서비스 필요 | 글로벌 락 병목, Latency 증가 | ZooKeeper, etcd, Optimistic Concurrency Control |
성능 트레이드오프 | ACID 준수 비용 낮고 지연 적음 | 네트워크 왕복·합의 비용 증가 | 고성능 유지 위해 일부 속성 완화 필요 | CAP 기반 설계, Hotspot Sharding, CQRS |
설계 초점 | 강한 일관성과 무결성 중심 | 가용성과 확장성 중심 | 속성별 절충 필요 | BASE 모델, Event Sourcing |
- 단일 DB → 분산 DB 전환 시, 원자성과 일관성 보장 방식이 가장 크게 변한다.
- 분산 환경은 **합의 알고리즘 (Consensus)**과 **대체 패턴 (SAGA, TCC, Eventual Consistency)**을 통한 속성 보완이 필수이다.
- 동시성·내구성 보장은 분산 락 서비스와 Quorum 기반 복제로 대체할 수 있다.
- 최종 설계는 CAP 정리와 비즈니스 요구사항에 맞춘 속성별 타협안이 핵심이다.
기본 원리 및 동작 메커니즘
기본 원리
속성 | 핵심 정의 | 주 구현 수단 (예) | 실패/경합 시 보장 방식 |
---|---|---|---|
원자성 (A) | 전부 수행/전무 수행 | Undo 로그, ARIES, 롤백 세그먼트 | 오류 시 Undo로 직전 일관 상태 복구 |
일관성 (C) | 제약 조건 항상 충족 | FK/체크/유니크, 트리거, 애플리케이션 불변식 | 위반 시 트랜잭션 실패→롤백 |
격리성 (I) | 동시 트랜잭션 간 간섭 차단 | 락(S/X, 범위락) 또는 MVCC 스냅샷 | 격리 수준에 따라 Dirty/Non-repeatable/Phantom 방지 |
지속성 (D) | 커밋 결과 영구 보존 | WAL 기록 후 fsync, 체크포인트, 리플리케이션 | 크래시 후 Redo로 커밋 내용 복원 |
ACID 는 " 무결성 보전 " 목표를 네 축 (A/C/I/D) 으로 분해한다. DBMS 는 로그 (Undo/Redo), 동시성 제어 (락/MVCC), 스토리지 보장 (WAL+fsync/복제) 의 조합으로 이를 실현한다.
동작 메커니즘
- 트랜잭션 시작 (Transaction Start)
- 애플리케이션이 DBMS 에
BEGIN
요청을 전송. - **트랜잭션 매니저 (TM)**가 트랜잭션 ID(TxID) 를 생성하고 세션 컨텍스트에 바인딩.
- 트랜잭션 상태를 **활성 (Active)**으로 전환.
- 애플리케이션이 DBMS 에
- DML 실행 & 동시성 제어
- 애플리케이션이
INSERT / UPDATE / DELETE
등 DML 명령 실행. - **트랜잭션 매니저 (TM)**가 해당 연산을 **동시성 제어 모듈 (CC)**에 전달.
- CC 모듈이 Isolation Level 에 따라 락 (Lock) 획득 또는 MVCC 스냅샷 생성.
- 락 획득 성공 시 **버퍼 매니저 (BM)**가 변경된 페이지를 버퍼 캐시에 로드.
- 변경 연산을 수행하고 수정된 데이터는 Dirty Page로 마킹.
- 애플리케이션이
- 로그 기록 (Write-Ahead Logging)
- **트랜잭션 매니저 (TM)**가 변경 사항에 대한 REDO/UNDO 로그를 생성.
- 로그는 **WAL(Log Manager)**에 기록.
- COMMIT 이전에는 로그가 디스크에 바로 플러시되지 않고 버퍼에 존재할 수 있음.
- 커밋 처리 (Commit Processing)
- 애플리케이션이
COMMIT
요청. - TM이 커밋 레코드를 WAL 에 작성.
- Log Manager가 해당 로그를 디스크에 fsync (Group Commit 가능).
- 로그 fsync 가 완료되면 Durability 보장 상태로 전환.
- 애플리케이션이
- 데이터 플러시 & 복제
- **버퍼 매니저 (BM)**는 변경된 페이지를 비동기 플러시(Checkpoint 시점 등) 로 디스크에 반영.
- **Replication Manager(REP)**가 변경 내용을 리플리카 노드로 전파 (동기/비동기 모드 설정 가능).
- 커밋 완료 응답
- 로그 fsync 완료 직후 TM이 애플리케이션에
COMMIT OK
응답. - 애플리케이션은 후속 트랜잭션을 시작할 수 있음.
- 로그 fsync 완료 직후 TM이 애플리케이션에
- 장애 발생 시 복구 절차
- 장애 복구 모듈 (Recovery Manager, RM) 이 로그를 기반으로 Analysis → Redo → Undo 수행.
- Analysis: 장애 시점 트랜잭션 상태 식별.
- Redo: 커밋 완료된 변경 사항을 재적용.
- Undo: 커밋되지 않은 변경 사항 롤백.
- 장애 복구 모듈 (Recovery Manager, RM) 이 로그를 기반으로 Analysis → Redo → Undo 수행.
이 흐름은 애플리케이션 요청 → 트랜잭션 매니저 → 동시성 제어 → 버퍼 매니저 → 로그 매니저 → 스토리지 계층 순서로 동작하며, Durability 보장 후 응답을 반환하는 구조이다.
sequenceDiagram autonumber participant App as 애플리케이션 participant TM as 트랜잭션 매니저(Txn Manager) participant CC as 동시성 제어(락/MVCC) participant BM as 버퍼 매니저(Buffer Manager) participant LOG as 로그 매니저(WAL) participant STO as 스토리지(Data Files) participant REP as 복제/스토리지 동기화(옵션) participant RM as 복구 매니저(Recovery) %% 트랜잭션 시작 App->>TM: BEGIN TM-->>App: Txn ID 부여 %% DML 실행 loop DML 연산들(INSERT/UPDATE/DELETE) App->>TM: DML 요청 TM->>CC: 격리성 보장 요청(락 획득 또는 스냅샷 확보) CC-->>TM: 허용/대기(경합 시 대기 또는 재시도) TM->>BM: 페이지 읽기/변경(Dirty Page 생성) TM->>LOG: REDO/Undo 로그 레코드 생성(LSN 배정) LOG-->>TM: 로그 수집 OK(아직 fsync 전) TM-->>App: DML 처리 결과 end %% 커밋 경로 App->>TM: COMMIT TM->>LOG: 커밋 레코드 기록 및 fsync(Group Commit 가능) LOG-->>TM: 영속화 보장(지속성: Durability) TM->>BM: 변경 페이지 플러시 스케줄(체크포인트/백그라운드) par 선택: 동기 복제일 때 TM->>REP: 커밋 LSN 전파(ACK 대기) REP-->>TM: 복제 ACK and 비동기 복제일 때 TM->>REP: 커밋 LSN 비동기 전파 end TM-->>App: COMMIT OK %% 롤백 경로(실패 또는 취소) opt 오류/취소 발생 시 App->>TM: ROLLBACK TM->>RM: Undo 수행(로그 기반 되돌리기) RM->>BM: 변경 전 이미지로 복원 TM-->>App: ROLLBACK OK end %% 크래시 리커버리(시스템 재시작 시) opt 재시작 시나리오 RM->>LOG: Analysis 단계(활성 Txn/더티 페이지 파악) RM->>BM: Redo 단계(커밋된 변경 재적용) RM->>BM: Undo 단계(미완료 Txn 되돌리기) RM-->>TM: 일관 상태 복구 완료 end
- 트랜잭션 매니저 (TM): 트랜잭션 ID 발급, 수명주기 관리 (BEGIN/COMMIT/ROLLBACK), 각 모듈 오케스트레이션의 허브 역할.
- 동시성 제어 (CC): 락 또는 MVCC 스냅샷으로 격리성 (Isolation) 보장. 경합 시 대기·재시도·타임아웃 등 정책 수행.
- 버퍼 매니저 (BM): 페이지 캐싱/수정 (Dirty Page), 체크포인트·백그라운드 플러시로 I/O 효율화.
- 로그 매니저 (WAL): 모든 변경의 Redo/Undo 로그를 먼저 기록하고, 커밋 시 fsync로 지속성 (Durability) 확보. Group Commit 로 지연·처리량 균형.
- 스토리지 (STO): 데이터 파일의 최종 영속화. WAL 선기록 규칙 덕분에 데이터 페이지는 지연 플러시여도 안전.
- 복제/스토리지 동기화 (REP, 옵션): 동기 복제 (ACK 후 커밋 보장) 또는 비동기 복제 (지연 전파) 선택으로 RPO/RTO·지연시간 트레이드오프 최적화.
- 복구 매니저 (RM): 재시작 시 ARIES 절차 (Analysis→Redo→Undo) 로 원자성·일관성 회복. 미완료 트랜잭션은 Undo, 커밋된 변경은 Redo.
핵심은 WAL 선기록 + 동시성 제어 + 지연 플러시/복제의 조합이다. 커밋 시점에는 로그 영속화가 최우선, 데이터 페이지는 이후 배치 플러시로 처리된다. 이렇게 모듈별 책임을 분리해 ACID 의 A/C/I/D를 체계적으로 달성한다.
아키텍처 및 구성 요소
flowchart TB subgraph APP["애플리케이션 계층"] A[애플리케이션] end subgraph TMX["트랜잭션 계층"] TM[Transaction Manager] CC["Concurrency Manager\n(Lock/MVCC)"] RM[Recovery Manager] LM["Log Manager (WAL)"] end subgraph BUF["저장소 계층"] BM[Buffer Manager] DS[(Data/Index Files)] end subgraph OPT["선택 컴포넌트"] DLD[Deadlock Detector] CKP[Checkpoint Manager] COOR["Dist. Txn Coordinator (2PC)"] REPL[Replication/Consensus] end A -->|BEGIN/Query| TM TM -->|isolation/plan| CC CC -->|latch/lock or snapshot| BM TM -->|log write intent| LM LM -->|WAL fsync| DS BM -->|page read/write| DS RM -->|ARIES controls| LM CKP -->|flush dirty set| BM DLD -->|detect/resolve| CC COOR -->|prepare/commit| TM REPL -->|sync/commit quorum| DS %% 커밋 경로(요약) TM -.commit txns.-> LM -.force log.-> DS TM -.release/isolation.-> CC -.unfix.-> BM
- Commit 경로:
TM → LM(WAL fsync) → DS
순으로 D(지속성) 확보 후 락/스냅샷 해제로 I(격리) 종료.
- Crash 후:
RM
이 WAL 로 A(원자성) 및 C(일관성) 복구 (Analysis/Redo/Undo). - 분산 커밋:
COOR
가 2PC prepare/commit,REPL
이 동기 복제로 내구성 강화.
구성 요소
구분 | 구성 요소 | 설명 | 주요 역할·기능 | ACID 기여 | 특징 |
---|---|---|---|---|---|
필수 | Transaction Manager | 트랜잭션 생명주기 관리 | 시작/커밋/롤백, 상태추적, 타임아웃 | A, C | Savepoint, 자동 재시도 정책 연계 |
필수 | Concurrency Manager (Lock/MVCC) | 격리 구현 계층 | 2PL 락 (S/X/IS/IX), MVCC 스냅샷/가시성 | I, C | 워크로드별 2PL↔MVCC 선택/혼용 |
필수 | Log Manager (WAL) | 변경 이전에 로그 기록 | Redo/Undo 로그, LSN, fsync | A, D | Write-ahead, 그룹 커밋 |
필수 | Buffer Manager | 버퍼 캐시/페이지 관리 | 페이지 fix/unfix, 교체 정책 | A, D, 성능 | LRU/Clock, 핫셋 캐싱 |
필수 | Recovery Manager | 장애 후 일관성 회복 | ARIES(Analysis/Redo/Undo) | A, C, D | Fuzzy checkpoint, 손상 페이지 격리 |
필수 | Storage (Data Files/Index) | 영속 데이터 저장 | 페이지/세그먼트 관리, 인덱스 I/O | D | WAL 과 순서 보장, CRC 등 무결성 |
선택 | Deadlock Detector | 교착 상태 탐지/해결 | Wait-for graph, 희생자 강제 롤백 | I, 가용성 | 낮은 오버헤드 주기 검사 |
선택 | Checkpoint Manager | 복구 단축/로그 절감 | 주기적 체크포인트/더티 페이지 플러시 | D, 성능 | Fuzzy 방식으로 작업 지연 최소화 |
선택 | MVCC Engine (전용) | 멀티버전 관리 | 버전 체인/가비지 수집/시점 읽기 | I | 고동시성 읽기, GC 튜닝 필요 |
선택 | Dist. Txn Coordinator (2PC) | 분산 트랜잭션 조정 | prepare/commit, 참가자 투표 | A, C | 로그 기반 재시도, 장애 시 보상 |
선택 | Replication/Consensus | 고가용성·내구성 강화 | 동기 복제, 리더 선출 (Raft/Paxos) | D, C | RPO/RTO 목표 충족 |
선택 | Audit/Capture | 변경 이력/감사 | CDC 스트림, 감사 로그 | C | 규제/컴플라이언스 대응 |
주요 기능과 역할
ACID 속성 | 핵심 기능 | 구현 메커니즘 | 역할 |
---|---|---|---|
Atomicity (원자성) | 트랜잭션 전체 성공 또는 전체 실패 보장 | 트랜잭션 로그 (WAL), Undo/Redo, Savepoint, Rollback | 부분 완료 방지, 오류 시 복구로 일관성 유지 |
Consistency (일관성) | 데이터 무결성 및 규칙 준수 | 스키마 제약조건, 트리거, 참조 무결성 (FK), 비즈니스 로직 검증 | 유효한 상태만 데이터베이스에 반영 |
Isolation (격리성) | 트랜잭션 간 상호 간섭 방지 | MVCC, 2PL, Row/Key Lock, Isolation Level 설정 | 동시성 제어로 Consistency 유지 및 Dirty/Phantom Read 방지 |
Durability (지속성) | 커밋된 데이터 영구 저장 | WAL, 체크포인트, 동기 복제, 저널링 파일 시스템 | 장애 이후에도 데이터 보존 및 복구 |
Recovery System (복구) | 장애 시 데이터 일관성 복구 | ARIES(분석→REDO→UNDO), 백업/복원, 리플리케이션 로그 | Atomicity·Durability 보완, 비정상 종료 후 복원 |
Concurrency Control (동시성 제어) | Isolation 구현 및 성능 최적화 | Lock Manager, Optimistic CC, Timestamp Ordering | 동시 처리 성능 유지와 무결성 보장 |
ACID 주요 기능 상호 관계
기능 요소 | 관련 ACID 속성 | 상호 관계 |
---|---|---|
트랜잭션 매니저 | Atomicity, Consistency | 트랜잭션 경계 관리 (시작·커밋·롤백), 원자성 보장으로 일관성 검증 기반 마련 |
동시성 제어 모듈 | Isolation, Consistency | MVCC·락으로 트랜잭션 간 간섭 방지, 일관성 유지 지원 |
컨시스턴시 엔진 | Consistency | 제약조건·비즈니스 규칙 검증, Atomicity 와 함께 데이터 무결성 보장 |
로그/저장소 | Durability, Atomicity | 변경사항 기록 (WAL), 장애 시 복구 가능, 커밋 이후 데이터 영속성 확보 |
복구 모듈 | Durability, Atomicity, Consistency | 장애 후 데이터베이스 복원, 트랜잭션 상태 정합성 회복 |
- Atomicity는 Rollback 과 트랜잭션 로그로, Consistency는 스키마 제약과 비즈니스 규칙으로, Isolation은 락·MVCC 로, Durability는 WAL 과 복제 기술로 보장한다.
- 각 기능은 독립적으로 존재하지만, 예를 들어 Atomicity 보장이 Consistency 유지의 전제가 되고, Isolation 이 없으면 Consistency 가 깨질 수 있으며, Durability 는 Atomicity 완료 이후에만 의미가 있다.
- 복구 시스템과 동시성 제어는 모든 ACID 속성을 보완하는 핵심 기반이며, 이들의 조합이 트랜잭션 안정성을 만든다.
단일 DB vs. 분산 DB 환경별 ACID 기능·역할 변화
ACID 속성 / 기능 요소 | 단일 DB 환경 | 분산 DB 환경 | 설계 변화 포인트 | 대안·보완 패턴 |
---|---|---|---|---|
Atomicity (원자성) | 로컬 트랜잭션 로그 (WAL), Undo/Redo 기반 원자성 보장 | 다중 노드 간 트랜잭션 원자성 확보 필요, 네트워크 지연·부분 실패 가능 | 2PC(2-Phase Commit) 또는 3PC, 네트워크 타임아웃 설계 | Saga 패턴, TCC(Try-Confirm/Cancel), Outbox 패턴 |
Consistency (일관성) | 단일 인스턴스에서 스키마·제약조건으로 일관성 보장 | 분산 환경에서는 노드별 복제 지연·네트워크 분할로 인한 일관성 깨짐 가능 | 최종 일관성 (Eventual Consistency) 허용 여부 결정 | BASE 모델 도입, CRDT(Conflict-free Replicated Data Type), 데이터 검증 파이프라인 |
Isolation (격리성) | MVCC, 2PL 로 안정적 구현 가능 | 분산 트랜잭션에서 락 유지가 장시간 필요 → 성능 저하 위험 | 락 범위 최소화, 분산 락 서비스 (Redis/ZooKeeper) 활용 | Snapshot Isolation, Logical Sharding, Read/Write Quorum |
Durability (지속성) | WAL·체크포인트·단일 스토리지 복제 | 노드 간 동기 복제 또는 비동기 복제 선택 필요 | 동기 복제는 낮은 RTO, 높은 지연 / 비동기 복제는 낮은 지연, 높은 데이터 손실 위험 | Raft/Paxos 합의 기반 로그 복제, 멀티 AZ/Region 복제 |
Recovery System (복구) | 단일 노드 장애 시 WAL 기반 복구 | 다중 노드 장애·네트워크 분할 복구 복잡 | 장애 노드 복구 시 데이터 재동기화 전략 필요 | Anti-entropy Sync, Leader-Follower 재선출, Incremental Snapshot |
Concurrency Control (동시성 제어) | 단일 Lock Manager, 로컬 MVCC | 분산 락 서비스 필요, 네트워크 지연 시 성능 하락 | 글로벌 락 최소화, 노드별 독립 트랜잭션 설계 | Optimistic Concurrency Control, Vector Clock, Versioned Writes |
- 단일 DB는 ACID 구현이 단순하며 DBMS 내부 기능으로 대부분 해결 가능하지만, 분산 DB는 네트워크 지연·노드 장애·복제 지연 등 외부 요인이 복잡하게 얽힘.
- Atomicity와 Consistency는 분산 환경에서 2PC 같은 강한 방법보다 Saga/TCC 같은 비동기 보상 패턴으로 대체되는 경우 많음.
- Isolation은 락 기반보다는 스냅샷 격리 (SI)·쿼럼 읽기/쓰기 같은 분산 친화적 방법이 선호됨.
- Durability는 Raft/Paxos 합의 알고리즘, Cross-Region 복제로 보장하며, 비용과 지연 간 균형 필요.
- 복구와 동시성 제어는 단일 환경보다 복잡도가 크게 증가하므로, 아키텍처 설계 초기부터 장애·성능 시뮬레이션이 필수.
특성 분석 (Characteristics Analysis)
장점 및 이점
ACID 속성은 데이터베이스 트랜잭션의 안정성, 무결성, 신뢰성을 보장하며, 개발자와 운영자가 데이터 정합성 문제 없이 안정적으로 시스템을 운영할 수 있게 한다.
구체적으로는 데이터 무결성과 신뢰성 유지, 장애 시 복구 용이성, 안전한 동시성 제어, 비즈니스 규칙 준수, 개발 복잡성 감소, 규제 준수 지원 등의 이점을 제공한다.
또한 트랜잭션 격리수준 조정을 통해 성능과 정합성 간의 균형을 조절할 수 있고, 멀티테넌트 환경에서 데이터 보호가 용이하며, 오류를 트랜잭션 단위로 국소화할 수 있다.
구분 | 항목 | 설명 | 기술적 근거 |
---|---|---|---|
장점 | 데이터 무결성·신뢰성 보장 | 실패·경쟁 상황에서도 데이터 정합성 유지 | Atomicity, Consistency, WAL |
장점 | 장애 복구 용이성 | 장애 후 로그 기반으로 빠른 복구 가능 | WAL, ARIES 알고리즘 |
장점 | 안전한 동시성 제어 | 다중 사용자 환경에서 데이터 충돌 방지 | Isolation, MVCC, Lock |
장점 | 비즈니스 규칙 준수 | 스키마·제약조건·검증 로직으로 업무 규칙 자동 보장 | Consistency, Constraint, Trigger |
장점 | 개발 복잡성 감소 | ACID 가 동시성·장애 처리 추상화하여 비즈니스 로직 집중 가능 | 트랜잭션 경계, DB 엔진 보장 |
장점 | 규제·컴플라이언스 지원 | 감사·법적 요구 사항 대응에 필요한 트랜잭션 기록·로그 제공 | 트랜잭션 로그, 감사 로그 |
장점 | 예측 가능한 성능 보장 | 격리 수준 조절로 성능과 정합성 간 균형 유지 가능 | ANSI 격리 수준 조정 |
장점 | 멀티테넌트 환경 지원 | 데이터 격리·보호 용이, 테넌트 간 간섭 최소화 | 스키마 분리, 접근 제어 |
장점 | 오류 국소화 | 트랜잭션 단위 롤백으로 장애 영향 최소화 | Atomicity, Rollback |
ACID 의 장점은 데이터 무결성과 신뢰성 확보, 장애 복구 능력, 동시성 제어 안정성이 핵심이며, 이를 통해 금융·공공·대규모 서비스 환경에서도 안전한 데이터 처리가 가능하다.
또한 개발 생산성 향상, 비즈니스 규칙 강제, 규제 준수를 지원하고, 성능 - 정합성 균형 조절과 멀티테넌트 지원 같은 확장성 측면에서도 강점을 가진다.
특히 오류를 트랜잭션 단위로 제한하여 시스템 전체의 안정성을 높인다.
단일 DB → 분산 DB 전환 시 ACID 속성별 설계 변화 비교
속성 (ACID) | 단일 DB 에서의 장점 | 분산 DB 전환 시 변화/리스크 | 보완 설계·대안 패턴 |
---|---|---|---|
Atomicity (원자성) | 단일 트랜잭션 경계에서 All-or-Nothing 보장 용이 (WAL/로그로 롤백 간단) | 노드·파티션 간 부분 실패/부분 커밋 위험, 분산 롤백 복잡 | 2PC/3PC(필요 시), SAGA(보상 트랜잭션), Outbox/Inbox, 멱등 처리, 트랜잭션 경계의 도메인 재설계 |
Consistency (일관성) | 스키마 제약·트리거로 강한 일관성 즉시 보장 | 네트워크 지연/파티션으로 전역 강일 보장 비용↑ → 일시적 불일치 가능 | 강일/최종 일관성 선택(요구별), CQRS, CRDT(충돌 자동해결 도메인), 검증을 앱 레벨로 승격, 리드 리플리카 정합성 정책 (RPO/RTO) |
Isolation (격리성) | 2PL/MVCC 로 ANSI 격리수준 제공, 현상 (Dirty/Phantom) 관리 용이 | 글로벌 락/버전 동기화 비용 증가, 지연과 핫샤드로 처리량 저하 | 격리수준 완화(Read Committed/RC+), 파티션 단위 트랜잭션, 분산 락 서비스(ZooKeeper/etcd), 버전 기반/낙관적 동시성, Hot key 분산 (샤딩·키 리라이트) |
Durability (지속성) | 단일 노드 WAL+ 체크포인트로 커밋 내구성 명확 | 다중 노드 복제 지연·스플릿 브레인·영구 손실 위험 (합의 실패 시) | 합의형 복제 (Raft/Paxos), 동기/준동기 복제 정책, 커밋 퀘럼 정의, 글로벌 체크포인트, 다중 AZ/리전 배치, 백업·Point-in-Time Recovery |
단점 및 제약사항과 해결방안
- ACID 구현은 데이터 무결성과 신뢰성을 보장하지만, 성능·확장성·가용성·운영 복잡성의 대가가 따른다.
- 성능 저하는 락 관리, 버전 관리, 로그 기록 등에서 발생하며, 그룹 커밋·낙관적 동시성 제어·격리 수준 완화로 완화 가능하다.
- 분산 환경에서는 글로벌 일관성 유지가 확장성을 제한하므로, SAGA·Eventual Consistency 등 대안이 필요하다.
- Deadlock·Lock 경합은 락 순서 규약, 타임아웃, MVCC 등으로 완화한다.
- 장기 트랜잭션은 OLTP 부하를 악화시키므로, 트랜잭션 분할·배치화가 필요하다.
- Phantom Read·Lost Update 같은 이상 현상은 Serializable, SSI, 버전 필드 검증으로 방지한다.
- 스토리지나 로그 I/O 실패 시 Durability 가 깨질 수 있어, 안정적 하드웨어·WAL 정책 조정·복제 구성이 필요하다.
구분 | 항목 | 원인 | 영향 | 탐지/진단 | 예방 방법 | 해결 기법 / 대안 |
---|---|---|---|---|---|---|
단점 | 성능 오버헤드 | 락/버전 관리, 로그 I/O | 처리 지연, TPS 저하 | 성능 모니터링 | 격리 수준 완화, 배치/그룹 커밋 | MVCC, 낙관적 CC |
단점 | 확장성 제약 | 글로벌 일관성 유지 비용 | 분산 환경 성능 저하 | Throughput 측정 | 샤딩 + 로컬 트랜잭션 | SAGA, Eventual Consistency |
단점 | 가용성 트레이드오프 | CAP 정리상 Consistency 우선 | Failover 지연, 서비스 중단 | 장애 시나리오 테스트 | 지역 일관성 적용 | BASE 모델, Regional Consistency |
문제점 | Deadlock / Lock 경합 | 순환 대기, 자원 경합 | 트랜잭션 중단, 대기 증가 | Deadlock Detector, 대기 큐 모니터 | 락 순서 규약, 락 범위 축소 | 타임아웃, MVCC |
문제점 | 장기 트랜잭션 | 장시간 자원 점유 | Blocking, 메모리 점유 | 트랜잭션 시간 로깅 | 트랜잭션 분리, 배치 처리 | 강제 종료, 체크포인트 |
문제점 | 일관성 이상 현상 | Phantom Read, Lost Update | 잘못된 데이터 반환/갱신 | Isolation Test, Audit Log | Serializable, 버전 필드 체크 | SSI, OCC |
문제점 | 스토리지/로그 실패 | fsync 지연/실패 | Durability 약화 | 로그 무결성 검사 | 안정적 스토리지, 배터리 캐시 | WAL 정책 조정, 로그 복제 |
ACID 는 높은 데이터 신뢰성을 제공하지만, 락·로그·버전 관리로 인한 성능 저하, 글로벌 일관성의 확장성 한계, CAP 에 따른 가용성 손실, Deadlock 과 장기 트랜잭션, 일관성 이상 현상, 그리고 스토리지 I/O 실패 시 Durability 약화 등의 문제가 발생할 수 있다. 이를 해결하려면 격리 수준 조정, MVCC·OCC·SAGA·Eventual Consistency 같은 대안 적용, 락 순서 규약, 배치·그룹 커밋, 안정적 스토리지와 WAL 정책 최적화 등 종합적 접근이 필요하다.
트레이드오프 관계 분석
비교 항목 | A 선택 시 장점 | A 선택 시 단점 | B 선택 시 장점 | B 선택 시 단점 | 고려 기준 |
---|---|---|---|---|---|
격리성 vs 동시성 | 높은 격리 (Serializable) 로 직관적 일관성, 오류 방지 | 락 경합·대기, 처리량 저하 | 낮은 격리로 처리량↑, 지연↓ | 비일관 상태 가능, 앱 보정 필요 | 데이터 무결성 vs 처리 성능 우선순위 |
일관성 vs 성능 | 강한 일관성으로 트랜잭션 후 데이터 무결성 보장 | 제약 조건·검증 오버헤드로 성능 저하 | 약한 일관성으로 성능↑ | 일시적 불일치 가능 | 규제·금융 등 강일관 필요 여부 |
지속성 vs 응답성 | 동기 WAL/복제로 데이터 안전 | I/O 대기 증가, 응답 지연 | 비동기 기록으로 응답 빠름 | 장애 시 데이터 유실 위험 | RPO/RTO 목표, 데이터 가치 |
ACID vs 확장성 | ACID 유지로 강일관성·신뢰성 확보 | 2PC/3PC 지연, 네트워크 부담 | BASE/SAGA 로 확장·가용성↑ | 강일관성 손실 | 분산 환경, 트랜잭션 범위 |
락 vs MVCC | 단순, 메모리 효율↑ | 경합 시 대기 발생 | 읽기 동시성↑ | 버전 관리 비용 | 읽기 vs 쓰기 비중 |
즉시 커밋 vs Group Commit | 지연 없음 | I/O 빈번, 처리량↓ | 배치 처리로 처리량↑ | 커밋 지연 발생 | 응답 지연 허용 범위 |
ACID 속성 간에는 안전성과 성능·확장성 사이의 본질적 균형 조정이 필요하다.
높은 격리·강한 일관성·동기 지속성은 데이터 신뢰성을 보장하지만, 성능 저하와 확장성 한계를 유발한다.
반대로 낮은 격리·약한 일관성·비동기 지속성·BASE 모델은 처리량과 가용성을 높이지만, 데이터 무결성 위험을 감수해야 한다.
결국 업무 특성, 규제 요건, SLA에 맞춰 설계해야 하며, 2PC/3PC·SAGA·MVCC·Group Commit 등 구현 전략의 장단점을 이해하고 선택하는 것이 핵심이다.
구현 및 분류 (Implementation & Classification)
구현 기법 및 방법
분류 | 기법 | 정의 | 구성 요소 | 원리 | 목적 | 사용 상황 | 특징 |
---|---|---|---|---|---|---|---|
동시성 제어 | 2PL(보수적/강 2PL) | 락 획득→해제 2 단계로 직렬가능성 보장 | 공유/배타 락, 락 매니저 | Growing/ Shrinking, 필요 자원 선점 (보수적) | Serializable 보장 | 강한 일관성·충돌 빈번 | 데드락 가능, 쓰기 - 쓰기 충돌에 강함 |
동시성 제어 | MVCC(=Snapshot Isolation) | 버전 체인으로 " 읽기 - 쓰기 " 비차단 | TxID, 가시성 규칙, Undo/버전 저장 | 각 트랜잭션에 일관된 스냅샷 제공 | 읽기 성능·동시성 향상 | 읽기 많은 OLTP | 팬텀/갱신충돌은 엔진별 처리 (SSI 등) |
복구/저장 | WAL(+ARIES) | " 로그 먼저, 데이터 나중 " 선기록 | WAL 로그, LSN, 체크포인트 | Commit 시 로그 fsync, 복구는 Analysis→Redo→Undo | Durability·원자성 | 대부분 RDBMS | 그룹 커밋과 궁합, 로그 I/O 민감 |
복구/저장 | 섀도 페이징 | 페이지 사본에 갱신 후 원자적 스위치 | 페이지 맵, 섀도/현재 버전 | 커밋 시 포인터 전환 | 단순 원자성/복구 | 임베디드/학습용 | 랜덤 쓰기↑, GC 부담 |
분산 트랜잭션 | 2PC(XA) | 노드 간 원자 커밋 | 코디네이터/파티시펀트 | Prepare→Commit/Abort | 분산 Atomicity | 다중 DB/서비스 | 코디네이터 장애 취약, 지연↑ |
성능/운영 | 그룹 커밋 | 여러 커밋을 한 번에 fsync | 로그 버퍼, 플러시 정책 | 짧은 기간 커밋 집계→단일 fsync | TPS 향상 | 쓰기 많은 OLTP | 지연↔처리량 트레이드오프 |
- 인덱스 로그 (ARIES/IM): ARIES 의 페이지·인덱스 수준 REDO/UNDO 로깅. 앱 코드 예시보다는 엔진 내부 최적화로, WAL 범주에서 함께 이해 (인덱스 분할/삭제 등도 로그로 복구).
2PL (PostgreSQL, Python/psycopg)
|
|
- 핵심:
FOR UPDATE
로 행 락을 획득 (2PL 의 Growing), 커밋 시 해제 (Shrinking).
MVCC / Snapshot Isolation (PostgreSQL, Python/psycopg)
|
|
- Readers don’t block writers 예시. TxA 는 스냅샷 일관성 유지.
WAL (SQLite, Python)
|
|
- WAL 의 선기록 - 후반영을 앱 수준에서 체감 가능한 형태로 시연.
2PC (PostgreSQL, 순수 SQL 스크립트)
- Prepare → (All OK?) → Commit Prepared. 코디네이터 장애 시 준비된 트랜잭션 정리 필요.
섀도 페이징 (개념 데모, Python: 파일 스왑)
|
|
- 사본에서 수정→원자적 스위치: 실패 시 원본 유지 (원자성 확보), 성공 시 새 버전 활성화.
그룹 커밋 (Go, 배치 커밋 큐)
|
|
- 다수 커밋을 주기/개수 기준으로 배치해 한 번의 플러시로 처리.
분류 기준에 따른 유형 구분
분류 기준 | 유형 | 특징 | 대표 시스템/기술 | 적용 시나리오 |
---|---|---|---|---|
격리 수준 | Read Uncommitted (RU) | 커밋 전 데이터 읽기 가능, Dirty Read 발생 | 일부 NoSQL, 구형 DB 옵션 | 성능 우선, 데이터 정확성 낮은 로그 분석 |
Read Committed (RC) | 커밋된 데이터만 읽기, Non-repeatable Read 가능 | PostgreSQL, Oracle 기본 | 대부분의 온라인 트랜잭션 처리 (OLTP) | |
Repeatable Read (RR) | 동일 트랜잭션 내 동일 쿼리 결과 보장, Phantom 가능 | MySQL(InnoDB 기본) | 금융·재고 관리 등 정합성 높은 업무 | |
Serializable (S) | 완전한 직렬 실행 보장, 성능 저하 | 일부 OLTP, 테스트 환경 | 강한 일관성 필수 업무 | |
동시성 제어 | Pessimistic Lock | 잠금 기반, 충돌 방지, 지연 발생 가능 | SQL Server, DB2 | 충돌 가능성 높은 환경 |
Optimistic CC | 버전 기반, 충돌 시 롤백, 지연 최소화 | PostgreSQL, Oracle | 충돌 가능성 낮고 읽기 비중 높은 환경 | |
2PL | 락 점유 후 해제, 데드락 가능 | 일부 상용 RDBMS | 강한 정합성 보장 환경 | |
MVCC | 스냅샷 읽기, 높은 읽기 성능, 버전 관리 필요 | PostgreSQL, InnoDB | 읽기·쓰기 혼합 환경 | |
구조/환경 | 단일 DB 트랜잭션 | 단일 인스턴스 내 트랜잭션 | MySQL, PostgreSQL | 단일 리전·작은 규모 |
분산 트랜잭션 | 여러 노드/DB 跨 ACID 보장 | Spanner, CockroachDB | 글로벌 일관성 필요 환경 | |
일관성 모델 | 강한 일관성 | 즉시 일관성, 높은 비용 | 전통적 RDBMS | 금융, 주문 처리 |
최종 일관성 | 지연된 일관성, 높은 가용성 | DynamoDB, Cassandra | SNS 피드, 콘텐츠 배포 | |
복구 기법 | WAL | 로그 선기록, 커밋 안전성 보장 | PostgreSQL, MySQL(InnoDB) | 대부분 RDBMS |
ARIES | WAL 기반, 분석→REDO→UNDO 단계 복구 | IBM DB2, SQL Server | 대규모 트랜잭션 복구 |
이 분류표는 ACID 속성 구현 시 선택할 수 있는 격리 수준, 동시성 제어 기법, 구조, 일관성 모델, 복구 기법을 비교해 각 환경과 요구사항에 맞는 설계를 도출하는 데 도움을 준다.
단일 DB 환경에서는 강한 일관성과 높은 격리 수준을 적용하기 쉽지만, 분산 DB 환경에서는 성능과 가용성을 위해 격리 수준 완화, 최종 일관성, 낙관적 동시성 제어를 선택하는 경우가 많다.
복구 기법은 WAL 이 기본이며, 대규모·고성능 복구에는 ARIES 가 활용된다.
실무 적용 (Practical Application)
실제 도입 사례
도메인 | 핵심 트랜잭션/불변식 | 대표 조합 기술 | 기대 효과 (지표) | 설계 포인트 |
---|---|---|---|---|
금융 결제/이체 | 차감=가산, 이중기입 원장 보존 | 2PL 또는 SSI, Sync WAL, 동기 복제, 필요 시 좁은 2PC | 무결성 100%, 이중지급 0, 감사 용이 | 트랜잭션 짧게, 데드락 탐지, 멱등성 키 |
전자상거래 (주문·재고·결제) | 주문=결제=재고 차감 일관 | 단일 DB: ACID 원트랜잭션 / MSA: SAGA+Outbox+ 멱등 | 과판매↓, 실패 시 자동 보상 | 재고는 수량형 조건 (≥0), 보상 트랜잭션 명세 |
의료 (EMR/처방) | 환자기록/처방 원자 갱신 | 고격리 (Serializable/RR+ 검증), 감사 로그, 백업/복제 | 안전성↑, 규제 준수 | 변경 이력 불변 저장, 접근 통제 |
핀테크 원장/포인트 | 원장 불변식, 중복 차감 방지 | SSI/Serializable, 멱등 API, 리플레이 프로텍션 | 정합성↑, 분쟁 처리 용이 | 고가용 복제, 정밀 감사 |
게임/인앱 구매 | 결제 승인↔아이템 지급 일관 | ACID(내부) + 외부영수증 검증, SAGA(환불/회수) | 유실/중복 지급 0 | 지급 전 검증, 보상 루틴 확정 |
물류/재고 동기화 | 창고 간 예약/차감 일관 | 낙관적 락킹 + 조건부 업데이트, 또는 락 기반 | 과예약 방지, 재고정확도 | 재시도/충돌 해결 정책 |
분산 DB(글로벌) | 지리 분산 ACID | 분산 시계/합의, 2PC, 동기 복제 | 강 일관성 | 지연↑ 수용, 파티션 전략 |
데이터 레이크하우스 | 스트리밍 + 배치 ACID | Delta/Iceberg(스냅샷), 트랜잭션 로그 | 스냅샷 일관, 롤백 | 스키마 진화/머지 정책 |
IoT 과금/집계 | 컷오버 원자 스냅샷 | Exactly-once+ 트랜잭션 메타, 스냅샷 격리 | 이중 과금 0 | 시간창/윈도 보정, 재처리 안전 |
- 강 ACID vs 확장성: 돈/의료처럼 불변식 위반 비용이 큰 도메인은 지연·처리량을 희생하더라도 강 ACID 가 정답.
- 마이크로서비스: 경계 넘는 작업은 2PC 비용·복잡도가 커지므로 SAGA/Outbox/멱등으로 설계하는 편이 운영 난이도·성능 균형이 좋다.
- 격리 선택: 읽기 비중이 높고 리포팅이 많다면 MVCC + RC/RR가 효율적. 재고/원장처럼 쓰기 충돌이 핵심이면 락 기반 + 짧은 트랜잭션이 유리.
- 복구/감사: 금융·의료·원장은 ** 감사 로그 (불변 이벤트 스트림)** 가 실무 필수. WAL 만으로는 규제 증적에 부족할 수 있어 CDC/감사 테이블을 병행한다.
- 운영 지표: p95 커밋 지연, 데드락율, 재시도율, 보상 트랜잭션 비율, 멱등키 충돌률, LSN 라그 등을 상시 모니터링하면 품질이 빠르게 안정된다.
실습 예제 및 코드 구현
사례: 전자 상거래 플랫폼 (장바구니 → 주문 확정)
시나리오: 장바구니 → 주문 확정 (재고 차감 포함) 을 단일 DB 에서 ACID 로 처리
시스템 구성:
- API 서버, PostgreSQL, WAL 동기화 스토리지
graph TB Client --> API[Order API] API --> PG[(PostgreSQL)] PG --> LOG[WAL/Commit Log]
Workflow:
- BEGIN
- 재고 확인 및 잠금
- 주문 레코드 작성
- 결제 승인 코드 기록
- 커밋 (로그 플러시)
핵심 역할: ACID 로 일관성·원자성·지속성 보장, 격리수준은 READ COMMITTED
또는 REPEATABLE READ
.
유무에 따른 차이점:
- 도입 전: 동시성 시 재고 음수/이중 주문 위험
- 도입 후: 일관성 보장, 실패 시 전부 롤백
구현 예시 (Python + psycopg2):
|
|
구현 예시 (Node.js + pg):
|
|
사례: 온라인 도서 구매 시스템
시나리오: 온라인 도서 구매 시스템에서 책 주문 처리
시스템 구성:
- 고객 관리 서비스
- 재고 관리 서비스
- 결제 처리 서비스
- 주문 관리 서비스
graph TB A[고객] --> B[주문 서비스] B --> C[재고 확인] B --> D[결제 처리] B --> E[주문 생성] C --> F[재고 DB] D --> G[결제 DB] E --> H[주문 DB] subgraph "ACID 트랜잭션 경계" C D E end
Workflow:
- 고객이 책 주문 요청
- 재고 확인 및 예약
- 결제 정보 검증 및 차감
- 주문 정보 생성 및 저장
- 모든 단계 성공 시 COMMIT, 실패 시 ROLLBACK
핵심 역할:
- Atomicity: 재고 차감, 결제, 주문 생성이 모두 성공하거나 모두 실패
- Consistency: 재고 수량이 음수가 되지 않고, 결제 금액이 정확함
- Isolation: 동시 주문 시 재고 중복 할당 방지
- Durability: 주문 완료 후 시스템 장애에도 주문 정보 보존
유무에 따른 차이점:
- 도입 전: 부분 실패로 인한 재고 불일치, 중복 결제, 데이터 손실
- 도입 후: 완전한 주문 처리 보장, 데이터 일관성 유지, 고객 신뢰도 향상
구현 예시 (Python/PostgreSQL):
|
|
사례: 은행 계좌 이체
시나리오: 은행 계좌 이체 (보낸 사람/받는 사람 동시 처리)
시스템 구성:
- Application Server(트랜잭션 로직)
- RDBMS(트랜잭션 지원 DB: PostgreSQL)
graph TB Client --> AppServer AppServer --> DB[PostgreSQL DB with ACID]
Workflow:
- 트랜잭션 시작 (BEGIN)
- 출금 계좌 차감
- 입금 계좌 증액
- 정상 처리 시 COMMIT, 오류 발생 시 ROLLBACK
핵심 역할:
- 트랜잭션의 원자성과 일관성을 보장
유무에 따른 차이점:
- 도입 전: 네트워크 끊김 등 장애 발생 시 일부 데이터만 반영 → 데이터 불일치
- 도입 후: 부분 처리 방지, 모든 작업이 완전히 반영/완전 복구
구현 예시 (Python/SQLAlchemy)
|
|
사례: 전자상거래에서 주문 처리 시스템
시나리오: 아마존 스타일 전자상거래에서 주문 처리 시스템
시스템 구성:
- 분산 마이크로서비스 아키텍처
- PostgreSQL (주문/재고), Redis (세션), 메시지 큐
graph TB A[사용자] --> B[API Gateway] B --> C[주문 서비스] C --> D[재고 서비스] C --> E[결제 서비스] C --> F[배송 서비스] D --> G[(재고 DB)] E --> H[(결제 DB)] F --> I[(배송 DB)] C --> J[(주문 DB)] C --> K[메시지 큐] K --> L[알림 서비스] K --> M[분석 서비스]
Workflow:
- 사용자 주문 요청 접수
- 분산 트랜잭션으로 재고 예약
- 결제 처리 및 승인
- 주문 확정 및 배송 준비
- 비동기로 알림 및 분석 데이터 전송
핵심 역할:
- 분산 ACID: 마이크로서비스 간 일관성 보장
- Saga 패턴: 긴 트랜잭션의 분할 및 보상 처리
- 최종 일관성: 실시간이 아닌 데이터의 지연된 동기화
유무에 따른 차이점:
- 도입 전: 서비스 간 데이터 불일치, 부분 실패로 인한 비즈니스 손실
- 도입 후: 마이크로서비스 환경에서도 데이터 일관성 보장, 사용자 경험 향상
구현 예시 (Python/분산 환경):
|
|
사례: 은행 계좌 이체 시스템
시스템 구성
- 코어뱅킹 시스템 (Core Banking System)
- 계좌 관리 데이터베이스
- 거래 로그 시스템
- 실시간 모니터링 시스템
시스템 구성 다이어그램
graph TB subgraph "프레젠테이션 계층" A[모바일 앱] B[웹 인터페이스] C[ATM] end subgraph "비즈니스 로직 계층" D[계좌 이체 서비스] E[인증 서비스] F[알림 서비스] end subgraph "데이터 계층" G[계좌 DB - ACID 보장] H[거래 로그 DB] I[감사 로그] end A --> D B --> D C --> D D --> E D --> F D --> G G --> H G --> I
활용 사례 Workflow
sequenceDiagram participant U as 사용자 participant S as 이체 서비스 participant DB as 계좌 DB participant L as 로그 시스템 U->>S: 이체 요청 (출금계좌, 입금계좌, 금액) S->>DB: BEGIN TRANSACTION S->>DB: 출금계좌 잔액 확인 및 차감 S->>DB: 입금계좌 잔액 증가 S->>L: 거래 로그 기록 alt 모든 연산 성공 S->>DB: COMMIT S->>U: 이체 완료 응답 else 연산 실패 S->>DB: ROLLBACK S->>U: 이체 실패 응답 end
ACID Properties 의 역할
- 원자성: 출금과 입금이 모두 성공하거나 모두 실패
- 일관성: 총 자금량 보존, 계좌 잔액 제약조건 유지
- 고립성: 동시 이체 시 계좌 잔액 충돌 방지
- 지속성: 완료된 이체 거래의 영구적 보존
ACID 유무에 따른 차이점
- ACID 적용 시: 자금 유실 없음, 정확한 잔액 유지, 감사 가능성
- ACID 미적용 시: 부분 이체 발생, 잔액 불일치, 거래 추적 불가
구현 예시:
|
|
운영 및 최적화 (Operations & Optimization)
보안 및 거버넌스
영역 | 항목 | 목적 | 권장 실무 | 주의/메모 |
---|---|---|---|---|
접근통제 | RBAC/ABAC, RLS | 최소권한·행 수준 격리 | 업무 역할별 권한, 테넌트 격리, 승격·만료 자동화 | 과권한 탐지·리뷰 주기화 |
암호화 (전송) | TLS 1.2+/mTLS | 도청·위변조 방지 | 강 암호군/PFS, 인증서 자동 회전 | 내부 트래픽도 mTLS |
암호화 (저장) | TDE/컬럼 암호화 | 유출시 노출 최소화 | PII/결제 컬럼 암호화, 로그·백업 암호화 | 인덱싱 영향·검색 전략 고려 |
키관리 | KMS/HSM | 키 안전·순환 | 회전·폐기·접근감사, 키 분리보관 | 키 삭제=효과적 삭제 전략 |
감사/무결성 | 서명/해시체인·WORM | 위·변조 탐지 | 변경 이벤트 전부 기록, 시간 동기화 | 개인정보 최소화·마스킹 |
네트워크 | 세분망/DBFW | 공격면 축소 | VPC/SG 분리, 최소 포트 | 관리면 분리 (Bastion/VPN) |
애플리케이션 | SQLi/중복방지 | 논리 무결성 | 파라미터 바인딩, 멱등키, 중복 거부 | 재시도 정책과 함께 설계 |
운영 | DR/BCP·백업 | 가용성/복구 | 주기 복구 리허설, RPO/RTO 검증 | 암호화 백업·키 보관 분리 |
모니터링 | 락/데드락/지연 | 조기 탐지 | p95 지연·락 대기·데드락율 경보 | SLO 연결, 자동 진단 |
규정 | GDPR/PCI/SOX | 규제 대응 | 데이터 분류, 보존/삭제, 키관리·감사 | Legal Hold/주권 데이터 |
ACID 보증을 안전하게 운영하려면 권한·암호화·감사 불변성이 기본이고, 여기에 키관리·데이터 분류·보존/삭제·DR/BCP가 더해져야 완성된다. GDPR/PCI/SOX 등 규제는 ACID 자체와 충돌하지 않지만, 삭제권·보존·감사 요구와의 균형을 정책과 기술 (키 삭제·마스킹·WORM) 로 풀어야 한다. 운영에서는 락/데드락·지연·복구 가능성을 지표로 상시 관찰해 품질을 유지하는 게 핵심이다.
모니터링 및 관측성
구분 | 항목 | 정의/설명 | 활용 목적 | 예시 |
---|---|---|---|---|
메트릭 | TPS | 초당 트랜잭션 처리 수 | 처리량 모니터링 | pg_stat_database.xact_commit |
메트릭 | 커밋/롤백 비율 | 커밋 대비 롤백 비율 | 트랜잭션 안정성 평가 | 모니터링 대시보드 |
메트릭 | 데드락 수 | 단위 시간당 데드락 발생 건수 | 동시성 병목 탐지 | pg_stat_database.deadlocks |
메트릭 | 락 대기 시간 | 트랜잭션 락 획득까지 걸린 평균 시간 | 경합도 측정 | Wait Event 분석 |
메트릭 | 평균 응답 시간 | 트랜잭션 완료까지 평균 시간 | SLA 준수 여부 평가 | APM 도구 |
메트릭 | 체크포인트 시간 | 체크포인트 수행에 소요되는 시간 | 복구 성능 최적화 | DB 로그 |
메트릭 | WAL 쓰기 대기 | WAL flush/fsync 대기 시간 | 지속성 병목 확인 | I/O 모니터링 |
메트릭 | IOPS | 읽기/쓰기 초당 I/O 횟수 | 스토리지 성능 모니터링 | OS/스토리지 모니터 |
메트릭 | 활성 스냅샷 수 | MVCC 활성 버전 개수 | 장기 트랜잭션 감지 | MVCC 통계 |
로깅 | 슬로우 쿼리 | 실행 시간 초과 쿼리 기록 | 성능 병목 SQL 식별 | slow query log |
로깅 | 데드락 그래프 | 데드락 발생 시 자원 대기 그래프 | 원인 분석 | DBMS deadlock log |
로깅 | 구조화된 로그 | JSON 등 파싱 가능한 로그 포맷 | 자동 분석 파이프라인 | ELK, Loki |
로깅 | 복구 이벤트 | Crash recovery 시작/종료 기록 | 장애 대응 속도 향상 | DB 로그 |
추적 | 분산 추적 | 트랜잭션 흐름 전 서비스 추적 | 마이크로서비스 병목 파악 | OpenTelemetry |
경보 | 임계치 알림 | 메트릭이 기준 초과 시 알림 | 실시간 대응 | Slack, PagerDuty |
분석 | Wait Events | CPU/I/O/Lock 대기 원인 분류 | 병목 구체화 | Oracle v$session, pg_stat_activity |
분석 | 락 경합률 | 락 타입별 경합 비율 | 동시성 최적화 | 락 모니터링 툴 |
모니터링 및 관측성은 단순 성능 측정이 아니라 장애 예방·원인 분석·실시간 대응을 가능하게 하는 체계이다.
핵심 요소는 다음 세 가지이다.
- 정량 메트릭 → TPS, 응답 시간, 락 대기, WAL 대기, IOPS 등 처리·지속성·동시성 관련 지표를 수집.
- 정성 로깅 → 구조화된 로그, 슬로우 쿼리, 데드락 그래프, 복구 이벤트 등 원인 파악에 필요한 데이터 확보.
- 실시간 추적·경보 → 분산 추적, Wait Events 분석, 임계치 알림을 통한 즉각 대응.
이렇게 구성하면 DBMS 의 ACID 보장 성능을 장기적으로 안정화시키고, 병목과 장애를 신속하게 해결할 수 있다.
실무 적용 고려사항 및 주의점
카테고리 | 고려사항 | 설명 | 권장사항 |
---|---|---|---|
성능 | 트랜잭션 크기 최적화 | 긴 트랜잭션은 락 경합·성능 저하 유발 | 1,000 개 이하 연산, 배치 처리, 그룹 커밋 활용 |
성능 | 적절한 격리 수준 | 과도한 격리는 성능 저하 | 기본 READ COMMITTED, 필요 시만 상향 |
동시성·격리성 | 데드락 방지 | 순환 대기로 인한 무한 대기 | 락 순서 표준화, 타임아웃 설정 |
동시성·격리성 | Lock 경합 완화 | 락 점유 최소화 | MVCC, Optimistic Lock 사용 |
가용성·장애 대응 | 장애 복구 | 시스템 다운 시 신속 복구 | WAL, 체크포인트, 자동 페일오버 |
가용성·장애 대응 | 로그 관리 | 장애 후 복구 기반 | WAL 동기화, 로그 보존 정책 |
확장성 | 샤딩 전략 | 대용량 데이터 분산 처리 | 파티션 키 기반 수평 분할 |
확장성 | 읽기 부하 분산 | 마스터 부하 감소 | Read Replica, 로드 밸런싱 |
보안 | 접근 제어 | 불필요 접근 방지 | RBAC, 최소 권한 원칙 |
보안 | 감사 로깅 | 변경 사항 추적 | Audit Log, 변경 이력 관리 |
분산 트랜잭션 | 분산 환경 복잡성 | 네트워크 지연·부분 실패 가능 | 로컬 트랜잭션 우선, SAGA, Outbox 패턴 |
- 성능: 트랜잭션 범위와 격리 수준 조정이 핵심이며, 배치·그룹 커밋 활용
- 동시성: 데드락 예방과 락 경쟁 완화가 필수
- 가용성: 장애 복구 자동화와 WAL 기반 로그 관리로 신속 복구
- 확장성: 샤딩과 읽기 전용 복제본으로 부하 분산
- 보안: RBAC 와 감사 로깅으로 무결성·컴플라이언스 확보
- 분산 트랜잭션: 로컬 우선, 필요 시 분산 트랜잭션 패턴 활용해 안정성 보장
단일 DB Vs 분산 DB 환경에서의 ACID 속성별 설계 변화 및 대안 패턴 비교
ACID 속성 | 단일 DB 환경 | 분산 DB 환경 전환 시 변화 | 대안 패턴 / 기술 | 적용 사례 |
---|---|---|---|---|
Atomicity (원자성) | 로컬 트랜잭션으로 모든 연산을 단일 인스턴스에서 원자적으로 실행 | 다중 노드에서 원자성 보장 어려움 → 네트워크 장애·부분 실패 가능성 | 2PC(이단계 커밋), 3PC, SAGA 패턴, Outbox 패턴 | 금융 거래, 글로벌 결제 |
Consistency (일관성) | 강한 일관성 보장, DB 제약조건·트리거로 즉시 검증 | 노드 간 데이터 동기 지연 발생 → 스키마·규칙 적용 지연 가능성 | Eventual Consistency, CRDT, Conflict Resolution, CQRS | SNS 피드, 분산 캐시 |
Isolation (격리성) | 높은 격리 수준 (RR, S) 사용 가능, 락 기반 제어 용이 | 글로벌 트랜잭션에서 높은 격리 수준은 성능 저하·락 경합 증가 | Read Committed + Validation, MVCC, 분산락 (ZooKeeper/Etcd) | 재고 관리, 글로벌 주문 |
Durability (지속성) | WAL, 체크포인트로 커밋 후 데이터 영구 저장 | 노드 간 복제 지연, 장애 시 일부 노드 미반영 가능 | 동기/비동기 복제, Write-Ahead Log, Raft/Paxos 합의 | CockroachDB, Spanner |
- 원자성: 단일 DB 에서는 로컬 트랜잭션으로 해결되지만, 분산 DB 는 네트워크·노드 장애에 대응 가능한 분산 트랜잭션 패턴이 필수
- 일관성: 분산 환경에서는 강한 일관성 대신 최종 일관성 모델이나 충돌 해결 전략을 더 자주 채택
- 격리성: Serializable 유지 비용이 크므로 낮은 격리 수준 + 검증 로직으로 절충
- 지속성: 분산 환경에서는 합의 알고리즘과 복제 전략이 핵심 설계 요소
단일 DB Vs 분산 DB 환경별 실무 적용 차이
카테고리 | 고려사항 | 단일 DB 환경 적용 방식 | 분산 DB 환경 전환 시 변화 | 권장 대안 패턴/전략 |
---|---|---|---|---|
성능 | 트랜잭션 크기 최적화 | 단일 인스턴스 내에서 긴 트랜잭션도 성능 영향이 비교적 예측 가능 | 네트워크 지연·복제 지연으로 긴 트랜잭션 성능 저하 심화 | 트랜잭션 단위 축소, 배치 처리, 그룹 커밋 |
성능 | 적절한 격리 수준 | READ COMMITTED 또는 REPEATABLE READ 사용 가능 | 글로벌 격리 보장 시 지연·충돌 증가 | 지역별 낮은 격리 수준 + 중요 경로만 강한 격리 |
동시성·격리성 | 데드락 방지 | 로컬 락 순서 규약, 타임아웃으로 관리 가능 | 분산 락 관리가 복잡, 네트워크 장애로 교착 탐지 지연 | 글로벌 락 최소화, 로컬 리소스 우선 접근 |
동시성·격리성 | Lock 경합 완화 | MVCC, Optimistic Lock 적용 쉬움 | 복제 지연 시 Stale Read 발생 가능 | 버전 기반 동시성 제어, Conflict Resolution 로직 |
가용성·장애 대응 | 장애 복구 | WAL + 체크포인트로 단일 노드 복구 | 다중 노드 장애·네트워크 분할 시 일관성 깨질 위험 | 멀티리전 복제 + 자동 페일오버, DR(재해 복구) 계획 |
가용성·장애 대응 | 로그 관리 | 단일 로그 스트림 관리 용이 | 각 노드 로그 동기화 필요, 복구 시 순서 보장 문제 | 글로벌 시퀀스 넘버, 분산 로그 관리 시스템 |
확장성 | 샤딩 전략 | 필요 시 수평 확장, 비교적 단순 | 필수적, 키 설계 실패 시 불균형 샤드·Hotspot 발생 | 파티션 키 설계, 리밸런싱 자동화 |
확장성 | 읽기 부하 분산 | Read Replica 로 즉시 부하 감소 | 리플리카 지연 (Replication Lag) 으로 최신성 저하 | 읽기 - 쓰기 분리 + Cache/TTL 기반 접근 |
보안 | 접근 제어 | 중앙 집중형 RBAC 적용 용이 | 다중 노드에서 권한 동기화 필요 | 중앙 인증 서비스, JWT/OAuth 기반 |
보안 | 감사 로깅 | 단일 로그로 변경 추적 | 분산 로그 취합·정렬 필요 | 중앙 로깅/분석 플랫폼 (ELK, OpenSearch) |
분산 트랜잭션 | 분산 환경 복잡성 | 필요 시 XA/2PC 적용 가능 | 네트워크 지연, 부분 실패 시 복잡성 급증 | SAGA 패턴, Outbox/Inbox, 이벤트 소싱 |
- 성능 측면: 분산 환경에서는 네트워크 지연과 복제 지연이 핵심 병목 → 트랜잭션 단위 최소화 필수
- 동시성 측면: 단일 DB 에서는 비교적 단순하지만, 분산 환경에서는 락/버전 관리가 복잡
- 가용성 측면: 단일 노드 복구보다 분산 환경의 다중 노드 복구·네트워크 분할 대응이 훨씬 어려움
- 확장성 측면: 단일 DB 에서는 옵션이지만, 분산 환경에서는 필수 과제
- 보안 측면: 권한·로그 관리가 단일 DB 보다 훨씬 복잡하며 중앙화된 관리 체계 필요
- 분산 트랜잭션: 2PC/3PC 성능·복잡성 문제로 SAGA, 이벤트 소싱 등 대안 필요
최적화하기 위한 고려사항 및 주의할 점
카테고리 | 최적화 방법 | 구현 전략 | 권장사항 |
---|---|---|---|
락킹·동시성 최적화 | 락 범위 최소화 | Row-level Lock, Gap Lock 최적화 | 필요한 자원만 잠금, 커버링 인덱스로 범위 축소 |
데드락 방지 | 락 순서 표준화, Lock Timeout | 리소스 접근 순서 규약화, 타임아웃 기본값 설정 | |
MVCC 활용 | Snapshot Isolation, Versioning | 읽기 집약적 환경에서 활용 | |
로깅·복구 최적화 | WAL I/O 경감 | 비동기/배치 쓰기, 그룹 커밋 | 지연 허용 범위 내에서 설정 |
로그 관리 최적화 | 로그 압축, 주기적 아카이빙 | 장기 보관 로그는 별도 스토리지 | |
인덱스·쿼리 최적화 | 인덱스 설계 | 외래키, 조인 컬럼, 복합 인덱스 | 커버링 인덱스 적극 활용 |
버퍼링·메모리 관리 | 버퍼 풀 최적화 | 워킹셋 기반 크기 조정 | 모니터링 기반 동적 조정 |
트랜잭션 구조 최적화 | 트랜잭션 분리 | 마이크로 트랜잭션 설계 | 짧은 트랜잭션 유지, 경합 최소화 |
비동기·확장성 전략 | 비동기 처리 | 메시지 큐, 이벤트 소싱 | 실시간성 낮은 작업 위임 |
읽기 - 쓰기 분리 | Read Replica 활용 | 최신성 요구에 따라 TTL 설정 | |
운영·모니터링 관리 | 성능·락 모니터링 | 데드락 감지, 쿼리 분석 | 실시간 대시보드, 알람 연계 |
체크포인트 관리 | 주기적 체크포인트 | 복구 시간과 성능 균형 유지 |
- 락킹 최적화: 범위 최소화와 데드락 방지가 성능·안정성 모두에 필수
- 로깅 최적화: WAL I/O 를 줄이는 비동기·배치 전략이 큰 성능 향상
- 인덱스 전략: 커버링 인덱스와 복합 인덱스로 락 경합과 I/O 비용 동시 절감
- 메모리 관리: 워킹셋 기반 버퍼링으로 캐시 히트율 향상
- 트랜잭션 구조: 짧고 단순한 트랜잭션이 동시성 극대화
- 비동기 처리: 실시간성이 낮은 작업은 메시지 큐로 분리
- 운영 관리: 실시간 모니터링·체크포인트 주기로 장애 복구 속도 확보
ACID 속성별 단일 DB Vs 분산 DB 환경 최적화 포인트
속성 | 단일 DB 최적화 포인트 | 분산 DB 최적화 포인트 | 차이·설계 변화 |
---|---|---|---|
Atomicity (원자성) | - WAL 그룹 커밋으로 트랜잭션 단위 보장 - 짧은 락 유지로 롤백 비용 최소화 | - 글로벌 트랜잭션 최소화, 로컬 트랜잭션 우선 - Saga 패턴·보상 트랜잭션 설계 | 분산은 2PC/3PC 지연과 실패 가능성이 크므로 원자성 보장보다 부분적 보상 전략이 실무적 |
Consistency (일관성) | - 제약조건·트리거 활용 - 단일 스키마·단일 타임라인 유지 | - Eventually Consistency 설계 - CQRS 로 읽기/쓰기 경로 분리 - 글로벌 일관성 필요한 경우 Spanner 등 선택 | 분산은 네트워크 파티션 시 강한 일관성 유지 비용이 커서 최종 일관성 허용이 유리 |
Isolation (고립성) | - MVCC 활용, 락 범위 최소화 - READ COMMITTED/REPEATABLE READ 조정 | - 노드별 격리 수준 유지 - 글로벌 락 회피, 로컬 격리 + 보상 처리 | 분산에서는 글로벌 격리 유지 비용이 매우 커서 로컬 수준 격리 + 트랜잭션 설계로 보완 |
Durability (지속성) | - WAL 동기화 튜닝, 체크포인트 주기 최적화 - 배터리 백업 캐시 사용 | - 각 노드 로컬 WAL + 비동기 복제 - 합의 기반 (Consensus) 로그 복제 최소화 | 분산은 지속성 보장이 네트워크 합의에 의존하므로 복제 지연과 안정성 균형 필요 |
- Atomicity: 단일 DB 는 빠른 커밋/롤백 중심, 분산 DB 는 보상 트랜잭션 중심
- Consistency: 단일 DB 는 강한 일관성 유지, 분산 DB 는 최종 일관성과 CQRS 활용
- Isolation: 단일 DB 는 격리 수준 조정, 분산 DB 는 글로벌 락 최소화
- Durability: 단일 DB 는 로컬 I/O 최적화, 분산 DB 는 복제·합의 비용 최적화
고급 주제 (Advanced Topics)
현재 도전 과제
카테고리 | 과제 | 원인 | 영향 | 해결방안 |
---|---|---|---|---|
분산 환경 및 글로벌 확장성 | 글로벌 환경에서 ACID 유지 | CAP 정리에 따른 일관성 - 가용성 트레이드오프, 2PC 지연 | 글로벌 지연, 가용성 저하, 운영 복잡성 증가 | 지역별 ACID + 글로벌 eventual consistency, SAGA/Outbox |
클라우드 네이티브 / 마이크로서비스 | 분산 트랜잭션 복잡성 | 서비스 간 트랜잭션 경계 복잡, SSI 운영 난이도 | 장애 대응 복잡성, 성능 저하 | 이벤트 소싱, CQRS, 트랜잭션 경계 최소화 |
실시간 및 대용량 데이터 처리 | ACID 보장에 따른 지연 | 대용량 데이터 락 경합, 메모리 부담 | 실시간 응답 저하, 배치 지연 | 읽기 복제본, 파티셔닝/샤딩, 병렬 처리, 비동기 ACID |
스토리지·내구성 및 규제 대응 | 내구성과 지연의 균형, 규제 준수 | 멀티 AZ/리전 WAL 동기화 지연, 규제 감사 요구 | 데이터 복제 비용 증가, 법적 리스크 | 지연 허용 기반 스토리지 정책, 안정적 스토리지 계층, 감사 로깅 |
- 분산 환경 및 글로벌 확장성: CAP 한계를 극복하려면 지역적 강한 일관성과 글로벌 eventual consistency 를 혼합해야 함.
- 클라우드 네이티브 / 마이크로서비스: 트랜잭션 경계를 최소화하고 보상 트랜잭션 패턴을 적극 활용해야 안정성 확보 가능.
- 실시간 및 대용량 데이터 처리: 읽기 복제본·샤딩·비동기화를 통한 지연 완화가 핵심.
- 스토리지·내구성 및 규제 대응: 내구성 보장과 성능 사이의 균형 설계, 규제 준수 로깅 체계 필수.
생태계 및 관련 기술
카테고리 | 기술/제품 | ACID 연계 역할 | 핵심 포인트 | 적용 예 |
---|---|---|---|---|
표준/프로토콜 | ANSI/ISO SQL 격리, XA/2PC, MVCC | 격리 규격·분산 커밋 규정 | RC/RR/Serializable 의미론, 2PC 준비·커밋 | 다중 서비스 커밋, 은행 이체 |
엔진/메커니즘 | PostgreSQL(MVCC/SSI), MySQL InnoDB(MVCC+2PL), ARIES/WAL | 동시성·복구의 코어 | 스냅샷 읽기, 로그 선기록, Analysis/Redo/Undo | 주문·결제, 원장 시스템 |
코디네이션/합의 | ZooKeeper/etcd, Raft/Paxos | 리더·락·메타 일관성 | 상태·메타데이터의 강 일관성, 장애 복구 | 분산 락, 클러스터 메타 |
메시징/이벤트 | Kafka, RabbitMQ, Outbox+CDC | 트랜잭션 이벤트 전달 | 정확히 한 번 근사, 멱등키·리트라이 | 주문 이벤트, 사가 오케스트레이션 |
캐싱/세션 | Redis, Memcached | 읽기 성능·세션 일관 | 캐시 무효화/TTL, 토큰화 | 재고 조회, 세션 공유 |
관측/운영 | Prometheus, Grafana, CDC/Audit | 무결성·성능 가시화 | WAL LSN 라그, 락/데드락율, CDC 감사 | SLA 모니터링, 컴플라이언스 |
패턴/아키텍처 | SAGA, TCC, Idempotency Key, Transactional Outbox | 2PC 대안 | 보상 플로우/멱등성으로 최종 일관 | 마이크로서비스 주문·환불 |
이론/모델 | BASE, CAP | 설계 판단 기준 | 가용성·지연 vs 일관성 트레이드오프 | 글로벌 분산 설계 |
Lakehouse ACID | Delta, Iceberg, Hudi | 테이블 레벨 ACID | 스냅샷/메타 로그, 멀티 라이터 제어 | 배치 + 스트리밍 동시 처리 |
ACID 를 실무에서 제대로 보장하려면 ** 엔진 내부 (MVCC/WAL/복구)** 에 더해, ** 분산 합의·메시징·패턴 (SAGA/Outbox)** 이 함께 설계되어야 한다. 단일 DB 에선 2PL/MVCC 로 충분하지만, 마이크로서비스·글로벌 분산에선 2PC 비용이 커지므로 보상·멱등으로 일관성을 달성하는 구성이 현실적이다. 데이터 레이크하우스 환경도 트랜잭션 테이블 포맷으로 ACID 를 확장해 배치·스트리밍 동시 운영을 안전하게 만든다.
최신 기술 트렌드와 미래 방향
카테고리 | 핵심 트렌드 | 주요 기술/패턴 | 기대 효과 | 제약/주의 | 대표 적용 |
---|---|---|---|---|---|
분산 ACID/글로벌 트랜잭션 | 멀티리전 직렬성·하이브리드 일관성 | Raft/Paxos, TrueTime/HLC, 지리적 파티셔닝 | 전세계 일관성, RPO/RTO 개선 | 레이턴시·비용 증가, 스키마·트래픽 설계 필요 | Spanner/Cockroach/Yugabyte |
서버리스·마이크로서비스 | 트랜잭션 오케스트레이션 | SAGA/TCC, Outbox, Idempotency, Step Functions/Workflows | 결합도↓, 실패 격리, 운영 단순화 | 보상 로직 복잡, 최종 일관성 수용 필요 | 결제·주문·예약 |
레이크하우스 ACID | 테이블 포맷 ACID | Delta/ Iceberg/ Hudi, 옵티미스틱 락, 스냅샷/타임트래블 | 배치·스트리밍 일원화, 데이터 품질↑ | 메타데이터 스케일·병합 비용 | 분석 + 실시간 파이프라인 |
AI/자율 최적화 | 예측·튜닝 자동화 | 락/경합 예측, 자동 인덱싱, 이상 트랜잭션 탐지, AIOps | SLO 안정, 운영비↓ | 오탐·데이터 드리프트 | 금융·커머스 |
블록체인 연계 | 온·오프체인 콤포저블 | 온체인 결제/영수증 + 오프체인 OLTP, 크립토 영수증 | 불변성·감사 추적, 결제 신뢰 | 지연·수수료·브리지 리스크 | 정산·디지털 자산 |
인프라 가속 | 로그·복제 최적화 | 그룹 커밋, WAL 압축, 비동기/선택적 동기복제, NVMe/RDMA | TPS↑, 지연↓ | 강한 내구성과의 트레이드오프 | 고 TPS OLTP |
보안·거버넌스 | 정책·감사 자동화 | 데이터 주권, 리전 경계, OTel 트레이싱, KMS/HSM | 규제 준수, 사고 대응력↑ | 멀티리전 정책 복잡 | 규제 산업 |
- 분산 SQL 과 레이크하우스 ACID 가 주류로 정착, 트랜잭션은 오케스트레이션/보상 패턴과 결합.
- AI 기반 운영 자동화와 인프라 가속이 SLO 를 뒷받침.
- 보안·거버넌스와 데이터 주권 요구가 설계 초기에 반영되는 것이 2025 년의 기본값.
ACID vs. BASE 비교
구분 | ACID 모델 | BASE 모델 |
---|---|---|
전체 의미 | Atomicity, Consistency, Isolation, Durability–트랜잭션의 완전성과 무결성을 보장 | Basically Available, Soft State, Eventually Consistent–가용성과 확장성을 극대화 |
목적 | 데이터 무결성·신뢰성 유지 | 가용성·성능·확장성 최우선 |
일관성 | 강한 일관성 (Strong Consistency)–즉각적이고 전역적으로 동일한 데이터 보장 | 최종적 일관성 (Eventual Consistency)–시간 경과 후 일관성 회복 |
장애 시 동작 | 트랜잭션 단위 전부 롤백 또는 전부 커밋 | 일부 데이터 반영 후 나중에 동기화 |
주 활용 환경 | 금융, 회계, 주문·결제, 재고, 컴플라이언스 필수 업무 | 소셜 피드, 로그 수집, 캐시 시스템, 대규모 분산 분석 |
대표 기술 | PostgreSQL, Oracle, MySQL InnoDB, Google Spanner | Cassandra, Amazon DynamoDB, Couchbase, Redis(비동기 복제) |
장점 | 데이터 신뢰성, 무결성, 장애 복구 용이 | 대규모 트래픽 처리, 가용성 높음, 지연 최소화 |
단점 | 확장성·성능 저하 | 데이터 잠시 불일치 허용, 비즈니스 로직이 복잡 |
선택 의사결정 매트릭스 (업무 시나리오별 추천)
조건 | 데이터 정확성 중요도 | 응답 속도 요구 | 시스템 규모 | 추천 모델 |
---|---|---|---|---|
결제/이체 | 매우 높음 | 중간 | 중간~대형 | ACID |
재고 관리 | 높음 | 중간 | 대형 | ACID 우선, 특정 로그·분석은 BASE |
소셜 피드 | 낮음 | 매우 높음 | 초대형 | BASE |
로그 수집 | 낮음 | 높음 | 초대형 | BASE |
글로벌 데이터 분석 | 중간 | 중간 | 초대형 | BASE + 이벤트 정합성 보정 |
멀티리전 결제 | 매우 높음 | 낮음 허용 | 초대형 분산 | ACID (글로벌 일관성 보장 시스템) |
- 업무상 데이터 불일치가 법적·금전적 피해를 초래 → ACID 필수
- 일시적 불일치를 허용하고 대규모 분산 처리·가용성이 핵심 → BASE 선택
- 하이브리드 전략: 핵심 데이터 경로는 ACID, 비핵심 경로는 BASE 적용
실제 하이브리드 적용 아키텍처 예시 (ACID + BASE 혼합)
graph LR subgraph Critical-Path A1[주문·결제 서비스] --> DB_ACID[(PostgreSQL - ACID 작성)] end subgraph NonCritical-Path A2[추천·로그 서비스] --> DB_BASE[(Cassandra - BASE 처리)] end Client --> A1 Client --> A2 A1 --> Kafka[이벤트 브로커] Kafka --> A2
- Critical Path(핵심 경로): ACID 기반 시스템 → 데이터 무결성 필수 보장
- Non-Critical Path(비핵심 경로): BASE 기반 시스템 → 고성능·고가용성 확보
- 이벤트 브로커 (Kafka): 두 경로를 분리하되, 데이터 흐름을 느슨하게 연결
ACID vs. Isolation Level 매핑
Isolation Level | Atomicity | Consistency | Isolation | Durability | 설명 |
---|---|---|---|---|---|
Read Uncommitted | ✅ | ❌ | ❌ | ✅ | Dirty read 허용 |
Read Committed | ✅ | ✅ | ⚠️ | ✅ | Non-repeatable read 가능 |
Repeatable Read | ✅ | ✅ | ✅ | ✅ | Phantom read 가능 |
Serializable | ✅ | ✅ | ✅ | ✅ | 완전한 격리 보장 |
⚠️: 일부 anomaly 허용
Isolation Level 별 동시성 오류 실습
이 실습의 목적은 ACID 중 Isolation 특성이 충분히 지켜지지 않을 때 발생하는 전형적인 동시성 문제를 직접 재현하는 것.
PostgreSQL 같은 ACID 준수 DB 에서 Isolation Level 을 변경하며 테스트하면 체감이 크다.
실습 시나리오:
- 환경: PostgreSQL, Python(psycopg2 사용), 두 개의 세션 (트랜잭션) 동시 실행
- 목표: Isolation Level 변경에 따른 Dirty Read, Non-repeatable Read, Phantom Read 체험
시스템 구성 다이어그램:
graph TB Client1[세션 1] --> DB[PostgreSQL] Client2[세션 2] --> DB DB --> Storage[(데이터저장소)]
코드 예시:
|
|
- Isolation Level 을
READ UNCOMMITTED
로 설정 → Dirty Read 가능 - 세션 1 이 첫 번째 읽기 후, 세션 2 에서 값을 변경하고 커밋 전 Dirty Read 발생
- 세션 2 가 롤백하면, 세션 1 이 읽었던 값은 실제 DB 에 존재하지 않는 " 더러운 데이터 " 가 됨
분산 트랜잭션과 CAP 이론 연결
CAP 이론이란?
항목 | 설명 |
---|---|
C (Consistency) | 모든 노드에서 같은 데이터를 반환 |
A (Availability) | 클라이언트 요청에 항상 응답 가능 |
P (Partition Tolerance) | 네트워크 분할 시에도 일부 시스템이 계속 작동 가능 |
이 세 가지 중 분산 시스템은 동시에 두 개만 보장할 수 있음 (CAP 정리)
ACID 트랜잭션과 CAP 대응 관계
ACID 속성 | CAP 대응 항목 | 설명 |
---|---|---|
Consistency | C | 모든 트랜잭션 후 DB 가 유효한 상태로 유지됨 |
Durability | A / P | 시스템 장애 후에도 결과 유지 |
Isolation | C / A | 동시 트랜잭션 충돌 방지, 응답 지연 가능성 |
Atomicity | C | 실패 시 전체 작업 취소하여 일관성 유지 |
분산 트랜잭션에서의 선택 사례
시스템 | 선택한 2 개 | 희생한 항목 | 설명 |
---|---|---|---|
Zookeeper | CP | A | 일관성 우선, 응답이 느릴 수 있음 |
Cassandra | AP | C | 빠른 응답, Eventually Consistent |
Etcd | CP | A | 리더 기반 강한 일관성 |
DynamoDB | AP | C | 빠르고 가용성 높음, 일관성은 조정 가능 |
Spanner (Google) | CAP 극복 시도 | None | TrueTime 기반 동기화로 강한 일관성과 분산을 동시에 지향 |
2PC 와 CAP 연계
- 2PC(2-Phase Commit):
- C 보장을 위해 동기화 과정 필요 → A 저하 위험
- 네트워크 분할 시 트랜잭션 중단 → P 불완전
sequenceDiagram participant Client participant NodeA participant NodeB Client->>NodeA: prepare() NodeA->>Client: ready Client->>NodeB: prepare() NodeB->>Client: ready Client->>NodeA: commit() Client->>NodeB: commit()
- Paxos / Raft 기반 DB (e.g. Etcd, TiDB) 는 Paxos 기반 합의를 통해 CP 시스템을 구현하고 있음.
종합 정리 및 학습 가이드
내용 정리
ACID 는 트랜잭션의 원자성·일관성·격리성·지속성을 보장해 데이터 정합성과 신뢰성을 담보한다.
구현은 WAL/ARIES로 원자성·지속성을, 2PL 또는 MVCC로 격리성을 달성하고, 제약조건/트리거로 일관성을 강화한다.
실무에서는 격리수준 선택과 트랜잭션 경계 최소화, 로그/스토리지 튜닝이 성능 - 정합성 균형의 관건이다.
분산·멀티리전 환경에서는 합의·시간모델 또는 SAGA/이벤트로 확장하며, 레이크하우스 ACID는 분석·실시간 파이프라인의 정합성을 끌어올린다.
최근에는 관측성·자율 최적화와 보안·거버넌스가 동등한 설계 축으로 부상했다.
범주 | 핵심 내용 | 대표 기술/기법 | 실무 체크포인트 |
---|---|---|---|
Atomicity(원자성) | 전부 성공/전부 실패 보장, 실패 시 롤백 | WAL/ARIES(UNDO/REDO), Savepoint | 트랜잭션 경계 최소화, 예외 시 일관된 롤백 경로 |
Consistency(일관성) | 모든 제약·규칙 충족 상태로만 전이 | FK/Unique/Check, 트리거, 앱 레벨 검증 | 스키마·도메인 규칙 일치, 데이터 품질 규칙 자동화 |
Isolation(격리성) | 동시 트랜잭션 간 간섭 차단 | 2PL, MVCC, ANSI 격리수준 | 업무별 격리수준 선택 (RC/RR/Serializable), 경합 모니터링 |
Durability(지속성) | 커밋 결과 영구 보존 | WAL fsync, 체크포인트, 복제 | 그룹 커밋·스토리지 지연 최적화, 백업·복구 RTO/RPO |
분산 적용 | 전역 일관성/지연의 절충 | 2PC/XA, Raft/Paxos, TrueTime/HLC | 트래픽·리전 토폴로지 설계, 지연·비용 모델링 |
대안/보완 | 최종 일관·보상 트랜잭션 | SAGA/TCC, Outbox/Inbox, Idempotency | 보상 로직, 중복처리, 재처리 안전성 |
데이터레이크 | 테이블 포맷 ACID | Delta/Iceberg/Hudi | 스냅샷/타임트래블, 머지/컴팩션 비용 관리 |
관측성/운영 | 병목·경합 가시화/자동화 | OpenTelemetry, eBPF, AIOps | 락/IO·로그 지표, 자동 튜닝·알림 기준 |
학습 로드맵
단계 | 기간 | 학습 내용 | 실습/도구 | 목표 |
---|---|---|---|---|
기초 | 1~2 주 | ACID 정의, SQL 트랜잭션 기본 문법, 격리 수준 개념 | 단일 DB 실습 (PostgreSQL/MySQL) | ACID 속성 이해 및 기본 조작 숙지 |
중급 | 2~3 주 | 격리 수준 심화, 락킹/MVCC, WAL 기초, 복구 기초 | WAL 로그 관찰, 장애 복구 테스트 | 동시성 제어와 복구 메커니즘 이해 |
고급 | 3~4 주 | WAL·ARIES, 2PL, SSI, 분산 트랜잭션, CAP/BASE, 설계 패턴 (SAGA, CQRS) | Docker 분산 환경, Outbox 구현 | 분산 환경에서 ACID 구현 능력 확보 |
전문가 | 지속 | 성능 최적화, 모니터링·관측성, 도메인별 설계, 최신 트렌드 (NewSQL, HTAP), 보안·규제 준수 | Prometheus, Grafana, 장애 복구 시나리오 | 실무 레벨의 안정적 트랜잭션 설계·운영 |
학습 항목 매트릭스
카테고리 | Phase | 항목 | 중요도 | 설명 |
---|---|---|---|---|
기초 | 1 | ACID 속성 정의 | 필수 | 원자성, 일관성, 고립성, 지속성의 개념과 목적 |
기초 | 1 | 트랜잭션 기본 개념 | 필수 | BEGIN, COMMIT, ROLLBACK 사용법 |
이론 | 2 | 동시성 제어 메커니즘 | 필수 | 2PL, MVCC 의 원리와 차이 |
이론 | 2 | 격리 수준·현상 | 필수 | 4 단계 SQL 격리 수준과 Dirty/NR/Phantom |
이론 | 2 | WAL/복구 메커니즘 | 필수 | WAL, ARIES 구조와 UNDO/REDO 규칙 |
구현 | 4 | 언어별 구현 실습 | 권장 | Java, Python, Node.js 트랜잭션 코드 작성 |
구현 | 5 | DB 설정·최적화 | 권장 | Isolation Level, 인덱스, 커넥션 풀, 배치 처리 |
운영 | 6 | 모니터링·관측성 | 권장 | 락/데드락, LSN lag, 트랜잭션 메트릭 수집 |
운영 | 6 | 장애 대응·튜닝 | 권장 | Deadlock 해소, WAL/체크포인트 최적화 |
고급/확장 | 7 | 분산 ACID | 선택 | 2PC, 3PC, 글로벌 일관성 구현 |
고급/확장 | 7 | CAP vs ACID | 선택 | 분산 환경에서의 일관성·가용성 트레이드오프 |
고급/확장 | 7 | 분산 대안 패턴 | 선택 | Saga, TCC, Outbox+CDC, 멱등 처리 |
고급/확장 | 7 | 최신 기술 동향 | 선택 | Spanner, Delta Lake, Kafka Exactly-once |
ACID 학습은 기초 → 엔진 메커니즘 → 구현/운영 → 분산/확장 순서로 계단식 접근이 효율적이다.
기초와 이론은 모든 환경에서 필수이며, 구현·운영 단계에서 실무 장애와 튜닝 경험이 중요하다.
분산·고급 항목은 규모와 환경에 따라 선택적으로 학습하되, SAGA, CAP/BASE, 최신 ACID 확장 기술은 분산 설계 시 필수 참고 대상이다.
용어 정리
카테고리 | 용어 | 정의 | 관련 개념 |
---|---|---|---|
핵심 개념 | ACID | 트랜잭션의 4 가지 속성 (원자성·일관성·격리성·지속성) | 데이터 무결성, 신뢰성 |
핵심 개념 | Transaction | 하나의 논리적 작업 단위 | BEGIN, COMMIT, ROLLBACK |
핵심 개념 | Commit | 트랜잭션 결과를 영구 저장 | Durability, WAL |
핵심 개념 | Rollback | 트랜잭션 작업을 취소하고 이전 상태로 복원 | Atomicity |
핵심 개념 | Atomicity | 전부 실행되거나 전혀 실행되지 않음 | 롤백 |
핵심 개념 | Consistency | 트랜잭션 전후 유효 상태 유지 | 제약조건 |
핵심 개념 | Isolation | 트랜잭션 간 간섭 방지 | 격리 수준 |
핵심 개념 | Durability | 커밋 결과 영구 보존 | WAL, 복구 |
동시성 제어 | Isolation Level | 격리 정도 설정 단계 | READ COMMITTED, SERIALIZABLE |
동시성 제어 | Locking | 공유/배타 락으로 동시성 제어 | Deadlock |
동시성 제어 | MVCC | 다중 버전 스냅샷으로 읽기/쓰기 병행 | Snapshot Read |
동시성 제어 | 2PL | 락 획득·해제 단계를 구분하는 프로토콜 | 교착상태 |
동시성 제어 | Snapshot Isolation | MVCC 기반의 일관성 보장 | Serializable 대안 |
동시성 제어 | Deadlock | 자원 순환 대기로 인한 무한 대기 | 락 순서 규약 |
복구 및 로그 | WAL | 데이터보다 로그를 먼저 기록 | Durability |
복구 및 로그 | ARIES | WAL 기반 복구 알고리즘 | LSN |
복구 및 로그 | LSN | WAL 로그 식별자 | 복구 범위 추적 |
복구 및 로그 | Checkpoint | 복구 시작점을 단축하는 주기적 기록 | REDO, UNDO |
분산 트랜잭션 | 2PC | 분산 환경에서 원자적 커밋 보장 | Coordinator, Participant |
분산 트랜잭션 | XA Protocol | 분산 트랜잭션 표준 인터페이스 | 2PC |
분산 트랜잭션 | BASE | Basically Available, Soft State, Eventual Consistency | CAP 정리 |
분산 트랜잭션 | Eventual Consistency | 시간이 지나면 일관성 회복 | BASE |
분산 트랜잭션 | Partition Tolerance | 네트워크 분리에도 일부 동작 가능 | CAP 정리 |
패턴 | SAGA Pattern | 분산 트랜잭션을 단계로 나누어 보상 처리 | 보상 트랜잭션 |
패턴 | Outbox Pattern | DB 변경과 이벤트 발행을 트랜잭션 내 동기화 | Event Driven |
성능 최적화 | Group Commit | 여러 커밋을 묶어 로그 플러시 | TPS 향상 |
성능 최적화 | Sharding | 데이터 수평 분할 | Regional Consistency |
성능 최적화 | Regional Consistency | 특정 지역 단위의 일관성 유지 | 지연 최소화 |
참고 및 출처
- Wikipedia – ACID Properties
- Yugabyte – ACID 설명
- PostgreSQL Documentation – Transaction Isolation
- Oracle Database Transaction Concepts
- MongoDB – ACID Transactions Guide
- TiDB – Distributed Transactions Overview
- FoundationDB – ACID in Distributed Database
- IBM Developer – ACID vs BASE
- ACM Queue – CAP Theorem
- Databricks – ACID Transactions Glossary
- GeeksforGeeks – DBMS ACID Properties
- FreeRTOS – Embedded RTOS Binary Semaphores (context relevance)
- Martin Kleppmann – Designing Data-Intensive Applications (ACID/BASE sections)
- SQLite – Write-Ahead Logging (WAL) Concept
- Stormatics – Database Concurrency: 2PL to MVCC explained
- Vlad Mihalcea – How does MVCC work?