기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 가용성에 대한 이해
가용성은 복원력을 정량적으로 측정할 수 있는 주요 방법 중 하나입니다. *A*로 표시하는 가용성은 워크로드를 사용할 수 있는 시간의 백분율로 정의합니다. 가용성은 측정되는 총 시간(예상 “가동 시간”과 예상 “가동 중지 시간”)에 대한 예상 “가동 시간"(사용 가능)의 비율입니다.
![\[방정식 그림 A = 가동 시간 / (가동 시간 + 가동 중지 시간)\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/availability-and-beyond-improving-resilience/images/availability.png)
이 공식을 더 잘 이해하기 위해 가동 시간과 가동 중지 시간을 측정하는 방법을 살펴보겠습니다. 먼저 워크로드가 고장 없이 얼마나 오래 지속되는지 알고 싶습니다. 이를 *평균 고장 간격(MTBF)*이라고 하며, 워크로드가 정상적으로 작동하기 시작한 시점과 다음 고장 시점 사이의 평균 시간을 의미합니다. 그런 다음 고장이 발생한 후 복구하는 데 시간이 얼마나 걸릴지 알고 싶습니다.
이를 *평균 수리(또는 복구) 시간*(MTTR)이라고 하며, 고장이 발생한 하위 시스템을 수리하거나 서비스 상태로 복원하는 동안 워크로드를 사용할 수 없는 기간을 MTTR(평균 복구 시간)이라고 합니다. MTTR에서 중요한 기간은 *평균 탐지 시간*(MTTD), 즉 고장 발생 시점과 수리 작업 시작 시점 사이의 시간입니다. 다음 다이어그램은 이러한 모든 지표가 어떻게 관련되어 있는지를 보여줍니다.
![\[MTTD, MTTR 및 MTBF 간의 관계를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/availability-and-beyond-improving-resilience/images/availability-metrics.png)
따라서 워크로드가 가동되는 시간인 MTBF와 워크로드가 중단된 시간인 MTTR을 사용하여 가용성 *A*를 표현할 수 있습니다.
![\[방정식 그림 A = MTBF / (MTBF + MTTR)\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation2.png)
그리고 워크로드가 “다운(사용할 수 없음)”될 확률은 고장 확률 *F*로 표시합니다.
![\[방정식 그림 F = 1 - A\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation3.png)
[신뢰성](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/reliability.html)이란 요청 시 지정된 응답 시간 내에 워크로드가 올바른 작업을 수행할 수 있는 능력을 말합니다. 이것이 가용성을 측정하는 척도입니다. 워크로드 고장 빈도를 줄이거나(MTBF 연장) 복구 시간이 짧을수록(MTTR 단축) 가용성이 향상됩니다.
**규칙 1**
고장 빈도 감소(MTBF 연장), 고장 감지 시간 단축(MTTD 단축), 수리 시간 단축(MTTR 단축)은 분산 시스템에서 가용성을 개선하는 데 사용되는 세 가지 요소입니다.
**Topics**
+ [분산 시스템 가용성](distributed-system-availability.md)
+ [종속성이 있는 가용성](availability-with-dependencies.md)
+ [중복성이 있는 가용성](availability-with-redundancy.md)
+ [CAP 정리](cap-theorem.md)
+ [내결함성 및 장애 격리](fault-tolerance-and-fault-isolation.md)
# 분산 시스템 가용성
분산 시스템은 소프트웨어 구성 요소와 하드웨어 구성 요소로 구성됩니다. 일부 소프트웨어 구성 요소는 그 자체가 또 다른 분산 시스템일 수 있습니다. 기본 하드웨어와 소프트웨어 구성 요소 모두의 가용성은 결과적으로 워크로드의 가용성에 영향을 미칩니다.
MTBF와 MTTR을 사용한 가용성 계산은 하드웨어 시스템에 그 뿌리를 두고 있습니다. 하지만 분산 시스템이 실패하는 이유는 하드웨어와는 매우 다릅니다. 제조업체가 하드웨어 구성 요소가 마모되기까지 걸리는 평균 시간을 일관되게 계산할 수 있는 경우 분산 시스템의 소프트웨어 구성 요소에는 동일한 테스트를 적용할 수 없습니다. 하드웨어는 일반적으로 고장률의 “욕조” 곡선을 따르는 반면, 소프트웨어는 새 릴리즈마다 발생하는 추가 결함으로 인해 생기는 엇갈린 곡선을 따릅니다([소프트웨어 신뢰성](https://users.ece.cmu.edu/~koopman/des_s99/sw_reliability) 참조).
![\[하드웨어 및 소프트웨어 고장률을 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/availability-and-beyond-improving-resilience/images/failure-rates.png)
또한 분산 시스템의 소프트웨어는 일반적으로 하드웨어보다 기하급수적으로 높은 속도로 변경됩니다. [예를 들어, 표준 마그네틱 하드 드라이브의 연간 평균 고장률(AFR)은 0.93%일 수 있으며, 이는 HDD의 실제 수명이 마모 기간에 도달하기까지 최소 3\$15년이 걸릴 수 있으며, 이는 더 길어질 수 있습니다(Backblaze 하드 드라이브 데이터 및 통계, 2020 참조).](https://www.backblaze.com/b2/hard-drive-test-data.html) 예를 들어 Amazon은 3\$15년 내에 소프트웨어 시스템에 4억 5천만\$17억 5천만 개 이상의 변경 사항을 배포할 수 있는 수명 기간 동안 하드 드라이브는 크게 변경되지 않습니다. ([Amazon Builders' Library: 안전한 수동 배포 자동화](https://aws.amazon.com/about-aws/whats-new/2020/06/new-abl-article-automating-safe-hands-off-deployments/)를 참조하세요.)
또한 하드웨어에는 계획된 노후화 개념이 적용됩니다. 즉, 수명이 내장되어 있으며 일정 기간이 지나면 교체해야 합니다. [(위대한 전구 음모 참조)](https://spectrum.ieee.org/tech-history/dawn-of-electronics/the-great-lightbulb-conspiracy) 이론적으로 소프트웨어는 이러한 제약의 적용을 받지 않으며, 마모 기간이 없으며 무기한으로 작동할 수 있습니다.
즉, 하드웨어에서 MTBF 및 MTTR 번호를 생성하는 데 사용하는 것과 동일한 테스트 및 예측 모델이 소프트웨어에는 적용되지 않습니다. 1970년대 이후 이 문제를 해결하기 위해 모델을 구축하려는 시도가 수백 번 있었지만, 모두 일반적으로 예측 모델링과 추정 모델링이라는 두 가지 범주로 나뉩니다. ([소프트웨어 신뢰성 모델 목록](https://en.wikipedia.org/wiki/List_of_software_reliability_models) 참조)
따라서 분산 시스템에 대한 미래 예측 MTBF 및 MTTR 계산, 따라서 미래 예측 가용성은 항상 특정 유형의 예측 또는 예보에서 도출됩니다. 예측 모델링, 확률적 시뮬레이션, 과거 분석 또는 엄격한 테스트를 통해 생성될 수 있지만 이러한 계산이 가동 시간이나 가동 중지 시간을 보장하지는 않습니다.
과거에 분산 시스템이 고장 났던 이유는 다시 발생하지 않을 수 있습니다. 미래에 고장 나는 이유는 다를 수 있으며 아마도 알 수 없을 것입니다. 향후 고장 발생 시 필요한 복구 메커니즘은 과거에 사용된 메커니즘과 다를 수 있으며 소요 시간도 크게 다를 수 있습니다.
또한 MTBF와 MTTR은 평균값입니다. 평균값과 실제 값 사이에 약간의 차이가 있을 수 있습니다(이 변동을 측정한 표준 편차 γ는 이 변동을 측정합니다). 따라서 실제 프로덕션 사용에서는 워크로드에 고장이 발생한 후 복구 시간이 걸리는 시간이 짧거나 길어질 수 있습니다.
그렇긴 하지만 분산 시스템을 구성하는 소프트웨어 구성 요소의 가용성은 여전히 중요합니다. 소프트웨어는 여러 가지 이유로 장애가 발생할 수 있으며(다음 항목에서 자세히 설명) 워크로드의 가용성에 영향을 미칠 수 있습니다. 따라서 가용성이 높은 분산 시스템의 경우 하드웨어 및 외부 소프트웨어 하위 시스템과 마찬가지로 소프트웨어 구성 요소의 가용성을 계산, 측정 및 개선하는 데 중점을 두어야 합니다.
**규칙 2**
워크로드의 소프트웨어 가용성은 워크로드의 전체 가용성을 결정하는 중요한 요소이므로 다른 구성 요소와 마찬가지로 중점을 두어야 합니다.
분산 시스템에서 MTBF와 MTTR은 예측하기 어렵지만 여전히 가용성 개선 방법에 대한 주요 통찰력을 제공한다는 점에 유의해야 합니다. 고장 빈도를 줄이면(MTBF가 높음), 고장 발생 후 복구 시간을 줄이면(MTTR이 낮아짐) 모두 경험적 가용성을 높일 수 있습니다.
## 분산 시스템의 고장 유형
분산 시스템에는 일반적으로 *보어버그*와 *하이젠버그*라는 애칭으로 불리는 두 종류의 버그가 있습니다([“브루스 린지와의 대화”, ACM Queue vol. 2, No. 8 - 2004년 11월](http://queue.acm.org/detail.cfm?id=1036486) 참조).
보어버그는 반복해서 작동하는 소프트웨어 문제입니다. 동일한 입력이 주어지면 버그는 일관되게 동일한 잘못된 출력을 생성합니다(예: 확실하고 쉽게 감지할 수 있는 결정론적 보어 원자 모델). 워크로드가 프로덕션에 들어갈 때쯤이면 이런 유형의 버그는 거의 발생하지 않습니다.
하이젠버그는 일시적인 버그입니다. 즉, 특정하고 흔하지 않은 상황에서만 발생합니다. 이러한 조건은 일반적으로 하드웨어(예: 일시적인 장치 장애 또는 레지스터 크기와 같은 하드웨어 구현 세부 사항), 컴파일러 최적화 및 언어 구현, 제한 조건(예: 일시적으로 스토리지 부족) 또는 경쟁 조건(예: 다중 스레드 작업에 세마포어를 사용하지 않음)와 관련이 있습니다.
하이젠버그는 프로덕션 환경에서 발생하는 버그의 대부분을 차지하며 관찰하거나 디버깅하려고 할 때 동작이 바뀌거나 사라지는 것처럼 보이기 때문에 찾기가 어렵습니다. 그러나 프로그램을 다시 시작하면 운영 환경이 약간 달라서 하이젠버그를 발생시킨 조건이 사라지기 때문에 고장 난 작업이 성공할 가능성이 높습니다.
따라서 대부분의 프로덕션 실패는 일시적이며 작업을 다시 시도해도 다시 고장 날 가능성은 거의 없습니다. 복원력을 갖추려면 분산 시스템이 하이젠버그에 대한 내결함성을 갖추어야 합니다. [분산 시스템 MTBF 늘리기 항목에서 이를 실현하는 방법을 살펴보겠습니다.](increasing-mtbf.md#increasing-mtbf.title)
# 종속성이 있는 가용성
이전 항목에서는 하드웨어, 소프트웨어 및 기타 분산 시스템이 모두 워크로드의 구성 요소라고 언급했습니다. 이러한 구성 요소를 *종속성*이라고 하며, 이러한 구성 요소는 워크로드가 기능을 제공하기 위해 의존하는 요소입니다. 여기에는 워크로드가 제대로 작동하지 않는 *하드* 종속성과 일정 기간 동안 가용성이 눈에 띄지 않거나 용인될 수 있는 *소프트* 종속성이 있습니다. 하드 종속성은 워크로드의 가용성에 직접적인 영향을 미칩니다.
워크로드의 이론상 최대 가용성을 계산해 보고 싶을 수도 있습니다. 이는 소프트웨어 자체를 포함한 모든 종속성(*α*n**는 단일 하위 시스템의 가용성)의 곱입니다. 각 종속성이 작동해야 하기 때문입니다.
![\[방정식 그림 A = α1 X α2 X... X αn아래 첨자>\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation4.png)
이러한 계산에 사용되는 가용성 수치는 일반적으로 SLA 또는 서비스 수준 목표(SLO)와 같은 항목과 연관됩니다. SLA는 고객이 받게 될 예상 서비스 수준, 서비스를 평가하는 기준, 서비스 수준을 달성하지 못할 경우 조치 또는 벌금(일반적으로 금전적)을 정의합니다.
위 공식을 사용하면 순전히 수학적으로 볼 때 워크로드는 종속 항목보다 가용성이 높을 수 없다는 결론을 내릴 수 있습니다. 하지만 현실에서는 일반적으로 그렇지 않다는 것을 알 수 있습니다. 99.99% 가용성 SLA와 함께 2\$13개의 종속성을 사용하여 구축된 워크로드는 여전히 자체적으로 99.99% 또는 그 이상의 가용성을 달성할 수 있습니다.
이것은 이전 항목에서 설명했듯이 이러한 가용성 수치는 추정치이기 때문입니다. 그것은 고장이 발생하는 빈도와 수리 속도를 추정하거나 예측합니다. 그렇다고 가동 중지를 보장하지는 않습니다. 종속성은 명시된 가용성 SLA 또는 SLO를 초과하는 경우가 많습니다.
또한 종속성은 공개 SLA에 제공된 수치보다 성능을 목표로 하는 내부 가용성 목표가 더 높을 수 있습니다. 이를 통해 미지 또는 불가지의 상황이 발생했을 때 SLA를 준수하는 데 따르는 위험을 일정 수준 완화할 수 있습니다.
마지막으로, 워크로드에는 SLA를 알 수 없거나 SLA 또는 SLO를 제공하지 않는 종속성이 있을 수 있습니다. 예를 들어 전 세계 인터넷 라우팅은 많은 워크로드의 공통적인 종속성이지만 글로벌 트래픽이 어떤 인터넷 서비스 공급자를 사용하고 있는지, SLA가 있는지, 공급업체 간에 얼마나 일관성이 있는지 파악하기가 어렵습니다.
이 모든 것이 시사하는 바는 이론상의 최대 가용성을 계산하는 것은 대략적인 규모만 계산할 수 있을 뿐 그 자체로는 정확하지 않거나 의미 있는 통찰력을 제공하지 못할 가능성이 높다는 것입니다. 계산을 통해 알 수 있는 것은 워크로드가 의존하는 대상이 적을수록 전반적인 실패 가능성이 줄어든다는 것입니다. 1보다 작은 수의 숫자를 적게 곱할수록 결과는 더 커집니다.
**규칙 3**
종속성을 줄이면 가용성에 긍정적인 영향을 미칠 수 있습니다.
수학은 종속성 선택 프로세스에 정보를 제공하는 데도 도움이 됩니다. 선택 프로세스는 워크로드를 설계하는 방법, 종속성의 중복성을 활용하여 가용성을 개선하는 방법, 이러한 종속성을 소프트 종속성으로 간주할지 하드 종속성으로 간주할지 여부에 영향을 줍니다. 워크로드에 영향을 미칠 수 있는 종속성은 신중하게 선택해야 합니다. 다음 규칙은 이 작업을 수행하는 방법에 대한 지침을 제공합니다.
**규칙 4**
일반적으로 가용성 목표가 워크로드 목표와 같거나 더 큰 종속성을 선택하세요.
# 중복성이 있는 가용성
워크로드가 여러 독립적이고 중복된 하위 시스템을 사용하는 경우 단일 하위 시스템을 사용하는 경우보다 이론적으로 더 높은 수준의 가용성을 달성할 수 있습니다. 예를 들어 두 개의 동일한 하위 시스템으로 구성된 워크로드를 고려하세요. 하위 시스템 1이나 하위 시스템 2가 작동 중이면 완전히 작동할 수 있습니다. 전체 시스템이 다운되려면 두 하위 시스템이 동시에 다운되어야 합니다.
*한 하위 시스템의 고장 확률이 1 - *α*인 경우 두 개의 중복 하위 시스템이 동시에 다운될 확률은 각 하위 시스템의 고장 확률의 곱, *F* = (1−*α*1) × (1− α*2)입니다. 두 개의 중복 하위 시스템이 있는 워크로드의 경우 방정식 *(3)*을 사용하면 다음과 같이 정의된 가용성이 제공됩니다.
![\[세 가지 방정식 그림\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation5.png)
따라서 가용성이 99%인 두 하위 시스템의 경우 한 하위 시스템에 고장이 발생할 확률은 1%이고 둘 다 고장 날 확률은 (1-99%) × (1-99%) = 0.01%입니다. 따라서 두 개의 중복 하위 시스템을 사용할 경우 가용성이 99.99% 향상됩니다.
이를 일반화하여 추가 중복 스페어, *s**,*도 통합할 수 있습니다. 수식 *(5)*에서는 스페어를 하나만 가정했지만, 워크로드에는 스페어가 2개, 3개 또는 그 이상 있을 수 있으므로 여러 하위 시스템이 동시에 손실되어도 가용성에 영향을 주지 않고 버틸 수 있습니다. 워크로드에 세 개의 하위 시스템이 있고 두 개가 스페어 시스템인 경우 세 개의 하위 시스템이 모두 동시에 실패할 확률은 (1−*α*) × (1−*α*) × (1−*α*) or (1−*α*)3입니다. 일반적으로 *s*개의 스페어가 있는 워크로드는 *s* \$1 1개의 하위 시스템에 고장이 발생하는 경우에만 고장 납니다.
*n*개의 하위 시스템과 *s*개의 스페어가 있는 워크로드의 경우 *f*는 고장 모드의 수 또는 *s* \$1 1개의 하위 시스템이 *n*개 중 고장을 일으킬 수 있는 방법을 나타냅니다.
이것은 사실상 이항 정리로, *n*개의 집합에서 *k*개의 요소를 선택하거나 *“**n*은 *k*를 *선택한다**”*는 조합 수학입니다. 이 경우 *k*는 *s* \$1 1입니다.
![\[네 개의 방정식 그림\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation6.png)
그런 다음 고장 모드와 스페어링 수를 포함하는 일반화된 가용성 근사치를 산출할 수 있습니다. (근사치로 이러한 이유를 이해하려면 Highleyman 등의 부록 2를 참조하세요. [가용성 장벽을 허물다](https://www.amazon.com/Breaking-Availability-Barrier-Survivable-Enterprise/dp/1410792331).)
![\[네 개의 방정식 그림\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation7.png)
스페어링은 독립적으로 고장이 발생하는 리소스를 제공하는 모든 종속성에 적용할 수 있습니다. 그 예로는 여러 AZ에 있는 Amazon EC2 인스턴스, 다른 AWS 리전에 있는 Amazon S3 버킷이 포함됩니다. 스페어를 사용하면 종속 항목이 총 가용성을 높여 워크로드의 가용성 목표를 지원하는 데 도움이 됩니다.
**규칙 5**
스페어링을 사용하여 워크로드의 종속성 가용성을 높이세요.
하지만 스페어링에는 대가가 따릅니다. 예비 부품을 추가할 때마다 원래 모듈과 비용이 동일하므로 비용이 최소한 선형적으로 늘어납니다. 스페어를 사용할 수 있는 워크로드를 구축하면 복잡성도 증가합니다. 종속성 고장을 식별하고, 적절한 리소스로 작업량을 줄이고, 워크로드의 전체 용량을 관리하는 방법을 알아야 합니다.
중복성은 최적화 문제입니다. 스페어가 너무 적으면 워크로드가 원하는 것보다 더 자주 고장 나고, 스페어가 너무 많으면 워크로드 실행 비용이 너무 많이 들 수 있습니다. 스페어를 더 추가할 경우 보증된 추가 가용성보다 비용이 더 많이 드는 임계값이 있습니다.
스페어 사용 일반 가용성 공식인 수식 *(7)* 을 사용하면 가용성이 99.5% 이고 스페어가 두 개 있는 서브시스템의 경우 워크로드 가용성은 *A* ≈ 1 − (1)(1−.995)3 = 99.9999875%(연간 약 3.94초의 가동 중지)고, 스페어 10개를 사용할 경우 *A* ≈ 1 − (1)(1−.995)11 = 25.5 9′*s*가 됩니다(대략적인 가동 중지는 연간 1.26252 × 10-15*m**s*이며, 사실상 0입니다). 이 두 워크로드를 비교한 결과 스페어링 비용이 5배 증가하여 연간 가동 중지를 4초 줄였습니다. 대부분의 워크로드에서 이러한 비용 증가는 가용성 증가에 비해 부당합니다. 다음 그림은 이 관계를 보여줍니다.
![\[스페어링 증가로 인한 수익 감소를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/availability-and-beyond-improving-resilience/images/effect-of-sparing.png)
예비 부품이 3개 이상이면 연간 예상 가동 중지 시간의 1분의 1분의 1에 불과합니다. 즉, 이 시점 이후에는 수익이 감소하는 영역에 도달하게 됩니다. 더 높은 수준의 가용성을 달성하기 위해 “그냥 추가하고 싶다”는 충동이 들 수도 있지만 실제로는 비용상의 이점이 매우 빠르게 사라집니다. 예비 부품을 3개 이상 사용한다고 해서 실질적인 효과를 얻을 수 있는 것은 아닙니다. 하위 시스템 자체의 가용성이 99% 이상이면 거의 모든 워크로드에서 눈에 띄는 이득을 얻을 수 있습니다.
**규칙 6**
스페어링의 비용 효율성에는 상한선이 있습니다. 필요한 가용성을 달성하는 데 필요한 최소한의 스페어를 활용하세요.
올바른 스페어 수를 선택할 때는 고장 단위를 고려해야 합니다. 예를 들어, 최대 용량을 처리하기 위해 EC2 인스턴스 10개가 필요하고 단일 AZ에 배포된 워크로드를 살펴보겠습니다.
AZ는 고장 격리 경계를 설정하도록 설계되었으므로 단일 EC2 인스턴스에만 고장이 발생하는 것은 아닙니다. AZ 전체에 해당하는 EC2 인스턴스가 함께 고장이 발생할 수 있기 때문입니다. 이 경우 [다른 AZ와 중복성을 추가하여 AZ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html) 고장 발생 시 부하를 처리할 EC2 인스턴스 10개를 추가로 배포하여 총 20개의 EC2 인스턴스(정적 안정성 패턴 적용)를 구축하는 것이 좋습니다.
이는 10개의 예비 EC2 인스턴스인 것처럼 보이지만 실제로는 단일 스페어 AZ에 불과하므로 수익이 감소하는 지점을 넘지 않았습니다. 하지만 AZ를 3개 활용하고 AZ당 EC2 인스턴스 5개를 배포하면 가용성을 높이는 동시에 비용 효율성을 높일 수 있습니다.
이렇게 하면 1개의 스페어 AZ에 총 15개의 EC2 인스턴스가 제공되지만(20개의 인스턴스가 있는 두 개의 AZ에 비해), 단일 AZ에 영향을 미치는 이벤트 발생 시 최대 용량을 제공하는 데 필요한 총 10개의 인스턴스가 계속 제공됩니다. 따라서 워크로드가 사용하는 모든 장애 격리 경계(인스턴스, 셀, AZ, 지역)에서 내결함성을 갖추도록 스페어링을 구축해야 합니다.
# CAP 정리
가용성에 대해 생각할 수 있는 또 다른 방법은 CAP 정리를 이용하는 것입니다. 이론에 따르면 데이터를 저장하는 여러 노드로 구성된 분산 시스템은 다음 세 가지 보장 중 두 가지까지만 동시에 제공할 있습니다.
+ 일관성, **C**: 모든 읽기 요청은 가장 최근의 쓰기 요청을 수신하거나 일관성을 보장할 수 없는 경우 오류가 발생합니다.
+ 가용성, **A**: 모든 요청은 노드가 다운되거나 사용할 수 없는 경우에도 오류 없는 응답을 받습니다.
+ 파티션 내성, **P**: 노드 간에 임의의 수의 메시지가 손실되더라도 시스템은 계속 작동합니다.
(자세한 내용은 Seth Gilbert와 Nancy Lynch, [http://dl.acm.org/citation.cfm?id=564601&CFID=609557487&CFTOKEN=15997970](http://dl.acm.org/citation.cfm?id=564601&CFID=609557487&CFTOKEN=15997970), *ACM SIGACT 뉴스*, 33권 2호(2002), 51\$159페이지를 참조하세요.)
대부분의 분산 시스템은 네트워크 고장을 견뎌야 하므로 네트워크 파티셔닝이 허용되어야 합니다. 즉, 네트워크 파티션이 발생할 경우 이러한 워크로드는 일관성과 가용성 중 하나를 선택해야 합니다. 워크로드가 가용성을 선택하면 항상 응답을 반환하지만 데이터가 일치하지 않을 수 있습니다. 일관성을 선택하면 워크로드가 데이터의 일관성을 확신할 수 없으므로 네트워크 파티션 중에 오류가 반환됩니다.
더 높은 수준의 가용성을 제공하는 것이 목표인 워크로드의 경우 네트워크 파티션 중에 오류(사용할 수 없음)가 반환되는 것을 방지하기 위해 가용성 및 파티션 내성(AP)을 선택할 수 있습니다. 따라서 최종 일관성 또는 단조로운 일관성과 같은 더욱 완화된 [정합성 모델](https://en.wikipedia.org/wiki/Consistency_model)이 필요합니다.
# 내결함성 및 장애 격리
이 두 가지 개념은 가용성을 고려할 때 아주 중요합니다. 내결함성이란 하위 [시스템 고장을 견디고](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-withstand-component-failures.html) 가용성을 유지하는 능력(설정된 SLA 내에서 올바른 작업 수행)을 말합니다. 내결함성을 구현하기 위해 워크로드는 스페어(또는 중복) 하위 시스템을 사용합니다. 중복 세트의 하위 시스템 중 하나에 고장이 발생하면 일반적으로 거의 원활하게 다른 하위 시스템이 작업을 시작합니다. 이 경우 스페어는 진정한 스페어 용량이므로 고장이 발생한 하위 시스템의 작업을 100% 떠맡을 수 있습니다. 진정한 스페어가 있으면 여러 개의 하위 시스템 고장이 발생해야만 워크로드에 부정적인 영향이 미칩니다.
고장 격리는 고장 발생 시 영향 범위를 최소화합니다. 이는 일반적으로 모듈화를 통해 구현됩니다. 워크로드는 고장이 한꺼번에 발생하지 않고, 따라서 개별적으로 복구할 수 있는 작은 하위 시스템들로 나누어집니다. 모듈의 고장은 [모듈 외부로 전파되지 않습니다](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-interactions-in-a-distributed-system-to-mitigate-or-withstand-failures.html). 이 아이디어는 수직적으로는 워크로드의 다양한 기능에 걸쳐 적용되고 수평적으로는 동일한 기능을 제공하는 여러 하위 시스템에 걸쳐 적용됩니다. 이러한 모듈은 이벤트 중에 미치는 영향 범위를 제한하는 장애 컨테이너 역할을 합니다.
컨트롤 플레인, 데이터 영역 및 정적 안정성의 아키텍처 패턴은 내결함성 및 장애 격리 구현을 직접적으로 지원합니다. Amazon Builders' Library 문서 [가용 영역을 사용한 정적 안정성](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)에서는 이러한 용어에 대한 올바른 정의와 복원력 있고 가용성이 높은 워크로드를 구축하는 데 적용하는 방법을 제공합니다. 이 백서에서는 [AWS에서 고가용성 분산 시스템 설계](designing-highly-available-distributed-systems-on-aws.md#designing-highly-available-distributed-systems-on-aws.title) 항목에서 이러한 패턴을 사용하며 여기에 해당 정의도 요약되어 있습니다.
+ **컨트롤 플레인**: 리소스 추가, 리소스 삭제, 리소스 수정, 해당 변경 사항을 필요한 곳으로 전파하는 등 변경과 관련된 워크로드의 일부입니다. 컨트롤 플레인은 일반적으로 데이터 영역보다 더 복잡하고 움직이는 부분이 많기 때문에 통계적으로 실패 가능성이 더 높고 가용성이 낮습니다.
+ **데이터 영역**: 일상적인 비즈니스 기능을 제공하는 워크로드의 일부입니다. 데이터 영역은 컨트롤 플레인보다 단순하고 대량으로 작동하는 경향이 있어 가용성이 높아집니다.
+ **정적 안정성**: 종속성 손상에도 불구하고 워크로드가 올바른 작동을 계속할 수 있는 능력입니다. 구현 방법 중 하나는 데이터 영역에서 컨트롤 플레인 종속성을 제거하는 것입니다. 또 다른 방법은 워크로드 종속성을 느슨하게 결합하는 것입니다. 종속 항목이 전달해야 하는 업데이트된 정보(예: 새 항목, 삭제된 항목, 수정된 항목)가 워크로드에 표시되지 않을 수 있습니다. 하지만 종속성이 손상되기 전에 수행했던 모든 작업은 계속 작동합니다.
워크로드 장애를 생각할 때 복구를 위해 고려할 수 있는 두 가지 상위 수준의 접근 방식이 있습니다. 첫 번째 방법은 장애가 발생한 후 이에 대응하는 것입니다. AWS Auto Scaling로 새 용량을 추가하는 방법이 있겠지요. 두 번째 방법은 이러한 장애가 발생하기 전에 이에 대비하는 것입니다. 예를 들어 워크로드의 인프라를 오버프로비저닝하여 추가 리소스 없이도 올바르게 운영될 수 있도록 하는 것입니다.
정적으로 안정적인 시스템은 후자의 접근 방식을 사용합니다. 고장 발생 시 사용할 수 있도록 예비 용량을 미리 프로비저닝합니다. 이 방법을 사용하면 고장 복구를 위한 새 용량을 프로비저닝하기 위해 워크로드의 복구 경로에 컨트롤 플레인에 종속성을 생성하지 않아도 됩니다. 또한 다양한 리소스에 새 용량을 프로비저닝하려면 시간이 걸립니다. 새 용량을 기다리는 동안 기존 수요로 인해 워크로드에 과부하가 걸리고 추가 성능 저하가 발생하여 가용성이 완전히 손실될 수 있습니다. 하지만 사전 프로비저닝된 용량을 가용성 목표에 맞게 활용할 경우 비용에 미치는 영향도 고려해야 합니다.
정적 안정성은 고가용성 워크로드에 대한 다음 두 가지 규칙을 제공합니다.
**규칙 7**
특히 복구 중에는 데이터 영역의 컨트롤 플레인에 대한 종속성을 고려하지 마세요.
**규칙 8**
가능한 경우 종속성이 손상되더라도 워크로드가 올바르게 작동할 수 있도록 종속성을 느슨하게 결합하세요.