Apache Cassandra에서 가져온 경우 Azure Cosmos DB for Apache Cassandra에 맞게 조정하는 방법

  • 아티클

적용 대상: Cassandra

Azure Cosmos DB for Apache Cassandra는 기존 Cassandra SDK 및 도구와의 유선 프로토콜 호환성을 제공합니다. 최소한의 변경으로 API for Cassandra를 사용하여 Apache Cassandra에 연결하도록 설계된 애플리케이션을 실행할 수 있습니다.

API for Cassandra를 사용하는 경우 Apache Cassandra와 Azure Cosmos DB 간의 차이점을 알고 있어야 합니다. 네이티브 Apache Cassandra에 익숙한 경우 이 문서가 Azure Cosmos DB for Apache Cassandra 사용을 시작하는 데 도움이 될 수 있습니다.

기능 지원

API for Cassandra는 많은 Apache Cassandra 기능을 지원합니다. 일부 기능은 지원되지 않거나 제한 사항이 있습니다. 마이그레이션하기 전에 필요한 기능이 지원되는지 확인해야 합니다.

복제

복제를 계획하는 경우 마이그레이션과 일관성을 모두 살펴봐야 합니다.

CQL(Cassandra Query Language) 이진 프로토콜 v4 유선 프로토콜을 통해 API for Cassandra와 통신할 수 있지만 Azure Cosmos DB는 자체 내부 복제 프로토콜을 구현합니다. 라이브 마이그레이션 또는 복제에는 Cassandra gossip 프로토콜을 사용할 수 없습니다. 자세한 내용은 이중 쓰기를 사용하여 Apache Cassandra에서 API for Cassandra로 라이브 마이그레이션을 참조하세요.

오프라인 마이그레이션에 대한 자세한 내용은 Azure Databricks를 사용하여 Cassandra에서 Azure Cosmos DB for Apache Cassandra 계정으로 데이터 마이그레이션을 참조하세요.

Apache Cassandra와 Azure Cosmos DB의 복제 일관성에 대한 접근 방식은 비슷하지만 차이점을 이해해야 합니다. 매핑 문서는 복제 일관성에 대한 Apache Cassandra 및 Azure Cosmos DB의 접근 방식을 비교합니다. 그러나 Azure Cosmos DB 일관성 설정을 구체적으로 검토하거나 간단한 Azure Cosmos DB 플랫폼의 일관성 설정 이해 동영상 가이드를 시청하는 것이 좋습니다.

API for Cassandra를 사용하는 경우 Apache Cassandra를 실행하는 기존 애플리케이션에 대한 코드를 크게 변경할 필요가 없습니다. Azure Cosmos DB의 API for Cassandra에 대한 몇 가지 접근 방식 및 구성 설정을 사용하는 것이 좋습니다. Java용 API for Cassandra 권장 사항 블로그 게시물을 검토하세요.

코드 샘플

API for Cassandra는 기존 애플리케이션 코드에서 작동하도록 설계되었습니다. 연결 관련 오류가 발생하는 경우 빠른 시작 샘플을 시작점으로 사용하여 기존 코드에서 수행해야 할 수 있는 사소한 설정 변경 내용을 검색합니다.

또한 Java v3 및 Java v4 드라이버에 대한 더 심층적인 샘플이 있습니다. 이러한 코드 샘플은 사용자 지정 확장을 구현하며, 이는 차례로 권장 클라이언트 구성을 구현합니다.

Java Spring Boot(v3 드라이버) 및 Java Spring Boot(v4 드라이버)용 샘플을 사용할 수도 있습니다.

스토리지

API for Cassandra는 문서 지향 NoSQL 데이터베이스 엔진인 Azure Cosmos DB에서 지원됩니다. Azure Cosmos DB는 메타데이터를 유지 관리합니다. 이로 인해 특정 워크로드에 필요한 물리적 스토리지의 양이 변경될 수 있습니다.

네이티브 Apache Cassandra와 Azure Cosmos DB 간의 스토리지 요구 사항에 대한 차이는 작은 행 크기에서 가장 분명하게 드러납니다. 경우에 따라 Azure Cosmos DB에서 압축 또는 삭제 표시를 구현하지 않으므로 차이가 상쇄될 수 있습니다. 이 요소는 워크로드에 따라 크게 달라집니다. 스토리지 요구 사항이 확실하지 않은 경우 먼저 개념 증명을 만드는 것이 좋습니다.

다중 지역 배포

네이티브 Apache Cassandra는 기본적으로 다중 마스터 시스템입니다. Apache Cassandra에는 읽기 전용 다중 지역 복제가 있는 단일 마스터에 대한 옵션이 없습니다. 쓰기를 위한 다른 지역으로의 애플리케이션 수준 장애 조치(failover) 개념은 Apache Cassandra에서 중복됩니다. 모든 노드는 독립적이며 단일 실패 지점이 없습니다. 그러나 Azure Cosmos DB는 쓰기를 위해 단일 마스터 또는 다중 마스터 지역을 구성할 수 있는 기본 기능을 제공합니다.

쓰기를 위한 단일 마스터 지역을 갖는 장점은 영역 간 충돌 시나리오를 방지할 수 있다는 것입니다. 이는 고가용성 수준을 유지하면서 여러 지역에서 강력한 일관성을 유지할 수 있는 옵션을 제공합니다.

참고 항목

모든 노드에서 쓰기를 제공할 수 있으므로 네이티브 Apache Cassandra에서는 지역 간 강력한 일관성 및 0의 RPO(복구 지점 목표)를 사용할 수 없습니다. 단일 쓰기 지역 구성에서 지역 간 강력한 일관성을 유지하도록 Azure Cosmos DB를 구성할 수 있습니다. 그러나 네이티브 Apache Cassandra와 마찬가지로 강력한 일관성을 위해 여러 쓰기 지역으로 구성된 Azure Cosmos DB 계정을 구성할 수 없습니다. 분산 시스템은 0의 RPO 및 0의 RTO(복구 시간 목표)를 제공할 수 없습니다.

자세한 내용은 Java용 API for Cassandra 권장 사항 블로그에서 부하 분산 정책을 참조하세요. 또한 공식 Cassandra Java v4 드라이버용 코드 샘플에서 장애 조치(failover) 시나리오를 참조하세요.

요청 단위

네이티브 Apache Cassandra 클러스터 실행과 Azure Cosmos DB 계정 프로비전 간의 주요 차이점 중 하나는 데이터베이스 용량이 프로비전되는 방식입니다. 기존 데이터베이스에서 용량은 CPU 코어, RAM 및 IOPS로 표현됩니다. Azure Cosmos DB는 다중 테넌트 서비스로서의 플랫폼 데이터베이스입니다. 용량은 요청 단위라는 정규화된 단일 메트릭을 사용하여 표현됩니다. 데이터베이스에 전송되는 모든 요청에는 RU 비용(요청 단위 비용)이 있습니다. 각 요청을 프로파일링하여 비용을 확인할 수 있습니다.

요청 단위를 메트릭으로 사용하면 예측 가능한 성능과 효율성을 위해 데이터베이스 용량을 결정적으로 프로비전할 수 있다는 이점이 있습니다. 각 요청의 비용을 프로파일링하면 요청 단위를 사용하여 데이터베이스에 보낸 요청 수를 프로비전해야 하는 용량과 직접 연결할 수 있습니다. 용량을 프로비전하는 이 방법의 문제는 워크로드의 처리량 특성을 확실히 이해해야 한다는 것입니다.

요청을 프로파일링하는 것이 좋습니다. 이 정보를 사용하여 프로비전해야 하는 요청 단위의 수를 예측할 수 있습니다. 예측하는 데 도움이 되는 몇 가지 문서는 다음과 같습니다.

용량 프로비전 모델

기존 데이터베이스 프로비전에서는 예상 처리량을 처리하기 위해 고정 용량이 미리 프로비전됩니다. Azure Cosmos DB는 프로비전된 처리량이라는 용량 기반 모델을 제공합니다. 다중 테넌트 서비스인 Azure Cosmos DB는 자동 크기 조정 모드 및 서버리스 모드에서 사용량 기반 모델도 제공합니다. 워크로드에서 이러한 사용량 기반 프로비전 모델을 활용할 수 있는 정도는 워크로드에 대한 처리량의 예측 가능성에 따라 달라집니다.

일반적으로 처리량이 예측 가능한 안정 상태 워크로드는 프로비전된 처리량을 가장 효율적으로 활용할 수 있습니다. 유휴 기간이 긴 워크로드는 서버리스 모드를 활용할 수 있습니다. 지속적인 수준의 최소 처리량을 갖지만 예측할 수 없는 급증이 있는 워크로드는 자동 크기 조정을 가장 효율적으로 활용할 수 있습니다. 처리량 요구 사항에 가장 적합한 용량 모델을 명확하게 이해하려면 다음 문서를 검토하는 것이 좋습니다.

분할

Azure Cosmos DB의 분할은 Apache Cassandra의 분할과 비슷합니다. 주요 차이점 중 하나는 Azure Cosmos DB가 수평 크기 조정에 더 최적화되어 있다는 것입니다. Azure Cosmos DB에서는 모든 실제 파티션에서 사용할 수 있는 수직 처리량 용량에 제한이 있습니다. 이 최적화의 효과는 기존 데이터 모델에 상당한 처리량 편차가 있을 때 가장 분명하게 드러납니다.

파티션 키 설계로 인해 요청이 비교적 균일하게 분산되도록 조치를 취합니다. 논리 분할 및 실제 분할이 작동하는 방법 및 파티션당 처리량 용량 제한에 대한 자세한 내용은 Azure Cosmos DB for Apache Cassandra의 분할을 참조하세요.

확장

네이티브 Apache Cassandra에서 용량 및 크기 조정을 늘리려면 새 노드를 클러스터에 추가하고 해당 노드가 Cassandra 링에 적절하게 추가되었는지 확인해야 합니다. Azure Cosmos DB에서 노드 추가는 투명하고 자동으로 수행됩니다. 크기 조정은 키스페이스 또는 테이블에 프로비전된 요청 단위 수의 함수입니다. 물리적 컴퓨터의 크기 조정은 실제 스토리지 또는 필요한 처리량이 논리 파티션 또는 실제 파티션에 허용되는 제한에 도달할 때 수행됩니다. 자세한 내용은 Azure Cosmos DB for Apache Cassandra의 분할을 참조하세요.

속도 제한

특히 프로비전된 처리량을 사용하는 경우 요청 단위 프로비전의 문제는 속도 제한입니다. 클라이언트에서 프로비전한 양보다 많은 리소스를 사용하는 경우 Azure Cosmos DB는 속도 제한 오류를 반환합니다. Azure Cosmos DB의 API for Cassandra는 Cassandra 네이티브 프로토콜에서 이러한 예외를 오버로드된 오류로 변환합니다. 애플리케이션에서 속도 제한을 방지하는 방법에 대한 자세한 내용은 Azure Cosmos DB for Apache Cassandra 작업에 대한 속도 제한 오류 방지를 참조하세요.

Apache Spark 커넥터

대부분의 Apache Cassandra 사용자는 Apache Spark Cassandra 커넥터를 사용하여 분석 및 데이터 이동 요구 사항에 대한 데이터를 쿼리합니다. 동일한 커넥터를 사용하여 동일한 방식으로 API for Cassandra에 연결할 수 있습니다. API for Cassandra에 연결하기 전에 Spark에서 Azure Cosmos DB for Apache Cassandra에 연결을 검토하세요. 특히 Spark 커넥터 처리량 구성 최적화 섹션을 참조하세요.

일반적인 문제 해결

일반적인 문제에 대한 해결 방법은 Azure Cosmos DB for Apache Cassandra의 일반적인 문제 해결을 참조하세요.

다음 단계