Azure Managed Instance for Apache Cassandra는 순수 오픈 소스 Apache Cassandra 클러스터를 위한 완전 관리형 서비스입니다. 이 서비스를 사용하면 각 워크로드의 요구 사항에 따라 구성을 재정의할 수 있으므로 필요한 경우 최대한의 유연성과 제어가 가능합니다.
Apache Cassandra는 분산된 특성 및 피어 투 피어 아키텍처로 인해 복원력이 뛰어난 애플리케이션을 빌드하는 데 적합합니다. 데이터베이스의 모든 노드는 다른 노드와 동일한 기능을 제공할 수 있습니다. 이 디자인은 Cassandra의 견고성과 복원력에 기여합니다. 이 문서에서는 고가용성을 최적화하는 방법과 재해 복구에 접근하는 방법에 대한 팁을 제공합니다.
복구 지점 목표 및 복구 시간 목표
다음 요소가 있는 한 RPO(복구 지점 목표) 및 RTO(복구 시간 목표)는 모두 일반적으로 낮고 0에 가깝습니다.
- 지역 간 복제 및 복제 계수가 3인 다중 지역 배포
- 가용성 영역을 사용하도록 설정했습니다. Azure Portal에서 또는 Azure CLI를 사용하여 클러스터를 만들 때 이 옵션을 구성합니다.
- Azure Traffic Manager 또는 Azure Front Door를 사용한 부하 분산 수준 장애 조치(failover)나 클라이언트 드라이버에서 부하 분산 정책을 사용하여 애플리케이션 수준 장애 조치(failover)를 구성했습니다.
RTO는 가동 중단 시간입니다. 클러스터는 영역과 지역 모두에서 복원력이 있기 때문에 낮습니다. 또한 Apache Cassandra 자체는 모든 노드가 기본적으로 작성할 수 있는 매우 내결함성이 뛰어난 피어 투 피어 시스템입니다.
RPO는 중단으로 손실될 수 있는 데이터의 양입니다. 데이터가 모든 노드와 데이터 센터 간에 동기화되기 때문에 낮습니다. 가동 중단으로 데이터가 손실되는 경우는 최소화됩니다.
참고 항목
CAP 정리당 RTO=0 및 RPO=0을 모두 달성할 수 없습니다. 일관성과 가용성 또는 최적 성능 간의 절충을 평가합니다.
이 잔액은 애플리케이션마다 다르게 보입니다. 예를 들어 애플리케이션을 많이 읽는 경우 데이터 손실을 방지하기 위해 지역 간 쓰기의 대기 시간 증가에 대처하는 것이 더 나을 수 있습니다. 이는 일관성을 선호합니다. 애플리케이션이 긴 대기 시간 요구 사항으로 쓰기가 많은 경우 주요 지역 가동 중단에서 가장 최근의 쓰기 중 일부를 잃을 위험이 허용될 수 있으며 이는 가용성을 선호합니다.
가용성 영역
Cassandra의 피어 투 피어 아키텍처는 처음부터 내결함성을 제공합니다. Apache Cassandra용 Azure Managed Instance는 선택한 지역의 가용성 영역에 대한 지원을 제공합니다. 이 지원은 인프라 수준에서 복원력을 향상시킵니다. 3의 복제 요소에 대해 가용성 영역 지원은 각 복제본이 다른 가용성 영역에 있는지 확인합니다. 이 방법은 영역 중단이 데이터베이스 또는 애플리케이션에 영향을 주지 않도록 방지합니다. 가능한 경우 가용성 영역을 사용하도록 설정하는 것이 좋습니다.
다중 지역 중복성
Cassandra의 아키텍처는 Azure 가용성 영역 지원과 함께 내결함성 및 복원력 수준을 제공합니다. 또한 애플리케이션에 대한 지역 중단의 영향을 고려합니다. 지역 수준 중단을 방지하려면 여러 지역 클러스터를 배포하는 것이 좋습니다. 드물기는 하지만 잠재적 영향이 심각합니다.
비즈니스 연속성을 위해 여러 지역 데이터베이스를 사용하는 것으로는 충분하지 않습니다. 애플리케이션의 다른 부분도 적절히 분산 배포되거나 장애 조치 메커니즘이 충분히 갖춰져야 합니다. 사용자가 여러 지리적 위치에 분산되어 있는 경우 데이터베이스에 대한 여러 지역 데이터 센터 배포는 대기 시간을 줄이는 추가적인 이점이 있습니다. 클러스터 전체의 모든 데이터 센터의 모든 노드는 가장 가까운 지역의 읽기 및 쓰기를 모두 제공할 수 있습니다.
애플리케이션이 활성-활성으로 구성된 경우 CAP 정리가 복제본(노드) 간 데이터 일관성에 어떻게 적용되는지와, 고가용성을 제공하기 위해 필요한 절충을 고려하십시오.
CAP 정리 용어에서 Cassandra는 기본적으로 AP(사용 가능한 파티션 내성) 데이터베이스 시스템으로, 튜닝 가능한 일관성이 높습니다. 대부분의 사용 사례에서는 읽기에 LOCAL_QUORUM 사용하는 것이 좋습니다.
쓰기에서 액티브-패시브의 경우 안정성과 성능 간에 균형이 필요합니다. 안정성을 위해 QUORUM_EACH를 권장하지만, 대부분의 사용자에게는 LOCAL_QUORUM 또는 QUORUM이 좋은 타협입니다. 지역 가동 중단이 있는 경우 LOCAL_QUORUM 일부 쓰기가 손실될 수 있습니다.
애플리케이션이 병렬로 실행되는 경우 대부분의 경우 QUORUM_EACH 쓰기를 선호하여 두 데이터 센터 간의 일관성을 보장합니다.
대기 시간이나 가용성보다는 일관성을 선호하거나 RPO를 낮추거나 RTO를 낮추는 것이 목표인 경우 일관성 설정 및 복제 요소는 이 목표를 반영해야 합니다.
일반적으로 읽기에 필요한 쿼럼 노드 수와 쓰기에 필요한 쿼럼 노드 수는 복제 요소보다 커야 합니다. 예를 들어 복제 계수가 3이고 읽기에 quorum_one(노드 1개)인 경우, 쓰기에서 quorum_all(노드 3개)을 수행해야 합계 4가 복제 계수 3보다 큽니다.
참고 항목
Apache Cassandra용 Azure Managed Instance에 대한 제어 평면 연산자는 단일 지역에만 배포됩니다. 지역은 첫 번째 데이터 센터를 배포할 때 선택한 지역입니다. 전체 지역 가동 중단이 발생할 가능성이 낮을 경우 제어 평면을 다른 지역으로 장애 조치(failover)하기 위해 3시간의 복구 시간을 커밋합니다.
데이터 센터는 계속 작동해야 하므로 이 문제는 서비스의 가용성 SLA 에 영향을 주지 않습니다. 이 기간 동안 Azure Portal 또는 리소스 공급자 도구에서 데이터베이스 구성을 변경하지 못할 수 있습니다.
복제
데이터 센터 간에 필요한 복제가 올바르게 구성되었는지 확인하기 위해, keyspaces 및 그들의 복제 설정을 수시로 감사할 것을 권장합니다. 개발 초기 단계에서는 .를 사용하여 cqlsh간단한 테스트를 수행하는 것이 좋습니다. 예를 들어 한 데이터 센터에 연결된 동안 값을 삽입하고 다른 데이터 센터에서 읽습니다.
특히 기존 데이터 센터에 이미 데이터가 있는 두 번째 데이터 센터를 설정할 때 모든 데이터를 복제하고 시스템이 준비되었는지 확인합니다. DBA 명령을 사용하여 복제 진행 상황을 모니터링하는 것을 권장합니다 nodetool netstats. 다른 방법은 각 테이블의 행 수를 계산하는 것입니다. Cassandra의 분산 특성으로 인해 빅 데이터 크기로 인해 이 접근 방식은 대략적인 예상치만 제공할 수 있습니다.
재해 복구 비용 조정
애플리케이션이 활성-수동인 경우 일반적으로 각 지역에 동일한 용량을 배포하는 것이 좋습니다. 이 접근 방식을 사용하면 애플리케이션이 보조 지역의 핫 스탠바이 데이터 센터로 즉시 장애 조치(failover)됩니다. 지역 가동 중단이 발생하는 경우 이 방법은 성능 저하를 보장하지 않습니다. 대부분의 Cassandra 클라이언트 드라이버는 애플리케이션 수준 장애 조치(failover)를 시작하는 옵션을 제공합니다. 기본적으로 지역 가동 중단은 애플리케이션도 중단되었으므로 부하 분산 장치 수준에서 장애 조치(failover)가 발생해야 한다고 가정합니다.
두 번째 데이터 센터를 프로비전하는 비용을 줄이려면 보조 지역에 더 작은 SKU 및 더 적은 노드를 배포하는 것이 좋습니다. 가동 중단이 발생하면 Apache Cassandra용 Azure Managed Instance에서 턴키 세로 및 수평 크기 조정 을 통해 더 쉽게 확장할 수 있습니다. 애플리케이션이 보조 지역으로 장애 조치(failover)되는 동안 보조 데이터 센터에서 노드를 수동으로 추가 확장하고, 용량을 증설할 수 있습니다. 보조 데이터 센터는 비용이 적게 드는 웜 스탠바이 역할을 합니다. 가동 중단이 발생할 경우 시스템을 전체 용량으로 복원하는 데 필요한 시간과 균형을 유지해야 합니다. 지역이 손실되면 어떤 일이 일어나는지 테스트하고 연습하는 것이 중요합니다.
참고 항목
노드를 스케일 업하는 것은 스케일 아웃보다 훨씬 빠릅니다. 수직 규모와 수평 확장 간의 균형과 클러스터에 배포할 노드 수를 고려할 때 이 사실을 염두에 두어야 합니다.
백업 일정
백업은 Apache Cassandra용 Azure Managed Instance에서 자동으로 수행됩니다. 매일 백업에 대한 고유한 일정을 선택할 수 있습니다. 부하가 적은 시간을 선택하는 것이 좋습니다. 백업은 유휴 CPU만 사용하도록 구성되지만, 경우에 따라 Cassandra에서 압축을 트리거하여 CPU 사용량이 증가할 수 있습니다. 압축은 언제든지 Cassandra에서 발생할 수 있습니다. 워크로드 및 선택한 압축 전략에 따라 달라집니다.
중요합니다
백업의 의도는 실수로 인한 데이터 손실 또는 데이터 손상을 완화하기 위한 것입니다. 백업을 재해 복구 전략으로 사용하는 것은 권장하지 않습니다.
백업은 지역 중복되지 않습니다. 이 경우에도 백업에서 데이터베이스를 복구하는 데 시간이 오래 걸릴 수 있습니다. 따라서 가능한 경우 가용성 영역을 사용하도록 설정하고 재해 시나리오를 완화하고 효과적으로 복구할 수 있도록 여러 지역 배포를 권장합니다. 이 방법은 실패한 지역을 복구할 수 없는 드문 시나리오에서 특히 중요합니다. 다중 지역 복제가 없으면 모든 데이터가 손실될 수 있습니다.
