Azure SLA vs AWS SLA 비교 분석 (Service Level Agreement)
작성자
Roronoa
작성일
2021-06-02 13:45
조회
648
AWS와 Azure 의 SLA 비교
AWS와 Azure 와 같은 Cloud 벤더사는 물건을 사면 마치 보증기간을 주는것 처럼 그들의 제품의 보증서을
SLA (Service Level Agreement) 서비스 수준 협약서 라는 것을 제공합니다. 그렇다면 보증서는 만능인가?
묻지도 따지지도 않고 물건 반품을 해주지 않습니다. 그럼 어떤 조건이 필요 충분이 되어야 그에 따른 보상을
주는것인가 알아보도록 합니다.
먼저 AWS와 Azure안에 있는 제품은 수백개가 넘습니다. 이중에서 가장 중요한 제품들을 예를 들어서 설명드릴것이며
이 SLA 보장을 어떻게 잘 활용하고 어떻게 써먹어야 가장 효과적인지를 알아야지 이를 활용해서 자신이 사용하는
아키텍처에 반영할 수 있습니다. 그리고 이 SLA 를 얼만큼 믿어야 되며 얼만큼 믿지 않아야될지를 논의 해보겠습니다.
SLA vs SLO vs SLI 차이점
기업의 제품을 사용하면서 SLA SLO SLI 를 이해하고 유지하는것은 매우 중요하며 이는 제품에 대한 퀄리티를 과거,
현재, 미래를 표현하는 추정 가능한 미래를 위한 마치 견문색(가까운 미래 예측)을 위한 준비단계라 할수 있습니다.
견문색만 있으면 모든 상대를 해치울수 없듯이 이는 단순이 예측을 위한 도구일 뿐 이것으로 퀄리티를 판단한다면 실패하게 됩니다.
SLA 는 회사와 고객간의 측정 가능한 계약이라 쉽게 표현 할 수 있습니다. 그러나 이 계약 안에는 항상 충족하기
힘든 메트릭과 조건이 있습니다.
SLO는 계약이 아닌 목표입니다. 우리는 이런 목표를 가지고 달성하기 위해 최선을 다한다고 말씀드릴 수 있다
라고 하는 것으로 이는 SLA 처럼 계약이 아닌 목표이므로 더 명확하지 않은 조건이 포함됩니다.
이런 목표로 최선을 다하고 있으니 우리를 믿어달라! 그러나 계약은 아니다 라고 생각하면 됩니다.
SLI는 서비스를 측정 하는 실제 지표 입니다. 예를들어 우리는 SLA 가 99.99% 입니다. 그러면 실제 우리의 서비스가
99.99%를 달성하려면 실제 지표가 99.991% 일 수도 있고 99.999%도 있는데 이 99.99% SLA를 달성하기 위해서
계속 내부적으로 측정하는 실제 지표입니다. 이는 고객이 아닌 벤더가 계속해서 측정하는 실제 지표라 할수 있습니다.
SLA 보장
SLA 99.9%를 보장하는 상품은 월간 10분 4초간은 Down time이 날수 있으며 10분 4초를 넘어가면 월 비용 전체의 10%를
서비스 크레딧(Azure를 사용할 수 있는 비용)으로 보상해줍니다. https://uptime.is/ 링크에서 확인 할 수 있습니다.
SLA 계산식
1.월간 전체 작동 시간(Monthly Maximum Available Time/Min)
2.작동 중지 시간(Service Downtime/Min)
3.월간 가동 시간(Monthly Uptime/Min) = 1-2
4.월간 작동 시간 비율(Monthly Uptime Percentage) = ((1-2)/1)*100
4번의 계산 식이 99.9보다 작으면 그 프로덕트의 25%를 Azure를 사용할 수 있는 크레딧을 줍니다.
SLA(Service Level Agreement) -> 보증 계약
SLO(Service Level Objectives) -> 보증 목표
SLI(Service Level Indicators) -> 보증을 위한 실제 지표
AWS EC2 VS Azure 가상머신 비교하기
AWS 의 EC2와 Azure Virtual Machine은 비슷하지만 다른 구조이며 KVM 과 Hyper-V 의 가상화로 만들어진
Compute 기능을 하는 클라우드에서 가장 기본이되는 원자 같은 역활을 합니다.
동일한 AWS와 Azure 지역에 가상머신이 가용성 존에 있으며 다른지역에 두개 이상 있습니다. 이 가상머신중
최소한 1개의 인스턴스에 대해 99.99% SLA를 보장합니다. 한개의 가상머신에 대해 SLA를 보장하는 것이 아니고
이 가상머신이 2개 이상이어야 하며 이 두개 이상의 가상머신이 가용성 존에 있거나 가용성집합에 있어야 SLA를
보장하며 가상머신이 최소한 한개 이상은 장애가 없이 유지 되는 퍼센트임을 확인해야 합니다.
가상머신부분 결론
AWS의 한대의 EC2와 Azure 한대의 가상머신은 둘다 SLA 보장 하지 않습니다. 그러나 AWS에서는 EC2가
SLO를 90%로 공식문서에 나와있으므로 이부분에서 Azure는 가상머신 자체 한대는 SLO나 SLA는 없습니다.
하기의 표 처럼 디스크와 연동될 때 Azure는 SLA를 제공하며 디스크의 타입에 따라 SLA 보장을 하며 이는 가상머신과
디스크를 동시에 있을때만 보장합니다.
크기 자동조정 기능은 AWS와 Azure 둘다 SLA 를 보장 하지는 않습니다. 하기의 표만 보면 AWS가 보장을 덜하는것 처럼
보이지만 전혀 그렇지 않고 방법의 차이일 뿐입니다.
AWS EBS vs Azure 디스크 SLA 비교
Azure는 디스크는 프리미엄 이상 급 디스크의 단일 인스턴스에 대해 99.9%를 보장합니다.
(표준SSD는 99.5% 표준HDD는 95%) Azure의 경우 위에 표처럼 가상머신과 디스크를 조합해서 SLA를
제공하므로 이부분을 잘 유념해야할듯 합니다.
AWS의 EBS는 가용성 존 (AZ)에 두개 이상 연결되어 있어야 하며 그 디스크의 대기열에 IO가 읽기 쓰기가 0으로
되어 있어야만 99.99%의 SLA를 보장 합니다.대기열에 디스크 쓰기가 0이되는 부분은 쉽게 되지 않으며 이런 조건을
충족 시키기 위해서는 매우 조건이 까다로운 부분입니다. 보통은 공식문서에 AWS에 이런 조항을 넣지 않는데 정확히
표현되어 있어서 이 조건을 제외한 다른 Disk의 문제는 쉽게 SLA를 보장하지 않는 부분은 아쉽습니다.
단순히 숫자만 비교하면 이부분은 AWS는 99.99%를 보장하고 Azure 도 99.99%를 가용성 존에 2개이상 분산되어
있다는 가정하에는 같은 조건입니다. 그러나 조건이 조금씩 다른점은 인식 하고 있어야 하며 가용성 존과 HA 구성이 필요
없는 경우에는 이런 부분을 고려해서 EC2와 Virtual Machine을 아키텍처에 반영 해야 합니다.
디스크부분 결론
사실 AWS EBS와 Azure 디스크에서 이런 SLA를 고객이 전혀 원하지 않습니다. 실제로 가장 중요한 SLA 는 IOPS 와
Throughput의 평균 속도나 Performance가 가장 중요합니다. 그러나 이 부분을 AWS나 Azure에서 SLA 를 보장 하지
않으며 이부분은 품질에 대한 SLO 조차 공개되지 않으며 고객이 가장 불만을 가지고 있는 부분이라 할 수 있습니다.
왜냐면 온프레미스에서는 보통 제공이 됩니다. 많은 부분이 디스크 분야에서 SLI가 수년 동안 개선이 되긴 했지만
추후에도 이 부분은 SLA 를 보장할 만큼 수준은 먼 미래에 가능할 듯합니다.
AWS EFS vs Azure Files SLA 비교
AWS EFS와 Azure Files 는 방식이 다르지만 대표적인 “공유” 디스크 입니다.
99.99% SLA를 보장하며 EFS는 AWS EBS와는 다르게 단순이 서버지연으로 표현은 15초 이상 이며 1분간 사용할수
없으면 장애로 변정됩니다. 그러므로 EBS 보다 조건이 적고 디테일한 조건이 없습니다. 그로 인하여 다른 제품보다는
SLA에 유리하지만 가격이 다른 디스크보다 높으므로 꼭 공유에 초점이 있는 부분만 사용하고 그렇지 않은 부분에서는
다른 저장매체를 사용하는것이 비용 효율적입니다
Azure Files 는 SMB 3.0 프로토콜을 사용하는 공유 디스크입니다. 99.99% SLA를 보장하며 가장 높은 등급인
RA-GRS(읽기-액세스 지리적 중복 저장소)를 사용하고 주 읽기 지역이 실패하면 보조지역을 시도해야지 99.99%이지
기본이 99.99%는 아니므로 LRS,ZRS,GRS (99.9%) 이므로 이 부분은 눈여겨 보아야 합니다.
공유 디스크부분 결론
AWS EFS와 Azure Files에서는 가장 중요한 포인트는 AWS가 좀 더 조건이 명확하고 Azure는 조건이 덜 명확한 부분에
있습니다. 이부분은 조건이 덜 명확한 부분이 좀 더 범위가 넓다고 볼수 있습니다. 공유 디스크는 Performance 부분과
latency 가 가장 중요한 부분이나 이런 부분은 SLA에 보장이 안되므로 어떤 티어의 디스크를 써야 하는지 기능을 잘
인지하고 사용하는것이 최선입니다.
AWS와 Azure 와 같은 Cloud 벤더사는 물건을 사면 마치 보증기간을 주는것 처럼 그들의 제품의 보증서을
SLA (Service Level Agreement) 서비스 수준 협약서 라는 것을 제공합니다. 그렇다면 보증서는 만능인가?
묻지도 따지지도 않고 물건 반품을 해주지 않습니다. 그럼 어떤 조건이 필요 충분이 되어야 그에 따른 보상을
주는것인가 알아보도록 합니다.
먼저 AWS와 Azure안에 있는 제품은 수백개가 넘습니다. 이중에서 가장 중요한 제품들을 예를 들어서 설명드릴것이며
이 SLA 보장을 어떻게 잘 활용하고 어떻게 써먹어야 가장 효과적인지를 알아야지 이를 활용해서 자신이 사용하는
아키텍처에 반영할 수 있습니다. 그리고 이 SLA 를 얼만큼 믿어야 되며 얼만큼 믿지 않아야될지를 논의 해보겠습니다.
SLA vs SLO vs SLI 차이점
기업의 제품을 사용하면서 SLA SLO SLI 를 이해하고 유지하는것은 매우 중요하며 이는 제품에 대한 퀄리티를 과거,
현재, 미래를 표현하는 추정 가능한 미래를 위한 마치 견문색(가까운 미래 예측)을 위한 준비단계라 할수 있습니다.
견문색만 있으면 모든 상대를 해치울수 없듯이 이는 단순이 예측을 위한 도구일 뿐 이것으로 퀄리티를 판단한다면 실패하게 됩니다.
SLA 는 회사와 고객간의 측정 가능한 계약이라 쉽게 표현 할 수 있습니다. 그러나 이 계약 안에는 항상 충족하기
힘든 메트릭과 조건이 있습니다.
SLO는 계약이 아닌 목표입니다. 우리는 이런 목표를 가지고 달성하기 위해 최선을 다한다고 말씀드릴 수 있다
라고 하는 것으로 이는 SLA 처럼 계약이 아닌 목표이므로 더 명확하지 않은 조건이 포함됩니다.
이런 목표로 최선을 다하고 있으니 우리를 믿어달라! 그러나 계약은 아니다 라고 생각하면 됩니다.
SLI는 서비스를 측정 하는 실제 지표 입니다. 예를들어 우리는 SLA 가 99.99% 입니다. 그러면 실제 우리의 서비스가
99.99%를 달성하려면 실제 지표가 99.991% 일 수도 있고 99.999%도 있는데 이 99.99% SLA를 달성하기 위해서
계속 내부적으로 측정하는 실제 지표입니다. 이는 고객이 아닌 벤더가 계속해서 측정하는 실제 지표라 할수 있습니다.
SLA 보장
SLA 99.9%를 보장하는 상품은 월간 10분 4초간은 Down time이 날수 있으며 10분 4초를 넘어가면 월 비용 전체의 10%를
서비스 크레딧(Azure를 사용할 수 있는 비용)으로 보상해줍니다. https://uptime.is/ 링크에서 확인 할 수 있습니다.
SLA 계산식
1.월간 전체 작동 시간(Monthly Maximum Available Time/Min)
2.작동 중지 시간(Service Downtime/Min)
3.월간 가동 시간(Monthly Uptime/Min) = 1-2
4.월간 작동 시간 비율(Monthly Uptime Percentage) = ((1-2)/1)*100
4번의 계산 식이 99.9보다 작으면 그 프로덕트의 25%를 Azure를 사용할 수 있는 크레딧을 줍니다.
SLA(Service Level Agreement) -> 보증 계약
SLO(Service Level Objectives) -> 보증 목표
SLI(Service Level Indicators) -> 보증을 위한 실제 지표
AWS EC2 VS Azure 가상머신 비교하기
AWS 의 EC2와 Azure Virtual Machine은 비슷하지만 다른 구조이며 KVM 과 Hyper-V 의 가상화로 만들어진
Compute 기능을 하는 클라우드에서 가장 기본이되는 원자 같은 역활을 합니다.
동일한 AWS와 Azure 지역에 가상머신이 가용성 존에 있으며 다른지역에 두개 이상 있습니다. 이 가상머신중
최소한 1개의 인스턴스에 대해 99.99% SLA를 보장합니다. 한개의 가상머신에 대해 SLA를 보장하는 것이 아니고
이 가상머신이 2개 이상이어야 하며 이 두개 이상의 가상머신이 가용성 존에 있거나 가용성집합에 있어야 SLA를
보장하며 가상머신이 최소한 한개 이상은 장애가 없이 유지 되는 퍼센트임을 확인해야 합니다.
가상머신부분 결론
AWS의 한대의 EC2와 Azure 한대의 가상머신은 둘다 SLA 보장 하지 않습니다. 그러나 AWS에서는 EC2가
SLO를 90%로 공식문서에 나와있으므로 이부분에서 Azure는 가상머신 자체 한대는 SLO나 SLA는 없습니다.
하기의 표 처럼 디스크와 연동될 때 Azure는 SLA를 제공하며 디스크의 타입에 따라 SLA 보장을 하며 이는 가상머신과
디스크를 동시에 있을때만 보장합니다.
크기 자동조정 기능은 AWS와 Azure 둘다 SLA 를 보장 하지는 않습니다. 하기의 표만 보면 AWS가 보장을 덜하는것 처럼
보이지만 전혀 그렇지 않고 방법의 차이일 뿐입니다.
AWS EBS vs Azure 디스크 SLA 비교
Azure는 디스크는 프리미엄 이상 급 디스크의 단일 인스턴스에 대해 99.9%를 보장합니다.
(표준SSD는 99.5% 표준HDD는 95%) Azure의 경우 위에 표처럼 가상머신과 디스크를 조합해서 SLA를
제공하므로 이부분을 잘 유념해야할듯 합니다.
AWS의 EBS는 가용성 존 (AZ)에 두개 이상 연결되어 있어야 하며 그 디스크의 대기열에 IO가 읽기 쓰기가 0으로
되어 있어야만 99.99%의 SLA를 보장 합니다.대기열에 디스크 쓰기가 0이되는 부분은 쉽게 되지 않으며 이런 조건을
충족 시키기 위해서는 매우 조건이 까다로운 부분입니다. 보통은 공식문서에 AWS에 이런 조항을 넣지 않는데 정확히
표현되어 있어서 이 조건을 제외한 다른 Disk의 문제는 쉽게 SLA를 보장하지 않는 부분은 아쉽습니다.
단순히 숫자만 비교하면 이부분은 AWS는 99.99%를 보장하고 Azure 도 99.99%를 가용성 존에 2개이상 분산되어
있다는 가정하에는 같은 조건입니다. 그러나 조건이 조금씩 다른점은 인식 하고 있어야 하며 가용성 존과 HA 구성이 필요
없는 경우에는 이런 부분을 고려해서 EC2와 Virtual Machine을 아키텍처에 반영 해야 합니다.
디스크부분 결론
사실 AWS EBS와 Azure 디스크에서 이런 SLA를 고객이 전혀 원하지 않습니다. 실제로 가장 중요한 SLA 는 IOPS 와
Throughput의 평균 속도나 Performance가 가장 중요합니다. 그러나 이 부분을 AWS나 Azure에서 SLA 를 보장 하지
않으며 이부분은 품질에 대한 SLO 조차 공개되지 않으며 고객이 가장 불만을 가지고 있는 부분이라 할 수 있습니다.
왜냐면 온프레미스에서는 보통 제공이 됩니다. 많은 부분이 디스크 분야에서 SLI가 수년 동안 개선이 되긴 했지만
추후에도 이 부분은 SLA 를 보장할 만큼 수준은 먼 미래에 가능할 듯합니다.
AWS EFS vs Azure Files SLA 비교
AWS EFS와 Azure Files 는 방식이 다르지만 대표적인 “공유” 디스크 입니다.
99.99% SLA를 보장하며 EFS는 AWS EBS와는 다르게 단순이 서버지연으로 표현은 15초 이상 이며 1분간 사용할수
없으면 장애로 변정됩니다. 그러므로 EBS 보다 조건이 적고 디테일한 조건이 없습니다. 그로 인하여 다른 제품보다는
SLA에 유리하지만 가격이 다른 디스크보다 높으므로 꼭 공유에 초점이 있는 부분만 사용하고 그렇지 않은 부분에서는
다른 저장매체를 사용하는것이 비용 효율적입니다
Azure Files 는 SMB 3.0 프로토콜을 사용하는 공유 디스크입니다. 99.99% SLA를 보장하며 가장 높은 등급인
RA-GRS(읽기-액세스 지리적 중복 저장소)를 사용하고 주 읽기 지역이 실패하면 보조지역을 시도해야지 99.99%이지
기본이 99.99%는 아니므로 LRS,ZRS,GRS (99.9%) 이므로 이 부분은 눈여겨 보아야 합니다.
공유 디스크부분 결론
AWS EFS와 Azure Files에서는 가장 중요한 포인트는 AWS가 좀 더 조건이 명확하고 Azure는 조건이 덜 명확한 부분에
있습니다. 이부분은 조건이 덜 명확한 부분이 좀 더 범위가 넓다고 볼수 있습니다. 공유 디스크는 Performance 부분과
latency 가 가장 중요한 부분이나 이런 부분은 SLA에 보장이 안되므로 어떤 티어의 디스크를 써야 하는지 기능을 잘
인지하고 사용하는것이 최선입니다.