곧 출시될 libcouchbase 버전에는 향상된 클러스터 업데이트와 기타 여러 가지 안정성 및 성능 개선 사항이 포함되어 있습니다. 새로운 작업의 대부분은 다음을 중심으로 이루어집니다. 클러스터 구성 캐리어 게시 또는 CCCP 줄여서
카우치베이스는 확장성, 탄력성 클러스터. 이 기능 세트의 일부는 애플리케이션 수준에서 다운타임을 일으키지 않고 클러스터 노드를 자유롭게 추가하거나 제거할 수 있다는 것을 의미합니다. 클러스터에서 모든 노드를 교체하고 교체하는 것은 완전히 지원되며 일반적으로 SDK를 사용하는 애플리케이션 서버에서 투명하게 이루어집니다.
SDK 자체는 건강한 클러스터와 통신하고 있으며 클러스터 구성원인 다양한 노드를 인식하고 있는지 확인해야 합니다. 구체적으로 이는 두 가지 사항을 파악하는 것으로 구성됩니다:
- 클러스터의 일부인 노드
- 주어진 키를 담당하는 노드
이 정보는 "" 라는 JSON 객체를 통해 전송됩니다.구성 맵" 또는 "클러스터 맵". 다음과 같은 URL로 이동하여 직접 확인할 수 있습니다.
이 JSON 객체에는 노드 목록과 큰 "vBucket 맵"를 사용하여 기본적으로 클라이언트에게 어떤 노드가 어떤 vBucket을 담당하는지 알려주고, 클라이언트는 이 맵에 대해 키를 해시합니다.
부트스트랩
SDK(특히, libcouchbase)를 함께 배치하여 strace 에서 출력 cbc
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 6 connect(6, {sa_family=AF_INET, sin_port=htons(8091), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (현재 작업 진행 중) connect(6, {sa_family=AF_INET, sin_port=htons(8091), sin_addr=inet_addr("127.0.0.1")}, 16) = 0 sendmsg(6, {msg_name(0)=NULL, msg_iov(1)=[{"GET /pools/default/bucketsStream"..., 145}], msg_controllen=0, msg_flags=0}, 0) = 145 recvmsg(6, {msg_name(0)=NULL, msg_iov(1)=[{"HTTP/1.1 200 OKrnTransfer-Encodi"..., 65536}], msg_controllen=0, msg_flags=0}, 0) = 200 recvmsg(6, 0x7fff7b7e9bb0, 0) = -1 EAGAIN(일시적으로 리소스를 사용할 수 없음) recvmsg(6, {msg_name(0)=NULL, msg_iov(1)=[{"2223rn{"name":"protected","bucke"..., 65536}], msg_controllen=0, msg_flags=0}, 0) = 8756 recvmsg(6, 0x7fff7b7e9bb0, 0) = -1 EAGAIN(일시적으로 리소스를 사용할 수 없음) socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 7 connect(7, {sa_family=AF_INET, sin_port=htons(11210), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (현재 작업 진행 중) connect(7, {sa_family=AF_INET, sin_port=htons(11210), sin_addr=inet_addr("127.0.0.1")}, 16) = 0 getsockname(7, {sa_family=AF_INET, sin_port=htons(34432), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0 getpeername(7, {sa_family=AF_INET, sin_port=htons(11210), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0 sendmsg(7, {msg_name(0)=NULL, msg_iov(1)=[{"200 ", 24}], msg_controllen=0, msg_flags=0}, 0) = 24 recvmsg(7, {msg_name(0)=NULL, msg_iov(1)=[{"201 16CRAM-MD5"..., 65536}], msg_controllen=0, msg_flags=0}, 0) = 38 recvmsg(7, 0x7fff7b7e9b70, 0) = -1 EAGAIN(일시적으로 리소스를 사용할 수 없음) sendmsg(7, {msg_name(0)=NULL, msg_iov(1)=[{"200!1010CRAM-MD5", 32}], msg_controllen=0, msg_flags=0}, 0) = 32 recvmsg(7, {msg_name(0)=NULL, msg_iov(1)=[{"201!!.36<9003993"..., 65536}], msg_controllen=0, msg_flags=0}, 0) = 54 recvmsg(7, 0x7fff7b7e9b70, 0) = -1 EAGAIN(일시적으로 리소스를 사용할 수 없음) sendmsg(7, {msg_name(0)=NULL, msg_iov(1)=[{"200"10002CRAM-MD5"..., 74}], msg_controllen=0, msg_flags=0}, 0) = 74 recvmsg(7, {msg_name(0)=NULL, msg_iov(1)=[{"201"rAuthenti"..., 65536}], msg_controllen=0, msg_flags=0}, 0) = 37 recvmsg(7, 0x7fff7b7e9b70, 0) = -1 EAGAIN(일시적으로 리소스를 사용할 수 없음) sendmsg(7, {msg_name(0)=NULL, msg_iov(1)=[{"2003s31foo", 27}], msg_controllen=0, msg_flags=0}, 0) = 27 recvmsg(7, {msg_name(0)=NULL, msg_iov(1)=[{"20142111~$@327-17Hell"..., 65536}], msg_controllen=0, msg_flags=0}, 0) = 41 recvmsg(7, 0x7fff7b7e9b70, 0) = -1 EAGAIN(일시적으로 리소스를 사용할 수 없음) "foo" 크기:13 플래그:0 CAS:f2dd740247e0100 안녕하세요! |
위에서 라이브러리가 먼저 포트에 HTTP 요청을 하는 것을 볼 수 있습니다. 8091 를 입력하여 클러스터 맵을 검색합니다. 클러스터 맵이 검색되면 클러스터 맵이 검색된 노드에 연결됩니다. vBucket Master 포트의 "foo" 키에 11210, 는 SASL 인증을 수행하고 마지막으로 멤캐시드 키를 요청하세요.
CCCP를 사용하면 멤캐시드 포트의 11210 자체도 구성 정보를 호스팅할 수 있습니다. 따라서 곧 출시될 예정인 DP 버전의 cbc 도구에 들어가면 이걸 볼 수 있습니다:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
connect(6, {sa_family=AF_INET, sin_port=htons(11210), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (현재 작업 진행 중) connect(6, {sa_family=AF_INET, sin_port=htons(11210), sin_addr=inet_addr("127.0.0.1")}, 16) = 0 getsockname(6, {sa_family=AF_INET, sin_port=htons(34412), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0 getpeername(6, {sa_family=AF_INET, sin_port=htons(11210), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0 sendmsg(6, {msg_name(0)=NULL, msg_iov(1)=[{"200 ", 24}], msg_controllen=0, msg_flags=0}, 0) = 24 recvmsg(6, {msg_name(0)=NULL, msg_iov(1)=[{"201 16CRAM-MD5"..., 65536}], msg_controllen=0, msg_flags=0}, 0) = 38 recvmsg(6, 0x7fff8206e770, 0) = -1 EAGAIN(일시적으로 리소스를 사용할 수 없음) sendmsg(6, {msg_name(0)=NULL, msg_iov(1)=[{"200!1010CRAM-MD5", 32}], msg_controllen=0, msg_flags=0}, 0) = 32 recvmsg(6, {msg_name(0)=NULL, msg_iov(1)=[{"201!!.36<9014490"..., 65536}], msg_controllen=0, msg_flags=0}, 0) = 54 recvmsg(6, 0x7fff8206e770, 0) = -1 EAGAIN(일시적으로 리소스를 사용할 수 없음) sendmsg(6, {msg_name(0)=NULL, msg_iov(1)=[{"200"10002CRAM-MD5"..., 74}], msg_controllen=0, msg_flags=0}, 0) = 74 recvmsg(6, {msg_name(0)=NULL, msg_iov(1)=[{"201"rAuthenti"..., 65536}], msg_controllen=0, msg_flags=0}, 0) = 37 recvmsg(6, 0x7fff8206e770, 0) = -1 EAGAIN(일시적으로 리소스를 사용할 수 없음) sendmsg(6, {msg_name(0)=NULL, msg_iov(1)=[{"200265r360", 24}], msg_controllen=0, msg_flags=0}, 0) = 24 recvmsg(6, {msg_name(0)=NULL, msg_iov(1)=[{"20126536{r360{"rev":1"..., 65536}], msg_controllen=0, msg_flags=0}, 0) = 7827 recvmsg(6, 0x7fff8206e770, 0) = -1 EAGAIN(일시적으로 리소스를 사용할 수 없음) sendmsg(6, {msg_name(0)=NULL, msg_iov(1)=[{"2003s31foo", 27}], msg_controllen=0, msg_flags=0}, 0) = 27 recvmsg(6, {msg_name(0)=NULL, msg_iov(1)=[{"20142111~$@327-17Hell"..., 65536}], msg_controllen=0, msg_flags=0}, 0) = 41 recvmsg(6, 0x7fff8206e730, 0) = -1 EAGAIN(일시적으로 리소스를 사용할 수 없음) "foo" 크기:13 플래그:0 CAS:f2dd740247e0100 안녕하세요! |
여기서는 구성을 가져와서 추가 TCP 연결을 줄입니다. 직접 를 데이터 포트에서 가져옵니다.
로컬 호스트 클러스터에 대해서도 두 번째 예제는 초기 HTTP 연결이 감소하기 때문에 첫 번째 예제보다 약 2배 더 빠르게 실행됩니다.
구성 업데이트
구성 업데이트는 클러스터 토폴로지가 변경될 때 수신되는 새롭고 업데이트된 클러스터 맵입니다. 이를 통해 클라이언트는 노드가 추가 또는 제거되었음을 알 수 있으며, 그에 따라 vBucket 맵이 변경되었음을 알 수 있습니다.
libcouchbase에 대한 이전 동작은 스트리밍 버킷의 구성 업데이트를 수신하기 위해 지정된 버킷에 대한 REST API 엔드포인트를 호출해야 합니다. 이를 위해서는 라이브러리가 클러스터에서 구성 정보를 푸시하는 대부분 유휴 상태의 TCP 연결을 유지해야 했습니다. 이 접근 방식에는 두 가지 주요 단점이 있었습니다:
- 라이브러리를 대기/긴 폴링 상태로 전환하면 구성을 제공하는 소켓이 작동하는 노드에 연결되어 있다고 가정하여 다음과 같은 작업을 수행합니다. push 구성 정보를 반환합니다. 물론 클라이언트가 스트리밍 엔드포인트를 통해 연결한 노드가 자체적으로 장애를 일으킨 노드라면(그리고 더 나쁜 경우 TCP RST를 전달하지 않는다면) 이 가정은 실패할 것입니다. 시맨틱이 푸시 기반이기 때문에 클라이언트가 설정할 수 없습니다. 시간 초과 를 사용하여 연결이 여전히 제대로 작동하는지 확인했습니다.
- 최신 구성 정보를 유지하기 위해 항상 추가 TCP 연결이 필요했습니다. REST API 엔드포인트는 일상적인 사용이 아닌 관리용으로 설계되었기 때문에 메모리 사용에 최적화되어 있지 않습니다. 특히 이러한 엔드포인트에 대한 각 TCP 연결은 서버 측에서 상당한 리소스 페널티를 발생시킵니다.
Confmon - 구성 관리자
새로운 2.3에서는 구성이 검색되는 방식에 대한 모델과 접근 방식이 변경됩니다. 다음과 같이 통칭되는 내부 API 집합은 confmon/clconfig 를 코드베이스에 도입했습니다. 오픈 소켓에 구성을 적용하는 침입형 푸시 기반 모델 대신에 말입니다, confmon 는 풀 기반이며 필요할 때만 트리거됩니다. 따라서 클라이언트는 기본적으로 구성을 위해서만 열린 소켓을 유지하지 않고 특정 오류 임계값에 도달하거나 명시적인 NOT_MY_VBUCKET 오류(클라이언트의 맵에 데이터가 없음을 나타냄)가 발생했습니다(클러스터 노드 중 하나에서).
특히 새로운 CCCP 개선 사항, 각각 NOT_MY_VBUCKET 응답 자체 이미 에 업데이트된 클러스터 맵이 포함되어 있으므로 처음부터 구성을 다시 가져올 필요가 없습니다.
새 모델은 REST API 연결만 열기 때문에 이전 클러스터에서도 이점을 얻을 수 있습니다. 온디맨드 - (실제로 리밸런싱과 같은 토폴로지 변경 시 구성 업데이트가 연속적으로 발생하는 경향이 있으므로 짧은 시간 동안 롱폴링하는 최적화를 수행했습니다).
로깅
라이브러리에 로깅 후크가 추가되었습니다. 이 모델을 사용하면 기본값인 콘솔 로거 를 설정하여 LCB_LOGLEVEL 환경 변수를 사용하거나, 자체 로깅 훅을 구현하여 lcb_logprocs 인터페이스와 인스턴스에 로깅 훅에 대해 알려줍니다.
시간 초과, 소켓 연결, 소켓 파괴, 구성 업데이트 등과 같이 눈에 띄지만 CPU를 많이 사용하지 않는 이벤트에 대한 로깅이 추가되었습니다.
기록할 항목이 더 있으며 이것이 추가할 모든 계측 및 진단 보조 도구의 끝이 아닙니다!
연결 관리
또한 멤캐시된 "데이터" 노드에 대한 새로운 연결을 처리하는 방식도 강화했습니다. 이전에는 연결을 생성한 객체로 연결 범위가 지정되었습니다. 즉, 이제 lcb_server_t 객체 자체가 연결을 열고 닫을 수 있습니다.
2.3 버전에서는 connmgr 모듈을 사용하여 소켓 풀처럼 작동합니다(향후에는 보기 쿼리 등을 위한 소켓 풀링을 지원하는 데 사용될 예정입니다). 하위 시스템 대신 열기 그리고 닫기 I/O 시스템에서 직접 연결할 수 있게 되었습니다. 요청 그리고 릴리스 (또는 폐기) 연결과 connmgr 인스턴스
이제 서버 구조는 무조건 TCP 연결을 닫지 않고 보류 중인 데이터가 있는지 확인하고, 데이터가 있으면 소켓이 폐기됨 를 풀로 되돌립니다(즉, 소켓이 해제되고 이와 관련된 모든 풀링된 리소스도 해제됩니다) 소켓이 유효하지 않은 상태라고 간주하기 때문입니다(서버에서 추가 응답이 있을 수 있으므로 NOT_MY_VBUCKET 응답). 보류 중인 데이터가 없는 경우 소켓은 출시 를 풀에 다시 추가하여 이후 새 연결 요청에 사용할 수 있게 됩니다. 테스트 결과, 클러스터 토폴로지가 변경되는 동안 새 TCP 연결이 생성되는 횟수가 최대 6배까지 감소하는 것으로 나타났습니다.
코드 받기
다음에서 해당 릴리스의 소스 타볼을 다운로드할 수 있습니다.
http://packages.couchbase.com/clients/c/snapshots/libcouchbase-2.3.0_dp2.tar.gz
카우치베이스용 커스텀 드라이버를 빌드하는 방법에 대한 참고 자료가 있나요? 아직 카우치베이스 용 기본 Erlang 드라이버가 없으며 개발에 도움이 될 수있는 일관된 문서가 있는지 궁금합니다.