서버 활용도: 카우치베이스 대 몽고DB

2012년에 운영 및 아키텍처 담당자로서 MongoDB를 처음 사용하기 시작했을 때, 저는 아키텍처 설계 방식에 몇 가지 중요한 문제가 있었습니다. 시간이 지나면서 다른 사람들도 비슷한 문제를 겪는 것을 목격했습니다. 근본적인 문제는 MongoDB가 설계상 서버/인스턴스의 성능을 충분히 활용하지 못한다는 것입니다. 좋은 서버/인스턴스 세 대를 프로비저닝해도 애플리케이션은 실제로 리소스의 일부만 사용합니다. 이것이 바로 MongoDB가 하는 일입니다. 복제본 세트의 기본 서버에만 쓸 수 있습니다. 그런 다음 읽기를 확장하려면 보조 노드에서 읽어야 하며, 이러한 읽기는 결국 일관성을 유지할 수 있습니다. 완전한 일관성을 유지해야 하는 경우에는 복제본 세트의 기본 노드와만 상호 작용할 수 있습니다.

반면 Couchbase는 스케일 아웃, 스케일 업 또는 둘 다 가능합니다. 설계상 활용도가 낮은 서버가 없습니다. 클러스터의 모든 서버가 애플리케이션의 성능에 기여하며 여전히 높은 가용성을 제공합니다.

이제 두 데이터베이스가 이 문제를 어떻게 처리하는지 자세히 살펴보겠습니다.

MongoDB로 확장

문제의 근원은 MongoDB의 "마스터-슬레이브" 아키텍처에 있습니다. 예를 들어 물리적 서버가 세 대 있고 복제본 세트로 MongoDB 클러스터를 실행하는 경우(권장되는 하나 서버당 MongoDB 인스턴스), 애플리케이션은 이 세 서버 중 하나, 즉 기본 서버를 실행하는 서버에만 쓸 수 있습니다. 복제본 세트의 다른 두 서버는 순전히 슬레이브(MongoDB 용어로 "보조 서버")로서 기본 서버가 다운될 경우에만 존재합니다. 읽기 확장을 위해 이 두 개의 보조 서버에서 데이터를 읽을 수는 있지만, 그러면 읽기의 일관성이 더 이상 유지되지 않습니다. 따라서 MongoDB 권장 접근 방식에서는 이러한 보조 서버는 백그라운드 DB 유지 관리 작업 외에는 활용도가 낮고 애플리케이션에서 거의 사용하지 않습니다.

외로운 보조 서버는 다음과 같은 경우에 대비하여 기본 서버와 동일한 리소스로 구성해야 합니다. become 기본. 그 동안에는 애플리케이션에서 거의 활용되지 않습니다. 웹 사이트는 환상적으로 잘 돌아가고 있지만 DB 성능이 약간 저하되기 시작하고 쓰기 시간이 SLA가 허용하는 것보다 오래 걸린다고 가정해 보겠습니다. 이제 확장할 때입니다! MongoDB를 사용하면 다음을 추가해야 합니다. 최소한 다른 네 하지만 가장 좋은 방법은 여섯 서버를 추가해야 합니다. MongoDB의 모범 사례에 따르면, 다음을 추가해야 합니다. 다른 복제본 세트(샤드 #2). 서버는 3개이지만 모든 문서가 있는 위치에 대한 정보를 보관하는 구성 서버가 있으므로 모범 사례에 따르면 다음과 같습니다. 세 더 보기 서버.

새 서버를 사용하면 쓰기 처리량이 훨씬 더 많아지겠죠? 그렇지 않습니다! 서버를 6개 더 추가하더라도 이제 9개가 아니라 최대 2개의 서버에만 쓸 수 있습니다. 원래 기본 서버(복제본 세트 #1)와 새로운 기본 서버(복제본 세트 #2)가 생겼습니다. 이 모든 작업으로 인해 클러스터의 복잡성과 유지 관리 오버헤드가 크게 증가했습니다. 쓰기 성능을 향상시키기 위해 다른 샤드를 추가해야 하는 경우, 추가해야 합니다. 다른 세 개의 노드. 애플리케이션은 각 복제본 세트에서 해당 서버 중 두 개씩만 플레이할 수 있습니다.

제가 관찰한 베어 메탈 서버의 활용도 저하 문제를 해결하는 한 가지 방법은 동일한 서버에 많은 수의 몽고 프로세스를 배치하는 것입니다. 권장 사항. 성능 문제는 제쳐두고, 가상 서버를 사용하더라도 노드 중 하나가 다운되면 어떻게 되나요? 얼마나 많은 프라이머리와 세컨더리가 손실되나요? 이를 견딜 수 있도록 복제본 세트가 클러스터의 서버에 적절히 분산되어 있는지 확인하기 위해 모든 기본 및 보조 서버의 위치를 추적했나요? 복잡성 증가에 대해 말씀하셨는데, 이게 바로 그거예요!

Couchbase로 확장

위에서 설명한 것과 동일한 세 대의 서버 시나리오를 이번에는 Couchbase를 염두에 두고 살펴봅시다. 애플리케이션은 격리된 디스크, 메모리, 네트워크, CPU 코어 등 세 대의 서버에서 모두 읽고 쓸 수 있습니다. Couchbase에서는 데이터가 세 서버에 고르게 분산되고 서버 간에 복제됩니다. 애플리케이션에서 사용하는 Couchbase SDK는 데이터에 액세스하는 방법, 클러스터에서 Couchbase 서비스가 있는 위치, 그리고 모든 서비스에 액세스하는 방법을 알고 있습니다. 위와 동일한 확장 시나리오를 가정하여 Couchbase의 옵션을 살펴봅시다. 관리 콘솔에서 두 번의 클릭 또는 하나의 CLI 명령으로 클러스터에 다른 서버를 빠르게 추가할 수 있습니다.

이를 다음과 비교해보십시오. 필요한 단계 를 사용하여 MongoDB로 복제본 세트를 추가할 수 있습니다. Couchbase를 사용하면 용량이 더 필요하면 서버 한두 대를 추가한 다음 다시 밸런싱하면 됩니다. 다음 주에 용량이 더 필요하면 용량을 추가하고 다시 밸런스를 조정하면 됩니다. 얼마나 쉬운지 아시겠죠? 애플리케이션은 항상 모두 서버를 클러스터에 추가할 수 있습니다. 애플리케이션을 변경할 필요도 없으며 다운타임 없이 원할 때 언제든지 하나 이상의 서버를 추가할 수 있습니다. 결론은 서버나 서버 리소스를 낭비하지 않는다는 것입니다. 원하는 경우 각 서버의 모든 비트를 사용할 수 있으며 수평적으로 확장할 수 있습니다. 컴퓨터의 Couchbase 노드 하나에서 애플리케이션을 작성하고 추가 작업 없이 프로덕션의 클러스터 규모에 상관없이 배포할 수 있습니다.

물론 Couchbase에도 복제 데이터가 있지만, 복제 데이터는 고가용성을 위해서만 사용됩니다. Couchbase에서 두 가지를 모두 얻을 수 있는데 왜 MongoDB와 같은 성능을 위해 일관성을 포기할까요? 그리고 Couchbase에서 VM을 사용하고자 할 때 복잡성을 낮추려면 랙/영역 인식 기능을 사용할 수 있습니다.

아래는 여기서 말하는 내용을 시각적으로 간단히 비교한 것입니다. 이 모든 서버가 있는 MongoDB 클러스터에서는 나열된 14개 서버 중 쓸 수 있는 서버가 3개뿐이라는 것을 알 수 있습니다. 

이를 Couchbase 측과 비교하면 얼마나 더 간단하고 깔끔하며 관리하기 쉬운지 알 수 있습니다. 이와 관련된 자세한 내용은 다음을 참조하세요. 마누엘 후르타도의 블로그 게시물 에서 프로덕션 준비 클러스터를 설정하는 것과 MongoDB를 설정하는 것을 비교하는 문서입니다. 또한 다음과 같이 문제를 해결하는 독립적인 타사 아키텍처 비교도 있습니다. 이것.

요약

이제야 알 수 있겠지만, MongoDB는 애플리케이션이 고가의 서버/인스턴스를 모두 활용하는 데 심각한 문제가 있습니다. 물론 몇 가지 해결 방법이 있긴 하지만 대부분의 운영 담당자는 가상화를 사용하더라도 그렇게 고밀도로 스택하는 것은 좋은 생각이 아니라고 조언할 것입니다. 무엇보다도 이 문제는 핵심 아키텍처에 내장되어 있기 때문에 MongoDB가 조만간 수정할 가능성이 높지 않습니다. 반면에 Couchbase는 모든 서버를 최대한 활용하도록 설계되어 데이터와 부하를 클러스터 전체에 고르게 분산시킵니다. 이 모든 것이 손쉬운 관리와 규모에 관계없이 운영할 수 있는 능력과 함께 제공됩니다.

데이터베이스 라이선스, 하드웨어, 관리 오버헤드, 시설 비용을 합치면 금방 통제 불능 상태가 될 수 있기 때문에 서버 사용률은 중요한 문제입니다. 관리 오버헤드를 제외하고 몇 가지 수치를 살펴보면 다음과 같습니다. 연간 $700 자체 데이터센터의 일반 상용 서버에 전력을 공급하는 데만 (멋지지 않은) 비용이 듭니다. 그리고 용량을 위해 클라우드를 선택하면 총 비용은 인스턴스당 $8-10,000에 육박할 수 있습니다, 연간. 따라서 이것은 아키텍처 고려 사항이 비용과 복잡성에 상당한 영향을 미칠 수 있는 진정한 예입니다. 그러니 원하신다면 다운로드 바로가기 Couchbase를 로드하고 해당 서버와 Couchbase 자체의 성능을 얼마나 쉽게 끌어낼 수 있는지 확인해 보세요.