다음을 통해 공유

비즈니스 연속성, 고가용성 및 재해 복구란?

  • 아티클

이 문서에서는 고가용성 및 재해 복구 디자인을 통한 위험 관리 측면에서 비즈니스 연속성 및 비즈니스 연속성 계획을 정의하고 설명합니다. 이 문서에서는 고유한 비즈니스 연속성 요구 사항을 충족하는 방법에 대한 명시적 지침을 제공하지 않지만 Microsoft의 안정성 지침 전체에서 사용되는 개념을 이해하는 데 도움이 됩니다.

비즈니스 연속성은 비즈니스가 오류, 중단 또는 재해 중에 작업을 계속할 수 있는 상태입니다. 비즈니스 연속성을 위해서는 사전 계획, 준비 및 복원력 있는 시스템 및 프로세스의 구현이 필요합니다.

비즈니스 연속성을 계획하려면 위험을 식별, 이해, 분류 및 관리해야 합니다. 위험 및 해당 가능성에 따라 HA(고가용성) 및 DR(재해 복구)을 모두 디자인합니다.

고가용성 은 일상적인 문제에 대한 복원력과 가용성에 대한 비즈니스 요구 사항을 충족하는 솔루션을 설계하는 것입니다.

재해 복구 는 드문 위험과 발생할 수 있는 치명적인 중단을 처리하는 방법을 계획하는 것입니다.

비즈니스 연속성

일반적으로 클라우드 솔루션은 비즈니스 운영에 직접 연결됩니다. 클라우드 솔루션을 사용할 수 없거나 심각한 문제가 발생할 때마다 비즈니스 운영에 미치는 영향은 심각할 수 있습니다. 심각한 영향은 비즈니스 연속성을 깨뜨릴 수 있습니다.

비즈니스 연속성에 심각한 영향을 미칠 수 있는 사항은 다음과 같습니다.

  • 사업 소득의 손실.
  • 사용자에게 중요한 서비스를 제공할 수 없습니다.
  • 고객 또는 다른 당사자에게 적용된 약정 위반

워크로드를 설계, 구현 및 운영하는 사용자를 포함하여 중요한 이해 관계자에게 비즈니스 기대치와 실패의 결과를 이해하고 전달하는 것이 중요합니다. 그런 다음 이러한 이해 관계자들은 해당 비전을 충족하는 데 관련된 비용을 공유하여 대응합니다. 일반적으로 예산 및 기타 제약 조건에 따라 해당 비전의 협상 및 수정 프로세스가 있습니다.

비즈니스 연속성 계획

비즈니스 연속성에 부정적인 영향을 제어하거나 완전히 방지하려면 비즈니스 연속성 계획을 사전에 만드는 것이 중요합니다. 비즈니스 연속성 계획은 다양한 접근 방식을 통해 위험 평가 및 이러한 위험을 제어하는 방법을 개발하는 방법을 기반으로 합니다. 완화할 특정 위험 및 접근 방식은 각 조직 및 워크로드에 따라 다릅니다.

비즈니스 연속성 계획은 클라우드 플랫폼 자체의 복원력 기능뿐만 아니라 애플리케이션의 기능도 고려하지 않습니다. 또한 강력한 비즈니스 연속성 계획은 사람, 비즈니스 관련 수동 또는 자동화된 프로세스 및 기타 기술을 포함하여 비즈니스 지원의 모든 측면을 통합합니다.

비즈니스 연속성 계획에는 다음 순차적 단계가 포함되어야 합니다.

  1. 위험 식별. 워크로드의 가용성 또는 기능에 대한 위험을 식별합니다. 가능한 위험은 네트워크 문제, 하드웨어 오류, 사용자 오류, 지역 중단 등이 될 수 있습니다. 각 위험의 영향을 이해합니다.

  2. 위험 분류. 각 위험을 HA 계획에 고려해야 하는 일반적인 위험 또는 DR 계획의 일부여야 하는 드문 위험으로 분류합니다.

  3. 위험 완화. 중복성, 복제, 장애 조치(failover) 및 백업 사용과 같은 위험을 최소화하거나 완화하기 위해 HA 또는 DR에 대한 완화 전략을 설계합니다. 또한 비기술적 및 프로세스 기반 완화 및 제어를 고려합니다.

비즈니스 연속성 계획은 일회성 이벤트가 아닌 프로세스입니다. 생성되는 모든 비즈니스 연속성 계획을 정기적으로 검토하고 업데이트하여 관련성과 효율성을 유지하고 현재 비즈니스 요구를 지원해야 합니다.

위험 식별

비즈니스 연속성 계획의 초기 단계는 워크로드의 가용성 또는 기능에 대한 위험을 식별하는 것입니다. 각 위험을 분석하여 가능성과 심각도를 이해해야 합니다. 심각도에는 잠재적인 가동 중지 시간 또는 데이터 손실뿐만 아니라 나머지 솔루션 디자인의 측면이 부정적인 영향을 보정할 수 있는지 여부도 포함되어야 합니다.

다음 표는 가능성을 줄임으로써 정렬된 위험의 완전하지 않은 목록입니다.

위험 예제 설명 규칙성(가능성)
일시적인 네트워크 문제 네트워킹 스택 구성 요소의 일시적인 오류로, 짧은 시간(일반적으로 몇 초 이하) 후에 복구할 수 있습니다. 일반
가상 머신 다시 부팅 사용하는 가상 머신 또는 종속 서비스에서 사용하는 가상 머신을 다시 부팅합니다. 가상 머신이 충돌하거나 패치를 적용해야 하기 때문에 다시 부팅이 발생할 수 있습니다. 일반
하드웨어 오류 하드웨어 노드, 랙 또는 클러스터와 같은 데이터 센터 내 구성 요소의 오류입니다. 간헐적
데이터 센터 중단 전원 오류, 네트워크 연결 문제 또는 난방 및 냉각 문제와 같은 데이터 센터의 대부분 또는 전부에 영향을 주는 중단입니다. 엉뚱하다
지역 중단 주요 자연 재해와 같이 대도시 지역 전체 또는 더 넓은 지역에 영향을 미치는 중단. 매우 특이한

비즈니스 연속성 계획은 클라우드 플랫폼 및 인프라에만 국한되지 않습니다. 사용자 오류의 위험을 고려하는 것이 중요합니다. 또한 일반적으로 보안, 성능 또는 운영 위험으로 간주될 수 있는 일부 위험은 솔루션의 가용성에 영향을 미치기 때문에 안정성 위험으로 간주되어야 합니다.

다음 몇 가지 예를 참조하세요.

위험 예제 설명
데이터 손실 또는 손상 사고나 랜섬웨어 공격과 같은 보안 위반으로 인해 데이터가 삭제, 덮어쓰기 또는 손상되었습니다.
소프트웨어 버그 새 코드 또는 업데이트된 코드의 배포는 가용성 또는 무결성에 영향을 주는 버그를 도입하여 워크로드를 오작동 상태로 만듭니다.
실패한 배포 새 구성 요소 또는 버전의 배포가 실패하여 솔루션이 일관되지 않은 상태로 유지되었습니다.
서비스 거부 공격 시스템이 솔루션의 합법적인 사용을 방지하기 위해 공격을 받았습니다.
Rogue 관리자 관리자 권한이 있는 사용자가 의도적으로 시스템에 대해 손상된 작업을 수행했습니다.
애플리케이션에 예기치 않은 트래픽 유입 트래픽 급증으로 인해 시스템 리소스가 과부하가 발생했습니다.

FMA(오류 모드 분석 )는 워크로드 또는 해당 구성 요소가 실패할 수 있는 잠재적인 방법과 이러한 상황에서 솔루션이 작동하는 방식을 식별하는 프로세스입니다. 자세한 내용은 실패 모드 분석을 수행하기 위한 권장 사항을 참조 하세요.

위험 분류

비즈니스 연속성 계획은 일반적인 위험과 일반적이지 않은 위험을 모두 해결해야 합니다.

  • 일반적인 위험이 계획되고 예상됩니다. 예를 들어 클라우드 환경에서는 간단한 네트워크 중단, 패치로 인한 장비 다시 시작, 서비스 사용량이 많은 시간 제한 등을 비롯한 일시적인 오류가 발생하는 것이 일반적입니다. 이러한 이벤트는 정기적으로 발생하므로 워크로드는 복원력이 있어야 합니다.

    고가용성 전략은 이 유형의 각 위험을 고려하고 제어해야 합니다.

  • 일반적이지 않은 위험은 일반적으로 자연 재해 또는 주요 네트워크 공격과 같이 예측할 수 없는 이벤트로 인해 치명적인 중단이 발생할 수 있습니다.

    재해 복구 프로세스는 이러한 드문 위험을 처리합니다.

고가용성 및 재해 복구는 상호 관련되므로 두 가지 모두에 대한 전략을 함께 계획하는 것이 중요합니다.

위험 분류는 워크로드 아키텍처 및 비즈니스 요구 사항에 따라 달라지고, 일부 위험은 한 워크로드의 경우 HA로, 다른 워크로드의 경우 DR로 분류할 수 있다는 점을 이해하는 것이 중요합니다. 예를 들어 전체 Azure 지역 중단은 일반적으로 해당 지역의 워크로드에 대한 DR 위험으로 간주됩니다. 그러나 전체 복제, 중복성 및 자동 지역 장애 조치(failover)가 있는 활성-활성 구성에서 여러 Azure 지역을 사용하는 워크로드의 경우 지역 중단은 HA 위험으로 분류됩니다.

위험 완화

위험 완화는 비즈니스 연속성에 대한 위험을 최소화하거나 완화하기 위한 HA 또는 DR 전략을 개발하는 것으로 구성됩니다. 위험 완화는 기술 기반 또는 인간 기반일 수 있습니다.

기술 기반 위험 완화

기술 기반 위험 완화는 워크로드를 구현하고 구성하는 방법에 따라 다음과 같은 위험 제어를 사용합니다.

  • 중복
  • 데이터 복제
  • 장애 조치(Failover)
  • Backup

기술 기반 위험 제어는 비즈니스 연속성 계획의 컨텍스트 내에서 고려해야 합니다.

예시:

  • 가동 중지 시간 요구 사항이 낮습니다. 일부 비즈니스 연속성 계획은 엄격한 고가용성 요구 사항으로 인해 어떤 형태의 가동 중지 시간 위험도 용인할 수 없습니다. 특정 기술 기반 컨트롤은 사람이 알림을 받은 다음 응답하는 데 시간이 필요할 수 있습니다. 느린 수동 프로세스를 포함하는 기술 기반 위험 제어는 위험 완화 전략에 포함하기에 적합하지 않을 수 있습니다.

  • 부분 오류에 대한 허용 오차입니다. 일부 비즈니스 연속성 계획은 성능이 저하된 상태에서 실행되는 워크플로를 허용할 수 있습니다. 솔루션이 성능이 저하된 상태에서 작동하는 경우 일부 구성 요소는 비활성화되거나 비기능적일 수 있지만 핵심 비즈니스 작업은 계속 수행될 수 있습니다. 자세한 내용은 자기 치유 및 자기 보존에 대한 권장 사항을 참조하세요.

인간 기반 위험 완화

인간 기반 위험 완화는 다음과 같은 비즈니스 프로세스를 기반으로 하는 위험 제어를 사용합니다.

  • 응답 플레이북 트리거
  • 수동 작업으로 돌아갑니다.
  • 교육 및 문화적 변화.

Important

워크로드를 설계, 구현, 운영 및 발전시키는 개인은 유능하고, 문제가 있는 경우 목소리를 높이고, 시스템에 대한 책임감을 느끼도록 권장되어야 합니다.

인간 기반 위험 제어는 종종 기술 기반 컨트롤보다 느리고 사람의 오류가 발생하기 쉽기 때문에 좋은 비즈니스 연속성 계획에는 실행 중인 시스템의 상태를 변경하는 모든 것에 대한 공식적인 변경 제어 프로세스가 포함되어야 합니다. 예를 들어 다음 프로세스를 구현하는 것이 좋습니다.

  • 워크로드 중요도에 따라 워크로드를 엄격하게 테스트합니다. 변경 관련 문제를 방지하려면 워크로드에 대한 변경 내용을 테스트해야 합니다.
  • 워크로드의 안전한 배포 방법의 일부로 전략적 품질 게이트를 소개합니다. 자세한 내용은 안전한 배포 방법에 대한 권장 사항을 참조 하세요.
  • 임시 프로덕션 액세스 및 데이터 조작에 대한 절차를 공식화합니다. 이러한 활동은 아무리 사소하더라도 안정성 인시던트를 유발할 위험이 높아질 수 있습니다. 절차에는 다른 엔지니어와의 페어링, 검사 목록 사용, 스크립트를 실행하거나 변경 내용을 적용하기 전에 피어 검토 가져오기가 포함될 수 있습니다.

고가용성

고가용성이란 일시적인 오류 및 일시적인 오류 발생 시에도 특정 워크로드가 필요한 가동 시간 수준을 매일 유지할 수 있는 상태입니다. 이러한 이벤트는 정기적으로 발생하므로 각 워크로드는 특정 애플리케이션의 요구 사항 및 고객 기대에 따라 고가용성을 위해 설계 및 구성해야 합니다. 각 워크로드의 HA는 비즈니스 연속성 계획에 기여합니다.

HA는 각 워크로드에 따라 달라질 수 있으므로 고가용성을 결정할 때 요구 사항 및 고객 기대치를 이해하는 것이 중요합니다. 예를 들어 조직에서 사무용품을 주문하는 데 사용하는 애플리케이션은 비교적 낮은 수준의 가동 시간이 필요할 수 있지만 중요한 재무 애플리케이션에는 훨씬 더 높은 가동 시간이 필요할 수 있습니다. 워크로드 내에서도 흐름 에 따라 요구 사항이 다를 수 있습니다. 예를 들어 전자 상거래 애플리케이션에서 주문 검색 및 배치 고객을 지원하는 흐름은 주문 처리 및 백오피스 처리 흐름보다 더 중요할 수 있습니다. 흐름에 대한 자세한 내용은 흐름 식별 및 등급에 대한 권장 사항을 참조 하세요.

일반적으로 가동 시간은 가동 시간 백분율의 "9개"를 기준으로 측정됩니다. 가동 시간 비율은 지정된 기간 동안 허용되는 가동 중지 시간과 관련이 있습니다. 다음 몇 가지 예를 참조하세요.

  • 99.9%의 가동 시간 요구 사항(3개의 9개)을 사용하면 한 달에 약 43분의 가동 중지 시간이 허용됩니다.
  • 99.95%의 가동 시간 요구 사항(3개 반 9개)은 한 달에 약 21분의 가동 중지 시간을 허용합니다.

가동 시간 요구 사항이 높을수록 중단에 대한 허용 오차가 줄어들고 해당 가용성 수준에 도달하기 위해 수행해야 하는 작업이 더 많이 수행됩니다. 가동 시간은 노드와 같은 단일 구성 요소의 작동 시간이 아니라 전체 워크로드의 전체 가용성에 따라 측정됩니다.

Important

정당화되는 것보다 높은 수준의 안정성에 도달하기 위해 솔루션을 과도하게 입력하지 마세요. 비즈니스 요구 사항을 사용하여 의사 결정을 안내합니다.

고가용성 디자인 요소

HA 요구 사항을 달성하기 위해 워크로드에는 여러 디자인 요소가 포함될 수 있습니다. 이 섹션에서는 몇 가지 일반적인 요소를 나열하고 아래에 설명합니다.

참고 항목

일부 워크로드는 업무상 중요하므로 가동 중지 시간이 인간의 생명과 안전에 심각한 영향을 미칠 수 있거나 재정적 손실이 발생할 수 있습니다. 중요 업무용 워크로드를 설계하는 경우 솔루션을 디자인하고 비즈니스 연속성을 관리할 때 고려해야 할 구체적인 사항이 있습니다. 자세한 내용은 Azure Well-Architected Framework: 중요 업무용 워크로드를 참조 하세요.

고가용성을 지원하는 Azure 서비스 및 계층

많은 Azure 서비스는 고가용성으로 설계되었으며 고가용성 워크로드를 빌드하는 데 사용할 수 있습니다. 다음 몇 가지 예를 참조하세요.

  • Azure Virtual Machine Scale Sets 는 VM 인스턴스를 자동으로 만들고 관리하고 이러한 VM 인스턴스를 배포하여 인프라 오류의 영향을 줄여 VM(가상 머신)에 고가용성을 제공합니다.
  • Azure 앱 Service는 비정상 노드에서 정상 노드로 작업자를 자동으로 이동하는 등 다양한 방법을 통해 고가용성을 제공하며, 여러 일반적인 오류 유형에서 자가 복구 기능을 제공합니다.

각 서비스 안정성 가이드 를 사용하여 서비스의 기능을 이해하고, 사용할 계층을 결정하고, 고가용성 전략에 포함할 기능을 결정합니다.

각 서비스에 대한 SLA(서비스 수준 계약)를 검토하여 예상 가용성 수준 및 충족해야 하는 조건을 이해합니다. 특정 수준의 가용성을 달성하려면 특정 서비스 계층을 선택하거나 피해야 할 수 있습니다. Microsoft의 일부 서비스는 개발 또는 기본 계층과 같이 SLA가 제공되지 않거나 스폿 기반 제품과 같은 실행 중인 시스템에서 리소스를 회수할 수 있다는 것을 이해하여 제공됩니다. 또한 일부 계층에는 가용성 영역에 대한 지원과 같은 안정성 기능이 추가되었습니다.

내결함성

내결함성은 오류가 발생할 경우 시스템이 일부 정의된 용량에서 계속 작동할 수 있는 기능입니다. 예를 들어 웹 애플리케이션은 단일 웹 서버가 실패하더라도 계속 작동하도록 설계될 수 있습니다. 중복성, 장애 조치, 분할, 정상 성능 저하 및 기타 기술을 통해 내결함성을 달성할 수 있습니다.

또한 내결함성은 애플리케이션에서 일시적인 오류를 처리해야 합니다. 사용자 고유의 코드를 빌드할 때 임시 오류 처리를 사용하도록 설정해야 할 수 있습니다. 일부 Azure 서비스는 일부 상황에 대해 기본 제공 임시 오류 처리를 제공합니다. 예를 들어 기본적으로 Azure Logic Apps는 실패한 요청을 다른 서비스에 자동으로 다시 시도합니다. 자세한 내용은 일시적인 오류 처리에 대한 권장 사항을 참조 하세요.

중복

중복성은 워크로드의 안정성을 높이기 위해 인스턴스 또는 데이터를 복제하는 방법입니다.

복제본 또는 중복 인스턴스를 다음과 같은 방법으로 하나 더 배포하여 중복성을 달성할 수 있습니다.

  • 데이터 센터 내부(로컬 중복성)
  • 지역 내의 가용성 영역 간(영역 중복성)
  • 지역 간(지역 중복성)

다음은 일부 Azure 서비스에서 중복 옵션을 제공하는 방법의 몇 가지 예입니다.

  • Azure 앱 Service를 사용하면 애플리케이션의 여러 인스턴스를 실행하여 하나의 인스턴스가 실패하더라도 애플리케이션을 계속 사용할 수 있도록 할 수 있습니다. 영역 중복을 사용하도록 설정하면 해당 인스턴스는 사용하는 Azure 지역의 여러 가용성 영역에 분산됩니다.
  • Azure Storage 는 데이터를 세 번 이상 자동으로 복제하여 고가용성을 제공합니다. 이러한 복제본은 ZRS(영역 중복 스토리지)를 사용하도록 설정하여 가용성 영역에 분산할 수 있으며, 여러 지역에서 GRS(지역 중복 스토리지)를 사용하여 지역 간에 스토리지 데이터를 복제할 수도 있습니다.
  • Azure SQL Database 에는 하나의 복제본이 실패하더라도 데이터를 계속 사용할 수 있도록 하는 여러 복제본이 있습니다.

중복성에 대한 자세한 내용은 가용성 영역 및 지역 사용에 대한 중복성 및 권장 사항 디자인에 대한 권장 사항을 참조하세요.

확장성 및 탄력성

확장성 및 탄력성은 리소스를 추가 및 제거하여 증가된 부하를 처리하고(확장성) 요구 사항이 변경될 때 빠르게 수행할 수 있는 시스템 기능입니다(탄력성). 확장성 및 탄력성은 최대 부하 중에 시스템이 가용성을 유지하는 데 도움이 될 수 있습니다.

많은 Azure 서비스는 확장성을 지원합니다. 다음 몇 가지 예를 참조하세요.

  • Azure Virtual Machine Scale Sets, Azure API Management 및 기타 여러 서비스는 Azure Monitor 자동 크기 조정을 지원합니다. Azure Monitor 자동 크기 조정을 사용하면 "내 CPU가 지속적으로 80%를 초과하는 경우 다른 인스턴스를 추가"와 같은 정책을 지정할 수 있습니다.
  • Azure Functions는 인스턴스를 동적으로 프로비전하여 요청을 처리할 수 있습니다.
  • Azure Cosmos DB는 자동 크기 조정 처리량을 지원합니다. 여기서 서비스는 사용자가 지정한 정책에 따라 데이터베이스에 할당된 리소스를 자동으로 관리할 수 있습니다.

확장성은 부분 또는 완전한 오작동 중에 고려해야 할 핵심 요소입니다. 복제본 또는 컴퓨팅 인스턴스를 사용할 수 없는 경우 나머지 구성 요소는 이전에 오류가 발생한 노드에서 처리하던 부하를 처리하기 위해 더 많은 부하를 부담해야 할 수 있습니다. 시스템이 예상된 부하 변경을 처리할 만큼 빠르게 확장할 수 없는 경우 과잉 프로비전을 고려합니다.

확장 가능하고 탄력적인 시스템을 설계하는 방법에 대한 자세한 내용은 신뢰할 수 있는 크기 조정 전략을 설계하기 위한 권장 사항을 참조 하세요.

가동 중지 시간 없는 배포 기술

배포 및 기타 시스템 변경으로 인해 가동 중지 시간이 발생할 위험이 큽니다. 가동 중지 시간 위험은 고가용성 요구 사항에 대한 과제이므로 가동 중지 시간 없이 가동 중지 시간 없이 배포 사례를 사용하여 업데이트 및 구성을 변경하는 것이 중요합니다.

가동 중지 시간 없는 배포 기술에는 다음이 포함될 수 있습니다.

  • 리소스의 하위 집합을 한 번에 업데이트합니다.
  • 새 배포에 도달하는 트래픽 양을 제어합니다.
  • 사용자 또는 시스템에 미치는 영향을 모니터링합니다.
  • 이전의 정상 배포로 롤백하는 등 문제를 신속하게 수정합니다.

가동 중지 시간 없는 배포 기술에 대한 자세한 내용은 안전한 배포 방법을 참조 하세요.

Azure 자체는 자체 서비스에 대해 가동 중지 시간 없는 배포 방법을 사용합니다. 고유한 애플리케이션을 빌드할 때 다음과 같은 다양한 방법을 통해 가동 중지 시간 없는 배포를 채택할 수 있습니다.

가동 중지 시간이 없는 배포는 종종 애플리케이션 배포와 연결되지만 구성 변경에도 사용해야 합니다. 구성 변경 내용을 안전하게 적용할 수 있는 몇 가지 방법은 다음과 같습니다.

가동 중지 시간 배포를 구현하지 않기로 결정한 경우 사용자가 예상하는 시간에 시스템을 변경할 수 있도록 유지 관리 기간을 정의해야 합니다.

자동화된 테스트

HA 범위에 있는 것으로 간주하는 중단 및 오류를 견딜 수 있는 솔루션의 기능을 테스트하는 것이 중요합니다. 이러한 오류의 대부분은 테스트 환경에서 시뮬레이션할 수 있습니다. 다양한 오류 유형을 자동으로 허용하거나 복구하는 솔루션의 기능을 테스트하는 것을 비정상 상황 엔지니어링이라고 합니다. 카오스 엔지니어링은 HA에 대한 엄격한 표준을 가진 성숙한 조직에 매우 중요합니다. Azure Chaos Studio 는 몇 가지 일반적인 오류 유형을 시뮬레이션할 수 있는 비정상 상황 엔지니어링 도구입니다.

자세한 내용은 안정성 테스트 전략 설계에 대한 권장 사항을 참조 하세요.

모니터링 및 경고

모니터링을 사용하면 자동화된 완화가 수행되더라도 시스템의 상태를 알 수 있습니다. 모니터링은 솔루션이 어떻게 작동하는지 이해하고 오류율 증가 또는 높은 리소스 사용량과 같은 오류의 초기 신호를 감시하는 데 중요합니다. 경고를 사용하면 환경에서 중요한 변경 내용을 사전에 수신할 수 있습니다.

Azure는 다음을 포함하여 다양한 모니터링 및 경고 기능을 제공합니다.

자세한 내용은 신뢰할 수 있는 모니터링 및 경고 전략을 설계하기 위한 권장 사항을 참조 하세요.

재해 복구

재해는 애플리케이션이 디자인의 고가용성 측면을 통해 완화할 수 있는 것보다 더 크고 오래 지속되는 고유한 일반적이지 않은 주요 이벤트입니다. 재해의 예는 다음과 같습니다.

  • 허리케인, 지진, 홍수 또는 화재와 같은 자연 재해.
  • 실수로 프로덕션 데이터를 삭제하거나 중요한 데이터를 노출하는 잘못 구성된 방화벽과 같이 큰 영향을 주는 사용자 오류입니다.
  • 데이터 손상, 데이터 손실 또는 서비스 중단으로 이어지는 서비스 거부 또는 랜섬웨어 공격과 같은 주요 보안 인시던트

재해 복구 는 이러한 유형의 상황에 대응하는 방법을 계획하는 것입니다.

참고 항목

이러한 이벤트의 가능성을 최소화하려면 솔루션 전체에서 권장되는 사례를 따라야 합니다. 그러나 신중한 사전 계획 후에도 이러한 상황이 발생할 경우 어떻게 대응할지 계획하는 것이 좋습니다.

재해 복구 요구 사항

재해 이벤트의 희귀성 및 심각도로 인해 DR 계획은 응답에 대해 서로 다른 기대를 제공합니다. 많은 조직에서는 재해 시나리오에서 일정 수준의 가동 중지 시간 또는 데이터 손실이 불가피하다는 사실을 받아들입니다. 전체 DR 계획은 각 흐름에 대해 다음과 같은 중요한 비즈니스 요구 사항을 지정해야 합니다.

  • RPO(복구 지점 목표) 는 재해 발생 시 허용되는 데이터 손실의 최대 기간입니다. RPO는 "데이터 30분" 또는 "4시간 데이터"와 같은 시간 단위로 측정됩니다.

  • RTO(복구 시간 목표) 는 재해 발생 시 허용되는 가동 중지 시간의 최대 기간이며, 여기서 "가동 중지 시간"은 사양에 따라 정의됩니다. RTO는 또한 "가동 중지 시간 8시간"처럼 시간 단위로 측정됩니다.

RTO 및 RPO 기간(시간)의 스크린샷.

워크로드의 각 구성 요소 또는 흐름에는 개별 RPO 및 RTO 값이 있을 수 있습니다. 요구 사항을 결정할 때 재해 시나리오 위험 및 잠재적 복구 전략을 검토합니다. RPO 및 RTO를 지정하는 프로세스는 고유한 비즈니스 문제(비용, 영향, 데이터 손실 등)의 결과로 워크로드에 대한 DR 요구 사항을 효과적으로 만듭니다.

참고 항목

RTO 및 RPO 0(재해 발생 시 가동 중지 시간 및 데이터 손실 없음)을 목표로 하는 것은 유혹적이지만 실제로는 구현하기가 어렵고 비용이 많이 듭니다. 기술 및 비즈니스 이해 관계자가 이러한 요구 사항을 함께 논의하고 현실적인 요구 사항을 결정하는 것이 중요합니다. 자세한 내용은 안정성 목표를 정의하기 위한 권장 사항을 참조하세요.

재해 복구 계획

재해의 원인에 관계없이 잘 정의되고 테스트 가능한 DR 계획을 만드는 것이 중요합니다. 이 계획은 적극적으로 지원하기 위해 인프라 및 애플리케이션 디자인의 일부로 사용됩니다. 다양한 유형의 상황에 대해 여러 DR 계획을 만들 수 있습니다. DR 계획은 종종 프로세스 제어 및 수동 개입에 의존합니다.

DR은 Azure의 자동 기능이 아닙니다. 그러나 많은 서비스는 DR 전략을 지원하는 데 사용할 수 있는 기능과 기능을 제공합니다. 각 Azure 서비스에 대한 안정성 가이드를 검토 하여 서비스의 작동 방식과 기능을 파악한 다음 해당 기능을 DR 계획에 매핑해야 합니다.

다음 섹션에서는 재해 복구 계획의 몇 가지 일반적인 요소를 나열하고 Azure가 이를 달성하는 데 어떻게 도움이 되는지 설명합니다.

장애 조치 및 장애 복구

일부 재해 복구 계획에는 다른 위치에 보조 배포를 프로비전하는 작업이 포함됩니다. 재해가 솔루션의 기본 배포에 영향을 미치는 경우 트래픽을 다른 사이트로 장애 조치(failover)할 수 있습니다. 장애 조치(failover)를 수행하려면 신중한 계획과 구현이 필요합니다. Azure는 다음과 같은 장애 조치(failover)를 지원하는 다양한 서비스를 제공합니다.

  • Azure Site Recovery 는 Azure의 온-프레미스 환경 및 가상 머신 호스팅 솔루션에 대한 자동화된 장애 조치(failover)를 제공합니다.
  • Azure Front Door 및 Azure Traffic Manager 는 다른 지역과 같이 솔루션의 여러 배포 간에 들어오는 트래픽의 자동화된 장애 조치(failover)를 지원합니다.

일반적으로 장애 조치(failover) 프로세스에서 주 인스턴스가 실패했음을 감지하고 보조 인스턴스로 전환하는 데 다소 시간이 걸립니다. 워크로드의 RTO가 장애 조치(failover) 시간에 맞춰지도록 합니다.

복구된 후 주 지역에서 작업을 복원하는 프로세스인 장애 복구를 고려하는 것도 중요합니다. 장애 복구는 계획 및 구현이 복잡할 수 있습니다. 예를 들어 장애 조치(failover)가 시작된 후 주 지역의 데이터가 기록되었을 수 있습니다. 해당 데이터를 처리하는 방법에 대해 신중한 비즈니스 결정을 내려야 합니다.

Backup

백업에는 데이터의 복사본을 가져와서 정의된 기간 동안 안전하게 저장하는 작업이 포함됩니다. 백업을 사용하면 다른 복제본으로 자동 장애 조치(failover)할 수 없거나 데이터 손상이 발생한 경우 재해로부터 복구할 수 있습니다.

재해 복구 계획의 일부로 백업을 사용하는 경우 다음 사항을 고려해야 합니다.

  • 스토리지 위치입니다. 재해 복구 계획의 일부로 백업을 사용하는 경우 기본 데이터에 별도로 저장해야 합니다. 일반적으로 백업은 다른 Azure 지역에 저장됩니다.

  • 데이터 손실. 백업은 일반적으로 자주 수행되지 않으므로 백업 복원에는 일반적으로 데이터 손실이 포함됩니다. 이러한 이유로 백업 복구는 최후의 수단으로 사용해야 하며 재해 복구 계획은 백업에서 복원하기 전에 수행해야 하는 단계 및 복구 시도의 순서를 지정해야 합니다. 워크로드 RPO가 백업 간격에 맞춰지도록 하는 것이 중요합니다.

  • 복구 시간입니다. 백업 복원에는 종종 시간이 걸리므로 백업 및 복원 프로세스를 테스트하여 무결성을 확인하고 복원 프로세스에 걸리는 시간을 이해하는 것이 중요합니다. 워크로드의 RTO가 백업을 복원하는 데 걸리는 시간을 고려해야 합니다.

많은 Azure 데이터 및 스토리지 서비스는 다음과 같은 백업을 지원합니다.

  • Azure Backup 은 가상 머신 디스크, 스토리지 계정, AKS 및 기타 다양한 원본에 대한 자동화된 백업을 제공합니다.
  • Azure SQL Database 및 Azure Cosmos DB를 비롯한 많은 Azure 데이터베이스 서비스에는 데이터베이스에 대한 자동화된 백업 기능이 있습니다.
  • Azure Key Vault 는 비밀, 인증서 및 키를 백업하는 기능을 제공합니다.

자동 배포

재해 발생 시 필요한 리소스를 신속하게 배포하고 구성하려면 Bicep 파일, ARM 템플릿 또는 Terraform 구성 파일과 같은 IaC(Infrastructure as code) 자산을 사용합니다. IaC를 사용하면 리소스를 수동으로 배포하고 구성하는 것에 비해 복구 시간과 오류 가능성이 줄어듭니다.

테스트 및 드릴

DR 계획과 광범위한 안정성 전략의 유효성을 정기적으로 검사하고 테스트하는 것이 중요합니다. 모든 인적 프로세스를 훈련에 포함시키고 기술 프로세스에만 집중하지 마세요.

재해 시뮬레이션에서 복구 프로세스를 테스트하지 않은 경우 실제 재해에서 복구 프로세스를 사용할 때 큰 문제가 발생할 가능성이 높습니다. 또한 DR 계획 및 필요한 프로세스를 테스트하여 RTO의 타당성을 확인할 수 있습니다.

자세한 내용은 안정성 테스트 전략 설계에 대한 권장 사항을 참조 하세요.

관련 콘텐츠