노드 수는 몇 개인가요? 4부: 사이징 모니터링

이번 포스팅은 크기 조정에 관한 이 시리즈의 마지막 글입니다. 이전 글에서 저는 Couchbase Server 클러스터의 크기를 조정할 때 고려해야 할 사항에 대한 개요입니다, a 다양한 기능/버전이 이 크기 조정에 어떤 영향을 미치는지 자세히 살펴보세요. 를 제공하고 특정 하드웨어 고려 사항 및 권장 사항.

이 마지막 글에서는 실행 중인 Couchbase Server 클러스터의 크기 조정 요구 사항을 이해하는 데 사용해야 하는 다양한 메트릭에 대해 설명하겠습니다. 또한 적절한 경우 임계값과 알림에 대한 지침도 제공하려고 합니다. 커피 좀 드세요, 길어질 테니...

처음 세 개의 포스팅을 통해 초기 사이징을 이해하고 프로덕션 환경으로 이동한 후에는 클러스터를 계속 모니터링하고 모니터링과 관련된 사이징을 변경하는 것이 매우 중요합니다. Couchbase Server의 널리 인정받는 장점 중 하나는 애플리케이션을 중단하지 않고 업그레이드 및 확장할 수 있다는 점이며, 이는 전체 고객 기반에서 많이 사용되고 있습니다.

간단히 요약하자면, 처음에 크기 조정에 사용한 5가지 주요 요소는 앞으로 모니터링할 5가지 요소와 동일합니다:

• RAM
• 디스크(IO 및 공간)
• CPU
• 네트워크
• 데이터 배포

많은 메트릭은 Couchbase 자체에서 직접 제공되며 소프트웨어와만 관련이 있습니다. 그러나 Couchbase 외부의 관점에서 시스템을 광범위하게 모니터링하는 것도 중요합니다(처음 4개의 경우). 또한 많은 메트릭이 전체 클러스터(버킷 단위)에 걸쳐 집계되고 일반적으로 사람이 가장 쉽게 사용할 수 있는 방법이지만, 모든 것이 노드/버킷 단위로 일어나므로 단일 노드 단위로 모니터링하는 것이 중요하다는 점을 염두에 두세요. 이 모든 것을 중앙 집중식 모니터링 시스템으로 통합하는 것이 가장 좋은 방법입니다.

추적 및 임계값

애플리케이션마다 조금씩 다르므로 이러한 통계의 값과 동작도 다를 수 있습니다. 어떤 통계가 애플리케이션에 중요한지, 어느 수준까지 신경을 써야 하는지는 관리자의 몫입니다.

또한 각 노드는 기본적으로 모든 메트릭에서 동일한 값(+/-)을 가져야 하며, 한 노드가 너무 많이 차이가 나면 경고를 생성할 수 있습니다.

대부분의 경우 임계값을 설정하는 것도 중요하지만, 임계점에 도달하기 전에 크기 변경에 대비할 수 있도록 시간 경과에 따라 이러한 지표를 추적하는 것이 더 합리적일 때가 많습니다. 또한 이를 통해 예상되는 상황에 대한 정확한 기준선을 수집할 수 있습니다.

아래의 각 통계에 대해 다양한 애플리케이션 클래스에 적합한 수준 및/또는 임계값을 제시하려고 노력했습니다. 귀하의 애플리케이션과 관련된 질문이 있으시면 언제든지 카우치베이스에서 쌓아온 수백 년의 경험을 활용하시기 바랍니다.

변화에 대응하기

아래에서 각 영역에 대해 "이렇게 하라"는 구체적인 실행 항목을 제시하지 않는 것을 볼 수 있습니다. 저는 각 값이 의미하는 바를 이해한 다음 모든 것을 조합하여 변경이 필요한지 여부를 결정하는 것이 더 중요하다는 접근 방식을 취합니다. 아래 값 중 하나라도 애플리케이션에 허용되는 범위 내에 있지 않다면 크기 조정 계산을 다시 살펴보고 그에 따라 조정하는 것이 중요합니다. 더 많은 리소스가 필요한 거의 모든 상황에서는 노드를 하나 이상 추가하는 것이 정답입니다.

요약

먼저 Couchbase의 모니터링 그래프 중 '요약' 섹션을 살펴보겠습니다:

이 통계 세트는 일반적으로 Couchbase를 모니터링하고 규모를 조정할 때 가장 먼저 참조해야 합니다. 여러 영역에 걸쳐 높은 수준의 보기를 제공하도록 설계되었으며 이 논의의 뒷부분에서 이러한 메트릭 중 상당수를 사용할 것입니다. 여기서 직접 다루지 않은 몇 가지 통계를 가져오는 것을 볼 수 있지만 다음과 같은 시작점을 찾고 있다면 시작하기에 좋은 곳입니다. 자체 시스템으로 메트릭 가져오기.

각 사이징 요소의 중요도와 모니터링해야 하는 지표의 수 사이에 비례하는 관계를 확인할 수 있습니다.

RAM

이 시점에서 의심할 여지 없이 인지하고 계시겠지만, RAM은 일반적으로 Couchbase의 크기 조정과 관련된 가장 중요한 요소 중 하나이며 워크로드, 데이터 세트 크기 또는 기타 요인에 따라 가장 큰 폭으로 변할 수 있는 요소이기도 합니다.

Couchbase 내에서 메모리 사용량을 살펴보는 몇 가지 방법이 있으며, 많은 부분이 서로 연관되어 있습니다:

• "항목"는 특정 버킷에 있는 활성 문서의 수입니다(복제본 제외). 이는 사용 중인 메모리의 양을 간접적으로 나타내며, 크기 조정 계산에 사용하는 주요 값 중 하나입니다. 하지만 지속적으로 모니터링하는 것이 항상 가장 유용한 것은 아닙니다.
• "사용된 메모리": 이것은 의 메모리 사용량 메트릭으로, 소프트웨어가 사용 중이라고 생각하는 메모리의 양을 설명합니다. 이 값은 이젝션 및 OOM 메시지를 제어하는 데 사용됩니다. (엔지니어가 이를 "mem_used"...동일합니다)
  • "하이 워터 마크"와 매우 밀접한 관련이 있습니다.사용된 메모리'로 설정하고 그래프에서 함께 추적할 수 있습니다. 이 값은 노드가 데이터를 내보내기 시작하는 시점을 알려줍니다.
  • 당신은 항상 "사용된 메모리"를 "하이 워터 마크". 일부 애플리케이션은 약간 넘어갔다가 데이터가 배출되면서 다시 내려올 것으로 예상할 수 있고, 다른 애플리케이션은 절대로 "하이 워터 마크".  
  • 또한 이 값을 운영 체제 내 '멤캐시드' 프로세스에서 사용하는 실제 RAM 양과 비교하여 모니터링하는 것도 중요합니다. 이 두 값이 서로 다른 경우가 몇 가지 있으므로 이를 주시하는 것이 중요합니다. 10% 이상의 차이는 어떤 조치를 취하기 전에 일부 시스템에서는 더 높은 비율을 허용할 수도 있지만, 어느 정도 조사가 필요합니다.
• 작업 세트:
  • "캐시 미스 비율": 이 값은 RAM이 아닌 디스크에서 제공되는 읽기 횟수의 백분율입니다. 값이 0이면 모든 읽기가 RAM에서 제공되고, 이보다 높으면 일부 읽기가 디스크에서 제공됨을 나타냅니다.
    • 모든 것이 RAM에서 제공되기를 기대하는 애플리케이션의 경우 이 값은 항상 0이어야 합니다.
    • 이 값이 0이 아닐 것으로 예상하는 애플리케이션의 경우 가능한 한 낮게 설정하는 것이 이상적이며, 대부분의 배포는 1% 미만이지만 일부에서는 10% 이상을 허용합니다. SSD와 스피닝 디스크는 합리적인 값에 큰 영향을 미칩니다.
  • "활성 문서 상주 %": 현재 RAM에 캐시된 항목의 백분율입니다. 100%는 모든 항목이 RAM에 캐시되어 있음을 의미하며, 이보다 작으면 일부 항목이 꺼졌음을 나타냅니다.  
    • 일부 애플리케이션에서는 이 값이 항상 100%로 설정되어 있으며, 이 값이 아래로 내려가면 경고합니다.  
    • 다른 애플리케이션에서는 100%보다 낮을 것으로 예상하지만 실제 값은 사용자가 결정할 수 있습니다. 일반적으로 애플리케이션에 매우 적합한 경우가 아니라면 30% 이하로 설정하지 않는 것이 좋습니다.
• "활성 문서 상주 %"는 100%보다 훨씬 작을 수 있으며, "캐시 미스 비율'는 애플리케이션의 작업 세트에 따라 여전히 허용 범위 내에 있을 수 있습니다.
• "초당 임시 OOM."메모리 사용량"은 노드/버킷 내에서 "메모리 부족" 상황으로 인해 실패한 쓰기 작업의 수를 측정한 값입니다. "메모리 사용량"이 전체 버킷 할당량의 90%에 도달하는 경우에만 발생합니다.  
  • 명시적으로 예상하지 않는 한, 여기서 0이 아닌 것은 매우 나쁜 것으로 간주해야 합니다. 그러나 이러한 상황은 "사용된 메모리'를 입력합니다.

Couchbase 특정 지표 외에도 모니터링해야 할 지표가 있습니다:

• 노드에서 사용 가능한 전체 RAM 용량입니다. Linux에는 실제로 "무료"를 표현하는 몇 가지 재미있는 방법이 있다는 점을 기억하세요.
  • 1~2GB 이하로 내려가면 알림을 받습니다.
• 스왑 사용량. Linux는 정상적인 조건에서 약간의 스왑을 사용할 것으로 예상되지만, 과도한 스왑 사용량 또는 과도한 스왑('vmstat' 출력 확인)은 우려할 만한 원인으로 간주됩니다.
• beam.smp 프로세스(Windows의 경우 erl.exe)의 메모리 사용량입니다. 이전 버전에서는 이 프로세스에서 잠재적으로 과도한 증가가 발생할 수 있었습니다. 이러한 문제는 2.5 버전에서 수정되었지만 여전히 계속 주시하는 것이 좋습니다.
  • 4.5GB를 초과하는 용량은 부적절합니다.

디스크

IO와 공간으로 나눈 전체 디스크 리소스 크기 또한 매우 중요합니다. 워크로드의 성격에 따라 때로는 RAM보다 더 중요할 수도 있습니다.

먼저 IO를 살펴보면 추적할 가치가 있는 몇 가지 지표가 있습니다:

• "디스크 쓰기 대기열": 이것은 의 메트릭을 사용하여 노드에 충분한 디스크 IO가 있는지 파악할 수 있습니다. 데이터 쓰기, 압축, 보기, XDCR, 로컬 백업 등 디스크 IO를 놓고 경합하는 프로세스는 많지만, 저희는 "디스크 쓰기 대기열'를 일반 미터로 사용하면 IO가 부족하면 원인에 관계없이 디스크에 항목이 느리게 쓰여지므로 해결해야 합니다.
  • 노드당 버킷당 항목 수가 100만 개에 가까워지면 우려해야 하지만, 많은 애플리케이션은 워크로드에 비해 이보다 훨씬 낮을 것으로 예상합니다. 리밸런싱 중에는 이 수치가 더 높아질 것으로 예상해야 합니다.
  • 이 지표는 대부분의 경우 오르락내리락하기 때문에 추세적인 관점에서도 중요합니다. 많은 애플리케이션이 워크로드가 최고조에 달할 때 이 수치가 급증하지만(여전히 100만 미만이어야 함), 부하가 낮은 기간에는 이 수치가 감소하는 것이 중요합니다. 시간이 지남에 따라 지속적으로 증가하는 대기열은 전체적으로 디스크 IO가 충분하지 않다는 것을 나타냅니다.
• "초당 디스크 생성 수", "초당 디스크 업데이트 수", "초당 디스크 읽기 횟수": 이는 모두 읽기/쓰기 속도를 나타내며 향후 크기 조정 계산에 사용할 수 있습니다.

공간을 위해:

• "문서 총 디스크 크기" 및 "총 디스크 크기 보기": 이는 데이터 디렉터리와 뷰 디렉터리에서 사용 중인 디스크 공간의 양을 측정합니다(모범 사례에 따라 별도의 파티션에 있어야 함). 이것은 "디스크 데이터 크기" 또는 "뷰 데이터 크기"를 사용하여 해당 파일 내의 활성 카우치베이스 데이터의 양을 측정합니다. 이 두 가지의 차이로 인해 "문서 조각화 %" 및 "뷰 조각화 %'를 입력하면 잠재적으로 압축이 트리거됩니다.
  • 데이터 저장뿐만 아니라 파일 형식의 추가 전용 특성, 압축 수행, 백업 등을 위해 사용 가능한 디스크 공간을 충분히 확보하는 것이 매우 중요합니다. 적절한 경고 수준은 약 75%의 디스크 사용량이며, 90%에서 심각 경고가 표시됩니다.

Couchbase 외부에서는 운영 체제가 디스크 공간('df')뿐만 아니라 디스크 사용률('iostat')도 모니터링합니다.

CPU

이전 포스팅에서 보셨듯이, CPU는 Couchbase 사이징에서 매우 중요한 영역이 아닙니다. 그렇긴 하지만, 노드의 전체 CPU 사용량과 멤캐시드 그리고 beam.smp/erl.exe 프로세스.

CPU 사용량의 또 다른 중요한 측면은 여러 코어에 걸친 분포입니다. 반드시 크기 조정과 관련이 있는 것은 아니지만 CPU 사용량의 불균형은 어느 정도 조사가 필요할 수 있습니다.

네트워크

네트워크 대역폭과 지연 시간은 시스템의 전반적인 성능에 큰 영향을 미치기는 하지만, 예상 수준에서 벗어나 문제를 일으키는 경우는 매우 드뭅니다.

건강한 네트워크를 보장하기 위해 Couchbase 내에서 사용하는 주요 값은 노드 간 복제 대기열과 관련이 있습니다. 위의 "요약"에는 나와 있지 않지만, 이것은 "TAP 대기열"로 통칭되며 "항목"탭 메뉴" 섹션에서 '탭 메뉴'를 클릭합니다:

이 값은 거의 항상 0이며 0보다 조금 높더라도 걱정할 필요는 없습니다. 이 값이 노드당 200을 초과하는 경우, 특히 계속 증가하는 경우에는 네트워크 문제 또는 클러스터 내의 다른 문제로 인해 복제 속도가 느려지고 있음을 나타낼 수 있습니다.

카우치베이스 외부에서는 카우치베이스 노드 간, 그리고 해당 노드와 애플리케이션 서버 간의 네트워크 대역폭 사용량도 전반적으로 주시해야 합니다. 또한 잠재적으로 중요한 것은 여러 가지 다양한 네트워크 포트, 대부분 클라이언트-서버 간 통신의 관점에서 접근합니다.

데이터 배포

목록의 맨 아래에는 크기 조정과 관련하여 모니터링할 항목이 많지 않습니다. 또한 개별 노드가 아닌 전체 클러스터를 살펴보는 것이 합리적일 수 있는 유일한 요소이기도 합니다.

UI의 "vbucket 리소스" 섹션을 살펴보면 다음과 같습니다:

이 버킷에 대해 얼마나 많은 활성 상태와 얼마나 많은 복제본 "vBuckets"이 있는지 확인할 수 있습니다. "활성 vBuckets"는 항상 1024여야 하며 "복제 vBuckets"는 항상 1024*(복제본 수)여야 합니다. 그렇지 않다면 사용할 수 없거나 복제되지 않은 데이터가 있다는 뜻이므로 즉각적인 조치가 필요합니다. 이는 일반적으로 장애/장애 조치 후에 발생하며 정상으로 되돌리려면 리밸런싱이 필요합니다.

클러스터에 항상 3개 이상의 노드를 보유하는 것이 좋다는 광범위한 권장 사항도 여전히 유효합니다.

XDCR

카우치베이스와 함께 XDCR을 사용하는 경우 가장 주의 깊게 살펴봐야 할 메트릭은 XDCR 돌연변이 대기열입니다 - "아웃바운드 XDCR 돌연변이". 이것은 이 버킷의 대상 역할을 하는 버킷에 복제되기를 기다리는 항목의 수를 나타냅니다. 디스크 쓰기 대기열과 마찬가지로 이 대기열은 부하가 걸리면 커지거나 줄어들 것으로 예상되지만 시간이 지나면서 결국 0에 가까워지고 계속 커지지 않도록 하는 것이 중요합니다.

가상화/클라우드

위의 논의는 예외 없이 물리적 하드웨어, 가상 머신 및 클라우드 배포의 모든 환경에 동일하게 적용됩니다. 실제 값은 다를 수 있으며 임계값과 예상 기준선도 다를 수 있습니다.

가상화 및 클라우드 환경에서 이 퍼즐의 주요 추가 사항은 기본 시스템과 하이퍼바이저의 영향입니다. 이 시리즈의 이전 게시물에서 구체적인 배포 가이드라인을 제공했으므로 여기서는 다시 설명하지 않겠습니다. 모니터링 측면에서 보면, 기본 시스템에는 모두 동일한 '카우치베이스 외부'가 적용됩니다.

이 두 가지의 흥미로운 교차점은 다음과 같습니다. "훔친 시간".

결론

이 모든 것을 한곳에 모으기 위해 이 모든 메트릭을 한 곳에 모았습니다. 모두 사용자 환경에 적용될 수 있는 것은 아니지만, 모두 애플리케이션에 '적용될 수 있으며' 이해해야 합니다:

이 여정을 함께 해주셔서 감사드리며, 도움이 되었기를 바랍니다. 질문이나 우려 사항이 있거나 환경에 대한 구체적인 도움이 필요한 경우 주저하지 마시고 저나 Couchbase 팀에 직접 문의해 주세요.