Amazon Aurora DSQL의 낙관적 동시성 제어 (Optimistic Concurrency Control)

자세한 내용 : https://gemini.google.com/app/b79936baaab7f162

 

4줄 요약 :

1. 현대 웹/앱 워크로드 환경에서 동일한 밀리초에 동일한 레코드로 경합이 벌어질 가능성이 매우 낮다.

2. 따라서 충돌이 일어나지 않을 것이라고 낙관적으로 가정하고, 데이터베이스의 퍼포먼스를 챙긴다.

3. 반짝 세일처럼, 동일한 밀리초에 동일한 레코드로 충돌이 벌어질 것 같으면 큐로 처리한다.

4. 단, 트레이드 오프로 애플리케이션 단에서 견고한 충돌 감지 및 리트라이 로직이 필요하다.

 

낙관적 원칙: 조화를 가정하고 마지막에 검증하라

낙관적 동시성 제어(OCC)는 충돌이 드물 것이라는 "낙관적인" 가정에 기반합니다. 이 방식은 잠금의 선행 비용을 피함으로써 처리량을 극대화하는 데 우선순위를 둡니다.

 

동시성 처리 부담의 철학적 전환

PCC와 OCC 사이의 선택은 '동시성 처리의 부담'을 어디에 둘 것인가에 대한 근본적인 철학의 전환을 의미합니다. PCC는 그 부담을 전적으로 데이터베이스 시스템에 지웁니다. 데이터베이스는 복잡한 잠금 테이블을 관리하고, 교착 상태를 감지하며, 트랜잭션을 대기시키는 책임을 집니다. 이로 인해 애플리케이션 코드는 데이터가 사용 가능해질 때까지 단순히 대기하면 되므로 상대적으로 단순해질 수 있습니다.

반면, OCC는 그 부담의 상당 부분을 애플리케이션 계층으로 이전시킵니다. 데이터베이스의 역할은 원자적인 '확인 후 설정(check-and-set)' 연산을 제공하는 것으로 단순화됩니다. OptimisticLockException과 같은 예외를 포착하고, 전체 비즈니스 트랜잭션을 재시도할지, 몇 번이나 재시도할지, 그리고 모든 재시도가 실패했을 때 어떻게 처리할지를 결정하는 것은 온전히 애플리케이션의 책임이 됩니다.

결과적으로, 동시성 모델의 선택은 단순한 데이터베이스 성능 튜닝 결정을 넘어, 전체 시스템 아키텍처에 관한 결정이 됩니다. Aurora DSQL과 같이 OCC 기반 시스템을 선택하는 팀은 더 정교한 애플리케이션 수준의 오류 처리 및 재시도 로직에 투자할 준비가 되어 있어야 합니다. 데이터베이스 수준의 복잡성을 희생하여 잠재적으로 더 높은 처리량을 얻는 대신 애플리케이션 수준의 복잡성을 감수하는 이 트레이드오프가 바로 "낙관적 베팅"의 핵심입니다.

 

가설 1: 현대 웹 스케일 워크로드의 본질은 본래 낙관적이다

대다수의 현대 클라우드 네이티브 애플리케이션은 읽기 대 쓰기 비율이 압도적으로 읽기 쪽으로 치우쳐 있습니다. 수많은 사용자가 상품을 조회하지만 특정 순간에 구매하는 사용자는 소수인 전자상거래 사이트, 많은 이들이 스크롤하지만 소수만 게시물을 올리는 소셜 미디어 피드, 또는 콘텐츠 관리 시스템을 생각해보면 명확합니다.