두 가지 방출 방식의 이야기: 값 전용 대 전체 방출

소개

본 글을 작성하는 데 엄청난 도움을 주시고 제 수많은 질문에 끝없는 인내심을 보여주신 Couchbase Server 엔지니어링 팀, 특히 데이브 리그비(Dave Rigby)와 짐 워커(Jim Walker)에게 감사의 말씀을 전합니다. 정말 감사합니다, 두 분의 해박한 지식과 이를 기꺼이 나누어 주려는 태도에 깊이 감사드립니다!

카우치베이스 서버(Couchbase Server)에서 데이터는 버킷(bucket)에 저장됩니다. 기본 버킷 타입 – 진부하게 명명된 카우치베이스 유형 – 디스크에 대한 비동기 데이터 영속성을 보장합니다. 서버는 사용자의 모든 데이터, 즉 활성 세트와 복제 세트(들)을 메모리에 모두 보관하려고 시도합니다. 그러나 메모리 내 데이터가 버킷 메모리 할당량의 85%에 도달하면(이 수준을 최고 수위), 서버는 메모리에서 최근에 사용되지 않은 문서 중 일부를 제거(에젝트)하기 시작합니다. 활성 문서는 40%의 확률로 제거되며, 복제본 문서는 60%의 확률로 제거됩니다.  그 이유는 다음과 같습니다. 활성 문서를 메모리에 상주시키는 것이 더 중요하지만, 노드 장애 발생 시 복제본 문서가 활성 문서로 전환되어야 할 경우를 대비하여 일부 복제본 문서도 메모리에 남겨두어야 합니다.  제거 프로세스는 메모리 내 데이터가 버킷 메모리 할당량의 75% 미만으로 줄어들 때까지 계속됩니다(이 수준을 최저 수위).

Couchbase에 저장된 문서의 구조에 대한 간단한 알림입니다.

• 문서 열쇠 또는 아이디: 가변 길이 – 최대 250바이트, 동일한 버킷 내에 저장되는 문서 간에 고유해야 함
• 문서 메타데이터: 고정 길이 – Couchase 버킷 유형에 저장된 문서의 경우 56바이트, Ephemeral 버킷 유형에 저장된 문서의 경우 72바이트(이 버킷 유형은 이 문서의 범위를 벗어남)
• 문서 가치: 가변 길이 – 최대 20MB, 주로 JSON, 다른 형식도 사용 가능

두 가지 배출 방법

기본적으로 Couchbase 버킷은 값만 해당 배제(또는 축출) 방식. 많은 버전 전에는 이것이 유일하게 사용 가능한 옵션이었습니다. 이름에서 알 수 있듯이, 배제 프로세스는 값만 제거합니다 문서들과 문서 키와 메타데이터를 항상 메모리에 유지할 것입니다..

버전 3.0부터 (카우치베이스 서버 이 글을 작성하는 시점에 버전 6.5.1에 도달해 있으며, 저희는 추가했습니다 가득 찬 배출 방식. 전체 축출을 위해 구성된 버킷이라고 쉽게 추측할 수 있다 문서의 키, 메타데이터 및 값을 제거합니다 사출 과정의 일환으로.

상이트오프: 성능 대 메모리 크기

그렇다면, 버킷으로 어떤 옵션을 선택해야 할까요? 최신 Couchbase 서버 버전의 GUI에 있는 툴팁에서는 다음과 같이 설명합니다:

• 가치 방출 배출 중에는 값만 배출됩니다(키와 메타데이터는 메모리에 유지됩니다).
• 전체 배출 배출 중에는 (키, 메타데이터, 값을 포함하여) 모든 것이 배출됩니다.
  값 방출은 더 많은 시스템 메모리가 필요하지만 최고의 성능을 제공합니다. 전체 방출은 메모리 오버헤드 요구 사항을 줄여줍니다.

더 정확히 말하자면, 어느 쪽도 아님 메서드“시스템 메모리가 더 필요합니다“ 가득 찬 추출(배출)을 통해 데이터셋이 메모리를 크게 초과할 수 있는 반면, 가치 배출 기능은 키와 메타데이터를 메모리에 유지해야 하므로, 데이터셋이 메모리보다 어느 정도 더 커지는 것을 허용합니다.

만약 일관된 읽기 지연 시간 Couchbase Server의 데이터와 작동하는 애플리케이션 중 (매우) 중요한 것이 있다면, 값 배출(value ejection)을 고수해야 합니다. 또한 이를 위해서는 클러스터 규모 산정하기 제대로, 할당하다 충분한 메모리 할당량 버킷을 구현하다 문서 보관 정책(정기적으로 오래된 문서 보관 또는 삭제) 및 메모리 사용량 모니터링.

이내에 머무는 경우 예산 또는 기존 기술의 한계 (매우) 중요하다면, 대용량 버킷에 대해 전체 퇴거(full eviction)를 고려해야 합니다. 온프레미스 하드웨어 자원이 한계에 달해 Couchbase 노드에 램을 더 이상 추가할 방법이 없는 경우가 이에 해당할 수 있습니다. 온프레미스나 클라우드 기술 지출 비용이 부족할 때, 이러한 성능 절감 타협안이 해결책이 될 수 있습니다.

전체 배출을 고려해야 하는 또 다른 이유는 데이터셋이 다음과 같을 것으로 예상될 때입니다. 큰, 그렇게 하여 초과하다 합리적인 메모리 구성. 얼마나 큰가요 큰수십억 건의 문서, 수십 테라바이트에 달하는 데이터 말입니다. 저희 솔루션 엔지니어와 솔루션 아키텍트는 언제나 여러분을 도울 준비가 되어 있습니다. 카우치베이스 클러스터 규모 산정하기 제발 우리에게 말을 해 주세요.

배출 방식을 다른 방식으로 변경하는 것은 가능하지만, 이는 버킷 재시작이 필요한 몇 안 되는 작업 중 하나이므로 약간의 가동 중지 시간이 발생합니다. 실제로 배출 방식을 변경하려고 하면 UI에 다음과 같은 빨간색 경고 문구가 표시됩니다. 축소 정책을 변경하면 버킷이 재시작됩니다. 이로 인해 모든 열린 연결이 종료되고 약간의 가동 중지 시간이 발생합니다..따라서 버킷을 프로덕션에 배포하기 전에 배출 방식을 결정하는 것이 현명합니다.

성능 차이가 나는 이유는 무엇인가요?

버킷 배출 방식과 데이터 레지던시의 다양한 시나리오를 살펴보겠습니다. 이는 성능이 어떻게 영향을 받는지 이해하는 데 도움이 될 것입니다.

1. 완전한 데이터 레지던시

데이터가 완전히 상주 상태(즉, 버킷 메모리 할당량인 ~85% 내에 모두 들어맞는 경우)일 때, ‘값만 저장(value-only)’ 버킷과 ‘전체 제거(full ejection)’ 버킷의 성능은 비슷해야 합니다. 문서 작업은 아래와 같이 수행됩니다:

• key = profile::john-doe::123인 문서를 가져오기(읽기)
  • 빠른이 키가 메모리에 존재하는지 확인합니다.
    • 빠른그렇다면 메모리에서 문서를 반환하세요.
    • 빠른: 그렇지 않으면, “문서가 존재하지 않습니다” 오류를 반환합니다.
• key가 profile::john-doe::123인 문서를 삽입하세요.
  • 빠른이 키가 메모리에 존재하는지 확인합니다.
    • 빠른그렇다면 “문서가 이미 존재합니다” 오류를 반환합니다.
    • 빠른그렇지 않다면, 문서를 메모리에 기록하세요. 그런 다음 비동기적으로 지속화하고 복제하세요.
• key = = profile::john-doe::123인 문서를 교체하세요
  • 빠른이 키가 메모리에 존재하는지 확인합니다.
    • 빠른그렇다면 변경 사항을 메모리에 저장합니다. 그런 다음 비동기적으로 이를 지속시키고 복제합니다.
    • 빠른: 그렇지 않으면, “문서가 존재하지 않습니다” 오류를 반환합니다.

2. 부분 데이터 상주, 값 전용 배출

다음 조건을 충족하는 버킷의 데이터 상주성이 100% 미만일 때 값 전용 방출 시, 카우치베이스 서버는 이를 알고 있습니다. 문서 키와 메타데이터가 여전히 메모리에 있습니다.. 따라서 문서 작업은 다음과 같습니다:

• key = profile::john-doe::123인 문서를 가져오기(읽기)
  • 빠른이 키가 메모리에 존재하는지 확인합니다.
    • 빠른: 그렇다면 문서 값이 메모리에 있는지 확인하세요
      • 빠른그렇다면 메모리에서 문서를 반환하세요.
      • 느림그렇지 않으면, 문서를 디스크에서 메모리로 읽어들여 반환합니다.
    • 빠른: 그렇지 않으면, “문서가 존재하지 않습니다” 오류를 반환합니다.
• key가 profile::john-doe::123인 문서를 삽입하세요.
  • 빠른이 키가 메모리에 존재하는지 확인합니다.
    • 빠른그렇다면 “문서가 이미 존재합니다” 오류를 반환합니다.
    • 빠른그렇지 않다면, 문서를 메모리에 기록하세요. 그런 다음 비동기적으로 지속화하고 복제하세요.
• key = = profile::john-doe::123인 문서를 교체하세요
  • 빠른이 키가 메모리에 존재하는지 확인합니다.
    • 빠른그렇다면 변경 사항을 메모리에 저장합니다. 그런 다음 비동기적으로 이를 지속시키고 복제합니다.
    • 빠른: 그렇지 않으면, “문서가 존재하지 않습니다” 오류를 반환합니다.

3. 부분 데이터 상주, 완전한 배출

다음 조건을 충족하는 버킷의 데이터 상주성이 100% 미만일 때 가득 찬 축출, 카우치베이스 서버 의존할 수 없다 문서 키와 메타데이터가 메모리에 존재할지 여부에 대해, 이들이 퇴출(evicted)되었을 수 있기 때문입니다. 따라서 문서 작업은 다음과 같은 형태를 띨 것입니다:

• key = profile::john-doe::123인 문서를 가져오기(읽기)
  • 빠른이 키가 메모리에 존재하는지 확인합니다.
    • 빠른: 그렇다면 문서 값이 메모리에 있는지 확인하세요
      • 빠른그렇다면 메모리에서 문서를 반환하세요.
      • 느림그렇지 않다면 디스크를 확인하세요.
        • 느림문서가 디스크에서 발견되면, 디스크에서 메모리로 문서를 읽어와 반환합니다.
        • 느림: 그렇지 않으면, “문서가 존재하지 않습니다” 오류를 반환합니다.
• key가 profile::john-doe::123인 문서를 삽입하세요.
  • 빠른이 키가 메모리에 존재하는지 확인합니다.
    • 빠른그렇다면 “문서가 이미 존재합니다” 오류를 반환합니다.
    • 느림그렇지 않다면 디스크를 확인하세요.
      • 느림그렇지 않다면, 문서를 메모리에 기록하세요. 그런 다음 비동기적으로 지속화하고 복제하세요.
      • 느림그렇다면 “문서가 이미 존재합니다” 오류를 반환합니다.
• key = = profile::john-doe::123인 문서를 교체하세요
  • 빠른이 키가 메모리에 존재하는지 확인합니다.
    • 빠른그렇다면 변경 사항을 메모리에 저장합니다. 그런 다음 비동기적으로 이를 지속시키고 복제합니다.
    • 느림그렇지 않다면 디스크를 확인하세요.
      • 느림: 그렇지 않으면, “문서가 존재하지 않습니다” 오류를 반환합니다.
      • 느림그렇다면 문서를 메모리에 작성하십시오. 그런 다음 비동기적으로 지속화하고 복제하십시오.

100% 메모리에 상주하지 않는 가득 찬 퇴거 버킷의 경우, 많은 존재한다 작업은 디스크로 가야 합니다. 완전 퇴거 버킷의 경우 백그라운드 페치 수(디스크에서 메모리로 문서를 읽는 작업으로, “캐시 미스”라고도 함)도 더 높을 가능성이 높습니다.

성능을 향상시키는 방법이 있나요?

게다가 삽입 그리고 바꾸다 작업, Couchbase SDK 지원 업서트. 업서트 작업은 문서를 삽입하거나(존재하지 않는 경우) 기존 문서를 대체합니다. Couchbase Server에서 데이터 변경 사항을 처리하는 추가 전용(append-only) 특성으로 인해, 그 업서트 작업 요구하지 않음 해당하는 존재한다 작업.  따라서, 그 사용은 업서트 ~ 대신에 삽입물 그리고 대체합니다 사용 사례가 이러한 대체 기능을 허용한다는 전제하에, 귀하의 애플리케이션 성능을 향상시킬 것입니다.

전용 고속 디스크는 전체 퇴출(full ejection) 버킷의 성능도 향상시킬 것입니다. 이는 가상화된 스토리지보다 노드당 전용 디스크를 사용하는 Couchbase 노드의 권장 구성 중 하나입니다.

밸류 전용에서 전체 배출로 전환해야 하는 시기

다음 상황을 생각해 봅시다:

• 값 기반 배출이 구성된 버킷이 있습니다.
• 버킷의 크기가 커지면서 메모리에 상주하는 데이터의 양이 15-20% 미만으로 줄어들었는데, 이는 당사가 권장하는 최소 상주 비율입니다.
• 더 많은 데이터가 유입될 것으로 예상되며, 사용 사례 요구사항에 따라 이미 문서를 아카이브/삭제하고 있고, 버킷에 더 많은 RAM을 할당할 방법이 없습니다.

전체 배출 방식을 채택해야 합니까?

이 질문에 답하는 데 도움이 되는 좋은 측정 지표가 있습니다. 바로 동일한 버킷에 대해 RAM에 있는 사용자 데이터와 비교한 RAM 내 메타데이터의 양입니다. 여기서 “메타데이터”란 문서를 의미합니다. 키 + 메타데이터, 이 특정 경우에. 이 경우 “사용자 데이터”는 문서를 의미합니다. 가치.

이러한 지표는 다음 위치에서 찾을 수 있습니다. vBucket 리소스 UI의 해당 섹션. 아래 스크린샷에서 볼 수 있듯이, 메타데이터가 메모리 내 버킷 데이터의 약 42%를 차지하고 있습니다:

특정 시점에 UI 및 Couchbase 로그에서 다음과 같은 메시지가 나타날 수 있습니다:

문서 키와 메타데이터가 메모리 할당량의 대부분을 차지하고 있기 때문에, 문서 값을 유지할 수 있는 공간이 거의 없습니다. 이 경우, 사용 가능한 메모리가 너무 적기 때문에 서버가 디스크에서 메모리로 데이터를 로드하기 위해 백그라운드 조회를 빈번하게 수행하고, 이는 곧 다시 방출(제거)되는 현상을 목격하게 될 것입니다.

클러스터에 노드를 더 추가할 수 없거나 다른 버킷에서 메모리를 재할당할 수 없는 경우, 해당 버킷을 전체 퇴출(full ejection) 방식으로 전환하는 것이 좋습니다. 단, 버킷이 재시작되고 웜업(warmup) 과정을 거치는 동안 약간의 다운타임이 발생한다는 점을 유념하시기 바랍니다.

마무리

• 값만 해당 배출/축출(ejection/eviction)은 메모리에서 문서 값만 제거하는 반면, 가득 찬 퇴거는 문서 키와 메타데이터도 제거합니다.
• 너는 ~을 만들어야 한다 정보에 입각한 선택 버킷을 프로덕션에 투입하기 전에 방출 방법을 결정해야 합니다. 수백만 개의 문서가 있는 쓰기 집약적 사용 사례는 전체 방출의 좋은 후보입니다. 나중에 프로덕션에서 방출 방법을 변경하는 것은 약간의 가동 중지 시간으로 인해 비용이 많이 들 수 있습니다.
• 업데이트 및 삽입 작업과 전용 고속 디스크는 항상 애플리케이션 성능을 향상시키며, 전체 배출 버킷(full ejection bucket)의 경우 훨씬 더 중요합니다.
• 버킷 모니터링 metadata overhead.  It is a good indicator that your cluster may be in need of more RAM.  If you can’t get more memory to your Couchbase cluster, and your metadata overhead is at or higher than 40%, you may consider switching your large write-heavy buckets to full ejection.