모든 시스템 관리자의 결론은 데이터베이스를 유지하는 것이며, Couchbase의 경우에는 데이터베이스를 유지해야 합니다, 클러스터를 연중무휴로 가동 및 실행 유지. 앱 요구 사항이 까다롭기 때문에 클러스터를 적절하게 구성하고, 규모를 조정하고, 모니터링해야 합니다. 이는 사전 경고 없이 언제든 장애가 발생할 수 있기 때문에 상당히 어려울 수 있습니다. 운영자에게는 놀라움과 도전으로 가득한 매일이 다릅니다.
하지만 모든 카우치베이스 서버 운영자가 반드시 알아야 할 몇 가지 사항이 있습니다. 다음 10가지 사항이 도움이 되길 바라며, 여러분의 업무가 더 쉬워지길 바랍니다:
1. 클라이언트 라이브러리를 최신 상태로 유지
항상 서버와 호환되는 최신 버전의 클라이언트 라이브러리를 사용하세요. 최신 클라이언트 라이브러리를 사용하면 최근에 테스트된 코드와 클라이언트를 통해 제공되는 최신 기능 등 Couchbase 클러스터를 최대한 활용할 수 있습니다.
2. 모니터링, 모니터링, 모니터링
관리자 대시보드 또는 REST API를 사용하여 Couchbase 클러스터가 어떻게 작동하는지 모니터링할 수 있습니다. 캐시 적중률, 디스크 읽기, 상주 항목 비율 및 디스크 쓰기 대기열과 같은 시스템 메트릭을 모니터링하는 것이 좋습니다.
캐시 미스 비율 는 low. 즉, 문서 키가 메모리에 캐시되어 읽기 및 쓰기 속도가 빨라집니다.
상주 항목 비율 는 메모리에 있는 활성 문서의 총 개수를 보여줍니다. 일반적으로 지연 시간을 줄이고 멋진 사용자 환경을 위해 작업 세트(활발하게 액세스하는 문서)를 메모리에 저장하는 것이 좋습니다.
그리고 디스크 읽기 횟수 를 확인하면 디스크 I/O를 파악할 수 있습니다. 이 숫자를 유지하는 것이 좋습니다. low 를 사용하여 대부분의 읽기가 RAM에서 처리되므로 더 빠릅니다.
그리고 디스크 쓰기 대기열 를 사용하면 디스크에 기록해야 하는 항목의 수와 디스크가 소모되는 속도를 알 수 있습니다. 디스크 쓰기 대기열이 매우 많은 경우(수백만 개의 항목) 클러스터의 크기가 정확하지 않을 수 있습니다.
다음은 REST API에 대한 링크입니다.
3. 별도의 디스크 장치에 데이터 및 인덱스 파일 분할
최적의 성능을 위해 데이터와 인덱스 파일을 서로 다른 저장 장치에 분리하세요. 이렇게 하면 성능 저하 없이 압축과 같은 성능 집약적인 작업을 수행할 수 있는 충분한 디스크 I/O 대역폭을 확보할 수 있습니다.
압축은 Couchbase의 애드온 전용 아키텍처를 고려할 때 공간을 확보하기 위해 항상 실행되는 중요한 프로세스입니다. 또한 예약할 수도 있습니다. 압축에 대해 자세히 알아보기 여기.
4. 안 돼! 리밸런싱에 실패하셨나요?
리밸런싱 카우치베이스 클러스터는 복잡한 작업입니다. 리밸런싱이 느려지거나 실패하는 데에는 몇 가지 이유가 있습니다. 이 프로세스를 보다 강력하게 만들기 위해 많은 노력을 기울였지만 그래도 리밸런싱이 실패하면 5분 정도 기다렸다가 프로세스를 다시 시작하세요. 리밸런싱 중에 클라이언트의 클러스터 맵이 자동으로 업데이트되므로 애플리케이션에는 아무런 영향이 없습니다.
재조정 버튼을 연속해서 여러 번 클릭하지 마세요. 프로세스를 다시 시작하면 유용한 작업이 낭비되고 때로는 혼란을 야기할 수 있습니다.
5. 스왑 리밸런싱이 일반 리밸런싱보다 낫다는 점을 기억하세요.
스왑 리밸런스는 동일한 작업에서 동일한 수의 노드를 추가 및 제거할 때 데이터 이동을 최적화합니다. 데이터는 제거되는 노드에서 추가되는 노드로 직접 이동됩니다. 이는 일반적으로 전체 클러스터에 걸쳐 데이터를 이동하는 표준 리밸런싱보다 더 효율적입니다.
6. 시스템 상태를 모니터링하고 Couchbase를 에코시스템과 통합하세요.
이미 nagios와 같은 외부 모니터링 시스템을 사용하여 인프라를 모니터링하고 있는 경우, REST API를 통해 기존 모니터링 시스템을 Couchbase에 플러그인할 수 있습니다. Couchbase Server는 알림 및 경고를 통해 사용자가 Couchbase Server 클러스터의 상태를 확인할 수 있도록 할 수 있습니다. 그 중 일부는 다음과 같습니다:
- IP 주소 변경 클러스터에 있는 Couchbase 서버의 IP 주소가 변경되면 해당 주소를 더 이상 사용할 수 없다는 경고 메시지가 표시됩니다. 서버의 IP 주소를 확인하고 클라이언트 또는 서버 구성을 업데이트해야 합니다.
- 메타데이터 오버헤드 버킷이 현재 메타데이터와 키를 저장하는 데 할당된 RAM 중 50% 이상을 사용하고 있어 데이터 값에 사용할 수 있는 RAM의 양이 줄어들고 있음을 나타냅니다. 클러스터에 노드를 추가해야 할 때 유용한 지표입니다.
- 디스크 사용량 영구 저장소에 사용 가능한 디스크 공간이 최소 90% 용량에 도달했음을 나타냅니다. 이는 클러스터에 디스크를 더 추가해야 할 수 있다는 신호입니다.
Couchbase는 또한 Hadoop 커넥터와 ElasticSearch용 플러그인 등 풍부한 어댑터 에코시스템을 갖추고 있습니다.
7. RAM, 디스크 및 CPU에 맞게 클러스터 크기를 적절히 조정하세요.
생산 전에는 매우 클러스터의 크기를 정하고 적절하게 테스트하는 것이 중요합니다.. Couchbase 클러스터의 크기는 안정성과 성능에 매우 중요합니다. 고성능을 위해 애플리케이션은 캐시에서 가능한 한 많은 읽기를 처리하고 시스템에는 쓰기를 처리할 수 있는 충분한 IO 용량이 있어야 합니다. 필요한 수준의 성능을 유지하면서 시스템이 수행하는 다른 모든 작업을 지원하려면 모든 다양한 영역에 충분한 용량이 있어야 합니다.
8. 데이터는 클러스터 전체에 복제됩니다. 선택적으로 인덱스도 복제할 수 있습니다.
카우치베이스의 문서는 클러스터 내에서 최대 3개까지 복제할 수 있습니다. 복제본 수(최대 3개)는 관리자 UI를 통해 구성할 수 있습니다. 인메모리 내 문서의 변경 사항은 활성 노드에서 복제 노드로 복제됩니다. 문서를 쿼리하려면 문서 ID를 사용하면 Couchbase가 기본 인덱스를 사용하여 문서를 조회합니다. 데이터의 하위 집합을 쿼리하려면 보조 인덱스를 사용할 수 있습니다. Couchbase에서 인덱스 복제는 선택 사항이며 관리자 UI를 통해 구성할 수 있습니다.
9. 데이터 센터 간 복제를 재해 복구에 사용할 수 있습니다.
Couchbase XDCR을 사용하면 클러스터 간에 데이터를 복제할 수 있습니다. 클러스터 간 데이터 액세스는 결국 일관성을 유지합니다. XDCR을 사용하려면 디스크와 I/O 용량이 두 배로 늘어나고 CPU도 더 필요하므로 클러스터의 크기를 조정하는 것을 잊지 마세요.
10. 인덱싱 조정
많은 수의 문서를 처리할 때 색인을 생성하는 방법에는 몇 가지가 있습니다. 첫 번째는 모든 문서를 처음부터 색인하는 것인데, 이는 시간이 오래 걸리는 프로세스입니다. 다른 하나는 변경된 문서에 대해서만 인덱스를 업데이트하는 것인데, 이는 점진적인 프로세스입니다. Couchbase에서는 증분 맵리듀스 방식으로 인덱스가 구축되므로 인덱스 업데이트 또는 구축 프로세스가 효율적입니다. 관리자는 병렬로 빌드할 수 있는 인덱스 수를 조정하거나 인덱스 빌드 사이의 시간/간격을 조정할 수 있습니다. 더 적은 수의 디자인 문서에 더 많은 뷰를 그룹화하여 성능을 개선하세요. 더 많은 보기 모범 사례는 여기에서 확인할 수 있습니다.
딱 10가지? 물론 아닙니다! 카우치베이스는 NoSQL 데이터베이스 시스템이며, 사용해 보면 더 많은 것을 배울 수 있습니다. 제가 상위 10가지 목록에 추가해야 할 중요한 내용을 놓쳤다고 생각되면 아래 댓글을 통해 자유롭게 추가해 주세요. 마지막으로 Couchbase Server 2.0의 모범 사례 가이드라인을 읽어보지 않으셨다면 꼭 읽어보세요.
즐기세요!
관련 링크
- 카우치베이스 서버 매뉴얼
- 카우치베이스 문서
전체 텍스트 검색을 위해 생성된 인덱스가 Couchbase에서 성능 문제를 일으킬 수 있나요? 성능이란 모든 애플리케이션에 의한 문서 추출을 의미하나요?
안녕하세요 로히트 님, 엔터프라이즈 프로덕션 환경에서는 검색 서비스의 워크로드를 데이터 서비스에서 완전히 분리할 수 있습니다. 카우치베이스 서버 엔터프라이즈 에디션의 다차원 확장 기능을 사용하는 한, 데이터, 보조 인덱스, N1QL 쿼리 등과 별도로 모든 검색 관련 서비스를 노드에서 실행하도록 선택할 수 있습니다.