다음을 통해 공유


클라우드 규모 분석을 위한 비즈니스 연속성 및 재해 복구

클라우드 서비스에 대한 아키텍처를 디자인할 때 가용성 요구 사항 및 서비스의 잠재적 중단에 대응하는 방법을 고려합니다. 특정 인스턴스 또는 지역 전체로 문제를 지역화할 수 있습니다. 둘 다에 대한 계획을 갖는 것이 중요합니다. 복구 시간 목표 및 복구 지점 목표에 따라 고가용성 및 재해 복구를 위한 공격적인 전략을 선택할 수 있습니다.

경우에 따라 고가용성 및 재해 복구를 결합할 수 있습니다. 두 영역은 약간 다른 전략을 가지고 있으며, 특히 데이터에 관해서는 그렇습니다. 자세한 내용은 Microsoft Azure Well-Architected Framework 및안정성 원칙 을 참조하세요.

오류를 방지하는 대신 오류가 발생할 수 있고 발생할 수 있도록 미리 수락합니다. 수명 주기에서 단일 실패 구성 요소의 영향을 최소화합니다. 비용, 복구 지점 목표 및 복구 시간 목표에 대한 허용 오차는 구현할 솔루션 유형을 결정합니다.

백업 전략

여러 지역에서 분산 컴퓨팅을 구현하는 데 많은 대체 전략을 사용할 수 있습니다. 전략은 애플리케이션의 비즈니스 요구 사항 및 상황에 맞게 조정되어야 합니다. 높은 수준에서 접근 방식은 다음 범주로 분류됩니다.

  • 백업 및 복원: 재해가 발생하기 전에 마지막 백업 복사본에서 데이터베이스 애플리케이션을 복원합니다. 이 방법은 데이터 손상 또는 실수로 삭제된 후 일반적으로 사용됩니다.

  • 재해 시 애플리케이션을 처음부터 다시 배포하는 다시 배포:. 이 방법은 보장된 복구 시간이 필요하지 않은 비임계 애플리케이션에 적합합니다.

  • 웜 예비(활성/수동): 다른 지역에 보조 호스팅 서비스를 생성합니다. 최소한의 용량을 보장하기 위해 역할을 배포합니다. 역할은 프로덕션 트래픽을 수신하지 않습니다. 이 방법은 지역 간에 트래픽을 분산하도록 설계되지 않은 애플리케이션에 유용합니다.

  • 핫 스페어(활성/활성): 여러 지역에서 프로덕션 부하를 처리할 수 있도록 애플리케이션을 디자인합니다. 재해 복구를 위해 필요한 것보다 더 높은 용량으로 각 지역의 클라우드 서비스를 구성할 수 있습니다. 대신 재해 및 장애 복구 시 필요한 경우 클라우드 서비스를 확대할 수 있습니다.

    이 방법은 애플리케이션 디자인에 대한 투자가 필요하지만 이점이 있습니다. 낮고 보장된 복구 시간을 제공합니다. 모든 복구 위치에 대한 지속적인 테스트와 효율적인 용량 사용이 있습니다. 데이터베이스 애플리케이션의 경우 이 방법은 단일 연결 지점과 동기화되는 두 데이터베이스에 대한 부하 분산 장치를 포함합니다.

Azure 서비스에 대한 재해 복구 및 고가용성

Cloud Scale Analytics는 플랫폼, 코어 및 데이터로 그룹화된 여러 Azure 서비스로 구성됩니다. 서비스별 안정성 가이드 및 재해 복구에 대한 자세한 내용은 Azure 안정성 설명서 참조하세요.

다음 단계