카우치베이스 모니터링
Couchbase는 단일 클러스터 아키텍처의 분산형 고성능 캐시 및 NoSQL 데이터베이스입니다. 비슷한 이름과 공유된 유산에도 불구하고, Couchbase는 CouchDB나 다른 어떤 NoSQL 제품과는 매우 다른 제품입니다. 애플리케이션 메트릭과 함께 Couchbase 성능을 모니터링하고 프로파일링할 수 있는 것은 매우 중요합니다. 시간이 지남에 따라 모니터링은 모든 미션 크리티컬 시스템의 성공적인 배포를 위한 필수 요소입니다. 이는 일반적으로 그렇지만 특히 분산 컴퓨팅 환경에서는 더욱 중요합니다. 장기적인 성공을 보장하는 유일한 방법이기 때문입니다. 이 논의에서는 모니터링에 초점을 맞추고자 하지만, 애플리케이션 문제 해결을 용이하게 하기 위해 자세한 Couchbase 로깅을 제공한다는 점을 알아두는 것이 중요합니다. 이러한 로그는 '/opt/couchbase/var/lib/couchbase/logs'에 저장됩니다. 이러한 로그에 대한 자세한 내용은 Couchbase 비행 기록기(https://www.couchbase.com/blog/couchbase-server-recorder/).
Couchbase는 풍부한 정보를 제공하는 관리 콘솔을 제공하며, 콘솔에서 캡처한 모든 정보는 명령줄 유틸리티와 REST 인터페이스를 통해서도 사용할 수 있습니다. 따라서 필요한 통계를 제공할 뿐만 아니라 업무상 중요한 프로덕션 클러스터를 모니터링하기 위한 타사 도구를 지원합니다. 저희 클러스터는 과거 정보를 저장하는 동안 공간을 절약하기 위해 시간 경과에 따라 데이터를 집계하며, 타사 도구는 과거 정보를 보존하기 위해 정기적으로 폴링할 수 있습니다.
모범 사례 모니터링
이제 잡초 속으로 들어가 보겠습니다 ...
Couchbase를 효율적으로 모니터링하려면 두 가지 관점이 필요합니다. 클러스터 전체는 개별 노드 또는 서버로 구성됩니다. 각 노드는 클러스터 전체에 분산된 데이터베이스를 활용하는 모든 애플리케이션에 컴퓨팅 용량을 제공합니다. 따라서 노드당 리소스 소비량과 사용 가능한 컴퓨팅 용량을 모니터링하고자 합니다. 또한 특정 애플리케이션 내에서 캐시를 통해 제공되는 요청의 수를 파악하고 디스크가 데이터를 디스크에 신속하게 보존할 수 있는지 확인하고자 합니다. 아래 메트릭을 살펴볼 때 클러스터 동작은 애플리케이션의 요구 사항에 따라 달라진다는 점을 염두에 두어야 합니다. 우리의 목표는 인메모리 작업 집합을 관리하고 클러스터에 추가 노드가 필요함을 나타내는 조기 경고 이벤트를 포착하는 것입니다.
노드 모니터링
REST API(https://:8091/pools/default)를 활용하면 노드당 소비되는 컴퓨팅 리소스에 대한 인사이트를 얻을 수 있습니다.
- 노드 상태 - (클러스터 멤버십) nodeStatuses 엔드포인트에서 반환되는 JSON의 일부로 노드 상태는 클러스터 멤버십을 통해 반환됩니다. 이는 노드가 클러스터에 참여하고 있는지 확인하기 위해 노드별로 '활성'을 모니터링할 수 있는 기능을 제공합니다. 중요한 이벤트는 노드가 실패하여 관리자의 개입이 필요하다는 것을 나타내는 "inactiveFailed"로 정의됩니다.
- 시스템 통계(systemStats) - 엔드포인트에서 CPU(cpu_utilization), SWAP(swap_used) 및 여유 메모리(mem_free)에 대한 기본 용량 소비 통계를 제공함으로써 추가 정보를 얻을 수 있습니다. 클러스터의 각 노드에 대해 이러한 리소스 중 제약이 있는 경우 개별 노드를 해결하고 추가 노드가 필요한지 평가할 수 있습니다.
- 카우치베이스별(흥미로운 통계) - 마지막 섹션에서는 개별 노드에서 소비하는 리소스에 대한 추가 인사이트를 제공합니다. Couchbase에서 소비하는 개별 노드 디스크는 couch_docs_actual_disk_size로 정의되며, 노드 내에서 사용되는 물리적 메모리는 노드당 사용되는 메모리로 정의되고 백그라운드 가져오기 ep_bg_fetched(캐시에 없고 디스크에서 가져온 데이터) 횟수도 측정됩니다.
버킷 모니터링
REST API(https://:8091/pools/default/buckets/stats)를 활용하면 버킷 자체의 상태에 대한 인사이트를 얻을 수 있습니다. 각 개별 노드가 제공할 수 있는 추가 컴퓨팅 용량이 있더라도 특정 버킷이 제약을 받을 수 있습니다. 따라서 버킷 통계를 계속 주시하면 애플리케이션 상태에 대한 가장 많은 인사이트를 얻을 수 있습니다.
- 초당 작업 수(ops) - 특정 버킷에 대해 발생하는 총 가져오기, 설정, 증가 및 감소 횟수를 나타내는 기본적인 측정값입니다. 조회 수는 이 메트릭에 포함되지 않지만 애플리케이션당 부하를 매우 빠르게 측정할 수 있습니다. 요컨대, 모든 리소스가 클러스터에 할당될 수 있지만 로드를 생성하는 특정 애플리케이션에 대한 인사이트를 제공할 수 있습니다.
- 캐시 미스(ep_cache_miss_rate) - 이 메트릭은 문제가 될 수 있는 것과 그렇지 않은 것을 보여주는 좋은 예입니다. 기본적으로 이 메트릭은 디스크에서 가져와야 하는 것과 관련하여 캐시에서 발견된 요청된 개체의 비율을 계산합니다. 예를 들어, 10개의 요청이 데이터베이스에 들어왔고 1개의 요청을 디스크에서 검색해야 하는 경우 미스 비율은 10%가 됩니다. 진짜 문제는... 이것이 문제일까요? 이는 이 수치를 가능한 한 0에 가깝게 유지하는 클러스터에서 최상의 성능을 발휘하는 메모리에 무엇을 기대하는지에 따라 달라집니다.
- 조각화(couch_docs_fragmentation) - Couchbase는 디스크에 추가 전용 형식으로 저장하므로 클러스터 내에서 발생하는 조각화를 계속 주시해야 합니다. 이는 자동 압축이 예약 기반으로 설정된 경우 측정하는 데 특히 중요합니다. 이렇게 하면 일정이 데이터베이스를 건강하게 유지하기에 충분히 오래 그리고 충분히 자주 실행되고 있는지 파악할 수 있습니다.
- 워킹 세트(ep_bg_fetched 및 vb_active_resident_items_ratio) - 위에서 언급한 ep_cache_miss_ratio를 상주 항목 비율 및 메모리 헤드룸 메트릭과 함께 사용하여 버킷에 가장 많이 요청된 객체를 메모리에 저장할 수 있는 충분한 용량이 있는지 파악할 수 있습니다. 더 중요한 것은 클러스터의 메모리 용량을 확장하기 위해 추가 노드가 필요한지 예측할 수 있다는 점입니다.
- 디스크 드래인(ep_queue_size) - 애플리케이션의 작업과 관계없이 모니터링해야 할 가장 중요한 메트릭 중 하나는 드래인 속도입니다. 대기열에 대기 중인 변경 사항의 양을 주의 깊게 관찰하세요. 추가 정보는 아래 명령줄 유틸리티에서 확인할 수 있습니다. REST 관점에서 대기열 채우기(ep_diskqueue_fill)와 대기열이 얼마나 빨리 배수되는지(ep_diskqueue_drain)를 모두 모니터링하여 시간 경과에 따른 추세를 추적할 수 있습니다.
REST 인터페이스 내에서 다양한 추가 정보를 모니터링할 수 있습니다. 여기서는 API에서 사용할 수 있는 모든 것을 다루지는 않겠지만 주로 클러스터를 건강하게 유지하기 위한 주요 통계에 초점을 맞추겠습니다. REST 외에도 couchbase-cli 및 cbstats 유틸리티를 통해 스크립트 모니터링을 실행하여 클러스터의 각 노드 내에서 발생하는 작업을 캡처할 수도 있습니다.
명령줄
CBSTATS는 '/opt/couchbase/bin'에서 찾을 수 있으며 클러스터 내에서 발생하는 여러 가지 상황에 대한 인사이트를 제공합니다. 다음은 몇 가지 주요 메트릭과 이 메트릭이 알려주는 내용입니다:
- curr_connections 및 rejected_conns 통계를 통해 열린 연결과 거부된 연결의 수를 추적하여 이 노드에서 연결 요청이 거부되었는지 여부를 파악할 수 있습니다.
- 애플리케이션에서 개체를 요청했지만 캐시에서 찾을 수 없을 때마다 Couchbase는 디스크에서 해당 개체를 찾습니다. 이 캐시 미스에는 백그라운드 가져오기가 필요하며, 디스크에서 가져온 항목당 ep_bg_fetched로 측정됩니다. 100% 작업 세트를 관리하는 경우 이는 클러스터가 스트레스를 받고 있다는 신호일 수 있으며, 반대로 작업 세트가 더 작은 경우에는 문제가 되지 않을 수 있습니다. 어느 시나리오에서든 큰 증가는 조기 경고 신호를 제공하기 때문에 환경의 일반적인 상황을 파악하는 것이 중요합니다.
- 지속성을 위해 대기 중인 항목의 수는 애플리케이션을 따라잡을 수 있는 충분한 I/O 리소스가 있는지 파악하기 위해 모니터링해야 할 중요한 영역입니다. 애플리케이션은 항상 캐싱 계층을 통해 제공되지만, Couchbase의 가장 큰 장점 중 하나는 디스크에 지속성을 유지하여 데이터 내구성을 제공할 수 있다는 점입니다. 이 비동기 작업이 과부하가 걸리면 애플리케이션 성능에 영향을 미칠 수 있습니다. 따라서 특히 쓰기량이 많은 시스템에서는 ep_queue_size와 ep_flusher_todo를 계속 주시해야 합니다. 특히 시간이 지남에 따라 증가하는 추세인 경우 100만 개에 도달하지 않기를 바라며, 50만~80만 개 정도에서 경고를 표시하는 것이 좋습니다.
- vb_num_eject_replicas 통계를 보면 Couchbase가 메모리에서 복제본 값을 꺼낸 횟수를 알 수 있습니다. 이는 특정 버킷이 저수위에 도달했음을 나타냅니다. 단순히 이 임계값에 도달하는 것은 클러스터가 단순히 메모리 리소스를 확보하는 것이므로 문제가 되지 않을 수 있지만, 이러한 동작이 지속적으로 발생하거나 증가 추세를 보인다면 문제가 될 수 있습니다. 더 중요한 것은 프로덕션 클러스터에서 절대 보고 싶지 않은 메모리 부족(ep_oom_errors/ep_tmp_oom_errors) 시나리오를 방지할 수 있는 방법입니다.
- 카우치베이스는 설계상 노드를 시작할 때 '워밍업' 프로세스를 수행하여 오래된 캐시 시나리오를 방지합니다. 워밍업은 디스크에서 개체를 읽고 캐시를 미리 로드하는 프로세스입니다. 워밍업을 모니터링하면 Couchbase 노드가 얼마나 빨리 시작 프로세스를 완료하고 클러스터 내에서 로드를 지원할 수 있는지에 대한 가시성을 확보할 수 있습니다. ep_warmup_value_count가 vb_active_curr_items와 같으면 워밍업이 완료된 것이지만, ep_warmup_state를 통해 더 세분화된 정보를 얻을 수 있습니다. 아래는 7가지 워밍업 상태입니다. 노드는 '완료' 상태가 될 때까지 완료되지 않습니다.
- 초기 - 워밍업 프로세스를 시작합니다.
- 추정 데이터베이스 항목 수 - 데이터베이스 항목 수를 추정합니다.
- KeyDump - 문서가 아닌 키와 메타데이터를 RAM에 로드하기 시작합니다.
- CheckForAccessLog - 액세스 로그를 사용할 수 있는지 확인합니다. 이 로그는 자주 읽거나 쓴 키를 나타냅니다.
- LoadingAccessLog - 액세스 로그에서 정보를 로드합니다.
- 로딩 데이터 - 서버가 액세스 로그에 나열된 키에 대해 먼저 데이터를 로드하거나, 사용 가능한 로그가 없는 경우 '키 덤프' 단계에서 찾은 키를 기반으로 데이터를 로드합니다.
- 완료 - 서버가 읽기 및 쓰기 요청을 처리할 준비가 되었습니다.
- Couchbase는 NoSQL 지속성 엔진일 뿐만 아니라 캐시이기도 하므로 Couchbase 서버 ep_engine의 메모리 소비를 이해하고자 합니다. 이것은 mem_used로 모니터링할 수 있습니다.
- 위에서 다룬 cbstats 통계는 REST 인터페이스(https://:8091/pools/default/buckets//stats)를 통해서도 사용할 수 있다는 점에 주목할 필요가 있습니다.
- 운영, ep_cache_miss_rate, couch_docs_fragmentation, ep_queue_size, vb_active_resident_items_ratio, curr_connections, curr_items_tot, ep_bg_fetched, ep_diskqueue_drain, ep_diskqueue_fill, vb_replica_eject, ep_oom_errors, ep_queue_size, ep_tmp_oom_errors, mem_used 등을 제공합니다.
이 글의 목적은 카우치베이스 모니터링 전략을 개발할 때 어디서부터 시작해야 하는지에 대한 몇 가지 지침을 제공하기 위한 것입니다. 고객이 구현한 기본적인 모범 사례를 요약한 것입니다. 각 고객은 고유하며 애플리케이션에 따라 추가 메트릭이 필요할 수 있습니다.
