기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 다중 AZ 관찰성
단일 가용 영역으로 격리된 이벤트 중에 가용 영역을 제거할 수 있으려면 먼저 장애가 실제로 단일 가용 영역에 격리되어 있음을 감지할 수 있어야 합니다. 이를 위해서는 각 가용 영역에서 시스템이 어떻게 작동하는지 정확하게 파악할 수 있어야 합니다. 많은 AWS 서비스가 리소스에 대한 운영 통찰력을 제공하는 out-of-the-box 지표를 제공합니다. 예를 들어 EC2 Amazon은 CPU 사용률, 디스크 읽기 및 쓰기, 들어오고 나가는 네트워크 트래픽과 같은 다양한 지표를 제공합니다.
하지만 이러한 서비스를 사용하는 워크로드를 구축할 때는 표준 지표보다 더 많은 가시성이 필요합니다. 워크로드가 제공하는 고객 경험에 대한 가시성이 필요합니다. 또한 지표가 생성되는 가용 영역에 맞게 지표를 조정해야 합니다. 이는 차등적으로 관찰 가능한 회색 장애를 탐지하는 데 필요한 통찰력입니다. 이러한 수준의 가시성을 확보하려면 계측이 필요합니다.
계측을 사용하려면 명시적 코드를 작성해야 합니다. 이 코드는 작업에 걸리는 시간 기록, 성공 또는 실패한 항목 수 계산, 요청에 대한 메타데이터 수집 등과 같은 작업을 수행해야 합니다. 또한 임계값을 미리 정의하여 정상으로 간주되는 항목과 그렇지 않은 항목을 정의해야 합니다. 워크로드의 지연 시간, 가용성, 오류 수에 대한 목표와 다양한 심각도 임계값을 간략하게 설명해야 합니다. Amazon Builders' Library 문서 [운영 가시성을 위한 분산 시스템 계측](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/)에 여러 모범 사례가 나와 있습니다.
지표는 서버 측과 클라이언트 측 모두에서 생성되어야 합니다. 클라이언트측 지표를 생성하고 고객 경험을 이해하기 위한 모범 사례는 정기적으로 워크로드를 조사하고 지표를 기록하는 소프트웨어인 [canary](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)를 사용하는 것입니다.
이러한 지표를 생성하는 것 외에도 해당 지표의 컨텍스트를 이해해야 합니다. 이를 수행하는 한 가지 방법은 [차원](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Dimension)을 사용하는 것입니다. 차원은 지표에 고유한 정체성을 부여하고 지표가 의미하는 바를 설명하는 데 도움이 됩니다. 워크로드의 장애를 식별하는 데 사용되는 지표(예: 지연 시간, 가용성 또는 오류 수)의 경우 [장애 격리 경계](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html)에 맞는 차원을 사용해야 합니다.
예를 들어, [M odel-view-controller](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller) (MVC) 웹 프레임워크를 사용하여 여러 가용 영역에 걸쳐 한 지역에서 웹 서비스를 실행하는 경우`Region`, [https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html)`Controller``Action`, 및 `InstanceId` 를 차원 집합의 차원으로 사용해야 합니다 (마이크로서비스를 사용하는 경우 컨트롤러 및 작업 이름 대신 서비스 이름과 HTTP 메서드를 사용할 수 있음). 이는 이러한 한계로 인해 여러 유형의 장애가 격리될 것으로 예상되기 때문입니다. 제품을 나열하는 기능에 영향을 미치는 웹 서비스 코드의 버그가 홈 페이지에도 영향을 미칠 것으로 예상하지 못할 것입니다. 마찬가지로 단일 EC2 인스턴스의 전체 EBS 볼륨이 웹 콘텐츠를 제공하는 다른 EC2 인스턴스에 영향을 미칠 것으로 예상하지는 않습니다. 가용 영역 ID 차원을 사용하면 가용 영역 관련 영향을 AWS 계정전반에 걸쳐 일관되게 식별할 수 있습니다. 다양한 방법으로 워크로드 내에서 가용 영역 ID를 찾을 수 있습니다. 몇 가지 예는 [부록 A — 가용 영역 ID 가져오기](appendix-a-getting-the-availability-zone-id.md)을 참조합니다.
이 문서에서는 주로 Amazon을 컴퓨팅 리소스로 사용하지만 차원의 구성 요소인 Amazon EC2 Elastic Container [Service (AmazonECS) 및 Amazon [Elastic Kubernetes Service (EKSAmazon](https://aws.amazon.com/eks/)) 컴퓨팅 리소스의 경우 컨테이너](https://aws.amazon.com/ecs/) ID로 대체할 `InstanceId` 수 있습니다.
워크로드에 영역 엔드포인트가 있는 경우 canary는 `Controller`, `Action`, `AZ-ID` 및 `Region`를 지표의 차원으로 사용할 수도 있습니다. 이 경우 테스트 중인 가용 영역에서 실행되도록 canary를 조정합니다. 이렇게 하면 격리된 가용 영역 이벤트에서 canary가 실행 중인 가용 영역에 영향을 미치는 경우 테스트 중인 다른 가용 영역을 비정상으로 표시하는 지표를 기록하지 않습니다. [예를 들어, 카나리아는 영역 이름을 사용하여 Network Load Balancer () 또는 Application Load Balancer NLB () 뒤에 있는 서비스의 각 영역 엔드포인트를 테스트할 수 있습니다. ALB DNS](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancers.html#dns-name)
![\[CloudWatch Synthetics에서 실행되는 카나리아 또는 각 영역 끝점을 AWS Lambda 테스트하는 함수를 보여주는 다이어그램 NLB\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/advanced-multi-az-resilience-patterns/images/canary-testing-for-zonal-impact.png)
이러한 측정기준을 사용하여 측정치를 생성하면 해당 범위 내에서 가용성이나 지연 시간이 변경될 때 알려주는 [Amazon CloudWatch 경보를](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) 설정할 수 있습니다. 또한 [대시보드](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)를 사용하여 해당 데이터를 빠르게 분석할 수 있습니다. 지표와 로그를 모두 효율적으로 사용하기 위해 CloudWatch Amazon은 사용자 지정 지표를 로그 데이터에 [내장할 수 있는 내장된 지표 형식](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format.html) (EMF) 을 제공합니다. CloudWatch사용자 지정 지표를 자동으로 추출하므로 이를 시각화하고 이에 대한 경보를 확인할 수 있습니다. AWS 는 쉽게 시작할 수 있도록 다양한 프로그래밍 언어를 위한 여러 [클라이언트 라이브러리를](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Libraries.html) 제공합니다. EMF AmazonEC2, Amazon ECS EKS [AWS Lambda](https://aws.amazon.com/lambda/), Amazon 및 온프레미스 환경에서 사용할 수 있습니다. 지표가 로그에 내장되어 있으면 [Amazon CloudWatch Contributor Insights를 사용하여 기여자](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html) 데이터를 표시하는 시계열 그래프를 생성할 수도 있습니다. 이 시나리오에서는 `AZ-ID`,`InstanceId` 또는 `Controller`와 같은 차원별로 그룹화된 데이터를 표시할 수 있을 뿐만 아니라 `SuccessLatency`나 `HttpResponseCode`와 같은 로그 내 다른 필드도 표시할 수 있습니다.
```
{
"_aws": {
"Timestamp": 1634319245221,
"CloudWatchMetrics": [
{
"Namespace": "workloadname/frontend",
"Metrics": [
{ "Name": "2xx", "Unit": "Count" },
{ "Name": "3xx", "Unit": "Count" },
{ "Name": "4xx", "Unit": "Count" },
{ "Name": "5xx", "Unit": "Count" },
{ "Name": "SuccessLatency", "Unit": "Milliseconds" }
],
"Dimensions": [
[ "Controller", "Action", "Region", "AZ-ID", "InstanceId"],
[ "Controller", "Action", "Region", "AZ-ID"],
[ "Controller", "Action", "Region"]
]
}
],
"LogGroupName": "/loggroupname"
},
"CacheRefresh": false,
"Host": "use1-az2-name.example.com",
"SourceIp": "34.230.82.196",
"TraceId": "|e3628548-42e164ee4d1379bf.",
"Path": "/home",
"OneBox": false,
"Controller": "Home",
"Action": "Index",
"Region": "us-east-1",
"AZ-ID": "use1-az2",
"InstanceId": "i-01ab0b7241214d494",
"LogGroupName": "/loggroupname",
"HttpResponseCode": 200,
"2xx": 1,
"3xx": 0,
"4xx": 0,
"5xx": 0,
"SuccessLatency": 20
}
```
이러한 로그 내에 세 가지 차원 세트가 있습니다. 인스턴스부터 가용 영역, 리전에 이르기까지 세분화된 순서대로 진행됩니다 (`Controller` 및 `Action`은 예제에 항상 포함됨). 단일 인스턴스, 단일 가용 영역 또는 전체 AWS 리전내에서 특정 컨트롤러 작업에 영향이 있을 때를 나타내는 경보를 워크로드 전반에 생성할 수 있도록 지원합니다. 이러한 측정기준은 2xx, 3xx, 4xx, 5xx HTTP 응답 지표의 개수와 성공적인 요청 지표의 지연 시간에 사용됩니다 (요청이 실패하면 실패한 요청 지연 시간에 대한 지표도 기록됨). 로그에는 HTTP 경로, 요청자의 소스 IP, 이 요청에 로컬 캐시를 새로 고쳐야 하는지 여부와 같은 기타 정보도 기록됩니다. 그런 다음 이러한 데이터 포인트를 사용하여 워크로드가 제공하는 각 가용성과 지연 시간을 계산할 수 있습니다API.
**가용성 지표의 HTTP 응답 코드 사용에 대한 참고 사항**
일반적으로 2xx 및 3xx 응답은 성공한 것으로 간주하고 5xx 응답은 실패로 간주할 수 있습니다. 4xx 응답 코드는 중간에 위치합니다. 일반적으로 클라이언트 오류로 인해 생성됩니다. 매개변수가 범위를 벗어나서 [400 응답](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes)이 발생하거나, 존재하지 않는 것을 요청하여 404 응답이 발생할 수 있습니다. 이러한 응답을 워크로드의 가용성에 포함시키지는 않을 것입니다. 하지만 이는 소프트웨어 버그의 결과일 수도 있습니다.
예를 들어 이전에 성공했을 요청을 거부하는 보다 엄격한 입력 검증을 도입한 경우 400 응답은 가용성 저하로 간주될 수 있습니다. 아니면 고객을 제한 및 429 응답을 반환하는 것일 수도 있습니다. 고객이 서비스의 가용성을 유지하기 위해 서비스 제한을 하는 동안, 고객의 관점에서 서비스는 고객의 요청을 처리할 수 없습니다. 4xx 응답 코드를 가용성 계산에 포함할지 여부를 결정해야 합니다.
이 섹션에서는 지표를 수집 및 분석하는 CloudWatch 방법으로 사용하는 방법을 개괄적으로 설명했지만 사용할 수 있는 유일한 솔루션은 아닙니다. 또한 지표를 Amazon Managed Service for Prometheus 및 Amazon Managed Grafana, Amazon DynamoDB 테이블로 보내거나 타사 모니터링 솔루션을 사용하도록 선택할 수도 있습니다. 핵심은 워크로드가 생성하는 지표에 워크로드의 장애 격리 경계에 대한 컨텍스트를 포함해야 한다는 것입니다.
장애 격리 경계에 맞게 차원이 정렬된 메트릭을 생성하는 워크로드를 사용하면 가용 영역 격리 장애를 탐지하는 관찰성을 만들 수 있습니다. 다음 섹션에서는 단일 가용 영역의 손상으로 인해 발생하는 장애를 탐지하기 위한 세 가지 보완적인 접근 방식을 설명합니다.
**Topics**
+ [CloudWatch 복합 경보를 통한 장애 감지](failure-detection-with-cloudwatch-composite-alarms.md)
+ [이상치 감지를 사용한 장애 감지](failure-detection-using-outlier-detection.md)
+ [단일 인스턴스 영역 리소스의 장애 감지](failure-detection-of-single-instance-zonal-resources.md)
+ [요약](summary.md)
# CloudWatch 복합 경보를 통한 장애 감지
CloudWatch 지표에서 각 차원 집합은 고유한 지표이므로 각 측정기준에 대해 CloudWatch 경보를 생성할 수 있습니다. 그런 다음 [Amazon CloudWatch 복합 경보를](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html) 생성하여 이러한 지표를 집계할 수 있습니다.
영향을 정확하게 감지하기 위해 이 백서의 예시에서는 알람이 적용되는 각 차원 설정에 대해 서로 다른 두 가지 CloudWatch 알람 구조를 사용합니다. 각 경보는 1분의 **기간**을 사용합니다. 즉, 지표는 분당 한 번 평가됩니다. 첫 번째 접근 방식은 **평가 기간** 및 **경고할 데이터 포인트**를 설정하여 총 3분 동안 영향을 미치는 세 개의 연속 침해 데이터 포인트를 사용하는 것입니다. 두 번째 접근 방식은 5분 동안 데이터 요소 3개가 위반되는 경우 ‘M out of N’을 사용하여 **평가 기간**을 5로 설정하고 **경고할 데이터 포인트**를 3으로 설정하는 것입니다. 이를 통해 일정한 신호는 물론 짧은 시간 동안 변동하는 신호도 감지할 수 있습니다. 여기에 포함된 기간 및 데이터 포인트 수는 권장 사항이며 워크로드에 적합한 값을 사용하십시오.
## 단일 가용 영역에서 영향 감지
이 구성을 사용할 때, `Controller`, `Action`, `InstanceId`, `AZ-ID` 및 `Region`을 차원으로 사용하는 워크로드를 고려합니다. 워크로드는 Products와 Home이라는 두 개의 컨트롤러와 컨트롤러당 하나의 작업, 즉 List와 Index를 포함합니다. `us-east-1` 리전 내 세 가용 영역에서 운영됩니다. 각 가용 영역의 가용성 `Controller` 및 `Action` 조합에 대한 두 개의 경보와 각 가용 영역의 지연 시간에 대한 두 개의 경보를 생성해야 합니다. 그런 다음 각 `Controller` 조합과 `Action` 조합의 가용성에 대한 복합 경보를 생성하도록 선택할 수도 있습니다. 마지막으로 가용 영역에 대한 모든 가용성 경보를 집계하는 복합 경보를 생성합니다. 다은 그림은 각 `Controller` 및 `Action` 조합에 대해 선택적 복합 경보를 사용하여 단일 가용 영역, `use1-az1`을 보여줍니다(`use1-az2` 및 `use1-az3` 가용 영역에도 유사한 경보가 존재하지만 단순화를 위해 표시하지 않음).
![\[use1-az1 내 가용성에 대한 복합 경보 구조를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-availability.png)
다음 그림과 같이 지연 시간에 대해서도 유사한 경보 구조를 구축할 수 있습니다.
![\[use1-az1 내 지연 시간에 대한 복합 경보 구조를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-latency.png)
이 섹션의 나머지 그림에서는 최상위 레벨에 `az1-availability` 및 `az1-latency` 복합 경보만 표시됩니다. 이러한 복합 경보 `az1-availability` 및 `az1-latency`는 워크로드의 특정 부분에 대해 특정 가용 영역에서 가용성이 정의된 임계값 이하로 떨어지거나 지연 시간이 증가하는지 알려줍니다. 단일 가용 영역의 워크로드가 작업을 받지 못하게 하는 영향을 감지하기 위해 처리량 측정을 고려할 수도 있습니다. canary로 내보낸 지표에서 생성된 경보를 이러한 복합 경보에 통합할 수도 있습니다. 이렇게 하여 서버 측 또는 클라이언트 측에서 가용성이나 지연 시간에 미치는 영향을 확인하면 경보가 알림을 생성합니다.
## 영향의 지역적 여부 확인
또 다른 복합 경보 세트를 사용하여 격리된 가용 영역 이벤트만 경보가 활성화되도록 할 수 있습니다. 이는 다른 가용 영역에 대한 복합 경보가 `ALARM` 상태에 있는 동안 가용 영역 복합 경보가 `OK` 상태에 있는지 확인하여 수행됩니다. 그러면 사용하는 가용 영역당 하나의 복합 경보가 생성됩니다. 다음 그림에 예가 나와 있습니다 (`use1-az2` 및 `use1-az3`, `az2-latency`, `az2-availability`, `az3-latency` 및 `az3-availability`에는 단순화를 위해 그림으로 표시되지 않은 지연 시간 및 가용성에 대한 경보가 있다는 점을 기억하십시오).
![\[단일 AZ에만 국한된 영향을 탐지하기 위한 복합 경보 구조를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-impact.png)
## 단일 인스턴스로 인한 영향이 아닌지 확인
단일 인스턴스(또는 전체 플릿의 작은 비율)는 가용성 및 지연 시간 지표에 불균형적인 영향을 미칠 수 있으며, 이로 인해 전체 가용 영역이 영향을 받는 것처럼 보이지만 실제로는 그렇지 않을 수 있습니다. 문제가 되는 단일 인스턴스를 제거하는 것이 가용 영역을 제거하는 것보다 더 빠르고 효과적입니다.
인스턴스와 컨테이너는 일반적으로 임시 리소스로 취급되며, [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)와 같은 서비스로 대체되는 경우가 많습니다. 새 인스턴스가 생성될 때마다 새 CloudWatch 경보를 생성하는 것은 어렵습니다 (하지만 [Amazon EventBridge 또는 Amazon EC2](https://docs.aws.amazon.com/autoscaling/ec2/userguide/cloud-watch-events.html) [Auto Scaling 수명 주기 후크를](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) 사용하면 확실히 가능합니다). 대신 [CloudWatch Contributor Insights를](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html) 사용하여 가용성 및 지연 시간 지표에 기여한 사람의 수를 파악할 수 있습니다.
예를 들어 HTTP 웹 애플리케이션의 경우 각 가용 영역에서 5xx HTTP 응답의 상위 기여자를 식별하는 규칙을 만들 수 있습니다. 이를 통해 어떤 인스턴스가 가용성 저하의 원인인지 식별할 수 있습니다 (위에서 정의한 가용성 지표는 5xx 오류의 존재 여부에 따라 결정됨). EMF로그 예제를 사용하여 의 키를 사용하여 규칙을 생성합니다. `InstanceId` 그런 다음 `HttpResponseCode` 필드를 기준으로 로그를 필터링합니다. 이 예는 `use1-az1` 가용 영역에 대한 규칙입니다.
```
{
"AggregateOn": "Count",
"Contribution": {
"Filters": [
{
"Match": "$.InstanceId",
"IsPresent": true
},
{
"Match": "$.HttpStatusCode",
"IsPresent": true
},
{
"Match": "$.HttpStatusCode",
"GreaterThan": 499
},
{
"Match": "$.HttpStatusCode",
"LessThan": 600
},
{
"Match": "$.AZ-ID",
"In": ["use1-az1"]
},
],
"Keys": [
"$.InstanceId"
]
},
"LogFormat": "JSON",
"LogGroupNames": [
"/loggroupname"
],
"Schema": {
"Name": "CloudWatchLogRule",
"Version": 1
}
}
```
CloudWatch 이러한 규칙을 기반으로 경보를 생성할 수도 있습니다. [지표 수학](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) 및 `UniqueContributors` 지표가 포함된 `INSIGHT_RULE_METRIC` 함수를 사용하여 Contributor Insights 규칙을 기반으로 경보를 생성할 수 있습니다. 가용성에 대한 규칙 외에도 지연 시간이나 오류 수와 같은 지표에 대한 CloudWatch 경보를 포함하는 추가 Contributor Insights 규칙을 만들 수도 있습니다. 이러한 경보를 격리된 가용 영역 영향 복합 경보와 함께 사용하여 단일 인스턴스가 경보를 활성화하지 않도록 할 수 있습니다. `use1-az1`에 대한 인사이트 규칙 지표는 다음과 같을 수 있습니다.
```
INSIGHT_RULE_METRIC("5xx-errors-use1-az1", "UniqueContributors")
```
이 지표가 임계값(이 예시에서는 2) 보다 클 때 경보를 정의할 수 있습니다. 5xx 응답의 고유 기여자가 해당 임계값을 초과할 때 활성화되며, 이는 두 개 이상의 인스턴스 내에서 영향이 발생하고 있음을 나타냅니다. 이 경보가 비교보다 작은 값보다 큰 값을 사용하는 이유는 고유 기여자의 값이 0이라고 해서 경보가 발생하지 않도록 하기 위함입니다. 이는 단일 인스턴스가 미치는 영향이 *아님*을 나타냅니다. 개별 워크로드에 맞게 이 임계값을 조정합니다. 일반적인 지침은 이 숫자를 가용 영역 전체 리소스의 5% 이상으로 만드는 것입니다. 영향을 받는 리소스의 5% 이상은 충분한 표본 크기를 고려할 때 통계적 유의성을 나타냅니다.
## 모두 통합
다음 그림은 단일 가용 영역에 대한 전체 복합 경보 구조를 보여줍니다.
![\[단일 AZ 영향을 파악하기 위한 완전한 복합 경보 구조를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/advanced-multi-az-resilience-patterns/images/composite-alarm-structure-complete.png)
최종 복합 경보 `use1-az1-isolated-impact`는 지연 시간 또는 가용성으로 인한 격리된 가용 영역 영향을 나타내는 복합 경보 `use1-az1-aggregate-alarm`가 `ALARM` 상태에 있고 동일한 가용 영역 `not-single-instance-use1-az1`에 대한 Contributor Insights 규칙에 기반한 경보가 `ALARM` 상태에 있을 때 활성화됩니다(즉, 영향이 단일 인스턴스 이상이라는 의미). 워크로드가 사용하는 각 가용 영역에 대해 이 경보 스택을 생성합니다.
이 최종 경보에 [Amazon 단순 알림 서비스](https://aws.amazon.com/sns/) (AmazonSNS) 알림을 첨부할 수 있습니다. 이전의 모든 경보는 별도의 조치 없이 구성됩니다. 경고는 이메일을 통해 운영자에게 수동 조사를 시작하라고 알릴 수 있습니다. 또한 자동화를 시작하여 가용 영역을 제거할 수도 있습니다. 하지만 이러한 경고에 대응하기 위해 구성 자동화에 주의를 기울여야 합니다. 가용 영역 대피 상황이 발생하면 증가된 오류율이 완화되고 경보가 `OK` 상태로 돌아가게 됩니다. 다른 가용 영역에서 영향이 발생하는 경우 자동화로 인해 두 번째 또는 세 번째 가용 영역이 제거되어 워크로드의 가용 용량이 모두 제거될 수 있습니다. 자동화에서는 조치를 취하기 전에 대피가 이미 수행되었는지 확인해야 합니다. 대피가 성공하기 전에 다른 가용 영역의 리소스를 확장해야 할 수도 있습니다.
MVC웹 앱이나 새 마이크로서비스에 새 컨트롤러나 작업을 추가하거나 일반적으로 별도로 모니터링하려는 추가 기능을 추가할 때는 이 설정에서 경보를 몇 개만 수정하면 됩니다. 해당 새 기능에 대한 새로운 가용성 및 지연 시간 경보를 생성한 다음 이를 여기에서 사용한 예의 적절한 가용 영역 정렬 가용성 및 지연 시간 복합 경보 `az1-latency`와 `az1-availability`에 추가합니다. 나머지 복합 경보는 구성된 후에도 정적 상태를 유지합니다. 따라서 이 접근 방식을 통해 새 기능을 온보딩하는 프로세스가 더 간단해집니다.
# 이상치 감지를 사용한 장애 감지
여러 가용 영역에서 *상관관계가 없는* 이유로 발생하는 오류율이 높아지면 이전 접근 방식과 한 가지 차이가 발생할 수 있습니다. 3개의 가용 영역에 EC2 인스턴스를 배포하고 가용성 경보 임계값이 99% 인 시나리오를 상상해 보십시오. 그렇게 되면, 단일 가용 영역 장애가 발생하여 많은 인스턴스가 격리되고 해당 영역의 가용성이 55%로 떨어집니다. 동시에 다른 가용 영역에서는 단일 EC2 인스턴스가 해당 EBS 볼륨의 모든 스토리지를 소진하여 더 이상 로그 파일을 쓸 수 없게 됩니다. 이로 인해 오류가 반환되기 시작하지만 로드 밸런서 상태 검사를 통과하면 로그 파일 작성이 트리거되지 않기 때문에 여전히 로드 밸런서 상태 검사를 통과합니다. 그 결과 해당 가용 영역의 가용성이 98%로 떨어집니다. 이 경우 여러 가용 영역에서 가용성에 영향을 미치기 때문에 단일 가용 영역 영향 경보가 활성화되지 않습니다. 하지만 손상된 가용 영역을 제거하면 거의 모든 영향을 완화할 수 있습니다.
일부 유형의 워크로드 내에서 이전 가용성 지표가 유용하지 않을 수 있는 모든 가용 영역에서 일관되게 오류가 발생할 수 있습니다. AWS Lambda 예를 들어 보겠습니다. AWS 고객이 Lambda 함수에서 실행할 자체 코드를 생성할 수 있습니다. 서비스를 사용하려면 종속성을 포함하여 ZIP 파일에 코드를 업로드하고 함수의 진입점을 정의해야 합니다. 그러나 고객이 이 부분을 잘못 이해하는 경우가 있습니다. 예를 들어 ZIP 파일의 중요한 종속성을 잊어버리거나 Lambda 함수 정의에서 메서드 이름을 잘못 입력할 수 있습니다. 이로 인해 함수 호출이 실패하고 오류가 발생합니다. AWS Lambda 이런 종류의 오류가 항상 나타나지만, 그렇다고 해서 반드시 비정상인 것은 아닙니다. 하지만 가용 영역 장애와 같은 원인으로 인해 이러한 오류가 나타날 수도 있습니다.
이러한 종류의 노이즈에서 신호를 찾으려면 이상치 감지를 사용하여 가용 영역 간의 오류 수에 통계적으로 유의한 편차가 있는지 확인할 수 있습니다. 여러 가용 영역에서 오류가 발생하긴 하지만 그 중 하나에 실제로 장애가 발생한 경우 해당 가용 영역에서 다른 가용 영역에 비해 오류율이 훨씬 높거나 더 낮을 수 있습니다. 하지만 얼마나 높거나 낮을까요?
이 분석을 수행하는 한 가지 방법은 [카이 제곱](https://en.wikipedia.org/wiki/Chi-squared_test)(*χ*2) 검정을 사용하여 가용 영역 간 오류율의 통계적으로 유의한 차이를 탐지하는 것입니다([이상값 탐지를 수행하는 알고리즘은 매우 다양함](https://dataprocessing.aixcape.org/DataPreprocessing/DataCleaning/OutlierDetection/index.html)). 카이 제곱 테스트의 작동 방식을 살펴보겠습니다.
카이 제곱 테스트는 결과의 일부 분포가 발생할 확률을 평가합니다. 이 경우에는 정의된 일부 집합에 오류가 분포되어 있는지 살펴보겠습니다. AZs 이 예제에서는 계산을 더 쉽게 하기 위해 가용 영역 4개를 고려해 보겠습니다.
먼저 기본 결과가 무엇이라고 생각하는지 정의하는 *귀무가설*을 설정합니다. 이 테스트에서 귀무가설은 오류가 각 가용 영역에 고르게 분포될 것으로 예상한다는 것입니다. 그런 다음 오류가 균등하게 분포되지 않아 가용 영역이 손상되었다는 *대안가설*을 설정합니다. 이제 메트릭의 데이터를 사용하여 이러한 가설을 테스트할 수 있습니다. 이를 위해 5분 동안 지표를 샘플링해 보겠습니다. 해당 창에 1,000개의 게시된 데이터 포인트가 있고 총 100개의 오류가 표시된다고 가정해 보겠습니다. 균등한 분포를 사용하면 네 가용 영역 각각에서 25%의 시간 동안 오류가 발생할 것으로 예상됩니다. 다음 표에 예상한 내용과 실제로 본 내용이 비교되어 나타난다고 가정해 보겠습니다.
*표 1: 발생한 예상 오류와 실제 오류 비교*
| AZ | 예상 | 실제 |
| --- | --- | --- |
| use1-az1 | 25 | 20 |
| use1-az2 | 25 | 20 |
| use1-az3 | 25 | 25 |
| use1-az4 | 25 | 35 |
따라서 실제 분포는 균일하지 않다는 것을 알 수 있습니다. 하지만 샘플링한 데이터 포인트가 어느 정도 무작위적이기 때문에 이런 일이 발생했다고 가정할 수 있습니다. 표본 집합에서 이러한 유형의 분포가 발생할 확률은 어느 정도 있지만 귀무가설이 참이라고 가정할 수 있습니다. 이는 다음과 같은 질문으로 이어집니다. 적어도 이 극단적인 결과를 얻을 확률은 얼마일까요? 해당 확률이 정의된 임계값보다 낮으면 귀무가설을 기각합니다. [https://en.wikipedia.org/wiki/Statistical_significance](https://en.wikipedia.org/wiki/Statistical_significance), 이 확률은 5% 이하여야 합니다.1
1 Craparo, Robert M. (2007). ‘중요도 수준’. Salkind, Neil J. 측정 및 통계 백과사전 3. 캘리포니아 주 사우전드 옥스: SAGE 간행물. 889\$1891쪽. ISBN1-412-91611-9.
이 결과가 나올 확률은 어떻게 계산할까요? 매우 잘 연구된 분포를 제공하는 *χ2* 통계를 용하여 이 극단적 또는 더 극단적인 결과가 나올 확률을 결정하는 데 이를 사용할 수 있습니다.
![\[Ei, Oi 및 X2의 공식\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/advanced-multi-az-resilience-patterns/images/formulas1.png)
이 예제의 결과는 다음과 같습니다.
![\[이 예제를 사용하여 Ei, Oi 및 X2의 공식을 계산하면 답은 6입니다.\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/advanced-multi-az-resilience-patterns/images/formulas2.png)
그렇다면 확률 측면에서 `6`은 무엇을 의미할까요? 적절한 자유도를 가진 카이-제곱 분포를 살펴봐야 합니다. 다음 그림은 다양한 자유도에 대한 여러 카이 제곱 분포를 보여줍니다.
![\[다양한 자유도에 대한 카이 제곱 분포를 보여주는 그래프\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/advanced-multi-az-resilience-patterns/images/chi-squared-distributions.png)
자유도는 테스트에서 선택한 항목 수보다 하나 적은 것으로 계산됩니다. 이 경우 가용 영역이 4개이므로 자유도는 3입니다. 그 다음 *k = 3* 그림의 *x ≥ 6*에 대한 곡선 아래 면적(적분) 을 구해보겠습니다. 일반적으로 사용되는 값이 포함된 미리 계산된 표를 사용하여 해당 값의 근사치를 계산할 수도 있습니다.
*표 2: 카이 제곱 임계값 *
| 자유도 | 임계값보다 낮은 확률 | | **0.75** | **0.90** | **0.95** | **0.99** | **0.999** |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 1 | 1.323 | 2.706 | 3.841 | 6.635 | 10.828 |
| 2 | 2.773 | 4.605 | 5.991 | 9.210 | 13.816 |
| 3 | 4.108 | 6.251 | 7.815 | 11.345 | 16.266 |
| 4 | 5.385 | 7.779 | 9.488 | 13.277 | 18.467 |
자유도가 3인 경우 카이-제곱 값인 6은 확률 열 0.75와 0.9 사이에 속합니다. 이것이 의미하는 바는 이 분포가 발생할 확률이 10% 이상이며, 이는 5% 임계값 이상이라는 것입니다. 따라서 *귀무가설*을 받아들이고 가용 영역 간의 오류율에 통계적으로 유의한 차이가 *없다고* 판단합니다.
카이 제곱 통계 테스트 수행은 CloudWatch 메트릭 수학에서 기본적으로 지원되지 않으므로 CloudWatch Lambda와 같은 컴퓨팅 환경에서 해당하는 오류 메트릭을 수집하고 테스트를 실행해야 합니다. MVC컨트롤러/액션, 개별 마이크로서비스 수준 또는 가용 영역 수준에서 이 테스트를 수행할지 결정할 수 있습니다. 가용 영역 장애가 각 컨트롤러/액션 또는 마이크로서비스에 동일하게 영향을 미칠지, 또는 장애와 같은 문제가 처리량이 높은 서비스가 아닌 처리량이 낮은 서비스에 영향을 미쳐 집계했을 때 그 영향을 가릴 수 있는지 고려해야 합니다. DNS 어느 경우든 적절한 차원을 선택하여 쿼리를 생성합니다. 세분화 수준은 생성한 결과 경보에도 영향을 미칩니다. CloudWatch
지정된 기간 내에 각 AZ 및 컨트롤러/작업에 대한 오류 수 지표를 수집합니다. 먼저 카이-제곱 테스트 결과를 참(통계적으로 유의한 편차가 있음) 또는 거짓(존재하지 않았으므로 귀무가설 성립)으로 계산합니다. 결과가 거짓이면 메트릭 스트림에 0 데이터 포인트를 게시하여 각 가용 영역에 대한 카이 제곱 결과를 얻습니다. 결과가 참인 경우, 예상 값에서 가장 멀리 떨어진 오류가 있는 가용 영역에 대해 1 데이터 포인트를 게시하고 나머지는 0으로 게시합니다 (Lambda 함수 내에서 사용할 수 있는 샘플 코드는 [부록 B — 카이 제곱 계산의 예](appendix-b-example-chi-squared-calculation.md) 참조). Lambda 함수에서 생성되는 데이터 포인트를 기반으로 3연속 CloudWatch 측정치 경보 및 CloudWatch 5점 중 3점 측정치 경보를 생성하여 이전 가용성 경보와 동일한 접근 방식을 따를 수 있습니다. 이전 예시처럼 이 접근 방식을 수정하여 더 짧거나 긴 기간에 더 많거나 적은 데이터 포인트를 사용할 수 있습니다.
그 다음, 다음 그림에 표시된 컨트롤러 및 작업 조합에 대한 기존 가용 영역 가용성 경보에 이러한 경보를 추가합니다.
![\[카이 제곱 통계 테스트를 복합 경보와 통합하는 방법을 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/advanced-multi-az-resilience-patterns/images/statistics-test-with-composite-alarms.png)
앞서 언급했듯이 워크로드에 새 기능을 온보딩할 때는 새 기능에 맞는 적절한 CloudWatch 메트릭 경보를 생성하고 이러한 경보를 포함하도록 복합 경보 계층 구조의 다음 계층을 업데이트하기만 하면 됩니다. 나머지 경보 구조는 정적으로 유지됩니다.
# 단일 인스턴스 영역 리소스의 장애 감지
경우에 따라 영역 리소스의 단일 활성 인스턴스가 있을 수 있으며, 가장 일반적으로 시스템에는 관계형 데이터베이스 (예: AmazonRDS) 또는 분산 캐시 ([Amazon ElastiCache (Redis OSS](https://aws.amazon.com/elasticache/redis/))) 와 같은 단일 작성기 구성 요소가 필요합니다. 단일 가용 영역 손상이 기본 리소스가 속한 가용 영역에 영향을 미치는 경우 해당 리소스에 액세스하는 모든 가용 영역에 영향을 미칠 수 있습니다. 이로 인해 모든 가용 영역에서 가용성 임계값이 초과될 수 있으며, 이는 첫 번째 접근 방식으로는 영향의 단일 가용 영역 원인을 정확하게 식별하지 못할 수 있습니다. 또한 각 가용 영역에서 유사한 오류율이 나타날 수 있습니다. 즉, 이상치 분석으로도 문제를 발견하지 못할 수 있습니다. 즉, 이 시나리오를 구체적으로 탐지하려면 추가 관찰성을 구현해야 합니다.
우려되는 리소스가 자체 상태에 대한 지표를 생성할 가능성이 높지만 가용 영역에 장애가 발생하면 해당 리소스가 해당 지표를 제공하지 못할 수 있습니다. 이 시나리오에서는 *플라잉 블라인드* 상태가 언제인지 알 수 있도록 경보를 만들거나 업데이트해야 합니다. 이미 모니터링하고 경보를 발령한 중요 지표가 있는 경우 [누락된 데이터](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)를 위반으로 처리하도록 경보를 구성할 수 있습니다. 이렇게 하면 리소스가 데이터 보고를 중단하는지 여부를 알 수 있으며, 이전에 사용한 동일한 경보와 *n개 중 m개*의 경보를 *연속으로* 포함할 수 있습니다.
또한 리소스 상태를 나타내는 일부 지표에서는 활동이 없을 때 값이 0인 데이터 포인트를 게시할 수도 있습니다. 장애로 인해 리소스와의 상호 작용이 불가능하다면 이러한 종류의 지표에는 누락된 데이터 접근 방식을 사용할 수 없습니다. 또한 값이 정상 임계값 내에 있는 합법적인 시나리오가 있을 수 있으므로 값이 0이라고 해서 경보를 울리는 것은 좋지 않을 것입니다. 이러한 유형의 문제를 탐지하는 가장 좋은 방법은 리소스가 이 종속성을 사용하여 산출한 지표를 사용하는 것입니다. 이 경우 복합 경보를 사용하여 *다중* 가용 영역에 미치는 영향을 감지하고자 합니다. 이러한 경보는 리소스와 관련된 몇 가지 중요한 지표 카테고리를 사용해야 합니다. 몇 가지 예가 아래에 나열되어 있습니다.
+ **처리량** — 들어오는 작업 단위의 비율. 여기에는 트랜잭션, 읽기, 쓰기 등이 포함될 수 있습니다.
+ **가용성** — 성공한 작업 단위와 실패한 작업 단위의 수를 측정합니다.
+ **지연 시간** — 중요한 작업에서 성공적으로 수행된 작업의 지연 시간을 여러 백분위수로 측정합니다.
다시 한 번 말씀드리지만, 측정하려는 각 지표 범주의 각 지표에 대해 *연속* 및 *m개 중 n개* 지표 경보를 생성할 수 있습니다. 이전과 마찬가지로 이러한 경보를 복합 경보로 결합하여 이 공유 리소스가 가용 영역 전체에 미치는 영향의 근원인지 확인할 수 있습니다. 복합 경보를 사용하여 둘 이상의 가용 영역에 미치는 영향을 식별하고자 하겠지만, 그 영향이 반드시 *모든* 가용 영역일 필요는 없습니다. 이러한 접근 방식에 대한 상위 수준의 복합 경보 구조가 다음 그림에 나와 있습니다.
![\[단일 리소스로 인해 여러 가용 영역에 미치는 영향을 감지하기 위한 경보를 생성하는 예를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/advanced-multi-az-resilience-patterns/images/creating-alarms-to-detect-impact.png)
이 다이어그램이 사용해야 하는 지표 경보 유형과 복합 경보의 계층 구조에 대해서 보다 덜 규정적임을 알 수 있습니다. 이런 종류의 문제를 발견하는 것은 어려울 수 있으며 공유 리소스에 대한 올바른 신호에 주의를 기울여야 하기 때문입니다. 이러한 신호를 특정한 방식으로 평가해야 할 수도 있습니다.
또한 `primary-database-impact` 경보가 특정 가용 영역과 연결되어 있지 않다는 것도 알 수 있습니다. 이는 기본 데이터베이스 인스턴스가 사용하도록 구성된 모든 가용 영역에 위치할 수 있으며, 해당 인스턴스의 위치를 지정하는 CloudWatch 지표가 없기 때문입니다. 이 경보가 활성화되면 이를 리소스에 문제가 있을 수 있다는 신호로 사용하고 자동으로 수행되지 않은 경우 다른 가용 영역으로 장애 조치를 시작해야 합니다. 리소스를 다른 가용 영역으로 이동한 후에는 격리된 가용 영역 경보가 활성화되었는지 기다리거나 가용 영역 제거 계획을 선제적으로 간접적으로 호출하도록 선택할 수 있습니다.
# 요약
이 섹션에서는 단일 가용 영역 장애를 식별하는 데 도움이 되는 세 가지 접근 방식을 설명했습니다. 각 접근 방식을 함께 사용하여 워크로드 상태를 전체적으로 파악해야 합니다.
CloudWatch 복합 경보 접근 방식을 사용하면 가용성 편차가 통계적으로 유의미하지 않은 문제 (예: 가용성 98% (손상된 가용 영역), 100%, 99.99% 의 가용성이 단일 공유 리소스로 인한 것이 아닌 문제를 찾을 수 있습니다.
이상치 감지는 다중 가용 영역에서 상관 관계가 없는 오류가 발생하여 경보 임계값을 모두 초과하는 단일 가용 영역 장애를 감지하는 데 도움이 됩니다.
마지막으로, 단일 인스턴스 영역 리소스의 성능 저하를 식별하면 가용 영역 장애가 가용 영역 전체에서 공유되는 리소스에 영향을 미치는 시기를 파악하는 데 도움이 됩니다.
이러한 각 패턴의 결과 경보를 CloudWatch 복합 경보 계층 구조로 결합하여 단일 가용 영역 장애가 발생하고 워크로드의 가용성 또는 지연 시간에 영향을 미치는 시기를 찾아낼 수 있습니다.