에서 이 시리즈 소개에서 .NET SDK를 다시 작성하게 된 동기, 곧 출시될 2.0 릴리스의 목표, 목적 및 주요 기능에 대해 논의하고 Couchbase Server 클라이언트 SDK의 상위 수준 아키텍처(10000피트 뷰)를 살펴봤습니다. 이번 글에서는 Couchbase SDK의 핵심 구성 요소 중 하나인 서버 구성의 설계 및 개발에 대해 살펴보겠습니다: 서버 구성입니다.

소개

연결할 클러스터의 IP, 사용할 연결 수 및 클라이언트가 클러스터와 상호 작용하는 방법에 관한 기타 중요한 정보를 정의하는 클라이언트 구성과 클러스터의 현재 상태(예: 노드 수, 사용 가능한 버킷 등)를 정의하여 클라이언트의 내부 상태를 구동하는 서버 구성의 두 가지 소스에서 구성이 필요합니다(클러스터 맵)

이 글에서는 서버 구성 측면에 대해서만 설명하며, 주로 잘 정의된 몇 가지 인터페이스 또는 컨트랙트를 구현하는 데 중점을 둘 것입니다.

HTTP 스트리밍 구성

현재 대부분의 클라이언트는 클라이언트 구성을 통한 "부트스트래핑" 기법과 Couchbase REST API. 이 기능은 2.2 이후의 Couchbase 버전에서 지원됩니다. 일반적인 접근 방식은 다음과 같습니다:

이 접근 방식에는 몇 가지 문제점이 있습니다:

• '스트리밍 URL'은 서버 측에서 생성 및 유지 관리(주로 메모리)를 위해 리소스를 많이 사용합니다.
• 리밸런싱 또는 장애 조치 상황에서는 클러스터 구성이 여러 번 변경될 수 있습니다. 이런 일이 발생할 때마다 클라이언트는 모든 리소스(소켓 연결, VBucket 매핑)를 제거하고 상태를 다시 구축해야 하며, 이로 인해 처리량 감소, 지연 시간, 예상보다 높은 메모리 및 CPU 사용량 등이 발생할 수 있습니다....
• 진행 중인 작업은 종료된 후 새 구성 상태에서 다시 시도할 수 있습니다. 이는 마치 "카펫이 그 아래에서 뽑혔습니다.".
• 클라이언트가 작업을 리디렉션할 노드를 선택하는 데 도움이 되는 정보가 없기 때문에 목록의 다음 노드를 시도하는 것만으로 NOT_MY_VBUCKET 응답을 효율적으로 처리할 수 있습니다.

구성 관리를 위한 새로운 모델: CCCP 최적화된 연결 관리

스트리밍 HTTP "부트스트랩" 방식은 대부분의 클라이언트에서 비교적 잘 작동했지만, 단점이 장점보다 더 커지기 시작했기 때문에 클라이언트 구성을 업데이트하는 새로운 모델이 2.5 버전의 카우치베이스 서버부터 정의되어 있습니다: 클라이언트 클러스터 구성 게시 또는 "CCCP" 최적화된 연결 관리. CCCP  최적화된 연결 관리에는 인증 전후에 구성을 요청하기 위해 사용할 수 있는 새로운 작업과 실패한 작업으로 인해 NOT_MY_VBUCKET 응답이 반환될 때 구성 정보를 반환하는 메커니즘이 도입되었습니다.

이 경우 CCCP 최적화된 연결 관리 지원 SDK를 사용하면 클라이언트는 작업을 다시 보내기 전에 구성을 사용하여 스스로 업데이트하는 방식으로 반응합니다. 예를 들어 재조정 또는 장애 조치 시나리오 중 클러스터 자체가 변경되어 클라이언트가 아직 "동기화"되지 않았고 오래된 구성을 사용하고 있어 잘못된 키 매핑이 발생한 경우 클러스터에서 반환되는 표준 응답은 NOT_MY_VBUCKET이라는 점에 유의하세요. 반면 '부트스트랩' 접근 방식은 다소 '풀' 유형의 작업입니다, CCCP 최적화된 연결 관리는 요청이 클라이언트에 의해 시작되었는지(명시적인 CMD_GET_CLUSTER_CONFIG 작업을 통해) 아니면 서버 자체에 의해 시작되었는지(작업에 대한 NOT_MY_VBUCKET 응답을 통해)에 따라 "푸시" 또는 "풀" 중 하나로 이루어집니다. 다음 사항을 살펴보겠습니다. CCCP 최적화된 연결 관리는 이후 게시물에서 더 자세히 설명합니다.

*편집: CCCP는 이제 "최적화된 연결 관리"로 알려져 있습니다.

파일 기반 구성

준지원되는 또 다른 구성 옵션이 하나 더 있는데, 바로 파일 기반 구성입니다. 파일 기반 구성은 주로 테스트 및 개발에 유용하며 테스트 스위트를 실행할 때 복제하기 어렵거나 오탐을 유발하는 일부 종속성을 제거하기 위해 테스트 프로젝트에서 구현을 제공할 것입니다.

구조적 아키텍처 보기

내부적으로 클라이언트의 서버 구성 구성 요소는 공급자 기반 모델로, 클라이언트에서 구성 공급자의 여러 구현을 구성한 다음 전략을 선택하여 어떤 공급자를 사용할지 결정할 수 있습니다. 기본값은 첫 번째로 구성된 공급자가 사용된 다음 실패하면 다음 공급자가 순차적으로 그 자리를 대신하는 간단한 선형 폴백 방식입니다.

다음은 주요 액터 오브젝트와 클라이언트 내의 다른 주요 오브젝트와의 관계를 보여주는 다이어그램으로, 다음 포스트에서 설명할 것입니다:

각각에 대한 설명은 다음과 같습니다:

• 구성 공급자: 새 구성 정보를 반환하는 소스입니다. 소스에서 구성을 가져오는 메커니즘을 제공하는 것은 공급자의 책임입니다.
• 구성정보: 구성 정보에는 가능한 노드 목록과 해당 노드 내에서 주어진 키가 전달되어야 하는 서버를 클라이언트에 알려주는 VBucket 맵이 포함되어 있습니다.
• ConfigurationManager: 클라이언트와 공급자 사이의 가교 역할을 하며, 어떤 공급자를 사용할지, 어떤 재시도 로직을 적용할지 결정하기 위해 취한 전략입니다.

이 아키텍처에 대한 자세한 문서는 다음에서 확인할 수 있습니다. 여기. 모든 개발이 그렇듯이 이 기능도 진화하는 과정이므로 시간이 지남에 따라 약간의 변경과 수정이 있을 수 있다는 점에 유의하세요.

결론 및 다음 단계

이 게시물에서는 역사(HTTP 스트리밍)와 미래(CCCP 최적화된 연결 관리)의 Couchbase SDK 서버 구성 관리에 대해 설명했습니다. 다음 포스트에서는 2.5 이전 버전의 Couchbase Server를 대상으로 하는 클라이언트에 필요한 HTTP 스트리밍 구성 공급자의 구현에 대해 자세히 살펴보겠습니다.