SDK 3.0+로 내구성 있는 쓰기를 위한 성능 테스트와 Couchbase의 cbc-pillowfight를 사용한 인프라 설정에 대해 알아보세요.
성능에 영향을 미치는 다른 요소들이 있기 때문에 모든 데이터베이스의 내구성을 테스트하는 것은 주관적이고 까다로울 수 있습니다. 내구성이란 데이터의 활성, 복제본 및 영구 복사본에 쓸 수 있는 능력을 말합니다. Couchbase는 사용 사례와 SLA에 따라 다양한 수준의 내구성을 제공합니다. 그러나 궁극적으로 네트워크 속도, 디스크 쓰기 속도, 사용 가능한 CPU 리소스는 데이터베이스 자체만큼이나 성능에 민감합니다.
내구성 있는 쓰기의 성능(또는 고성능)을 정의하는 것은 무엇일까요? 작업 지연 시간인가요? 처리량(초당 작업 수)인가요? 사용 사례에 따라 다릅니다. 일반적인 대답은 보통... 둘 다입니다!
카우치베이스 SDK의 내구성 업데이트
이전 버전의 Couchbase SDK(3.0 이전)에는 다음과 같은 매개 변수를 사용한 내구성 있는 쓰기 기능이 있습니다. 복제 대상 그리고 persistTo. ReplicateTo 는 1~3개 복제본의 쓰기가 완료될 때까지 기다립니다. PersistTo 는 디스크의 활성 복사본도 쓰여질 때까지 기다립니다. 개발자들은 복제본과 디스크에 대한 내구성 있는 쓰기를 통해 더 세밀한 제어와 향상된 성능을 원했습니다.
카우치베이스 SDK 3.0은 약 1년 전에 출시되었습니다. 새 SDK 버전의 근본적인 업데이트는 지연 시간과 처리량 모두를 염두에 둔 내구성입니다.
문서에서 정의를 참조하세요:
내구성에는 세 가지 수준이 있습니다:
- 대다수 - 서버는 구성된 대부분의 복제본에서 변경 사항을 메모리에서 사용할 수 있는지 확인합니다.
- 다수결 및 활성 상태 유지 - 과반수 수준과 활성 노드의 디스크에 지속됩니다.
- PersistToMajority - 과반수 수준, 그리고 구성된 복제본의 대부분에서 디스크에 지속됩니다.
각 내구성 수준은 SDK가 다음을 사용하여 쓰기가 완료될 때까지 기다리므로 성능에 영향을 미칩니다. 다수, persistTo또는 둘 다.
관계형 데이터베이스를 사용하는 고객과 함께 일해 본 경험에 따르면, 가장 높은 내구성 수준을 선택하는 것이 당연한 결정입니다. 하지만 RDBMS는 쓰기가 완료되기 전에 읽기를 허용하지 않는 내구성을 아키텍처에 내장하고 있기 때문에 고객들의 경험은 상당히 다릅니다.
반면 Couchbase는 기존 RDBMS 사용자가 예상했던 것보다 더 세밀하게 내구성 설정을 제어할 수 있습니다. 예를 들어, Couchbase에는 버킷 수준의 내구성 설정합니다.
또한 내구성 선택은 사용 사례, 애플리케이션 및 SLA에 따라 달라집니다. 버킷 수준의 내구성으로 제어가 충분하지 않은 경우, Couchbase는 다음을 지원합니다. 쓰기 단위의 내구성 - 각 개별 쓰기를 특정 지속 시간으로 구성하거나 버킷 수준으로 설정할 수 있습니다. 즉, 모든 쓰기가 동일한 지속 시간 수준을 따르도록 설정할 수 있습니다.
테스트를 위한 서버 설정 고려 사항
데이터베이스 아키텍처의 내구성 메커니즘보다 더 중요한 것은 내구성 쓰기 성능을 테스트하기 위한 호스팅 머신 사양입니다. 카우치베이스는 데이터를 자동 하드닝하고 복제본이 활성과 함께 다른 노드에 상주하지 않도록 보장하므로 활성과 복제본을 동일한 디스크에 배치하지 않습니다.
즉, 복제본에 대한 쓰기는 네트워크 속도와 지연 시간의 영향을 받습니다. 네트워크 속도가 빠를수록 복제본에 대한 내구성 있는 쓰기(즉, 다수)가 더 빨라집니다. 내구성 있는 쓰기에 가장 큰 영향을 미치는 호스팅 기계 요소는 디스크 지연 시간과 처리량입니다. 카우치베이스는 속도뿐만 아니라 장애 발생 시 노드를 빠르고 효율적으로 복구하기 위해 지속성을 위해 로컬 SSD를 권장합니다.
퍼블릭 클라우드 고려 사항
오늘날 더 많은 고객이 속도, 단순성 및 일시적인 리소스 투자를 위해 퍼블릭 클라우드 환경에서 테스트 및 POC를 수행하고 있습니다.
스토리지/디스크 선택
퍼블릭 클라우드에서는 모든 제공업체가 일반적으로 가장 느린 EBS형 스토리지부터 고성능 NVRAM SSD까지 다양한 수준의 머신 인스턴스용 디스크 스토리지를 보유하고 있습니다.
모든 스토리지 유형이 작동하지만, 평가 대상 데이터베이스가 무엇이든 간에 볼륨 유형의 성능이 내구성 쓰기에서 더 큰 요소라는 것을 알고 있어야 합니다. 예를 들어 이 AWS 문서 링크 는 퍼블릭 클라우드 스토리지에서 스토리지 유형이 얼마나 복잡할 수 있는지 보여줍니다.
인스턴스 유형 선택
Couchbase 내구성을 성공적으로 테스트한 고객은 테스트 환경을 프로덕션 호스팅 환경과 일치시키려고 합니다. 그러나 고객들은 또한 t3.large 또는 t3.small 를 테스트한 다음 수행되지 않는 이유를 물어보세요.
네트워크 시나리오
최상의 성능을 위해 클라이언트가 서버 환경과 동일한 네트워크에 있는지 확인하세요. 퍼블릭 클라우드의 공개적으로 노출된 호스트 이름으로 무선으로 노트북에서 테스트를 실행하는 경우 품질이 좋지 않은 경우가 많습니다. 무선에서 라우터, 공용 네트워크, 호스트 네트워크 등 네트워크 홉이 너무 많아서 지연 시간이 엄청나게 길어집니다.
요약하면, 내구 쓰기 이벤트 처리를 통해 Couchbase는 매우 빠른 쓰기 속도를 제공합니다. 내구성 쓰기는 호스팅 환경이 허용하거나 설정한 만큼 빠르게 수행됩니다.
카우치베이스 내구성 테스트
내구성 테스트는 Couchbase SDK로 이미 만든 애플리케이션을 사용하여 수행할 수 있지만, 테스트를 간소화하고 표준화하려면 당사 도구 중 하나가 도움이 될 수 있습니다.
Couchbase Server에는 다음과 같은 성능 측정 명령줄 도구가 포함되어 있습니다. cbc-pillowfight. Pillowfight는 수년 동안 Couchbase의 일부로 사용되어 왔기 때문에 성능 테스트에 매우 견고합니다. Pillowfight는 Couchbase C SDK를 기반으로 하므로 성능이 매우 뛰어납니다. 너무 빠르다고 할 정도로 매우 빠릅니다! "너무 빠르다"는 게 무슨 뜻일까요? 잠시 후에 설명해드리겠습니다.
설정 및 구성 정보는 다음에서 확인할 수 있습니다. 이 이전 블로그 를 통해 카우치베이스 테스트와 관련된 몇 가지 샘플 시나리오가 아래에 나와 있습니다.
베개 싸움을 사용한 성능 테스트 옵션
기본 필로우파이트 설정은 카우치베이스에서 사용할 애플리케이션 유형에 최적이 아닐 수 있습니다. 사용 사례에 더 적합하도록 필로우파이트 설정을 조정하는 방법은 여러 가지가 있습니다. 전체 옵션 목록을 보려면 다음과 같이 입력하세요. cbc-pillowfight -help 를 명령줄에 입력합니다.
다음은 시도해 볼 만한 몇 가지 주목할 만한 옵션입니다:
- -I 또는 -num-items 를 숫자와 함께 사용하여 작업할 문서 수를 지정할 수 있습니다.
- -json 를 사용하여 문서에서 JSON 페이로드를 사용할 수 있습니다. 기본적으로 문서는 비 JSON 페이로드를 사용하지만, 베개 싸움이 실행되는 동안 성능의 다른 측면을 테스트하기 위해 실제 JSON 문서가 필요할 수 있습니다.
- -e 를 설정하여 일정 기간 후에 문서를 만료할 수 있습니다. Couchbase를 캐시 또는 단기 저장소로 사용하는 경우 이 설정을 사용하여 문서 만료의 영향을 모니터링할 수 있습니다.
- -subdoc 를 사용하여 하위 문서 API를 사용하세요. 모든 작업이 전체 문서에 있어야 하는 것은 아닙니다.
- -M 또는 -최대 크기 을 클릭해 문서 크기에 상한선을 설정합니다. 이를 조정하여 시스템에 보다 현실적인 문서 크기를 맞출 수 있습니다. 해당 -m 및 -min-size도 있습니다.
다음은 위의 옵션을 사용한 또 다른 예입니다:
cbc-pillowfight.exe -U couchbase://localhost/pillow -u Administrator -P password -I 10000 -json -e 10 -subdoc -M 1024
이렇게 하면 10초 후에 만료되고 하위 문서 API를 사용하며 최대 문서 크기가 1024바이트인 10000개의 JSON 문서를 사용하여 필로우 파이트가 시작됩니다.
참고: 다음과 같은 -t -num-threads 옵션이 필요합니다. 현재 저처럼 Windows를 사용하는 경우에는 단일 스레드로 제한됩니다( 이 코드).
특히 내구성 쓰기 성능 테스트와 같은 특정 작업에 맞게 Pillowfight를 조정할 수 있습니다.
이 베개 싸움 명령을 검토해 보겠습니다:
cbc-pillowfight -U / -u -P -I 2000 -set-pct=100 -min-size=100 -최대 크기=250 -t 10 -durability majority_and_persist_to_active -no-population
이 명령은 무엇을 하나요?
-I 2000 는 항목 수, 2000입니다.
-set-pct=100 i의 100% 작업은 쓰기입니다. 50으로 설정하면 50/50은 읽기에 대한 쓰기입니다.
-min-size=100 는 최소 100바이트의 문서 크기입니다.
-최대 크기=250 는 최대 250바이트의 문서 크기입니다. 필로우파이트는 100바이트에서 250바이트 사이의 문서를 무작위로 선택합니다.
-t 10 는 10 스레드
-내구성 다수_및_지속_유지_투_액티브 는 내구성 설정입니다.. 두 개 이상의 복제본이 있는 경우 SDK는 대부분의 복제본에 쓰고 디스크의 활성 복사본이 지속될 때까지 기다립니다.
-인구 없음 설정은 쓰기를 커밋한 다음 삭제합니다.
스레드/버퍼 관리
이 명령은 문서를 계속 생성하고 가능한 한 빨리 Couchbase에 기록합니다. Pillowfight는 키 목록을 배열로 생성하고 재귀적으로 작성합니다. 끝에 도달하면 배열의 맨 위로 돌아가서 동일한 키를 다시 쓰기 시작합니다.
앞서 제가 "너무 빠르다"고 말한 것을 기억하시나요? 내구성을 테스트할 때, 특히 느린 네트워크와 대용량 스토리지(EBS S3)가 있는 느린 호스팅 환경에서는 필로우파이트가 인프라보다 훨씬 빠릅니다. 즉, 다른 스레드가 다음 쓰기를 기다리는 동안에도 필로우파이트 스레드가 완료되기를 기다릴 수 있습니다.
진정한 내구성을 테스트하는 테스트를 만들려면 어떻게 해야 할까요? 키의 버퍼를 크게 만들고 맨 위로 돌아가지 않도록 하세요.
cbc-pillowfight -U / -u -P -I 2000000 -set-pct=100 -min-size=100 -최대 크기=250 -t 10 -durability majority_and_persist_to_active -batch-size 1 -no-population
이 명령의 차이점은 무엇인가요? 위의 명령은 2백만 개의 키 목록을 만들고 이를 한 번만 통과합니다. 이렇게 하면 한 스레드가 동일한 문서를 완료하기 위해 이전 스레드의 쓰기를 기다리지 않아도 됩니다. 이것은 Couchbase와 호스팅 환경의 내구성 있는 쓰기 기능을 실제로 테스트하는 것입니다. 제거할 수 있습니다. 배치 크기를 사용하면 쓰기 대기 중인 스레드가 없을 가능성이 높습니다.
테스트에서 필로우 파이트가 사용되지 않더라도 문서 버퍼가 재귀적으로 사용되는 경우 스레드에서 한 쓰기가 다른 쓰기가 완료될 때까지 기다릴 가능성이 있다는 점을 애플리케이션 및 테스트 기준에서 인지해야 합니다.
결론
카우치베이스는 고성능 쓰기가 가능하지만 각 사용 사례와 조건은 테스트에 따라 다릅니다. 내구성 있는 쓰기 테스트를 위해서는 올바른 테스트 환경을 설정하는 것이 중요합니다.
Pillowfight는 읽기 대 쓰기 비율 설정, 스레딩, 문서 크기, 내구성 수준 등 이미 내장된 많은 기능을 통해 Couchbase를 테스트할 수 있는 훌륭한 도구입니다.
테스트 애플리케이션을 생성하는 경우 데이터베이스와 인프라를 실제로 테스트하는 테스트를 수행하는 것이 중요합니다. 결과는 데이터베이스뿐만 아니라 테스트가 수행된 환경에 따라 달라질 수 있습니다.
궁금한 점이 있으면 다음 주소로 문의하세요. james.powenski@couchbase.com 기꺼이 도와드리겠습니다.