

# 사고 탐지 및 대응에서 경보 정의 및 구성
<a name="idr-gs-alarms"></a>

AWS는 사용자와 협력하여 지표 및 경보를 정의하여 애플리케이션 및 기본 AWS 인프라의 성능에 대한 가시성을 제공합니다. 임곗값을 정의하고 구성할 때 경보가 다음 기준을 준수하도록 요청합니다.
+ 경보는 즉각적인 운영자 주의가 필요한 모니터링되는 워크로드(수익 손실 또는 성능이 크게 저하되는 고객 경험 저하)에 심각한 영향을 미치는 경우에만 ‘경보’ 상태로 전환됩니다.
+ 또한 경보는 인시던트 관리 팀을 참여시키는 동시에 또는 참여 전에 워크로드에 대해 지정된 해석기를 참여시켜야 합니다. 인시던트 관리 엔지니어는 완화 프로세스에서 지정된 해석기와 협업해야 하며, 일선 대응 담당자 역할을 하지 않고 에스컬레이션해야 합니다.
+ 경보 임곗값은 경보가 조사를 실행할 때마다 적절한 임곗값 및 기간으로 설정해야 합니다. 경보가 ‘경보’ 상태와 ‘정상’ 상태 사이를 오가는 경우 운영자의 응답과 주의를 끌기에 충분한 영향이 발생합니다.

**경보 유형**:
+ 비즈니스 영향 수준을 설명하고 간단한 장애 감지를 위해 관련 정보를 전달하는 경보입니다.
+ Amazon CloudWatch 카나리. 자세한 내용은 [카나리 및 X-Ray 추적](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_tracing.html) 및 [X-Ray](https://aws.amazon.com/xray/)를 참조하세요.
+ 집계 경보(종속성 모니터링)

다음 표에는 CloudWatch 모니터링 시스템을 사용하는 경보의 예가 나와 있습니다.


****  

| 지표 이름/경보 임곗값 | 경보 ARN 또는 리소스 ID | 이 경보가 실행되는 경우 | 참여하는 경우 이러한 서비스에 대한 Premium Support Case를 자릅니다. | 
| --- | --- | --- | --- | 
| API 오류 / 10개의 데이터 포인트에 대해 오류 수 >= 10 | arn:aws:cloudwatch:us-west-2:000000000000:alarm:E2MPmimLambda-Errors | 데이터베이스 관리자(DBA) 팀으로 티켓 잘라내기 | Lambda API Gateway | 
| ServiceUnavailable(HTTP 상태 코드 503) 5분 동안 10개의 데이터 포인트(다른 클라이언트)에 대한 오류 수 >=3 | arn:aws:cloudwatch:us-west-2:xxxxx:alarm:httperrorcode503 | 서비스 팀으로 티켓 자르기 | Lambda API Gateway | 
| ThrottlingException(HTTP 상태 코드 400) 5분 동안 10개의 데이터 포인트(다른 클라이언트)에 대한 오류 수 >=3 | arn:aws:cloudwatch:us-west-2:xxxxx:alarm:httperrorcode400 | 서비스 팀으로 티켓 자르기 | EC2, Amazon Aurora | 

자세한 내용은 [AWS 사고 탐지 및 대응 모니터링 및 관찰성](observe-idr.md) 섹션을 참조하세요.

자동화 도구를 사용하여 경보를 온보딩하려는 경우 사고 탐지 및 대응 명령줄 인터페이스(CLI)를 사용하면 경보를 배포하고 온보딩할 수 있습니다. 자세한 내용은 [AWS 사고 탐지 및 대응 CLI](idr-cli.md) 섹션을 참조하세요.

**핵심 결과물:**
+ 워크로드에 대한 경보의 정의 및 구성입니다.
+ 온보딩 설문지의 경보 세부 정보 작성.

**Topics**
+ [CloudWatch 경보 생성](idr-alarms-fit-purpose.md)
+ [CloudFormation 템플릿을 사용하여 CloudWatch 경보 구축](idr-create-alarms-with-cfn.md)
+ [CloudWatch 경보 예제 사용 사례](idr-ex-alarm-use-cases.md)

# 사고 탐지 및 대응에서 비즈니스 요구 사항에 맞는 CloudWatch 경보 생성
<a name="idr-alarms-fit-purpose"></a>

Amazon CloudWatch 경보를 생성할 때 경보가 비즈니스 요구 사항에 가장 적합하도록 하기 위해 취할 수 있는 몇 가지 단계가 있습니다.

**참고**  
사고 탐지 및 대응에 온보딩하기 위해 AWS 서비스에 권장되는 CloudWatch 경보의 예는 [AWS re:Post의 사고 탐지 및 대응 경보 모범 사례](https://repost.aws/selections/KP6FA7iQgVSVeSNq1jAcjwxg/incident-detection-and-response-idr)를 참조하세요.

## 제안된 CloudWatch 경보 검토
<a name="idr-review-alarms"></a>

제안된 경보를 검토하여 모니터링되는 워크로드에 중요한 영향(수익 손실 또는 성능이 크게 저하되는 고객 경험 저하)이 있을 때만 ‘경보’ 상태가 되는지 확인합니다. 예를 들어 이 경보가 ‘경보’ 상태가 되면 즉시 대응해야 할 만큼 중요한 경보라고 생각하나요?

다음은 애플리케이션에 대한 최종 사용자의 경험에 영향을 미치는 등 중요한 비즈니스 영향을 나타낼 수 있는 권장 지표입니다.
+ **CloudFront:** 자세한 내용은 [CloudFront 및 엣지 함수 지표 보기](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/viewing-cloudfront-metrics.html)를 참조하세요.
+ **Application Load Balancer:** 가능하면 Application Load Balancer에 대해 다음 경보를 생성하는 것이 좋습니다.
  + HTTPCode\$1ELB\$15XX\$1Count
  + HTTPCode\$1Target\$15XX\$1Count

  위의 경보를 통해 Application Load Balancer 또는 다른 리소스를 사용하는 대상의 응답을 모니터링할 수 있습니다. 이렇게 하면 5XX 오류의 원인을 더 쉽게 식별할 수 있습니다. 자세한 내용은 [Application Load Balancer의 CloudWatch 지표](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html)를 참조하세요.
+ **Amazon API Gateway:** Elastic Beanstalk에서 WebSocket API를 사용하는 경우 다음 지표를 사용하는 것이 좋습니다.
  + 통합 오류율(5XX 오류로 필터링됨)
  + 통합 지연 시간
  + 실행 오류

  자세한 내용은 [CloudWatch 지표를 사용한 WebSocket API 모니터링](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-websocket-api-logging.html)을 참조하세요.
+ **Amazon Route 53:** **EndPointUnhealthyENICount** 지표를 모니터링합니다. 이 지표는 **자동 복구** 상태의 탄력적 네트워크 인터페이스 수입니다. 이 상태는 해석기가 엔드포인트와 연결된 하나 이상의 Amazon Virtual Private Cloud 네트워크 인터페이스를 복구하려는 시도(**EndpointId**로 지정)를 나타냅니다. 복구 프로세스에서 엔드포인트는 제한된 용량으로 작동합니다. 엔드포인트는 완전히 복구될 때까지 DNS 쿼리를 처리할 수 없습니다. 자세한 내용은 [Amazon CloudWatch를 사용하여 Amazon Route 53 Resolver 엔드포인트 모니터링](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-resolver-with-cloudwatch.html)을 참조하세요.

## 경보 구성 검증
<a name="idr-validate-alarm-config"></a>

제안된 경보가 비즈니스 요구 사항에 맞는지 확인한 후 경보의 구성 및 기록을 확인합니다.
+ 지표의 **임곗값**을 검증하여 지표의 그래프 추세와 비교하여 ‘경보’ 상태로 전환합니다.
+ 데이터 포인트를 폴링하는 데 사용되는 **기간**을 검증합니다. 60초에 데이터 포인트를 폴링하면 인시던트를 조기에 감지하는 데 도움이 됩니다.
+ **DatapointToAlarm** 구성을 검증합니다. 대부분의 경우 이 값을 3/3 또는 5/5로 설정하는 것이 가장 좋습니다. 인시던트에서 경보는 [3 DatapointToAlarm 중 3개가 포함된 60초 지표]로 설정된 경우 3분 후, [5 DatapointToAlarm 중 5개가 포함된 60초 지표]로 설정된 경우 5분 후에 트리거됩니다. 이 조합을 사용하여 노이즈 경보를 제거합니다.

**참고**  
위의 권장 사항은 서비스 사용 방식에 따라 달라질 수 있습니다. 각 AWS 서비스는 워크로드 내에서 다르게 작동합니다. 또한 여러 위치에서 사용할 때 동일한 서비스가 다르게 작동할 수 있습니다. 워크로드가 경보를 제공하는 리소스와 업스트림 및 다운스트림 효과를 어떻게 활용하는지 이해해야 합니다.

## 경보가 누락된 데이터를 처리하는 방법 검증
<a name="idr-validate-missing-data"></a>

일부 지표 소스는 정기적으로 CloudWatch로 데이터를 전송하지 않습니다. 이러한 지표의 경우 누락된 데이터를 **notBreaching**으로 처리하는 것이 가장 좋습니다. 자세한 내용은 [CloudWatch 경보가 누락된 데이터를 처리하는 방법 구성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data) 및 [경보 상태 조기 전환 방지](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#CloudWatch-alarms-avoiding-premature-transition)를 참조하세요.

예를 들어 지표가 오류율을 모니터링하고 오류가 없는 경우 지표는 데이터 없음(nil) 데이터 포인트를 보고합니다. 누락된 데이터를 **누락**으로 처리하도록 경보를 구성할 경우 위반 데이터 포인트 1개와 데이터 없음(nil) 데이터 포인트 2개가 있으면 지표가 ‘경보’ 상태가 됩니다(데이터 포인트 3개 중 3개). 이는 누락된 데이터 구성이 평가 기간의 마지막으로 알려진 데이터 포인트를 평가하기 때문입니다.

지표가 오류율을 모니터링하는 경우 서비스 성능 저하가 없으면 좋은 데이터가 없다고 가정할 수 있습니다. 누락된 데이터가 ‘정상'으로 처리되고 지표가 단일 데이터 포인트에서 ‘경보’ 상태가 되지 않도록 누락 데이터를 **notBreaching**으로 처리하는 것이 모범 사례입니다.

## 각 경보의 기록 검토
<a name="idr-review-alarm-history"></a>

경보 기록에 ‘경보’ 상태로 자주 전환되었다가 빠르게 복구되는 것으로 표시되면 경보가 문제가 될 수 있습니다. 경보를 조정하여 노이즈 또는 거짓 경보를 방지해야 합니다.

## 기본 리소스에 대한 지표 검증
<a name="idr-validate-underlying-resources"></a>

지표가 유효한 기본 리소스를 살펴보고 올바른 통계를 사용해야 합니다. 경보가 잘못된 리소스 이름을 검토하도록 구성된 경우 경보가 기본 데이터를 추적하지 못할 수 있습니다. 이로 인해 경보가 ‘경보’ 상태가 될 수 있습니다.

## 복합 경보 생성
<a name="idr-create-composite-alarms"></a>

온보딩을 위해 인시던트 감지 및 대응 작업에 많은 수의 경보를 제공하는 경우 복합 경보를 생성하라는 메시지가 표시될 수 있습니다. 복합 경보는 온보딩해야 하는 총 경보 수를 줄입니다.

# CloudFormation 템플릿을 사용하여 사고 탐지 및 대응에서 CloudWatch 경보 구축
<a name="idr-create-alarms-with-cfn"></a>

AWS 사고 탐지 및 대응에 대한 온보딩을 가속화하고 경보를 구축하는 데 필요한 노력을 줄이기 위해 AWS에서는 CloudFormation 템플릿을 제공합니다. 이러한 템플릿에는 Application Load Balancer, Network Load Balancer 및 Amazon CloudFront 등 일반적으로 온보딩되는 서비스에 대한 최적화된 경보 설정이 포함되어 있습니다.

**CloudFormation 템플릿을 사용하여 CloudWatch 경보 구축**

1. 제공된 링크를 사용하여 템플릿을 다운로드합니다.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/IDR/latest/userguide/idr-create-alarms-with-cfn.html)

1. 다운로드한 JSON 파일을 검토하여 조직의 운영 및 보안 프로세스를 충족하는지 확인합니다.

1. CloudFormation 스택을 생성합니다.
**참고**  
다음 단계에서는 표준 CloudFormation 스택 생성 프로세스를 사용합니다. 자세한 단계는 [CloudFormation 콘솔에서 스택 생성](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)을 참조하세요.

   1. AWS CloudFormation 콘솔([https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/))을 엽니다.

   1. **스택 생성**을 선택합니다.

   1. **템플릿 준비 완료**를 선택한 다음 로컬 폴더에서 템플릿 파일을 업로드합니다.

      다음은 **스택 생성** 화면의 예입니다.  
![\[스택 업로드 템플릿 파일 생성 예제\]](http://docs.aws.amazon.com/ko_kr/IDR/latest/userguide/images/create-cfn-stack1.png)

   1. **다음**을 선택합니다.

   1. 다음 필수 정보를 입력합니다.
      + **AlarmNameConfig** 및 **AlarmDescriptionConfig**: 경보의 이름과 설명을 입력합니다.
      + **ThresholdConfig**: 애플리케이션의 요구 사항에 맞게 임곗값을 수정합니다.
      + **DistributionIDConfig**: 배포 ID가 CloudFormation 스택을 생성하려는 계정의 올바른 리소스를 가리키는지 확인합니다.

   1. **다음**을 선택합니다.

   1. **PeriodConfig**, **EvalutionPeriodConfig** 및 **DatapointsToAlarmConfig** 필드의 기본값을 검토합니다. 이러한 필드의 기본값을 사용하는 것이 가장 좋습니다. 필요한 경우 애플리케이션의 요구 사항에 맞게 조정할 수 있습니다.

   1. 필요에 따라 태그 및 SNS 알림 정보를 입력할 수도 있습니다. 경보가 실수로 삭제되지 않도록 **종료 방지** 기능을 켜는 것이 가장 좋습니다. 종료 방지 기능을 켜려면 다음 예제와 같이 **활성화됨** 라디오 버튼을 선택합니다.  
![\[스택 생성 활성화 종료 방지 예제\]](http://docs.aws.amazon.com/ko_kr/IDR/latest/userguide/images/create-cfn-stack2.png)

   1. **다음**을 선택합니다.

   1. 스택 설정을 검토한 후 **스택 생성**을 선택합니다.

   1. 스택을 생성한 후 다음 예제와 같이 Amazon CloudWatch 경보 목록에 **경보**가 나열됩니다.  
![\[CloudWatch 경보 목록 예제\]](http://docs.aws.amazon.com/ko_kr/IDR/latest/userguide/images/create-cfn-stack3.png)

1. 올바른 계정 및 AWS 리전에서 모든 경보를 생성한 후 기술 계정 관리자(TAM)에게 알립니다. AWS 사고 탐지 및 대응 팀은 새 경보의 상태를 검토한 다음 온보딩을 계속합니다.

# 사고 탐지 및 대응의 CloudWatch 경보 예제 사용 사례
<a name="idr-ex-alarm-use-cases"></a>

다음 사용 사례는 사고 탐지 및 대응에서 Amazon CloudWatch 경보를 사용하는 방법의 예를 제공합니다. 이 예제는 다양한 AWS 서비스에서 주요 지표와 임곗값을 모니터링하도록 CloudWatch 경보를 구성하여 애플리케이션 및 워크로드의 가용성과 성능에 영향을 미칠 수 있는 잠재적 문제를 식별하고 대응할 수 있는 방법을 보여줍니다.

## 예제 사용 사례 A: Application Load Balancer
<a name="use-case-alb"></a>

잠재적인 워크로드 영향을 나타내는 다음과 같은 CloudWatch 경보를 생성할 수 있습니다. 이렇게 하려면 연결 성공이 특정 임곗값 아래로 떨어질 때 경보를 생성하는 지표 수학을 생성합니다. 사용 가능한 CloudWatch 지표는 [Application Load Balancer에 대한 CloudWatch 지표](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html)를 참조하세요.

**지표:**`HTTPCode_Target_3XX_Count;HTTPCode_Target_4XX_Count;HTTPCode_Target_5XX_Count. (m1+m2)/(m1+m2+m3+m4)*100 m1 = HTTP Code 2xx || m2 = HTTP Code 3xx || m3 = HTTP Code 4xx || m4 = HTTP Code 5xx`

**네임스페이스:** AWS/ApplicationELB

**ComparisonOperator(임곗값):** x 미만(x = 고객의 임곗값).

**기간:** 60초

**DatapointsToAlarm:** 3/3

**누락 데이터 처리** 누락 데이터를 [위반](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)으로 처리합니다.

**통계: **Sum

다음 다이어그램은 사용 사례 A의 흐름을 보여줍니다.

![\[Application Load Balancer의 예제 사용 사례\]](http://docs.aws.amazon.com/ko_kr/IDR/latest/userguide/images/UseCaseAALB.png)


## 예제 사용 사례 B: Amazon API Gateway
<a name="use-case-apigateway"></a>

잠재적인 워크로드 영향을 나타내는 다음과 같은 CloudWatch 경보를 생성할 수 있습니다. 이렇게 하려면 API Gateway에서 지연 시간이 높거나 평균 4XX 오류 수가 많을 때 경보를 생성하는 복합 지표를 생성합니다. 사용 가능한 지표는 [Amazon API Gateway 차원 및 지표](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-metrics-and-dimensions.html)를 참조하세요.

**지표:**`compositeAlarmAPI Gateway (ALARM(error4XXMetricApiGatewayAlarm)) OR (AALARM(latencyMetricApiGatewayAlarm))`

**네임스페이스:** AWS/API Gateway

**ComparisonOperator(임곗값):** 보다 큼(x 또는 y 고객의 임곗값)

**기간:** 60초

**DatapointsToAlarm:** 1/1

**누락 데이터 처리** 누락 데이터를 [위반하지 않음](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)으로 처리합니다.

**통계 **– .

다음 다이어그램은 사용 사례 B의 흐름을 보여줍니다.

![\[API Gateway의 예제 사용 사례\]](http://docs.aws.amazon.com/ko_kr/IDR/latest/userguide/images/UseCaseBAPIGW.png)


## 예제 사용 사례 C: Amazon Route 53
<a name="use-case-apigateway"></a>

CloudWatch를 사용하여 원시 데이터를 수집하고 읽기 가능하며 실시간에 가까운 지표로 처리하는 Route 53 상태 확인을 만들어 리소스를 모니터링할 수 있습니다. 잠재적인 워크로드 영향을 나타내는 다음과 같은 CloudWatch 경보를 생성할 수 있습니다. CloudWatch 지표를 사용하여 설정된 임곗값을 위반할 때 트리거되는 경보를 생성할 수 있습니다. 사용 가능한 CloudWatch 지표는 [Route 53 상태 확인을 위한 CloudWatch 지표](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/monitoring-cloudwatch.html#cloudwatch-metrics)를 참조하세요.

**지표:**`R53-HC-Success`

**네임스페이스:** AWS/Route 53

**임곗값 HealthCheckStatus:** 3분 이내에 3개의 데이터 포인트에 대한 HealthCheckStatus < x(x 고객의 임곗값)

**기간:** 1분

**DatapointsToAlarm:** 3/3

**누락 데이터 처리** 누락 데이터를 [위반](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-missing-data)으로 처리합니다.

**통계: **Minimum

다음 다이어그램은 사용 사례 C의 흐름을 보여줍니다.

![\[Route 53 예제 사용 사례\]](http://docs.aws.amazon.com/ko_kr/IDR/latest/userguide/images/UseCaseCR53.png)


## 예제 사용 사례 D: 사용자 지정 앱을 사용하여 워크로드 모니터링
<a name="use-case-apigateway"></a>

이 시나리오에서는 시간을 내어 적절한 상태 확인을 정의하는 것이 중요합니다. 애플리케이션의 포트만 열려 있는지 확인하는 경우 애플리케이션이 작동하는지는 확인하지 않은 것입니다. 또한 애플리케이션의 홈 페이지를 직접 호출하는 것이 앱이 작동하는지 확인하는 올바른 방법은 아닙니다. 예를 들어 애플리케이션이 데이터베이스와 Amazon Simple Storage Service(Amazon S3)에 모두 의존하는 경우 상태 확인은 모든 요소를 검증해야 합니다. 이를 수행하는 한 가지 방법은 **/monitor**와 같은 모니터링 웹 페이지를 생성하는 것입니다. 모니터링 웹 페이지는 데이터베이스를 직접 호출하여 데이터를 연결하고 가져올 수 있는지 확인합니다. 또한 모니터링 웹 페이지는 Amazon S3를 직접 호출합니다. 그런 다음 로드 밸런서의 상태 확인을 **/monitor** 페이지로 가리킵니다.

다음 다이어그램은 사용 사례 D의 흐름을 보여줍니다.

![\[사용자 지정 앱을 사용한 모니터링 예제 사용 사례\]](http://docs.aws.amazon.com/ko_kr/IDR/latest/userguide/images/CustomAlarm.png)
