클라우드 솔루션 설계자는 광범위한 오류로부터의 복구가 의도적으로 계획, 설계 및 DR(재해 복구) 계획으로 문서화되도록 하는 데 핵심적인 역할을 합니다. 실패의 경우, 해당 계획의 품질은 이벤트가 일시적인 차질인지 아니면 평판 및 금융 위기가 되는지에 영향을 미칩니다.
이 계획은 비즈니스 우선 순위에 따라 안내되고 측정 가능한 목표에 따라 관리되는 전략을 기반으로 해야 합니다. 이 문서에서는 압력을 받고 비즈니스 연속성을 방어하는 사고방식 전환으로 서비스를 복원하는 기본 사례부터 시작하여 실용적인 DR 계획을 개발하는 과정을 안내합니다.
이 문서에서는 기술 완화 및 프로세스를 통해 비즈니스 연속성을 달성하는 방법에 중점을 둡니다. 시작하기 전에 주요 전략을 검토하고 비즈니스에 적합한 전략을 선택합니다. 자세한 내용은 재해 복구에 대한 RE:09 아키텍처 전략을 참조하세요.
DR 계획은 효과적인 DR 계획의 필수 구성 요소 역할을 하는 인시던트 관리의 핵심 원칙을 기반으로 구축되어야 합니다. 인시던트 관리 계획 개발에 대한 지침은 중단에서 복구하기 위한 인시던트 관리 사례 개발을 참조하세요.
용어
계획 개발을 시작하기 전에 일반적인 어휘를 숙지하는 것이 좋습니다. DR 계획을 활성화할 때 명확한 통신 및 조정된 의사 결정을 가능하게 하려면 이러한 용어를 공유 언어로 설정합니다.
| 용어 | Definition |
|---|---|
| 활성-활성(핫 스탠바이) | 두 개 이상의 환경이 완전히 작동하고 여러 지역에서 동시에 라이브 트래픽을 제공합니다. 한 환경이 실패하더라도 다른 환경은 중단 없이 또는 거의 중단 없이 부하를 계속 처리합니다. |
| 액티브-패시브(콜드 스탠바이) | 실행되지 않고 활성화될 때 프로비전 및 데이터 복원이 필요한 환경입니다. 가장 낮은 비용, 가장 긴 복구 시간입니다. |
| 활성-수동(웜 스탠바이) | 실패하는 동안 빠르게 확장할 수 있는 최소 서비스를 실행하는 부분적으로 프로비전된 환경입니다. |
| 비즈니스 연속성 | DR, 직원, 통신 및 프로세스를 포함하는 중단 중 및 이후에도 중요한 작업을 계속하도록 하기 위한 전략입니다. |
| DR(재해 복구) 계획 | 단계별 작업, 역할, 책임, 장애 조치 시퀀스 및 통신 워크플로를 포함하여 특정 시스템을 복구하기 위한 상세하고 실행 가능한 절차입니다. |
| DR(재해 복구) 전략 | 워크로드 전반의 치명적인 오류에 대응하기 위한 목표, 원칙 및 복구 자세를 정의하는 고수준 접근 방식입니다. |
| DR 활성화 | 재해 복구 절차를 시작하기 위한 공식적인 결정으로, 일반적으로 경영진의 승인이 요구됩니다. |
| 장애 복구(failback) | 인시던트 해결 후 워크로드를 원래 기본 환경으로 반환하는 프로세스입니다. |
| 장애 조치(Failover) | 재해 발생 시 워크로드를 기본 환경에서 대기 환경으로 이동하는 프로세스입니다. |
| 복구 지점 목표(RPO) | 큰 손실을 초래하기 전에 허용할 수 있는 데이터 손실의 양입니다. RPO는 필수 데이터를 백업해야 하는 빈도를 결정합니다. |
| RTO(복구 시간 목표) | 기술 관련 재해 후 필수 액세스, 데이터 및 기능을 복원하는 데 걸리는 시간입니다. |
재해 복구란?
DR(재해 복구)은 주요 오류 이벤트 후 시스템 또는 중요한 부분을 복원하는 전략적이고 체계적인 접근 방식입니다.
클라우드 환경에서는 일시적인 오류가 정상입니다. 이러한 간단한 중단(종종 블립 또는 일시적인 오류라고 함)은 격리된 구성 요소를 사용할 수 없거나 예기치 않은 성능 저하를 초래할 수 있습니다. 일반적으로 사용자의 개입 없이 플랫폼 복원력 기능 및 기본 제공 자가 복구 메커니즘을 통해 해결됩니다.
그러나 재해는 다른 종류의 이벤트입니다. 범위가 넓고, 동시에 여러 시스템 또는 서비스에 영향을 미치며, 시스템을 중단시킬 수 있습니다. 이러한 이벤트에는 시스템의 기본 제공 자체 복구 복원력만으로는 충분하지 않을 때 활성화할 수 있는 잘 정의된 DR 계획에 따라 외부 개입 및 특수한 역할이 필요합니다. 몇 가지 예는 다음과 같습니다.
지역 전체 장애
제어 평면 접근 또는 서비스 관리 기능 상실
악의적인 활동 또는 심각한 잘못된 구성으로 인해 손상된 프로덕션 환경
시스템의 여러 계층에 영향을 주는 심각한 인프라 오류
확장된 서비스를 사용할 수 없게 하는 자연 재해 또는 지정학적 이벤트
관리되지 않은 작은 문제는 대규모 재해로 확대될 수 있습니다. 고급 모니터링 및 상태 모델링은 이러한 문제를 조기에 감지하고 완화하는 데 도움이 될 수 있지만 해당 항목은 이 문서의 범위를 벗어납니다. 자세한 내용은 상태 모델링을 참조하세요.
DR의 궁극적인 목표는 정의된 양적 메트릭 내에서 비즈니스 연속성을 유지하는 것입니다. 이 계획은 미리 정의된 절차, 명확한 통신 프로토콜 및 경영진 수준의 의사 결정이 필요한 조정된 노력이라고 생각합니다.
중요도 계층 선택
모든 워크로드(또는 일부)에 영웅적인 복구 계획이 필요한 것은 아닙니다. 복구는 중요도를 반영해야 합니다.
중요합니다
중요도는 비즈니스 의사 결정이며 해당 결정을 안내하는 데 도움이 되는 것은 사용자의 책임입니다. 워크로드가 수행하는 작업, 워크로드에 의존하는 사용자 및 중단되면 어떻게 되는지에 따라 달라집니다. Azure는 무엇이 중요한 작업인지 결정하지 않습니다.여러분이 결정합니다. 중단이 수익에 타격을 주거나, 고객 신뢰를 손상시키거나, 규정 준수를 중단하는 경우 이는 중요한 시스템입니다. 그 결정을 소유하고, 염두에 두고 디자인하십시오.
오버 엔지니어링 저영향 서비스는 리소스를 낭비합니다. 영향력이 높은 것을 준비하지 못한 경우 심각한 결과를 초래할 수 있습니다. 핵심은 비즈니스 영향에 따라 복구 전략의 크기를 조정하는 것입니다. 다음 분류 계층을 시작점으로 사용하여 중요도를 평가하고 재해 복구 투자를 적절하게 조정합니다.
계층을 정량화하는 일반적인 방법은 SLO(서비스 수준 목표)를 통해서이며, 종종 '99.999%'(99.999%), '네 아홉'(99.99%) 등으로 표현됩니다. 이러한 백분위수는 지정된 워크로드에 필요한 가용성 수준을 광범위하게 나타냅니다.
DR 전략에서 가장 중요한 메트릭은 RTO(복구 시간 목표) 및 RPO(복구 지점 목표)이며, 둘 다 시간 단위로 정량화됩니다. RTO는 중단 후 시스템을 복원해야 하는 빈도를 정의합니다. 가동 중지 시간에 대한 조직의 허용 범위를 나타냅니다. RPO는 허용되는 데이터 손실의 양을 정의하고 데이터를 백업해야 하는 빈도를 반영합니다.
이 문서에서는 SLO 및 복구 메트릭이 이미 정의되어 있으며 계산 방법을 다루지 않는다고 가정합니다. 의미 있는 SLO를 설정하는 방법에 대한 지침이 필요한 경우 안정성 메트릭을 참조하세요.
계층 0: 중요 업무
업무 필수 계층에는 가동 중지 시간이 허용되지 않고 비용 절감이 연속성에 비해 부차적인 전체 워크로드나 특정 구성 요소가 포함됩니다. 이러한 시스템은 조직의 기본이며, 직접 수익을 창출하거나, 고객 신뢰를 보호하거나, 삶에 영향을 미칩니다. 일반적인 예로는 금융 플랫폼, 의료 시스템 및 보안 인프라가 있습니다.
이 계층은 RTO가 초 단위로 측정되고 RPO가 0에 가까워지는 99.99%이상의 SLO를 요구합니다. 이러한 요구 사항을 충족하려면 일반적으로 활성-활성 다중 지역 배포가 필요하므로 사용자가 중단 없이 즉시 복구할 수 있습니다.
중요 업무용 시스템이 실패하면 수익 손실, 평판 손상 또는 규제 노출과 같은 결과가 즉각적이고 중요합니다.
계층 1: 중요 비즈니스용
중요 비즈니스용 시스템은 일상적인 운영 및 고객 환경에 필수적이지만 중요 업무용 시스템과 달리 복구가 빠르고 데이터 손실이 최소화되는 한 짧은 중단 기간을 허용할 수 있습니다. 이러한 시스템은 종종 전자 상거래 플랫폼, 고객 연결 애플리케이션 및 파트너 포털과 같은 수익 인센티브에 의해 구동됩니다.
일반적으로 약 99.95%SLO가 필요하며 RTO 및 RPO는 분 단위로 측정됩니다. 활성-활성 또는 웜 스탠바이 배포의 조합은 종종 복원력과 비용의 균형을 맞추는 데 활용됩니다.
짧은 중단은 살아남을 수 있지만 이 계층의 연장된 가동 중지 시간은 수익, 사용자 만족도 및 브랜드 신뢰도에 직접적인 영향을 줍니다. 예측 가능성 및 복구 속도는 매우 중요합니다.
계층 2: 비즈니스 운영
비즈니스 운영 시스템은 내부 팀과 프로세스를 지원합니다. 직접적인 고객 연결은 아니지만 생산성과 운영 연속성에 필수적입니다. 일반적인 예로는 보고 플랫폼, 내부 대시보드 및 관리 도구가 있습니다.
이러한 시스템은 일반적으로 약 99.9%SLO를 대상으로 하며 RTO 및 RPO는 몇 시간 단위로 측정됩니다. 활성-수동 구성과 웜/콜드 배포 전략이 일반적이며, 이 경우 보조 환경은 필요할 때까지 비활성 상태로 유지되어 복구 속도보다 비용 최적화에 중점을 둡니다.
이 계층의 중단이 고객에게 즉시 영향을 주지는 않지만 중단이 길어질수록 비즈니스 속도가 느려질 수 있습니다. 즉각적이지 않더라도 적시에 복구하는 것이 중요합니다.
계층 3: 관리
관리 시스템은 백그라운드 작업을 지원하거나 긴급하지 않은 사용 사례를 제공하는 중요하지 않은 워크로드입니다. 일반적으로 보관 플랫폼, 샌드박스 환경, 교육 포털 또는 가용성이 시간이 중요하지 않은 일괄 처리 도구가 포함됩니다.
SLO가%99.9 미만인 경우 이러한 시스템은 시간에서 며칠까지의 RTO와 시간 단위로 측정된 RPO를 사용하여 더 긴 복구 기간을 허용합니다. 가장 비용 효율적인 방법은 일반적으로 백업 및 복원이며, 복구 가능성을 유지하면서 지속적인 인프라 비용을 최소화합니다.
이 계층의 지연은 일반적으로 허용되지만 데이터 무결성은 여전히 보호되어야 합니다. 이러한 시스템은 중단될 경우 비즈니스를 중단하지 않을 수 있지만 완전히 손실되면 시간이 지남에 따라 규정 준수 위험 또는 지식 격차가 발생할 수 있습니다.
워크로드 분류
DR 전략을 시작하기 전에 실제 비즈니스 영향 및 복구 요구 사항에 따라 워크로드를 분류합니다.
먼저 워크로드의 모든 사용자 흐름을 나열합니다. 수행하는 작업, 해당 작업을 사용하는 사용자 및 작동 중단이 발생하면 어떻게 되는지 문서화합니다. 동일한 워크로드 내의 흐름이 다르면 개별 비즈니스 영향 및 중요도에 따라 다른 재해 복구 전략이 필요할 수 있습니다.
비즈니스 이해관계자와 협력하여 이러한 분류에 대한 승인을 받으세요. 기술적인 의견뿐만 아니라 실제 비즈니스 결과에 따라 RTO 및 RPO 대상을 확인합니다. 그들의 약속은 기초를 설정하고 DR 전략은 이를 기반으로 합니다. 비즈니스 위험에 대한 조정이 없으면 기술 응답에 방향이 부족합니다.
이러한 분류를 정기적으로 검토합니다. 비즈니스 요구 사항이 진화함에 따라 그에 따라 DR 계획을 업데이트합니다.
이러한 마찰 지점에 주의
다음은 주의해야 할 몇 가지 주요 마찰 포인트입니다. 그렇지 않으면 DR 계획이 올바른 결과없이 비용이 많이 드는 운동으로 바뀔 수 있습니다.
기대와 예산이 일치하지 않습니다. 이해 관계자가 콜드 대기 예산에서 뜨거운 대기 성능을 기대하지 않도록 기대치를 적절하게 설정합니다. RTO/RPO 약속과 예산 간의 격차는 위험과 실망으로 이어질 수 있습니다.
공유 서비스 종속성은 체인을 끊을 수 있습니다. DR 계획은 가장 약한 구성 요소만큼 효과적입니다. 워크로드가 적절한 장애 조치(failover) 전략이 없는 공유 또는 타사 리소스에 의존하는 경우 재해 발생 시 취약성이 발생할 수 있습니다.
DR 활성화 기준은 명확해야 합니다. 책임 목록에 나열된 모든 사람은 조건에 대해 명확해야 합니다. 이렇게 하지 않으면 복구를 시작하는 데 주저할 수 있으며 이로 인해 불필요한 지연이 발생할 수 있습니다.
장애 복구는 장애 조치만큼 중요합니다. 많은 사람들이 장애 조치(failover)를 단방향 컷오버로 처리하는 데 중점을 두지만 때로는 장애 복구(failback)가 실행 가능한 옵션입니다. 그러나 기본 사이트로 작업을 반환하는 경우 복잡성이 더 많이 발생하는 경우가 많습니다. 장애 복구 절차를 계획하고 테스트해야 합니다. 좋은 지침은 제어된 프로세스를 통해 장애 복구를 관리하는 동안 장애 조치(failover)를 자동화하는 것입니다.
복구 비용 최적화
재해 복구 비용은 워크로드의 중요도에 따라 확장됩니다.
계층 0(중요 업무용) 은 가장 높은 비용으로 제공되며, 이는 예상된 것입니다. 활성-활성 배포와 중복 인프라는 지출을 크게 증가시키지만, 거의 0에 가까운 가동 중지 시간을 제공합니다. 비용 최적화와 관련하여 가장 좋은 옵션은 예약 인스턴스 또는 해당되는 Azure 하이브리드 혜택과 같은 표준 사례입니다.
디자인의 단순성을 위해 노력합니다. 잘 정의된 요구 사항을 넘어서는 오버 엔지니어링은 숨겨진 비용이 조용히 쌓이는 곳입니다. 코드로서의 인프라, 자동화된 배포 및 테스트와 같은 기본 사례는 선행 엔지니어링 노력을 도입합니다. 이러한 노력은 새로운 기능을 제공하는 것과 경쟁할 수 있지만 강력한 운영에 대한 투자를 손상시키는 것은 선택 사항이 아닙니다.
계층 1(비즈니스 크리티컬)은 비용을 절감하는 대기 시스템을 활용하여 균형을 제공합니다.
보조 지역에 컴퓨팅 리소스를 일부 규모로 배치하고, 필요시에만 자동 크기 조정을 활성화하여 웜 대기 상태에서 기본 용량을 낮춥니다. 이 방법은 24/7 용량 모두에 대한 비용 지출을 줄입니다.
수동으로 트리거된 장애 조치 프로세스를 오케스트레이션된 런북과 함께 사용하여, 완전히 자동화된 장애 조치보다 복잡성과 지속적인 운영 비용을 줄일 수 있습니다. 정기적인 장애 조치(failover) 테스트는 비효율성을 식별하는 데 도움이 됩니다.
계층 2(비즈니스 운영) 는 콜드 대기 설정 및 종량제 옵션(예: 스폿 인스턴스 및 소비 가격 책정)을 사용하여 비용을 최적화하는 데 중점을 둡니다. 유휴 리소스에 대한 비용을 지불하지 않도록 필요한 경우에만 보조 지역에서 PaaS 컴퓨팅의 프로비저닝을 자동화합니다. 불필요한 장애 조치(failover)를 방지하기 위해 명확한 재해 조건 및 장애 조치 프로세스를 정의합니다. 정기적인 테스트를 통해 복구 목표가 충족되고 비용을 절감할 영역을 강조 표시합니다.
계층 3(관리) 은 복구 기간이 긴 백업 및 보관 스토리지를 사용하여 비용 절감의 우선 순위를 지정합니다. 보조 인프라 없이 영구 데이터를 보호하기 위해 2차 지역에서 복제된 백업과 Azure Backup 볼트를 활용합니다. 복원 프로세스를 정기적으로 테스트하여 비용을 최소한으로 유지하면서 안정성을 보장합니다.
계층이 무엇이든 적절한 도구를 사용하여 비용을 검토합니다. Microsoft Cost Management 및 Azure Advisor와 같은 도구를 사용하여 모든 계층에서 지출을 모니터링, 예측 및 최적화합니다. 리소스에 태그를 지정하고 예산 임계값을 설정하여 책임 및 차지백 모델을 더 쉽게 추적할 수 있도록 합니다. Microsoft 권장 태그에 대한 자세한 내용은 중요 업무용 워크로드 태그 지정을 참조하세요.
DR 계획 문서화
강력한 DR(재해 복구) 계획은 전략을 결정적인 작업으로 바꿉니다. 활성화는 자동화된 경고와 사용자 감독의 조합으로 시작됩니다. 관찰성 도구는 성능 저하와 같은 잠재적인 문제에 플래그를 지정하고 운영 팀이 조사할 경고를 트리거합니다. 대시보드에서 변칙을 검토하고 상황을 평가합니다. 문제가 더 광범위하거나 더 심각해 보이면 에스컬레이션되고 추가 팀이 참여할 수 있습니다. 충분한 증거가 있으면 DR 리더는 재해를 공식적으로 선언하고 시스템 연속성을 유지하기 위해 구조화된 장애 조치 프로세스를 시작합니다.
이를 가능하게 하려면 모든 DR 계획에는 명확한 Runbook, 잘 정의된 통신 계획 및 구조적 에스컬레이션 경로의 세 가지 필수 구성 요소가 포함되어야 합니다.
DR 통신 계획
통신 계획은 적절한 정보가 중단 중에 적절한 시기에 적절한 사람에게 도달하도록 보장합니다. 조정을 지원하고, 혼동을 줄이며, 복구 프로세스 전반에 걸쳐 관련자에게 정보를 제공합니다. 계획에는 다음과 같은 측면이 포함됩니다.
활성화 조건 및 승인. DR 이벤트로 간주될 수 있는 항목을 규정합니다. DR 프로세스를 트리거할 권한이 있는 사용자를 식별합니다. 에스컬레이션 경로 및 의사 결정 검사점을 문서화합니다.
역할 및 책임. 의사 소통의 책임자와 그 대상자를 정의합니다.
주요 이해 관계자. 직원, 리더십, 파트너 및 고객과 같은 주요 내부 및 외부 대상 그룹을 식별합니다.
통신 채널. 이메일, SMS 등과 같은 기본 및 백업 방법을 설정합니다. 또한 해당 채널에 대한 업데이트 빈도를 설정합니다.
알림 및 템플릿. 업데이트를 보내고 이메일, 상태 페이지 및 인시던트 채널에 대해 미리 승인된 메시징 템플릿을 준비하는 시기를 간략하게 설명합니다.
에스컬레이션 및 연속성. 다른 사람을 사용할 수 없거나 상황이 빠르게 변경되는 경우 문제를 에스컬레이션하는 구조화된 방법이 있는지 확인합니다. 통신 계획은 적절한 세부 정보 및 빈도와 별도의 채널을 사용하여 내부 및 외부 이해 관계자를 모두 해결해야 합니다. 내부 통신은 비즈니스 영향, 타임라인 및 리소스 요구 사항에 초점을 맞춘 경영진 및 비즈니스 사용자에게 정기적인 업데이트를 제공합니다. 외부 통신은 고객, 파트너 및 규제 기관과 조정되며 복원을 위한 현재 상태 및 현실적인 기간을 포함합니다.
DR 실행 문서
강력한 Runbook은 추상 전략을 구조로 대체하고 팀이 압력을 받고 대응할 수 있도록 합니다. 명확하게 하고, 실용적으로 만들고, 작동하는지 확인합니다. 간단한 개요로 시작하고 점진적으로 빌드합니다. 비즈니스, 보안 및 운영과 협업하여 전체 범위를 보장합니다.
문서 장애 조치(failover) 및 장애 복구(failback) 절차 장애 조치(failover)를 시작하기 위한 단계별 기술 지침을 작성합니다. 링크 또는 참조를 사용하여 실행할 참조 도구 및 스크립트입니다. 장애 복구(failback) 및 조정된 절체 단계를 시작하기 위한 기준을 설정합니다.
장애 조치(failover) 실행을 위한 단계별 프로세스를 개발합니다.
조치 소유자 기준 1. 인시던트 검색 모니터링/작업 인시던트가 경고 또는 사용자 보고서에 의해 트리거됩니다. 2. 심각도 평가 인시던트 관리자 인시던트 분류 테이블을 사용하여 심각도 수준을 확인합니다. 3. 중단 선언(필요한 경우) 선임 Ops/BCDR 책임자 심각도가 높고 중요한 인시던트에 대해서만 중단을 선언합니다. 4. 관련자에게 알림 커뮤니케이션 리드 알림에 대해 설정된 통신 계획을 따릅니다. 5. Runbook 실행 시작 운영 팀 자동화된 DR Runbook 및 수동 단계를 포함하여 DR Runbook 실행을 시작합니다. 6. 보조 인프라 준비 운영 팀 보조에서 인프라 구성을 배포 및/또는 확장하고 유효성을 검사합니다. 7. 데이터 무결성 확인 운영 팀 필요한 경우 백업에서 데이터를 복원하고 데이터 무결성 및 RPO 준수의 유효성을 검사합니다. 8. 애플리케이션 복구 Ops/QA 팀 필요한 경우 보조 애플리케이션을 배포하고 활성화합니다. 올바른 작업 및 모든 종속성 유효성 검사 9. 교통 중단 운영 팀 사용자를 보조 환경으로 전환합니다. 필요한 경우 DNS 레코드 업데이트 10. 인시던트 및 문서 닫기 인시던트 관리자 사후 평가를 수행하고 인시던트 레코드를 업데이트합니다. 마찬가지로 장애 복구 결정 및 실행 프로세스(사용 가능한 주 지역)를 만듭니다.
조치 소유자 조건/결정 지점 1. 주 지역 상태 모니터링 운영/클라우드 팀 주 지역이 모든 상태 검사를 통과하고 완전히 작동하는지 확인합니다.
자동화된 모니터링 도구 및 수동 유효성 검사를 사용하여 준비 상태를 확인합니다.2. 비즈니스 영향 평가 애플리케이션 소유자/비즈니스 연속성 트래픽이 적은 기간 및 필요한 승인을 포함하여 장애 복구(failback)에 대한 비즈니스 준비 상태를 확인합니다.
이해 관계자와 협력하여 타이밍이 비즈니스 요구 사항에 맞게 조정되도록 합니다.3. 데이터 동기화 검토 데이터베이스/인프라 팀 보조 지역의 데이터가 주 지역과 동기화되고 RPO/RTO 요구 사항을 충족하는지 확인합니다.
복제 상태 대시보드를 사용하여 데이터 일관성을 확인합니다.4. 장애 복구 계획 전달 인시던트 관리자 타임라인 및 잠재적 영향을 포함하여 계획된 장애 복구(failback)를 관련자에게 알립니다.
통신에 전자 메일, Teams 또는 인시던트 관리 도구를 사용합니다.5. 주 지역 준비 인프라/클라우드 팀 기본 지역에서 인프라, 보안 및 애플리케이션 구성 요소가 준비되어 있는지 확인합니다.
장애 복구 전 검사 목록을 실행하여 완전한 준비 상태를 보장합니다.6. 장애 복구 시작 운영/클라우드 팀 승인된 변경 요청과 모든 조건이 충족되는 경우에만 진행합니다.
트래픽 및 워크로드를 주 지역으로 리디렉션하기 시작합니다.7. 장애 복구 진행률 모니터링 운영/클라우드 팀 전환 프로세스 중에 오류, 대기 시간 또는 데이터 손실을 모니터링합니다.
대시보드 및 경고 시스템을 사용하여 진행 상황을 추적합니다.8. 애플리케이션 기능 유효성 검사 애플리케이션 소유자/QA 애플리케이션 및 서비스가 주 지역에서 완벽하게 작동되는지 확인합니다.
스모크 테스트 및 회귀 테스트를 실행하여 기능의 유효성을 검사합니다.9. 인시던트 완료 및 닫기 인시던트 관리자 모든 시스템이 안정적이고 관련자에게 정보를 제공하며 설명서가 업데이트되었는지 확인합니다.
사후 분석을 완료하고 학습된 교훈을 캡처합니다.상태 유효성 검사 및 준비 검사를 설정합니다. 장애 조치(failover) 후 서비스 기능을 확인하는 방법을 정의합니다. 애플리케이션 수준, 인프라 및 데이터 무결성 검사를 포함합니다.
복구 후 계획 및 검토 임시 환경을 정리하는 작업에 대해 간략하게 설명합니다. 해당하는 경우 데이터 조정을 문서화합니다. 근본 원인 분석 및 DR 디브리프를 예약합니다.
팁 (조언)
DR Runbook을 프로덕션 코드처럼 처리합니다. 버전 지정하고 액세스할 수 있도록 합니다. Git 또는 버전이 지정된 wiki와 같은 버전 제어 도구를 사용하여 업데이트를 추적하고 시간에 따른 정확도를 보장합니다. 마찬가지로, 가동 중단 시에도 운영 매뉴얼에 언제든 접근할 수 있도록 준비해야 합니다. 오프라인 또는 인쇄 가능한 버전을 포함하여 여러 형식으로 저장하면 팀이 가장 중요한 경우에 액세스할 수 있습니다.
재해 복구(DR) 에스컬레이션 계획
재해 복구 중에 속도와 명확성이 전부입니다. 에스컬레이션 계획을 사용하면 계획에 따라 상황이 진행되지 않을 때 적절한 사용자에게 신속하게 경고를 받을 수 있습니다.
에스컬레이션 트리거. 누락된 복구 중요 시점, 중요한 시스템 오류 또는 응답하지 않는 공급업체 등 에스컬레이션 시기를 정확하게 정의합니다.
지휘 계통. 식별된 역할 및 연락처 목록에서 연락할 순서를 지정합니다. 즉, 기본, 보조 및 백업 담당자를 통해 문제를 에스컬레이션하는 방법입니다. 응답 시간 기대치도 포함됩니다. 예를 들어 전화 또는 응급 통신 플랫폼에서 15분 이내에 DR 관리자에게 전화합니다.
인시던트 심각도 수준 사소한 문제가 시스템을 방해하지 않도록 영향으로 인시던트를 분류하고 주요 문제는 리더십에서 즉각적인 주의를 기울입니다.
예제 템플릿은 다음과 같습니다.
| 심각도 수준 | Description | 예시 | 중단 선언 발생 요인 | 관련자에게 알림 |
|---|---|---|---|---|
| Low | 경미한 서비스 성능 저하 | 짧은 지연 시간 급증 | 공식 선언 없음 | 운영 팀 |
| 미디엄 | 부분 서비스 성능 저하 | 단일 서비스 오류 | 인시던트 기록, 관찰 중 | Ops, 비즈니스 리드 |
| High | 주요 중단, 광범위한 영향 | 다중 서비스 실패 | 공식 중단 선언 | 모든 이해 관계자, 고객 |
| 위험 | 총 손실, 비즈니스에 중요한 | 지역별 Azure 오류 완료 | 즉시 선언, 임원급 | 모든 이해 관계자, Exec 팀 |
정기적으로 테스트하고 계획 개선
재해 복구는 운영 분야입니다. 테스트되지 않은 DR 계획은 이론적이고 입증되지 않은 상태를 유지합니다.
시나리오를 시뮬레이션하고 팀 역할을 명확히 하기 위해 Runbook을 정기적으로 연습합니다.
전체 또는 부분 페일오버 훈련을 예약하여 실제 복구 과정 및 일정의 유효성을 검증합니다. 계획된 장애 조치(failover)는 원활한 시스템 전환을 연습하기 위해 지역 가동 중단을 시뮬레이션합니다. Azure Chaos Studio와 같은 도구는 계획되지 않은 오류를 테스트하고 시스템이 어떻게 반응하는지 확인하는 데 사용됩니다.
모든 테스트 후에 데이터를 확인하여 손실되거나 손상된 것이 없는지 확인합니다. 검색된 누락 사항 또는 문제를 캡처한 후, 아키텍처와 Runbook을 즉시 업데이트하세요.
백업 및 복원을 위한 복구 전략
백업 및 복원 전략은 모든 복구 전략의 일부여야 합니다.
제안된 작업
이를 모든 계층의 기초로 사용합니다. 각 단계에는 명확한 목표와 유효성을 검사하는 방법이 포함되어야 합니다.
| 활동 | 구성 / 설정 | Validation |
|---|---|---|
| 백업 정책 및 보존 구성 | - RPO 요구 사항에 맞는 인프라 및 데이터베이스에 대한 백업 일정 및 보존 기간 구성 - VM, Azure Files 및 Blob Storage에 Azure Backup 사용 - 사용 가능한 경우 지리적으로 중복된 백업 저장소를 사용하는 등 보조 지역에 백업을 저장하십시오. |
- 백업 정책 실행 테스트 - 백업 완료 및 무결성 확인 - 보존 정책 적용 유효성 검사 |
| 비용 효율적인 스토리지 계층 구현 | - 자주 액세스하지 않는 데이터에 보관 또는 쿨 스토리지 계층 사용 - 백업 계층화 정책을 적용하여 이전 백업을 저렴한 옵션으로 전환 - 스토리지 비용을 최소화하도록 압축 및 중복 제거 구성 |
- 스토리지 비용 최적화 보고서 검토 - 계층화 정책 실행 확인 - 다른 스토리지 계층에서 데이터 검색 테스트 |
| 문서 복원 절차 | 자세한 복구 단계가 포함된 Runbook을 유지 관리하기 - 복원을 위한 대상 환경 정의 - 승인 및 에스컬레이션에 대한 연락처 목록 포함 |
- 테스트 복원 프로시저 설명서 정확도 - 연락처 정보 통화 확인 - 에스컬레이션 경로 및 승인 워크플로 테스트 |
| 백업 비용 및 규정 준수 모니터링 | - 백업 관련 리소스에 대한 예산 임계값 설정 - 백업 전용 태그를 적용하여 올바르게 추적할 수 있도록 함 - 규정 준수 요구 사항을 충족하도록 보존 정책 구성 |
- 매월 백업 비용 보고서 검토 - 예산 임계값의 효과성 점검 - 보존 정책 준수 감사 |
| 백업 시스템 유지 관리 및 감사 | - 백업 요구 사항에 대한 분기별 감사 수행 - 사용되지 않는 시스템 사용 중지 및 정책 조정 - 비즈니스 및 기술 변경에 따라 RPO/RTO 요구 사항 검토 및 업데이트 |
- 감사 결과 해결 확인 - 사용 중지된 시스템이 제대로 서비스 해제되는지 확인 - RPO/RTO 요구 사항 변경의 유효성을 검사할 수 있습니다. |
활성-수동(콜드 스탠바이)에 대한 복구 전략
활성-수동 콜드 스탠바이 배치는 필요할 때까지 보조 지역의 컴퓨트 리소스를 정지합니다. 이 방법은 RTO가 더 긴 지연을 허용할 수 있지만 복구는 여전히 안정적이고 반복 가능해야 하는 계층 2 또는 계층 3 워크로드에 적합합니다.
주 지역은 모든 프로덕션 트래픽을 처리하는 반면 보조 지역은 최소한의 실행 중인 리소스로 인프라 준비 상태를 유지하므로 재해 시나리오 중에 수동 활성화가 요구됩니다.
제안된 작업
백업 및 복원을 위한 복구 전략을 구축하고 이러한 지점을 다룹니다. 필요에 따라 확장합니다.
| 활동 | 구성 / 설정 | Validation |
|---|---|---|
| 기본 및 보조 지역 설정 | - 주 지역에 본격적인 워크로드 배포 - 주 네트워크 토폴로지, 정책 및 구성을 복제하다 - RBAC, 보안 기준, 모니터링 에이전트 및 정책이 일관된지 확인 - 컴퓨팅 리소스가 중지된 코드로 인프라 배포 |
- 보조 지역 인프라 준비 확인 - 지역 간 정책 일관성 테스트 - 네트워크 연결 및 라우팅 유효성 검사 |
| 지역 간 데이터 복제 설정 | - Azure SQL Database, PostgreSQL, MySQL, Cosmos DB에 대한 기본 제공 복제 사용 - 쌍을 이루는 지역 스토리지 복제에 GZRS 또는 RA-GZRS 사용하도록 설정 - 쌍을 이지 않은 지역에서 Blob Storage에 대한 개체 복제 구성 - Azure Cosmos DB에 대해 구성 가능한 일관성 수준으로 다중 지역 읽기/쓰기 설정 - 복제 지연 모니터링 및 데이터 일관성 유효성 검사 프로세스 구성 |
- RPO 대상에 대한 데이터 동기화 지연 테스트 - 복제 상태 및 대기 시간 메트릭 확인 - 지역 간 데이터 일관성 유효성 검사 - 장애 조치 시나리오에서 데이터 무결성 검증 |
| DR 환경 보호 및 규정 준수 유지 | - 모든 지역에서 데이터 보존 요구 사항 복제 - 지역 간 ID 및 액세스 패리티 유지 관리 - 장애 조치(failover) 중 및 이후 감사 기록 연속성 테스트 |
- 지역 간 보안 구성 감사 - 아이덴티티 장애 조치 시나리오 테스트 - DR 이벤트 중 준수 확인 - 감사 로그 연속성 유효성 검사 |
| 프로비저닝 자동화 및 작업 준비 | - 필요에 따라 자동화된 리소스 프로비저닝 환경에 대한 IaC 템플릿 정의 - 서비스 구성, 크기 조정 매개 변수 및 종속성 포함 - 활성화될 때 전체 부하를 충족하도록 크기 조정 대상 미리 정의 - IaC의 경우: Bicep, Terraform, ARM 템플릿 - 배포 자동화: 두 지역 모두에 대한 CI/CD 파이프라인 - Runbooks: DR 프로시저를 실행하기 위한 자동화 및 수동 단계 |
- 자동화된 프로비저닝 절차 테스트 - 컴퓨팅 시작 시간이 RTO 대상을 충족하는지 확인 - 서비스 종속성 활성화 시퀀스 유효성 검사 - 지역 간 IaC 배포 일관성 테스트 Runbook 실행과 타이밍의 유효성을 검사 |
| 준비 상태 및 상태 모니터링 | - 복제 상태 및 대기 시간 메트릭에 대한 경고 설정 - 보조 지역 인프라 상태 모니터링 - 모든 구성 요소에서 활성화 준비 추적 - 복제 상태에 대한 상태 검사 구현 - 자동 크기 조정 이벤트 및 트래픽 라우팅에 대한 경고 구성 - 관찰 도구가 두 지역을 모두 포함하는지 확인 |
- 모니터링 및 경고 시스템 테스트 - 인프라 상태 검사 확인 - 준비 상태 표시기 정확도 유효성 검사 - 관찰 가능성 유효성 검증 |
| 수동 장애 조치를 통해 부하 분산 장치를 구성 |
- 우선 순위 기반 라우팅이 있는 Azure Front Door 또는 Traffic Manager - 정상적인 조건에서 모든 프로덕션 트래픽을 주 지역으로 라우팅 - 장애 조치 시 수동으로 트래픽 전환을 트리거 합니다. |
- 트래픽 장애 복구 시나리오 테스트 - 라우팅 우선 순위 구성 확인 - DNS 전파 및 중단 시간 유효성 검사 |
| 수동 장애 조치(failover) Runbook 및 조건 정의 | 명확한 장애 조치 트리거 및 활성화 기준 설정 - 컴퓨팅 시작 및 DNS 업데이트를 비롯한 수동 활성화 단계 문서화 - 실패 또는 임시 활성화에 대한 롤백 프로시저 포함 |
- 장애 조치 실행서 테스트 실행 - 수동 활성화 절차 확인 - 롤백 프로세스 및 타이밍 유효성 검사 |
| 정기적으로 복원 프로세스 테스트 | - 백업 무결성의 유효성을 검사하기 위한 정기 복원 훈련 예약 - 스테이징 환경으로의 복원 포함 - 소요된 로그 시간 및 RTO 대상과 비교 |
- 분기별 복원 훈련 실행 - 복원 후 데이터 일관성 확인 - RTO 대상에 대한 문서 성능 |
활성-수동(웜 대기)에 대한 복구 전략
활성-수동 온 대기 배포는 장애 발생 시 신속하게 확장 가능한 최소 프로비전된 백업 환경을 유지 관리하여 비용과 복원력의 균형을 유지합니다. 이 방법은 가동 중지 시간을 줄이면서 지역 간 상시 중복성의 전체 비용을 방지합니다.
주 지역은 정상적인 조건에서 모든 프로덕션 트래픽을 처리하지만 보조 지역은 최소한의 리소스로 실행되며 재해 복구를 위해 활성화된 경우에만 확장됩니다.
제안된 작업
활성-수동(콜드 대기)에 대한 복구 전략을 구축하고 이러한 점을 다룹니다. 필요에 따라 확장합니다.
| 활동 | 구성 / 설정 | Validation |
|---|---|---|
| 부분 규모로 보조 지역 구성 | - 보조 지역에 실행 가능한 최소 컴퓨팅 공간 배포 | - 보조 지역 인프라 준비 확인 |
| 보조 지역에서 자동 크기 조정 사용 | - 컴퓨팅 리소스를 장애 조치 후 자동으로 늘리도록 크기 조정 규칙을 구성합니다. - 적절한 크기 조정 임계값 및 제한 설정 - 종속 서비스에 대한 시작 시퀀스 정의 |
- 장애 조치(failover) 훈련 중 확장 동작 테스트 - 강화 중에 리소스 가용성 확인 |
| 자동화된 장애 조치(failover) 절차 구성 | - 지원되는 경우 자동 장애 조치 전환 사용 - 다른 서비스에 대한 수동 장애 조치(failover) 절차 문서화 - 단계별 프로세스를 사용하여 오케스트레이션된 장애 조치(failover) Runbook 만들기 |
- 자동화된 장애 조치 메커니즘 검증 - 수동 장애 조치(failover) 절차 유효성 검사 - Runbook 실행 타이밍 및 정확도 확인 |
| 부하 분산 장치를 자동 장애 조치 기능으로 구성 |
- 자동 장애 조치 기능이 설정된 Azure Front Door 또는 Traffic Manager - 자동 트래픽 리디렉션에 대한 상태 검사 구성 |
- 트래픽 장애 복구 시나리오 테스트 - 라우팅 우선 순위 구성 확인 |
활성-활성 배포 시스템에 대한 복구 전략
활성-활성 배포는 각 인스턴스가 프로덕션 트래픽을 적극적으로 처리하면서 지역 간에 여러 워크로드 인스턴스를 실행하여 서비스 가용성을 최대화합니다. 이 디자인은 가동 중지 시간을 없애고 즉각적인 장애 조치(failover)를 가능하게 하지만 분산 시스템 전반에서 일관성, 라우팅 및 비용을 관리하기 위한 정확한 계획을 요구합니다.
다음 두 가지 배포 방법 중 하나를 선택합니다.
활성-활성(최대 용량): 두 개 이상의 지역에 걸쳐, 각 지역이 프로덕션 부하를 나누어 처리하고, 지역 장애 시 전체 부하를 흡수할 수 있도록 확장 가능한 미러된 배포 스탬프나 지리적 배포 단위입니다.
활성-활성(오버프로비전): 두 개 이상의 지역에 배포된 미러링된 배포 스탬프 또는 지오드입니다. 각 지역은 독립적으로 100% 트래픽을 처리하기 위해 항상 최대 용량으로 운영됩니다.
비고
활성-활성 시나리오에서 오류가 발생하면 부하가 나머지 인스턴스로 이동함에 따라 사용자 환경이 영향을 받지 않을 수 있습니다. 그러나 실패한 인스턴스를 복원하려면 재해 복구 작업이 여전히 필요합니다.
제안된 작업
활성-수동(웜 대기)에 대한 복구 전략을 기반으로 합니다. 필요에 따라 확장합니다.
| 활동 | 구성 / 설정 | Validation |
|---|---|---|
| 전체 용량으로 보조 지역 구성 | - 주 지역과 동등하게 완전한 용량으로 보조 지역 배포 | - 주 지역이 실패할 때 보조 지역이 전체 부하를 즉시 지원할 수 있는지 확인 |
| 활성 인스턴스 간에 트래픽을 분산하도록 부하 분산 장치 구성 |
- 대기 시간 기반 또는 가중 라우팅이 있는 Azure Front Door 또는 Traffic Manager - 엔드포인트당 구성된 상태 프로브 - 오류 감지 시 트래픽 자동 경로 변경 |
- 지역 간 페일오버(failover) 시나리오 테스트 - 상태 프로브 정확도 및 응답 시간 확인 - 시뮬레이트된 중단 시 트래픽 라우팅 유효성 검사 |
| 부하 분산 동작 구성 | - 정상 작업 중에 각 지역이 처리하는 문서 로드 임계값 - 피어 지역이 실패할 경우 예상되는 성능 및 규모 확대 동작 - 단일 지역 오류, 부분 서비스 중단, 네트워크 분할에서 시스템 동작 정의 |
- 부하 중인 지역별 오류 시나리오 테스트 - 성능 저하 제한 확인 - 네트워크 파티션 처리 테스트 |