07장: 트랜잭션

[minkukjo]

끄적끄적

• 너무너무너무너무 중요한 트랜잭션... 요즘 이거 때문에 머리가 많이 아프다.
• 현대의 데이터 시스템은 많은 문제를 안고 있다.
  • 동시성 문제
  • 트랜잭션의 실패 (하드웨어, 소프트웨어, 네트워크 이슈 등등 )
• 트랜잭션은 위와 같은 문제를 풀어내는 메커니즘으로 사용되어 왔다.
• 트랜잭션은 두 개의 파로 나뉘어졌는데,
  • 높은 성능과 고가용성을 얻으려면 트랜잭션을 포기해야할 수 있다는 파와
  • 값진 데이터가 있는 애플리케이션에서 트랜잭션은 필수라는 파
• 저자는 두 관점 모두 과장되었다고 한다.
• 일반적으로 ACID에 대한 개념 설명을 하고 있다.
  • 원자성은 동시성과 관련이 없는 개념임
  • 오류가 생기면 무조건 롤백하거나 (abort) 커밋한다는 두 가지 상태만 존재하는 것이 원자성
  • 일관성은 굉장히 여러 의미로 쓰이는데, 여기서 말하는 일관성이란 애플리케이션의 속성에 더 가깝다고 저자는 말한다. ( 사실 이부분은 다소 동의하기 어렵다. 왜냐하면 유일키에 대한 정의는 DB에서 이루어지는데 어째서 이게 애플리케이션의 속성이라고 말하는지? )
• 데이터베이스가 제공해주는 격리 수준은 우리 생각보다 완화된 버전이다. 결국 개발자들이 이것을 챙겨야한다.
• 트랜잭션 격리 레벨을 read uncommitted, read committed 등을 그대로 한국어로 번역해서 처음에 뭔가 싶었다. 번역자 꿀밤이 마려웠다.
• Snapshot 격리를 위해서 MVCC에 대한 설명을 하고 있다.
  • 포스트그레 SQL처럼 txID를 관리해서 처리하거나
  • 이건 처음 봤는데 카우치 DB나 데이톰기과 같은 곳에서는 쓰기 전용 B 트리?를 만들어서 복제본으로 관리한다고 한다.
• Repeatable Read라는 이름이 모호하다고 하는데 공감한다. 표준이 없어서 그렇다는 말에도 끄덕 끄덕
• 트랜잭션 자체를 제거해버리고 실제적으로 직렬 실행하게 해주는 DB들도 있다. 대표적으로 레디스, 볼트DB , 데이토믹 등이 그렇다.
• 2PL 투페이즈 락킹이라는 개념이 나오는데, MySQL의 InnoDB가 사용하는, Shared Mode와 Exclusive Mode에 대한 내용이었다.
• MySQL의 경우 레코드락 앞 뒤로 락을 거는 Gap Lock, Gap Lock + Record Lock을 합친 Next Key Lock이 존재한다. 책에서도 Next key Lock, index range locking, predicate lock을 설명하고 있다.
• 기술 면접에서 주로 물어보는 트랜잭션에 대한 거의 모든 내용을 다루고 있었다. 👍

[MinJunKweon]

끄적끄적

• 단골주제 트랜잭션.. JPA에서 봤던 내용도 많이 겹침
• 2페이즈 락킹을 애플리케이션에서 구현할 케이스가 몇번 있었는데, 다른 분들도 있으신지?
• 너무 짧으니 스프링에서 @Transactional 어노테이션 사용할 때 주의사항 하나 공유합니다. (https://cheese10yun.github.io/spring-transacion-same-bean/)
  • 같은 class 내에서 @Transactional 어노테이션이 붙은 메소드 사용 시 의도한대로 동작하지 않음
  • 원인 : AOP가 Proxy Bean으로 동작하기 때문
  • 유사사례 : Resilience4j 또한 Proxy Bean으로 동작하기 때문에 이 같은 이슈가 있을 수 있습니다. 주의!

[HaeUlNam]

• 트랜잭션으로 인해 부분실패를 막고, 전체 성공/실패
• ACID(Atomic, Consistency, Isolation, Durability)
  • Atomic: 더 작은 부분으로 쪼갤 수 없는 뭔가를 가리킨다. 오류가 생겼을 때 트랜잭션을 abort하고 해당 트랜잭션에서 기록한 모든 내용을 취소하는 능력은 ACID 원자성의 결정적인 특징
  • Consistency: 데이터 불변. 일관성을 유지하도록 트랜잭션을 올바르게 정의하는 것은 애플리케이션의 책임. 데이터베이스는 불변식을 위반하는 잘못된 데이터를 쓰지 못하도록 막을 수는 없다
  • Isolation: 동시에 실행되는 트랜잭션은 서로 격리된다는 것을 의미
    • 금융/생명 등과 직결되는 시스템에서만 Serializable isolation 쓰고 나머지는 거의 쓸 이유가 없을듯?
  • Durability: 트랜잭션이 성공적으로 커밋됐다면 하드웨어 결함이 발생허가나 데이터베이스가 죽더라도 트랜잭션에서 기록한 모든 데이터는 손실되지 않는다.
    • e.g. write-ahead log처럼 비휘발성 저장소에 기록되었다는 뜻
    • 완벽한 지속성은 존재하지 않는다. 모든 하드디스크와 백업이 동시에 파괴돼 버리면..
• 오류와 Abort 처리
  • 부분 실패 시 트랜잭션을 실패처리하고, 필요하다면 retry 로직으로 재처리할 수 있도록 하면 될 듯
  • Retry는 exponential backoff를 사용하는 게 좋을 듯 (Resilience4j에서도 지원해주는 기능)
• Isolation level
  • Read committed
    • DB에서 읽을 때 커밋된 데이터만 보게 된다(No Dirty read)
    • DB에서 쓸 떄 커밋된 데이터만 덮어쓰게 된다(No Dirty write)
    • 단순히 잠금만으로는 Dirty read를 구현하기에 성능이 좋지 않음으로 아래와 같은 방식을 사용하게 됨.
      • 과거 commit된 값과 현재 트랜잭션의 새로운 값을 모두 기억해서 트랜잭션이 실행중인 경우 과거 값을 읽고, commit된 후에는 새로운 값을 읽게 함.
• Repeatable read
  • Snapshot 격리: 트랜잭션은 시작할 때 데이터베이스에 커밋된 상태였던 모든 데이터를 본다. 데이터가 나중에 다른 트랜잭션에 의해 바뀌더라도 각 트랜잭션은 특정한 시점의 과거 데이터를 볼 뿐
    • Multi-version concurrency control(MVCC)
    • txid
• Lost update
  • 두 트랜잭션에서 read-modify-write 주기가 생길 경우 발생할 수 있다. 두번째 쓰기 작업이 첫번째 변경을 포함하지 않으므로 변경 중 하나는 손실될 수 있다.
  • Cursor stability: 원자적 연산은 보통 객체를 읽을 때 exclusive 잠금을 획득해서 구현한다. 갱신이 적용될 때까지 다른 트랜잭션에서 그 객체를 읽지 못하게 한다.
  • 대안으로 병렬 실행을 허용하고, 트랜잭션 관리자가 갱신 손신을 발견하면 트랜잭션을 어보트시키고 read-modify-write 주기를 재시도하도록 강제하는 방법이 있다.
  • compare-and-set?

[2rohyun]

끄적끄적

---

• 다 못읽음.. 흑흑 너무 오래 걸리네요.
• 어렵다 어려워.. 개인적으로는 서비스를 개발할 때 가장 중요한 부분이라고 생각
• 기본적으로 클라이언트 따닥 이슈, 성능적으로 영향을 끼치지 않을 것 같은 부분은 레디스 분산락 사용 (redisson)
• "맹목적으로 도구에 의존하기보다는 존재하는 동시성 문제의 종류를 잘 이해하고 방지하는 방법을 배울 필요가 있다. 그러면 사용 가능한 도구를 써서 신뢰성 있고 올바르게 동작하는 애플리케이션을 만들 수 있다." 라는 구절에 완전 공감.
• 평소에는 느낌으로 아, 여기 동시성 문제 생길 것 같은데 또는 느낌적으로 race condition 이 발생할 수 있을 것 같은 부분에는 read-modify-write 을 최대한 지양하려고 하고.. 여기에 Compare-and-set 이라고 표현하는 where 조건에 old content 를 넣어 멱등성을 보장하는 형태로 사용했는데 항상 구체적으로 어떤 문제를 예방할 수 있는지 정확히 그려지지는 않았음.
• 이 챕터를 여러 번 읽어서 좀 체득하고 위에 책에 기술되어 있는 것 처럼 동시성 문제를 머릿 속에 체계적으로 정리하고, 실제 비지니스 요구사항에 대한 구현을 마주쳤을 때 adaptable 하게 동시성을 제어하는 것이 중요하다고 생각 (적용 또는 응용?)