Section 20. AWS 모니터링 및 감사: CloudWatch, X-Ray 및 CloudTrail - 1

AWS Monitoring

모니터링이 중요한 이유?

우리는 지금까지 AWS에 대해 배워오면서 어플리케이션을 배포하는 방법을 알아왔다.
그것도 안전하고, 자동적이고, 인프라 시설을 사용하면서 말이다.

하지만 우리의 어플리케이션이 배포가 되어도, 사용자들은 이 어플리케이션의 구축 방법에는 별로 관심이 없다.
오로지 그들은 작동 여부만 따진다.
그래서 어플리케이션의 지연이나 정지가 발생이 일어나기 전에 문제를 해결할 수 있도록 트러블 슈팅을 수행하는 것이 바람직하다.

Monitoring in AWS

• AWS CloudWatch를 통해 모니터링을 수행할 수 있다:
  • Metrics: 지표를 수집한다.
  • Logs: 로그를 수집하고 로그 파일을 분석한다.
  • Events: 특정 이벤트가 발생했을 때 알림을 보낸다.
  • Alarms: 지표 이벤트 및 이벤트 로그에 실시간으로 반응하여 알람을 보낸다.
• AWS X-Ray:
  • 애플리케이션 성능과 오류에 트러블 슈팅을 수행하는데 이를 통해 지연 시간을 살펴보고 오류를 실시간으로 확인할 수 있다.
  • 그리고 마이크로서비스 분산 추적 작업이 가능하다.
• CloudTrail:
  • API 호출에 대한 내부 모니터링을 수행할 수 있다.
  • 사용자가 AWS 리소스를 변경한 내용에 대한 감사를 수행할 수 있다.
• 위의 세 가지 기술을 이용하면 AWS를 확실하게 모니터링 할 수 있다!!

---

AWS CloudWatch

CloudWatch Metrics

• AWS의 모든 서비스에 대한 지표로 제공된다.
• 지표는 이름을 보고 구별할 수 있다. 트러블 슈팅도 이를 기반으로 해결된다.
• 지표는 이름공간에 속하며 배열을 갖는다.(배열의 예시로는 인스턴스 ID가 있다.)
• 지표당 최대 10개의 배열까지 선택할 수 있다.

EC2 Detailed monitoring

• EC2 인스턴스 지표는 5분마다 지표를 갖는다.
• 추가적으로 비용이 드는 세부 모니터링을 활성화 하면 1분마다 지표 데이터를 얻는다.
• 만일 ASG를 더욱 빠르게 스케일링 하고 싶다면 세부 모니터링을 활용하자!
• 프리티어에서는 10개의 세부 모니터링 지표를 가질 수 있다.

참고 | EC2 메모리 사용량은 기본적으로 RAM이 푸쉬되지 않으며 사용자 지정 지표로서 푸쉬되어야 한다.

CloudWatch Custom Metrics

• CloudWatch에 사용자 지정 지표를 보내고 정의할 가능성이 있다.
• 예시로 Ram에 메모리 사용량을 푸쉬하거나, CloudWatch나 어플리케이션에 로그인한 사용자 수 등이 있다.
• 이를 위해 PutMetricData라는 API를 호출한다.
• 세그먼트 지표에 배열이나 특성을 추가할 수 있다.
• StorageResolutionAPI 매개변수를 이용하여 지표 해상도로 두 가지 값을 지정할 수 있다.
  1. 표준 사용자 지정 지표 | 1분이나 60초에 한 번씩  푸쉬
  2. 고해상도 지표 | 1, 5, 10, 30초에 한 번씩 푸쉬하지만 비용이 높다.

참고 | 사용자 지정 지표는 푸시하는 방향이 미래든 과거든 상관이 없다. 즉 CloudWatch 오류가 발생하지 않는다는 것이다.

CloudWatch에 명령어를 넣어 지표의 값, 단위 바이트, 인스턴스 ID, 인스턴스 유형 등을 지정한다.

사용자 지정 지표를 통해 MyNameSpace가 나타나는 것을 볼 수 있다.

CloudWatch Logs

CloudWatch Log는 어플리케이션 로그를 AWS에 저장하기에 가장 좋은 장소이다!

 

개요

• 로그 그룹 | CloudWatch Log를 다루기 위해서는 로그 그룹을 정의해야 한다.
  • 원하는 이름으로 하면 되지만 주로 어플리케이션 이름으로 하곤 한다.
• 로그 스트림 | 로그 그룹에는 여러 로그 스트림이 있고, 어플리케이션 내 로그 인스턴스를 나타내거나 특정 로그 파일 혹은 컨테이너 를 나타낸다.
• 그 후에 로그 만료 정책을 정의하는데, 영원히 삭제되지 않게 할 수도 있고 1일에서 10년까지 기간을 선택할 수도 있다.
• CloudWatch Logs는 여러 목적지로 전송을 할 수 있다.
  • 이를 테면 Amazon S3, Kinesis Data Stream, Kinesis Data Firebase, AWS Lambda, OpenSearch가 있다.
• 기본적으로 모든 로그는 암호화되며, 원한다면 KMS 기반 암호화를 사용해 자신의 키로 암호화할 수도 있다!

CloudWatch로 보내는 로그 데이터의 종류(Sources)

• 로그 데이터는 보내는 방식은 SDK를 사용해서 로그를 보내거나, CloudWatch Logs Agent, CloudWatch Unified Agent를 사용할 수도 있다.
• Elastic Beanstalk는  어플리케이션에서 CloudWatch로 직접 로그를 수집한다.
• ECS는 컨테이너에서 CloudWatch로 로그를 보낸다.
• AWS Lambda는 함수 자체에서 로그를 보낸다.
• VPC Flow 로그는 VPC에 특화된 로그이다.(메타데이터, 네트워크, 트래픽 등등)
• API Gateway도 로그를 보낸다.
• CloudTrail은 필터 기반으로 로그를 보낸다.
• Route53은 서비스에 발생한 DNS 쿼리를 모두 기록한다.

CloudWatch 로그에서 로그를 쿼리하는 방법

 

간단하다. CloudWatch Logs Insights를 사용하면 된다!

CloudWatch Logs Insights를 통해 시각화를 만든 로그 라인을 볼 수 있음.

• 특징
  • CloudWatch Logs Insights에서 CloudWatch 로그 내 데이터를 검색하고 분석할 수 있다.
  • 해당 콘솔에는 샘플 쿼리도 많이 존재하기에 몇 개 이벤트에서 예외나 오류가 발생했는지도 살펴볼 수 있고 특정 IP를 찾는 등의 작업을 진행할 수 있다.
  • 여러 개 로그 그룹에 동시에 쿼리를 할 수 있다.
  • CloudWatch는 실시간 엔진이 아닌 쿼리 엔진이라는 것을 꼭 기억할 것.

CloudWatch Logs - S3 Export

CloudWatch Log는 여러 목적지로 보낼 수 있다.

 

1. Amazon S3

• 완료되는데 최대 12시간이 걸릴 수 있다.
• 이 내보내기를 실행하는 API 호출을 CreateExportTask라고 한다.
• 실시간이 아님을 명심!

CloudWatch Logs Subscriptions

 

실시간을 이용하려면 CloudWatch 로그 구독을 사용해야 한다. 특징을 알아보자

• 로그 이벤트를 실시간으로 스트림 받을 수 있으며, 처리하고 분석하는 것이 가능하다.
• 이 데이터를 여러 장소로 보내는데, Kinesis Data Streams, Kinesis Data Firehose나 람다 등이 있다.
• 해당 기술은 Subscription Filter를 정의하는데, 어떤 유형의 로그 이벤트를 목적지로 보낼지 정하는 역할을 한다.
  • 구독 필터는 Kinesis Data Streams로 보낼 수 있다.
  • Kinesis Data Firehose, Lambda로도 보낼 수 있음. 

구독 필터 사용.

로그 집계를 수행하는 방법

• CloudWatch 로그 구독의 핵심은 목적지를 사용해야 한다는 점이다. 해당 과정은 아래와 같다.
  • 발신자와 수신자 계정이 각각 있다고 가정하자.
  • 이때 CloudWatch 로그 구독 필터를 생성하고, 로그를 구독 목적지로 전송한다.
  • 그리고 목적지 액세스 정책을 가져와 첫 번째 계정이 실제로 목적지로 데이터를 전송하도록 허용한다.

참고 | 필터에 맞는 로그 이벤트를 보여주는 서비스 : live tail

 

live tail을 이용하여 실시간으로 올라온 로그를 확인 가능.

CloudWatch Agent

CloudWatch Logs for EC2

CloudWatch Agent를 사용하여 EC2 인스턴스로부터 로그와 지표를 불러들여 CloudWatch로 전송하는 방법을 알아보자.

기본적으로 로그를 EC2 인스턴스에서 CloudWatch로 전송할 수는 없다..
이를 위해서는 EC2 인스턴스에서 원하는 로그 파일을 푸시할 작은 프로그램인 Agent를 생성해야 한다.
EC2 안의 CloudWatch Logs Agent를 실행하여 CloudWatch Logs로 로그를 전송해 주는데 이때 EC2 인스턴스에 IAM역할이 있어야 한다!!

온프레미스 서버에도 Agent를 설치하여 로그 전송이 가능.

 

CloudWatch Logs Agent & Unified Agent

 

이전 버전인 CloudWatch Logs Agent와 최신 버전인 Unified Agent는 모두 온프레미스 서버의 가상 서버 EC2 인스턴스용이다.

이전 버전은 CloudWatch Logs에 로그를 전송하기만 하지만
최신 버전은 로그 전송 뿐아니라 추가 시스템 수준의 지표를 수집한다. 또한 SSM 파라미터 스토어를 사용하는 중앙 집중식 구성이 있다.

• CloudWatch Unified Agent - Metrics
  • Agent를 EC2 인스턴스랑 리눅스에 설치하면 지표를 수집할 수 있다. 지표들을 알아보자.
    1. CPU 지표를 수집하여 좀 더 세분화된 내용을 수집한다.
    2. 디스크 지표로는 사용 가능 여부나 용량을 보여준다.
    3. 디스크 IO에서는 읽기, 쓰기 바이트, IOPS 수 등을 보여준다.
    4. RAM은 사용 가능 여부 활성화, 용량, 캐시 등을 알려준다.
    5. Netstat은 TCP, UCP 연결 수, net 패킷, 바이트 등의 정보를 알려준다.
    6. 이 외에도 Processes, Swap Space를 수집한다.
  • CloudWatch Unified Agent를 사용하면 일반적으로 EC2 인스턴스를 모니터링하는 것보다 더 자세한 지표를 알 수 있다.

 

CloudWatch Logs Metric Filter

• 지금 살펴볼 내용은 필터 표현식을 통해 로그를 볼 수 있음을 알려준다.
  • 로그에서 특정 IP를 찾거나 로그에서 단어 오류 발생 수를 세는 등의 예시를 적용할 수 있다.
  • 이 메트릭 필터로 알람을 발생시킬 수도 있다.
• 중요한 점은 필터를 말들 때, 데이터를 소급해서 필터링하지 않는다는 것이다.
  • 즉 메트릭 데이터는 필터가 생성된 후에 발생하는 이벤트에 대해서만 푸쉬를 진행한다.

 

CloudWatch Alarms

알람은 모든 지표에 대해 알림을 트리거할 때 사용된다.
직접 다양한 옵션을 사용하여 복잡한 알람을 정의할 수가 있다!

경보의 3가지 상태에는
1. OK(알람이 트리거 되지 않은 상태)
2. INSUFFICIENT_DATA(데이터가 부족해 경보 상태를 결정할 수 없는 상태)
3. ALARM(임계값을 초과해 알림 전송이 예정된 상태)

기간은 알람이 지표를 평가하는 시간을 뜻한다.
매우 짧거나 길 수 있고 10초나 60초의 배수 등으로 설정할 수 있다.

 

CloudWatch Alarm Targets

알람의 대상에는 3가지가 있다.

1. EC2 인스턴스에 중지, 종료, 재부팅, 복구 동작을 수행
2. ASG를 트리거.
3. SNS 서비스에 알림을 전송

CloudWatch Alarms - Composite Alarms

CloudWatch 알람은 단일 지표를 지향하고 있다.
하지만 여러 지표를 활용하고 싶다면 복합 알람을 사용해야 한다.
복합 알람은 다른 여러 알람의 상태를 모니터링하고 있어서 각 알람이 서로 다른 지표에 의존하고 있을 수 있다.

AND와 OR 조건을 사용하여 검사하고 싶은 조건을 자유롭게 작성할 수 있다.
복합 알람은 알람 노이즈를 줄이는데 아주 유용하다.

EC2 인스턴스에 복합 알람을 사용한 예시

EC2 Instance Recovery

• 상태 점검
  • '인스턴스 상태'는 EC2 VM 점검과 기본 하드웨어를 점검하는 '시스템 상태'가 있다.
  • 위의 두 경우 모두 CloudWatch 알람을 정의할 수 있다.
  • 특정 EC2 인스턴스를 모니터링할 때 알람이 트리거되면 EC2 인스턴스 복구를 실행해 EC2 인스턴스를 다른 호스트로 옮기는 등의 작업을 할 수 있다.
  • SNS 주제에 알람을 전송해 EC2 인스턴스가 복구 중이라고 알릴 수 있다.

EC2 인스턴스 복구 작업

CloudWatch Alarm: 알아두면 좋은 사항

• CloudWatch Logs Metrics Filters에 알람을 생성할 수 있다.
• 알람 알림을 테스트하고 싶으면 set-alarm-state라는 CLI 요청을 실행하면 된다!

CloudWatch Synthetics Canary

구성 가능한 스크립트가 있고 그것이 CloudWatch에서 실행되면서 API와 URL, 웹사이트 등을 모니터링 할 수 있는 기술이다.
이 스크립트를 정의하면 프로그램상에서 고객의 작업을 똑같이 재현한다.

예시로 고객이 상품 페이지로 들어가 상품을 클릭해 장바구니에 담고 결제창에서 신용카드 정보를 입력한 뒤 결제가 제대로 되는지 확인한다고 할 때, CloudWatch Synthetics Canary로 이 전 과정을 재현하여 테스트 해볼 수 있는 것이다.
만일, 이 스크립트가 실패한다면 문제를 발견했다는 뜻인데 고객보다 먼저 발견하기에 이를 방지할 수 있다.

이 스크립트를 실행하면 위와 같은 문제를 해결할 뿐 아니라 일부 흐름을 파악할 수 있고 엔드포인트의 가용성과 지연 시간도 점검할 수 있고, 로드 시간 데이터는 물론 UI 스크린샷도 저장할 수 있다.

• 스크립트는 Node.js나 Python으로 작성되며 Synthetics Canary 안에서 구글 크롭 헤드리스 브라우저에 접근 가능하여 어떤 작업이든 할 수 있다.
• 스크립트는 일회성이나 엔드포인트 가용성을 점검할 때처럼 정기적으로 실행이 가능하다.

CloudWatch Syntheticcs Canary Blueprints

 

블루프린트라고 입문자들도 활용할 수 있는 것이 있다.

• Heartbeat Monitor | URL을 로드하고 스크린샷과 HTTP 아카이브 파일을 저장해 잘 작동되는지 점검한다.
• API Canary | REST API의 기본 읽기 쓰기 함수를 테스트한다.
• Broken Link Checker | 테스트 중인 URL 내부의 모든 링크를 검사한다.
• Visual Monitoring | Canary 실행 중 찍은 스크린샷을 이전에 찍은 기존 스크린샷과 비교한다.
• Canary Recorder | CloudWatch Synthetics Recorder과 함께 쓰여 웹사이트에서의 동작을 기록하고 그에 대한 스크립트를 자동으로 생성한다.
• GUI Workflow Builder | 로그인 양식 등을 갖춘 웹페이지에서 수행한 동작이 올바르제 작동되는지 식별한다.

---

Amazon EventBridge

Amazon EventBridge는 이전에 CloudWatch Event였다.
EventBridge로 할 수 있는 작업
1. Schedule | 클라우드에 작업을 스케줄링할 수 있다.
2. Event Pattern | 어떤 작업을 수행하는 서비스에 반응하는 이벤트 규칙을 생성한다.

EventBridge Rules

• Source에서 어떠한 이벤트가 발생하면, 해당 이벤트를 EventBridge에서 받아 JSON 문서를 생성한다.
• 생성된 문서는 여러 목적지로 전송된다.
• 사용 사례마다 다르게 나타난다.

EventBridge

종류

• 기본 이벤트 버스
  • AWS 서비스에서 이벤트를 기본 이벤트 버스로 보내는 원리이다.
• 파트너 이벤트 버스
  • AWS가 파트너와 결합된 형태이다.
  • 파트너 이벤트 버스에 이벤트를 직접 보낸다.
  • AWS 외부에서 발생하는 변경에도 계정 내에서 반응할 수 있는 특징이 있다.
• 사용자 이벤트 버스
  • 직접 이벤트 버스를 만들수 있다.
  • 사용자 이벤트 버스로 보내면 여러 목적지로 이벤트를 전송할 수 있다.

필터 덕분에 모든 이벤트를 보관할 수도 있는데, 이벤트를 보관하면서 영구 보관할 것인지 기간을 정할 것인지 설정할 수 있다.

이벤트 재현도 가능한데 트러블슈팅에 매우 유용하다.

Event Pattern과 Sample 이벤트가 매치하는지 확인..확인 결과 EC2가 실행 중이라 매치가 안되는 것을 확인할 수 있다.

참고

1. SandBox | 규칙을 만들지 않고도 샘플 이벤트로 이벤트 패턴을 테스트할 수 있는 서비스

 

Schema Registry

EventBridge는 다른 장소에서 많은 이벤트를 받는다.

• 보통 EventBridge는 버스의 이벤트를 분석하고 스키마를 추론한다.
• 스크마 레지스트리에서 스키마는 어플리케이션 코드를 생성할 수 있다. 그러면 이벤트 버스에서 데이터가 어떻게 구성되는지 미리 알 수 있게 된다.

Resource-based Policy

• 특정 이벤트 버스에 대한 권한을 관리하는 정책
• 예시로 특정 이벤트 버스가 다른 리전이나 계정의 이벤트를 허용하거나 거부할 수 있는 정책을 만들 수 있다.