노드는 몇 개인가요? 1부: 1부: Couchbase Server 2.0 클러스터 크기 조정에 대한 소개

이 시리즈의 첫 번째 부분에서는 프로덕션용 Couchbase Server 2.0 클러스터의 크기를 조정할 때 고려해야 할 사항에 대한 개요를 제공합니다. 그리고 두 번째 파에서는 구체적인 사용 사례와 시나리오에 대해 자세히 살펴봅니다. 의 3위 일부로 이동합니다. 하드웨어 고려 사항 및 4th 에서는 클러스터 크기 조정 및 클러스터 확장 시기를 결정하기 위한 메트릭과 모니터링에 대해 설명합니다.

Couchbase 클러스터를 배포하려고 할 때 가장 흔하고 중요한 질문은 아마도 다음과 같을 것입니다: 몇 개의 노드가 필요한가요?

여기에는 분명히 많은 변수가 있지만, 기본적인 아이디어는 워크로드 및 데이터 세트에 대한 전반적인 성능 및 용량 요구 사항을 평가한 다음 이를 사용 가능한 하드웨어 및 리소스로 나누는 것입니다. 이러한 요소와 프로덕션 환경에서 Couchbase 클러스터를 실행하기 위한 일반적인 관행에 대한 높은 수준의 시각적 토론을 보려면 최근 제가 진행한 Couchbase 컨퍼런스 프레젠테이션 중 하나를 참조하세요: 24×7 프로덕션 환경의 Couchbase Server 2.0

Couchbase 클러스터의 크기는 안정성과 성능에 매우 중요합니다. 애플리케이션은 캐시에서 가능한 한 많은 읽기와 쓰기를 처리할 수 있는 IO 용량을 원합니다. 필요한 수준의 성능을 유지하면서 시스템에서 수행되는 다른 모든 작업을 지원하려면 모든 다양한 영역에 충분한 용량이 있어야 합니다.

이 논의에서는 Couchbase 클러스터의 규모를 결정할 때 알아야 할 5가지 결정 요소를 언급하겠습니다: RAM, 디스크(IO 및 공간), CPU, 네트워크 대역폭 그리고 전반적으로 데이터 배포.

1. RAM: 올바른 크기를 설정하는 데 가장 중요한 영역 중 하나인 RAM은 Couchbase의 빠른 속도를 가능하게 하는 요소입니다. 캐시된 문서를 통해 읽기는 매우 짧은 지연 시간과 높은 처리량으로 제공되며, 사용 가능한 RAM은 쓰기에도 동일한 기능을 수행합니다.

곧 크기 조정 계산기가 업데이트될 예정이지만, 필요한 RAM의 양은 활성 및 복제 데이터 세트, 이 모든 것을 추적하는 데 필요한 메타데이터(각 항목당 약 64바이트의 오버헤드와 키 길이), 전체 데이터 세트 중 RAM에 캐시해야 하는 양('작업 세트'), OS가 디스크 IO 캐싱을 잘 수행하는 데 필요한 모든 오버헤드를 합산한 값으로 결정될 것입니다.

카우치베이스 서버 2.0에서는 항목별 메타데이터 오버헤드를 줄였습니다. 또한 애플리케이션 워크로드에 따라 어떤 데이터를 RAM에 보관해야 하는지 객체 캐싱 계층이 보다 지능적으로 판단하도록 설계된 NRU(최근 사용되지 않음) 비트를 사용하도록 '이젝션' 알고리즘을 크게 개선했습니다.

새로운 보기/색인 기능을 활용할 때는 OS가 디스크 요청을 캐싱하는 데 최선을 다할 수 있도록 RAM을 예약해 두는 것도 좋습니다. 이에 대한 자세한 내용은 파트 2.

2. 디스크: 디스크 하위 시스템의 요구 사항은 크기와 IO라는 두 가지 구성 요소로 나뉩니다.

• 크기: Couchbase Server 2.0은 1.8보다 디스크 크기 요구 사항이 증가합니다. 일반적으로 디스크 공간은 "저렴한" 것으로 간주되므로 문제가 되지 않지만, 이를 고려하는 것이 중요합니다.

제자리 업데이트 디스크 형식에서 추가 전용 디스크 형식으로 전환하면 모든 쓰기(삽입/업데이트/삭제)가 파일에 새 항목을 생성하게 됩니다. 이는 안정성, 성능, 성능의 일관성 및 워밍업/시작 시간 측면에서 엄청난 이점을 가져다줍니다. 하지만 디스크 크기가 무한대로 커질 수 있다는 단점도 있습니다.

1.8에서는 업데이트/삭제가 잦은 워크로드에서 온디스크 파일 조각화로 인해 성능 저하가 발생하기도 했습니다. 2.0에서는 이러한 조각화가 발생하지 않을 뿐만 아니라, 자동 압축 프로세스가 내장되어 있어 관련 데이터 사본만 남기고 디스크 파일 자체의 크기를 줄일 수 있습니다.

워크로드에 따라 필요한 디스크 크기는 추가 전용 디스크 형식으로 인해 전체 데이터 세트 크기(활성 및 복제본 데이터 합산)의 2~3배에 달할 수 있습니다. 업데이트/삭제 워크로드가 많으면 삽입 및 읽기 워크로드보다 크기가 더 크게 증가합니다. 실제로는 자동 압축 프로세스가 실행되면서 시간이 지남에 따라 크기가 크게 커지거나 줄어들 가능성이 높습니다. 2~3배라는 수치는 데이터가 실제로 디스크에서 더 많은 공간을 차지하기보다는 이러한 확장 필요성에서 비롯된 것입니다.

Couchbase Server 2.0의 보기/색인 기능을 활용할 때 새로운 공간 요구 사항도 있습니다. 이에 대한 자세한 내용은 2부에서 다시 설명합니다.

• IO: 지속적인 쓰기 속도, 데이터베이스 파일 압축의 필요성 및 디스크 액세스가 필요한 다른 모든 요소의 조합이 됩니다. 카우치베이스 서버는 데이터베이스에 대한 쓰기를 RAM에 자동으로 버퍼링한 후 결국 디스크에 유지합니다. 따라서 이 소프트웨어는 디스크가 처리할 수 있는 것보다 훨씬 빠른 쓰기 속도를 수용할 수 있습니다. 그러나 이러한 쓰기를 유지하려면 결국 디스크에 모두 기록할 수 있는 충분한 IO가 필요합니다.

압축 프로세스의 임계값과 일정을 쉽게 구성하여 압축 프로세스가 시작되는 시기와 시작되지 않는 시기를 제어할 수 있지만, 압축을 성공적으로 완료하는 것이 디스크 크기를 유지하는 데 중요하다는 점을 명심하세요.

자세한 내용은 2부에서 자세히 설명하겠지만, 뷰/색인 및 데이터 센터 간 복제(XDCR)와 같은 Couchbase Server 2.0의 새로운 기능을 활용할 때는 디스크 IO의 크기를 올바르게 설정하는 것이 훨씬 더 중요해집니다.

마지막으로, 백업은 물론 공간이 필요하거나 디스크에 액세스해야 하는 Couchbase 외부의 모든 것을 백업할 수 있는 충분한 디스크 공간과 IO가 있는지 확인해야 합니다. 가능하면 데이터 파일, 인덱스, 설치/설정 디렉터리를 별도의 드라이브/장치에 분리할 수 있는 구성 옵션을 사용하여 IO와 공간을 효과적으로 할당하는 것이 가장 좋습니다.

3. CPU: 일반적으로 Couchbase Server 1.8에서는 큰 문제가 되지 않았지만, Couchbase Server 2.0의 새로운 기능에는 더 많은 양의 CPU가 필요합니다. 저희의 객체 기반 캐싱 레이어는 CPU에 부하가 걸리는 경우에도 짧은 지연 시간으로 매우 높은 요청 처리량을 허용하지만, 나머지 시스템이 원활하게 실행될 수 있도록 충분한 처리 능력을 확보하는 것이 중요할 것입니다. 일반적으로 최소 4개의 코어를 권장하며, XDCR로 복제되는 버킷당 1개의 추가 코어와 디자인 문서당 1개의 추가 코어(뷰 관련)가 필요합니다.

4. 네트워크: 대부분의 상황에서는 이것이 Couchbase 클러스터의 크기를 결정하는 요인은 아닙니다. 그러나 네트워크 수준에서 어떤 일이 일어나고 있는지 파악하고 애플리케이션과 Couchbase 노드 사이는 물론 노드 자체 간에 트래픽을 처리할 수 있는 충분한 대역폭이 있는지 확인하는 것이 항상 중요합니다. XDCR을 사용하면 클러스터 간에 충분한 대역폭을 확보하는 것도 중요합니다(종종 WAN을 통해 지리적으로 분산되어 있음).

네트워크는 거의 항상 지연 시간에 영향을 미치는 최종 병목 현상입니다. 예를 들어, 개별 문서 읽기/쓰기가 캐시에 들어오고 나갈 때 응답 시간은 Amazon AWS에서는 99번째 백분위수인 1~2ms, 표준 기가-e 네트워크에서는 500~900us, 그리고 10G 네트워크에서 200us 미만. 이 모든 것은 카우치베이스 서버 자체가 매우 낮은 지연 시간을 제공할 수 있다는 것을 나타내며, 일반적으로 추가 시간을 잡아먹는 것은 네트워크입니다. 마일리지가 다를 수 있으며 일반적인 비교 목적으로 이 벤치마크를 사용한다는 점을 명심하세요.

5. 데이터 배포: 다른 모든 것과 관계없이 데이터의 안전성을 확보하는 것은 항상 중요합니다. 카우치베이스는 기본적으로 분산 시스템으로 설계되어 있으며, 효과적으로 허용되는 경우에만 매우 선형적인 규모와 데이터 중복성을 제공할 수 있습니다.

극단적으로는 단일 노드로 모든 RAM/디스크/CPU/네트워크 요구 사항을 충족할 수 있습니다. 하지만 이는 명백한 단일 장애 지점을 발생시킵니다.

두 번째 노드를 추가하면 복제가 가능하지만 여전히 가장 이상적인 환경은 아닙니다. 한편으로는 어느 한 노드에 장애가 발생하면 단일 장애 지점이 발생하게 됩니다. 다른 한편으로는 클러스터에 노드가 많을수록 각 노드가 이동해야 하는 데이터의 양이 줄어들기 때문에 궁극적인 확장 요구 사항에서 이점을 얻을 수 있습니다.

이러한 이유로 다른 크기 조정 요소에 관계없이 항상 클러스터에 최소 3개의 노드를 권장합니다.

요구 사항의 최고 수준을 결정하는 요인은 항상 한 가지이며, 따라서 필요한 노드 수를 "결정"합니다. 예를 들어, 쓰기 워크로드가 매우 높은 상대적으로 작은 데이터 세트의 경우 전체 데이터 세트 크기보다는 디스크 처리량 요구 사항으로 인해 더 많은 노드가 필요합니다. 반면에 상대적으로 큰 데이터 세트의 읽기 작업량이 많은 워크로드는 RAM 요구 사항으로 인해 더 많은 노드가 필요합니다.

위의 모든 요소는 노드를 더 추가함으로써 선형적으로 확장할 수 있으며, 이점을 누릴 수 있습니다. 애플리케이션 읽기 및 쓰기가 노드 전체에 고르게 분산될 뿐만 아니라 압축, 재조정, 보기/색인 업데이트, XDCR과 같은 작업도 노드가 많을수록 큰 이점을 누릴 수 있습니다. 각 노드는 로컬 데이터 세트에서만 작동하면 되므로 디스크와 CPU 집약적인 프로세스를 모두 병렬로 수행할 수 있습니다.

모든 사람의 요구 사항과 리소스 가용성은 다양하지만, Couchbase를 매우 비싼 몇 개의 노드로 구성된 스케일업 아키텍처로 강제하는 대신 항상 더 작은 노드를 사용하는 편이 낫습니다.

마지막으로, 가이드라인과 계산기는 종이에 크기 조정 수치를 제공할 때 한계가 있습니다. 다양한 수준의 규모에서 특정 애플리케이션의 동작을 테스트하고 시스템이 적절하게 시작되고 크기가 유지되는지 지속적으로 모니터링하는 것이 가장 좋습니다.

파트 2 에서는 Couchbase Server 2.0 클러스터를 배포(또는 업그레이드)할 때 고려해야 할 사항에 대해 훨씬 더 자세히 설명합니다.

다음 시간까지...