고가용성 및 재해 복구 모범 사례

Azure Managed Instance for Apache Cassandra는 순수 오픈 소스 Apache Cassandra 클러스터를 위한 완전 관리형 서비스입니다. 또한 이 서비스를 사용하면 각 워크로드의 특정 요구 사항에 따라 구성을 재정의할 수 있으므로 필요한 경우 최대한의 유연성과 제어가 가능합니다.

Apache Cassandra는 분산되는 특성 및 마스터리스 아키텍처로 인해 복원력이 뛰어난 애플리케이션을 빌드하는 데 적합합니다. 데이터베이스의 모든 노드는 다른 노드와 정확히 동일한 기능을 제공하여 Cassandra의 견고성과 복원력에 기여합니다. 이 문서에서는 고가용성을 최적화하는 방법과 재해 복구에 접근하는 방법에 대한 팁을 제공합니다.

RPO 및 RTO

Apache Cassandra의 RPO(복구 지점 목표) 및 RTO(복구 시간 목표)는 다음과 같은 경우 일반적으로 낮습니다(0에 가까움).

• 지역 간 복제를 사용하는 다중 지역 배포, 복제 계수가 3인 경우
• 가용성 영역을 사용하는 경우(포털에서 또는 Azure CLI를 통해 클러스터를 만들 때 옵션 선택)
• 클라이언트 드라이버에서 부하 분산 정책을 사용하여 애플리케이션 수준 장애 조치(failover)를 구성한 경우 및/또는 트래픽 관리자/Azure Front Door를 사용하여 부하 분산 수준 장애 조치(failover)를 구성한 경우

클러스터가 영역과 지역 모두에서 복원력이 있고 Apache Cassandra 자체가 기본적으로 내결함성이 뛰어나고 마스터리스 시스템(모든 노드가 쓸 수 있음)이므로 RTO("중단 시 다운 시간")가 낮습니다. 모든 노드와 데이터 센터 간에 데이터가 동기화되기 때문에 RPO("중단 시 손실할 수 있는 데이터 양")가 낮아지므로 중단 시 데이터 손실이 최소화됩니다.

참고 항목

Cap 정리에 따르면 RTO=0 및 RPO=0을 모두 달성하는 것은 이론적으로 불가능합니다. 일관성과 가용성/최적 성능 간의 절충을 평가해야 하며, 이 절충은 각 애플리케이션마다 다릅니다. 예를 들어 애플리케이션이 읽기 작업이 많은 경우 데이터 손실을 방지하기 위해 지역 간 쓰기의 대기 시간 증가에 대처하는 것이 더 나을 수 있습니다(일관성 선호). 애플리케이션이 쓰기 작업이 많고 대기 시간 예산이 빠듯한 경우 주요 지역 중단 시 가장 최근 쓰기 중 일부를 손실할 위험을 받아들일 수 있습니다(가용성 선호).

가용성 영역

Cassandra의 마스터리스 아키텍처는 처음부터 내결함성을 제공하며, Azure Managed Instance for Apache Cassandra는 인프라 수준에서 복원력을 향상하기 위해 선택한 지역의 가용성 영역에 대한 지원을 제공합니다. 복제 계수가 3인 경우, 가용성 영역 지원을 통해 각 복제본이 서로 다른 가용성 영역에 있으므로 영역 중단으로 인해 데이터베이스/애플리케이션이 영향을 받지 않습니다. 가능한 경우 가용성 영역을 사용하도록 설정하는 것이 좋습니다.

다중 지역 중복성

Cassandra의 아키텍처는 Azure 가용성 영역 지원과 결합되어 일정 수준의 내결함성 및 복원력을 제공합니다. 그러나 애플리케이션에 대한 지역 중단의 영향을 고려하는 것이 중요합니다. 지역 수준 중단으로부터 보호하기 위해 다중 지역 클러스터를 배포하는 것이 좋습니다. 드물기는 하지만 잠재적 영향이 심각합니다.

비즈니스 연속성을 위해 데이터베이스를 다중 지역으로 만드는 것만으로는 충분하지 않습니다. 애플리케이션의 다른 부분도 배포하거나 장애 조치(failover)할 적절한 메커니즘을 사용하여 동일한 방식으로 배포해야 합니다. 사용자가 여러 지리적 위치에 분산되어 있는 경우 데이터베이스에 대한 다중 지역 데이터 센터 배포는 대기 시간을 줄이는 추가적인 이점이 있습니다. 클러스터 전체의 모든 데이터 센터의 모든 노드가 가장 가까운 지역의 읽기 및 쓰기를 모두 제공할 수 있기 때문에 대기 시간을 줄일 수 있습니다. 그러나 애플리케이션이 "활성-활성"으로 구성된 경우 CAP 정리가 복제본(노드) 간의 데이터 일관성과 고가용성을 제공하는 데 필요한 절충에 어떻게 적용되는지 고려해야 합니다.

CAP 정리 측면에서 Cassandra는 기본적으로 AP(Available Partition-tolerant) 데이터베이스 시스템으로, 조정 가능한 일관성이 높습니다. 대부분의 사용 사례에서는 읽기에 local_quorum을 사용하는 것이 좋습니다.

• 쓰기에 대한 활성-수동에서는 안정성과 성능 간에 절충이 있습니다. 안정성을 위해 QUORUM_EACH를 권장하지만, 대부분의 사용자에게 LOCAL_QUORUM 또는 QUORUM이 좋은 절충안입니다. 그러나 지역 중단의 경우 LOCAL_QUORUM에서는 일부 쓰기가 손실될 수 있습니다.
• 애플리케이션이 병렬로 실행되는 경우 두 데이터 센터 간의 일관성을 보장하기 위해 대부분의 경우 QUORUM_EACH 쓰기가 선호됩니다.
• 대기 시간 또는 가용성(낮은 RTO)보다 일관성(낮은 RPO)을 선호하는 것이 목표인 경우 일관성 설정 및 복제 계수에 반영되어야 합니다. 일반적으로 읽기에 필요한 쿼럼 노드 수와 쓰기에 필요한 쿼럼 노드 수는 복제 계수보다 커야 합니다. 예를 들어 복제 계수가 3이고 읽기에 quorum_one(노드 1개)인 경우, 쓰기에서 quorum_all(노드 3개)을 수행해야 합계 4가 복제 계수 3보다 큽니다.

참고 항목

Apache Cassandra용 Azure Managed Instance에 대한 제어 평면 연산자는 단일 지역(처음 첫 번째 데이터 센터를 배포할 때 선택한 지역)에만 배포됩니다. 전체 지역 가동 중단이 발생할 가능성이 낮을 경우 제어 평면을 다른 지역으로 장애 조치(failover)하기 위해 3시간의 복구 시간을 커밋합니다. 데이터 센터가 계속 작동해야 하므로 서비스에 대한 가용성 SLA에는 영향을 주지 않습니다. 그러나 이 기간 동안 포털 또는 리소스 공급자 도구에서 데이터베이스 구성을 변경하지 못할 수 있습니다.

복제

keyspaces 및 해당 복제 설정을 때때로 감사하여 데이터 센터 간에 필요한 복제가 구성되었는지 확인하는 것이 좋습니다. 개발 초기 단계에서는 cqlsh를 사용하여 간단한 테스트를 수행하여 모든 것이 예상대로 작동하는지 테스트하는 것이 좋습니다. 예를 들어 한 데이터 센터에 연결된 동안 값을 입력하고 다른 데이터 센터에서 읽습니다.

특히 기존 데이터 센터에 이미 데이터가 있는 두 번째 데이터 센터를 설정하는 경우 모든 데이터가 복제되고 시스템이 준비되었는지 확인하는 것이 중요합니다. nodetool netstats와 함께 DBA 명령을 통해 복제 진행률을 모니터링하는 것이 좋습니다. 다른 방법은 각 테이블의 행 수를 계산하는 것이지만, Cassandra의 분산 특성으로 인해 빅 데이터 크기의 경우 대략적인 예상치만 제공할 수 있습니다.

재해 복구 비용 조정

애플리케이션이 "활성-수동"인 경우, 애플리케이션이 보조 지역의 "상시 대기" 데이터 센터로 즉시 장애 조치(failover)할 수 있도록 각 지역에 동일한 용량을 배포하는 것이 일반적으로 좋습니다. 이렇게 하면 지역 중단 시 성능이 저하되지 않습니다. 대부분의 Cassandra 클라이언트 드라이버는 애플리케이션 수준 장애 조치(failover)를 시작하는 옵션을 제공합니다. 기본적으로 지역 중단은 애플리케이션도 다운된 것을 의미하며, 이 경우 부하 분산 장치 수준에서 장애 조치(failover)가 일어나야 합니다.

그러나 두 번째 데이터 센터를 프로비전하는 비용을 줄이려면 보조 지역에 더 작은 SKU 및 더 적은 노드를 배포하는 것이 좋습니다. 중단이 발생하면 Azure Managed Instance for Apache Cassandra에서 턴키 수직 및 수평 크기 조정을 통해 스케일 업이 더 쉬워집니다. 애플리케이션이 보조 지역으로 장애 조치(failover)하는 동안 보조 데이터 센터 노드의 스케일 아웃 및 스케일 업을 수동으로 수행할 수 있습니다. 이 경우 보조 데이터 센터는 낮은 비용의 웜 대기 역할을 합니다. 이 방법을 사용하려면 중단 시 시스템을 전체 용량으로 복원하는 데 필요한 시간과 균형을 이루어야 합니다. 지역이 손실되면 어떤 일이 일어나는지 테스트하고 연습하는 것이 중요합니다.

참고 항목

노드를 스케일 업하는 것은 스케일 아웃보다 훨씬 빠릅니다. 수직 및 수평 스케일링 간의 균형과 클러스터에 배포할 노드 수를 고려할 때 이 점을 염두에 두어야 합니다.

백업 일정

백업은 Azure Managed Instance for Apache Cassandra에서 자동으로 수행되지만, 일일 백업에 대한 고유한 일정을 선택할 수 있습니다. 부하가 적은 시간을 선택하는 것이 좋습니다. 백업은 유휴 CPU만 사용하도록 구성되지만, 경우에 따라 Cassandra에서 압축을 트리거하여 CPU 사용량이 증가할 수 있습니다. 압축은 Cassandra에서 언제든지 발생할 수 있으며, 워크로드 및 선택한 압축 전략에 따라 달라집니다.

Important

백업의 목적은 실수로 인한 데이터 손실 또는 데이터 손상을 완화하는 것입니다. 백업을 재해 복구 전략으로 사용하는 것은 권장하지 않습니다. 백업은 지역 중복이 아니며, 중복된 경우라도 백업에서 데이터베이스를 복구하는 데 시간이 오래 걸릴 수 있습니다. 따라서 재해 시나리오를 완화하고 효과적으로 복구하기 위해서는 가능한 경우 가용성 영역을 사용하도록 설정하고 다중 지역 배포를 사용하는 것이 좋습니다. 이는 다중 지역 복제가 없으면 모든 데이터가 손실될 수 있는 실패한 지역을 다룰 수 없는 드문 시나리오에서 특히 중요합니다.

다음 단계

이 문서에서는 Cassandra를 사용하여 복원력 있는 애플리케이션을 빌드하기 위한 몇 가지 모범 사례를 설명했습니다.

Azure Portal을 사용하여 클러스터 만들기