애플리케이션 복원력: Windows 앱 가용성 유지

소개

Windows 애플리케이션은 종종 이를 호스팅하는 서버 이상의 많은 요소에 의존합니다. 데이터베이스, 아이덴티티 서비스, 스토리지, 게이트웨이, 네트워크 및 사용자 엔드포인트는 모두 애플리케이션이 중단 중에도 사용 가능한 상태를 유지하는 데 영향을 미칠 수 있습니다. 이 기사는 IT 팀이 이러한 의존성을 평가하고, 기존 Windows 애플리케이션 주위에 복원력을 설계하며, 올바른 계층을 모니터링하고, 복구 계획이 실제로 사용자가 의존하는 비즈니스 기능을 유지하는지 테스트하는 방법을 설명합니다.

애플리케이션 복원력이란 무엇인가요?

애플리케이션 복원력은 애플리케이션과 그 주변 인프라가 중단 동안 필수 기능을 계속 제공하고 실패 후 예측 가능하게 복구할 수 있는 능력입니다.

중단은 작거나 클 수 있으며, 그 원인은 하드웨어 또는 운영 체제 실패, 애플리케이션 충돌, 업데이트 실패, 데이터베이스 중단, 네트워크 중단, 인증 실패, 리소스 고갈, 사용 불가능한 종속성 또는 보안 사고 등 다양할 수 있습니다.

탄력적인 아키텍처는 실패가 불가피하다는 것을 인정하며, 모든 사건을 예방하는 것을 목표로 삼기보다는 IT 조직이 각 사건의 영향을 제한하고 서비스를 유지하거나 복원하기 위한 통제된 복구 절차를 수립하려고 한다.

애플리케이션 복원력은 서버 가동 시간 이상입니다.

서버의 가용성을 서버에서 실행되는 애플리케이션의 가용성의 대리로 사용하는 것은 일반적인 실수입니다.

비즈니스 애플리케이션이 진정으로 사용 가능하려면 여러 구성 요소가 동시에 사용 가능해야 합니다.

인프라 → 운영 체제 → 애플리케이션 → 종속성 → 접근 경로 → 사용자 세션 → 비즈니스 프로세스

이 체인의 어떤 요소에 문제가 생기면 애플리케이션이 사실상 사용할 수 없게 될 수 있습니다.

예를 들어, 애플리케이션 서버는 정상일 수 있지만 데이터베이스에 접근할 수 없습니다. 게시된 애플리케이션은 제대로 작동할 수 있지만 게이트웨이 오류로 인해 원격 직원이 접근할 수 없습니다. 사용자는 애플리케이션을 성공적으로 실행할 수 있지만 라이센스, 파일 또는 백엔드 서비스가 사용 불가능하여 거래를 완료하지 못할 수 있습니다.

애플리케이션 복원력은 서버가 가용성 또는 상태 점검에 응답할 수 있는지 여부가 아니라 사용자가 필요한 비즈니스 작업을 수행할 수 있는 능력을 기준으로 측정되어야 합니다.

왜 Windows 애플리케이션의 애플리케이션 복원력이 다른가요?

현대의 회복력 관행은 점점 더 클라우드 네이티브 애플리케이션, 컨테이너, 마이크로서비스 및 자동화된 오케스트레이션에 초점을 맞추고 있습니다. 이러한 접근 방식은 가치가 있지만 모든 조직에 항상 적용되는 것은 아닙니다.

많은 조직에는 클라우드 네이티브 아키텍처가 일반화되기 전에 개발된 레거시 Windows 비즈니스 애플리케이션이 있습니다. ERP 소프트웨어, 회계 애플리케이션, 제조 애플리케이션, 의료 애플리케이션, 엔지니어링 애플리케이션 및 내부 개발 애플리케이션은 모두 조직의 운영에 중요할 수 있습니다.

이러한 애플리케이션을 마이크로서비스로 재구성하는 것은 매우 비용이 많이 들거나 기술적으로 도전적일 수 있으며, 조직이 소스 코드를 제어하지 않는 경우에는 완전히 실행 불가능할 수도 있습니다.

이러한 경우, 애플리케이션 자체를 더 탄력적으로 만들기보다는 애플리케이션 주변의 운영을 더 탄력적으로 만드는 데 상당한 가치가 있을 수 있습니다. 애플리케이션 게시 이 접근 방식의 일환으로 기존 Windows 애플리케이션을 중앙 집중식 인프라에 유지하면서 사용자가 이를 접근하는 방식을 변경할 수 있습니다. 여기에는 애플리케이션을 호스팅하는 인프라에 대한 변경 사항이 포함될 수 있으며, 예를 들어 인프라 제약을 제거하고, 중복 애플리케이션 호스트를 생성하며, 대체 접근 방법을 활성화하고, 애플리케이션 호스트에 대한 보다 신속한 복구 절차를 구현하는 것이 포함됩니다.

Windows 애플리케이션 가용성이 실패할 수 있는 경우는?

애플리케이션 복원력을 구축하는 것은 호스트에서 사용자에게 애플리케이션을 성공적으로 전달하는 데 필요한 구성 요소를 발견하는 것에서 시작됩니다. 이 과정은 전체 애플리케이션을 중단시킬 수 있는 잠재적인 실패 지점을 강조합니다.

애플리케이션 호스트

단일 Windows 서버에서 실행되는 애플리케이션은 명확한 단일 실패 지점을 가지고 있습니다.

하드웨어 문제, Windows 업데이트, 운영 체제 손상, 리소스 고갈 또는 애플리케이션 실패는 해당 머신에 의존하는 모든 사용자에게 영향을 줄 수 있습니다. 가용성 요구 사항이 필요하다면, 여러 애플리케이션 호스트를 배치하여 특정 머신에 대한 의존성을 줄이고 서버가 사용할 수 없게 될 때 용량을 제공할 수 있습니다.

데이터베이스, 저장소 및 기타 종속성

많은 Windows 애플리케이션은 애플리케이션 호스트 외부의 서비스에 의존합니다. 이러한 서비스에는 다음이 포함될 수 있습니다:

• SQL 데이터베이스
• 파일 공유
• 라이센스 서버
• Active Directory
• 도메인 이름 시스템 (DNS)
• 인증서
• API
• 미들웨어
• 네트워크 스토리지
• 인쇄 인프라스트럭처

두 번째 애플리케이션 서버를 도입하는 것은 공통 데이터베이스나 사용할 수 없는 저장소 의존성을 공유하는 경우 최소한의 복원력을 제공합니다. 의존성 매핑은 가시적인 애플리케이션 인프라를 넘어 확장되어야 한다는 것이 분명해집니다.

인증 및 신원

사용자가 필요한 인증 인프라가 없으면 정상적인 애플리케이션에 접근할 수 없습니다.

IT 팀은 중요한 애플리케이션이 의존하는 신원 서비스를 식별하고 이러한 리소스에 접근할 수 없을 때를 대비한 장애 조치 계획이 마련되어 있는지 확인해야 합니다. Active Directory, 클라우드 신원 플랫폼, 다단계 인증(MFA) 서비스 및 인증 게이트웨이는 모두 애플리케이션의 가용성 체인을 제공하는 데 의존할 수 있습니다.

네트워크 및 원격 액세스 경로

중앙 집중식 Windows 애플리케이션의 경우, 사용자와 애플리케이션 환경 간의 연결은 또 다른 가능한 실패 영역을 나타냅니다.

전체 체인을 상상해 봅시다:

사용자 장치 → 인터넷 또는 LAN → 게이트웨이 → 애플리케이션 호스트 → 백엔드 서비스

이 체인에서의 어떤 고장도 애플리케이션이 정상적으로 실행되고 있더라도 사용자가 작업을 수행하는 것을 방해할 수 있습니다. 특히 애플리케이션이 데이터 센터에서 실행되고 있지만 다른 위치의 사용자에게는 접근할 수 없는 분산 조직에 특히 관련이 있습니다.

종단점

애플리케이션 복원력은 반드시 사용자의 일반 작업 공간이 사용 가능해야 하는 것은 아닙니다.

인증된 사용자에게 대체 장치나 브라우저를 통해 중앙에서 호스팅된 애플리케이션에 접근할 수 있는 수단을 제공하면, 노트북이 사용 불가능해지거나 사무실에 접근할 수 없거나 직원들이 다른 위치에서 작업해야 할 경우에도 접근을 보장할 수 있습니다.

애플리케이션 배포 아키텍처는 더 넓은 비즈니스 연속성 전략의 구성 요소가 될 수 있습니다.

Windows 앱을 위한 애플리케이션 복원력 구축 과정은 무엇인가요?

단일 기술이 애플리케이션을 탄력적으로 만들지는 않습니다. IT 팀은 대신 전체 기능을 중단시킬 수 있는 실패의 수를 줄이고, 남아 있는 것들에 대한 통제된 복구 메커니즘을 준비해야 합니다.

1. 중요한 애플리케이션 및 비즈니스 프로세스 식별

모든 애플리케이션이 동일한 수준의 보호를 요구하는 것은 아닙니다. 먼저 어떤 애플리케이션이 주요 작업을 지원하는지, 어떤 사용자가 이를 의존하는지 및 그들의 다운타임 허용 범위를 결정하십시오.

두 가지 복구 목표는 비즈니스 요구 사항을 기술 사양으로 변환합니다. NIST의 비상 계획 지침 복구 시간 목표(RTO)와 복구 지점 목표(RPO)를 복구 요구 사항을 결정하는 주요 매개변수로 정의합니다:

• 복구 시간 목표(RTO): 서비스가 복원되기 전에 허용 가능한 다운타임의 기간.
• 복구 지점 목표(RPO): 허용 가능한 데이터 손실의 간격, 시간으로 측정됩니다.

주문을 처리하기 위해 집중적으로 사용되는 애플리케이션은 몇 분의 RTO를 가질 수 있는 반면, 주 1회 실행되는 재무 보고 애플리케이션은 며칠의 다운타임을 감당할 수 있습니다.

RTO와 RPO는 애플리케이션에 필요한 보호 유형을 정의합니다: 즉각적인 장애 조치, 서비스의 빠른 재설정 또는 단순히 문서화된 복구 절차.

2. 전체 애플리케이션 의존성 체인 매핑

응용 프로그램이 작업을 수행하는 데 필요한 모든 것을 문서화하십시오.

실행 파일이나 Windows 서버에서 멈추지 마십시오. 데이터베이스, 스토리지, 인증, DNS, 네트워킹, 인증서, 라이선스 시스템, 게이트웨이 및 외부 서비스를 잊지 마십시오.

각각에게 물어보세요:

이것이 사라지면 애플리케이션에 어떤 일이 발생합니까?

이 연습은 숨겨진 단일 실패 지점을 드러내고 복구 순서를 설정할 것입니다. 애플리케이션 호스트를 먼저 복원하는 것은 데이터베이스, 아이덴티티 서비스 또는 저장소가 아직 사용 가능하지 않다면 큰 도움이 되지 않습니다.

3. 중요한 단일 실패 지점 제거

의존성 트리가 설정되면 비즈니스 중요성과 복구 목표에 따라 어떤 구성 요소를 중복 제거할지 결정합니다.

Windows 애플리케이션 배포의 경우, 단일 호스트의 기능에 의존하기보다는 여러 애플리케이션 서버를 배포하는 것이 포함될 수 있습니다. 로드 밸런싱 계층을 통해 정상 운영 중에 세션을 애플리케이션 인스턴스에 분산할 수 있습니다. 호스트 장애가 발생할 경우, 들어오는 연결은 정상 상태의 애플리케이션 서버 인스턴스로 라우팅될 수 있습니다.

중복성 계획은 의존성 분석에 의해 알려져야 합니다. 그러나 여러 애플리케이션 서버가 단일 중요한 데이터베이스, 네트워크 게이트웨이 또는 저장소 계층에 접근하는 것은 여전히 단일 실패 지점을 나타냅니다.

고가용성 설계는 따라서 애플리케이션 서비스를 통합된 엔티티로 고려해야 합니다. 인프라 수준의 중복성을 요구하는 Windows Server 환경의 경우, Microsoft의 장애 조치 클러스터링 문서 고가용성 및 재해 복구 토폴로지에 대한 추가 지침을 제공합니다.

4. 개별 엔드포인트에서 애플리케이션 분리

모든 직원의 워크스테이션에 중요한 애플리케이션을 직접 설치하는 것은 다른 종류의 복원력 문제를 일으킬 수 있습니다. 사용자가 일반 컴퓨터에 대한 접근을 잃으면, 계속 작업하는 데 필요한 애플리케이션에 대한 접근도 잃을 수 있습니다.

관리되는 Windows 호스트에서 애플리케이션 중앙 집중화 응용 프로그램 인터페이스를 사용자에게 제공함으로써 이 위험을 제거합니다. 데이터와 응용 프로그램 상태는 관리되는 Windows 호스트에 저장되며, 권한이 있는 엔드포인트에서 접근됩니다.

이렇게 함으로써 사용자가 장치나 위치를 변경하더라도 애플리케이션을 사용할 수 있게 됩니다. 애플리케이션을 중앙 집중화하는 것이 인프라 문제를 없애지는 않지만, IT가 제어할 수 있는 환경으로 이동하는 데 도움이 됩니다.

5. 여러 가지 실용적인 접근 방법 제공

회복력은 또한 단일 엔드포인트 유형이나 연결 방법에 대한 불필요한 의존을 피함으로써 달성될 수 있습니다.

응용 프로그램 배포 아키텍처에 따라 사용자는 다르게 사용할 수 있습니다. 원격 액세스 RDP 호환 클라이언트, 전용 애플리케이션 실행기, 웹 포털 또는 HTML5 브라우저 세션을 포함한 방법.

대체 연결 방법은 인프라 중복성과 혼동되어서는 안 됩니다. 모든 방법이 동일한 실패한 서버에 의존하고 있다면, 애플리케이션은 여전히 사용할 수 없습니다.

사용자의 정상 장치, 설치된 클라이언트 또는 위치에 영향을 미치는 중단이 발생할 때 접근 복원력을 제공합니다.

6. 고장으로 이어지기 전에 모니터링

애플리케이션 복원력은 단순히 복구에 관한 것이 아니라, 조기에 감지하면 중단으로의 저하를 피할 수 있습니다.

Windows 애플리케이션 환경에서 유용한 지표는 CPU 사용률, 메모리 압력, 디스크 용량 및 I/O, 네트워크 사용률, 활성 세션, 애플리케이션 프로세스, 응답 시간, 실패한 연결 및 종속 서비스의 가용성입니다.

트렌드 모니터링 서버가 반복적으로 한계에 접근하는 경우에도 여전히 온라인 상태일 수 있지만 사용자 경험이 점차 악화될 수 있으므로 이는 매우 중요합니다.

임계값 알림은 관리자가 사용자가 접근을 잃기 전에 사건의 전조를 조사할 수 있도록 합니다.

용량 급증 및 장애 조치 계획 세우기

하드웨어 수준의 실패를 견디지만 증가된 요구 사항 아래에서 완전히 기능할 수 없는 애플리케이션은 어떤 종류의 실패에도 진정으로 회복력이 있는 것이 아닙니다.

용량 계획은 일상적인 사용 패턴뿐만 아니라 계절적 수요, 변경된 근무 시간, 성장 또는 다른 애플리케이션의 호스팅 요구 사항으로 인한 피크를 고려해야 합니다.

특히 다중 서버 호스팅 환경에서는 단일 서버의 손실을 고려해야 하며, 다른 호스팅 노드가 실패한 노드에서 실행될 프로세스를 수용할 수 있는 여유 용량을 갖추고 있어야 합니다.

그렇지 않으면, 장애 조치 절차가 단순히 고립된 사건을 광범위한 시스템 성능 문제로 전환할 수 있습니다.

8. 데이터 및 구성 보호

대체 Windows 서버는 IT가 애플리케이션을 작동시키는 데 필요한 구성 요소를 복원할 수 없다면 거의 쓸모가 없습니다.

이것은 백업 절차에 애플리케이션 데이터, 데이터베이스, 구성 파일, 인증서, 애플리케이션 설정, 사용자 프로필, 인프라 구성, 스크립트 및 라이센스 정보가 포함되어야 함을 의미할 수 있습니다.

전략은 애플리케이션의 복구 시간 목표(RTO) 및 복구 지점 목표(RPO)에 따라 달라질 것입니다.

무엇보다도 성공적인 백업이 성공적인 복구와 같지 않다는 것을 확인해야 합니다. IT 팀은 보호된 데이터와 구성에서 전체 애플리케이션 서비스를 복원할 수 있는지 테스트해야 합니다.

변경의 폭발 반경 줄이기

예기치 않은 재해가 중단을 초래하는 경우만 있는 것은 아닙니다. 구현된 개선 사항으로 인해 발생할 수도 있습니다. 따라서 Windows 패치, 애플리케이션 및 드라이버 업그레이드, 보안 정책 및 구성 변경도 애플리케이션의 가용성에 부정적인 영향을 미칠 수 있습니다. 가능하다면 모든 프로덕션 호스트에 대해 유사한 변경을 동시에 수행하지 않는 것이 좋습니다.

다중 서버 설정에서는 개선 변경을 단계적으로 수행할 수 있어 관리자가 모든 것이 올바르게 작동하는지 확인할 수 있습니다. 변경 사항을 롤백할 수 있는 능력도 필수적입니다.

따라서 비상 절차를 설계할 때 롤백 옵션도 고려해야 합니다. 프로세스는 적절하게 문서화되어야 하며, 직원들은 변경이 실패할 경우 무엇을 해야 하는지 알아야 하며, 단순히 그들의 재량에 맡겨서는 안 됩니다.

10. 우아한 저하를 위한 디자인

회복력은 항상 정상 기능의 100%를 유지하는 것이 아닙니다.

일부 경우, 주요 사용자 또는 애플리케이션을 위한 운영을 유지하는 것이 모든 사용자에게 모든 서비스를 제공하는 것보다 더 중요할 수 있습니다. IT 팀은 사건이 발생하기 전에 우선 순위를 설정할 수 있습니다.

사용할 수 있는 용량이 있다면, 이를 먼저 생산, 고객 서비스, 재무 또는 기타 기능에 할당하는 것이 합리적일 수 있습니다.

그것은 우아한 저하입니다: 전체 시스템이 충돌하는 것을 방지하기 위해 가장 큰 비즈니스 가치를 생성하는 기능을 실행할 수 있는 능력을 유지하는 것입니다.

IT 팀은 애플리케이션 복원력을 어떻게 모니터링해야 합니까?

개별 서버 모니터링은 유용할 수 있지만, 복원력 모니터링은 사용자가 인식하는 전체 애플리케이션 서비스 반영해야 합니다.

현실적인 모델은 여러 계층으로 구성됩니다:

레이어	모니터링할 내용	예제 실패
호스트	CPU, RAM, 디스크, OS 가용성	서버가 과부하 상태이거나 오프라인입니다.
응용 프로그램	프로세스 및 서비스 상태	애플리케이션 충돌
의존성	데이터베이스, DNS, 아이덴티티, 저장소	응용 프로그램이 실행되지만 작동할 수 없습니다.
접속	게이트웨이, 포털, 네트워크 경로	사용자가 연결할 수 없습니다.
세션	활성 사용자, 실패, 지연	응용 프로그램이 온라인이지만 사용할 수 없습니다.
비즈니스 기능	성공적인 워크플로우 완료	사용자가 필요한 작업을 완료할 수 없습니다.

비즈니스 기능 계층은 간과하기 가장 쉬운 계층 중 하나입니다.

인프라 대시보드는 모든 서버, 서비스 및 네트워크 경로가 정상으로 표시될 수 있지만, 실제 사용자의 작업 흐름이 손상될 수 있습니다. 따라서 중요한 애플리케이션은 지원하도록 설계된 운영의 관점에서 자신의 상태를 모니터링하는 것이 중요합니다.

애플리케이션 복원력은 어떻게 테스트해야 합니까?

통제된 실패를 경험한 적이 없는 회복력 아키텍처는 검증되지 않은 가정을 포함하고 있습니다.

시스템의 주요 구성 요소가 사용할 수 없게 될 때 시스템의 응답을 평가하기 위해 테스트를 사용하십시오. 테스트에는 애플리케이션 호스트를 오프라인으로 전환하고, 애플리케이션 서비스를 중지하고, 네트워크 경로 손실을 시뮬레이션하고, 게이트웨이 또는 로드 밸런싱 동작을 확인하고, 백업에서 복원하고, 대체 엔드포인트에서 애플리케이션에 접근하는 것이 포함되어야 합니다.

테스트 프로세스는 복구의 기술적 측면을 넘어 확장되어야 합니다. IT 팀은 경고가 올바른 관리 인력에게 전송되고 있는지, 복구 단계가 올바른 순서로 수행되고 있는지, 서비스가 복원된 후 사용자가 실제 비즈니스 작업을 수행할 수 있는지를 검토해야 합니다.

운영 절차는 회복력 있는 시스템에 필수적입니다. 경고 에스컬레이션 절차: 누가 경고를 받습니까? 누가 장애 조치를 시작할 권한이 있습니까? 복구 문서와 자격 증명은 어디에 저장됩니까? 어떤 종속성이 먼저 온라인으로 전환되어야 합니까?

기술적 중복성은 접근을 회복하는 프로세스가 테스트되지 않았다면 거의 이점이 없습니다.

애플리케이션 복원력 체크리스트란 무엇인가요?

중요한 Windows 애플리케이션 복원력을 구축하기 전에 IT 팀은 다음 질문에 답할 수 있어야 합니다:

• 어떤 비즈니스 프로세스가 이 애플리케이션에 의존합니까?
• 그것의 RTO와 RPO는 무엇입니까?
• 어떤 서버, 데이터베이스 및 외부 서비스가 필요합니까?
• 그의 주요 단일 실패 지점은 어디인가요?
• 다른 호스트가 실패하면 다른 애플리케이션 호스트가 사용자를 수용할 수 있습니까?
• 사용자의 일반 엔드포인트나 위치가 사용 불가능할 경우 연결할 수 있나요?
• 저하된 운영을 위한 여유 용량이 충분한가요?
• 인프라, 의존성 및 세션 문제가 적극적으로 모니터링되고 있습니까?
• 관리자가 중요한 임계값이 중단되기 전에 경고를 받습니까?
• 애플리케이션 데이터와 구성은 보호됩니까?
• 복원이 실제로 테스트되었나요?
• 문제가 있는 변경 사항을 롤백할 수 있나요?
• 복구 절차가 문서화되어 있습니까?
• 사용자가 복구 후 필요한 비즈니스 프로세스를 완료할 수 있습니까?

모든 답변이 비싼 고가용성 인프라를 요구하는 것은 아닙니다. 적절한 보호 수준은 비용과 다운타임의 운영적 영향에 따라 달라집니다.

중요한 것은 가용성, 중복성 및 복구 결정이 가정되는 것이 아니라 의도적으로 이루어진다는 것입니다.

TSplus는 Windows 애플리케이션을 어떻게 지속적으로 사용할 수 있도록 도와줄 수 있나요?

기존 Windows 애플리케이션에 의존하는 조직을 위해, 관리되는 Windows 서버에 애플리케이션을 중앙 집중화하고 RDP 호환 클라이언트, RemoteApp 스타일 액세스 또는 HTML5 웹 포털을 통해 사용자에게 제공함으로써 가용성을 개선하는 데 도움을 드릴 수 있습니다. 이는 개별 사용자 엔드포인트에 대한 의존도를 줄이고, 사용자가 다른 장치나 위치에서 연결해야 할 때 IT 팀에 더 많은 유연성을 제공합니다.

TSplus 원격 액세스 다중 서버 배포를 로드 밸런싱 및 게이트웨이 기반 액세스와 함께 지원할 수 있습니다. 탄력적인 데이터베이스, 스토리지, 아이덴티티 서비스 및 네트워킹과 결합될 때, 이 아키텍처는 단일 애플리케이션 호스트에 대한 의존도를 줄이고 인프라 중단 동안 중요한 Windows 애플리케이션에 대한 액세스를 유지하는 데 도움을 줄 수 있습니다.

결론

애플리케이션 복원력은 인프라와 비즈니스 사용 간의 전체 경로를 이해하는 데 달려 있습니다. 중복성, 모니터링, 백업, 용량 계획 및 복구 절차는 명확하게 정의된 애플리케이션 의존성과 복구 목표를 중심으로 설계될 때 가장 효과적입니다.

기존 Windows 애플리케이션의 경우, 복원력은 종종 애플리케이션 자체를 재구성하기보다는 소프트웨어 주변 환경을 강화하는 데서 옵니다. 핵심 테스트는 간단합니다: 중단이 발생했을 때, 사용자가 계속 작업할 수 있는지, 아니면 IT가 합의된 복구 시간 내에 필요한 비즈니스 기능을 복원할 수 있는지입니다.