이 페이지가 유용했습니까?
이 콘텐츠에 대한 여러분의 의견은 중요합니다. 의견을 알려주십시오.
추가 의견
1500자 남음
Azure 비즈니스 연속성 기술 지침

Azure 비즈니스 연속성 기술 지침

업데이트 날짜: 2015년 3월

저자: Patrick Wickline, Jason Roth

기고가 및 검토자: Luis Carlos Vargas Herring, Drew McDaniel, David Magar, Ganesh Srinivasan, Milan Gada, Nir Mashkowski ,Harsh Mittal, Sasha Nosov, Selcin Turkarslan, Cephas Lin, Cheryl McGuire, Bill Mathers, Mandi Ohlinger, Sidney Higa, Michael Green, Heidi Steen, Matt Winkler, Shayne Burgess, Larry Franks, Brad Severtson, Yavor Georgiev, Glenn Gailey, Tim Ammann, Ruppert Koch, Seth Manheim, Abhinav Gupta, Steve Danielson, Corey Sanders, John Deutscher

고가용성 및 재해 복구 요구 사항을 충족하려면 두 가지 지식이 필요합니다. 그 중 첫 번째는 클라우드 플랫폼의 기능에 대한 자세한 기술적 이해이고, 두 번째는 분산된 서비스를 적절하게 설계하는 방법입니다. 이 백서에서는 첫 번째 지식에 해당하는 Azure 플랫폼의 기능과 제한 사항에 대해 비즈니스 연속성의 측면에서 살펴봅니다. 아키텍처와 디자인 패턴에 대해서도 설명하지만 집중적으로 다루지는 않습니다. 디자인 지침은 다른 추가 리소스 섹션의 자료를 참조해야 합니다.

이 백서의 내용은 다음 섹션으로 구성됩니다.

  • 1. 로컬 오류에서 복구 : 갑작스럽게 부하가 증가하면 물리적 하드웨어(예: 드라이브, 서버 및 네트워크 장치) 전체에서 오류가 발생하고 리소스가 소진될 수 있습니다. 이 섹션에서는 이러한 조건에서 고가용성을 유지하기 위해 Azure에서 제공하는 기능에 대해 설명합니다.

  • 2. Azure 지역의 손실에서 복구: 광범위한 오류는 드물긴 하지만 가능한 일입니다. 전체 지역이 네트워크 오류 때문에 고립되거나 자연 재해로 인해 물리적인 피해를 입을 수 있습니다. 이 섹션에는 Azure의 기능을 사용하여 지리적으로 다양한 지역에 걸쳐 있는 응용 프로그램을 만드는 방법을 설명합니다.

  • 3. 온-프레미스에서 Azure로 복구: 클라우드는 재해 복구의 경제성을 크게 변화시키며 조직에서 Azure를 사용하여 복구를 위한 두 번째 사이트를 설정할 수 있도록 합니다. 여기에 드는 비용은 보조 데이터 센터의 구축 및 유지 관리 비용의 일부분에 불과합니다. 이 섹션에서는 온-프레미스 데이터 센터를 클라우드로 확장하기 위해 Azure에서 제공하는 기능에 대해 설명합니다.

  • 4. 데이터 손상 또는 실수로 인한 삭제에서 복구: 응용 프로그램에는 데이터를 손상시키는 버그가 있을 수 있으며 운영자가 중요한 데이터를 잘못 삭제할 수도 있습니다. 이 섹션에서는 데이터를 백업하고 이전 시점으로 복원하기 위해 Azure에서 제공하는 기능에 대해 설명합니다.

  • 5. 추가 리소스: Azure의 가용성 및 재해 복구를 다루는 다른 중요한 리소스를 제공합니다.

응용 프로그램 가용성에는 두 가지 주요 위협 요인이 있습니다. 그 중 하나는 드라이브 및 서버와 같은 장치의 오류이고, 다른 하나는 최대 부하 조건에서 계산 리소스 등의 중요 리소스 소진입니다. Azure는 이러한 경우에 가용성을 높이기 위해 리소스 관리, 유연성, 부하 분산 및 분할 기능을 결합하여 제공합니다. 이러한 기능 중에는 모든 클라우드 서비스에 대해 자동으로 수행되는 것도 있지만, 응용 프로그램 개발자가 기능을 활용하기 위해 추가 작업을 수행해야 하는 경우도 있습니다.

Azure에서 호스팅하는 모든 클라우드 서비스는 하나 이상의 웹 또는 작업자 역할로 구성된 컬렉션입니다. 지정된 역할의 인스턴스 중 하나 이상이 동시에 실행될 수 있습니다. 인스턴스의 수는 구성에 의해 결정됩니다. 역할 인스턴스는 FC(패브릭 컨트롤러)라는 구성 요소를 사용하여 모니터링되고 관리됩니다. FC는 소프트웨어 및 하드웨어 오류를 자동으로 감지하고 응답합니다.

  • 모든 역할 인스턴스는 자체 VM(가상 컴퓨터)에서 실행되고 GA(게스트 에이전트)를 통해 FC와 통신합니다. GA는 VM 사용, 상태, 로그, 리소스 사용, 예외 및 오류 조건을 비롯한 리소스 및 노드 메트릭을 수집합니다. FC는 구성 가능한 간격으로 GA를 쿼리하고 GA가 응답하지 못하는 경우 VM을 다시 부팅합니다.

  • 하드웨어 오류 시 관련된 FC는 영향을 받는 모든 역할 인스턴스를 새 하드웨어 노드로 이동하고 트래픽을 이 노드로 라우팅하도록 네트워크를 다시 구성합니다.

이러한 기능을 활용하기 위해 개발자는 모든 서비스 역할이 역할 인스턴스에 상태를 저장하지 않도록 해야 합니다. 대신에 모든 영구 데이터는 Azure 저장소 서비스 또는 Azure SQL 데이터베이스와 같은 지속성이 있는 저장소에서 액세스되어야 합니다. 이렇게 하면 어떠한 역할에서든지 요청을 처리할 수 있습니다. 이는 또한 서비스의 임시 상태나 영구 상태에서 불일치를 발생시키지 않고 역할 인스턴스의 작동이 언제든지 중단될 수 있음을 의미합니다.

역할 외부에 상태를 저장하는 요구 사항에는 몇 가지 의미가 있습니다. 예를 들어 Azure 저장소 테이블의 모든 관련 변경 내용이 가능한 경우 단일 엔터티 그룹 트랜잭션에서 변경되어야 함을 의미합니다. 물론 모든 변경을 항상 단일 트랜잭션에서 수행할 수 있는 것은 아닙니다. 역할 인스턴스 오류가 서비스의 영구 상태에 대한 둘 이상의 업데이트에 걸쳐 있는 장기 실행 작업을 중단시킬 때 문제를 일으키지 않도록 특별히 주의를 기울여야 합니다. 다른 역할이 이러한 작업을 다시 시도하려고 하는 경우 작업이 부분적으로 완료된 경우를 예상하고 처리해야 합니다.

예를 들어 여러 저장소에 데이터를 분할하는 서비스에서 분할된 데이터를 재배치하는 동안 작업자 역할의 작동이 중단되면 분할된 데이터의 재배치가 완료되지 않거나 다른 작업자 역할에 의해 처음부터 반복될 수 있으며 이로 인해 데이터가 분리되거나 손상될 수 있습니다. 문제를 방지하려면 장기 실행 작업이 멱등원이거나(즉, 부작용 없이 반복 가능하거나) 증분 다시 시작이 가능해야(즉, 가장 최근의 오류 지점에서 계속할 수 있어야) 합니다.

  • 멱등원이 되려면 장기 실행 작업이 실행되는 횟수에 관계없이 동일한 결과를 생성해야 하며 이는 실행 중에 중단되는 경우에도 마찬가지입니다.

  • 증분 다시 시작이 가능하려면 장기 실행 작업이 보다 작은 원자성 작업의 시퀀스로 구성되어야 하며 지속성이 있는 저장소에 진행률을 기록하여 각각의 이후 호출이 바로 전 호출이 중단된 곳에서 시작되도록 해야 합니다.

마지막으로 모든 장기 실행 작업은 성공할 때까지 반복적으로 호출되어야 합니다. 예를 들어 프로비전 작업은 Azure 큐에 배치된 다음 성공한 경우에만 작업자 역할에 의해 큐에서 제거될 수 있습니다. 가비지 수집이 중단된 작업에서 만든 데이터를 정리하기 위해 필요할 수도 있습니다.

각 역할에 대해 처음에 실행되는 인스턴스의 수는 각 역할의 구성에서 결정됩니다. 관리자는 예상된 부하에 따라 두 개 이상의 인스턴스와 함께 실행되도록 처음에 각 역할을 구성해야 합니다. 그러나 역할 인스턴스는 사용 패턴 변경에 따라 쉽게 확장되거나 축소될 수 있습니다. 이 작업은 Azure 포털, Windows PowerShell, 서비스 관리 API 또는 타사 도구를 사용하여 수행할 수 있습니다. FC는 자동으로 새 인스턴스를 프로비전하고 해당 역할의 부하 분산 장치에 삽입합니다.

Azure 자동 크기 조정(미리 보기)을 사용하여 Azure에서 부하에 따라 역할의 크기를 자동으로 조정하게 할 수 있습니다. 또한 자동 크�� 조정은 자동 크기 조정 응용 프로그램 블록(WASABi)과 같은 프레임워크를 사용하여 클라우드 서비스에 대해 프로그래밍 방식으로 기본 제공되고 구성될 수도 있습니다.

FC는 두 가지 유형의 파티션을 사용합니다. 그것은 바로 업그레이드 도메인과 오류 도메인입니다.

  • 업그레이드 도메인은 그룹에 포함된 서비스의 역할 인스턴스를 업그레이드하는 데 사용됩니다. Azure는 서비스 인스턴스를 여러 업그레이드 도메인에 배포합니다. 전체 업그레이드의 경우 FC는 한 업그레이드 도메인의 모든 인스턴스를 가져와서 업그레이드한 후 다음 업그레이드 도메인으로 이동하기 전에 다시 시작합니다. 이 방법은 업그레이드 프로세스 중에 전체 서비스를 사용할 수 없는 상황을 방지합니다.

  • 오류 도메인은 잠재적인 하드웨어 또는 네트워크 오류 지점을 정의합니다. 인스턴스가 두 개 이상인 역할의 경우 FC는 분리된 하드웨어 오류가 서비스를 중단시키는 것을 방지하기 위해 해당 인스턴스가 여러 오류 도메인에 분산되도록 합니다. Azure에서 서버 및 클러스터 오류에 대한 모든 노출은 오류 도메인에 의해 제어됩니다.

Azure SLA에 따라 Microsoft는 둘 이상의 웹 역할 인스턴스가 여러 오류 및 업그레이드 도메인에 배포된 경우 최소 99.95%의 시간 동안 외부 연결을 사용할 수 있도록 보장합니다. 업데이트 도메인과 달리 오류 도메인 수를 제어하는 방법은 없습니다. Azure는 자동으로 오류 도메인을 할당하고 할당된 도메인으로 역할 인스턴스를 분산합니다. 인스턴스가 최소한 두 개인 모든 역할이 SLA를 충족하도록 하기 위해 각 역할의 인스턴스 중 처음 두 개 이상이 여러 오류 도메인과 업그레이드 도메인에 배치됩니다. 이는 다음 다이어그램에서 확인할 수 있습니다.

오류 도메인 격리(단순 뷰)

웹 역할에 대한 모든 인바운드 트래픽이 클라이언트 요청을 역할 인스턴스로 분산하는 상태 비저장 부하 분산 장치를 통과합니다. 개별 역할 인스턴스에는 공용 IP 주소가 없고 인터넷에서 직접 주소를 지정할 수 없습니다. 웹 역할은 상태를 저장하지 않으므로 각 클라이언트 요청이 어떠한 역할 인스턴스로도 라우팅될 수 있습니다. StatusCheck 이벤트가 15초마다 발생합니다. 이 이벤트는 역할이 트래픽을 받을 준비가 되어 있는지, 아니면 사용 중이어서 부하 분산 장치 순환 순서에서 제거되어야 하는지를 나타내는 데 사용할 수 있습니다.

Azure 가상 컴퓨터는 고가용성과 관련하여 몇 가지 측면에서 PaaS 계산 역할과 다릅니다. 어떤 경우에는 고가용성을 보장하기 위해 추가 작업을 수행해야 합니다.

PaaS 역할 인스턴스와 달리 가상 컴퓨터 드라이브에 저장된 데이터는 가상 컴퓨터가 재배치되는 경우에도 지속됩니다. Azure 가상 컴퓨터는 Azure 저장소에서 Blob으로 존재하는 VM 디스크를 사용합니다. Azure 저장소의 가용성 특성 때문에 가상 컴퓨터의 드라이브에 저장된 데이터도 가용성이 높습니다. D: 드라이브는 이 규칙의 예외입니다. D: 드라이브는 VM을 호스팅하는 랙 서버에 실제로 있는 물리적 저장소이며 VM이 재활용되는 경우 이 드라이브의 데이터가 손실됩니다. D: 드라이브는 임시 저장에만 사용해야 합니다.

Azure는 PaaS 응용 프로그램의 계층(웹 역할 및 작업자 역할)을 기본적으로 이해하므로 오류 도메인과 업데이트 도메인으로 이러한 계층을 적절하게 분산할 수 있습니다. 반면에 IaaS 응용 프로그램의 계층은 가용성 집합을 사용하여 수동으로 정의해야 합니다. 가용성 집합은 IaaS의 SLA에 필요합니다.

Windows Azure VM에 대한 가용성 집합

위의 다이어그램에서 IIS 계층 및 SQL 계층은 서로 다른 가용성 집합에 할당됩니다. 이에 따라 각 계층의 모든 인스턴스가 오류 도메인으로 분산되어 하드웨어 중복성을 갖게 되며 업데이트 중에 작동이 중단되지 않습니다.

여러 VM으로 트래픽을 분산해야 하는 경우 클라우드 서비스에 VM을 그룹화하고 특정 TCP 또는 UDP 끝점에서 부하를 분산해야 합니다. 자세한 내용은 가상 컴퓨터 부하 분산을 참조하십시오. VM이 다른 원본에서 입력을 받는 경우(예: 큐 메커니즘) 부하 분산 장치가 필요하지 않습니다. 부하 분산 장치는 기본적인 상태 검사를 사용하여 트래픽이 노드로 전송되어야 하는지 여부를 결정합니다. 또한 고유한 프로브를 만들어 VM이 트래픽을 받아야 하는지 여부를 결정하는 응용 프로그램 관련 상태 메트릭을 구현할 수도 있습니다.

Azure 저장소는 Azure의 기준이 되는 영구 데이터 서비스로서 Blob, 테이블, 큐 및 VM 디스크 저장소를 제공합니다. Azure 저장소는 복제 및 리소스 관리를 함께 사용하여 단일 데이터 센터 내에서 고가용성을 제공합니다. Azure 저장소 가용성 SLA는 형식이 올바르게 지정된 데이터 추가, 업데이트, 읽기 및 삭제 요청이 최소 99.9%의 시간 동안 성공적으로 처리되며 저장소 계정이 인터넷 게이트웨이에 연결될 것을 보장합니다.

Azure 저장소의 데이터 지속성은 지역 내의 완전히 독립된 다양한 물리적 저장소 하위 시스템에 위치한 여러 드라이브의 모든 데이터에 대한 복사본을 여러 개 유지 관리하여 촉진됩니다. 데이터는 동기적으로 복제되며 모든 복사본은 쓰기가 승인되기 전에 커밋됩니다. Azure 저장소는 일관성이 매우 높으므로 읽기는 가장 최근의 쓰기를 반영하도록 보장됩니다. 또한 데이터의 복사본은 지속적으로 검사되어 저장된 데이터의 무결성에 위협이 되지만 흔히 간과되는 손상된 비트를 검색하고 복구합니다. 서비스는 Azure 저장소를 사용하기만 하면 복제의 혜택을 얻습니다. 로컬 오류에서 복구하기 위해 서비스 개발자가 추가 작업을 수행할 필요가 없습니다.

2012년 6월 7일 후에 만든 저장소 계정은 200TB까지 커질 수 있습니다(이전의 최대 크기는 100TB임). 추가 공간이 필요하면 여러 저장소 계정을 활용하도록 응용 프로그램을 디자인해야 합니다.

가상 컴퓨터의 VM 디스크는 Azure 저장소에서 페이지 Blob으로 저장되어 Blob 저장소와 동일한 지속성 및 확장성 속성을 제공합니다. 이 디자인은 가상 컴퓨터를 실행하는 서버에서 오류가 발생하고 VM이 다른 서버에서 다시 시작되어야 하는 경우에도 VM의 디스크에 있는 데이터가 지속되도록 합니다.

Microsoft Azure SQL 데이터베이스는 DaaS(database-as-a-service)를 제공하므로 응용 프로그램이 신속하게 프로비전하고, 데이터를 삽입하고, 관계형 데이터베이스를 쿼리할 수 있습니다. 익숙한 SQL Server의 기능 중 상당 부분을 그대로 제공하는 한편 하드웨어, 구성, 패치 및 복구의 부담을 줄였습니다.

note참고
Azure SQL 데이터베이스는 SQL Server와 1대1로 대응되는 기능을 제공하지는 않으며 클라우드 응용 프로그램의 고유한 요구 사항(유연한 확장, 유지 관리 비용을 절감하기 위한 DaaS(database-as-a-service) 등)을 만족하는 것이 목적입니다. 자세한 내용은 데이터 시리즈: Azure 가상 컴퓨터의 SQL Server와 SQL 데이터베이스 비교를 참조하십시오.

Azure SQL 데이터베이스는 노드 수준 오류에 대한 복구 기능을 기본적으로 제공합니다. 데이터베이스에 대한 모든 쓰기 작업은 쿼럼 커밋 기술을 사용하여 두 개 이상의 배경 노드에 자동으로 복제됩니다(주 데이터베이스와 하나 이상의 보조 데이터베이스에서 작업이 트랜잭션 로그에 기록된 것을 확인한 후 트랜잭션이 정상적으로 처리된 것으로 간주하고 반환해야 함). 노드 오류가 발생할 경우 데이터베이스가 자동으로 보조 복제본 중 하나로 장애 조치(failover)합니다. 이로 인해 클라이언트 응용 프로그램에 대한 일시적 연결 오류가 발생할 수 있으며, 바로 이러한 이유로 모든 Microsoft Azure SQL 데이터베이스 클라이언트에 일시적 연결 오류를 처리할 수 있는 기능을 구현해야 합니다. 자세한 내용은 SQL Azure와 함께 일시적인 오류 처리 응용 프로그램 블록 사용을 참조하십시오.

생성되는 각 데이터베이스는 최대 크기가 제한됩니다. 현재 사용할 수 있는 최대 크기는 150GB입니다. 데이터베이스가 최대 크기 제한에 도달하면 더 이상의 INSERT 또는 UPDATE 명령을 거부합니다(데이터를 쿼리하고 삭제하는 명령은 가능).

데이터베이스 내에서 Microsoft Azure SQL 데이터베이스는 패브릭을 사용하여 리소스를 관리합니다. 그러나 패브릭 컨트롤러 대신에 링 토폴로지를 사용하여 오류를 감지합니다. 클러스터에 있는 모든 복제본은 두 이웃 복제본을 갖고 있으며 이웃 복제본의 작동이 중단되었을 때 감지할 책임이 있습니다. 복제본의 작동이 중단되면 이웃 복제본이 RA(Reconfiguration Agent)를 트리거하여 다른 컴퓨터에서 복제본을 다시 만듭니다. 논리 서버가 컴퓨터에서 너무 많은 리소스를 사용하거나 컴퓨터의 물리적 제한을 초과하지 않도록 하기 위해 엔진 제한이 제공됩니다.

응용 프로그램에 150GB보다 큰 데이터베이스 제한이 필요한 경우 수평 확장 방식을 구현해야 합니다. Microsoft Azure SQL 데이터베이스를 사용한 수평 확장은 데이터를 여러 Azure SQL 데이터베이스에 수동으로 분할하여 수행됩니다. 이러한 수평 확장 방식은 규모에 따라 선형에 가까운 비용 증가를 달성할 수 있는 기회를 제공합니다. 데이터베이스는 가능한 최대 크기가 아니라 일일 평균 실제 사용 크기에 따라 요금이 청구되기 때문에 필요에 따라 탄력적인 성장이나 용량 증가와 함께 비용이 점차적으로 증가할 수 있습니다.

Azure 가상 컴퓨터(IaaS)에 SQL Server 2014를 설치하여 AlwaysOn 가용성 그룹 또는 데이터베이스 미러링과 같은 기존의 SQL Server 가용성 기능을 이용할 수 있습니다. Azure VM, 저장소 및 네트워킹은 가상화되지 않은 온-프레미스 IT 인프라와 다른 작업 특성을 갖고 있습니다. Azure에서 HADR SQL Server 솔루션을 성공적으로 구현하려면 이러한 차이점을 이해하고 이를 고려하여 솔루션을 디자인해야 합니다.

Azure에서 고가용성 솔루션을 구현하는 경우 Azure의 가용성 집합을 통해 고가용성 노드를 각기 다른 장애 도메인 및 업그레이드 도메인에 배치할 수 있습니다. 명확하게 말하자면 가용성 집합은 Azure 개념입니다. 이 방법은 AlwaysOn 가용성 그룹을 사용하든, 데이터베이스 미러링을 사용하든, 다른 것을 사용하든 간에 데이터베이스의 가용성을 높이기 위해 따라야 하는 최상의 방법입니다. 이 최상의 방법을 따르지 않는 경우 시스템의 가용성이 높다고 잘못 생각할 수 있지만 실제로는 모든 노드가 Azure 데이터 센터의 동일한 장애 도메인에 배치될 가능성이 있으므로 모든 노드에서 동시에 장애가 발생할 수 있습니다. 이 권장 사항은 로그 전달을 사용하는 경우 적용할 수 없습니다. 재해 복구 기능으로서 서버가 각기 다른 Azure 데이터 센터 위치(지역)에서 실행되도록 해야 하기 때문입니다. 이러한 데이터 센터 위치는 정의상 각기 다른 오류 도메인입니다.

Azure VM이 동일한 가용성 집합에 배치되려면 동일한 클라우드 서비스에서 Azure VM을 배포해야 합니다. 동일한 클라우드 서비스의 노드만 동일한 가용성 집합에 참가할 수 있습니다. 또한 VM은 서비스 복구 후에도 IP를 유지하여 DNS 업데이트 시간을 방지하도록 하기 위해 동일한 VNet에 있어야 합니다.

AlwaysOn 가용성 그룹 또는 데이터베이스 미러링을 사용하여 Azure에서 SQL Server 데이터베이스의 고가용성 솔루션을 구현할 수 있습니다.

다음 다이어그램에서는 Azure 가상 컴퓨터에서 실행되는 AlwaysOn 가용성 그룹의 아키텍처를 보여 줍니다. 이 다이어그램은 이 주제를 자세히 다룬 문서인 Azure 가상 컴퓨터의 SQL Server에 대한 고가용성 및 재해 복구에서 가져온 것입니다.

Windows Azure의 AlwaysOn 가용성 그룹

Microsoft Azure 포털에서 AlwaysOn 템플릿을 사용하여 Azure VM에서 종단 간 AlwaysOn 가용성 그룹 배포를 자동으로 프로비전할 수 있습니다. 자세한 내용은 Microsoft Azure 포털 갤러리의 SQL Server AlwaysOn 제품을 참조하세요.

다음 다이어그램에서는 Azure 가상 컴퓨터에서 데이터베이스 미러링을 사용하는 방법을 보여 줍니다. 이 다이어그램도 Azure 가상 컴퓨터의 SQL Server에 대한 고가용성 및 재해 복구 문서에서 가져온 것입니다.

Windows Azure의 데이터베이스 미러링
note참고
두 아키텍처에서는 도메인 컨트롤러가 필요합니다. 그러나 데이터베이스 미러링을 사용하면 서버 인증서를 사용하여 도메인 컨트롤러의 필요성을 없앨 수 있습니다.

Azure 클라우드 서비스는 Azure를 기반으로 작성되었으므로 앞에서 설명한 로컬 오류에서 복구하는 플랫폼 기능을 활용할 수 있습니다. 경우에 따라 지정된 시나리오에 대한 가용성을 높이기 위해 특정한 조치를 취할 수 있습니다.

ACS(액세스 제어 서비스) 2.0은 하루에 한 번씩 모든 네임스페이스의 백업을 만들어 안전한 외부 위치에 저장합니다. ACS 운영자가 ACS의 지역 데이터 센터 중 하나에서 복구할 수 없는 데이터 손실이 있음을 확인하는 경우 ACS는 가장 최근의 백업을 복원하여 고객의 구독을 복구하려고 시도합니다. 백업 주기 때문에 최대 24시간의 데이터 손실이 발생할 수 있습니다. 자세한 내용은 액세스 제어 서비스(재해 복구)를 참조하세요.

Azure 서비스 버스의 일시적 중단 문제를 완화하려면 지속성이 있는 클라이언트 쪽 큐를 만드는 것이 좋습니다. 이렇게 하는 경우 일시적으로 대체 로컬 저장소 메커니즘을 사용하여 Service Bus 큐에 추가할 수 없는 메시지를 저장합니다. 응용 프로그램은 서비스가 복원된 후 일시적으로 저장된 메시지를 처리하는 방법을 결정할 수 있습니다. 자세한 내용은 Service Bus 중단 및 재해 시 Service Bus 응용 프로그램 격리를 참조하십시오. 자세한 내용은 Service Bus(재해 복구)를 참조하세요.

Azure 모바일 서비스의 경우 가용성에 대해 고려할 사항이 두 가지 있습니다. 첫째, 모바일 서비스와 관련된 Azure SQL 데이터베이스를 정기적으로 백업합니다. 둘째, 모바일 서비스 스크립트를 백업합니다. 자세한 내용은 재해 시 모바일 서비스 복구를 참조하십시오. 모바일 서비스에서 일시적 중단을 경험하는 경우 일시적으로 대체 Azure 데이터 센터를 사용해야 할 수도 있습니다. 자세한 내용은 모바일 서비스(재해 복구)를 참조하세요.

HDInsight와 연결된 데이터는 Azure 저장소에 의해 지정된 고가용성 및 지속성 속성이 있는 Azure Blob 저장소에 기본적으로 저장됩니다. Hadoop MapReduce 작업과 관련된 다중 노드 처리는 HDInsight에 필요할 때 프로비전되는 임시 HDFS(Hadoop Distributed File System)에서 수행됩니다. MapReduce 작업의 결과도 기본적으로 Azure Blob 저장소에 저장되므로 처리된 데이터는 Hadoop 클러스터가 프로비전 해제된 후 지속되며 고가용성을 유지합니다. 자세한 내용은 HDInsight(재해 복구)를 참조하세요.

 

서비스/영역 확인 목록

계산(PaaS)

  • 각 역할의 인스턴스를 두 개 이상 구성합니다.

  • 상태를 역할 인스턴스가 아니라 지속성이 있는 저장소에 유지합니다.

  • StatusCheck 이벤트를 올바르게 처리합니다.

  • 가능한 경우 관련 변경 내용을 트랜잭션에 래핑합니다.

  • 작업자 역할 작업이 멱등원이고 다시 시작 가능한지 확인합니다.

  • 작업이 성공할 때까지 계속 작업을 호출합니다.

  • 자동 크기 조정 전략을 고려합니다.

가상 컴퓨터(IaaS)

  • D: 드라이브를 지속성이 있는 저장소로 사용하지 않습니다.

  • 서비스 계층의 컴퓨터를 가용성 집합으로 그룹화합니다.

  • 부하 분산 및 선택적 프로브를 구성합니다.

저장소

  • 데이터나 대역폭이 할당량을 초과하는 경우 저장소 계정을 여러 개 사용합니다.

이동합니다.

  • 일시적인 오류를 처리하는 다시 시도 정책을 구현합니다.

  • 분할을 수평 확장 전략으로 사용합니다.

가상 컴퓨터의 SQL Server 2014(IaaS)

  • 가상 컴퓨터에 대한 이전의 권장 사항을 따릅니다.

  • AlwaysOn과 같은 SQL Server 고가용성 기능을 사용합니다.

액세스 제어 서비스(가용성)

  • 로컬 오류의 경우 추가 가용성 단계가 필요하지 않습니다.

Service Bus(가용성)

  • 지속성이 있는 클라이언트 쪽 큐를 백업으로 만드는 것을 고려합니다.

모바일 서비스(가용성)

  • 모바일 서비스와 관련된 Azure SQL 데이터베이스를 정기적으로 백업합니다.

  • 모바일 서비스 스크립트를 백업합니다.

HDInsight(가용성)

  • 로컬 오류의 경우 추가 가용성 단계가 필요하지 않습니다.

Azure는 지역이라는 단위로 물리적 및 논리적으로 나뉘어져 있습니다. 지역은 서로 가까운 거리에 위치한 하나 이상의 데이터 센터로 구성됩니다. 이 문서가 작성된 현재 기준으로 Azure의 지역은 8개입니다(북미에 4개, 아시아에 2개, 유럽에 2개).

드문 경우이긴 하지만 전체 지역의 시설이 네트워크 오류 등으로 인해 액세스할 수 없게 되거나 자연 재해로 완전히 소실될 수 있습니다. 이 섹션에서는 여러 지역에 분산된 응용 프로그램을 만들기 위한 Azure의 기능에 대해 설명합니다. 지역은 한 지역의 오류가 다른 지역에 영향을 미칠 수 있는 가능성을 최소화하기 위한 것입니다.

계산 인스턴스를 여러 지역에 분산하는 작업은 각 대상 지역에서 별도의 클라우드 서비스를 만들고 각 클라우드 서비스에 배포 패키지를 게시하여 수행됩니다. 그러나 여러 지역의 클라우드 서비스에 트래픽을 분산하는 기능은 응용 프로그램 개발자나 트래픽 관리 서비스를 통해 구현해야 합니다.

재해 복구를 위해 사전에 배포할 예비 역할 인스턴스의 수를 결정하는 것은 용량 계획의 중요한 측면입니다. 대규모 보조 배포가 있으면 필요한 경우 사용 가능한 용량이 이미 확보되지만 비용이 사실상 두 배가 됩니다. 일반적인 패턴은 중요 서비스를 실행할 정도의 소규모 보조 배포를 마련하는 것입니다. 용량을 예약하고 보조 환경의 구성을 테스트하기 위해 적어도 소규모 보조 배포를 만드는 것이 좋습니다.

note참고
구독 할당량은 용량을 보장하지 않습니다. 할당량은 신용 한도일 뿐입니다. 용량을 보장하려면 필요한 수의 역할이 서비스 모델에서 정의되어야 하며 역할이 배포되어야 합니다.

여러 지역에 트래픽의 부하를 분산하려면 트래픽 관리 솔루션을 사용해야 합니다. Azure에서는 Azure 트래픽 관리자를 제공합니다. 유사한 트래픽 관리 기능을 제공하는 타사 서비스를 이용할 수도 있습니다.

여러 지역에 분산된 계산을 구현하기 위해 다양한 대체 전략을 사용할 수 있습니다. 이러한 전략은 응용 프로그램의 특정 비즈니스 요구 사항과 상황에 맞게 조정되어야 합니다. 상위 수준에서 이러한 전략은 다음 세 가지 범주로 분류할 수 있습니다.

  • 재해 시 다시 배포: 이 방법에서는 재해 시 응용 프로그램이 처음부터 다시 배포됩니다. 복구 시간이 보장되지 않아도 되는 중요하지 않은 응용 프로그램에 적합합니다.

  • 웜 예비(활성/수동): 호스트된 보조 서비스가 다른 지역에서 만들어지고 최소 용량을 보장하기 위해 역할이 배포되지만 역할이 프로덕션 트래픽을 받지는 않습니다. 이 방법은 여러 지역에 트래픽을 분산하도록 디자인되지 않은 응용 프로그램에 유용합니다.

  • 핫 예비(활성/활성): 응용 프로그램이 여러 지역에서 프로덕션 로드를 받도록 디자인됩니다. 각 지역의 클라우드 서비스가 DR 용도에 필요한 것보다 많은 용량에 대해 구성될 수도 있습니다. 또는 클라우드 서비스가 재해와 장애 조치(Failover) 시에 필요에 따라 수평 확장될 수도 있습니다. 이 방법은 응용 프로그램 디자인에 많은 투자가 필요하지만 보장된 짧은 복구 시간, 모든 복구 위치의 연속 테스트, 용량의 효율적 사용 등의 상당한 이점이 있습니다.

분산된 디자인에 대한 자세한 설명은 이 문서에서는 다루지 않습니다. 다음 백서에서 이러한 시나리오에서 대한 자세한 지침을 제공합니다.

IaaS VM의 복구는 많은 측면에서 PaaS 계산 복구와 유사하지만 IaaS VM이 VM과 VM 디스크로 구성되어 있다는 사실 때문에 중요한 차이점이 있습니다.

  • Blob 복사 API를 사용하여 VM 디스크 복제: 여러 지역에서 VM을 만들려면 VM 디스크를 다른 지역에 복사해야 합니다. VM 디스크가 바로 Blob이므로 이 작업은 표준 Blob 복사 API를 사용하여 수행할 수 있습니다.

  • 데이터 디스크와 OS 디스크 분리: IaaS VM에 대한 중요한 고려 사항은 VM을 다시 만들지 않고 OS 디스크를 변경할 수 없다는 것입니다. 복구 전략이 재해 후 다시 배포하는 것이면 이는 문제가 되지 않습니다. 그러나 웜 예비 방법을 사용하여 용량을 예약하는 경우에는 문제가 될 수 있습니다. 이 방법을 적절하게 구현하려면 올바른 OS 디스크가 기본 위치와 보조 위치에 배포되어야 하고 응용 프로그램 데이터가 별도의 드라이브에 저장되어야 합니다. 가능하면 두 위치에서 제공될 수 있는 표준 OS 구성을 사용합니다. 장애 조치(Failover) 후 보조 DC의 기존 IaaS VM에 데이터 드라이브를 연결해야 합니다. CopyBlob API를 사용하여 데이터 디스크의 스냅숏을 원격 사이트에 복사합니다.

  • 여러 VM 디스크의 지리적 장애 조치(Failover) 후 가능한 일관성 문제: VM 디스크는 Azure 저장소 Blob으로 구현되고 동일한 지역에서 복제 특성을 갖습니다(아래 참조). VM 디스크는 지리적 장애 조치(Failover) 후 크래시 일관성이 있는 상태가 되도록 보장되지만 지리적 복제가 비동기이고 독립적으로 복제되기 때문에 디스크 전체에서 일관성은 보장되지 않습니다. 이 때문에 디스크 스트라이프와 같은 경우에 문제가 발생할 수도 있습니다. 이러한 경우 지리적 장애 조치 후 일관성을 복원하려면 추가 작업이 필요할 수도 있습니다. 백업의 정확성을 유지하려면 Data Protection Manager와 같은 백업 제품을 사용하여 응용 프로그램 데이터를 백업하고 복원해야 합니다.

Azure에서 Blob, 테이블, 큐 및 VM 디스크는 기본적으로 모두 지리적으로 복제됩니다. 이를 GRS(지역 중복 저장소)라고 합니다. GRS는 저장소 데이터를 특정 지역 내에서 수백 킬로미터 떨어져 있는 쌍을 이룬 데이터 센터에 복제합니다. GRS는 규모가 큰 데이터 센터 재해가 발생한 경우 추가 내구성을 제공하기 위해 디자인되었습니다. Microsoft는 장애 조치(Failover)가 발생하는 경우를 제어하며 장애 조치(Failover)는 원래 기본 위치가 상당한 기간 동안 복구될 수 없는 것으로 간주되는 규모가 큰 재해로만 제한됩니다. 일부 시나리오에서 이 기간은 며칠에 이를 수 있습니다. 데이터는 일반적으로 몇 분 안에 복제됩니다. 동기화 간격은 아직 SLA에서 다루지 않습니다.

지리적 장애 조치(Failover) 시에 계정이 액세스되는 방법은 변경되지 않지만(URL과 계정 키가 변경되지 않음), 장애 조치 후 저장소 계정이 다른 지역에 있으므로 저장소 계정에 대한 지역 선호도를 필요로 하는 응용 프로그램이 영향을 받을 수도 있습니다. 동일한 데이터 센터의 저장소 계정을 필요로 하지 않는 서비스와 응용 프로그램의 경우에도 데이터 센터 간 지연과 대역폭 요금 때문에 트래픽을 일시적으로 장애 조치 지역으로 이동해야 할 수 있습니다. 이 점을 고려하여 전체적인 재해 복구 전략을 수립할 수 있습니다.

GRS에서 제공하는 자동 장애 조치(Failover) 외에, Azure에는 보조 저장소 위치에 있는 데이터 복사본에 대한 읽기 액세스를 제공하는 서비스가 도입되었습니다. 이를 RA-GRS(읽기 액세스 지역 중복 저장소)라고 합니다.

GRS 및 RA-GRS 미리 보기에 대한 자세한 내용은 Azure 저장소 중복 옵션 및 읽기 액세스 지역 중복 저장소를 참조하세요.

저장소에 대한 지역 선호도를 필요로 하는 데이터의 다른 인스턴스를 배포할 위치를 알기 위해 데이터가 지리적으로 복제되는 위치를 알아야 합니다. 다음 표에서는 기본 및 보조 위치 쌍을 보여 줍니다.

 

Primary Secondary

북중미

미국 중남부

미국 중남부

북중미

미국 동부

미국 서부

미국 서부

미국 동부

북유럽

서유럽

서유럽

북유럽

동남아시아

동아시아

동아시아

동남아시아

동중국

북중국

북중국

동중국

브라질 남쪽

미국 중남부

지리적 복제는 Azure 저장소에 대한 현재 가격에 포함되어 있습니다. 이를 지리 중복 저장소라고 합니다. 데이터가 지리적으로 복제되지 않도록 하려면 계정에 대해 지리적 복제를 사용하지 않도록 설정하면 됩니다. 이를 로컬 중복 저장소라고 하며 지리적으로 복제되는 저장소에 비해 할인된 가격으로 요금이 부과됩니다.

지리적 장애 조치(Failover)가 발생하면 Azure 서비스 상태 대시보드에 게시되지만, 응용 프로그램은 저장소 계정에 대한 지리적 영역을 모니터링하여 이를 자동으로 감지하는 기능을 구현할 수 있습니다. 이는 저장소가 이동한 지리적 영역에서 계산 리소스 활성화 등의 다른 복구 작업을 트리거하는 데 사용할 수 있으며 저장소 계정 속성 가져오기를 사용하여 서비스 관리 API에서 쿼리할 수 있습니다. 관련 속성은 다음과 같습니다.

<GeoPrimaryRegion>primary-region</GeoPrimaryRegion>
<StatusOfPrimary>[Available|Unavailable]</StatusOfPrimary>
<LastGeoFailoverTime>DateTime</LastGeoFailoverTime
<GeoSecondaryRegion>secondary-region</GeoSecondaryRegion
<StatusOfSecondary>[Available|Unavailable]</StatusOfSecondary>

  • VM 디스크에 대한 섹션에서 설명한 대로 장애 조치 후 VM 디스크 전체의 데이터 일관성은 보장되지 않습니다. 백업의 정확성을 유지하려면 Data Protection Manager와 같은 백업 제품을 사용하여 응용 프로그램 데이터를 백업하고 복원해야 합니다.

Basic, Standard 또는 Premium 계층용 지정 시간 복원 기능을 활용하여 Azure Azure SQL 데이터베이스를 복원할 수 있습니다. 자세한 내용은 Azure SQL 데이터베이스 백업 및 복원을 참조하세요.

지정 시간 복원을 사용할 수 있을 뿐만 아니라 Azure Azure SQL 데이터베이스 가져오기/내보내기 서비스를 사용하여 Azure 저장소 Blob로 데이터베이스를 수동으로 내보낼 수 있습니다. 이 작업은 다음 세 가지 방법으로 구현할 수 있습니다.

  • 다른 데이터 센터의 저장소 계정을 사용하여 Blob으로 내보냅니다.

  • 같은 데이터 센터의 저장소 계정을 사용하여 Blob으로 내보내고 Azure 저장소 지역 간 복제를 사용하여 별도의 데이터 센터에 복사합니다.

  • 온-프레미스 SQL Server로 가져옵니다.

구현에 대한 자세한 내용은 MSDN 문서, Azure SQL 데이터베이스의 비즈니스 연속성을 참조하십시오.

IaaS에서 실행되는 SQL Server 데이터베이스를 다른 Azure 데이터 센터로 복구하기 위한 두 가지 권장 옵션이 있습니다. 이 두 옵션 중 하나는 영역 간 AlwaysOn 가용성 그룹이고 다른 하나는 저장소 Blob를 사용한 백업/복원입니다.

데이터베이스 미러링을 사용할 수도 있지만 향후 SQL Server 버전에서는 이 기능이 제거될 예정입니다. 재해 복구에 데이터베이스 미러링을 사용하는 경우 주 서버와 미러 서버가 서로 다른 Azure 데이터 센터에서 실행되어야 합니다. 즉, Active Directory 도메인이 온-프레미스 네트워크를 통해 트래픽을 라우팅하지 않고 여러 Azure 데이터 센터에 걸쳐 있을 수 없기 때문에 서버 인증서를 사용하여 배포해야 합니다. 다음 다이어그램에서는 이러한 설정을 보여 줍니다.

Windows Azure의 데이터베이스 미러링(DR)

다음 다이어그램에는 Azure 저장소 Blob를 사용한 표준 백업 및 복원 방법이 나와 있습니다.

Windows Azure에서 블로그에 백업

자세한 내용은 Azure 가상 컴퓨터의 SQL Server에 대한 고가용성 및 재해 복구를 참조하십시오.

여러 Azure 지역에서 클라우드 서비스를 실행하려고 할 때 각 종속성에 대한 영향을 고려해야 합니다. 다음 섹션의 서비스 관련 지침에서는 대체 Azure 데이터 센터에서 동일한 Azure 서비스를 사용해야 한다고 간주합니다. 여기에는 구성 및 데이터 복제 작업이 둘 다 포함됩니다.

경우에 따라 이러한 단계는 전체 데이터 센터 사건보다는 서비스 관련 중단을 완화하는 데 도움이 될 수 있습니다. 응용 프로그램 관점에서 서비스 관련 중단은 마찬가지로 제한��� 될 수 있으며 대체 Azure 지역으로 서비스를 일시적으로 마이그레이션해야 할 것입니다.

ACS(액세스 제어 서비스)는 여러 Azure 지역에 걸쳐 있지 않은 고유한 네임스페이스 이름을 사용합니다. ACS 2.0은 하루에 한번씩 모든 네임스페이스의 백업을 만들어 안전한 외부 위치에 저장합니다. 재해 시 ACS 운영자는 가장 최근의 백업을 사용하여 원격 Azure 지역에서 고객의 구독을 복구하려고 시도할 수 있습니다. 백업 주기 때문에 최대 24시간의 데이터 손실이 발생할 수 있습니다. 지역 장애 조치(Failover)에 대한 SLA는 없으며 시나리오에 따라 복구에 며칠이 걸릴 수 있습니다.

대체 지역에서 ACS를 사용하려면 고객이 해당 지역에서 ACS 네임스페이스를 구성해야 합니다. 데이터 손실 가능성을 우려하는 ACS 2.0 고객은 ACS 2.0 관리 서비스를 검토하는 것이 좋습니다. 관리자는 이 인터페이스를 사용하여 네임스페이스를 관리하고 모든 관련 데이터를 가져오고 추출할 수 있습니다. 이 인터페이스의 사용을 통해 ACS 고객은 현재 ACS에서 제공하는 것보다 높은 수준의 데이터 일관성을 위한 사용자 지정 백업 및 복원 솔루션을 개발할 수 있습니다. 다른 가용성 고려 사항은 액세스 제어 서비스(가용성)를 참조하세요.

ACS와 마찬가지로 Service Bus는 여러 Azure 지역에 걸쳐 있지 않은 고유한 네임스페이스 이름을 사용합니다. 따라서 첫 번째 요구 사항은 대체 지역에서 필요한 Service Bus 네임스페이스를 설정하는 것입니다. 그러나 큐에 대기된 메시지의 지속성에 대한 고려 사항도 있습니다. 여러 Azure 지역에 메시지를 복제하기 위한 몇 가지 전략이 있습니다. 이러한 복제 전략 및 다른 재해 복구 전략에 대한 자세한 내용은 Service Bus 중단 및 재해 시 Service Bus 응용 프로그램 격리를 참조하십시오. 다른 가용성 고려 사항은 Service Bus(가용성)를 참조하세요.

Azure 웹 사이트를 보조 Azure 지역으로 마이그레이션하려면 게시에 사용할 수 있는 웹 사이트의 백업이 있어야 합니다. 전체 Azure 데이터 센터가 중단되지는 않은 경우 FTP를 사용하여 사이트 콘텐츠의 최근 백업 다운로드가 가능할 수도 있습니다. 그런 다음 대체 지역에서 새 웹 사이트를 만듭니다. 용량을 예약하기 위해 이전에 이미 만든 경우에는 다시 만들 필요가 없습니다. 새 지역에 사이트를 게시하고 필요에 따라 구성을 변경합니다. 이러한 변경에는 데이터베이스 연결 문자열이나 기타 지역 관련 설정이 포함될 수 있습니다. 필요한 경우 사이트의 SSL 인증서를 추가하고 사용자 지정 도메인 이름이 다시 배포된 Azure 웹 사이트 URL을 가리키도록 DNS CNAME 레코드를 변경합니다.

보조 Azure 지역에서 응용 프로그램의 백업 모바일 서비스를 만듭니다. Azure SQL 데이터베이스도 대체 지역에 복원합니다. 그런 다음 Azure 명령줄 도구를 사용하여 모바일 서비스를 대체 지역으로 이동하고 복원된 데이터베이스를 사용하도록 모바일 서비스를 구성합니다. 이 프로세스에 대한 자세한 내용은 재해 시 모바일 서비스 복구를 참조하십시오. 다른 가용성 고려 사항은 모바일 서비스(가용성)를 참조하세요.

HDInsight와 연결된 데이터는 기본적으로 Azure Blob 저장소에 저장됩니다. HDInsight는 MapReduce 작업을 처리하는 Hadoop 클러스터가 분석될 데이터가 포함된 저장소 계정과 동일한 지역에 배치되어야 하도록 요구합니다. Azure 저장소에 사용할 수 있는 지리적 복제 기능을 사용하는 경우 특정 이유로 기본 지역을 더 이상 사용할 수 없으면 데이터가 복제된 보조 지역에서 데이터에 액세스할 수 있습니다. 데이터가 복제된 지역에서 새로운 Hadoop 클러스터를 만들고 처리를 계속할 수 있습니다. 다른 가용성 고려 사항은 HDInsight(가용성)를 참조하세요.

지금 현재 Azure 지역의 손실에서 복구하려면 다양한 Azure 지역에서 여러 SQL 보고 인스턴스가 필요합니다. 이러한 SQL 보고 인스턴스는 동일한 데이터에 액세스해야 하며 해당 데이터에는 재해 시 자체 복구 계획이 있어야 합니다. 또한 각 보고서에 대한 RDL 파일의 외부 백업 복사본을 유지 관리할 수도 있습니다.

Azure 미디어 서비스에는 인코딩 및 스트리밍을 위한 다른 복구 방법이 있습니다. 일반적으로 지역 가동 중단 중에는 스트리밍이 더 중요합니다. 이에 대비하려면 서로 다른 두 Azure 지역에 미디어 서비스 계정을 두어야 합니다. 인코딩된 콘텐츠는 두 지역에 배치되어야 합니다. 오류가 발생하는 동안 대체 지역에 스트리밍 트래픽을 리디렉션할 수 있습니다. 인코딩은 어떠한 Azure 지역에서도 수행할 수 있습니다. 라이브 이벤트 처리 중과 같이 시간이 중요한 인코딩의 경우 오류가 발생하는 동안 대체 데이터 센터에 작업을 제출하도록 준비되어 있어야 합니다.

구성 파일은 대체 Azure 지역에서 가상 네트워크를 설정하는 가장 빠른 방법을 제공합니다. 기본 Azure 지역에서 가상 네트워크를 구성한 후 현재 네트워크에 대한 가상 네트워크 설정을 네트워크 구성 파일로 내보냅니다. 기본 지역에서 가동 중단이 발생하면 저장된 구성 파일에서 가상 네트워크를 복원합니다. 그런 다음 새 가상 네트워크와 함께 작동하도록 다른 클라우드 서비스, 가상 컴퓨터 또는 크로스-프레미스 설정을 구성합니다.

 

서비스/영역 확인 목록

계산(PaaS)

  • 지역 간 재해 복구 전략을 만듭니다.

  • 대체 지역에서 용량을 예약하는 경우의 장단점을 파악합니다.

  • Azure 트래픽 관리자(CTP)와 같은 트래픽 라우팅 도구를 사용합니다.

가상 컴퓨터(IaaS)

  • Blob VM 디스크 리소스를 대체 데이터 센터에 복사합니다.

  • VM 디스크 또는 디스크 콘텐츠를 정기적으로 백업합니다.

저장소

  • 저장소 리소스의 지리적 복제를 사용하지 않도록 설정하지 않습니다.

  • 장애 조치(Failover) 시에 지리적 복제를 위한 대체 지역을 파악합니다.

  • 사용자 제어 장애 조치(Failover) 전략에 대한 사용자 지정 백업 전략을 만듭니다.

SQL 데이터베이스(재해 복구)

  • Azure SQL 데이터베이스 지정 시간 복원을 사용합니다.

  • Azure SQL 데이터베이스를 Blob 저장소로 내보냅니다.

  • 이전 저장소 고려 사항에 따라 재해 복구 계획을 만듭니다.

가상 컴퓨터의 SQL Server(재해 복구)

  • 영역 간 AlwaysOn 가용성 그룹 또는 데이터베이스 미러링을 사용합니다.

  • 또는 백업을 사용하고 Blob 저장소에 복원합니다.

액세스 제어 서비스(재해 복구)

  • 대체 지역에서 ACS 네임스페이스를 구성합니다.

  • ACS 2.0 관리 서비스를 사용하여 사용자 지정 백업 솔루션을 만듭니다.

Service Bus(재해 복구)

  • 대체 지역에서 Service Bus 네임스페이스를 구성합니다.

  • 여러 지역에 걸쳐 있는 메시지에 대한 사용자 지정 복제 전략을 고려합니다.

웹 사이트(재해 복구)

  • 기본 지역 외부에서 웹 사이트 백업을 유지 관리합니다.

  • 가동 중단이 부분적인 경우 FTP를 사용하여 현재 사이트의 검색을 시도합니다.

  • 대체 지역의 새로운 웹 사이트나 기존 웹 사이트에 웹 사이트를 배포할 계획을 세웁니다.

  • 응용 프로그램 및 DNS CNAME 레코드에 대한 구성 변경을 계획합니다.

모바일 서비스(재해 복구)

  • 대체 지역에서 백업 모바일 서비스를 만듭니다.

  • 장애 조치(Failover) 중에 복원할 연결된 Azure SQL 데이터베이스의 백업을 관리합니다.

  • Azure 명령줄 도구를 사용하여 모바일 서비스를 이동합니다.

HDInsight(재해 복구)

  • 복제된 데이터가 있는 지역에서 새로운 Hadoop 클러스터를 만듭니다.

SQL 보고(재해 복구)

  • 다른 지역에서 대체 SQL 보고 인스턴스를 유지 관리합니다.

  • 해당 지역에 대상을 복제하는 별도의 계획을 유지 관리합니다.

미디어 서비스(재해 복구)

  • 대체 지역에서 미디어 서비스 계정을 만듭니다.

  • 스트리밍 장애 조치(Failover)를 지원하기 위해 두 지역에서 동일한 콘텐츠를 인코딩합니다.

  • 가동 중단 시에 대체 지역에 인코딩 작업을 제출합니다.

가상 네트워크(재해 복구)

  • 내보낸 가상 네트워크 설정을 사용하여 다른 지역에서 가상 네트워크를 다시 만듭니다.

Azure는 고가용성 및 재해 복구 목적으로 온-프레미스 데이터 센터를 Azure로 확장할 수 있는 포괄적인 서비스 집합을 제공합니다.

  • 네트워킹: 가상 사설망을 사용하여 온-프레미스 네트워크를 클라우드로 안전하게 확장합니다.

  • 계산: 온-프레미스에서 Hyper-V를 사용하는 고객은 기존 VM을 그대로 Azure로 이동할 수 있습니다.

  • 저장소: StorSimple은 파일 시스템을 Azure 저장소로 확장합니다. Azure 백업 서비스는 파일과 Azure SQL 데이터베이스의 백업을 Azure 저장소에 제공합니다.

  • 데이터베이스 복제: SQL 2014 가용성 그룹을 사용하여 온-프레미스 데이터에 대한 고가용성 및 재해 복구를 구현할 수 있습니다.

Azure 가상 네트워크를 사용하면 Azure에 논리적으로 분리된 섹션을 만들 수 있으며 IPsec 연결을 사용하여 온-프레미스 데이터센터 또는 단일 클라이언트 컴퓨터에 안전하게 연결할 수 있습니다. 가상 네트워크를 사용하면 Windows Server, 메인프레임 및 UNIX에서 실행되는 시스템을 비롯한 응용 프로그램 및 데이터에 온-프레미스 연결을 제공하는 동시에 Azure의 확장 가능한 주문형 인프라를 쉽게 이용할 수 있습니다. 자세한 내용은 여기를 참조하십시오.

온-프레미스에서 Hyper-V를 사용하는 고객은 VM을 변경하거나 VM 형식을 변환하지 않고 기존 VM을 그대로 Azure 및 Windows Server 2012를 실행하는 서비스 공급자로 이동할 수 있습니다. 자세한 내용은 디스크 및 이미지 관리를 참조하십시오.

온-프레미스 데이터에 대한 백업 사이트로 Azure를 사용하기 위한 몇 가지 옵션이 있습니다.

StorSimple은 온-프레미스 응용 프로그램에 대한 클라우드 저장소를 안전하고 투명하게 통합하고 계층화된 고성능 로컬 및 클라우드 저장소, 라이브 보관, 클라우드 기반 데이터 보호 및 재해 복구를 제공하는 단일 어플라이언스를 제공합니다. 자세한 내용은 StorSimple -- 클라우드 통합 저장소 -- 정의 및 용도를 참조하세요.

Azure 백업 서비스는 Windows Server 2012, Windows Server 2012 Essentials 및 System Center 2012 Data Protection Manager의 익숙한 백업 도구를 사용하여 클라우드 백업을 수행할 수 있도록 합니다. 이러한 도구는 로컬 디스크이든 Azure 저장소이든 관계없이 백업의 저장 위치와 독립적인 백업 관리 워크플로를 제공합니다. 데이터가 클라우드에 백업된 다음에는 승인된 사용자가 어느 서버에든 쉽게 백업을 복구할 수 있습니다.

증분 백업으로, 변경된 파일만 클라우드에 전송됩니다. 이는 저장소 공간을 효율적으로 사용하고 대역폭 사용을 줄이는 데 도움이 되며 여러 버전의 데이터에 대해 지정 시간 복구를 지원합니다. 데이터 보존 정책, 데이터 압축, 데이터 전송 제한 등의 추가 기능을 사용하도록 선택할 수도 있습니다. Azure를 백업 위치로 사용하면 백업이 자동으로 "오프사이트" 백업이 되는 분명한 이점이 있습니다. 이 경우 온사이트 백업 미디어를 보호하는 추가 요구 사항이 제거됩니다. 자세한 내용은 Azure 백업 개요Azure 백업과 함께 DPM 사용을 참조하십시오.

AlwaysOn 가용성 그룹, 데이터베이스 미러링, 로그 전달, Azure Blob 저장소를 사용한 백업 및 복원을 통해 하이브리드 IT 환경에서 SQL Server 데이터베이스의 재해 복구 솔루션을 구현할 수 있습니다. 이러한 모든 솔루션은 Azure 가상 컴퓨터에서 실행되는 SQL Server를 사용합니다.

데이터베이스 복제본이 온-프레미스와 클라우드 둘 다에 존재하는 하이브리드 IT 환경에서 AlwaysOn 가용성 그룹을 사용할 수 있습니다. 이를 보여주는 다이어그램이 아래에 있습니다. 이 다이어그램은 자세한 내용이 포함된 Azure 가상 컴퓨터의 SQL Server에 대한 고가용성 및 재해 복구에서 가져온 것입니다.

HybrID IT의 AlwaysOn 가용성 그룹

데이터베이스 미러링은 인증서 기반 설정에서 온-프레미스 서버와 클라우드에 걸쳐 있을 수 있습니다. 다음 다이어그램에서는 이러한 개념을 보여 줍니다.

HybrID IT의 데이터베이스 미러링

로그 전달을 사용하여 온-프레미스 데이터베이스를 Azure 가상 컴퓨터의 SQL Server 데이터베이스와 동기화할 수 있습니다.

HybrID IT에서 로그 전달

마지막으로 온-프레미스 데이터베이스를 Azure Blob 저장소에 직접 백업할 수 있습니다.

HybrID IT에서 블로그에 백업

자세한 내용은 Azure 가상 컴퓨터의 SQL Server에 대한 고가용성 및 재해 복구Azure 가상 컴퓨터에서 SQL Server의 백업 및 복원을 참조하십시오.

 

서비스/영역 확인 목록

네트워킹

  • 가상 네트워크를 사용하여 온-프레미스를 클라우드에 안전하게 연결합니다.

계산

  • Hyper-V와 Azure 간에 VM을 재배치합니다.

저장소

  • 클라우드 저장소를 사용하기 위해 StorSimple 서비스를 이용합니다.

  • Azure 백업 서비스를 사용합니다.

데이터베이스

  • Azure VM에서 SQL Server를 백업으로 사용하는 것을 고려합니다.

  • AlwaysOn 가용성 그룹을 설정합니다.

  • 인증서 기반 데이터베이스 미러링을 구성합니다.

  • 로그 전달을 사용합니다.

  • 온-프레미스 데이터베이스를 Azure Blob 저장소에 백업합니다.

이 시나리오는 응용 프로그램 오류 또는 운영자 오류로 인해 손상되거나 실수로 삭제된 데이터의 복구에 대한 것입니다.

Azure 저장소는 자동화된 복제본을 통해 데이터 복구 기능을 제공하기는 하지만 응용 프로그램 코드(또는 개발자/사용자)가 실수로 또는 의도하지 않게 데이터를 삭제하거나 업데이트하여 데이터가 손상되는 것을 막아 주지는 못합니다. 응용 프로그램 오류 또는 사용자의 실수가 발생하더라도 데이터의 정확성을 유지하려면 감사 로그와 함께 데이터를 보조 저장소 위치에 복사하는 등의 고급 기술이 필요합니다. 개발자는 Blob 콘텐츠의 읽기 전용 시점 스냅숏을 만들 수 있는 Blob 스냅숏 기능을 이용할 수 있으며, 이를 Blob에 대한 데이터 정확성 솔루션의 기초로 사용할 수 있습니다.

Blob 및 테이블은 지속성이 높지만 항상 데이터의 현재 상태를 나타냅니다. 데이터의 원치 않는 수정 또는 삭제에서 복구하려면 데이터를 이전 상태로 복원해야 할 수 있습니다. 이 작업은 지정 시간 복사본을 저장하고 유지하도록 Azure에서 제공하는 기능을 이용하여 수행할 수 있습니다.

Azure Blob의 경우 Blob 스냅숏 기능을 사용하여 지정 시간 백업을 수행할 수 있습니다. 각 스냅숏에 대해 마지막 스냅숏 상태 이후의 Blob 내 차이점을 저장하는 데 필요한 저장소에 대해서만 요금이 부과됩니다. 스냅숏은 기반으로 하는 원본 Blob이 있어야만 하므로 실수로 삭제되지 않도록 백업 데이터를 적절하게 보호하기 위해 다른 Blob 또는 다른 저장소 계정으로 복사하는 것이 좋습니다. Azure 테이블의 경우 다른 테이블 또는 Azure Blob에 지정 시간 복사본을 만들 수 있습니다. 테이블과 Blob의 응용 프로그램 수준 백업 수행에 대한 자세한 지침과 예제는 다음을 참조하십시오.

Azure SQL 데이터베이스에 사용할 수 있는 몇 가지 비즈니스 연속성(백업, 복원) 옵션이 있습니다. 데이터베이스 복사 기능 또는 DAC 가져오기/내보내기 서비스를 통해 데이터베이스를 복사할 수 있습니다. 데이터베이스 복사는 트랜잭션에 일관성이 있는 결과를 제공하는 반면 가져오기/내보내기 서비스를 통한 bacpac는 그렇지 않습니다. 두 옵션 모두 데이터 센터 내에서 큐 기반 서비스로 실행되며 현재는 완료 시간 SLA를 제공하지 않습니다.

note참고
데이터베이스 복사 및 가져오기/내보내기 서비스는 원본 데이터베이스에 상당한 부하를 주기 때문에 리소스 경합 또는 제한 이벤트가 트리거될 수 있습니다(공유 리소스 및 제한에 대한 다음 섹션 참조).

Microsoft Azure SQL 데이터베이스의 지정 시간 백업은 Azure SQL 데이터베이스 복사 명령을 사용하여 수행됩니다. 이 명령을 사용하여 동일한 논리 데이터베이스 서버 또는 다른 서버에 트랜잭션 측면에서 일관된 데이터베이스 복사본을 만들 수 있습니다. 두 경우 모두 데이터베이스 복사본은 완전히 기능하고 원본 데이터베이스와 완벽하게 독립적입니다. 만드는 각 복사본은 지정 시간 복구 옵션을 나타냅니다. 새 데이터베이스의 이름을 원본 데이터베이스 이름으로 바꾸어 데이터베이스 상태를 완전히 복구할 수 있습니다. 또는 Transact-SQL 쿼리를 사용하여 새 데이터베이스에서 데이터의 특정 하위 집합을 복구할 수 있습니다. SQL 데이터베이스에 대한 자세한 내용은 Azure SQL 데이터베이스의 비즈니스 연속성을 참조하십시오.

IaaS의 SQL Server에는 전통적인 백업과 로그 전달이라는 두 가지 옵션이 있습니다. 전통적인 백업을 사용하면 특정 시점으로 복원할 수 있지만 복구 프로세스가 느립니다. 전통적인 백업을 복원하려면 초기 전체 백업에서 시작한 다음 그 후 수행된 백업을 모두 적용해야 합니다. 두 번째 옵션은 로그 백업의 복원을 지연하도록(예를 들어 2시간) 로그 전달 세션을 구성하는 것입니다. 이렇게 하면 기본 위치에서 발생한 오류에서 복구할 수 있는 창이 제공됩니다.

일부 Azure 플랫폼 서비스는 사용자 제어 저장소 계정 또는 Azure SQL 데이터베이스에 정보를 저장합니다. 계정이나 저장소 리소스가 삭제되거나 손상되면 서비스에서 심각한 오류가 발생할 수 있습니다. 이러한 경우 삭제되거나 손상된 리소스를 다시 만드는 데 사용할 수 있는 백업을 유지 관리하는 것이 중요합니다.

Azure 웹 사이트와 Azure 모바일 서비스의 경우 연결된 데이터베이스를 백업하고 유지 관리해야 합니다. Azure 미디어 서비스와 가상 컴퓨터의 경우에는 연결된 Azure 저장소 계정과 해당 계정의 모든 리소스를 유지 관리해야 합니다. 예를 들어 가상 컴퓨터의 경우 Azure Blob 저장소에서 VM 디스크를 백업하고 관리해야 합니다.

 

서비스/영역 확인 목록

저장소

  • 중요한 저장소 리소스를 정기적으로 백업합니다.

  • Blob에 대한 스냅숏 기능을 사용하는 것을 고려합니다.

데이터베이스

  • 데이터베이스 복사 명령을 사용하여 지정 시간 백업을 만듭니다.

가상 컴퓨터의 SQL Server 백업(IaaS)

  • 전통적인 백업 및 복원 방법을 사용합니다.

  • 지연된 로그 전달 세션을 만듭니다.

웹 사이트

  • 연결된 데이터베이스가 있으면 백업하고 유지 관리합니다.

모바일 서비스

  • 연결된 데이터베이스를 백업하고 유지 관리합니다.

미디어 서비스

  • 연결된 저장소 리소스를 백업하고 유지 관리합니다.

가상 컴퓨터

  • Blob 저장소에서 VM 디스크를 백업하고 유지 관리합니다.

Failsafe: 복원력 있는 클라우드 아키텍처에 대한 지침: 복원력이 있는 클라우드 아키텍처를 구축하기 위한 지침, 이러한 아키텍처를 Microsoft 기술을 기반으로 구현하기 위한 지침 및 특정 시나리오를 대상으로 이러한 아��텍처를 구현하는 방법을 제공합니다.

Azure 응용 프로그램의 재해 복구 및 고가용성: 가용성 및 재해 복구에 대한 자세한 개요입니다. 참조 및 트랜잭션 데이터의 수동 복제에 대한 과제를 다룹니다. 마지막 섹션에서는 최고 수준의 가용성을 위해 여러 Azure 데이터 센터에 걸쳐 있는 다양한 종류의 DR 토폴로지에 대한 요약을 제공합니다.

Azure SQL 데이터베이스의 비즈니스 연속성: 백업 및 복원 전략을 중심으로 하는 가용성을 위한 Azure Azure SQL 데이터베이스 기술을 집중적으로 살펴봅니다. 클라우드 서비스에서 Azure SQL 데이터베이스를 사용하는 경우 이 백서와 관련 리소스를 검토해야 합니다.

Azure 가상 컴퓨터의 SQL Server에 대한 고가용성 및 재해 복구: IaaS(Infrastructure-as-a-Service)를 사용하여 데이터베이스 서비스를 호스팅하는 경우 사용할 수 있는 가용성 옵션에 대해 설명합니다. AlwaysOn 가용성 그룹, 데이터베이스 미러링, 로그 전달 및 백업/복원을 살펴봅니다. 이러한 기술을 사용하는 방법을 보여주는 몇 가지 자습서도 동일한 섹션에 있습니다.

Azure 클라우드 서비스에서 대규모 서비스를 디자인하는 방법에 대한 모범 사례: 확장성이 높은 클라우드 아키텍처의 개발을 집중적으로 살펴봅니다. 확장성을 높이기 위해 채택하는 기술 중 상당수가 가용성도 높입니다. 또한 부하가 증가한 경우 응용 프로그램이 확장될 수 없으면 확장성이 가용성 문제가 됩니다.

Azure 가상 컴퓨터에서 SQL Server의 백업 및 복원

Microsoft는 MSDN 웹 사이트에 대한 귀하의 의견을 이해하기 위해 온라인 설문 조사를 진행하고 있습니다. 참여하도록 선택하시면 MSDN 웹 사이트에서 나가실 때 온라인 설문 조사가 표시됩니다.

참여하시겠습니까?
표시:
© 2015 Microsoft