[29일차] | 대규모 시스템 설계 기초2 | 책너두

방안 1: 비관적 락

• 비관적 동시성 제어방안
• 사용자가 업데이트를 시도하는 순간 락을 걸어 다른 사용자가 업데이트를 시도하지 못하도록 한다.
  • 다른 사용자는 현재 사용자가 업데이트를 완료할 때까지 대기해야 한다.
• 장단점
  • 장점
    • 모든 갱신을 직렬화하여 충돌을 막을 수 있다.
    • 데이터 경합이 심할 때에도 무결성을 보장할 수 있다.
  • 단점
    • 여러 레코드에 락이 걸리면 교착상태(deadlock)가 발생할 수 있다.
    • 트랜잭션이 길어지면 락을 유지하는 시간이 길어지므로 성능이 저하될 수 있다.

방안 2: 낙관적 락

• 낙관적 동시성 제어방안
• 버전번호나 타임스탬프 등을 사용하여 데이터의 버전을 관리한다.
  • 일반적으로는 버전번호를 사용한다. 서버 시간은 부정확해 질 수 있기 때문이다.
• 장단점
  • 장점
    • 실제로 락을 걸지 않으므로 성능이 좋다.
    • 일관성 유지의 책임을 애플리케이션으로 위임할 수 있다.
  • 단점
    • 동시성 수준이 매우 높은 시스템에서는 성능 저하가 더 심해질 수 있다.
• 이 사례의 경우, 예약확정의 QPS가 약 3으로 추정되므로 비관적 락을 사용하는 것이 적절하다.

방안 3: 데이터베이스 제약 조건

• 낙관적 락과 유사한 방식으로 동작한다.

• 데이터베이스에 아래와 같은 제약 조건(예시)을 추가한다.

  • 예시

    CONSTRAINT "check_room_count" CHECK(("total_inventory - total_reserved" >= 0))

    • 이를 통해 데이터 업데이트 전에 데이터베이스가 자동으로 예약 충돌을 방지한다.

• 장단점

  • 장점
    • 데이터베이스가 자동으로 충돌을 방지하므로 개발자가 락을 걸지 않아도 된다. 즉, 구현이 쉽다.
  • 단점
    • 경쟁이 심한 경우 데이터베이스 성능이 저하될 수 있다.
    • 데이터베이스의 제약조건은 코드와 같이 버전관리가 어렵다. 이로 인해 관리가 어렵다.
    • 데이터베이스에 따라 이 기능을 지원하지 않을 수 있다. 따라서 새로운 데이터베이스로의 마이그레이션이 어려울 수 있다.