TIL

07장 트랜잭션

애매모호한 트랜잭션의 개념

• 현대 거의 모든 관계형/비관계형 데이터베이스는 트랜잭션을 지원한다.
• NoSQL이 인기를 얻기 시작하면서 새로운 세대의 데이터베이스 중 다수는 트랜잭션을 완전히 포기하거나 약한 보장을 지원하기 시작했다.
• 이러한 분산 데이터베이스들의 등장은 고가용성을 유지하려면 트랜잭션을 포기해야 한다는 잘못된 믿음이 퍼지기도 했다.
• 트랜잭션에 존재하는 이점과 한계, 트레이드 오프를 이해할 필요가 있다.

ACID의 의미

• 실제로는 데이터베이스마다 ACID 구현은 제각각이며 격리성에는 특히 모호함이 많이 있다.
• ACID 표준을 따르지 않는 시스템은 BASE라 불리기도 한다.
  • 기본적인 가용성(Basically Available)을 가지며 유연하고(Soft state), 최종적 일관성(Eventual consistency)을 지닌다는 뜻
• 원자성 (Atomicity)
  • 시스템은 연산을 실행하기 전이나 후의 상태만 있을 수 있으며 중간 상태에서 머물 수 없다.
  • 오류가 발생하면 트랜잭션을 어보트하고 해당 트랜잭션의 모든 내용을 취소하는 능력
  • 원자성은 시스템에 오류가 발생했을 때의 재연산 문제를 단순하게 만들어준다.
  • 원자성은 동시성과 관련이 없는데 이는 여러 프로세스의 동시 접근 시 무슨 일이 생기는지 설명하지 않기 때문이다.
    • 이 문제는 격리성과 관련이 있다.
• 일관성 (Consistency)
  • 일관성은 항상 진실이어야 하는 데이터에 대한 어떤 선언(불변식)을 지키는 속성이다.
  • 하지만 일관성은 애플리케이션 로직에서 제어되어야 하며 데이터베이스는 불변식을 위반하는 데이터를 쓰지 못하도록 막을 수 없다.
    • 외래 키 제약 조건 등은 제외
  • 다른 속성들과 달리 데이터베이스는 일관성을 달성하지 못한다고도 할 수 있다.
• 격리성 (Isolation)
  • 동시에 실행되는 트랜잭션은 서로 격리된다는 것을 의미
  • 직렬성 격리를 사용하면 여러 트랜잭션이 동시에 실행됐더라도 커밋 후의 결과가 순차적으로 실행됐을 때의 결과와 동일하도록 보장한다.
  • 하지만 직렬성 격리는 성능 손해를 동반하기에 거의 사용하지 않고 직렬성 보단 보장이 약하지만 스냅숏 격리를 사용하기도 한다.
• 지속성(Durability)
  • 트랜잭션이 성공적으로 커밋됐다면 장애가 발생하더라도 데이터는 손실되지 않는다는 보장
  • 단일 노드 데이터베이스에선 비휘발성 저장소에 데이터가 기록됐다는 것이고 복제 노드가 있는 데이터베이스에서는 성공적으로 다른 노드 몇 개에 저장했다는 것을 의미할 수도 있다.
  • 당연하지만 완벽한 지속성은 존재하지 않는다.
    • 모든 하드디스크와 백업이 파괴되는 경우

단일 객체 연산과 다중 객체 연산

• 다중 객체 트랜잭션 상황에서 데이터들이 동기화된 상태로 유지해야할 필요가 있다.
  • 원자성을 통해 오류가 발생해도 전부 반영되거나 전부 반영되지 않게 한다.
  • 격리성을 통해 여러 트랜잭션이 실행되어도 서로의 중간 내용을 볼 수 없게 한다.
• 비관계형 데이터베이스엔 관계형처럼 연산을 묶는 방법이 없는 경우가 많다.
  • 한 연산 내에 여러 키를 갱신하는 다중 연산에서 부분적으로 갱신된 상태가 도출될 수도 있는 것
• 원자성과 격리성은 단일 객체를 변경하는 경우에도 적용된다.
  • 원자성은 장애 복구용 로그를 써서 구현 가능
  • 격리성은 각 객체에 잠금을 사용해 구현 가능
  • 이러한 단일 객체 연산은 동시에 같은 객체에 쓰려고 할 때 갱신 손실을 방지하는데 유용하다.
• 다중 객체 트랜잭션의 필요성
  • 많은 분산 데이터베이스는 다중 객체 트랜잭션 지원을 포기했는데 이는 여러 파티션에 걸친 트랜잭션을 구현하기 매우 까다롭고 높은 가용성과 성능에도 방해되기 때문이다.
  • 단일 객체 연산만으로 충분한 사용 사례도 많지만 다중 객체 연산이 필요할 때도 있다.
    • 관계형 데이터 모델에서 외래 키 참조가 유효하도록 보장
    • 비정규화된 정보를 갱신할 때 한 번에 여러 객체를 갱신해야 한다.
    • 보조 색인이 있는 경우 값을 변경할 때 색인도 갱신되어야 한다.
• 오류 발생 시의 어보트 처리는 효과적이지만 어보트된 트랜잭션을 재시도하는 것은 생각해볼 필요가 있다.
  • 트랜잭션이 실제론 성공했지만 클라이언트에게 커밋 성공 메시지를 네트워크 오류로 알리지 못한 경우 재시도는 트랜잭션을 두 번 실행하게 한다.
  • 오류가 과부하 때문이라면 트랜잭션 재시도는 문제를 악화시킬 수 있다.
  • 일시적인 오류만 재시도 가치가 있고 영구적인 오류는 재시도해도 소용이 없다.
  • 트랜잭션 재시도가 외부 시스템에 부수 효과를 일으킬 수도 있다. ex) 이메일 전송 기능에 이메일이 2번 감

완화된 격리 수준

• 동시성 문제는 다음 두 경우에 발생한다.
  • 트랜잭션이 다른 트랜잭션에서 동시에 변경한 데이터를 읽을 때
  • 두 트랜잭션이 동시에 같은 데이터를 변경하려고 할 때
• 데이터베이스는 트랜잭션 격리를 제공해 동시성을 해결하려고 하지만 현실은 그리 간단하지 않다.
  • 직렬성 격리는 성능 비용이 많음
  • 완화된 격리 수준을 사용하는 데이터베이스가 많은데 이해하기 훨씬 어렵고 미묘한 버그를 발생시킬 수도 있다.

커밋 후 읽기

• 커밋 후 읽기 (read committed)는 가장 기본적인 수준의 트랜잭션 격리이다.
  • 커밋된 데이터만 보게 된다. (더티 읽기가 없음)
  • 커밋된 데이터만 덮어쓰게 된다. (더티 쓰기가 없음)
• 더티 쓰기를 방지하는 가장 간단한 방법은 트랜잭션에서 특정 객체(로우)에 잠금을 거는 것이다.
• 더티 읽기 또한 잠금을 통해 읽으면 커밋 후 읽기를 보장할 수 있다.
• 하지만 이러한 직렬성 격리는 트랜잭션 대기 시간을 증가 시키고 성능에 해를 끼친다.

스냅숏 격리와 반복 읽기

• 커밋 후 읽기를 보장해도 반복 가능한 읽기가 되지 않아 버그가 발생할 수 있다.
  • 반복 가능한 읽기가 되지않아 발생하는 현상을 nonrepeatable read 또는 읽기 스큐(read skew)라 한다.
• 스냅숏 격리는 반복 가능한 읽기를 구현하는 가장 흔한 방법이다.
  • 각 트랜잭션은 데이터베이스의 일관된 스냅숏으로부터 데이터를 읽는다.
  • 다른 트랜잭션에 의해 데이터가 바뀌더라도 각 트랜잭션은 특정 시점의 스냅숏을 볼 뿐이다.
• 스냅숏 격리의 핵심 원리 - 읽는 쪽에서 쓰는 쪽을 결코 차단하지 않고 쓰는 쪽에서 읽는 쪽을 결코 차단하지 않는다는 것
  • 쓰기 트랜잭션은 같은 객체에 쓰려는 다른 트랜잭션은 차단할 수 있지만 읽을 때는 잠그지 않는다.
• 스냅숏 격리의 구현
  • 데이터베이스는 객체마다 커밋된 버전 여러 개를 유지한다.
  • 진행 중인 트랜잭션에서 서로 다른 시점의 데이터베이스 상태를 봐야하기 때문
  • 이러한 기법을 다중 버전 동시성 제어 (multi-version-concurrency control, MVCC)라 한다.
• PostgreSQL의 MVCC 구현 예
  • 트랜잭션에는 고유한 ID(txid)가 할당된다.
  • 테이블 각 로우에는 그 로우를 삽입한 txid를 갖는 created_by 필드와 그 로우를 삭제한 txid를 갖는 deleted_by 필드를 갖는다.
  • 트랜잭션이 로우를 삭제하면 deleted_by를 해당 txid로 설정한 뒤 남겨두었다가 모든 트랜잭션이 더 이상 삭제된 로우에 접근하지 않는 게 확실해지면 가비지 컬렉션 프로세스가 해당 로우를 완전히 삭제한다.
• 일관된 스냅숏을 보는 가시성 규칙
  • 각 트랜잭션을 시작할 때 그 시점에 진행 중인 모든 트랜잭션 목록을 만들고 이 트랜잭션들이 쓴 데이터는 모두 무시된다.
  • 어보트된 트랜잭션이 쓴 데이터는 모두 무시된다.
  • 트랜잭션 ID가 더 큰 트랜잭션이 쓴 데이터는 그 트랜잭션 커밋 여부에 관계 없이 모두 무시된다.
  • 그 밖의 모든 데이터는 애플리케이션 질의로 볼 수 있다.
• 색인과 스냅숏 격리 환경에서 색인 구현 주요 방식
  • 모든 버전 참조 - 색인이 객체의 모든 버전을 가리키면서 질의 시 현재 트랜잭션에서 볼 수 없는 버전을 필터링
  • PostgreSQL - 동일 객체의 다른 버전들이 같은 페이지(page)에 저장될 수 있다면 색인 갱신을 회피하는 최적화를 하기도 한다.
  • append-only/copy-on-write - 트리의 페이지가 갱신될 때 덮어쓰는 대신 각 변경된 페이지의 새로운 복사본을 생성
  • 추가 전용 B 트리 - 쓰기를 실행하는 모든 트랜잭션은 새로운 B 트리 루트를 생성하며 특정 루트는 그것이 생성된 시점에 해당하는 데이터베이스의 일관된 스냅숏이 된다.
    • txid를 기반으로 객체를 걸러낼 필요 없이 각 시점 트리를 참조하면 된다.

갱신 손실 방지

• 갱신 손실 문제
  • 애플리케이션이 데이터베이스에서 값을 읽고 변경한 후 변경된 값을 다시 쓸 때 발생할 수 있는 문제
  • 두 트랜잭션이 동시에 위 작업을 하면 첫 번째 변경이 손실될 수 있다.
  • 갱신 손실을 해결하는 여러 방법이 있다.
• 원자적 쓰기 연산
  • 관계형 데이터베이스에서 UPDATE counters SET value = value = 1 WEHRE key = ‘foo’; 연산은 원자적으로 동작해 동시성 안전하다.
  • 몽고 DB 등은 JSON 문서 일부를 지역적으로 변경하는 원자적 연사을 제공한다.
  • 하지만 객체 관계형 매핑 프레임워크를 사용하다 보면 원자적 연산을 사용하지 못할 때가 있다.
• 명시적인 잠금
  • 갱신할 객체를 명시적으로 잠근다면 다른 트랜잭션에서 접근하지 못하고 기다리게 된다.
  • 명시적 잠금은 올바르게 동작하지만 애플리케이션 로직에 대해 신중하게 생각하지 않으면 잠그는 것을 잊어버려 경쟁 조건을 유발하기 쉽다.
• 갱신 손실 자동 감지
  • 순차 실행을 강제하는 위 두 방법과 달리 병렬 실행을 허용하고 갱신 손실 감지 시 트랜잭션을 어보트시키는 방법이 있다.
  • 데이터베이스가 갱신 손실 확인을 스냅숏 격리와 결합해 효율적으로 수행할 수 있는 이점이 있다.
  • PostgreSQL의 반복 읽기, 오라클의 직렬성 등이 갱신 손실을 감지해 트랜잭션을 자동으로 어보트시킨다.
  • 하지만 MySQL/InnoDB의 반복 읽기는 갱신 손실을 감지하지 않는다.
• Compare-and-set
  • 값을 마지막으로 읽은 후로 변경되지 않았을 때만 갱신을 허용하는 방식
  • 트랜잭션을 제공하지 않는 데이터베이스 중에서 Compare-and-set 연산을 제공하는 것도 있다.
• 충돌 해소와 복제
  • 복제가 적용된 데이터베이스에선 데이터가 다른 노드들에서 동시 변경될 수 있기에 문제가 더 복잡하다.
  • 복제가 있는 상황에선 한 값에 대해 여러 충돌된 버전을 생성하는 것을 허용하고 사후에 이를 해소하는 방식을 사용한다.

쓰기 스큐와 팬텀

• 쓰기 스큐 (write skew)
  • 두 트랜잭션이 동일한 데이터를 읽고 각각 다른 부분을 수정할 때, 트랜잭션 격리 수준이 충분히 높지 않아 발생하는 데이터 일관성 문제
  • 각 트랜잭션이 공통된 데이터를 읽은 뒤 이를 기반으로 내린 결정으로 서로 다른 객체를 수정한 결과가 전체적인 일관성 제약 조건을 위반하는 경우
  • ex) 적어도 1명의 당직이 있어야 하는 일관성 규칙에서 서로 다른 트랜잭션이 2명의 당직이 있다는 사실을 확인 후 각각 서로 다른 당직을 제외시켜버려 당직이 사라지는 문제가 발생
• 쓰기 스큐가 발생하는 여러 상황이 있지만 모두 비슷한 패턴을 따른다.
  • SELECT 질의가 어떤 로우를 검색함으로써 어떤 요구사항을 만족하는지 확인
  • 첫 번째 질의 결과에 따라 애플리케이션 코드가 어떠한 진행을 결정
  • 트랜잭션을 커밋하자 이 쓰기의 효과로 2단계를 결정한 전제 조건이 변경되어 일관성이 깨진다.
• 쓰기 스큐를 해결하기 위한 선택지는 더 제한적이다.
  • 같은 객체를 수정할 때 발생하는 문제도 아니기에 단일 객체에 대한 원자적 연산은 도움이 되지 않는다.
  • 트랜잭션이 의존하는 로우(ex. 당직 수)를 명시적으로 잠그는 것이 차선책
• 팬텀 (phantom)
  • 어떤 트랜잭션에서 실행한 쓰기가 다른 트랜잭션의 검색 질의 결과를 바꾸는 효과
  • 팬텀이 쓰기 스큐의 특히 까다로운 경우를 유발할 수도 있다.
  • 팬텀이 문제가 되는 점은 잠글 수 있는 객체가 없다는 것이다.
• 충돌 구체화(materializaing conflict)
  • 팬텀 현상을 방지하기 위해 인위적으로 잠글 수 있는 객체를 추가하는 것
  • 트랜잭션이 이러한 로우에 대한 잠금을 획득하여 팬텀 현상을 방지
  • ex) 당직 문제의 경우 시간 슬롯에 대한 테이블을 만들어 잠그는 방법을 사용할 수 있다.
  • 하지만 충돌 구체화는 다른 대안이 불가능할 때 최후 수단으로 고려해야 한다.
    • 충돌 구체화는 방법을 알아내기 어렵고 오류가 발생하기 쉽다.
    • 동시성 제어 메커니즘이 애플리케이션 데이터 모델로 도출되는 것도 보기 좋지 않다.

직렬성

• 여러 경쟁 조건을 해결하는 방법은 결국 직렬성 격리를 사용하는 것이다.
  • 여러 트랜잭션이 병렬로 실행되더라도 최종 결과는 직렬로 실행될 때와 같도록 보장
• 직렬성을 구현하는 선택지
  • 말 그대로 트랜잭션을 순차적으로 실행
  • 2단계 잠금 (2PL)
  • 낙관적 동시성 제어

실제적인 직렬 실행

• 한 번에 트랜잭션 하나씩만 직렬로 단일 스레드에서 실행하는 방법
• 트랜잭션의 단일 스레드 실행이 가능한 이유
  • 램 가격이 저렴해져서 활성화된 데이터셋 전체를 메모리에 유지할 수 있게 되었다.
  • 트랜잭션이 접근해야 하는 데이터가 메모리에 있다면 빠르게 실행될 수 있다.
  • OLTP 트랜잭션이 보통 짧고 실행하는 읽기/쓰기 개수가 적다.

• 단일 스레드로 실행되는 시스템이 동시성을 지원하는 시스템보다 성능이 좋을 때도 있지만 처리량이 CPU 코어 하나로 제한되기에 트랜잭션이 전통적인 형태와는 다르게 구조화되어야 한다.

• 트랜잭션을 스토어드 프로시저 안에 캡슐화
  • 보통 애플리케이션이 질의를 하고 그 결과를 읽고, 첫 질의 결과에 따라 다른 질의를 실행하는 식으로 로직이 동작한다.
    • ex) 항공권 예약 시 경로, 요금, 좌석을 탐색하고, 일정을 정하고, 비행기 좌석을 선택하는 등의 일련의 과정을 거친다.
  • 하지만 이러한 상호작용은 애플리케이션과 데이터베이스 사이의 네트워크 통신에 많은 시간을 소비한다.
  • 단일 스레드 직렬성 기반의 데이터베이스는 성능을 위해 스토어드 프로시저를 사용한다.
  • 스토어드 프로시저
    • SQL 문들을 하나의 함수처럼 실행할 수 있게 해주는 데이터베이스 객체
  • 단일 스레드 트랜잭션에서 스토어드 프로시저 사용의 장점
    • 여러 SQL 문을 한 번의 호출로 실행할 수 있어 네트워크 트래픽을 줄인다.
    • 트랜잭션에 필요한 데이터가 모두 메모리에 있으면 디스크 I/O 오버헤드 없이 빠르게 실행된다.
    • 별도의 동시성 제어 메커니즘이 필요없어 오버헤드를 피할 수 있다.
• 파티셔닝
  • 여러 파티션으로 분리된다면 각 파티션은 자신만의 트랜잭션 처리 스레드를 가지고 처리량을 선형적으로 확장할 수 있다.
  • 하지만 트랜잭션이 여러 파티션에 접근해야 한다면 직렬성을 보장하기 위해 전체 파티션을 잠그고 코디네이션을 해야 하는데 오버헤드를 피할 수 없다.
  • 트랜잭션을 단일 파티션 내에서 실행될 수 있는지 여부는 애플리케이션에서 사용하는 데이터 구조에 크게 의존한다.

2단계 잠금(2PL)

• 2PL (2 Phase Locking, 2단계 잠금)
  • 데이터베이스에서 직렬성을 구현하는 데 널리 쓰인 알고리즘
  • 동시성을 제어하고 직렬성을 보장하기 위한 프로토콜
  • 2PL을 쓰면 다른 쓰기 트랜잭션뿐 아니라 읽기 트랜잭션도 진행하지 못하게 막는다.
• 2단계 잠금 구현
  • 읽기와 쓰기를 막는 것은 데이터베이스 각 객체에 잠금을 사용해 구현한다.
    • 공유 락이나 베타 락을 사용
  • 잠금이 아주 많이 사용되기에 교착 상태에 빠질 수도 있다.
• 2단계 잠금의 성능
  • 2단계 잠금은 트랜잭션 처리량과 질의 응답 시간이 크게 나빠진다.
  • 동시성이 줄어들어 트랜잭션이 일렬로 처리되기 때문이다.
• 서술 잠금 (predicate lock)
  • 쓰기 스큐를 유발하는 팬텀을 해결하기 위해 사용 가능한 방법
  • 특정 객체를 잠그는 것이 아닌 어떤 검색 조건에 부합하는 모든 객체를 잠그는 행위
  • 서술 잠금의 핵심은 아직 없지만 미래에 추가될 수도 있는 객체(팬텀)에도 적용 가능하다는 점이다.
  • 2PL과 함께 사용하면 모든 형태의 쓰기 스큐와 다른 경쟁 조건을 막는 직렬성 격리를 구현 가능하다.
  • 하지만 진행 중인 트랜잭션들이 획득한 잠금이 많다면 검색 조건에 부합하는 잠금을 확인하는 데 오래 걸린다.
• 색인 범위 잠금
  • 서술 잠금의 단점으로 인해 서술 잠금을 간략하게 근사한 잠금
  • 검색 조건에 인덱싱이 붙은 칼럼이 있는 경우 사용
  • 서술 잠금보다 정밀하진 않지만 오버헤드가 훨씬 낮다.

직렬성 스냅숏 격리(SSI)

• 직렬성 스냅숏 격리 (serializable snapshot isolation, SSI)
  • 완전한 직렬성을 제공하지만 스냅숏 격리에 비해 약간의 성능 손해를 가지는 알고리즘
  • 낙관적 접근 - 낙관적 동시성 제어 기법을 사용해 커밋 시점에 충돌을 검사한다.
  • 직렬성 충돌 감지 - 스냅숏 격리 위에 쓰기 작업 사이의 직렬성 충돌을 감지하고 어보트시킬 트랜잭션을 결정하는 알고리즘을 추가
• 직렬성 격리를 제공하려면 데이터베이스는 트랜잭션이 뒤처진 전제를 기반으로 동작한다는 것을 고려해야 한다.
  • 트랜잭션을 커밋하려는 시점에 원래 데이터가 바뀌어서 전제가 더 이상 참이 아닐 수 있다.
• 오래된 MVCC 객체 버전을 읽었는지 감지하기
  • 전제가 달라지는 현상을 막으려면 MVCC 가시성 규칙에 따라 다른 트랜잭션의 쓰기(커밋되지 않은 쓰기 등)를 무시하는 경우를 추적해야 한다.
  • 무시된 쓰기 중 커밋된 게 있다면 트랜잭션을 어보트한다.
• 과거의 읽기에 영향을 미치는 쓰기를 감지하기
  • 트랜잭션이 쓰기를 수행할 때 실행되어 현재 쓰기가 다른 트랜잭션의 읽기에 영향을 미치는지 확인한다.
  • 데이터베이스는 질의 조건의 색인에 기반하여 어떤 트랜잭션들이 특정 데이터를 읽었는지 기록할 수 있다.
  • 같은 데이터를 읽는 트랜잭션끼리 서로 읽은 데이터가 뒤쳐졌다고 알려주고, 나중에 커밋을 시도하는 트랜잭션이 충돌을 감지해 어보트된다.
• 직렬성 스냅숏 격리의 성능
  • 2단계 잠금과 달리 트랜잭션이 다른 트랜잭션을 기다릴 필요가 없다.
  • 읽기와 쓰기가 서로를 차단하지 않아 지연 예측이 쉽고 변동이 적다.
  • 읽기 전용 질의는 잠금 없이 일관된 스냅숏에서 실행 가능하다.
  • 단일 CPU 처리량에 제한되지 않으며 여러 파티션에 걸친 트랜잭션도 직렬성을 보장하면서 처리할 수 있다.
  • 다만 트랜잭션 동작을 상세히 추적해야 하고, 경쟁이 심할 경우 어보트되는 트랜잭션 비율이 높아져 오버헤드가 발생할 수도 있다.
  • 그래도 비관적 동시성 제어보단 충분히 좋은 성능을 제공하는 편이다.