올해 초부터 저희(카우치베이스 인덱싱 팀)는 다음과 같은 개선 프로젝트에 착수했습니다. 인덱싱 서비스 on 카펠라. 이 블로그에서는 이 프로젝트를 시작할 때 달성하고자 했던 목표와 그 목표를 달성하기 위해 제공된 개선 사항 목록에 대해 설명합니다. 이러한 개선 사항의 대부분은 Capella(Couchbase의 클라우드 데이터베이스)를 대상으로 하지만, 자체 관리형 Couchbase Server 클러스터에도 유효하다는 점에 유의하시기 바랍니다.

목표

    • 더 빠른 확장 작업: 클라우드 데이터베이스의 경우 확장은 매우 빈번한 작업이 될 수 있으므로 속도가 빨라야 합니다.
    • 저사양 하드웨어에 대한 지원을 개선합니다: 사용자는 처음에는 저사양 하드웨어로 시작하고 나중에 애플리케이션 수요가 증가하면 더 많은/더 높은 사양의 하드웨어를 프로비저닝할 수 있습니다.
    • 느린 디스크 I/O에 대한 지원을 개선합니다: 클라우드 배포는 직접 연결된 SSD보다 속도가 느릴 수 있는 스토리지와 같은 EBS를 사용합니다. 따라서 클라우드 환경에서는 단일 I/O 작업의 비용이 배가됩니다. 

궁극적인 목표는 전반적인 사용자 경험을 개선하는 것이었습니다.

다음 섹션에서는 인덱스 서비스 개선 사항 의 개선 사항과 이러한 개선 사항이 위에서 언급한 목표를 어떻게 달성하는지 설명합니다.

더 빠른 확장 작업

사용자 애플리케이션 워크로드는 수시로 증가/감소할 수 있습니다. 애플리케이션 워크로드가 증가할 것으로 예상되는 경우 사용자는 "노드 추가(즉, 스케일 아웃)" 또는 "노드의 CPU/메모리 증가(즉, 스케일 업)"를 수행하거나 두 가지를 모두 수행할 수 있습니다. 

확장하려면, 카펠라 는 기존 노드와 동일한 구성을 가진 인덱스 서비스 노드를 클러스터에 더 추가합니다. 그 다음에는 카우치베이스 서버 재조정인덱스가 현재 호스트 노드에서 클러스터의 다른 노드로 이동될 수 있습니다. 이 이동은 모든 인덱서 노드에 걸쳐 균형 잡힌 부하 분산을 위해 수행됩니다.  

확장하려면, 카펠라 스케일링 작업 내부적으로 일련의 카우치베이스 서버의 스왑 리밸런싱 작업을 수행합니다. 각 스왑 리밸런싱은 업그레이드된 구성을 가진 새 노드를 하나 추가하고 이전 구성을 가진 이전 노드를 하나 제거합니다. 모든 이전 노드가 새 노드로 교체되면 확장 작업이 완료됩니다. 스왑 리밸런싱 중에 인덱스 서비스는 인덱스가 손실되지 않도록 인덱스를 이전 노드에서 새 노드로 이동해야 합니다.

인덱스 서비스는 (1) 다음을 사용하여 인덱스를 재구축하여 인덱스 이동을 수행합니다. 데이터 변경 프로토콜(DCP) 를 생성한 다음 (2) 소스 노드에서 인덱스를 삭제합니다. 대상 노드에서 인덱스를 다시 빌드하는 것은 CPU를 많이 사용할 수 있으므로 인덱스 서비스는 인덱스를 배치. 각 배치는 데이터 서비스에서 데이터 스트림을 읽어야 하며 인덱스는 인덱스 서비스 노드에 구축됩니다. 인덱스 배치가 대상 노드로 이동되면, 해당 인덱스 배치는 다음과 같은 서비스를 제공할 수 있습니다. N1QL 쿼리 (인덱스 스캔)을 대상 노드에서 수행합니다. 

스케일 아웃 예시

다음 다이어그램은 DCP 기반 리밸런스를 사용하는 2단계 "스케일 아웃" 워크플로우의 예시를 보여줍니다. 여기서 인덱스 서비스는 인덱스 3, 6, 9를 새 노드로 이동하기로 결정했습니다. 마찬가지로 인덱스 5도 노드 1에서 노드 2로 이동합니다. 따라서 첫 번째 단계에서 인덱스 3, 6, 9는 DCP의 도움으로 새 인덱스 노드에서 재구축됩니다. 마찬가지로 인덱스 5도 노드 2에서 다시 빌드됩니다.

그런 다음 두 번째 단계에서는 새 노드의 인덱스 3, 6, 9가 활성화되고 이전 호스트에서 이전 사본이 삭제됩니다. 마찬가지로 노드 2의 인덱스 5가 활성화되고 이전 사본은 노드 1에서 삭제됩니다.

확장 예제

다음 다이어그램은 노드에서 스케일 업 작업을 수행하는 데 사용되는 DCP 기반 스왑 리밸런싱 프로세스를 설명합니다. 여기서 첫 번째 단계에서는 클러스터에 새 인덱스 노드가 추가됩니다. 인덱스 서비스는 인덱스 3과 4를 새 인덱스 노드로 옮기고, 인덱스 5는 인덱스 노드 1로 옮기기로 결정했습니다. 따라서 첫 번째 단계에서 인덱스 3과 4는 새 인덱스 노드에서 재구축되고 인덱스 5는 인덱스 노드 1에서 재구축됩니다.

두 번째 단계에서는 인덱스 3, 4, 5에 대한 인덱스 빌드가 완료되면 해당 대상 노드에서 인덱스가 활성화되고 인덱스 노드 2가 클러스터에서 제거됩니다.

Couchbase Server 7.2.2에서는 다음과 같이 확장 작업이 더 빨라졌습니다:

    1. 일괄적으로 이동하는 인덱스 수 늘리기
      기본적으로 대상 노드에서 재구축되는 인덱스의 수는 적은 수로 제한됩니다. 적은 수를 선택한 이유는 인덱스 재구성과 인덱스 스캔 간의 리소스(CPU) 경합을 피하기 위해서입니다. 이 리소스 경합 문제를 해결하기 위해, Couchbase Server 7.2.2에서는 해당 노드의 모든 인덱스가 다시 빌드될 때까지 인덱스 스캔을 새 노드로 포워딩하지 않도록 했습니다. 이렇게 하면 전체 CPU를 인덱스 재구축에 사용할 수 있으므로 한 번에 더 많은 인덱스를 이동할 수 있습니다. 더 큰 배치는 인덱스 배치를 클러스터의 "비어 있는" 노드로 이동하는 경우에만 사용된다는 점에 유의하세요. 비어 있지 않은 노드(즉, 일부 인덱스를 호스팅하고 있는 노드)의 경우, 인덱스 스캔을 제공해야 하므로 CPU 공유가 필요합니다. 그렇기 때문에 인덱스가 빈 노드로 이동하는 경우에만 더 큰 배치 크기가 사용됩니다. 다음은 기본 배치 크기입니다:

비어 있지 않은 노드 배치 크기: 3
배치 크기 비우기: 20

참고: 배치 크기를 늘리면 데이터 서비스에서 데이터 항목을 읽는 횟수도 줄어들기 때문에 데이터 서비스의 부하를 줄일 수 있습니다.

    1. 기존 노드 간 인덱스 이동 방지
      스케일 아웃의 경우, 인덱스 서비스는 클러스터의 기존 노드 간에 인덱스를 이동할 수 있습니다. 마찬가지로, 스왑 리밸런싱의 경우, 인덱스 서비스는 인덱스를 이전 노드에서 다른 기존 노드로 옮길 수도 있습니다. 이러한 인덱스 이동은 주로 클러스터에서 균형 잡힌 부하 분산을 달성하기 위해 수행됩니다. 그러나 개념적으로 이러한 추가 인덱스 이동은 확장 오버헤드를 추가합니다.

카우치베이스 서버 7.2.2에서는 인덱스의 이동이 기능을 보장하는 데 필요한 이동으로 제한됩니다. 불필요한 이동은 피할 수 있습니다.

위의 예에서 스케일 아웃의 경우, 인덱스 5를 노드 1에서 노드 2로 이동하는 것은 피할 수 있습니다. 마찬가지로 스케일 업의 경우 인덱스 5는 노드 1이 아닌 새로 추가된 노드로 이동합니다.

균형 잡힌 부하 분산을 위해 스케일링 작업이 완료된 후 명시적으로 리밸런싱 작업을 트리거할 수 있습니다.

실험 결과

이 실험에서는 인덱스 서비스에 대한 스케일 아웃, 즉 3개의 인덱스 서비스 노드에서 4개의 인덱스 서비스 노드로 확장하는 것을 수행합니다. 3개의 인덱스 서비스 노드에 100개의 인덱스가 분산되어 있습니다. 스케일링의 일환으로 이 100개의 인덱스는 4개의 노드에 다시 분산됩니다. 또한 리밸런싱 작업 중에는 프론트엔드 데이터 업데이트 워크로드와 스캔 워크로드가 실행됩니다. 따라서 이 실험을 통해 지속적인 리밸런싱 작업이 들어오는 쿼리에 미치는 영향이 줄어드는 것을 확인할 수 있었습니다.

결과 표:

카우치베이스 서버 버전 7.2.0 7.2.2
스케일 아웃에 소요되는 시간(인덱스 노드 3개에서 4개로) 20.7분 6.8분
확장 작업 중 데이터 서비스 CPU 사용량 400% 270%

위의 결과 외에도 내부 테스트에서 다음과 같은 결과가 관찰되었습니다. 95번째 및 99번째 백분위수 쿼리 지연 시간 8배 및 15배 개선 를 각각 입력합니다.

참고: 이 기능은 프로비저닝된 Capella 클러스터에서 기본적으로 사용 설정되어 있습니다. 자체 관리 클러스터의 경우 다음 설정을 사용하여 활성화하세요.

다음 REST 명령을 사용하여 빈 노드 일괄 처리를 활성화할 수 있습니다:

curl -X POST -u http://:9102/settings --data '{"indexer.rebalance.enableEmptyNodeBatching" : true}'

이 REST 명령을 사용하여 빈 노드 배치 크기를 25로 변경할 수 있습니다:

curl -X POST -u http://:9102/settings --data '{"indexer.rebalance.emptyNodeBuildBatchSize" : 25}'

다음 단계는 무엇인가요?

이 블로그의 다음 부분에서는 Couchbase Server 7.2.2의 더 많은 인덱스 서비스 개선 사항에 대해 설명합니다.

카우치베이스 제품에 대해 자세히 알아보세요:

작성자

게시자 아밋 쿨카르니

아밋 쿨카니는 글로벌 보조 인덱스의 Couchbase에서 엔지니어링 매니저로 일하고 있습니다. 그는 분산 시스템, 분산 NoSQL 데이터베이스, 클라우드 스토리지, 스토리지 가상화 등과 같은 기술을 연구한 경험이 있습니다.

댓글 하나

  1. "인덱스 서비스는 (1) 대상 노드에서 데이터 변경 프로토콜(DCP)을 사용하여 인덱스를 재구축한 다음 (2) 소스 노드에서 인덱스를 삭제하는 방식으로 인덱스 이동을 수행합니다."

    노드 1에서 노드 2로 물리적 인덱스 파일을 복사하는 것이 더 간단하고 훨씬 더 효율적이지 않을까요? 어쨌든 GSI는 (보조 키, PK) 쌍이므로 물리적 사본이 유효할 것입니다. 제가 무엇을 놓치고 있나요?

    1. 오버헤드를 줄여주는 최신 새 기능을 확인해 보세요: https://www.couchbase.com/blog/file-transfer-index-rebalance/ - Couchbase Server 7.6부터.

댓글 남기기