[분산 시스템] PACELC 이론
이건 데이터베이스 아키텍쳐 수준의 trade-off를 정리한 이론 중 하나다. 2010년에 나왔다.
CAP과 연관이 깊다.
https://m.blog.naver.com/sssang97/223115732041
애초에 CAP에 대한 오해와, 미비한 부분을 보완하기 위해 제시된 주장이다.
CAP 이론의 한계
cap은 데이터베이스 설계에서 나타나는 trade-off 지점을 꽤나 명료하게 정의해서 많은 동의를 얻었지만, 그럼에도 좀 미비한 부분이 있어서 많은 오해를 불러일으키곤 한다.
레이턴시 고려 없음
CAP은 일관성을 취한다면 가용성이 낮아지게 된다고 설명한다.
하지만 일관성을 얻음으로 잃는 것은 가용성 뿐이 아니다. CAP은 "레이턴시"라는 중요한 성능 요소를 빠뜨렸다.
최적의 일관성을 얻기 위해서는 모든 쓰기마다 모든 노드에 복제를 시키고 대기해야 하는데, 이 대기 시간도 당연히 레이턴시를 길게 만드는 요인이다.
흑백이론?
CAP 정의에 따르면 대부분의 분산시스템은 CP, AP 중 하나여야 한다.
하지만 사실 현실세계에서는 그런 일이 별로 없다.
예를 들어, 완벽한 정의의 CP 시스템은 쓰기가 발생할때마다 모든 노드에 복제를 확인해야 한다.
이러면 노드가 하나만 내려가더라도 쓰기가 실패하고, 쓰기 레이턴시가 급격하게 증가한다.
- 일반적인 CP 분류에 속하는 mongoDB도 그렇게 쓸 수 있긴 하지만, 기본값은 아니다.
그리고, 완벽한 정의의 AP 시스템은 복제에 대한 아무런 책임을 지지 않는다.
아무런 보장도 갖지 못하니 쓰는 입장에서도 잘못된 요청을 날리고 버그가 발생할 확률이 매우 높아진다.
- 일반적인 AP 분류에 속하는 CassandraDB 등도 일관성 레벨이란 옵션을 통해 가용성을 조금 낮추는 대신 일관성을 올리는 사용 패턴을 권장한다.
그래서
요지는, 꼭 극단적으로 하나만 취할 필요는 없단 것이다. CP와 AP 사이에서 유용한 부분을 취하고, 사용자의 선택에 따라서 조절을 할 수 있게 한다면 많은 흠을 메꿀 수 있다.
그리고 대부분의 분산 DB들이 그런 유연한 접근법을 사용한다.
PACELC 이론
아무튼 PACELC 이론은 CAP보다 많은 부분을 고려해서 현실적인 trade-off를 설명하고자 한다.
다음과 같은 기준을 적용해서 세분화한다.
- 네트워크 파티션 여부 (P/E)
- P인 경우 - 일관성과 가용성 중 선택 (A/C)
- E인 경우 - 레이턴시와 일관성 중 선택 (L/C)
https://coding-review.tistory.com/m/312
파티션 여부란 쉽게 말해 장애 상황에서의 선택을 말한다.
만약 노드가 일부 끊기더라도 쓰기가 무조건 성공해야한다면, 그것은 일관성을 포기하는 대신 가용성을 얻는 것이다. (PA)
노드가 일부 끊겨서 복제가 불가능한 상황에서 애매한 데이터 부정교합보단 실패되게 한다면 이것은 가용성보단 일관성을 선택한 것이다. (PC)
여기까지는 CAP과 크게 다르지 않다. PACELC가 추가한건 장애가 없는 일반적인 경우다.
일관성보다 레이턴시, 성능이 중요하다면 복제가 끝나는 것을 기다리지 않는다. (EL)
레이턴시보단 일관성이 중요하다면 모든 복제가 끝나길 기다린다. (EC)
그래서 PACELC에서는 일반적으로 다음 4가지 조합을 갖는다.
PC/EC, PC/EL, PA/EC, PA/EL
예: MySQL master-slave 구성의 경우
잘 구성된 단일 master 다중 slave 구성의 클러스터라면, 일반적으로 PA/EL가 된다.
mysql의 기본 복제 설정은 async 복제라서 일관성이 떨어진다.
만약 쓰기 복제가 실패하더라도 async하게 될때까지 재시도하거나 한다. 그래서 PA다.
그리고 async 복제라서 쓰기가 복제를 기다리지 않는다. 그래서 EL다. (설정하면 EC도 가능)
예: MongoDB의 경우
mongoDB는 PC/EC 혹은 PC/EL라고 할 수 있다.
slave에 문제가 생기는 경우도 쓰기 복제가 실패할 수 있는데, 특히 master에 문제가 생기면 그 즉시 새로운 master를 선출한다. 이 때는 몇초 수준의 다운타임이 발생한다. 일관성을 보장하기 위해 단일 master 구조를 취한데서 발생한 트레이트오프다.
그래서 PC라고 할 수 있다.
일반적인 복제 상황에 있어서도 일관성을 중요시하는 편이다.
write concern 옵션을 높게 준다면 EC, 낮게 준다면 EL이 된다.
예: CassandraDB의 경우
카산드라는 PA/EL로 분류된다.
대부분의 상황에서 일관성을 포기하고 가용성과 레이턴시를 선택한 구조다.
부분 장애가 발생해도 무시하고 일단 개별 노드에 대해서 완료되게 한다. (PA)
일반적인 상황에서 모든 쓰기는 비동기로 복제되고 기다리지 않는다. (EL)
다만 옵션을 통해서 일관성을 높일 수도 있다. (EC)
참조
http://happinessoncode.com/2017/07/29/cap-theorem-and-pacelc-theorem/
https://blog.nullbus.net/91
https://coding-review.tistory.com/m/312