에서 이 시리즈의 첫 번째 파트에서 Couchbase 클러스터의 크기를 결정하는 5가지 요소에 대한 개요를 설명했습니다: RAM, 디스크(IO 및 크기), CPU, 네트워크 및 데이터 배포입니다. 이번 2부에서는 구체적인 사용 사례와 시나리오를 통해 다양한 애플리케이션 설계와 워크로드가 이러한 다양한 요소에 어떤 영향을 미치는지 자세히 살펴보고자 합니다. 애플리케이션의 세 번째 항목 시리즈에서는 다양한 하드웨어 및 인프라 선택에 대해 설명합니다. 마지막으로 네 번째 항목 에서는 사이징 요구 사항을 이해하기 위해 Cocuhbase 내부와 외부에서 모니터링할 수 있는 메트릭을 살펴봅니다.
Couchbase Server 1.8 클러스터의 크기는 매우 간단했으며, 이에 대한 논의는 여기에서 계산기와 함께 확인할 수 있습니다. 최근 2.0에 추가된 기능으로 인해 조금 더 복잡해졌습니다...
클러스터 규모에 영향을 미치는 두 가지 애플리케이션 설계 및 요구 사항 고려 사항을 살펴보겠습니다:
- 애플리케이션이 주로(또는 독점적으로) 개별 문서 액세스로 구성되어 있나요? 아니면 색인 및 쿼리 기능을 사용할 예정인가요? 키/문서 액세스 및 보기를 결합하는 방법에 대한 좋은 설명은 여기에서 확인할 수 있습니다.
- 새로운 데이터센터 간 복제(XDCR) 기능?
1.8에서 개별 문서 액세스 및 업그레이드
가장 간단한 사용 사례는 애플리케이션에 개별 문서 액세스만 필요한 경우입니다(일반적으로 "키/값" 사용 사례라고 함). 여기에는 세션 및 사용자 프로필 저장소, 광고 타겟팅 애플리케이션, 많은 소셜 게임 등이 포함됩니다.
이러한 사용 사례의 크기 조정은 몇 가지 수정 사항을 제외하고 1.8 크기 조정 가이드라인과 매우 유사하게 매핑됩니다. 모든 크기 조정 논의와 마찬가지로 동일한 5가지 결정 요소가 적용되며, 여기서는 일반적으로 RAM 크기 조정이 가장 중요한 요소입니다.
- RAM: 참조 파트 1 를 참조하여 RAM 크기를 적절하게 설정할 때 고려해야 할 사항에 대해 알아보세요. 1.8에 익숙한 분들은 여기서 크게 달라진 점이 없습니다. 익숙하지 않으시다면 크기 조정 가이드라인과 계산기를 살펴보세요.
- 디스크: Couchbase Server 1.8에서 2.0으로 업그레이드하려면 훨씬 더 많은 디스크 공간이 필요할 수 있습니다. IO 관점에서 볼 때, 추가 전용 디스크 형식은 실제로 1.8보다 데이터를 더 빠르고 일관되게 읽고 쓸 수 있습니다. 그러나 디스크 파일을 온라인으로 압축해야 하므로 어느 정도의 추가 디스크 IO가 필요합니다. 이 블로그 는 압축을 더 잘 이해하는 데 도움이 될 수 있습니다.
- CPU: 에서 언급했듯이 파트 1를 사용하면 애플리케이션이 RAM을 읽고 쓰는 작업을 매우 적은 CPU로 매우 효율적으로 처리할 수 있습니다. 자동 압축을 추가하면 디스크 IO로 인해 CPU 활동이 약간 증가하지만 일반적으로 애플리케이션의 성능에는 영향을 미치지 않습니다. 일반적인 1.x 설치에서는 2개의 코어로도 '충분'하지만, 기본적인 '키 문서' 사용 사례의 경우에도 이 권장 사항을 최소 4개로 늘리고 있습니다.
???1.x에서 업그레이드할 때는 카우치베이스 지원 환경을 검토하고 권장 사항을 제공하며 최대한 원활하게 업그레이드할 수 있도록 도와드릴 수 있습니다.
데이터센터 간 복제(XDCR)
여러 상황/환경에서 여러 Couchbase 클러스터에 걸쳐 데이터를 복제해야 하는 경우가 많습니다. 재해 복구, 데이터의 지리적 위치 또는 단순히 테스트를 위한 동기화를 위해 XDCR이 필요합니다. Couchbase 클러스터의 크기를 효과적으로 조정하는 것이 중요합니다. 이러한 용량 요구 사항은 클러스터가 수행해야 하는 다른 모든 요구 사항에 추가됩니다.
이 논의의 목적을 위해 XDCR에 대한 "소스" 및 "대상" 클러스터 요구 사항을 별도로 살펴보겠습니다. 프로덕션에서는 여러 단방향 복제 스트림을 결합하여 일대다, 다대일 또는 다대다 토폴로지를 가질 수 있습니다.
1. 소스 클러스터
- RAM: 이것은 약간 가변적이지만, 데이터를 다른 클러스터로 복제하는 프로세스를 처리하는 데만 약간의 추가 RAM이 필요한 것으로 나타났습니다. 버킷(및 복제 스트림) 수에 따라 약간 달라지지만, 데이터를 저장하는 데 필요한 것 이상으로 노드당 약 2GB의 RAM을 여유 공간으로 남겨두는 것이 좋습니다. 이는 Erlang 프로세스(Linux의 경우 beam.smp, Windows의 경우 erl.exe)에 필요합니다.
- 디스크: 현재 XDCR의 구현은 소스 클러스터의 디스크 하위 시스템에서 대상으로 데이터를 전송합니다. 이렇게 하면 RAM에 대기열이 유지되지 않으며 모든 데이터를 다시 보내지 않고도 복제 프로세스를 다시 시작할 수 있습니다. 또한 로컬 애플리케이션의 여러 쓰기 작업이 복제되기 전에 자동으로 중복 제거되므로 귀중한 네트워크 대역폭을 절약할 수 있습니다. 그러나 이는 모든 XDCR의 소스 클러스터가 문서가 디스크에 지속된 후 이를 읽기 위해 디스크 IO 요구 사항이 증가한다는 것을 의미합니다.
- CPU: 데이터를 처리하고 다른 클러스터로 전송하기 위해 XDCR의 소스 클러스터의 CPU 요구 사항도 증가합니다. 기본적으로 복제당 노드당 32개의 스트림이 있습니다. 이 숫자는 늘릴 수 있지만 스트림 수가 많을수록 더 많은 CPU가 필요하다는 점에 유의하세요. 일반적인 모범 사례는 복제되는 XDCR 버킷당 하나의 추가 코어를 보유하는 것입니다.
2. 대상 클러스터:
- RAM 및 디스크 크기: 일반적으로 말할 필요도 없지만, 클러스터에 더 많은 데이터를 보내는 경우(다른 클러스터에서 데이터를 집계할 때처럼) 해당 데이터를 포함하려면 더 많은 RAM과 디스크 공간이 필요합니다. 단순히 동일한 데이터 집합을 복제하는 경우라면 여기서 요구 사항이 증가하지 않습니다.
- 디스크 IO: 동일한 데이터 세트에 대해 더 많은 공간이 필요하지 않더라도(즉, 메모리에 소스의 작업 세트가 필요하지 않더라도), XDCR을 통해 소스 클러스터에서 더 많은 쓰기가 발생할 수 있습니다. 이를 디스크에 유지하려면 충분한 디스크 IO가 필요하며, 다음과 같은 작업을 수행하려면 충분한 IO 대역폭도 필요합니다. 컴팩트 이 데이터는 로컬 애플리케이션 쓰기와 함께 저장됩니다. ???
- 일반적으로 소스 클러스터와 대상 클러스터의 크기를 모두 조정하고 워크로드에 대한 성능을 테스트하는 것이 중요합니다. 그러나 전송해야 하는 데이터가 병렬로 수행되므로 노드가 많을수록 소스 클러스터의 XDCR 성능이 크게 향상되는 것으로 알려져 있습니다.
3. 네트워크
카우치베이스 서버의 클러스터 간 네트워크 요구 사항은 일반적으로 크게 고려할 필요가 없지만, WAN 링크를 통해 데이터를 전송하는 경우에는 조금 더 고려해야 할 수 있습니다. 카우치베이스 서버는 네트워크가 허용하는 대로 자동으로 XDCR을 체크포인트하고 다시 시작하지만, 복제는 궁극적으로 데이터가 반대편에 도달할 수 있는 경우에만 효과적입니다.
4. 양방향 복제 및 기타 토폴로지
이 논의에서는 단일 버킷을 복제하는 단일 소스 및 대상 클러스터에 초점을 맞추었습니다. 양방향 복제는 각 클러스터를 소스 및 대상 모두의 용량 요구 사항을 충족하는 소스와 대상으로 전환합니다.
여러 클러스터 및/또는 여러 버킷을 결합할 때는 각각의 용량이 충분한지 확인하는 것이 중요합니다. 예를 들어, 1 대 다수의 경우 하나의 소스에 더 많은 복제 스트림이 생성되고, 다수 대 다수의 경우 대상 클러스터에 상당한 오버헤드(디스크 공간/IO/ CPU)가 발생합니다.
보기 및 쿼리
Couchbase Server 2.0의 가장 인기 있는 새로운 기능 중 하나는 데이터 인덱싱/쿼리를 위한 뷰가 추가된 것입니다. 다른 새로운 기능과 마찬가지로 클러스터 크기와 관련된 특정 요구 사항과 고려 사항이 함께 제공됩니다.
현재 뷰 시스템은 디스크 기반이므로 디스크 공간과 IO 요구 사항이 모두 증가하며, OS에 내장된 IO 캐싱을 통해 쿼리 처리량과 지연 시간을 개선하려면 객체 기반 캐시 외부에 더 많은 RAM이 필요합니다.
실제 영향은 애플리케이션의 작업 부하와 디자인 문서 및 뷰 정의의 양과 복잡성 모두에 따라 크게 달라집니다. 뷰를 설계할 때 이러한 뷰 작성 모범 사례를 따라 크기 조정 요구 사항을 최대한 완화하고 줄이는 것이 매우 중요합니다. 쓰기가 많은 워크로드는 실제 인덱스 업데이트에 더 많은 부담을 주고, 읽기 위주의 워크로드는 해당 인덱스 쿼리에 더 많은 부하를 줍니다.
1. 색인 업데이트
문서를 삽입하거나 업데이트하면 결국 색인 업데이트가 트리거됩니다. 이 트리거는 일반적인 백그라운드 프로세스의 일부이거나 애플리케이션 요청에 의해 발생합니다. 이러한 업데이트가 효과적으로 처리되면 다음과 같은 영향을 미칩니다:
- 디스크 크기: 각 디자인 문서와 그 안에 있는 각 뷰에 대해 추가 파일이 생성됩니다. 이러한 파일은 뷰 설명에 포함된 키와 값으로 채워집니다(따라서 가능한 한 작게 유지하는 것이 중요합니다). 이러한 파일은 추가 전용 파일이므로 새로 삽입, 업데이트 또는 삭제할 때마다 커지며 데이터 파일과 비슷한 방식으로 압축됩니다.
- 디스크 IO: 뷰 사용이 시스템에 미치는 가장 큰 영향은 아마도 디스크 IO에 있을 것입니다. 각 문서 쓰기가 여러 인덱스 파일에 기록되어야 할 수 있으므로 인덱스 업데이트 자체에 상당한 양의 IO가 필요할 수 있습니다. 이러한 업데이트는 데이터베이스의 정상적인 기능에 영향을 미치지 않도록 별도의 스레드와 프로세스에 의해 처리되지만, 인덱스를 최신 상태로 유지하려면 충분한 IO를 확보하는 것이 중요합니다. 또한 인덱스의 정상적인 자동 압축은 어느 정도의 디스크 IO를 소비하므로 디스크 파일의 크기를 조절하는 데 필요합니다.
- CPU: 디스크 IO와 함께 뷰 업데이트에는 CPU가 추가로 사용됩니다. 기본적으로 노드당 버킷당 4개의 인덱서가 있습니다. 코어가 많은 시스템에서는 이 수를 늘리면 이점이 있습니다. 일반적으로 디자인 문서당 1개의 코어를 추가하는 것이 좋습니다(각 뷰는 디자인 문서 내에서 순차적으로 처리되지만 여러 디자인 문서를 병렬로 처리할 수 있음).
- 복제 인덱스: 기본적으로 꺼져 있지만 켜면 노드 장애 후 쿼리 성능을 크게 향상시킬 수 있습니다. 그러나 시스템에 필요한 디스크 공간, 디스크 IO 및 CPU 부하를 최소 두 배(구성된 복제본 수에 따라 다름)로 증가시킵니다. 기본 인덱서와 함께 기본적으로 노드당 버킷당 2개의 복제 인덱서가 있습니다.???
인덱스 업데이트 프로세스는 각 노드가 자신의 데이터 처리만 담당하기 때문에 노드를 더 추가하면 선형적으로 확장됩니다.
인덱스의 디스크 경로는 데이터 파일과 별도의 드라이브/드라이브에 있도록 구성하는 것이 가장 좋습니다. 각 파일 세트는 추가 전용이므로 파일에 대한 쓰기는 항상 순차적으로 이루어집니다. 그러나 데이터 파일과 인덱스 파일을 모두 결합하면 공유 디스크에 훨씬 더 많은 임의의 IO가 생성됩니다. 또한 쓰기 작업이 많은 워크로드는 SSD 사용을 심각하게 고려해야 합니다.
2. 쿼리 보기
애플리케이션이 뷰를 쿼리할 때 최상의 성능을 얻으려면 다음과 같은 크기 조정 영향을 고려해야 합니다:
- RAM: 인덱스 파일이 디스크에 저장되고 디스크에서 액세스되지만, 이러한 디스크 파일의 형식은 OS의 일반 디스크 IO 캐싱에 매우 적합합니다. 따라서 Couchbase 할당량 외에 일정량의 RAM을 시스템에 남겨두는 것이 중요합니다. 실제 수치는 인덱스의 크기에 따라 크게 달라지지만, 상대적으로 적은 양이라도 쿼리 지연 시간과 성능에 큰 영향을 미칠 수 있습니다.
- 디스크 IO: 단순히 뷰를 쿼리하는 것만으로는 추가 공간이 필요하지 않지만, 어느 정도의 추가 디스크 IO가 필요합니다. 이는 인덱스가 얼마나 자주 업데이트되고 쿼리되는지, 그리고 인덱스를 캐시하는 데 사용할 수 있는 RAM의 양에 따라 크게 달라집니다.
- CPU: 개별 쿼리 처리 및 여러 노드의 결과 병합으로 인해 뷰를 쿼리할 때 CPU 요구 사항도 증가합니다.???
색인 및 쿼리의 수집/수집 구현을 고려할 때, 모든 노드는 모든 쿼리 요청에 참여해야 합니다. 쿼리 처리량은 사용 가능한 파일 시스템 캐시 또는 물리적 하드웨어를 늘려서 개선할 수 있습니다.
3. 조회수가 리밸런싱에 미치는 영향
Couchbase Server 2.0의 새로운 보기 기능을 활용할 때는 클러스터의 리밸런싱에 미칠 영향을 알고 대비하는 것이 중요합니다.
리밸런싱 프로세스의 어느 시점에서 한 노드에서 다른 노드로 이동하는 데이터는 쿼리가 일관되게 동일한 결과를 반환하도록 하기 위해 해당 노드의 인덱스에 반영되어야 합니다. 저희는 이 업데이트를 마지막에 한꺼번에 처리하지 않고 전체 리밸런싱 프로세스에 걸쳐 수행하도록 시스템을 설계했습니다. 각 데이터 파티션 이동 로 설정하면 소유권을 이전하기 전에 인덱스가 업데이트됩니다. 이 동작은 구성할 수 있습니다. 애플리케이션에서 일관되지 않은 결과를 처리하고 재조정 시간을 크게 단축할 수 있는 경우 인덱스 인식 재조정을 비활성화할 수 있습니다.
이 설정을 그대로 두면 다음과 같은 영향이 발생합니다:
- RAM: 수행해야 할 추가 처리가 있으므로 각 대상 노드의 디스크 쓰기 대기열에 보류 중인 쓰기를 보관하는 데 더 많은 RAM이 사용됩니다.
- 디스크 크기: 뷰의 안전성과 일관성을 보장하기 위해 재조정하는 동안 디스크 공간이 크게 증가합니다. 데이터가 더 이상 필요하지 않으면 정리되지만 쓰기량이 많기 때문에 재밸런싱이 완료될 때까지 압축 프로세스가 따라가지 못할 수 있습니다.
- 디스크 IO: 많은 양의 데이터가 동시에 읽고, 쓰고, 인덱싱되기 때문에 리밸런싱 중에 디스크 IO가 급격히 증가합니다.
Couchbase의 다른 거의 모든 부분과 마찬가지로, 리밸런싱 프로세스는 더 많은 노드를 보유함으로써 이점을 얻을 수 있습니다. 클러스터에 노드를 하나만 추가한다고 상상해 보세요. 극단적인 예로, 노드를 1개에서 2개로 늘리는 것은 항상 최악의 시나리오입니다. 데이터 세트의 절반을 이동해야 하기 때문입니다. 대부분의 경우, 리밸런싱을 하는 동안 복제 데이터 세트도 함께 생성됩니다. 이 특별한 경우에는 전체 데이터 읽기 및 수신을 처리할 수 있는 노드가 하나뿐입니다. 반면, 21개에서 22개로 노드를 늘리는 것은 훨씬 덜 집약적입니다. 데이터의 1/21만 이동하면 되므로 복제본이 생성되지 않고 읽기/수신 부하가 21개 노드 모두에서 공유될 가능성이 높습니다.
결론
복잡한 시스템(특히 데이터베이스)의 경우 사이징은 결코 쉬운 일이 아닙니다. 변수는 다양하며 고려 사항과 결정은 항상 애플리케이션의 개별 요구 사항과 리소스 가용성을 기반으로 이루어져야 합니다. 저희는 지속적으로 지침을 제공하기 위해 최선을 다할 것이지만, 배포 전후에 애플리케이션 워크로드/요구 사항에 따라 시스템을 테스트하고 단계적으로 구축하는 것이 매우 중요합니다.
그리고 다음 및 세 번째 항목 이 시리즈에서는 프로덕션 카우치베이스 서버 클러스터에 대한 몇 가지 구체적인 배포 및 하드웨어 권장 사항/고려 사항을 제공합니다.
