Rds aurora의 쿼럼 모델

RDS Aurora의 쿼럼 모델

Amazon Aurora under the hood: quorums and correlated failure | Amazon Web Services

• 분산 스토리지가 좋은 아이디어이지만 잘 실행하기 어려운 이유
  • 동기식 복제 → 모든 복사본이 승인해야한다.
  • 비동기식 복제는 지연 시간 → 데이터가 복제되어 내구성을 가지기 전에 실패가 발생하면 데이터 손실이 발생
• 그래서 Aurora는 쿼럼 모델을 사용

쿼럼 모델

• 정의
  • 데이터의 여러 복사본 중 일부분(부분집합)에서 읽기와 쓰기를 수행하는 시스템
    • 리더리스의 정족수와 유사
    • 하지만 다음과 같은 차이가 있음
      • 쿼럼: 데이터베이스의 읽기/쓰기 작업의 일관성 보장, 읽기 쿼럼과 쓰기 쿼럼을 별도로 정의
      • 리더리스 정족수: 리더 없이 분산 시스템의 합의를 이루기 위한 목적, 일반적으로 단일 정족수 값 사용
  • 전체 복사본 수를 V, 쓰기 쿼럼을 Vw, 읽기 쿼럼을 Vr로 표시

• 핵심 규칙
  • 규칙 1: 읽기 세트(Vr)와 쓰기 세트(Vw)는 최소 하나의 복사본에서 반드시 겹쳐야 함
  • 규칙 2: 쓰기 쿼럼(Vw)은 전체 복사본 수의 절반보다 커야 함 (Vw > V/2)

Aurora 쿼럼

• AZ(가용 영역) 전체 장애 대응
  • Aurora는 3개의 AZ에 걸쳐 6개의 복사본을 분산 저장 (각 AZ당 2개)
  • 한 개의 AZ가 완전히 실패하더라도(2개 복사본 손실) 시스템은 계속 운영 가능
    • 남은 복사본 = 4
    • Vw(4개 필요) 조건을 여전히 만족
    • Vr(3개 필요) 조건을 여전히 만족
  • 심지어 한 AZ이 손실되고, 추가 1개의 복사본이 손실되더라도 남은 복사본은 3개이기에 Vr=3을 만족하므로 최신 데이터를 읽을 수 있음
    • 이를 기반으로 새로운 복사본을 만들어 Vw=4를 만족하게 할 수 있다.
• 2/3 쿼럼의 한계 극복

  • 2/3 쿼럼

      AZ1: 1개 복사본
      AZ2: 1개 복사본
      AZ3: 1개 복사본
      총 3개 복사본, 2개의 승인 필요
    

  • 일반적인 2/3 쿼럼은 한 개의 장애만 처리 가능
  • 하지만 실제로는 장애가 독립적이지 않을 수 있음
  • AZ 전체 실패 + 다른 장애가 동시에 발생하면 2/3 쿼럼은 데이터 손실 위험
• 극단적 상황 대비
  • AZ 장애가 장기화될 경우 3/4 쓰기, 2/4 읽기의 저하된 모드로 전환 가능
  • 이를 통해 남은 AZ들에서 추가 장애가 발생해도 시스템 운영 가능
  • AZ 복구 후 다시 6복사본 체제로 복귀