[AWS] CloudWatch 구성 및 활용 메뉴얼

이동엽·2024년 3월 27일
1

aws

목록 보기
3/4

본 자료는 사내 스터디에서 진행했던 내용입니다.

상세 지표들에 대해서는 사내 정보이기에 수치를 가려 작성하였습니다.


1. AWS CloudWatch 소개

Amazon CloudWatch는 DevOps 엔지니어, 개발자, 사이트 안정성 엔지니어(SRE), IT 관리자 및 제품 소유자를 위해 구축된 모니터링 및 관찰 서비스입니다.

CloudWatch는 애플리케이션을 모니터링하고 시스템 전체 성능 변경에 대응하며 리소스 사용률을 최적화하는 데 필요한 데이터와 실행 가능한 인사이트를 제공합니다.

출처 : AWS 공식 홈페이지


1.1 AWS의 각종 리소스를 감시하는 서비스

  • AWS 리소스의 생사, 성능, 로그의 감시/감독
  • 대상 지표에 대한 그래프를 통한 가시화
  • 각종 지표에 기반한 알람 서비스


1.2 AWS CloudWatch 관련 용어 개념

네임 스페이스

  • CloudWatch 지표의 컨테이너로, CloudWatch에 게시하는 각 데이터 포인트의 네임스페이스를 지정해야 한다.

  • AWS 네임스페이스는 일반적으로 AWS/service라는 명명 규칙을 사용

    • 예를 들어 Amazon EC2는 AWS/EC2 네임스페이스를 사용
    • AWS 네임스페이스 목록은 첨부 링크에서 확인할 수 있음

지표

  • 지표는 모니터링할 변수로, 데이터 요소는 시간에 따른 변수의 값을 나타내는 것으로 간주
    • 예를 들어 특정 EC2 인스턴스의 CPU 사용량은 Amazon EC2가 제공하는 하나의 지표

  • 기본적으로 많은 AWS 서비스에서 리소스(예: Amazon EC2 인스턴스, Amazon EBS 볼륨, Amazon RDS DB 인스턴스)에 대한 지표를 무료로 제공
  • 또한 유료로 Amazon EC2 인스턴스와 같은 일부 리소스에 대한 세부 모니터링을 사용하거나 자체 애플리케이션 지표를 게시할 수도 있음.
  • 사용 가능한 지표 보기

경보

  • 경보는 지정한 기간에 단일 지표를 감시하고 시간에 따른 임계값에 대한 지표 값을 기준으로 지정된 작업을 하나 이상 수행
    • 이 작업은 Amazon SNS 주제 또는 Auto Scaling 정책에 전송되는 알림으로, 대시보드에 경보를 추가할 수도 있음
  • 경보는 지속적인 상태 변경에 대해서만 작업을 호출합니다.
    • CloudWatch 경보는 단순히 특정 상태에 있다고 해서 작업을 호출하지 않으며,
    • 상태가 변경되어 지정된 기간 수 동안 유지되어야 한다.
  • Amazon CloudWatch 경보 사용 및 그래프의 지표에서 경보 생성

2. AWS CloudWatch 시작하기

처음 Overview에서는 CloudWatch-Defualt 라는 대시보드가 없을 경우, 아래와 같은 메뉴얼이 보여진다.


2.1 모든 AWS 서비스의 주요 지표 살펴보기

  • Overview > 개요 > 교차 서비스 대시보드를 클릭

  • 각 서비스별 기본 지표들을 조회 가능


2.2 단일 서비스의 대시보드를 조회하고 싶은 경우

  • 위 사진에서 보이는 파란 글씨의 “{서비스명} 대시보드 보기”를 클릭하거나

  • Overview > 개요 > 서비스 대시보드를 클릭

  • 단일 서비스의 기본 지표 조회 화면 (아래 사진은 EC2 서비스 클릭 시)


3. 기본 대시보드 만들기

3.1 기본 대시보드 생성

  • CloudWatch 시작하기 > 기본 대시보드 생성

3.2 대시보드 이름 입력

  • 사용자 지정 대시보드 > 대시보드 생성 > 대시보드 이름 : CloudWatch-Default 입력

  • AWS CloudWatch User Guide에 의하면 CloudWatch 메인 화면에 대시보드를 나타내기 위해서는 CloudWatch-Default 혹은 CloudWatch-Default-ResourceGroupName 으로 명시해야 한다고 한다.


3.3 시각화 할 데이터 및 위젯 유형 선택

  • 시각화할 지표/로그/경보 중 원하는 유형을 선택

3.4 지표 선택 및 위젯 생성

  • 원하는 지표를 선택(데이터 유형 - 지표, 위젯 유형 - 행 선택시) > 이름 변경 > 위젯 생성

3.5 기본 대시보드 완성 화면

  • 3번 & 4번을 반복 후 완성된 기본 대시보드 예시

4. 경보 생성하기

위처럼 기본 대시보드를 만들었다면, CloudWatch Overview 화면은 아래와 같다.

경보를 설정할 경우 단일 지표를 감시하고 시간에 따른 임계값에 대한 지표 값을 기준으로 알림을 받을 수도 있다.


4.1 지표 선택

  • 경보 생성 > 원하는 지표 선택

4.2 집계할 통계/기간 및 임계값 선택

  • 집계할 통계/기간 및 임계값 유형/기준 선택 (아래는 RDS - DatabaseConnections 선택 시 화면)

임계값 유형 : 정적 임계값 설정시 → 정적 값을 기준으로 경보 생성

임계값 유형 : 이상 탐지 선택시 → 경보 생성 후 이상 탐지 모델이 생성되며, 대역을 기준으로 경보 생성


4.3 작업 구성

  • 경보 상태 트리거를 선택한 뒤, 알림을 전송할 SNS 주제를 선택 (필수값이 아니므로 제거 가능)
    - 아래 예시는 AWS SNS를 사용중임을 가정한 선택 예시입니다.

  • 이외에도 작업을 생성할 수 있음.


4.4 경보 이름 및 설명 추가

  • 설명 작성 시, 마크다운 문법을 사용한다.

4.5 경보 생성 완료시 화면


4.6 설정한 경보 조건 만족시, 발생한 알림


4.7 Slack 알람 화면


5. AWS 서비스 별 권장 경보

AWS : CloudWatch 권장 경보 메뉴얼을 참고하였으며, 아래에서 모든 경보를 설명하지는 않습니다.


5.1 Amazon DymanoDB

  • AccountProvisionedReadCapacityUtilization
    • 계정의 읽기 용량이 프로비저닝된 한도에 도달하는지 여부를 감지
    • 통계: Maximum
    • 권장 임곗값: 80.0
    • 임곗값 정당화: 임곗값을 80%로 설정하면 최대 용량에 도달하기 전에 계정 한도 상향 조정과 같은 조치를 실행하여 제한을 방지할 수 있습니다.
  • AccountProvisionedWriteCapacityUtilization
    • 통계: Maximum
    • 권장 임곗값: 80.0
    • 임곗값 정당화: 임곗값을 80%로 설정하면 최대 용량에 도달하기 전에 계정 한도 상향 조정과 같은 조치를 실행하여 제한을 방지할 수 있습니다.
  • ReadThrottleEvents
    • DynamoDB 테이블에 대해 제한이 발생하는 읽기 요청 수가 많은지 여부를 감지
    • 통계: Sum
    • 권장 임곗값: 상황에 따라 다름

5.2 Amazon EC2

  • CPUUtilization
    • 높은 CPU 사용률을 감지
    • 통계: Average
    • 권장 임곗값: 80.0
    • 임곗값 정당화: 일부 시스템의 경우 지속적으로 높은 CPU 사용률이 정상이고 문제로 표시되지 않을 수 있지만, 다른 시스템에서는 문제가 발생할 수 있습니다.
  • StatusCheckFailed
    • 시스템 상태 확인 실패와 인스턴스 상태 확인 실패를 비롯한 인스턴스의 근본적인 문제를 감지
    • 통계: Maximum
    • 권장 임곗값: 1.0
    • 임곗값 정당화: 상태 확인이 실패하면 이 지표의 값은 1입니다. 임곗값은 상태 확인이 실패할 때마다 경보가 ALARM 상태가 되도록 설정됩니다.

5.3 Amazon ElastiCache

  • CPUUtilization
    • ElastiCache 호스트의 높은 CPU 사용률을 감지하는 데 사용
    • 통계: Average
    • 권장 임곗값: 상황에 따라 다름
    • 임곗값 정당화: 임곗값을 애플리케이션의 중요한 CPU 사용률 수준을 반영하는 백분율로 설정합니다.
      • Memcached의 경우 엔진은 최대 num_threads 코어를 사용할 수 있습니다.
      • Redis의 경우 엔진은 대부분 단일 스레드이지만 I/O 가속화를 위해 가능한 경우 추가 코어를 사용할 수 있습니다.
      • 대부분의 경우 임곗값을 사용 가능한 CPU의 약 90%로 설정할 수 있습니다.
      • Redis는 단일 스레드이기 때문에 실제 임곗값은 노드 총 용량의 일부로 계산해야 합니다.
  • CurrConnections
    • 경보를 통해 ElastiCache 클러스터의 성능 및 안정성에 영향을 미칠 수 있는 높은 연결 수를 식별
    • 통계: Average
    • 권장 임곗값: 상황에 따라 다름
    • 임곗값 정당화: 이 경보의 권장 임곗값은 클러스터의 허용 가능한 연결 범위에 따라 크게 달라집니다. -
      • ElastiCache 클러스터의 용량 및 예상 워크로드를 검토하고, 정기적인 사용 중 과거 연결 수를 분석하여 기준을 설정한 다음 그에 따라 임곗값을 선택합니다.
      • 각 노드는 최대 65,000개의 동시 연결을 지원합니다.

5.4 Lambda

  • Errors
    • 함수 호출 시 오류 수가 많은 경우를 감지
    • 통계: Sum
    • 권장 임곗값: 상황에 따라 다름
    • 임곗값 정당화: 임곗값을 0보다 큰 수로 설정합니다.
      • 정확한 값은 애플리케이션의 오류 허용 오차에 따라 달라질 수 있습니다.
      • 함수가 처리하는 호출의 중요도를 이해해야 합니다.
      • 일부 애플리케이션의 경우 어떠한 오류도 허용되지 않을 수 있지만 다른 애플리케이션에서는 일정한 오차 범위를 허용할 수 있습니다.
  • Throttles
    • Lambda 함수에 대해 많은 수의 제한된 간접 호출 요청 수를 감지
      • 제한으로 인해 요청이 계속 거부되는지, 지속적인 제한을 피하기 위해 Lambda 함수 성능을 개선하거나 동시성 용량을 늘려야 하는지를 파악해야 합니다.
    • 통계: Sum
    • 권장 임곗값: 상황에 따라 다름
    • 임곗값 정당화: 임곗값을 0보다 큰 수로 설정합니다.
      • 정확한 임곗값은 애플리케이션의 허용 오차에 따라 달라질 수 있습니다.

5.5 Amazon RDS

  • CPUUtilization
    • 매우 긴 응답 시간과 시간 초과를 방지하기 위해 지속적으로 높은 CPU 사용률을 탐지
    • 통계: Average
    • 권장 임곗값: 90.0
    • 임곗값 근거:
      • CPU 사용률이 무작위로 급증해도 데이터베이스 성능이 저하되지는 않지만 CPU가 계속 높게 유지되면 향후 데이터베이스 요청에 방해가 될 수 있습니다.
      • 전체 데이터베이스 워크로드에 따라 RDS/Aurora 인스턴스의 CPU가 높으면 전체 성능이 저하될 수 있습니다.
  • DatabaseConnections
    • 이 경보는 최대 DB 연결 수에 도달했을 때 연결이 거부되는 것을 방지하는 데 사용
      DB 인스턴스 클래스를 자주 변경하는 경우 메모리와 기본 최대 연결 수가 변경되므로 이 경보는 사용하지 않는 것이 좋습니다.
    • 통계: Average
    • 권장 임곗값: 상황에 따라 다름
    • 임곗값 근거: 허용되는 연결 수는 DB 인스턴스 클래스의 크기 및 프로세스/연결과 관련된 데이터베이스 엔진별 파라미터에 따라 달라집니다. 데이터베이스의 최대 연결 수의 90~95% 사이 값을 계산하고 해당 결과를 임곗값으로 사용해야 합니다.
  • FreeableMemory
    • 메모리 부족으로 인한 연결 거부를 방지하는 데 사용
    • 통계: Average
    • 권장 임곗값: 상황에 따라 다름
    • 임곗값 근거: 워크로드 및 인스턴스 클래스에 따라 임곗값을 다르게 설정하는 것이 적절할 수 있습니다. 가용 메모리가 장기간 동안 전체 메모리의 25% 미만으로 떨어지지 않는 것이 좋습니다.
      • Aurora의 경우 임곗값을 5%에 가깝게 설정할 수 있습니다.
      • 지표가 0에 가까울수록 DB 인스턴스가 최대한 스케일 업되었음을 의미하기 때문입니다.
  • ReadLatency
    • 긴 읽기 지연 시간을 탐지하는 데 사용
    • 통계: p90
    • 권장 임곗값: 상황에 따라 다름
    • 임곗값 정당화: 이 경보의 권장 임곗값은 사용 사례에 따라 크게 달라집니다.
      • 읽기 지연 시간이 20밀리초보다 길면 조사가 필요할 수 있습니다.
      • 애플리케이션의 읽기 작업 지연 시간이 길어질 수 있는 경우 더 높은 임곗값을 설정할 수도 있습니다.

5.6 Amazon S3

  • 4xxErrors
    • 일반적인 4xx 오류 발생률에 대한 기준을 만드는 데 사용
    • 통계: Average
    • 권장 임곗값: 0.05
    • 임곗값 정당화: 권장 임곗값은 전체 요청의 5% 이상에서 4XX 오류가 발생하는지 감지하는 것입니다.
      • 임곗값을 너무 낮게 설정하면 경보가 너무 민감해질 수 있습니다. 허용 가능한 수준의 4XX 오류를 고려하여 요청 로드에 맞게 임곗값을 조정할 수 있습니다.
  • 5xxErrors
    • 5xx 오류로 인해 애플리케이션에 문제가 발생하는지 감지
    • 통계: Average
    • 권장 임곗값: 0.05
    • 임곗값 정당화: 전체 요청의 5% 이상에서 5XXError가 발생하는지 감지하도록 임곗값을 설정하는 것이 좋습니다.

5.7 Amazon SNS

  • NumberOfNotificationsFailed
    • 실패한 SNS 메시지 수가 너무 많을 때 이를 감지
    • 통계: Sum
    • 권장 임곗값: 상황에 따라 다름
    • 임곗값 정당화: SQS, Lambda 또는 Firehose 구독만 있는 주제의 경우 실패한 알림 수는 0이어야 합니다.
  • SMSSuccessRate
    • SMS 메시지 전송 실패를 탐지
    • 통계: Average
    • 권장 임곗값: 상황에 따라 다름
    • 임곗값 정당화: SMS 메시지 전송 실패에 대한 허용 한도에 맞춰 경보 임곗값을 설정합니다.

5.8 Amazon SQS

  • ApproximateAgeOfOldestMessage
    • 대기열에 있는 가장 오래된 메시지의 수명을 감시
      • 메시지가 처리되기 전에 삭제되는 것을 방지하려면 잠재적 독약 메시지를 차단하도록 DLQ(Dead Letter Queue)를 구성하는 것이 좋습니다.
    • 통계: Maximum
    • 권장 임곗값: 상황에 따라 다름
    • 임곗값 정당화: 과거 데이터를 사용하여 평균 메시지 처리 시간을 계산한 다음, 임곗값을 대기열의 소비자가 예상한 최대 SQS 메시지 처리 시간보다 50% 더 높게 설정할 수 있습니다.
  • ApproximateNumberOfMessagesVisible
    • 활성 대기열의 메시지 수가 너무 많아 소비자가 메시지를 처리하는 속도가 느리거나 메시지를 처리할 소비자가 충분하지 않은지 여부를 감지
    • 통계: Average
    • 권장 임곗값: 상황에 따라 다름
    • 임곗값 정당화: 표시되는 메시지 수가 예상보다 많으면 소비자가 메시지를 예상 속도로 처리하지 못하고 있음을 나타냅니다. 이 임곗값을 설정할 때 과거 데이터를 고려해야 합니다.

5.9 번외) 우아한 형제들이 활용한 CloudWatch Aurora 메트릭 알람 구성



6. 로그

당장 저장하거나 감시해야 할 로그들이 없다고 판단되어 생략.

다만 로그 그룹의 경우, 기본적으로 보존이 만기없음으로 설정되어 있는데, 이는 곧 어마어마한 비용이 나올 수도 있다.

따라서, 보존 기간을 적절하게 설정해야 한다.
특정 로그를 반드시 저장해야 하는 일이 있다면 S3로 수동으로 옮겨서 저장하는 것도 방법이다.→ 이를 자동화하려면 람다를 이용할 수 있다.


8. 참고자료

profile
이동엽
백엔드 개발자로 등 따숩고 배 부르게 되는 그 날까지
이전 포스트

[AWS] 로드밸런서와 API 게이트웨이

다음 포스트

[AWS] RDS Exporter로 비용 최적화하기

0개의 댓글