온프레미스 또는 퍼블릭 클라우드에 관계없이 Couchbase 고객은 각기 다른 요구 사항을 가지고 있습니다: ACID 트랜잭션, 내구성 높은 쓰기, 고가용성 및 고성능. Couchbase의 아키텍처는 이러한 요구 사항을 충족하는 동시에 DevOps와 DBA의 수고를 덜어줍니다(커피를 마시거나 편안한 휴식을 취하는 데도 도움이 됩니다!). 특히, 이벤트 중심의 비동기식 설계는 하나의 활성 복사본과 최대 3개의 복제본 및 리전 내 자동 페일오버를 지원합니다. 마찬가지로, 서버 그룹 는 랙 수준 또는 퍼블릭 클라우드의 가용성 영역 수준에서 광범위하게 사용할 수 있는 기본 제공 기능으로 고가용성, 영구 쓰기, 고성능을 제공합니다. 이러한 모든 기능이 결합되어 즉시 유연성과 복원력을 제공합니다.
클러스터를 결합하고 서버 그룹을 활용하는 방법
이 블로그에서는 서버 그룹을 사용하여 가용성 영역으로 분할된 지역에 대해 클러스터를 하나의 자동 샤딩된 데이터베이스로 결합하는 방법을 설명합니다. 클러스터를 클러스터 내에서 3개의 별개의 서버 그룹으로 결합하면 몇 가지 장점이 있습니다:
-
- 더 많은 노드에 워크로드를 분산하면 더 많은 트래픽과 더 큰 데이터 용량을 처리하는 데 도움이 됩니다.
- 장애 조치 이중화의 가용성 영역 모델을 충족하고 스플릿 브레인 문제를 방지할 수 있습니다.
- Couchbase의 기본 제공 자동 장애 조치 기능을 활용하면 오프라인 서버 그룹 또는 가용성 영역이 자동으로 장애 조치됩니다.
- 클러스터를 결합한다는 것은 여러 문서 트랜잭션이 있는 데이터 또는 문서의 활성 복사본이 하나라는 뜻입니다. 여러 클라이언트에서 동일한 문서에 대한 쓰기와 읽기가 여러 번 있는 경우, 충돌을 해결할 필요가 없습니다. 필요한 경우, 쓰기와 읽기가 복제본과 영구 레이어에서 일관되게 이루어지도록 하고 ACID 트랜잭션을 보장할 수 있습니다.
최근 한 고객이 별도의 클러스터와 상호 작용하는 두 개의 애플리케이션이 있는 두 개의 클러스터에서 복제본과 디스크 모두에 대한 쓰기 내구성 있는 고가용성 클러스터로 전환하는 것을 도울 기회가 있었습니다. 문제는 아래 그림과 같이 각 애플리케이션이 클러스터 내에서 쓰기 보장을 통해 하나의 활성 복제본에 쓰는 것이었습니다. 
쓰기 보장이란 각 애플리케이션이 활성 복사본에 쓰고, 데이터를 잠그고, 복제본과 디스크가 쓰여질 때까지 기다리는 것을 의미합니다. 전에 다른 애플리케이션이 데이터를 읽고 쓸 수 있습니다. 복잡하게 들리나요? Couchbase와 서버 그룹을 사용할 때는 그렇지 않습니다.
고객은 다음과 같이 한 지역에서 퍼블릭 클라우드를 사용하고 가용성 영역이 3개인 자동 페일오버 기능을 갖춘 단일 클러스터를 원했습니다:
Couchbase 서버 그룹의 이점
위의 토폴로지에는 다음과 같은 기능이 지원됩니다:
-
- 자동 장애 조치 기능을 사용할 수 있습니다.
- 클러스터의 노드 수에 따라 하나의 활성 데이터 복사본과 최대 3개의 복제본이 가능합니다.
- 전체 클러스터에 걸쳐 활성 및 복제본이 균형 있게 자동 배포됩니다.
- 인덱스와 복제본 인덱스는 가용성 영역 간에 균형을 맞춥니다.
이러한 각 기능이 Couchbase에서 어떻게 지원되는지 살펴보겠습니다.
퍼블릭 클라우드 리전(또는 온프레미스 배포)에는 자동 페일오버가 필요합니다. 일반적으로 온프레미스 배포의 경우, 고객은 전원 공급 장치 장애와 같은 랙 장애로 인한 데이터 손실을 방지하기 위해 여러 랙에 시스템을 분산시키려고 합니다.
카우치베이스 서버 그룹 는 데이터의 활성 복사본과 복제본이 서버 그룹에 고르게 분산되는 기능입니다. 하지만 활성 데이터는 하나의 서버 그룹/가용성 영역에만 있는 것이 아니라 여러 서버 그룹에 걸쳐 있습니다. 모두 서버 그룹. 복제본은 각 활성 문서 및 인덱스에 대해 다른 그룹에 상주하도록 보장됩니다.
데이터를 계획하고 정렬할 필요가 없습니다. Couchbase의 아키텍처가 자동으로 작업을 수행합니다! 그런데 왜 세 그룹일까요? 이는 그룹/가용성 영역이 다운될 경우 두뇌가 분산되는 시나리오를 피하기 위해서입니다.
고가용성, 고성능 클러스터를 만드는 방법
두 개의 클러스터를 결합하고 세 번째 서버 그룹을 추가하는 데 권장되는 절차는 무엇인가요? 자동 샤딩, 인덱스 복제본 관리 및 서버 그룹으로 인해 Couchbase에서는 실제로 그렇게 복잡하지 않습니다. 다음 그림과 같이 한 클러스터에서 다른 클러스터(예: 클러스터 2)로 XDCR(데이터센터 간 복제) 기능을 사용한 다음 새 서버 그룹을 생성하면 됩니다.
클러스터 2가 메인 클러스터가 되고 해당 노드는 다음과 같이 선언됩니다. 서버 그룹 1런타임에 카우치베이스가 수행할 수 있습니다! 
그런 다음 노드를 한 번에 하나씩 추가하여 서버 그룹 2를 만들 수 있습니다. 퍼블릭 클라우드 배포인 경우 가용성 그룹 2로 선언할 수도 있습니다.
마지막으로 퍼블릭 클라우드 배포의 경우 가용성 영역 3의 클러스터에 서버 그룹 3 노드를 추가합니다.
노드를 추가할 때마다 한 번에 하나씩 재조정하는 두 가지 방법으로 노드별로 재조정할 수 있습니다. 또는 모든 노드를 추가한 후 리밸런싱을 사용하는 방법.
동일한 리밸런싱 중에 클러스터에 노드 하나를 추가하고 노드를 제거하면 Couchbase Server는 "스왑 리밸런싱"을 수행하며, 이 과정에서 데이터와 인덱스가 이동하므로 리소스 집약적인 작업이 될 수 있습니다. 리밸런싱 및 업그레이드 문서 보기 에서 자세한 정보를 확인하세요. 교통량이 적은 시간대에 신중하게 수행해야 합니다. 시간이 다소 걸릴 수 있으므로 적절히 계획하세요.
하지만 모든 지역에 인덱스와 쿼리 노드 두 개가 모두 필요할까요? 사실 이는 쿼리 트래픽에 따라 다릅니다. 하지만 쿼리 트래픽이 많지 않은 경우에는 서버 그룹당 하나의 인덱스 쿼리 노드를 사용할 수 있습니다.
고가용성을 위한 카우치베이스 목표
-
- 카우치베이스는 100%, 즉 다운타임 없이 작동하도록 설계되었습니다.
- 카우치베이스는 진정한 자동 샤딩 데이터베이스이므로 운영 전환 중 클러스터 전체에 데이터를 배포하는 데 DevOps 또는 데이터베이스 관리자의 집중적인 작업이 필요하지 않습니다.
- 서버 그룹 기능은 가용성 영역을 위한 것으로, 데이터 및 인덱스의 활성 및 복제본이 동일한 서버 그룹에 속하지 않도록 보장합니다.
- 3개의 가용성 영역에 3개의 서버 그룹을 사용하면 미리 설정된 타이머에 따라 자동 페일오버를 수행하는 Couchbase의 기능을 사용할 수 있습니다. 자동 장애 조치는 노드 또는 서버 그룹을 장애로 선언하고 적절한 단계를 거쳐 복제본을 생성하고 클러스터 맵을 클라이언트에 푸시합니다.
다음 단계 및 리소스
Couchbase는 아키텍처에 자율성이 내장되어 있어 데이터와 인덱스의 이동이 단순화되고 자동으로 이루어집니다. 클러스터를 결합하는 것이 좋은 이유와 클러스터를 100% 내결함성으로 만드는 방법을 살펴봤습니다. 카우치베이스는 운영 중단 없이 클러스터가 항상 작동하기 때문에 강력합니다. 애플리케이션은 클러스터와 상호 작용하기 위해 코드를 변경할 필요가 없습니다. 클러스터 변경은 SDK의 내부 클러스터 맵에 의해 처리되며, 모든 변경 사항은 애플리케이션 자체에 투명하게 표시됩니다.
Couchbase의 설계 팀과 아키텍처는 운영 자율성과 자동 샤딩을 포함하여 거의 모든 사용 사례에 최적의 내결함성 데이터베이스를 구축할 수 있는 미래 지향적인 사고방식을 갖추고 있습니다.
자동화의 다음 진화는 Couchbase의 쿠버네티스용 자율 운영자 및 OpenShift. 작업을 수행하는 운영자의 도움으로 자가 복구 및 자가 관리되는 클러스터를 상상해 보세요. 이것이 바로 카우치베이스 자율 운영자입니다. 위에서 설명한 프로세스는 모두 운영자와 새로운 최종 클러스터의 YAML 파일로 실행할 수 있습니다. 정말 간단합니다.
리소스
고가용성 클러스터, 리밸런싱 등에 대해 자세히 알아보려면 다음 문서와 페이지를 읽어보세요:
-
- 카우치베이스 서버 그룹 인식 문서
- Couchbase 리밸런싱 문서
- 관리자 REST API를 사용하여 Couchbase 클러스터 리밸런싱하기
- 카우치베이스 쿠버네티스용 자율 운영자
- 완전 관리형 카우치베이스 클라우드 NoSQL DBaaS (간편한 무료 평가판 사용 가능)
