클라우드에서 애플리케이션 가용성 계산

Date: 12월 18, 2020

클라우드에서 애플리케이션 가용성 계산

클라우드에 비즈니스 크리티컬 애플리케이션을 배포 할 때 가용성이 높은지 확인하려고합니다. 좋은 소식은 제대로 계획하면 99.99 % (4-9) 이상의 가용성을 달성 할 수 있다는 것입니다. 그러나 실제 가용성을 계산하는 것은 생각만큼 간단하지 않을 수 있습니다.

가용성을 고려할 때 애플리케이션에 대한 액세스를 가능하게하는 주요 구성 요소를 고려해야합니다.이를 가용성 체인이라고합니다. 가용성 체인의 구성 요소는 다음과 같습니다.

• 계산
• 회로망
• 저장
• 신청
• 종속 서비스

애플리케이션은 가장 약한 링크만큼만 사용할 수 있으며, 체인에 링크를 추가 할 때마다 다운 타임이 기하 급수적으로 증가합니다.각 링크를 살펴 보겠습니다.

컴퓨팅 가용성

세 가지 주요 클라우드 서비스 공급자는 각각 몇 가지 유사점이 있습니다. 세 가지 플랫폼에서 공통적으로 사용되는 한 가지는 컴퓨팅에 대해 약속 할 SLA (서비스 수준 계약)입니다.

서로 다른 가용성 영역에 구성된 두 개 이상의 VM이있는 경우 VM에 대한 세 가지 공용 클라우드 공급자 모두에 대한 SLA는 99.99 %입니다.이 SLA는 주어진 시간에 VM 중 하나의 원격 액세스 가능성 만 보장하며 VM 내에서 실행되는 서비스 또는 애플리케이션의 가용성에 대해서는 약속하지 않습니다.단일 데이터 센터 내에 단일 VM을 배포하는 경우이 SLA는 "시간당 90 %"(AWS)에서 99.5 % (Azure 및 GCP) 또는 99.9 % (프리미엄 SSD 사용시 Azure 단일 VM)까지 다양합니다.

진정한 고 가용성은 99.99 %에서 시작하므로 애플리케이션을 사용할 수 있는지 확인하는 첫 번째 단계는 애플리케이션이 가용성 영역에 걸쳐있는 두 개 이상의 VM에 분산되어 있는지 확인하는 것입니다. 두 개의 VM이 두 개의 가용 영역에 분산되어 있으므로 해당 VM 중 하나 이상에 대해 99.99 %의 가용성을 제공하는 경우 세 개의 가용 영역에 분산 된 세 개의 VM이있는 경우 가용성이 99.99 %보다 훨씬 더 크다는 이론을 세울 수 있습니다. 클라우드 제공 업체의 SLA는 사용중인 가용성 영역의 수에 관계없이 99.99 % 이상의 가용성을 보장하지 않지만 순수 통계를 사용하면 가용성이 99.999999 % 또는 8-99 %까지 증가 할 수 있다는 결론에 도달 할 수 있습니다. 가용성, 월 26.30 밀리 초의 다운 타임.

1-(. 0001 * .0001) = .99999999

3 개의 가용 영역으로 99.999999 % 가용성?

그 숫자를 인용하지 마세요. 하지만 두 개의 가용 영역이 99.99 %의 가용성을 제공 할 수 있다는 점을 명심하십시오. 3 개의 가용성 영역이 99.99 % 이상의 가용성을 제공 할 것이라는 것은 당연합니다.

컴퓨팅은 가용성 체인에서 하나의 링크 일뿐입니다. 우리는 여전히 네트워크, 스토리지 및 기타 종속 서비스를 처리해야하며, 이는 모두 가능한 장애 지점을 나타냅니다.

네트워크 가용성

애플리케이션을 사용할 수 있으려면 클라이언트와 애플리케이션 간의 모든 네트워크 홉과 애플리케이션이 의존하는 모든 리소스가 사용 가능하고 허용 가능한 대기 시간 범위 내에서 작동해야합니다. 네트워크가 실패 할 수있는 위치를 정확하게 파악하려면 데이터베이스 서버, 애플리케이션 서버, 웹 서버 및 클라이언트 간의 네트워크 링크를 이해해야합니다. 가용성 체인에 링크가 많을수록 전체 가용성이 낮아집니다.

동일한 vNet에있는 VM 간의 네트워크 가용성은 표준 컴퓨팅 SLA에 포함되지만 다른 네트워크 서비스를 활용할 수도 있습니다. 다음은 전체 애플리케이션 가용성에 영향을 미칠 수있는 네트워크 서비스의 몇 가지 예입니다.

급행 노선 – 99.95 %
VPN 게이트웨이 – 99.9 % ~ 99.95 %
부하 분산기 – 99.99 %
Traffic Manager – 99.99 %
Elastic Load Balancer – 99.99 %
직접 연결 – 99.9 % – 99.99 %

지금까지 배운 내용을 바탕으로 두 가용 영역에 배포 된 애플리케이션의 가용성을 살펴 보겠습니다.

99.99 % 컴퓨팅 가용성

99.99 %로드 밸런서 가용성

.9999 * .9999 = .9998

99.98 % 가용성 = 월별 다운 타임 최대 9 분

컴퓨팅 및 네트워크 가용성에 대해 다루었으므로 이제 스토리지로 이동하겠습니다.

스토리지 가용성

이제 여기에서 이야기가 조금 더 복잡해집니다. 다음 스토리지 SLA를 살펴보십시오.

https://azure.microsoft.com/en-us/support/legal/sla/storage/v1_5/

https://cloud.google.com/storage/sla

https://aws.amazon.com/compute/sla/

Azure와 Google이 블록 스토리지 솔루션에 대해 99.9 %의 SLA를 제공하고 있음이 분명해 보입니다. AWS는 여기서 EBS를 구체적으로 언급하지 않습니다. VM에 대해 이야기하고 다른 클라우드 제공 업체와 마찬가지로 월 단위가 아닌 시간 단위로 단일 인스턴스 VM 가용성을 측정합니다. 논의를 위해 Azure와 GCP가 모두 게시 한 99.9 % 가용성 보장을 사용하겠습니다.

이전 예제를 바탕으로 방정식에 저장 공간을 추가해 보겠습니다.

99.99 % 컴퓨팅 가용성

99.99 %로드 밸런서 가용성

99.9 % 관리 디스크

.9999 * .9999 * .999 = .9988

99.88 % 가용성 = 매월 약 53 분의 다운 타임.

53 분의 다운 타임은 이전 예제에서 계산 한 9 분의 다운 타임보다 훨씬 큽니다. 99.9 % 스토리지 가용성의 영향을 최소화하려면 어떻게해야합니까? 우리는 스토리지에 더 많은 중복성을 구축해야합니다!

다행히 애플리케이션 가용성을 계획 할 때 일반적으로 스토리지 중복성을 포함합니다. 예를 들어 웹 서버를 세우면 각 웹 서버는 일반적으로 로컬로 연결된 디스크에 데이터를 저장합니다. 도메인 컨트롤러를 배포 할 때 Microsoft Active Directory는 모든 도메인 컨트롤러에서 AD 정보를 복제합니다. SQL Server와 같은 경우에는 Always On 가용성 그룹 또는 SIOS DataKeeper를 활용하여 로컬에 연결된 디스크에서 데이터를 동기화 상태로 유지합니다.

여러 가용 영역에 배포 한 데이터 사본이 많을수록 장애에서 살아남을 가능성이 높아집니다.

예를 들어 서로 다른 가용성 영역에있는 두 개의 서로 다른 디스크에 데이터를 저장하는 애플리케이션은 중복성의 이점을 얻을 수 있으며 99.9 % 가용성 대신 99.9999 %의 스토리지 가용성을 달성 할 가능성이 높습니다.

1 – (.001 * .001) = .999999

이것을 앞의 방정식에 넣으면 그림이 조금 더 밝아지기 시작합니다.

.9999 * .9999 * .999999 = .9998

99.98 % 가용성 = 최대 9 분의 다운 타임

여러 AZ, 즉 여러 디스크에 걸쳐 데이터를 복제함으로써 클라우드 스토리지와 관련된 가동 중지 시간을 효과적으로 완화했습니다.

애플리케이션 및 종속 서비스 가용성

컴퓨팅, 네트워크 및 스토리지 가용성을 보장하기 위해 할 수있는 모든 작업을 수행했습니다. 하지만 애플리케이션 자체는 어떻습니까? 일부 애플리케이션은 동일한 애플리케이션의 여러 인스턴스간에 부하를 분산하여 확장하고 중복성을 제공 할 수 있습니다. 일반적으로 5 개의 서버간에 웹 요청 부하를 분산 할 수있는 일반적인 웹 서버 팜을 생각해보십시오. 서버 하나가 손실되면로드 밸런서가 다시 응답 할 때까지 순환에서 서버를 제거합니다.

다른 응용 프로그램은 좀 더 많은 관리와 모니터링이 필요합니다. 예를 들어 SQL Server를 사용하십시오. 일반적으로 Always On 가용성 그룹 또는 장애 조치 클러스터 인스턴스는 데이터베이스 가용성을 모니터링하고 응용 프로그램 또는 시스템 수준 오류로 인해 데이터베이스가 응답하지 않는 경우 복구 작업을 수행하는 데 사용됩니다. SQL Server 가용성 솔루션에 대해 게시 된 SLA는 없지만 고 가용성을 위해 적절하게 구성하면 SQL Server가 99.99 %의 가용성을 제공 할 수 있다는 것이 일반적으로 받아 들여집니다.

호스팅 된 Active Directory, 호스팅 된 DNS, 마이크로 서비스와 같은 다른 클라우드 기반 서비스에 의존 할 수 있으며, 클라우드 포털 자체의 가용성까지도 전체 가용성 방정식에 반영해야합니다.

요약

애플리케이션 가용성은 모든 움직이는 부품의 합계입니다. 한 영역 만 스킴은 애플리케이션의 전체 가용성에 기하 급수적으로 영향을 미칠 수 있습니다. 시간을내어 컴퓨팅, 네트워크, 스토리지, 애플리케이션 및 종속 서비스를 포함한 약점에 대한 가용성 체인의 모든 링크를 조사하십시오.

일반적으로 여기에 제시된 수치는 최악의 시나리오이며 실제 가용성은 게시 된 SLA를 초과해야합니다. 숙제를하고 고 가용성으로 간주되는 일반적인 임계 값 인 99.99 % 가용성을 보장 할 수없는 서비스에주의하십시오.

인적 오류 및 보안은이 기사에서 다루지 않았습니다. 애플리케이션을 가능한 한 고 가용성으로 만들 수 있습니다. 그러나 외부 위협과 어리석은 인간의 실수로부터 애플리케이션을 보호하기위한 조치를 취하지 않은 경우 가용성과 관련하여 모든 베팅이 해제됩니다.