[Azure Certi] AZ-900 Certi 준비 (5) - Azure 아키텍처 및 서비스 보증에 대하여

장애 발생시 정보를 보호할 수 있도록 서비스와 데이터를 중복시키려고 할 때, 인프라를 호스팅할 때 이 요구 사항에 따라 중복된 하드웨어 환경을 만들어야 한다. Azure에서는 ‘가용성 영역’을 통해 앱의 가용성을 높일 수 있다.

가용성 영역이란?

가용성 영역은 Azure 지역 내 물리적으로 분리된 데이터센터다.

각 가용성 영역은 독립된 전원, 냉각 및 네트워킹을 갖춘 하나 이상의 데이터 센터로 구성된다. 가용성 영역은 ‘격리 경계’로 설정되는데, 한 영역이 다운되어도 다른 영역은 계속 작동한다. 가용성 영역은 고속 프라이빗 광 네트워크를 통해 연결된다.

지원되는 Azure 지역

일부 Azure 지역에서는 가용성 영역이 지원되지 않는다. 다음 Azure 지역은 복원력을 보장할 수 있도록 세개 이상의 별도 영역을 가지고 있다.

미국 중부
미국 동부 2
미국 서부 2
서유럽
프랑스 중부
북유럽
동남 아시아

앱에서 가용성 영역 사용

가용성 영역을 사용하여 중요 업무용 어플리케이션을 실행할 수 있으며, 한 영역 내에 컴퓨팅, 스토리지, 네트워킹 및 데이터 리소스를 공동 배치하고 다른 영역에 복제하여 어플리케이션 아키텍처에 고가용성을 구현할 수 있다. 서비스를 중복시키고 영역 간에 데이터를 전송하는 비용이 발생할 수 있다.

가용성 영역은 주로 VM, 관리 디스크, 부하 분산 장치 및 SQL 데이터베이스에 주로 사용된다. 가용성 영역을 지원하는 Azure 서비스는 다음의 두 범주라 나뉜다.

영역 서비스 - 특정 영역에 리소스를 고정한다. (예. 가상 머신, 관리 디스크, IP주소)
영역 중복 서비스 - 플랫폼이 영역에서 자동으로 복제된다. (예 : 영역 중복 스토리지, SQL Database)

설명서를 통해 가용성 영역에 연결할 수 있는 아키텍처 요소를 확인하자.

Azure의 지역 쌍 이해

가용성 영역은 하나 이상의 데이터 센터를 사용하여 생성되며 단일 지역 내 최소 3개의 영역이 있다. 그러나 두 데이터 센터 모두 중단될 정도로 큰 영향을 줄 만큼 대규모 재해가 발생할 수도 있다. 이러한 이유로 Azure는 항상 “Azure 지역쌍”을 만든다.

Azure 지역 쌍이란?

각 Azure 지역은 300마일 이상 떨어져 있는 동일한 지리적 위치(예 : 미국, 유럽 또는 아시아) 내의 다른 Azure 지역과 항상 쌍을 이룬다. 이 방법을 통해 한 지리적 위치에서 가상 머신 스토리지와 같은 리소스를 복제할 수 있으며, ㅍ이렇게 하면 두 Azure 지역에 동시에 영향을 주는 자연재해, 내전, 정전 또는 물리적 네트워크 중단 등의 이벤트 때문에 서비스가 중단될 가능성을 줄일 수 있다.

예를 들어, 한 쌍의 지역이 자연 재해의 영향을 받은 경우 서비스는 해당 지역 쌍의 다른 지역으로 자동으로 장애 조치(failover) 된다.

Azure 지역 쌍의 예로는 미국 동부와 미국 서부 쌍, 동남 아시아와 동아시아 쌍이 있다.

Azure 지역 쌍은 직접 연결되고 Azure 지역 규모의 재해를 피할 수 있도록 충분히 멀리 떨어져 있기 때문에 안정적인 서비스 및 데이터 중복성을 제공하는 데 사용할 수 있다. 일부 서비스는 Azure 지역 쌍을 사용하여 자동 지역 중복 스토리지를 제공한다.

Azure 지역 쌍의 추가적인 이점은 아래와 같다.

광범위한 Azure 중단이 발생하는 경우 해당 지역 쌍에서 호스트되는 어플리케이션에 대해 하나 이상의 지역이 가능한 빨리 복원되도록 하기 위해 모든 쌍 중에서 하나의 지역이 우선하도록 지정된다.
계획된 Azure 업데이트는 가동 중지 및 어플리케이션 중단 위험을 최소화하기 위해 한번에 한 Azure 지역 쌍으로 롤아웃 된다.
데이터는 세금 및 법률 집행 관할 구역에서 사용될 수 있게 동일한 지리적 위치 내에 쌍으로 상주한다.

Azure의 SLA(서비스 수준 계약) 이해

마이크로소프트는 SLA(서비스 수준 계약) 라고 하는 공식문서가 있어 Azure에 적용된는 성능 표준을 정의하는 특정 조건을 캡처한다.

SLA는 Azure고객에게 특정 성능 표준을 제공하겠다는 Microsoft의 약정을 설명한다.
개별 Azure 제품 및 서비스에 대한 SLA가 있다.
SLA는 서비스 또는 제품이 관련 SLA 사양을 수행하지 못할 때 발생하는 일을 지정한다.

Azure 제품 및 서비스의 SLA

Azure 제품 및 서비스의 SLA는 세 가지 주요 특징을 갖고 있습니다.

성능 목표
작동 시간 및 연결 보증
서비스 크레딧

성능 목표

SLA는 Azure 제품 또는 서비스의 성능 목표를 정의합니다. SLA가 정의하는 성능 목표는 각 Azure 제품 및 서비스로 한정됩니다. 예를 들어 일부 Azure 서비스의 성능 목표는 작동 시간 보증 또는 연결률로 표현됩니다.

작동 시간 및 연결 보증

일반적인 SLA는 해당하는 각 Azure 제품 또는 서비스의 성능 목표 약정을 99.9%(“3개의 9”)에서 99.999%(“5개의 9”) 사이에서 지정합니다. 이러한 목표는 서비스의 작동 시간 또는 응답 시간 같은 성능 기준에 적용할 수 있습니다.

다음 표는 여러 시간 동안 다양한 SLA 수준의 잠재적인 누적 가동 중지 시간을 보여줍니다.

테이블 1SLA %주간 가동 중지 시간월간 가동 중지 시간연간 가동 중지 시간

99	1.68시간	7.2시간	3.65일
99.9	10.1분	43.2분	8.76시간
99.95	5분	21.6분	4.38시간
99.99	1.01분	4.32분	52.56분
99.999	6초	25.9초	5.26분

예를 들어 Azure Cosmos DB(Database) 서비스 SLA는 99.999% 작동 시간을 제공하며, 여기에는 DB 읽기 작업뿐만 아니라 DB 쓰기 작업에서도 10밀리초 미만의 짧은 대기 시간이 포함됩니다.

서비스 크레딧

또한 SLA는 Azure 제품 또는 서비스가 관련 SLA 사양을 수행하는 데 실패할 경우 Microsoft에서 어떻게 대응할 것인지를 설명합니다.

예를 들어 고객은 성능이 떨어지는 Azure 제품 또는 서비스에 대한 보상으로 Azure 가격 할인을 받을 수 있습니다. 아래 표에는 이 예에 대한 내용이 자세히 설명되어 있습니다.

아래 테이블의 첫 번째 열은 단일 인스턴스 Azure Virtual Machine의 월간 SLA 목표 백분율을 보여줍니다. 두 번째 열은 해당 월의실제가동 시간이 SLA에 지정된 목표보다 적은 경우에 받게 되는 서비스 크레딧 금액을 보여줍니다.

테이블 2월간 가동률서비스 크레딧 백분율

< 99.9	10
< 99	25
< 95	100

서비스 간 SLA 구성

여러 서비스 제품 간에 SLA를 결합할 때 그 결과로 얻은 SLA를 복합 SLA라고 한다. 결과로 얻은 복합 SLA는 어플리케이션 아키텍처에 따라 더 높거나 낮은 가동 시간 값을 제공할 수 있다.

가동 중지 시간 계산

Azure SQL Database에서 쓰는 App Service 웹앱을 생각해보자. 이러한 Azure 서비스의 현재 SLA는 아래와 같다.

이 예에서는 두 서비스 중 하나가 중단되면 전체 어플리케이션이 중단된다. 일반적으로 각 서비스의 개별 확률 값은 독립적이다. 그러나 이 어플리케이션의 복합 SLA 값은 다음과 같다.

99.95 percent × 99.99 percent = 99.94 percent

즉, 결합된 실패 확률은 개별 SLA 값보다 높다. 여러 서비스를 사용하는 어플리케이션이 잠재적 오류 지점이 더 많다. 반면, 독립적인 대체 경로를 만들어서 복합 SLA를 높일 수 있다. 예를들어 SQL Database를 사용할 수 없으면 트랜잭션을 큐에 배치하여 나중에 처리할 수 있다.

이 디자인에서는 어플리케이션이 데이터베이스에 연결할 수 없는 경우에도 계속 사용할 수 있다. 그러나 데이터베이스와 큐가 동시에 중단되면 어플리케이션도 중단된다.

예상되는 동시 중단 시간 비율이 0.0001 x 0.001 이면 데이터베이스 또는 큐의 이 복합 경로에 대한 복합 SLA 는 아래와 같다.

1	`1.0 − (0.0001 × 0.001) = 99.99999 percent`

따라서 큐를 웹앱을 추가하면 총 복합 SLA는 다음과 같습니다.

1	`99.95 percent × 99.99999 percent = ~99.95 percent`

SLA 동작이 많이 개선되긴 하나, 이 방법을 사용하면 어플리케이션 로직이 복잡해진다. 큐 지원을 추가하기 위해 더 많은 비용을 지불해야 하고, 재시도 동작으로 인해 데이터 일관성 문제가 발생할 수 있다.

Azure의 앱 안정성 향상

SLA를 이용하여 Azure 솔루션이 클라이언트와 사용자의 비즈니스 요구 사항 및 수요를 얼마나 충족하는지 평가할 수 있다. 고유한 SLA를 만들어서 고객의 특정 Azure 어플리케이션에 맞는 성능 목표를 설정할 수 있다. 이 접근 방식을 어플리케이션 SLA라고 한다.

앱 요구 사항 이해

효율적이고 신뢰할 수 있는 Azure 솔루션을 빌드하려면 요구사항을 알아야 한다. 그 후 Azure 제품 및 서비스를 선택하고, 요구 사항에 따라 리소스를 프로비전 할 수 있다. 솔루션에 포함된 Azure 제품 및 서비스의 성능 목표를 정의하는 Azure SLA를 반드시 이해해야 한다. 달성 가능한 어플리케이션 SLA를 만드는 데 도움이 되기 때문이다.

복원력

복원력은 오류를 복구하여 계속 작동하는 시스템 기능이다. 오류를 방지하는 것이 아니라 가동 중지 또는 데이터 손실을 방지하는 바업ㅂ으로 오류에 대응한다. 복원력의 목표는 오류가 발생한 후 어플리케이션을 완전히 작동하는 상태로 되돌리는 것이다. 복원력의 두 가지 중요한 측변은 고가용성과 재해복구(?? fault tolerance)다.

아키텍처를 설계할 때 복원력을 설계해야 하며, FMA(실패 모드 분석)를 수행해야 한다. FMA의 목표는 가능한 실패 지점을 식별하고 어플리케이션이 이러한 오류에 대응하는 방식을 정의하는 것이다.

비용 및 복잡성과 고가용성

가용성이란 시스템이 정상적으로 작동하는 시간을 말한다. 가용성을 최대화하려면 가능한 서비스 오류를 방지하는 수단을 구현해야 한다. 그러나 예방 수단을 고안하는 것은 어렵고 비용이 많이 들 수 있고, 복잡한 솔루션으로 이어지는 경우가 많다.

솔루션의 복잡성이 증가할수록 점점 더 많은 서비스가 서로 종속된다. 따라서 상호 종속 관계인 서비스가 여러 개 있으면 솔루션의 오류 지점을 놓치게 될 수 있다.

대부분의 공급 기업은 가동 중지 시간을 최소화하여 Azure 솔루션의 가용성을 극대화하려고 한다. 그러나 가용성을 솦이면 솔루션의 비용과 복잡성도 함께 높아진다.

잠재적 가동 중단의 위험은 다양한 SLA 수준에서 누적되며, 복잡한 솔루션일수록 더 큰 가용성 문제에 직면할 수 있다. 따라서 고가용성이 요구 사항에서 차지하는 비중에 따라 어플리케이션 SLA에 추가되는 복잡성과 비용이 결정된다.

애플리케이션 SLA를 정의할 때 고려할 사항

애플리케이션 SLA에서 정의하는 성능 목표가 4개의 9(99.99%)인 경우 수동 작업으로 오류를 복구하면 SLA를 충족하기에 충분하지 않을 수 있습니다. Azure 솔루션이 자체적으로 진단하고 자체적으로 복구해야 합니다.
4개의 9보다 높은 SLA 성능 목표를 충족하도록 신속하게 오류에 대응하기는 쉽지 않습니다.
애플리케이션 SLA 성능 목표를 측정할 시간 범위를 신중하게 고민해야 합니다. 시간 범위가 짧을수록 허용 오차도 작습니다. 애플리케이션 SLA를 시간 단위 또는 일 단위 가동 시간으로 정의하는 경우 허용 오차가 작으면 성능 목표를 달성하지 못할 수 있다는 점을 이해해야 합니다.