In 이 블로그 시리즈의 1부 카우치베이스 함수의 순서 지정에 대한 이해를 돕기 위해 다음과 같은 변이가 어떻게 소비되는지 관찰했습니다. 카우치베이스 이벤트 서비스 다양한 시나리오에서 사용할 수 있습니다.
이제 이벤트 처리 서비스의 내부를 살펴보고 실제로 이벤트 처리 워커가 어떻게 변이 처리를 위해 할당되는지 이해해 보겠습니다.
작업자 할당에 대한 vBucket
카우치베이스는 데이터 노드 전체에 걸쳐 데이터를 자동으로 샤딩하며, 이러한 샤드를 v버킷이라고 합니다. 모든 버킷은 1024개의 vBucket으로 샤딩됩니다. 자동 샤딩과 vbuckets에 대해 자세히 알아보려면 다음을 확인하세요. 백서.
샘플 클러스터에 데이터 노드 3개와 이벤트 노드 1개가 있다고 가정해 보겠습니다. 이벤트 노드에는 2개의 함수가 배포되어 있고 데이터 노드에서 1개의 버킷을 수신합니다.
소스 버킷은 3개의 노드에 분산된 1024개의 버킷으로 자동 샤딩됩니다. 아래 그림은 단조롭게 증가하는 순서로 할당되는 vBucket을 보여 주지만 항상 그렇지는 않을 수 있으며, 가독성을 높이기 위해 그림에서는 순서대로 vBucket 순서를 나열했습니다. Eventing 노드에 배포된 함수는 각각 4명과 3명의 워커가 할당된 fn-email과 fn-score의 두 가지 함수입니다.
이벤트 노드가 하나뿐이므로 1024개의 vBucket이 모두 이 이벤트 노드에 할당됩니다. 주어진 함수의 각 워커는 1024개/개의 vBuckets를 수신합니다. 1024/num_workers != 0인 경우, 소수의 워커에 대해서는 Vbucket 분포가 하나씩 떨어져 있습니다. 따라서 그림에서 볼 수 있듯이 fn-email 함수의 각 워커 4명은 256(=1024/4)개의 vBuckets를 수신하고, 같은 비유로 fn-score 함수의 각 워커 3명은 341(=1024/3)개의 vBuckets를 수신합니다(한 워커만 342개의 vBuckets를 수신함).
클러스터가 안정적이고 클러스터 재밸런스가 없는 경우: 특정 vBucket에 발생하는 모든 변경 사항은 할당된 워커가 소비하고, 특정 문서에 발생하는 모든 변경 사항은 워커가 순서대로 소비합니다(기본적으로 각 워커 프로세스는 여러 스레드를 생성하고 문서는 스레드에 따라 순서대로 표시됨).
이제 문서가 순서대로 처리되지 않는 이유를 설명합니다(테이크아웃#1 및 테이크아웃#3에서 Part-1) 문서가 서로 다른 vBucket에 속할 수 있고, 따라서 서로 다른 vBucket에 할당된 서로 다른 작업자가 동시에 작업하여 순차적이지 않은 동작이 발생할 수 있기 때문입니다.
탄력적인 확장성
이제 변이율이 증가하여 주어진 단일 이벤트 노드의 백로그가 증가하여 이벤트 노드의 CPU 부하가 증가한다고 가정해 보겠습니다. 관리자는 Eventing 노드를 하나 더 추가하고 클러스터 리밸런스를 수행합니다.
이제 각 Eventing 노드에는 1024/2 = 512개의 vBucket이 할당되고, 작업자에게도 이전에 할당된 것보다 절반의 vBucket이 표시됩니다. 작업자 간 vBucket 할당은 리밸런싱 중에 Eventing Service에 의해 원활하게 수행되며 관리자에게 완전히 투명하게 공개됩니다.
메타데이터 버킷은 수행 중인 처리의 체크포인트 정보와 작업자 할당을 저장하기 때문에, 클러스터 재조정 중에 변이가 손실되지 않고 Couchbase Eventing Service가 원활하게 수행됩니다.
위의 동작은 다양한 계절성 또는 트래픽 패턴에 따라 탄력적인 확장성을 제공합니다.
디버그 모드 중 동작
온라인 실시간 디버거는 개발자가 배포된 코드에서 변이가 발생할 때 디버깅할 수 있도록 도와줍니다. 디버그 세션은 한 번에 하나의 변이에 대해서만 작동하며, 이 변이는 임의로 선택됩니다. 모든 연속적인 변경 사항을 관찰하려면 새 디버그 세션을 시작해야 합니다.
디버그 세션이 시작되면 디버그 세션의 워커에 하나의 변이가 할당되고 버킷에서 발생하는 나머지 변이가 처리됩니다. 즉, 디버그 세션이 진행 중일 때 소스 버킷에서 발생하는 나머지 변이는 차단되지 않습니다.
디버거는 프로덕션 환경에서는 사용해서는 안 되며 개발 환경에서 사용하는 것이 가장 좋습니다. 디버거 세션이 진행되는 동안 나머지 변이는 함수에 의해 처리됩니다. 앞서 살펴본 vbucket-워커 간 할당은 잘 유지되지만 디버거에 사용된 돌연변이는 순서가 바뀌어 처리됩니다. 따라서 프로덕션 환경의 디버거 세션에서는 타이밍 문제가 발생할 수 있으며, 중간에 디버그 세션이 종료될 경우 돌연변이가 손실될 수 있습니다. 또한 함수의 작업이 특정 문서에 대한 돌연변이 순서에 민감한 경우 순서를 벗어난 돌연변이 처리로 인해 상태가 올바르지 않을 수 있습니다.
이 2부로 구성된 시리즈를 통해 워커 오더링의 의미에 대해 잘 이해하셨기를 바라며, 다음과 같은 기능도 간단히 살펴볼 수 있었기를 바랍니다. 카우치베이스 이벤트 서비스.
