노드 수는 몇 개인가요? 3부: 하드웨어 고려 사항

이 시리즈의 첫 두 파트에서는 다음과 같은 개요를 다루었습니다. Couchbase Server 클러스터 크기 조정의 5가지 요소를 살펴보고, 다양한 사용 사례와 기능 및 크기 조정에 미치는 영향에 대해 자세히 살펴봅니다. 네 번째 파트에서는 모니터링을 위한 메트릭 를 사용하여 적절한 크기와 클러스터를 확장할 시기를 결정할 수 있습니다.

이제 하드웨어 권장 사항에 대한 몇 가지 지침을 제공하고자 합니다. 카우치베이스에서 하드웨어에 대해 매우 엄격하고 빠른 요구 사항을 요구하기는 쉽지만, 고객이 소프트웨어를 사용하고자 하는 사용 사례와 애플리케이션/인프라 환경이 크게 다르다는 점을 고려하면 이는 전혀 적절하지 않을 수 있습니다. 예를 들어 512GB RAM 시스템, FusionIO 카드, 10Gig-E 네트워킹에 액세스할 수 있는 자체 데이터센터의 자체 물리적 하드웨어에서 실행하는 고객과 Amazon의 AWS 내에서 실행하는 고객 간의 차이를 생각해보십시오. 카우치베이스의 고객은 이 두 가지 극단적인 환경과 그 사이의 거의 모든 환경에 걸쳐 있으므로 구체적인 권장 사항을 제공하기가 얼마나 어려운지 알 수 있습니다.

가장 높은 수준에서 Couchbase는 "상용 하드웨어"에서 실행되도록 설계 및 테스트되었습니다. 위에서 알 수 있듯이 "상품"은 사람마다 다른 의미를 갖습니다. 저는 항상 고객에게 어떤 유형의 하드웨어 프로필을 사용할 수 있는지, 원하거나 계획하고 있는지 물어봅니다. 그런 다음 수평적 확장성의 이점과 데이터 세트 및 워크로드를 지원하는 데 필요한 노드 수를 염두에 두고 클러스터의 크기를 결정합니다... 64GB RAM, 24코어 CPU, 2TB SSD를 갖춘 HP DL 380 6대가 반드시 필요하다고 말하는 것과는 반대로 말이죠. 하드웨어 권장 사항은 데이터 세트와 워크로드 요구 사항, 사용 가능한 리소스, 비용의 교차점에서 결정됩니다. 문서에서도 이에 대해 간략하게 설명합니다: 리소스 요구 사항

면책 조항은 이제 그만하고 세부 사항을 살펴 보겠습니다. 이 시리즈의 이전 파트에서는 Couchbase 크기 조정의 5가지 요소를 나열했습니다:

1. RAM
2. 디스크
3. CPU
4. 네트워크
5. 데이터 배포

가장 쉬운 것(맨 아래)부터 시작해서 차근차근 설명해 드리겠습니다.

1. 데이터 배포

가장 쉽습니다 :-) Couchbase의 프로덕션 배포에는 3개 이상의 노드가 있어야 합니다. 그 이유는 자동 장애 조치의 안전성, 업그레이드의 용이성 및 추가 확장을 위해서입니다.

2. 네트워크

두 번째로 쉬운 방법 :-S. 일반적으로 사용 가능한 네트워크 유형에 대한 선택의 폭이 거의 없습니다. 요즘에는 1Gig-E 이상의 네트워크만 있으면 Couchbase에 충분합니다. 애플리케이션이 특히 지연 시간에 민감하거나 매우 높은 처리량이 필요한 경우 다음과 같은 엔드투엔드 연결의 이점을 누릴 수 있습니다. 10Gig-E.

방화벽과 라우터 측면에서 카우치베이스 노드와 클라이언트 사이에 "홉"을 최대한 적게 배치하세요. 중간에 방화벽과 라우터가 필요하다면 지연 시간이 영향을 받을 수 있다는 점을 알아두세요.

설정할 때 XDCR를 사용하면 네트워크 가변성이 커지지만 해당 기능을 설계한 방식에 따라 그 중요성이 떨어집니다.

3. 3.

카우치베이스는 각 코어의 속도보다는 CPU 코어 수에 더 중점을 둡니다(2.4GHz 대 2.6GHz 대 3.0GHz 대 인텔 대 AMD는 차이가 없습니다). 카우치베이스는 다양한 방식으로 멀티스레드를 지원하며 많은 코어를 사용하지만 32개 또는 64개 이상의 코어가 반드시 필요한 것도 아닙니다(대부분의 사람들은 이러한 코어가 "상품"이 아니라는 데 동의할 것입니다). 기본 워크로드를 위해 4개의 코어로 시작한 다음 뷰 및 XDCR에 필요한 만큼 코어를 추가하세요. 자세한 내용은 이전 파트 에서 자세한 내용을 확인하세요.

4. 디스크

이것은 큰 일이 될 것입니다. Couchbase는 데이터베이스이지만 다른 데이터베이스와는 다릅니다. Oracle/MySQL/Postgres가 디스크 성능에 크게 의존하는 반면, Couchbase는 주 애플리케이션 성능과 디스크 IO를 분리하므로 요구 사항이 훨씬 낮습니다. 낮지만 존재하지 않는 것은 아닙니다.

• 사용 가능한 최상의 '로컬' 저장소를 사용하세요.  저희의 모범 사례와 아키텍처는 분산 시스템을 중심으로 합니다. SAN이나 NAS와 같은 중앙 집중식 백엔드 스토리지 시스템을 사용하지 않는 것이 좋습니다. 이러한 시스템은 성능 요구 사항을 충족할 수 있지만, 단일 병목 지점/장애 지점(HA가 있더라도)이 존재하여 Couchbase의 분산 특성을 제한할 수 있습니다. 공유 스토리지의 이점이 이보다 더 클 수도 있지만 고려해야 할 사항입니다.
• EBS < 가상 드라이브 < 7200 < 10K < SSD < FusionIO: 나중에 클라우드 및 가상 머신 하드웨어 고려 사항에 대해 설명하겠지만, 디스크가 빠를수록 더 빠르다는 것은 당연한 이치입니다. 일반적으로 EBS의 경우 노드당 초당 쓰기 횟수는 약 1000회 이하, 10K 드라이브의 경우 약 1500회, SSD의 경우 6000회를 훨씬 넘습니다. 노드당 초당 3만 건이 넘는 쓰기 속도도 본 적이 있습니다... 상황에 따라 다르다는 것을 알 수 있습니다. 워크로드가 (디스크에서) 대량 읽기, 지속적인 쓰기, 인덱스 업데이트 및/또는 XDCR을 위해 디스크 성능에 크게 의존하는 경우 디스크 계층에 대해 더 많이 고려해야 할 것입니다. "무거운"이라는 용어가 매우 모호한 용어라는 것을 알고 있지만, 다른 표현이 없으므로 애플리케이션에 대한 구체적인 세부 정보를 얻으려면 여기 Couchbase 엔지니어링 및 현장 팀의 전문 지식을 활용하는 것 외에는 권장할 수 있는 방법이 없습니다.
• RAID 는 필수 사항은 아니지만 표준 배포 구성을 사용하는 경우 일반적으로 RAID 0 또는 10이 1 또는 5보다 낫습니다. Couchbase에는 이미 클러스터 전체에 복제본이 있으므로 더 나은 중복성을 위해서가 아니라 처리량과 지연 시간을 개선하기 위해 RAID를 사용하는 것이 좋습니다. 사용 가능한 디스크 드라이브와 공간이 있고 노드당 대용량의 데이터(100GB 이상)를 저장하는 경우에는 디스크 장애 시 장애 조치 및 재밸런싱을 방지하기 위해 RAID 5가 실제로 유용할 수 있습니다.
• 보기에 의존하는 경우 최상의 성능과 효율성을 위해 두 개의 별도 디스크를 만들고 데이터와 보기를 디스크 간에 분할하는 것이 좋습니다. 보기에 대한 자세한 내용은 이 시리즈의 이전 파트.
• 디스크 공간은 일반적으로 저렴하므로 여유가 있는 만큼 확보하세요. 내 이전 게시물 를 참조하여 첨부 전용 파일 형식과 압축을 고려해야 하는 방법을 알아보세요.

5. RAM

이것도 사실 꽤 쉽습니다... 일반적으로 클러스터 전체에 걸쳐 가능한 한 많은 RAM을 확보합니다(크기 계산 요구 사항에 따라). Couchbase의 최적 용량은 일반적으로 노드당 약 8GB-128GB입니다. 물론 예외가 있긴 하지만 8보다 낮으면 헤드룸이나 디스크 캐싱에 사용할 수 있는 공간이 많이 남지 않고 128보다 높으면 한 노드의 가용성과 사용 가능한 리소스에 매우 많은 양의 데이터를 책임지기 시작합니다.

몇 가지 다른 고려 사항도 있습니다:

• 사용 가능한 메모리를 모두 사용하는 것이 직관적으로 보일 수 있지만, 실제로는 Couchbase 할당량 외의 RAM을 일부 남겨 두는 것이 가장 좋습니다. 대부분의 최신 운영 체제는 몇 기가바이트(Windows는 일반적으로 Linux보다 약간 더 많음)를 필요로 하며, 이러한 노드에서 모니터링 에이전트와 같은 다른 프로세스가 실행되고 있을 수 있습니다. 또한 보기와 시스템의 일반적인 기능 모두를 위해 IO 캐싱이 필요합니다. 일반적으로 시스템 RAM의 약 60-80%를 Couchbase의 할당량에 할당하고 나머지는 Couchbase 자체 외부의 헤드룸 및 메모리 요구 사항을 위해 남겨 두는 것이 좋습니다.
• 3x64GB보다는 6x32GB 노드를 사용하는 것이 좋습니다.
• 다른 유형의 RAM이나 속도 간에는 눈에 띄는 차이가 없습니다.
• Linux(가장 효율적이고 최대의 RAM 사용 보장):
  • 5~10GB의 스왑 공간을 구성합니다. 이 공간을 사용할 일은 없겠지만, 어느 정도의 안전망이 필요합니다. Linux OOM 킬러
  • THP(투명한 거대한 페이지, 익명 하이게 페이지라고도 함)를 비활성화합니다. 경우에 따라 유용할 수 있지만, 이 기능이 켜져 있는 고객들에게서 문제가 발생하는 경우가 있었습니다(THP 비활성화에 대한 지침은 사용 중인 운영 체제 및 버전을 참조하세요).
  • 스왑을 0으로 설정
  • 최근 증거에 따르면 NUMA 시스템에서 영역 회수 기능을 비활성화하는 것이 도움이 될 수 있습니다(http://engineering.linkedin.com/performance/optimizing-linux-memory-management-low-latency-high-throughput-databases).

"콜로케이션"

애플리케이션과 동일한 서버에서 Couchbase를 실행해도 되는지 묻는 질문을 많이 받습니다. 기술적인 제한은 없지만 몇 가지 이유 때문에 권장하지 않는 것이 좋습니다:

• 다른 기술의 요구 사항을 고려하면 사이징 계산은 더욱 복잡해집니다.
• 대부분의 다른 애플리케이션은 실제로 하드웨어/크기 요구 사항이 Couchbase와 다르므로 리소스를 필요한 곳에 할당할 수 있는 기능은 리소스를 분할하여 사용하는 이점이 있습니다.
• 확장은 더욱 복잡해집니다. 동일한 서버에서 실행되는 3노드의 Couchbase가 있는 3노드 애플리케이션 팜을 상상해 보세요. 이제 애플리케이션을 확장하고 싶지만 Couchbase를 함께 확장할 필요는 없습니다. 5개의 애플리케이션 서버가 있고 그 중 3개만 Couchbase가 실행되고 있나요?
• 관리가 더 어렵습니다. 위와 동일한 환경...이제 애플리케이션 티어를 재부팅해야 하지만 Couchbase가 함께 다운되는 것을 원하지 않습니다.

VM으로 전환할 것인가, VM으로 전환하지 않을 것인가?

물리적 하드웨어가 최고의 성능과 가장 효율적인 리소스 사용을 제공한다는 것은 누구나 알고 있는 사실입니다. 하지만 Couchbase 고객의 상당수가 가상 머신을 사용하고 있으며, 이러한 배포를 테스트하고 지원합니다. 몇 가지 유의해야 할 사항이 있습니다:

• 다른 애플리케이션으로 호스트 머신을 과도하게 커밋하지 마세요. 특히 CPU와 RAM을 과도하게 커밋하면 매우 예상치 못한(그리고 진단하기 어려운) 결과가 발생할 수 있습니다. 이 중 일부는 가상 머신 호스트의 실제 설정으로 제어할 수 있으며(예: RAM), 일부는 모범 사례(예: 물리적 코어보다 더 많은 가상 CPU를 할당하지 않음)입니다.
• VM을 사용하면 네트워크 속도가 약간 느려질 수 있습니다... 눈에 띄지는 않지만 효과가 있습니다.
• CPU 및 RAM에도 동일한 수치 요구 사항이 적용됩니다.
• 분산 환경에서는 위와 같은 이유로 로컬 스토리지가 공유 SAN으로 돌아가는 것보다 낫습니다.
• 노드가 많으면 많을수록 좋다는 일반적인 조언은 VM에서 더욱 강력합니다.
• 물리적 머신당 Couchbase 노드가 두 개 이상 있지 않은지 확인하세요.
• 비프로덕션 환경에서는 위의 사항 중 일부를 희생할 수 있지만 성능이나 안정성 문제가 발생할 수 있다는 점을 염두에 두세요. 테스트, UAT 및/또는 스테이징에서 동일한 프로덕션 데이터 세트와 동일한 워크로드를 사용할 계획이라면 해당 환경에서도 동일한 리소스 요구 사항이 있을 것입니다.
• 가상화 기술 선택에는 차이가 없는 것 같습니다.

클라우드에서...

여기서 말하는 '클라우드'는 모든 구성 요소에 대해 하드웨어와 소프트웨어가 완전히 분리된 배포 환경을 의미하며, 단순히 가상 머신에서 실행되는 것과는 다릅니다. 저희 고객 중 약 50%가 Amazon에 배포되어 있습니다. 그 외 몇몇은 GAE/Rackspace/Softlayer/Savvis 등 다른 클라우드 공급업체를 이용하고 있으며, 일부는 자체 프라이빗 클라우드를 운영하고 있습니다. 처음부터의 주제에 따라, 저는 어떤 인프라에 Couchbase를 배포해야 하는지 말씀드릴 수 있는 입장이 아니므로 고객 여러분이 직접 말씀해주셔야 합니다.

클라우드에도 VM과 동일한 고려 사항이 대부분/전부가 적용되며, 다음과 같은 보다 구체적인 문서가 있습니다. 클라우드 고려 사항.

• RAM: 일반적으로 노드당 사용 가능한 RAM이 적습니다.
• 디스크: 단일 EBS 드라이브는 (잠재적으로 일관성 없이) 느립니다. 최상의 성능을 위해 노드당 4~6개의 드라이브로 구성된 LVM/스트라이프 레이드를 권장하며, 최적화된/프로비저닝된 IOPS EBS 드라이브를 고려하는 것이 좋습니다. EC2는 또한 SSD 기반 인스턴스를 제공하는데, 현재로서는 비용이 많이 들지만 성능을 위한 최고의 선택이 될 수 있습니다. 설치 디렉터리, 데이터 파일 디렉터리, 보기/색인 디렉터리의 디스크 유형을 '선택'할 수 있다는 점도 기억하세요.
• 데이터 배포: 다시 말하지만, 노드를 적게 사용하는 것보다 더 많이 사용하도록 계획하세요.
• 가용성 영역: 아직 랙이나 영역에 걸쳐 Couchbase를 배포하는 데 특별한 기능은 없지만(곧 추가될 예정), 클러스터를 여러 영역으로 분할하는 것이 좋습니다. 이렇게 하면 한 구역에 장애가 발생해도 전체 데이터 세트를 사용할 수 없게 되지 않습니다. 추가적인 복원력을 제공하기 위해 영역 간에 XDCR을 사용하는 것도 좋은 고려 사항일 수 있습니다.

"스케일업" 대 "스케일아웃"

리밸런싱을 통한 Couchbase의 탄력성은 소프트웨어뿐만 아니라 하드웨어의 원활한 유지 관리와 업그레이드를 가능하게 합니다. 더 높은 용량의 새 노드를 추가하고 더 낮은 용량의 구형 노드와 교체함으로써 실행 중인 애플리케이션의 성능이나 데이터 가용성 손실 없이 수직적 확장성을 달성할 수 있습니다.

노드 용량을 늘려야 하는 시기는 사용 사례, 리소스 가용성, 기본 비용 변수에 따라 달라집니다. 극단적인 예로, 매우 강력한 하드웨어를 1, 2 또는 3노드로 구성하는 것은 권장하지 않으며, 아주 작은 노드 1,000개도 권장하지 않습니다. 몇 가지 일반적인 경험 법칙은 다음과 같습니다:

1. 규모 out 노드 크기를 약 15~20개까지 가능한 가장 작은 노드로 설정한 다음 고려 스케일링 up 노드 수를 줄이기 위해
2. 확장할 때 노드 수가 6 이하로 줄어드는 하드웨어를 선택하지 마세요...위의 #1을 헹구고 반복하세요.
3. 워크로드가 메모리에 묶여 있는 경우, 디스크 처리량에 비해 노드 수를 줄이는 데 주의해야 합니다. 각 노드가 보유한 RAM이 많을수록 정상 상태 워크로드, 압축, 특히 리밸런싱 등을 위해 각 노드에 더 많은 디스크 IO가 필요하게 됩니다.
4. 워크로드가 디스크에 묶여 있는 경우, 각 노드의 디스크 성능을 점진적으로 늘리기보다는 워크로드를 분산할 노드를 더 많이 확보하는 것이 좋습니다.

이에 대한 좋은 예로 최근 쓰기 작업량이 많아 32노드의 스피닝 디스크 사이징이 필요했던 한 고객이 있습니다. 이 고객은 SSD를 사용하여 이를 9개로 줄일 수 있었으며, 이는 위의 #1 및 #2에 잘 맞고 SSD의 비용을 쉽게 상쇄할 수 있었습니다.

요약

우선 최소 하드웨어 요구 사항은 다음과 같아야 합니다:

• 3 노드
• 4GB 이상의 RAM
• CPU 코어 4개(버킷당 +1, 디자인 문서당 +1, XDCR 스트림당 +1, 기본값인 3개를 초과하는 리더/라이터 작업자당 +1)
• 사용 가능한 최고의 '로컬' 스토리지
• 지연 시간이 가장 짧고 처리량이 가장 많은 네트워크

결국, 전체 아키텍처는 전력(및 비용)이 많이 드는 노드를 적게 배치하는 것보다 용량/전력이 낮은 노드를 많이 배치하는 것이 훨씬 더 나은 결과를 가져올 수 있습니다.

확실하지 않은 경우, 카우치베이스 현장 팀이 귀하의 환경을 평가하고 특정 요구 사항에 대한 지침을 제공할 수 있다는 점을 기억하세요. 최대한 원활하게 제품을 사용할 수 있도록 최선을 다하고 있습니다.

에서 다음 및 네 번째 항목 이 시리즈에서는 Couchbase Server 클러스터의 적절한 사이징을 이해하기 위한 다양한 메트릭과 모니터링 사례에 대해 설명합니다.