AWS : 안정성, 가용성, 고가용성, 내결함성, 확장성 의미

Amazon CTO인 Werner Vogels 왈 "모든 것은 고장나기 마련(Everything fails, all the time)"

 

AWS Well-Architected 프레임워크에서 제시하는 모범 사례 중 하나는 장애(애플리케이션/워크로드 중지)에 대한 계획을 수립하는 것

-> 장애를 견디도록 애플리케이션과 워크로드를 설계해야함!

 

클라우드 아키텍트가 장애를 견디도록 아키텍처를 설계할 때 고려하는 두 가지 중요한 요소

1. 안정성

• 사용자가 원할 때 기능을 제공할 수 있는 시스템의 능력을 측정하는 척도
• 모든 것에서 항상 장애가 발생할 수 밖에 없으므로 통계적 방식으로 안정성을 생각해야함
• 안정성은 일정 기간 동안 전체 시스템이 정상적으로 작동할 확률을 의미
• 시스템에는 펌웨어 및 소프트웨어와 같은 여러 시스템 구성요소가 포함되어 있음
• -> 이러한 시스템 구성 요소의 장애는 시스템의 가용성에 영향을 미침
• MTBF : 안정성을 측정하는 방법. 총 서비스 시간 / 장애 횟수

2. 가용성

• 시스템 구성 요소의 장애는 가용성에 영향을 끼침
• 가용성 : 시스템이 정상적으로 작동하거나 작업을 올바르게 수행하는 시간의 비율, 총시간 대비 정상 작동 시간
• 예정된 중단, 예정되지 않은 중단 포함 애플리케이션이 정상적으로 작동하지 않을 때마다 가용성이 저하됨
• 가용성은 일정 기간(일반적으로 1년) 동안의 가동 시간 비율(장애 간에 시스템이 온라인 상태로 유지되는 시간)으로 정의됨
• 9의 개수 - 9가 5개이면 99.999%의 가용성을 의미

 

고가용성

• 성능이 어느 정도 저하되더라도 시스템이 사용 가능한 상태로 유지되는 시스템
• 고가용성 시스템에서는 가동 중지 시간이 최소화되고, 사람의 개입이 거의 필요X
• 고가용성 시스템은 서로 유기적으로 작동, 필수 서비스를 보장하는 시스템 전체의 공유 리소스 집합이라고 할 수 있음
• 소프트웨어를 개방형 표준 하드웨어와 결합하여 시스템 구성 요소 또는 애플리케이션이 실패할 때 필수 서비스를 신속하게 복원 -> 가동 중단 시간 최소화
• 서비스는 대개 1분이내에 복원됨

 

가용성의 요구사항은 다 다름

허용되는 중단 기간은 애플리케이션 유형에 따라 다름

 

<각 가용성 계층에서 자주 볼 수 있는 애플리케이션 유형의 예제>

가용성	최대 중단 시간(연간)	애플리케이션 범주
99%	3일 15시간	배치 처리, 데이터 추출, 전송, 로드 작업
99.9%	8시간 45분	지식 관리, 프로젝트 추적과 같은 내부 도구
99.95%	4시간 22분	온라인 상거래, PoS(Point of Sale)
99.99%	52분	비디오 전송, 방송 시스템
99.999%	5분	ATM 거래, 통신 시스템

Q. 99.95%는 뭐지..? 9의 개수를 의미한다고 했는데 그럼 99.9와 99.99의 중간을 의미하는 건가?

 

가용성에 영향을 미치는 요인

1. 내결함성

• 애플리케이션 구성 요소의 기본 이중화 기능, 일부 구성 요소에 장애가 발생하더라도 애플리케이션이 작동 상태를 유지하는 능력
• 특수 하드웨어를 사용하여 시스템 구성 요소(ex. 프로세서, 메모리 보드, 전원 공급 장치, I/O 하위 시스템, 스토리지 하위 시스템)의 장애를 탐지하는 즉시 해당 구성 요소를 이중화된 하드웨어 구성 요소로 전환
• 내결함성 모델은 소프트웨어 장애를 해결하지 못함 -> 가동 중단 시간이 발생하는 가장 일반적인 이유가 소프트웨어 장애이기 때문

2. 확장성

• 요구 용량 증가에 대비, 가용성 유지, 요구되는 표준 내에서 성능을 보장하는 애플리케이션의 능력
• 확장성이 가용성을 보장 X, 애플리케이션의 가용성에 영향O

3. 복구성

• 재해로 인해 구성 요소가 사용 불능 상태가 되거나 데이터가 파괴될 경우 데이터 손실 없이 서비스를 신속하게 복원하는 능력

 

- 일반적으로, 가용성을 개선하면 비용이 증가함!에 유의

- 환경의 가용성을 높일 방법을 고려할 때 개선 비용과 사용자에게 돌아가는 혜택간에 균형을 맞추는 것이 중요