데이터 중심 애플리케이션 설계 7장

[epicblues]

7장. 트랜잭션

여러 연산을 하나의 논리적 단위로 묶음

트랜잭션의 4가지 요소

Atomic

• 실패 시 중간에 연산된 내용들을 다 버림
• abortion이 핵심
  • 애플리케이션에서 부담없이 재시도할 수 있음

Consistency

• 비즈니스 불변식 보장

• DB가 아닌 애플리케이션에서 보장해야 하는 것

Isolation

• = Serialization
  • 모든 트랜잭션을 순차적으로 실행하는 것처럼 구성해야 함.
  • 동시성 100% 포기
• vs 스레드의 Isolation
  • 한 스레드의 중간 연산 과정을 다른 스레드에서 볼 수 없어야 함
  • ACID의 Isolation은 동시성을 고려하지 않는다.

Durability

• 완료된 트랜잭션은 데이터베이스에 완전히 반영되어야 한다.
• 보통 트랜잭션이 커밋됨을 알리기 전에, 디스크(복제 노드 등)에 완전히 저장됐는지 확인한다.
• 여러 요인(replication, 디스크, 네트워크, 노드 장애) 등으로 완전하게 보장할 수 없음

완화되 격리 수준

Dirty Read

• 하나의 트랜잭션에서 커밋되지 않은 변경 내역을 읽음

Dirty Write

• 일반적인 update 경로
  • read → modify → write
  • write 시점에 read된 내용이 다른 트랜잭션에 의해 변경되서 애플리케이션 개발자가 의도치 않은 update가 일어날 때
• 해결
  • DB에서 지원하는 원자적 연산을 사용
    • sequence, set value = value + 1
      • 내부적으로는 잠금 활용
  • compare-and-set 연산 활용
    • set 단계에서 대상의 변경을 감지할 경우 abort

Read committed

• 커밋된 내용만 읽기

Read Skew

• 다른 트랜잭션의 커밋으로 인해 이전 질의의 결과가 바뀌는 현상

Snapshot Isolation

• Repeatable Read라고도 불림
  • 다만 실제 학계의 Repeatable Read 표준을 만족시키는 경우 없음
• 상호 배제 최소화
  • 쓰기 트랜잭션이 읽기 트랜잭션을 막지 않음
  • 읽기 트랜잭션이 쓰기 트랜잭션을 막지 않음
• 일반적으로 MVCC로 구현
  • created_by, deleted_by 로 어떤 트랜잭션이 생성/삭제했는지 반영
  • 처음 트랜잭션을 시작할 때 커밋되지 않은 record는 읽지 않음

Write Skew

• 한 트랜잭션의 전제 조건으로 확인한 불변식이 다른 트랜잭션에 의해 훼손되었음에도 불구하고 write 작업을 수행하게 됨
  • 보통 불변식을 결정하는 row의 ‘존재 여부’를 확인하는 로직에서 발생(다른 트랜잭션에서 추가)
• 해결책
  • 충돌 구체화
    • 충돌 범위에 대한 잠금 객체 추가
      • redis

Isolation(Serialization)

여러 트랜잭션의 병렬 실행 여부와 상관 없이 최종적 결과는 한 번에 하나씩 직렬로 실행 보장

→ 모든 race condition 차단

단일 스레드 트랜잭션(진짜 직렬성!)

• ‘최근에 부활한’ 구식 아이디어
  • 값싼 메모리 → 모든 데이터를 인메모리로 처리 가능
  • OLTP 트랜잭션의 독특한 특징
    • 짧은 시간
    • 적은 데이터
  • 분석 질의
    • 읽기 전용 → snapshot isolation 으로 충분!
• 단일 코어(스레드)
• 동시성 지원 시스템보다 성능이 좋을 때도 있음
  • lock 코디네이션 오버헤드 X
• Redis, 볼트DB/H-스토어, 데이토믹

보완 방식

• 스토어드 프로시저

  • 모든 로직을 하나의 스토어드 프로시저로 뭉쳐서 처리하자!
  • 최근 대세는 다중 구문 트랜잭션
    • 질의 구문 → 애플리케이션 로직 실행 → 쓰기 구문
    • 빈번한 네트워크 요청 + 긴 트랜잭션 점유 시간 ⇒ 단일 스레드 직렬화 DB에서는 힘들다!

  • 여러 문제들

    • 성능
      • 여러 애플리케이션 인스턴스에서 실행되던 연산들이 DB 인스턴스로 모임
    • 유지 보수
      • 디버깅, 버전 관리…
    • 통일되지 않은 언어
      • 최근에는 기존 범용 프로그래밍 언어로 실행 가능

    • 예시(Redis)

      [Transactions](https://redis.io/docs/interact/transactions/)

• 파티셔닝

  • 각 파티션 별로 CPU 코어 할당
  • 값비싼 쓰기 트랜잭션에서 사용 가능
  • 대상 데이터 구조가 단순해야함
  • 하지만 트랜잭션이 여러 파티션을 건드리는 경우 코디네이션이 필요함 ⇒ 성능 저하
    • 인덱스 등

2단계 잠금(two-phase locking)

• Share Lock Exclusive lock 활용
  • 읽을 때 Share Lock 획득, 쓰기 시 Exclusive Lock으로 escalation
  • 읽을 때는 여러 명, 쓸 때는 한 명만!
• Lock 상호 배제
  • Share Lock ↔ Exclusive Lock
  • 특이한 점: Share Lock이 걸려있으면 Exclusive Lock을 걸 수 없음
    • snapshot isolation과 다른 점
• 단계?
  • 1단계
    • 잠금 획득
  • 2단계
    • (commit, abort 시)잠금 해제
• 매우 쉬운 데드락
  • 보통 DB에서 감지하고 트랜잭션 중 하나를 실패 처리 → 앱에서 재시도해야함.
• 팬텀 리드 막는 법
  • 서술 잠금(predicate lock)
    • 범위 기반
      • 미래에 추가되는 객체에도 적용 가능
    • 잠금이 많을 경우 성능 이슈
  • 색인 범위 잠금(index-range locking, next-key locking)
    • 실제 데이터가 아닌 색인에 잠금
    • 서술 잠금을 색인 잠금으로 근사
      • 11시~1시 방 잡기
        • 방 → room_id index 잠금
        • 시간 → start_date index 잠금
  • 테이블 잠금
    • 조건을 잡아낼 수 없을 때

SSI(Serialized Snapshot Isolation)

• 스냅숏 격리 + 색인 잠금

낙관적 동시성 제어 구현

• 다른 트랜잭션 작업 완료를 하지 않는다
• 데이터 읽기
  • 커밋되지는 않았으나 실행되는 트랜잭션이 있는지 확인
  • 해당 데이터에 자신의 트랜잭션 id를 기록
    • 인덱스(어려울 경우 테이블)
• 데이터 쓰기
  • 읽었던 데이터들이 다른 트랜잭션에 의해 쓰기 commit이 이루어 졌는지 확인
    • 있을 경우 → abort(앱에서 재시도)
    • 없을 경우 → commit

기타 커스텀

• DB에서 보장해주지 못하는 동시성 문제가 발생할 경우, 애플리케이션 사용자가 직접 lock을 거는 것이 좋음
• SELECT … FOR UPDATE