서버 사용률: Couchbase 대 MongoDB

2012년에 운영 및 아키텍처 담당자로 몽고DB(MongoDB)를 처음 사용하기 시작했을 때, 저는 그 아키텍처 방식에 대해 몇 가지 핵심적인 불만을 가지고 있었습니다. 시간이 흐르면서 다른 이들도 비슷한 어려움을 겪고 있는 것을 목격했습니다. 근본적인 문제는 몽고DB가 설계상 서버/인스턴스의 성능을 온전히 활용하지 못한다는 점입니다. 사양이 좋은 서버/인스턴스 세 대를 프로비저닝했는데 응용 프로그램이 그 자원의 극히 일부만 사용하는 상황은 정말 싫습니다. 그것이 바로 몽고DB가 하는 일입니다. 레플리카 세트에서는 오직 프라이머리에만 쓰기 작업을 할 수 있습니다. 그런 다음 읽기 성능을 확장하려면 세컨더리 노드에서 읽어야 하는데, 이러한 읽기는 결과적 일관성(eventually consistent)을 가질 수 있습니다. 완전한 일관성이 반드시 필요하다면, 레플리카 세트의 프라이머리 노드와만 상호작용해야 합니다.

반면 카우치베이스는 스케일 아웃, 스케일 업 또는 둘 다를 지원합니다. 설계상 리소스가 과소 사용되는 서버가 발생하지 않습니다. 클러스터의 모든 서버가 애플리케이션의 성능에 기여하는 동시에 고가용성을 제공합니다.

그럼 두 데이터베이스가 이를 어떻게 처리하는지 자세히 알아보겠습니다.

MongoDB로 확장하기

문제의 근원에는 MongoDB의 “마스터-슬레이브” 아키텍처가 있습니다. 예를 들어 물리적 서버 세대가 있고, MongoDB 클러스터를 레플리카 세트로 실행하는 경우 (권장되는 하나 서버당 MongoDB 인스턴스) 애플리케이션은 이 세 서버 중 Primary가 실행 중인 단 하나의 서버에만 쓸 수 있습니다. 레플리카 세트의 나머지 두 서버는 순수하게 슬레이브(MongoDB 용어로 “Secondary”)이며, Primary가 다운되는 경우를 위해서만 존재합니다. 읽기 성능을 확장하기 위해 그 두 개의 Secondary에서 데이터를 읽을 수도 있지만, 그렇게 하면 읽기 작업이 더 이상 강력한 일관성(strongly consistent)을 유지하지 못하게 됩니다. 따라서 MongoDB가 권장하는 접근 방식에서는 이 Secondary 서버들이 (백그라운드 DB 유지보수 작업을 제외하고는) 활용도가 낮아지고 애플리케이션으로부터 거의 사랑받지 못하게 됩니다.

외로운 보조 서버들은 주 서버가 필요할 때를 대비하여 주 서버와 동일한 리소스로 구성되어야 합니다. 되다 a Primary. In the meantime, they are hardly utilized by your application. Then let’s say your web site is chugging along fantastically, but DB performance is starting to suffer a bit and writes are taking longer than your SLA allows. Now it’s time to scale! With MongoDB you need to add 최소한 다른 넷 하지만 모범 사례는 여섯 서버. MongoDB의 모범 사례에 따라 추가해야 합니다 다른 레플리카 세트(Shard #2). 서버는 세 대이지만, 각 문서의 위치를 관리하는 구성 서버도 별도로 존재합니다. 따라서 모범 사례에 따르면 이는 셋 더 서버들.

글쎄요, 적어도 그 많은 새 서버들이 있으니 쓰기 처리량이 훨씬 더 늘어날 테죠, 그렇죠? 그렇게 쉽게 생각하면 안 됩니다! 서버를 여섯 대 더 추가했더라도, 이제 쓰기 작업을 수행할 수 있는 서버는 아홉 대가 아니라 두 대뿐입니다. 기존의 프라이머리(레플리카 세트 #1)와 새로 추가된 프라이머리(레플리카 세트 #2)가 있을 뿐입니다. 이 모든 과정을 거치면서 여러분이 한 일은 클러스터의 복잡성과 유지보수 부담을 상당히 늘린 것뿐입니다. 쓰기 성능을 높이기 위해 샤드를 하나 더 추가해야 한다면, 다음을 추가해야 합니다. 다른 세 개의 노드. 귀하의 애플리케이션은 각 복제 세트에서 그 서버들 중 단 두 개조차 사용할 기회를 얻지 못합니다.

내가 목격한 베어메탈 서버의 활용률 저하를 해결하는 한 가지 방법은, 몽고디비 자체의 권고에 반하여, 동일한 서버에 수많은 mongod 프로세스를 실행하는 것입니다. 추천. 성능 문제는 제쳐두고, 가상 서버를 사용하더라도 노드 중 하나가 다운되면 어떻게 됩니까? 몇 개의 프라이머리와 세컨더리를 잃게 됩니까? 레플리카 세트가 클러스터 내의 서버들에 적절히 분산되어 이를 견딜 수 있도록 모든 프라이머리와 세컨더리의 위치를 파악해 두었습니까? 복잡성을 높이는 것에 대해 말씀하셨는데, 맙소사, 이것야말로 정확히 그 일을 해냅니다!

카우치베이스로 확장하기

위에서 논의한 동일한 세 대의 서버 시나리오를 이번에는 카우치베이스(Couchbase) 관점에서 살펴보겠습니다. 여러분의 애플리케이션은 세 대의 서버에 걸쳐 있는 격리된 디스크, 메모리, 네트워크, CPU 코어 등을 통해 읽고 쓸 수 있습니다. 카우치베이스에서는 데이터가 세 대의 서버에 고르게 분산되며 서버 간에 복제됩니다. 애플리케이션이 사용하는 카우치베이스 SDK는 데이터에 접근하는 방법, 클러스터 내 카우치베이스 서비스의 위치, 그리고 이 모두에 접근하는 방법을 알고 있습니다. 위와 동일한 확장 시나리오를 통해 카우치베이스에서의 옵션을 살펴보겠습니다. 관리 콘솔에서 두 번의 클릭으로, 또는 하나의 CLI 명령어로 클러스터에 서버를 신속하게 추가할 수 있습니다.

$> /opt/couchbase/bin/couchbase-cli rebalance 
    -c :8091 
    --server-add=:8091 
    -u Administrator -p

이것을 다음 과 비교해 보세요. 필요한 단계 MongoDB에서 레플리카 세트를 추가하는 것과 같습니다. 카우치베이스의 경우, 용량이 더 필요할 때 서버를 한두 대 추가한 다음 리밸런싱만 하면 됩니다. 다음 주에 용량이 더 필요하면 서버를 더 추가하고 다시 리밸런싱을 하면 됩니다. 얼마나 간편한지 아시겠습니까? 귀하의 애플리케이션은 항상 다음을 사용하고 있습니다 모두 클러스터 내 서버들의. 여러분은 애플리케이션을 변경할 필요조차 없으며, 다운타임 없이 언제든지 하나 이상의 서버를 추가할 수 있습니다. 결론적으로 서버나 서버 자원을 낭비하지 않는다는 것입니다. 원한다면 각 서버의 모든 자원을 빠짐없이 활용하고 수평적으로 확장할 수 있습니다. 여러분은 컴퓨터의 Couchbase 노드 하나에서 애플리케이션을 작성하고 추가적인 노력 없이 프로덕션 환경의 얼마나 큰 클러스터에든 배포할 수 있습니다.

물론 카우치베이스에도 복제본 데이터가 있지만, 복제본 데이터는 고가용성을 위해서만 사용됩니다. MongoDB처럼 성능을 위해 일관성을 포기하는 이유는 무엇이며, 카우치베이스에서는 둘 다 얻을 수 있는데 왜 그러십니까? 그리고 카우치베이스에서 가상 머신(VM)을 사용하고자 할 때 복잡성을 줄이는 측면에서는 랙/영역 인식(Rack/Zone Awareness) 기능을 사용할 수 있습니다.

여기서 이야기하는 내용에 대한 간단한 시각적 비교가 아래에 있습니다. 나열된 열네 대의 서버 중 실제로 쓰기 작업을 할 수 있는 서버는 세 대뿐이라는 점에 주목하세요. 

 

이것을 카우치베이스 쪽과 비교해 보면 얼마나 더 단순하고 깔끔하며 관리하기 쉬운지 직접 확인할 수 있습니다. 이와 관련한 자세한 내용은 다음을 참조하세요. 마누엘 우르타도의 블로그 글 이는 카우치베이스와 몽고DB에서 프로덕션 준비가 완료된 클러스터를 구축하는 것을 대조합니다. 또한 이 문제를 다루는 독립적인 제3자 아키텍처 비교 자료도 있습니다. 예를 들어 이것.

요약

지금쯤이면 명확해졌겠지만, MongoDB에는 애플리케이션이 그 비싼 서버와 인스턴스들을 온전히 활용하는 데 있어 심각한 문제가 있습니다. 물론 몇 가지 우회책이 있기는 하지만, 대부분의 운영 담당자들은 그런 식의 적층형 구성을 권장하지 않습니다. 가상화를 사용하더라도 그렇게 고밀도로 구성하는 것은 좋은 생각이 아닙니다. 게다가 이 문제는 MongoDB의 핵심 아키텍처에 내재되어 있어 가까운 시일 내에 해결될 가능성이 낮습니다. 반면에 Couchbase는 제공하는 모든 서버를 온전히 활용하도록 아키텍처가 설계되어 있어, 데이터와 부하를 클러스터 전반에 고르게 분산시킵니다. 이 모든 것이 간편한 관리 기능과 어떤 규모에서도 운영할 수 있는 능력과 함께 제공됩니다.

서버 활용률은 데이터베이스 라이선스, 하드웨어, 관리 오버헤드, 시설 비용의 합산 비용이 순식간에 통제 불능 상태로 치솟을 수 있기 때문에 중요한 문제입니다. 이에 대해 몇 가지 수치를 들어보자면, 관리 오버헤드를 제외하고도 비용은 이상입니다 연간 $700 단순히 자체 데이터센터에 있는 평범한 상용 서버에 전력을 공급하는 데만도 (그다지 효율적이지 않은) 비용이 듭니다. 그리고 용량을 확보하기 위해 클라우드를 이용하기로 한다면, 인스턴스당 총 비용은 $8-10,000에 육박할 수 있으며, 연간. 따라서 이것은 아키텍처적 고려 사항이 비용과 복잡성에 상당한 영향을 미칠 수 있음을 보여주는 진정한 사례입니다. 그러므로 할 의향이 있으시다면, 다운로드하러 가기 카우치베이스를 실행하고 그 서버들과 카우치베이스 자체의 성능을 얼마나 쉽게 최대한으로 끌어낼 수 있는지 직접 확인해 보세요.