SharePoint Server의 고가용성 및 재해 복구 개념

적용 대상:yes-img-132013 yes-img-162016 yes-img-192019 yes-img-seSubscription Edition no-img-sopSharePoint in Microsoft 365

SharePoint Server 팜에 대한 계획 및 시스템 사양을 만들 때 고가용성과 재해 복구는 우선 순위가 가장 높습니다. 팜 서버 가용성이 높지 않고 팜을 복구할 수 없으면 고성능이나 용량과 같은 다른 계획 요소는 필요하지 않을 것입니다.

효율적이고 중단되지 않는 작업 상태를 유지할 수 있는 효과적인 전략을 설계하고 구현하기 위해서는 고가용성 및 재해 복구의 기본 개념을 이해해야 합니다. 이러한 개념은 또한 사용자의 SharePoint 환경을 위한 최상의 기술 솔루션을 평가하고 선택하기 위해서도 중요합니다.

비즈니스 연속성 관리 소개

비즈니스 연속성 관리는 연속된 조직 운영과 관련된 위험 요소들을 정의, 평가 및 관리하는 데 도움을 주는 관리 프로세스 또는 프로그램입니다. 비즈니스 연속성 관리는 부정적인 상황으로 인해 정상적인 비즈니스 운영이 중단되었을 때 운영을 계속하기 위한 로드맵으로 사용할 수 있는 비즈니스 연속성 계획의 작성 및 유지 관리에 집중되어 있습니다. 이러한 부정적 상황은 자연적이거나 인위적이거나 복합적인 것일 수 있습니다. 연속성 계획은 다음과 같은 분석 내용 및 기본 자료로부터 만들어집니다.

  • 비즈니스 영향 분석

  • 위협 및 위험 분석

  • 영향 시나리오 정의

  • 문서화된 복구 요구 사항 집합

비즈니스 연속성 관리에 대한 결과는 솔루션 설계 또는 식별된 옵션, 구현 계획, 테스트 및 조직 수용 계획, 유지 관리 계획 또는 일정으로 만들어집니다.

비즈니스 연속성 관리의 예로 Microsoft의 비즈니스 연속성 프로그램 스냅숏을 제공하는 데이터 및 응용 프로그램에 대한 재해 복구 및 보호가 있습니다.

분명히 IT(정보 기술)는 많은 조직에서 비즈니스 연속성 계획의 중요한 측면입니다. 그러나 비즈니스 연속성은 더 포괄적입니다. 여기에는 조직이 주요 중단 이벤트 중 및 직후에 비즈니스를 계속할 수 있도록 하는 데 필요한 모든 작업이 포함됩니다. 비즈니스 연속성 계획에는 다음 요소가 포함되지만 이에 국한되지는 않습니다.

  • 정책, 프로세스 및 절차

  • 가능한 옵션 및 의사 결정 책임

  • 인적 자원 및 설비

  • 정보 기술

비즈니스 연속성 관리를 이야기할 때 종종 고가용성과 재해 복구가 언급되지만 이 둘은 사실 비즈니스 연속성 관리에 포함된 하위 개념입니다.

고가용성 설명

특정 소프트웨어 응용 프로그램 또는 서비스에서 고가용성은 궁극적으로 최종 사용자의 경험과 기대치에 따라 측정됩니다. 수량화 및 인식할 수 있는 중단 시간이 비즈니스에 미치는 영향은 정보 손실, 자산 손상, 생산성 감소, 기회 비용, 계약상의 손해 또는 목표 손실이라는 용어로 표현될 수 있습니다.

고가용성 솔루션의 주요 목표는 중단 시간이 미치는 영향을 최소화하거나 완화하는 것입니다. 이에 대한 올바른 전략은 기술 및 인프라 비용을 통해 비즈니스 프로세스와 SLA(서비스 수준 계약) 사이의 균형을 최적화할 수 있어야 합니다.

플랫폼은 계약과 고객 및 이해 당사자의 기대 수준에 따라 가용성이 높은 것으로 고려됩니다. 시스템의 가용성은 다음과 같은 계산을 통해 표현될 수 있습니다.

실제 가동 시간/예상 가동 시간 X 100%

결과 값은 업계 솔루션들에서 자주 언급되는 일련의 9로 나타납니다. 이러한 수치는 다시, 연간 가능한 가동 시간 또는 그 반대로 가능한 중단 시간으로 변환되어 표현되기도 합니다.

일련의 9 가용성 비율 총 연간 중단 시간
2
99%
3일, 15시간
3
99.9%
8시간, 45분
4
99.99%
52분, 34초
5
99.999%
5분, 15초

계획된 중단 시간과 계획되지 않은 중단 시간

시스템 중단은 예상되었거나 계획된 것일 수도 있고 계획되지 않은 장애로 인해 발생할 수도 있습니다. 적절하게 관리만 된다면 중단 시간을 나쁜 것으로만 바라볼 필요가 없습니다. 발생 가능한 중단 시간은 두 가지 유형으로 구분할 수 있습니다.

  • 계획된 유지 관리. 소프트웨어 패치 적용, 하드웨어 업그레이드, 암호 업데이트, 오프라인 다시 인덱싱, 데이터 로드 또는 재해 복구 절차 리허설 등 계획된 유지 관리 작업을 위해 미리 일정이 발표되고 조정됩니다. 세밀하게 잘 관리되는 운영 절차는 중단 시간을 최소화하고 모든 데이터 손실을 방지해야 합니다. 계획된 유지 관리 활동은 보다 심각한 계획되지 않은 중단 시나리오를 방지하거나 완화하기 위해 필요한 투자로 이해될 수 있습니다.

  • 계획되지 않은 중단 시간. 시스템, 인프라 또는 프로세스 수준의 오류는 계획되지 않았거나, 제어할 수 없는 상태로 발생할 수 있으며, 예상되더라도 발생 가능성이 매우 낮아서 그에 따른 영향이 그리 크지 않은 것으로 간주될 수도 있습니다. 강력한 고가용성 솔루션은 이러한 유형의 오류를 감지하고 중단으로부터 자동으로 복구를 수행하고 내결함성을 다시 설정할 수 있어야 합니다.

고가용성에 대한 SLA를 설정할 때는 계획된 유지 관리 활동과 계획되지 않은 중단 시간에 대해 별도의 KPI(핵심 성과 지표)를 계산해야 합니다. 이러한 방식을 통해 계획된 유지 관리 활동에 대한 투자와 계획되지 않은 중단 시간을 방지함으로써 얻게 되는 이익을 비교할 수 있습니다.

가용성 저하

고가용성은 모 아니면 도 식의 접근 방식으로 고려되어서는 안됩니다. 최종 사용자의 입장에서는 기능 또는 성능이 일부 제한되더라도 시스템이 완전히 중단되는 대신 시스템을 부분적으로 사용할 수 있는 것이 오히려 나을 수도 있습니다. 이러한 다양한 가용성 수준은 다음과 같이 분류할 수 있습니다.

  • 읽기 전용 및 지연된 작업. 유지 관리 시간 또는 단계별 재해 복구 기간 중에도 데이터 검색은 가능하지만 새로운 워크플로 및 백그라운드 처리가 일시적으로 중단되거나 대기 중으로 전환될 수 있습니다.

  • 데이터 지연 및 응용 프로그램 응답성. 막대한 작업 부하, 처리 백로그 또는 부분적인 플랫폼 장애로 인해 제한된 하드웨어 리소스가 과도하게 커밋되거나 작게 조정될 수 있습니다. 사용자 경험은 저하될 수 있지만 작업은 덜 생산적인 방식으로 계속 수행될 수 있습니다.

  • 부분적, 일시적 장애 또는 곧 발생할 장애. 오류 발생 시 작업을 재시도하거나 자동 교정을 수행하는 응용 프로그램 논리 또는 하드웨어 스택의 내결함성. 이러한 유형의 문제는 최종 사용자에게 데이터 지연 또는 응용 프로그램 응답 성능 저하로 표시될 수 있습니다.

  • 부분적인 종단 간 장애. 계획되었거나 계획되지 않은 중단은 솔루션 스택의 수직 계층(인프라, 플랫폼 및 응용 프로그램) 내에서 또는 서로 다른 기능적 구성 요소 간에 수평적으로 안전한 방식으로 수행될 수 있습니다. 사용자는 영향을 받는 기능 또는 구성 요소에 따라 부분적인 성공 또는 성능 저하를 경험할 수 있습니다.

이러한 차선적인 시나리오의 수용 가능 여부는 저하된 가용성이 완전한 중단까지 이어지는 범위 및 단계별 재해 복구에서 중간 단계에 따라 결정됩니다.

중단 시간 수량화

중단 시간이 발생할 경우, 계획된 것이든, 계획되지 않은 것이든 간에 기본적인 비즈니스 목표는 시스템을 다시 온라인 상태로 되돌리고 데이터 손실을 최소화하는 것입니다. 중단 시간이 발생하면 매분마다 직접 및 간접적인 비용을 초래합니다. 계획되지 않은 중단 시간이 발생한 경우에는 중단이 발생한 이유, 현재 시스템의 상태, 중단으로부터 시스템을 복구하는 데 필요한 단계를 확인하는 시간과 노력을 균형적으로 맞출 수 있어야 합니다.

모든 중단 상황에서는 미리 결정된 지점에서 중단에 대한 조사 또는 유지 관리 작업 수행을 중지하고 시스템을 다시 온라인 상태로 전환하여 중단 상태를 복구하고, 필요에 따라 내결함성을 다시 설정하기 위한 비즈니스 의사 결정을 수행하거나 그러한 가능성을 모색해야 합니다.

복구 목표

데이터 중복성은 고가용성 데이터베이스 솔루션의 핵심 구성 요소입니다. 이를 위해서는 기본 SQL Server 인스턴스에서의 트랜잭션 활동이 하나 이상의 보조 인스턴스에 동기적으로 또는 비동기적으로 적용됩니다. 중단이 발생하면 진행 중이던 트랜잭션이 롤백되거나 데이터 전파 지연으로 인해 보조 인스턴스에서 트랜잭션이 손실될 수 있습니다.

중단 시간에 대해서는 그로 인한 영향을 측정하고 비즈니스를 복구하는 데 걸리는 시간 및 복구된 마지막 트랜잭션에서 발생한 지연 시간을 기준으로 복구 목표를 설정할 수 있습니다.

  • RTO(복구 시간 목표). 중단 상태가 진행되는 기간입니다. 초기 목표는 장애 조사를 시작할 수 있도록 최소한 읽기 전용 기능이 지원되는 온라인 상태로 시스템을 복구하는 것입니다. 하지만 주요 목표는 새 트랜잭션을 수행할 수 있는 지점까지 전체 시스템을 복원하는 것입니다.

  • RPO(복구 지점 목표). RPO는 허용 가능한 데이터 손실 측정 단위라고도 부릅니다. RPO는 장애 이전에 데이터 트랜잭션이 마지막으로 커밋된 시점과 장애 이후 처음으로 데이터가 복구된 시점 사이의 시간 간격 또는 지연 시간을 나타냅니다. 실제 데이터 손실은 장애 시점의 데이터 작업 부하, 장애 유형 및 사용된 고가용성 솔루션 유형에 따라 다를 수 있습니다.

    참고

    관련 목표는 RLO(복구 수준 목표)입니다. 이 목표는 전체 팜, 웹 애플리케이션, 사이트 모음, 사이트, 목록 또는 라이브러리 또는 항목을 복구할 수 있어야 하는지 여부에 관계없이 데이터를 복구할 수 있어야 하는 세분성을 정의합니다. 자세한 내용은 SharePoint Server의 백업 및 복구 계획을 참조하세요.

RTO 및 RPO 값은 비즈니스에서 허용되는 중단 시간, 허용 가능한 데이터 손실 정도를 나타내는 목표 및 가용성 상태 모니터링을 위한 측정 단위로 사용되어야 합니다.

ROI 또는 기회 비용의 당위성

중단 시간에 대한 비즈니스 비용은 재무적 단위 또는 고객 영업의 형태로 표현될 수 있습니다. 이러한 비용은 시간에 따라 누적되거나 중단 시간 중 특정 시점에 발생할 수도 있습니다. 특정 복구 시간 및 데이터 복구 지점에 따라 중단 발생 비용을 계획하는 것 외에도 RTO 및 RPO 목표를 달성하기 위해 또는 중단 방지를 위한 모든 노력에 필요한 비즈니스 프로세스 및 인프라 투자도 계산할 수 있습니다. 이러한 투자 분야는 다음과 같습니다.

  • 중단 시간 방지. 처음부터 중단이 발생하지 않으면 중단 복구 비용을 완전히 회피할 수 있습니다. 이러한 투자에는 격리된 장애 지점 및 사전 예방적 조치로 계획된 중단 시간 사이에 작업 부하를 분산하는 내결함성 및 중복성을 갖는 하드웨어 또는 인프라의 비용이 포함됩니다.

  • 복구 자동화. 시스템 장애가 발생할 경우 자동화되고 투명한 방식의 복구를 사용하면 중단 시간이 고객 환경에 미치는 영향을 크게 완화시킬 수 있습니다.

  • 리소스 사용률. 보조 또는 대기 인프라는 가동 중단을 기다리며 유휴 상태가 될 수 있습니다. 읽기 전용 워크로드에 활용하거나 사용 가능한 모든 하드웨어에 워크로드를 배포하여 전반적인 시스템 성능을 향상시킬 수도 있습니다.

특정 RTO 및 RPO 목표에 따라 필요한 가용성 및 복구 투자는 중단 시간에 대한 예상 비용과 함께 시계열 함수로 표현되고 정당화될 수 있습니다. 실제로 중단이 발생하면 이를 통해 경과된 중단 시간을 기준으로 비용에 기반한 의사 결정을 수행할 수 있습니다.

가용성 상태 모니터링

운영적인 관점에서 봤을 때, 실제 중단이 발생한 동안에는 모든 관련 변수를 고려해서 ROI 또는 기회 비용을 실시간으로 계산하려고 하지 않는 것이 좋습니다. 대신 예상된 RPO를 대신해서 대기 인스턴스에서 데이터 지연 시간을 모니터링해야 합니다.

또한 중단이 발생했으면, 일단 근본 원인 조사를 위해 투입되는 초기 시간을 제한하고, 대신 복구 환경의 상태가 유효한지 확인하는 데 집중한 후 이후 예측 분석을 위해 세부 시스템 로그 및 보조 데이터 복사본을 활용해야 합니다.

재해 복구 계획

고가용성 관련 투자는 중단이 발생하는 것을 방지하기 위한 노력이지만 재해 복구 투자는 중단 후 고가용성을 다시 설정하기 위한 노력입니다.

재해 복구 절차와 책임은 실제 중단이 발생하기 전에 최대한 정형화되어 있어야 합니다. 실제 모니터링 및 경고를 기반으로 자동 또는 수동 장애 조치(failove) 및 복구 계획을 시작할지 여부는 사전 설정된 RTO 및 RPO 임계값에 따라 결정됩니다. 올바른 재해 복구 계획의 범위에는 다음과 같은 항목들이 포함되어야 합니다.

  • 세분화된 장애 및 복구 수준. 장애가 발생한 위치 및 장애 유형에 따라 데이터 센터, 인프라, 플랫폼, 응용 프로그램 또는 작업 부하 등 서로 다른 수준에서 교정 조치를 취할 수 있습니다.

  • 원본 자료 조사. 기준선 및 최근 모니터링 내역, 시스템 경고, 이벤트 로그 및 진단 쿼리 등은 모두 적합한 당사자가 즉시 액세스할 수 있습니다.

  • 종속성 조정. 응용 프로그램 스택 내에서 그리고 여러 당사자 간에 시스템 및 비즈니스의 종속성을 확인해야 합니다.

  • 의사 결정 트리. 역할 책임, 오류 분류, 장애 조치(failover) 기준(RPO 및 RTO 목표 기반), 처방적 복구 단계를 포함하는 미리 결정되었고, 반복 가능하며, 유효성이 검증된 의사 결정 트리가 필요합니다.

  • 유효성 검사. 중단으로부터 복구하기 위한 단계를 수행한 후 시스템이 정상 운영 상태로 복구되었다는 것을 확인하기 위한 조치가 필요합니다.

  • 설명서. 위에 나열된 모든 항목들을 일련의 문서로 작성하고 제삼자도 최소한의 도움만으로 복구 계획을 실행할 수 있도록 충분히 자세하고 명확하게 기술합니다. 이러한 유형의 문서화를 일반적으로 '자습서' 또는 '설명서'라고 부릅니다.

  • 복구 리허설. RTO 목표에 대한 기준 요구 사항을 설정하기 위해 재해 복구 계획을 정기적으로 실행해야 하며, 주 시스템의 기본 프로덕션 사이트를 재해 복구 사이트의 보조 사이트와 정기적으로 순환시키는 것이 좋습니다.

참고 항목

개념

SharePoint Server의 재해 복구 전략 선택

기타 리소스

Azure Site Recovery로 어떤 워크로드를 보호할 수 있습니까?

Azure Site Recovery를 사용하여 재해 복구용 다층 계층 SharePoint 응용 프로그램 복제