이 문서에서는 클라우드 환경에서 장애 조치(failover) 와 장애 복구(failback )가 작동하는 방식에 대한 일반적인 개요를 제공합니다. 그러나 장애 조치(failover)를 이해하려면 먼저 중복성 및 복제를 이해해야 합니다. 이 문서를 계속 진행하기 전에 이러한 개념에 대해 알아보려면 중복성, 복제 및 백업을 참조하세요.
애플리케이션 및 데이터 복제본의 중복 복사본을 유지하는 일반적인 이유는 장애 조치( failover)를 수행할 수 있기 때문입니다. 장애 조치(failover)를 사용하면 비정상 인스턴스에서 정상 인스턴스로 트래픽 및 요청을 리디렉션할 수 있습니다. 그런 다음 원래 인스턴스가 다시 정상 상태가 되면 장애 복구를 수행하여 원래 구성으로 돌아갈 수 있습니다.
활성 및 수동 인스턴스 역할
장애 조치(failover)의 컨텍스트에서 인스턴스 는 데이터베이스와 같은 단일 구성 요소 또는 지역에서 서비스 배포를 구성하는 여러 구성 요소의 컬렉션일 수 있습니다. 전체 솔루션을 통해 다양한 방법과 다른 상황에서 해당 솔루션의 여러 부분을 장애 조치(failover)할 수 있습니다.
구성 요소 또는 장애 조치(failover) 및 장애 복구(failback)를 위해 구성된 구성 요소의 컬렉션에는 여러 인스턴스가 필요합니다. 이러한 각 인스턴스는 특정 역할을 가정합니다.
- 기본 또는 활성 인스턴스는 클라이언트에서 들어오는 요청을 제공하는 것과 같이 적극적으로 작동합니다. 일반적으로 한 번에 하나의 기본 인스턴스가 있습니다.
- 보조 또는 수동 인스턴스는 비활성 상태이지만 필요한 경우 주 인스턴스가 되도록 전환할 준비가 되었습니다. 여러 보조 인스턴스가 있을 수 있습니다.
수동 인스턴스를 구성하는 방법에는 여러 가지가 있습니다. 각 방법에는 복구 시간과 비용 및 운영 복잡성과 같은 기타 요인 간의 절충이 포함됩니다.
- 언제든지 프로덕션 트래픽을 수락할 수 있도록 설계된 핫 대기.
- 웜 대기는 프로덕션 트래픽을 거의 수락할 준비가 된 상태로 설계되었으나, 트래픽을 수락하기 전에는 일부 구성 변경 또는 스케일링 작업을 완료해야 할 수 있습니다.
- 파일럿 조명 대기는 최소 구성으로 부분적으로 배포되며 프로덕션 트래픽을 허용하기 전에 상당한 준비를 완료해야 합니다.
- 콜드 스탠바이는 전혀 배포되지 않을 수 있으며, 프로덕션 트래픽을 수용하기 위해서는 먼저 구성 요소가 배포되어야 합니다.
팁 (조언)
일부 솔루션은 활성-활성 접근 방식을 사용하도록 빌드됩니다. 즉, 여러 인스턴스가 모두 요청을 처리합니다. 모든 인스턴스가 항상 적극적으로 요청을 처리하므로 활성-활성 시스템에서는 장애 조치(failover)가 필요하지 않습니다.
장애 조치 범위
상황에 따라 다른 장애 조치(failover) 전략이 필요합니다. 이러한 가능한 전략을 설명하기 위해 데이터베이스의 데이터에 액세스하는 애플리케이션으로 구성된 예제 솔루션을 고려합니다. 애플리케이션 서버의 중복 복사본과 데이터베이스의 여러 복제본을 만들어 장애 조치(failover)에 대한 솔루션을 구성합니다. 다음으로 다음을 구성합니다.
- Azure 지역 내의 다양한 가용성 영역에 복사본 및 복제본을 배치하여 영역 중복성을 구현합니다.
- 전역 로드 밸런서를 사용하여 지역 간 장애 조치를 통해 지리적 중복성을 구현합니다.
다음은 일반 작업의 전체 아키텍처를 보여 주는 간소화된 다이어그램입니다.
상황에 따라 이 솔루션에서는 다양한 장애 조치 이벤트가 발생할 수 있습니다. 각각의 항목은 장애 조치 범위에 해당하며, 이는 장애 조치를 수행하는 구성 요소의 세분성을 나타냅니다.
활성 데이터베이스 복제본을 사용할 수 없게 되면 데이터베이스 복제본 장애 조치(failover)가 발생할 수 있습니다. 수동 복제본은 활성 복제본으로 승격됩니다. 일반적으로 애플리케이션은 새 활성 복제본으로 요청을 신속하게 다시 라우팅할 수 있습니다.
가용성 영역 장애 조치는 전체 가용성 영역에 중단이 발생할 경우 발생할 수 있습니다. 이 유형의 가동 중단은 모든 트래픽을 나머지 영역의 웹 서버로 라우팅해야 하며, 아직 활성 복제본이 아닌 경우 생존 영역의 데이터베이스 복제본이 활성 복제본이 되도록 합니다.
전체 주 Azure 지역에 치명적인 손실이 발생하면 리전 페일오버(Region Failover)가 발생할 수 있습니다.
이러한 각 범위는 장애 조치(failover) 형식을 제공하지만 고유한 장애 조치 요구 사항 및 프로세스가 있을 수 있습니다. 또한 Microsoft는 영역 중복 서비스를 사용하는 경우와 같은 일부 장애 조치(failover) 범위를 담당할 수 있지만, Azure 지역 간 장애 조치(failover)와 같은 광범위한 범위에서 장애 조치(failover)를 담당할 수 있습니다.
장애 조치(failover) 및 비즈니스 연속성 계획
비즈니스 연속성 계획의 일부는 장애 조치(failover)를 수행할 수 있는 다양한 범위를 포함하여 장애 조치 전략을 설계하는 것입니다.
일반적으로 비즈니스 연속성 계획에는 가용성 영역 내 또는 그 사이에 자동화된 장애 조치(failover) 절차가 포함되어야 합니다. 이러한 유형의 장애 조치(failover)는 고가용성 전략의 일부를 형성합니다. 예를 들어 데이터베이스의 활성 복제본이 실패하는 경우 자동화된 프로세스는 수동 복제본을 활성 복제본으로 승격할 수 있습니다. 그런 다음 웹 서버가 새 활성 복제본과 통신합니다. 마찬가지로 가용성 영역이 실패하면 나머지 영역을 사용하여 자동으로 복구하도록 많은 솔루션이 빌드됩니다.
전체 지역 가동 중단의 가능성이 낮은 경우와 같은 재해 시나리오에는 다른 장애 조치(failover) 절차가 사용됩니다. 지역 중단이 발생하면 들어오는 웹 요청을 두 번째 지역으로 전환하고, 데이터베이스를 보조 지역의 복제본으로 장애 조치(failover)를 트리거할 수 있습니다.
비즈니스 연속성 계획에 장애 조치(failover) 절차를 포함하려면 더 자세한 디자인 및 테스트를 수행해야 합니다. 자세한 내용은 비즈니스 연속성, 고가용성 및 재해 복구란?을 참조하세요.
계획 장애 조치 및 비계획 장애 조치
계획되지 않은 장애 조치(failover )는 다른 인스턴스를 사용하여 서비스를 복원할 수 있도록 구성 요소의 중단 중에 수행되는 장애 조치(failover)입니다. 계획되지 않은 장애 조치(failover)는 솔루션 설계 방식에 따라 가동 중지 시간 또는 데이터 손실이 발생하는 경우가 있습니다. 계획되지 않은 장애 조치(failover)를 수행하려면 오류를 감지하고 장애 조치(failover)를 트리거할 시기를 결정해야 합니다.
반면 계획된 장애 조치(failover)는 사용자가 사전에 트리거하는 것입니다. 패치 및 다시 부팅될 가상 머신과 같은 문제가 발생할 것으로 예상하여 이 작업을 수행할 수 있습니다. 계획된 장애 조치(failover)는 정기적인 유지 관리 절차의 일부이기 때문에 가동 중지 시간 및 데이터 손실에 대한 허용 오차가 낮을 수 있습니다.
장애 조치(failover) 작동 방식
장애 조치(failover)는 일반적으로 수동 또는 자동화된 시스템에서 수행할 수 있는 다음 단계로 구성됩니다. 이러한 각 단계에 대한 특정 세부 정보는 특정 시스템에 따라 달라집니다.
오류를 감지합니다(예기치 않은 장애 조치(failover)만 해당). 자동화된 장애 조치(failover)를 사용하려면 인스턴스를 사용할 수 없는 경우를 감지해야 하며, 이는 일반적으로 일종의 상태 검사를 기반으로 합니다. 다양한 서비스가 서로 다른 방식으로 건강 상태를 정의합니다. 예를 들어 일부 서비스는 인스턴스 간에 하트비트 이벤트를 사전에 보냅니다. 다른 구성 요소는 각 인스턴스를 정기적으로 프로브해야 합니다. 상태 모니터가 인스턴스가 실패했음을 감지하는 데 시간이 걸리는 경우가 많으며, 인스턴스가 단순히 사용 중이고 응답할 수 없는 경우 유예 기간을 지정하는 것이 중요합니다.
장애 조치(failover)를 선택합니다. 어느 시점에서는 장애 조치(failover)를 수행하기로 결정해야 합니다. 이 결정은 자동화된 도구 또는 수동으로 결정할 수 있습니다. 조직의 위험 허용 범위는 이 결정이 얼마나 빨리 내려지는지에 영향을 줄 수 있습니다. 위험에 대한 허용 오차가 낮다면 문제가 조금이라도 있을 경우 빠르게 장애 조치(failover)하도록 선택할 수 있습니다. 리스크 허용 범위가 높은 경우, 장애 조치 전환 전에 문제가 해결될 수 있는지 확인하기 위해 기다릴 수 있습니다.
새 주 인스턴스를 선택합니다. 나머지 인스턴스 중 하나가 새 주 인스턴스가 되어야 합니다.
경우에 따라 새 주 복제본이 될 인스턴스를 미리 정의했거나 전환할 인스턴스가 하나만 있을 수 있습니다.
다른 상황에서는 시스템에서 새 기본 인스턴스를 선택하는 자동화된 프로세스가 있습니다. 리더 선거를 포함하여 분산 컴퓨팅에 사용되는 여러 가지 합의 알고리즘이 있습니다. 이러한 알고리즘은 데이터베이스와 같은 관련 서비스 내에서 구현됩니다. 일부 시스템에서는 각 인스턴스가 새 주 복제본을 인식해야 하므로 선택 결과가 각 복제본에 자동으로 발표됩니다.
리디렉션 요청. 요청이 정상 인스턴스 또는 새 주 인스턴스로 전달되도록 환경을 구성합니다.
이렇게 하려면 요청을 보낼 위치를 알 수 있도록 다른 시스템을 업데이트해야 할 수 있습니다. 여기에는 비정상 인스턴스를 제외하도록 부하 분산 시스템을 업데이트하는 작업이 포함될 수 있습니다. 다른 상황에서는 DNS(도메인 이름 시스템)가 시스템의 활성 인스턴스에 요청을 보내는 방법으로 일반적으로 사용됩니다. 장애 조치 프로세스의 일부로 요청이 새 주 인스턴스로 라우팅되도록 일반적으로 DNS 레코드를 업데이트해야 합니다. DNS에는 업데이트된 DNS 레코드를 확인하는 빈도를 클라이언트에 지시하는 TTL( Time to Live ) 개념이 있습니다. TTL이 긴 값으로 설정된 경우, 클라이언트가 장애 전환에 대한 정보를 수신하는 데 시간이 걸릴 수 있으며, 이전 주 서버로 계속 요청을 보낼 수 있습니다.
장애 조치 프로세스에는 지연이 포함될 수 있으므로 가동 중지 시간(복구 지점 목표 또는 RTO) 및 데이터 손실(복구 지점 목표 또는 RPO)에 대한 요구 사항을 충족하도록 장애 조치 절차를 계획하는 것이 중요합니다. 자세한 내용은 비즈니스 연속성, 고가용성 및 재해 복구란?을 참조하세요.
Failback
장애 복구는 트래픽을 복원하고 원래 주 인스턴스로 다시 리디렉션하는 프로세스입니다.
경우에 따라 각 인스턴스가 주 인스턴스로 동일하게 작동할 수 있으므로 장애 복구(failback)할 필요가 없습니다. 그러나 특정 Azure 지역에서 애플리케이션을 실행해야 하고 지역 가동 중단 중에 일시적으로 다른 지역으로 장애 조치된 경우와 같이 장애 복구하는 것이 중요한 상황이 있습니다.
경우에 따라 장애 복구(failback)는 장애 조치(failover)와 동일한 방식으로 처리될 수 있습니다. 그러나 장애 복구는 다음과 같은 몇 가지 이유로 장애 조치(failover)보다 더 복잡할 수도 있습니다.
데이터 동기화 문제. 정기적인 장애 조치(failover) 중에도 이전 주 인스턴스는 여전히 일부 작업을 수행하거나 일부 데이터를 데이터 저장소에 기록했을 수 있습니다. 장애 복구 프로세스의 일부는 주 인스턴스와 보조 인스턴스 간의 충돌 또는 중복 관리를 포함하여 솔루션 전체에서 데이터 일관성과 무결성을 보장하는 것입니다.
데이터 동기화 문제에는 수동 개입이 필요한 것이 일반적입니다. 충돌하는 데이터가 필요하지 않은 경우 데이터베이스 또는 다른 상태를 다시 설정하도록 선택할 수 있습니다.
수정 단계입니다. 장애 조치(failover)가 발생하기 전에 주 데이터베이스에서 수정 단계를 시도한 경우 주 인스턴스를 알 수 없는 상태로 남겨 두었을 수 있습니다.
주 인스턴스가 일관되지 않은 상태에 있을 위험이 있는 경우, 복구 전에 알려진 정상 상태로 만들기 위해 주 인스턴스를 삭제하고 다시 배포해야 할 수 있습니다.
추가 가동 중지 시간입니다. 다시 구성이 필요하거나 데이터 일관성을 복원하는 작업으로 인해 장애 복구 프로세스 중 가동 중지 시간이 장애 조치(failover) 중보다 길어질 수 있습니다.
유지 관리 기간 동안 장애 복구 프로세스를 실행하거나 사용자에게 미리 변경 사항을 알리는 방법으로 이 문제를 완화할 수 있습니다. 또한 시스템이 온라인 상태인 동안 일부 준비 작업을 수행하고 필요한 가동 중지 시간을 최소화할 수 있습니다.
위험 허용 범위입니다. 중단으로 인해 장애 조치(failover)가 발생한 경우 장애 복구(failback) 중 가동 중지 시간 또는 기타 위험에 대한 조직의 허용 범위가 낮아질 수 있습니다.
비즈니스 관련자는 프로세스 전반에 걸쳐 상황을 계속 알려야 하며 장애 복구(failback) 필요성과 장애 복구 절차의 결과를 충분히 인식해야 합니다. 변경을 위해 적절한 시간을 협상할 수 있습니다.
Azure 서비스의 장애 조치(failover) 및 장애 복구(failback)
일반적으로 장애 조치(failover)가 작동하는 방식을 이해하는 것이 중요하지만, 각 Azure 서비스는 장애 조치(failover) 및 장애 복구(failback)에 다르게 접근할 수 있습니다. 특정 Azure 서비스가 안정성 관점에서 작동하는 방식에 대한 자세한 내용은 각 서비스의 안정성 가이드를 참조하세요.
많은 Azure 서비스는 특정 유형의 장애 조치(failover)를 자동으로 처리합니다. 예를 들어 영역 중복으로 구성된 Azure 서비스를 사용하는 경우 Microsoft는 가용성 영역 간에 자동으로 장애 조치(failover)를 수행합니다. 자세한 내용은 가용성 영역이란? 및 Azure 서비스 안정성 가이드를 참조하세요.
가상 머신을 사용하는 경우 Azure Site Recovery 는 가용성 영역 또는 다른 Azure 지역 간에 가상 머신과 해당 디스크를 복제하고 장애 조치(failover)를 수행할 수 있습니다.
여러 Azure 서비스를 함께 결합하는 고유한 솔루션을 설계하는 경우 장애 조치 요구 사항이 더 복잡해질 수 있습니다. 애플리케이션 계층 및 데이터베이스를 사용하여 솔루션을 디자인하고 다중 지역 활성/수동 아키텍처를 만들려고 하는 경우를 가정해 보겠습니다. 주 지역에서 중단되는 동안, 응용 프로그램과 데이터베이스가 모두 보조 지역으로 함께 장애 조치(failover)되는 것이 중요합니다. 사용하는 정확한 서비스에 따라 각 지역의 배포 간에 전환하기 위해 고유한 장애 조치(failover) 방법을 계획해야 할 수 있습니다. Azure는 Azure Front Door 및 Azure Traffic Manager를 통해 글로벌 트래픽 라우팅 및 부하 분산을 제공하며 장애 조치 요구 사항을 충족하는 기술을 선택할 수 있습니다. 각 서비스는 애플리케이션의 각 지역 인스턴스의 상태 모니터링을 지원하며 트래픽을 정상 인스턴스로 자동으로 다시 라우팅하도록 구성할 수 있습니다.
다음 단계
- 안정성에 대한 공동 책임에 대해 알아봅니다.
- Azure Well-Architected Framework에서 고가용성 다중 지역 디자인에 대한 권장 사항에 대해 알아봅니다.