DB Concurrency Issue

동시성 문제

[상황: 홍길동 계좌 잔액 10,000원] (Lost Update)

1. 트랜잭션 A: 3,000원 입금 시도. (DB 조회: 10,000원 -> 메모리에서 +3,000 = 13,000원)

2. 트랜잭션 B: 5,000원 입금 시도. (DB 조회: 10,000원 -> 메모리에서 +5,000 = 15,000원)

3. 트랜잭션 A 커밋: DB에 13,000원 저장.

4. 트랜잭션 B 커밋: DB에 15,000원 저장. (13,000원을 덮어씀)

결과: 최종 잔액은 15,000원입니다. 트랜잭션 A가 입금한 3,000원은 사라졌습니다.

두 트랜잭션이 모두 성공적으로 커밋을 했는데도 불구하고 데이터의 일관성은 깨졌습니다.

차라리 어딘가 장애가 발생해 예외가 발생하거나 사용자가 인지할 수 있는 증상이 있었다면 문제를 빠르게 인지하고 해결 방법을 찾아볼 수 있겠지만, 뒤늦게 발견한 경우 이미 일관성이 많이 깨져있어서 깨진 일관성을 맞추는 게 불가능하거나 오래 걸리는 작업이 될 수 있습니다.

이 외에도 다양한 동시성 문제가 존재합니다.

Dirty Read	한 트랜잭션이 아직 커밋되지 않은 다른 트랜잭션의 수정 데이터를 읽는 현상. 데이터를 수정한 트랜잭션이 롤백될 경우, 잘못된 데이터를 읽게 됨.
Non-Repeatable Read	한 트랜잭션 내에서 동일한 행(Row)를 두 번 이상 조회했을 때, 그 사이에 다른 트랜잭션이 해당 데이터를 수정하고 커밋하여 결과가 다르게 나타나는 현상.
Phantom Read	한 트랜잭션 내에서 특정 범위를 두 번 이상 조회했을 때, 그 사이에 다른 트랜잭션이 해당 범위에 데이터를 추가/삭제하고 커밋하여 결과 집합이 달라지는 현상.
Lost Update	두 개 이상의 트랜잭션이 동일 데이터를 동시에 수정할 때, 나중에 커밋한 트랜잭션의 수정 내용이 먼저 커밋한 트랜잭션의 수정 내용을 덮어써서 데이터 변경이 유실되는 현상

해결책: 격리 수준 (Isolation Level) 조정

격리 수준	Dirty Read	Non-Repeatable Read	Phantom Read	특징
READ UNCOMMITTED	O	O	O	- 커밋되지 않은 데이터를 읽는 것을 허용 - 정합성 문제가 많아 거의 사용하지 않음
READ COMMITTED	X	O	O	- 커밋된 데이터만 읽도록 하여 더티 리드를 방지. - 대부분 상용 DB의 기본 격리 수준
REPETABLE READ	X	X	O	- 트랜잭션이 시작된 시점의 데이터 스냅샷을 읽어, 트랜잭션 내내 일관된 데이터를 보장. - 논 리피터블 리드를 방지. - MySQL InnoDB의 기본 격리 수준
SERIALIZABLE	X	X	X	- 가장 엄격한 수준으로, 트랜잭션을 순서대로 실행시켜 모든 동시성 문제를 방지. - 동시 처리 성능이 가장 낮아 반드시 필요한 경우에만 사용.

격리 수준과 성능은 트레이드 오프 관계에 있기 때문에 개발하는 애플리케이션에서 실행 중인 트랜잭션은 어느 정도의 격리 수준이 필요한지 따져봐야 합니다.

해결책: Pessimistic Lock

비관적 락

• 개념: "충돌이 무조건 발생할 거야"라고 비관적으로 생각하고, 데이터를 읽을 때부터 아예 락을 걸어버립니다.

• SQL: SELECT ... FOR UPDATE 쿼리가 실행됩니다.

• 동작: 트랜잭션 A가 홍길동 계좌를 조회하는 순간 락을 획득합니다. 트랜잭션 B는 A가 끝날 때까지 조회를 못 하고 대기(Waiting) 상태가 됩니다.

• 장점: 데이터 정합성을 확실하게 보장합니다.

• 단점: 대기 시간이 길어져서 성능 저하나 **데드락(Deadlock)**이 발생할 수 있습니다.