CAP는 많은 분들에게 잘 알려져 있으므로 여기서 소개 자료를 설명하는 데 시간을 할애하지는 않겠지만, 최근 대화에서 몇 번 언급된 오해에 대해 정확히 짚고 넘어가고자 합니다. 이 글의 핵심은 다음과 같습니다: 단일 클러스터로서 Couchbase Server의 'CAP' 동작과 XDCR이 포함된 Couchbase Server의 'CAP' 동작은 다릅니다.
Couchbase Server 단일 클러스터 배포부터 시작하겠습니다: CAP는 일반적으로 시스템의 모든 색상을 설명하기에는 너무 높은 수준이지만, Couchbase Server는 주로 자동 장애 조치와 같은 옵션으로 C를 A로 대체하는 CP 시스템으로 불립니다.
그러나 XDCR을 사용하는 멀티클러스터 배포의 경우 Couchbase Server가 AP를 제공합니다. 클러스터 중 하나에 쓰면 충돌을 감지하고 해결하여 여러 클러스터 간에 최종적인 일관성을 제공합니다(이러한 충돌을 감지하고 해결하는 방법을 이해해야 기대하는 효과를 얻을 수 있습니다). 카우치베이스 서버는 배포 토폴로지에 따라 더 많은 CP 또는 더 많은 AP 시스템이 될 수 있습니다.
한 가지 경고를 드리자면, 이 논의는 엔지니어링 분야에서도 다양한 의견으로 나오고 있습니다: CAP는 높은 수준의 정의입니다. 시스템의 접근 방식을 이해하기 위한 좋은 첫걸음입니다. 하지만 시스템의 모든 색을 설명하는 데는 적합하지 않습니다. 첨부된 표를 통해 Couchbase Server의 CAP 밸런스가 어떻게 작동하는지에 대해 좀 더 자세히 알아볼 수 있습니다. 열에 대한 빠른 둘러보기: 이 표는 XDCR을 사용하는 다양한 배포 토폴로지를 살펴봅니다. 장애 도메인은 해당 토폴로지의 장애 도메인을 설명합니다. CAP 밸런스는 시스템의 AP-니와 CP-니를 설명합니다. 다음 표는 주의해서 사용하세요.
마지막으로, 가용성 기능으로서 XDCR을 살펴보지 않았다면 다음 표를 참고해 보세요. XDCR과 그 동작에 대해 더 자세히 알고 싶으시다면 다음 백서를 다운로드하는 것도 좋습니다: XDCR로 애플리케이션 개발하기
읽어 주셔서 감사드리며 언제나 그렇듯이 의견을 환영합니다.
Cihan Biyikoglu - 제품 관리 @ Couchbase
배포 토폴로지 |
결함 도메인 |
CAP 잔액 |
댓글 |
|
단일 카우치베이스 서버 클러스터 |
노드 수준 장애 도메인(예: HW 장애, 노드 간 통신 장애) |
CP를 구성할 수 있으며 자동 장애 조치 또는 복제본 읽기 등을 통해 사용 가능하도록 조정할 수 있습니다. |
카우치베이스 서버는 활성 또는 복제 v버킷 읽기를 허용하므로 짧은 페일오버 시간 초과 후 쓰기 가용성을 제공하도록 자동 페일오버로 조정할 수 있습니다. |
|
HA/DR용 단방향 XDCR이 포함된 Couchbase 서버 클러스터 |
노드 및 클러스터 전체 장애(예: 자연 재해로 인한 DC 장애) |
클러스터 전체 또는 노드 장애에 대한 보호 기능을 갖춘 단방향 XDCR로 클러스터 전반의 AP를 보호합니다. 노드 장애에 대해 각 클러스터 내에서 동일한 'CAP 잔액'을 유지합니다. |
두 번째 사이트/데이터 센터에서 수동 컴퓨팅 용량을 갖춘 단방향. 대상 클러스터는 안정 상태에서 궁극적으로 일관된 읽기에 사용할 수 있으며 소스 클러스터에 장애가 발생하면 읽기/쓰기로 승격될 수 있습니다. |
|
HA/DR용 양방향 XDCR이 포함된 Couchbase 서버 클러스터 |
노드 및 클러스터 전체 장애(예: 자연 재해로 인한 DC 장애) |
클러스터 전체 또는 노드 장애에 대한 보호 기능을 갖춘 양방향 XDCR로 클러스터 전반의 AP를 보호합니다. 노드 장애에 대해 각 클러스터 내에서 동일한 'CAP 잔액'을 유지합니다. |
사이트/데이터센터 전체에 걸쳐 활성/분할 계산 용량을 갖춘 양방향. 대상 클러스터는 안정 상태에서 궁극적으로 일관된 읽기 및 쓰기를 위해 사용할 수 있습니다. 두 클러스터에서 동일한 키가 변경되면 쓰기 충돌이 발생할 수 있습니다. 많은 고객들이 소스 클러스터와 대상 클러스터에서 겹치지 않는 키 범위로 쓰기 트래픽을 분할하여 쓰기 충돌을 최소화합니다. |
