카우치베이스 서버 2.0: 가장 일반적인 질문(및 답변)

곧 출시될 Couchbase Server 2.0의 기능을 소개하는 9주간의 기술 웨비나 시리즈를 막 마쳤습니다. 수백 명의 참가자들과 소통할 수 있어서 정말 즐거웠고, 이 신제품에 대한 기대와 참여도, 기대감에 놀랐습니다.

(참고로, 시리즈를 놓치셨다면 9개의 세션은 다음과 같습니다. 재생 가능.) 웨비나 시리즈를 진행하는 동안 사용자들로부터 좋은 질문이 많았는데, 원래 계획은 이 블로그 포스팅을 통해 그 질문들을 모두 소개하는 것이었습니다. 하지만 질문이 너무 많아서 모든 질문을 다 읽을 수 없다는 것을 금방 깨달았기 때문에 다른 방법을 택했습니다. 이 블로그에서는 가장 일반적이거나 중요하거나 흥미로운 질문들을 선별하여 모든 분들께 도움이 될 수 있도록 답변해 드리겠습니다. 시작하기 전에 가장 많이 받은 질문에 대한 답변을 먼저 드리겠습니다: "카우치베이스 서버 2.0의 일반 공개까지는 얼마나 걸리나요?" 현재 연말 이전에 출시하기 위해 순조롭게 진행 중입니다. 그 동안에는 이미 제공되는 개발자 프리뷰를 통해 자유롭게 실험해 보시기 바랍니다. 나머지 질문은 여기까지입니다!

질문: Membase와 CouchDB를 단일 제품으로 통합하면 어떤 주요 이점이 있나요?

A: Membase는 성능과 확장성이 뛰어난 초고속 키 값 저장소로 잘 알려져 있습니다. 반면에 CouchDB는 강력한 색인 및 쿼리 기능을 갖춘 훌륭한 문서 데이터베이스입니다. 이 두 제품을 결합하면 두 제품의 장점을 결합하여 쿼리, 인덱싱 및 문서 지향 기능을 제공하면서 선형적으로 확장되는 고성능의 매우 탄력적인 NoSQL 데이터베이스를 만들 수 있습니다.

질문: Couchbase는 데이터베이스 문서를 메모리에 자동으로 캐싱하여 액세스 속도를 높이나요?

A: 물론입니다! 이는 Couchbase Server 2.0의 가장 큰 특징 중 하나이며, 멤캐시에 대한 방대한 경험에서 비롯된 것입니다. 문서에 대한 모든 액세스는 멤캐시로 구축된 통합 RAM 캐싱 계층을 통해 이루어지기 때문에 부하가 매우 높은 상황에서도 매우 낮고 예측 가능한 지연 시간을 제공합니다. 예를 들어, 저희는 클러스터 전체에서 초당 10만 건 이상의 작업을 수행하는 고객을 정기적으로 만나고 있으며, 자체 테스트 환경에서는 단일 노드에서 초당 20만 건 이상의 작업을 수행한 적도 있습니다. 또한 이 RAM 캐싱 계층은 애플리케이션의 성능에 영향을 주지 않고 쓰기(및 읽기) 로드의 급증을 처리할 수 있게 해줍니다.

질문: 포럼에서 Couchbase Server 2.0이 데이터 액세스에 멤캐시드 프로토콜을 사용하는 것을 봤는데, 이는 기존 Membase 사용자와 호환되고 훨씬 더 높은 성능을 제공하기 때문입니다. CouchDB와 유사한 REST API를 사용하여 Couchbase Server 2.0의 문서에 액세스할 수 있는 방법이 있나요?

A: Couchbase Server 2.0의 첫 번째 버전은 문서 액세스에는 memcached 프로토콜을, 뷰 액세스에는 CouchDB HTTP 프로토콜을 사용합니다. 시간이 지남에 따라 이 두 프로토콜은 더욱 긴밀하게 통합될 것입니다. 그동안 저희는 개발자가 이 두 가지 액세스 방법을 추상화하는 여러 클라이언트 라이브러리를 제공해 왔습니다.

질문: Couchbase Server 2.0은 오픈 소스로 제공되나요?

A: 이미 그렇습니다! 카우치베이스는 회사로서 다양한 제품을 중심으로 존재하고 구축되고 있는 오픈 소스 커뮤니티를 발전시키는 데 전념하고 있습니다. 유료 고객에게 엔터프라이즈급 소프트웨어를 제공하는 데 중점을 두고 있지만, 오픈 소스 프로젝트가 허용하는 자유로운 아이디어의 흐름과 폭넓은 채택을 수용하며 이 두 가지 모두를 위한 자리가 있다고 굳게 믿고 있습니다.

인덱싱/쿼리

질문: "매핑/축소가 아닌 간단한 보조 인덱스만 필요한데 어떻게 해야 하나요?

A: 현재 모든 인덱스는 맵 함수를 사용하여 작성됩니다(감소는 전적으로 선택 사항이며 여기서는 무시해도 됩니다). 이것은 인덱스를 만드는 또 다른 구문일 뿐이며, 아주 간단한 인덱스를 만드는 방법을 설명하는 다양한 예제가 있습니다. 가장 간단한 형태는 색인을 생성하려는 맵 함수에 "emit(doc.)"를 넣는 것입니다. 그러면 해당 필드가 포함된 모든 문서 목록이 해당 필드별로 정렬되어 생성됩니다. 물론 더 복잡한 시나리오도 있지만, 필요한 경우 아주 간단하게 만들 수 있습니다.

질문: CouchBase Server 2.0 뷰를 처리하는 방식은 CouchDB 및 CouchBase 단일 서버와 어떻게 다른가요?

A: 전혀 그렇지 않습니다... 형식, 구문 등 모든 것이 동일합니다. 또한 쿼리를 위한 모든 옵션이 지원됩니다. 말 그대로 뷰 코드를 복사하여 다른 뷰에 붙여넣을 수 있습니다. 여러 디자인 문서도 지원됩니다.

질문: 카우치베이스 서버 2.0은 애드혹 쿼리를 지원하나요?

A: 현재 CouchDB와 같은 Couchbase Server에 대한 모든 쿼리는 미리 구체화된 뷰에 대해 수행해야 합니다. 일반적으로 이러한 쿼리를 수행할 때 안정적인 성능을 제공하는 유일한 방법입니다. 또한 더 많은 온디맨드/애드혹 쿼리에 대한 필요성을 이해하고 있으며, 이를 제공하기 위해 열심히 노력하고 있습니다. Couchbase는 이미 업계 선도적인 접근 방식을 취해 NoSQL 환경에서 사용할 수 있는 비정형 데이터 전용 언어를 만들기 시작했습니다. http://unqlspec.org 에서 저희가 어떤 작업을 하고 있는지 살펴보세요!

SDK/클라이언트 라이브러리

질문: 어떤 SDK와 클라이언트 라이브러리가 지원되나요?

A: 기본 수준에서 Couchbase Server 2.0은 멤캐시드 프로토콜을 구현하는 모든 라이브러리를 지원합니다(수많은 라이브러리가 있습니다). 추가된 추가 기능(확장 프로토콜 명령 및 보기 액세스)을 위해 Couchbase는 다양한 언어(Java, .NET, PHP, Python, Ruby, C/C++)용 클라이언트 라이브러리와 다른 언어용 라이브러리를 확장하는 방법에 대한 지침을 제공합니다.

질문: stale=update_after로 도그파일링이 발생할 가능성이 있나요? stale=update_after가 있는 뷰에 대해 30개의 요청을 동시에 받는 경우 인덱스 업데이트를 위한 여러 요청이 동시에 생성되나요?

A: 요약하자면, "stale"은 이미 기록된 일부 데이터가 뷰에 포함되지 않을 수 있음을 알고 있으므로 이 쿼리 요청을 가능한 한 빨리 반환해야 한다는 것을 서버에 알려줍니다. 요청에 "update_after"를 넣음으로써 클라이언트는 서버에 초기 요청을 최대한 빨리 반환한 후 백그라운드에서 인덱스를 다시 구체화하도록 지시합니다. 이 재물질화가 시작되면 후속 요청으로 인해 다른 일이 발생하지 않으므로 "도그파일링" 또는 "스탬핑 무리" 문제가 발생할 염려가 없습니다.

질문: 클라이언트는 언제 서버/vbucket 맵을 업데이트해야 하는지 어떻게 알 수 있나요?

A: 모든 클라이언트("스마트" 클라이언트이든 Moxi 프로세스를 거치는 클라이언트이든)는 Couchbase 서버에 대한 스트리밍 연결을 유지합니다. 클러스터의 토폴로지가 변경되면(노드 추가/제거/장애 조치), 클라이언트는 이 연결을 통해 새 vbucket 맵으로 자동 업데이트됩니다. 클라이언트는 필요에 따라 이 맵을 요청할 수도 있으며, 시작할 때마다 요청할 수 있습니다. 또한 클러스터의 각 노드는 자신이 담당하는 v버킷을 알고 해당 v버킷에 대한 데이터만 반환합니다. 이렇게 하면 클라이언트가 일시적으로 클러스터와 동기화되지 않더라도 일관되지 않은 데이터에 취약하지 않습니다.

개발/프로덕션 뷰 사용

질문: '개발' 모드에서 뷰를 만든 다음 프로덕션에 푸시하는 추가 작업이 필요한 이유는 무엇인가요?

A: 라이브 데이터 집합에서 뷰를 개발할 수 있는 기능을 제공하고 싶었지만, 그 개발이 현재 실행 중인 애플리케이션에 영향을 미치고 싶지 않았습니다. 따라서 사용자가 '실제' 데이터에 대한 뷰를 만들고 편집할 수 있도록 '개발' 모드를 만들었습니다. 개발 반복의 속도를 높이기 위해 기본값은 데이터의 하위 집합에 대한 뷰를 구체화하는 것입니다. 개발이 완료되면 사용자는 뷰를 프로덕션 환경으로 푸시하기 직전에 전체 클러스터에 대해 뷰를 구체화하도록 선택할 수 있습니다. 이렇게 하면 뷰를 구체화하여 애플리케이션에서 즉시 사용할 수 있도록 준비할 수 있다는 추가적인 이점이 있습니다. 마지막으로, 이 '개발' 모드를 사용하면 애플리케이션의 뷰 액세스에 영향을 주지 않고(복사본을 만들어서) 현재 프로덕션 환경에 있는 뷰를 편집할 수 있습니다. 편집이 완료되면 뷰를 구체화하여 원본과 교체하여 프로덕션에 적용할 수 있습니다.

질문: 개발 데이터 집합을 어떻게 제어하나요?

A: 현재 개발 데이터 집합은 존재하는 데이터의 양에 따라 소프트웨어가 자동으로 결정합니다. 작은 데이터 세트의 경우 소프트웨어가 실제로 전체에 걸쳐 뷰를 구체화합니다. 데이터 집합이 커지면 소프트웨어는 개발 중에 더 빠른 응답 시간을 제공하기 위해 자동으로 축소합니다. 뷰가 완성되면 사용자는 최종 검증을 위해 또는 프로덕션 사용을 준비하기 위해 전체 데이터 집합에 대해 수동으로('전체 클러스터 데이터 집합' 탭을 클릭하여) 뷰를 실행할 수 있는 옵션이 있습니다.

클러스터링

질문: 복제본 및 자동 장애 조치 기능이 있는 버킷의 경우, 리밸런싱 없이 서버에 장애가 발생하면 해당 버킷에서 검색/업데이트 오류가 발생하나요?

답변: 하드웨어, 네트워크, 소프트웨어 등 어떤 이유로든 서버에 처음 장애가 발생하면 해당 서버가 담당하던 모든 데이터에 대해 애플리케이션에 잠시 오류가 발생합니다. 다른 서버의 데이터 요청에는 영향을 미치지 않습니다. 이러한 오류는 노드가 '장애 조치'되어 클러스터의 다른 곳에서 복제 데이터(v버킷)를 활성화할 때까지 계속됩니다. 시간은 자동 장애 조치를 사용하는지 수동 장애 조치를 사용하는지에 따라 다르지만 일단 장애 조치가 트리거되면 더 이상 지연되지 않습니다. "하지만 이미 존재하는 복제본 데이터에서 읽을 수 없는 이유는 무엇인가요?"라고 질문할 수 있습니다. 답은 두 가지입니다. 첫째, 시스템이 제공하는 매우 강력한 일관성을 유지하기 위해 복제본 데이터('복제본' 상태)에 대한 액세스를 특별히 허용하지 않습니다. 정상 작동 시에는 '자신의 쓰기'가 보장되며, 이는 특정 데이터에 액세스할 수 있는 하나의 위치만 제공함으로써 이루어집니다. 복제본에 대한 무제한 읽기를 허용하면 한 클라이언트가 활성 복사본에 데이터를 쓰고 다른 클라이언트가 즉시 복제본에서 해당 데이터를 읽으려고 시도하는 상황이 발생할 수 있으며, 이로 인해 불일치가 발생할 수 있습니다. 이 답변의 두 번째 부분은 현재 이러한 복제본에서 읽을 수 있는 기능을 개발 중이라는 것입니다. 이 기능은 애플리케이션에서 명시적으로 호출되는 새로운 작업이 될 것이므로 어느 복제본에서 읽는지 혼동하지 않도록 할 것입니다. 쓰기가 계속 실패하므로 가능한 한 빨리 노드를 페일오버하고 싶을 것입니다. 이는 고객과 사용자의 요구에 직접적으로 대응하기 위해 추가한 많은 기능 중 한 가지 예입니다... 여러분이 말씀하시면 저희도 귀를 기울이고 그에 대한 조치를 취합니다!

질문: 쓰기 부하가 많은 상태에서 시스템을 리밸런싱할 때 어떤 영향/위험/시간이 있나요? 꽤 많은 시간 동안 노드를 추가하는 것이 가장 좋은가요?

답변: 설계상 재조정 작업은 클러스터의 성능에 미치는 영향을 최대한 최소화하기 위해 비동기적으로 수행됩니다. 그러나 실제로는 리밸런싱을 수행하면 클러스터에 부하가 증가하고 리소스(네트워크, 디스크, RAM, CPU)가 필요합니다. 클러스터가 이미 용량에 근접한 경우 부하가 증가하면 애플리케이션의 성능에 영향을 미칠 수 있습니다. 언제든지 수행해도 안전하지만, 자체 환경에서 자체 테스트를 수행하여 리밸런싱으로 인해 어떤 영향이 있는지 파악하는 것이 좋습니다. 일반적으로 고객은 한가하거나 조용한 시간에 이러한 테스트를 수행하지만, 가장 큰 장점은 계속 확장할 때 애플리케이션을 완전히 오프라인으로 전환할 필요가 없다는 것입니다.

Q: vbucket이란 무엇인가요?

A: v버킷은 데이터를 논리적으로 분할하여 클러스터 내의 모든 노드에 분산할 수 있도록 하는 방식입니다. 클러스터에 생성되는 모든 Couchbase 유형 버킷은 자동으로(그리고 투명하게) 정적 슬라이스 집합(v버킷)으로 분할됩니다. 그런 다음 개별 서버에 "매핑"됩니다. 노드가 추가되거나 제거되면 이러한 슬라이스가 이동하고 다시 매핑되어 선형적이고 중단 없는 확장을 제공합니다. 애플리케이션과 사용자로부터 완전히 추상화되어 있지만, Couchbase Server가 가진 많은 훌륭한 기능을 제공하기 위해 "내부에" vbuckets가 존재한다는 점을 인식하는 것이 중요합니다. vbucket 개념에 대해 자세히 알아볼 수 있습니다.

모니터링

질문: CouchBase Server 클러스터를 모니터링하는 유일한 방법은 CouchBase Server 웹 UI인가요?

A: 꼭 그렇지는 않습니다. 웹 UI에 표시되고 수행할 수 있는 모든 것은 실제로 외부에서 프로그래밍 방식으로 액세스할 수 있는 REST 인터페이스에 의해 구동됩니다. 또한, 각 개별 서버(및 해당 서버의 각 개별 버킷)는 REST API에서 사용하는 자체 '원시' 통계를 제공합니다. 이러한 원시 통계는 외부에서도 사용할 수 있습니다:

저희의 목표는 사용자가 용량 계획 관점과 문제가 발생했을 때 진단/문제 해결 관점에서 시스템을 효과적으로 모니터링할 수 있도록(또는 처음부터 문제가 발생하지 않도록) 시스템에 대한 정보를 최대한 많이 제공하는 것입니다.

질문: 카우치베이스 서버는 어떤 종류의 알림을 제공하나요?

A: 엄밀히 말하면 저희는 알림 소프트웨어를 만드는 회사가 아닙니다. 저희는 다른 시스템이 활용할 수 있는 인터페이스를 제공하는 일을 하고 있습니다. 대부분의 대규모 조직은 스택의 각 기술이 서로 다른 형식의 알림을 보내는 것을 원하지 않을 것입니다. 그렇기 때문에 저희는 통계 및 모니터링 데이터를 다른 시스템에 쉽게 연결할 수 있도록 만들었습니다. 그러나 일부 소규모 환경에서는 소프트웨어에서 이 기능을 즉시 제공하기를 원할 수도 있다는 사실도 알고 있습니다. 저희는 이 기능을 확장하기 위해 노력하고 있으며, 이미 노드 다운 시 알림을 제공하고 있습니다.

자동 압축

질문: 기간이 끝날 때 다짐을 중단하면 그 시점까지 완료된 다짐이 계속 저장되나요, 아니면 지금까지 완료된 모든 다짐이 손실되나요?

A: 일반적으로 압축은 전부 아니면 전무이기 때문에 압축을 중단하면 지금까지의 진행 상황을 잃게 됩니다. 하지만 Couchbase Server에서는 v버킷 단위로 압축을 수행하므로(위 참조), 중단해도 진행 상황을 모두 잃지 않고 전체 데이터 세트가 실제로 점진적으로 압축될 수 있습니다.

자동 장애 조치

질문: 클러스터가 다운된 노드를 자동으로 페일오버하기 전에 지연이 발생하는 이유는 무엇인가요?

답변: 기본적으로 소프트웨어는 자동 장애 조치가 시작되기까지 최소 30초가 걸리도록 구성되어 있습니다. 이는 소프트웨어가 "잘못된" 작업을 수행하지 않도록 하기 위한 것입니다. 예를 들어, 노드가 단순히 응답 속도가 느리거나 네트워크에 잠시 문제가 있는 경우, 노드가 장애 조치되는 것을 원하지 않을 것이므로 클러스터는 노드가 실제로 다운되었는지 확인하기 위해 기다립니다.

더 많은 정보를 얻으려면 여기를 방문하여 매주 25~30분 분량의 웨비나 동영상을 시청할 수 있습니다. 그리고 Couchbase Server 2.0에 관한 모든 정보를 얻을 수 있는 권위 있는 곳은 여기입니다. 이번 시리즈가 마무리되었지만, 다음 시리즈를 시작하여 Couchbase Server 2.0의 기능뿐만 아니라 Couchbase Mobile, SDK/클라이언트 라이브러리 등을 소개할 계획입니다! 일부 주제에는 다음이 포함될 예정입니다:

• 클러스터 간 동기화(일명 데이터 센터 간 복제)
• 카우치베이스 서버 2.0을 사용한 백업/복원
• Membase 1.7에서 업그레이드하기
• 그리고 더!

더 나은 서비스를 제공하기 위해 여러분의 참여를 요청합니다! 여기에 댓글을 달아주시거나 다음 주소로 직접 이메일을 보내주세요. perry@couchbase.com)로 문의해 주시면 다음 웨비나에 추가적으로 다뤄야 할 주제가 있다면 최선을 다해 포함하도록 하겠습니다.