다음을 통해 공유


Azure Managed Instance for Apache Cassandra와 Azure Cosmos DB for Apache Cassandra의 차이점

이 문서에서는 Azure Managed Instance for Apache CassandraRU 기반 Azure Cosmos DB for Apache Cassandra 간의 차이점을 알아봅니다. 이 문서에서는 두 서비스 중에 선택하는 방법 또는 고객 고유의 Apache Cassandra 환경을 호스트해야 하는 시기에 대한 권장 사항을 제공합니다.

주요 차이점

Azure Managed Instance for Apache Cassandra는 순수 오픈 소스 Apache Cassandra 클러스터를 위한 완전 관리형 서비스입니다. 또한 이 서비스를 사용하면 각 워크로드의 특정 요구 사항에 따라 구성을 재정의할 수 있으므로 필요한 경우 최대한의 유연성과 제어가 가능합니다. 또한 기존 온-프레미스 또는 클라우드 자체 호스팅 Apache Cassandra 클러스터의 용량을 스케일 아웃하는 기능을 제공합니다. 기존 클러스터 링에 관리형 Cassandra 데이터 센터를 추가하는 방법으로 스케일 아웃합니다.

Azure Cosmos DB의 RU 기반 Azure Cosmos DB for Apache Cassandra는 Microsoft의 전 세계적으로 분산된 클라우드 기반 데이터베이스 서비스인 Azure Cosmos DB에 대한 호환성 계층입니다.

선택 방법

다음 표에서는 각 배포 방법에 적합한 일반적인 시나리오, 워크로드 요구 사항 및 목표를 보여줍니다.

온-프레미스 또는 Azure의 자체 호스팅 Apache Cassandra Apache Cassandra용 Azure Managed Instance Azure Cosmos DB for Apache Cassandra
배포 유형 사용자 지정 패치 또는 snitch를 사용하여 고도로 사용자 지정된 Apache Cassandra 배포가 있습니다. 사용자 지정 코드가 없는 표준 오픈 소스 Apache Cassandra 배포가 있습니다. Apache Cassandra에 종속된 것이 아니라 유선 프로토콜 수준에서 모든 오픈 소스 클라이언트 드라이버와 호환되는 플랫폼을 원합니다.
운영 오버헤드 클러스터를 배포, 구성 및 유지 관리할 수 있는 기존 Cassandra 전문가가 있습니다. 오픈 소스 Apache Cassandra에 대해 완전 관리형 서비스로서의 데이터베이스를 사용하여 운영 오버헤드를 제거하고 싶지만 필요할 경우 복제 및 일관성과 같은 Cassandra 관련 구성을 제어할 수 있는 옵션이 있습니다. 클라우드에서 완전 관리형 Platform-as-as-Service 데이터베이스를 사용하여 운영 오버헤드를 제거하려고 합니다.
제품 지원 컴퓨팅, 네트워킹, 스토리지 등에 대한 관련 인프라 팀에 연락하는 것을 포함하여 실시간 인시던트 및 중단을 직접 처리합니다. 실시간 인시던트 및 중단을 지원하기 위한 원스톱 상점 역할을 하는 자사 관리되는 서비스 환경이 필요합니다. 사용자는 실시간 인시던트 및 중단에 대한 원스톱 상점 역할을 할 자사 관리되는 서비스 환경을 원합니다.
소프트웨어 지원 모든 패치를 처리하고 수명이 끝나기 전에 소프트웨어가 업그레이드되었는지 확인합니다. 주 버전에 대한 라이브 종료, 자동화된 패치 및 턴키 업그레이드를 넘어 Cassandra 소프트웨어 수준 지원을 제공하는 자사 관리되는 서비스 환경을 원합니다. 소프트웨어 수준 지원이 완전히 추상화된 자사 관리되는 서비스 환경을 원합니다.
운영 체제 요구 사항 사용자 지정 또는 최적의 Virtual Machine 운영 체제 이미지를 유지하기 위해 충족해야 하는 요구 사항이 있습니다. Vanilla 이미지를 사용할 수 있지만 SKU, 메모리, 디스크 및 IOPS 선택을 제어하려고 합니다. Azure Cosmos DB의 요청 단위처럼 처리량에 대한 일대일 관계를 사용하여 용량 프로비저닝을 단순화하고 정규화된 단일 메트릭으로 표현하고 싶습니다.
가격 책정 모델 Datastax 도구와 같은 관리 소프트웨어를 원하며 라이선스 비용에 만족합니다. 순수한 오픈 소스 라이선스 및 VM 인스턴스 기반 가격 책정을 선호합니다. 자동 스케일링서버리스 제품이 포함된 클라우드 기본 가격 책정을 사용하려 합니다.
분석 분석 파이프라인을 빌드하고 유지 관리하기 위한 오버헤드에 관계 없이 분석 파이프라인 프로비저닝을 완벽하게 제어할 수 있기를 원합니다. Azure Databricks와 같은 클라우드 기반 분석 서비스를 원합니다. Azure Cosmos DB용 Azure Synapse Link를 통해 플랫폼에 기본 제공되는 거의 실시간 하이브리드 트랜잭션 분석을 원합니다.
워크로드 패턴 워크로드가 매우 안정적인 상태이며 클러스터에서 스케일링을 자주 할 필요가 없습니다. 워크로드가 일정하지 않기 때문에 간편하게 데이터 센터의 노드를 스케일 업 또는 스케일 다운하거나 데이터 센터를 추가/제거할 수 있어야 합니다. 워크로드가 일정하지 않은 경우가 많기 때문에 신속하게 대량으로 스케일 업 또는 스케일 다운할 수 있어야 합니다.
SLA 일관성, 처리량, 가용성 및 재해 복구에 대한 SLA를 유지 관리하는 현재 프로세스에 만족합니다. 일관성 및 처리량에 대한 SLA를 유지하는 프로세스에 만족하지만 가용성을 위한 SLA를 원하고 백업에 대한 도움이 필요합니다. 일관성, 처리량, 가용성 및 재해 복구에 대한 완전히 포괄적인 SLA를 원합니다.
복제 및 일관성 읽기 및 쓰기 경로에 대해 Apache Cassandra에서 사용할 수 있는 조정 가능한 일관성 설정의 전체 배열을 구성할 수 있어야 합니다. 읽기 및 쓰기 경로에 대해 Apache Cassandra에서 사용할 수 있는 조정 가능한 일관성 설정의 전체 배열을 구성할 수 있어야 합니다. 모든 애플리케이션에 대해 ONE(최종) 또는 ALL(강함)의 읽기 경로 일관성이면 충분합니다(Cassandra 일관성 수준 매핑 참조).
데이터 모델 데이터의 균일한 배포와 왜곡된 데이터(파티션 키 전체의 스토리지 및 처리량 모두와 관련하여)가 혼합되어 노드의 수직 크기 조정에 대한 유연성이 필요한 워크로드를 마이그레이션하고 있습니다. 데이터의 균일한 배포와 왜곡된 데이터(파티션 키 전체의 스토리지 및 처리량 모두와 관련하여)가 혼합되어 노드의 수직 크기 조정에 대한 유연성이 필요한 워크로드를 마이그레이션하고 있습니다. 새 애플리케이션을 빌드 중이거나 기존 애플리케이션이 파티션 키 전체의 스토리지 및 처리량과 관련하여 비교적 균일한 데이터 배포를 갖고 있습니다.

다음 단계