[AWS] aws 강의 섹션 20-1 (CloudWatch, Event Bridge)

AWS Monitoring, TrobleShooting & Audit

AWS CloudWatch

• 클라우드 워치로는 지표를 수집할 수 있다.
• 모니터링을 위해 로그를 수집하고 로그 파일을 분석한다.
• 특정 이벤트가 발생했을 때 알림을 보내기도 한다.
• 특정 지표 및 로그에 실시간으로 반응해서 알림을 보내기도 한다.

AWS X-Ray

• 애플리케이션 성능과 오류에 트러블 슈팅을 수행한다.
• 지연 시간을 살펴보고 오류를 실시간으로 확인할 수 있다.
• 마이크로 서비스 분산 추적 작업이 가능하다.

AWS CloudTrail

• API 호출에 대한 모니터링을 수행한다.
• AWS 리소스 변경 내용에 대한 감사를 수행할 수 있다.

CloudWatch 지표

• AWS의 모든 서비스에 대한 metirc(성능 상태) 즉, 지표를 제공한다.
• Metric은 모니터링 하기 위한 변수(측정 항목이)다. (CPU Utilization, Networkln ,,)
  • 지표는 배열을 가질 수 있다. (ID, environment, 등등,)
  • 지표당 최대 10개의 배열을 선택할 수 있다.
    • 최대 10개의 인스턴스를 동시에 볼 수 있다.

[
  {ID: "i-12345678", environment: "prod", CPU 사용률: 25%},
  {ID: "i-87654321", environment: "dev", CPU 사용률: 40%},
  {ID: "i-11223344", environment: "test", CPU 사용률: 15%}
]

• 지표는 타임스탬프를 가지며, 지표 대시보드를 생성할 수 있다.
• AWS에서 기본적으로 제공하는 지표는 두 가지의 방식으로 지표가 수집된다.
  • Standard (default)
    • 5분 간격으로 데이터를 수집
  • Detailed Monitoring 
    • 1분 간격으로 데이터 수집 
    • 추가 비용 발생

CloudWatch - Custom Metric

• 기본적으로 제공되는 값 외에 다른 지표를 설정할 수 있다.
  • 메모리 사용량, Disk 잔량, 로그 숫자 등등,,
• 커스텀 지표를 만들기 위해선 PutMetricData라는 API를 호출해야 한다.
• 지표를 세분화 하기 위해 속성을 사용할 수 있다.
  • 속성이란: 지표에 추가적인 정보를 더해 지표를 더 세밀하게 구분할 수 있는 속성이다.
    예를 들어 ID, 환경, 리전 등의 차원이 될 수 있다.
  • 세분화: 속성을 기준으로 데이터를 나누는 것을 의미한다.
    즉, 차원을 사용해 지표를 그룹으로 나누어 모니터링 할 수 있다는 뜻이다. 
    • 예를 들어, 개발 환경이라는 속성을 추가해서 속성 별로 세분화 할 수 있다.
      • prod 별, dev 별 지표 확인 같은 느낌
  • 속성은 원하는 무엇이든 설정할 수 있다.
• Metric resolution (StorageResolution Api parameter - two possible value)
  • 지표 해상도: 지표 데이터를 얼마나 자주 수집하고 기록할지를 결정하는 값이다.
  • 파라미터로 가능한 값은 두 가지가 있다.
    • Standard resoultion (default)
      • 1분 간격으로 지표 데이터를 수집하고 기록한다.
    • High resolution
      • 1/5/10/30 초 간격으로 지표 데이터를 수집하고 기록한다.
      • 추가 비용이 든다.
• 2주 전의 데이터를 보내거나 기록할 수 있고, 미래의 시간에 데이터를 기록할 수도 있는데,
  미래는 최대 2시간 까지 기록이 가능하다.
  
  즉, 2주전 ~ 2시간 후의 데이터를 클라우드 워치에 기록할 수 있다는 의미다. 
  지표를 그대로 수용한다. 
  
  지표를 AWS 실제 시간과 동기화 하려면 EC2 인스턴스 시간과 같은 시간을 사용하는지 잘 확인하자.

CloudWatch - Logs

• 클라우드 워치 로그는 애플리케이션 로그를 저장하기에 가장 좋은 장소다.
  • 로그 그룹: 로그의 집합이다. 하나의 애플리케이션에 대한 모든 로그를 관리하기 위한 컨테이너라고 생각하면 편하다.
  • 임의 이름 정해야 한다. 보통 애플리케이션 이름 많이 쓴다.
  • 로그 그룹에는 여러 개의 로그 스트림이 있다.
    • 로그 스트림: 애플리케이션 내 특정 부분에서 발생한 로그 데이터의 흐름이다.
      • 예를 들어, 하나의 애플리케이션이 여러 서버에서 실행되고 있다면, 
        각 서버에 대한 로그 스트림이 있을 수 있다.
      • 또는 특정 파일이나 컨테이너에서 발생하는 로그를 따로 관리하기 위해
        별도의 로그 스트림을 만들 수 있다.
  • 로그 삭제 정책: 로그가 보존되는 기간을 정의한다. 기간은 상관없다. 영구 보존도 가능하다.
  • 로그를 보낼 수 있는 목적지
    • S3
    • 키네시스 데이터 스트림
    • 키네시스 파이어 호스
    • 람다
    • 오픈서치
  • 기본적으로 모든 로그는 암호화 된다.
    • 원한다면 KMS 기반 암호화를 사용해 자신의 키로 암호화 할 수 있다.

CloudWatch Logs - Source

• SDK, cloudWatch Logs Agent, CloudWatch Unified Agent 등을 이용해 로그를 보낼 수 있다.
• 앨라스틱 빈스톡은 애플리케이션에서 직접 로그를 수집한다.
• ECS는 컨테이너에서 로그를 수집한다.
• 람다는 함수 자체에서 로그를 받은 후 보낸다.
• VPC Flow logs는 VPC에 특화된 로그다. 메타데이터, 네트워크 트래픽등을 보낸다.
• API gateway는 API 게이트웨이로 들어온 모든 요청을 클라우드워치로 보낸다.
• CloudTrail은 필터 기반으로 로그를 보낸다.
• Route53은 DNS 쿼리를 모두 기록한 후 보낸다.

CliudWatch Logs - Insights

• 클라우드 워치에서 로그를 쿼리하려면 어떻게 해야할까
  • 클라우드 워치 로그 인사이트를 사용하면 된다.
  • 로그 인사이트 내부에서 쿼리 기능으로 쿼리를 작성할 수 있다.
    • 자동으로 시각화된 결과를 얻게 된다.
    • 결과를 추출할 수도 있다.
• 클라우드 워치 로그 안에 들어있는 데이터를 검색하고 분석하는 서비스다.
  • 샘플 쿼리도 많다.
• 최근 25개의 이벤트 찾기, 몇 개의 예외나 오류가 발생했는지 찾기, 특정 ip 찾기 등등,,,
• 미리 만들어진 쿼리 언어를 제공한다.
• 쿼리를 작성할 수 있는 필드는 클라우드 워치 로그에서 자동으로 감지된다.
• 조건을 걸고 필터링, 통계 계산, 이벤트 정렬, 이벤트 수 제한 등등이 가능하다.
• 여러 개 그룹에 동시에 쿼리를 날릴 수도 있다.
  • 다른 계정에 있어도 가능하다.
• 실시간 엔진이 아닌 쿼리 엔진이라는 것을 기억하자.
  • 기록된 데이터만 가지고 쿼리를 한다는 의미다.

CloudWatch Logs - S3로 보내기

• 배치로 모든 로그를 S3로 보낸다.
• 완료되는데 최대 12시간이 걸릴 수 있다.
• 이 내보내기를 실행하는 API 호출을 CreateExportTask라고 한다.
• 배치 작업이기 때문에 실시간이 아니다.
  • 실시간 작업은 로그 구독을 사용해야 한다.

CloudWatch Logs - Subscription

• 로그 이벤트를 실시간으로 받을 수 있다.
  • 키네시스 테이터 스트림, firehose, 람다 등으로 보낼 수 있다.
• 구독 필터링:
  • 어떤 유형의 로그를 어떤 목적지로 보낼지 정의하는 것이다.

여러 계정과 여러 Region의 로그 통합

• 구독 필터 기능을 사용하면 서로 다른 계정, 리전에서 cloudwatch 로그를 가져와 통합할 수 있다.
• 특정 계정의 키네시스 데이터 스트림으로 보내면 된다.
  • 이후 firehose로 보내 S3에 저장할 수도 있다.

CloudWatch Logs Subscription

• Cross account Subscription - 다른 계정으로 로그 보내기
  • 다른 계정이나 지역으로 로그를 보내기 위해서 Subscription Destination을 사용해야 한다.
  • 다른 지역의 구독 목적지로 로그를 보낸후 거기서 키네시스로 데이터를 보내는 것이다.
    • 역시 액세스 정책이 필요하다.

이를 통해 다른 계정으로 보내는게 가능하다.

 

CloudWatch Logs for EC2

• 클라우드 워치 에이전트를 사용하여 EC2 인스턴스로부터 로그와 지표를
  클라우드 워치로 보낼 수 있다.
• 기본적으로 로그를 EC2 인스턴스에서 클라우드 워치로 전송할 수는 없다.
  • 이를 위해서는 EC2 인스턴스에서 로그파일을 푸시할 에이전트를 설치해야한다.
  • 따라서 EC2 인스턴스에 CloudWatch Log Agent를 실행하면
    CloudWatch Logs로 로그를 보낼 수 있다.
    • 이 때 EC2 인스턴스에 IAM 역할이 있어야 한다.
    • 클라우드 워치 로그 에이전트는 온프레미스 서버에도 설치가 가능하다.

CloudWatch Logs - Agent 종류

• 두 가지 종류의 에이전트가 존재한다.
  • 둘 다 온프레미스 서버, EC2 서버 모두 적용 가능하다.
  • CloudWatch Logs AGent
    • 오래된 버전이다 
    • 로그를 전송하는 기능만 있다.
  • Unified Agent
    • 최신 버전이다.
    • 시스템 수준의 지표를 추가로 수집할 수 있다.
      • 램, 프로세스 등, ,,
    • SSM 파라미터 스토어를 사용한다. 
      
      • 에이전트의 설정과 구성 정보를 중앙에서 안전하게 관리할 수 있다. 

CloudWatch Unified Agent - Metrics

• EC2 서버에서 직접적으로 지표를 수집한다. 
  • CPU (active, guest, idle, system, user, steal) 등을 수집
  • Disk, Disk I/O
  • RAM
  • Network State
  • Processes (프로세스 수, 활성 상태 등..)
  • Swap Space
• 아무튼 더 많은 지표를 확인할 수 있다.

CloudWatch Logs - Metric Filter

• 필터를 통해 로그를 볼 수 있다.
  • 예를 들어, 로그에서 특정 ip를 찾거나
  •  ERROR 발생 수를 센다거나 하는 기능이다.
    • 이러한 메트릭을 만들 수 있기 때문에 메트릭 필터라고 부른다.
• 필터가 생성된 후 발생하는 이벤트에 대해서만 푸시한다.
  • 즉 필터가 만들어지고 난 이후의 일만 메트릭에 걸러져 기록된다는 것이다.
• 매트릭 필터의 차원을 3개까지 지정할 수 있다.
• 예를 들어, 클라우드 워치의 로그에 메트릭 필터를 건다
  • 에러가 5번 발생하면 알림을 가게 만들고 해당 알림을 SNS로 보내 이메일로 보낼 수 있다.

CloudWatch Alarms

• 모든 지표에 대해 알림을 발생시킬 때 사용된다.
  • 여러가지 옵션을 사용해 복잡한 경보를 정의할 수 있다.
• 알림에는 세 가지 상태가 있다.
  1. OK (경보가 발생하지 않은 상태)
  2. Insufficient_data (데이터가 부족해 경보 상태를 결정할 수 없는 상태)
  3. ALARM (임곗값을 초과해 알림 전송이 예정된 상태)
• Priod:
  • 지표를 평가하는 시간 간격을 뜻한다
  • High resolution Custom Metric에는 똑같이 10초, 30초 60초로 평가 간격을 정할 수 있다.

CloudWatch Alarm Targets

• 알림이 가는 대상
• EC2인스턴스
  • 인스턴스에 중지, 종료 재부팅, 복구 동작을 수행한다.
• Trriger ASG
  • 오토 스케일링 동작을 트리거 한다.
  • 스케일 아웃, 스케일 인이 있다.
• SNS
  • SNS에 알림을 전송한다.
  • 람다 함수나, 이메일을 보내는 등으로 설정할 수 있다.

 

CloudWatch Alarms - Composite Alarms

복합 경보

• 클라우드 워치는 단일 지표를 이용한다.
• 여러 지표를 이용해 알림을 울리고 싶다면 복합 경보를 사용해야 한다.
  • 복합 알림는 다른 여러 알림의 상태를 모니터링 하는 것이다.
• AND, OR 조건을 사용할 수 있다.
• CPU 사용률이 높고 네트워크 트래픽이 낮을 때만 알림을 울려라 하는 식으로 설정할 수 있다.

EC2 Instance Recovery

• Status Check
  • Instance Status: EC2를 체크
  • System status: 하드웨어를 체크 
• 여러 상태를 체크하다 임계값을 넘는다면 EC2 복구 잡업을 실행해서 EC2 인스턴스를 다른 호스트로 옮기는 등의 
  작업을 수행할 수 있다.
• 복구된 인스턴스는
  • Private IP, Public IP, Elastic IP, metadata, placement group 가 모두 동일하다

CloudWatch Alarm: Good to know

• 클라우드 워치 로그 지표 필터에 경보를 생성할 수 있다.
  • 즉 수집한 로그에서 ERROR 수 세기 같은 로그 지표 필터를 설정하고
  • 5개를 임계값으로 정한 후, 5개가 넘으면 SNS로 메시지를 전송하는 방식이다.
• 알림을 테스트해보고 싶으면 CLI를 사용하면 된다.
  • 임곗값을 초과하지 않은 상황이지만 일부러 경보를 울리는 것이다.
  • aws cloudwatch set-alarm-state --alarm-name "myalarm" --state-value ALARM --state-reason "testing purpose"

CloudWatch Systhetics Canary

• API, URL, 웹사이트 등을 모니터링 할 수 있는 스크립트를 만들 수 있다.
• 스크립트를 정의하면 그 스크립트가 프로그램상에서 고객의 작업을 똑같이 재현한다.
  • 예를 들어, 고객이 상품 페이지로 들어가 상품을 클릭해 장바구니에 담고 
    결제창에서 신용카드 정보를 입력한 뒤 제대로 결제되는지 확인한다고 할 때
  • 클라우드 동기화 카나리가 이 모든 과정을 스크립트로 입력 받아 똑같이 재현할 수 있는 것이다.
  • 즉, 테스트 용도로서 활용 가능하다.
• 이 외에도, 엔드포인트의 가용성과 지연 시간도 점검할 수 있고, 로드 시간 데이터는 물론 UI 스크린샷도 저장할 수 있다.

예시

• 클라우드 워치 카나리가 EC2 인스턴스를 감시하고 있다가. 
• 만약 테스트가 실패할 경우, 클라우드 워치 경보가 트리거 되고 람다 함수가 호출 되면서
• 라우트 53에 있던 DNS 레코드를 다른 인스턴스로 변경시키면
• 문제가 생긴 인스턴스를 자연스럽게 정상 작동하는 인스턴스로 바꿀 수 있다.

카나리의 스크립트는 노드js나 파이썬으로 작성된다.

 

스크립트는 일회성 또는 정기적 실행 두 가지중 하나를 선택할 수 있다.

 

CloudWatch Synthetics Canary - Blueprints

블루 프린트란 서전 정의된 코드 템플릿을 의미한다.

• heartbeat Monitor - url을 로드하고 스크린샷과 http아카이브 파일을 저장해 모든 게 잘 작동하는지 점검한다.
• API Canary - api의 기본 읽기 쓰기를 테스트한다.
• Broken link Checker - 테스트 중인 url 내부의 모든 링크를 테스트 한다.
• visual monitoring - 카나리 실행 중 찍은 스크린샷을 이전에 찍은 스크린샷과 비교한다.
• canary Recorder - 클라우드 워치 synthetics recorder와 함께 쓰여 웹사이트에서의 동작을 기록해고
  그 해동을 바탕으로 스크립트를 자동으로 만들어 준다. 
• GUI workflow builder - 로그인 양식 등을 갖춘 웹페이지에서 수행한 동작이 올바르게 작동하는 지를 
  검증한다.

 

EventBridge

• 아주 다양한 작업을 할 수 있다.
  • 클라우드에 작업을 스케쥴링 할 수 있다. (스크립트를 통해서)
    • 한 시간마다 람다 함수를 트리거 한다고 하고 
      람다 함수는 스크립트를 실행하는 방식이다.
    • 시간마다, 이벤트 브릿지에서 람다함수를 트리거 하는 것이다.
  • 시간 이외에도 여러가지 트리거 기준을 정할 수 있다.
    • 예를 들어, IAM 유저가 콘솔에서 로그인하는 이벤트에 반응할 수 있다.
    • 이를 sns로 보내서 이메일 알림을 받는다면 좋은 보안 기능이 될 것이다.
  • 목적지가 여러 개라면 sns나 큐에 메시지를 보내면 된다.

이벤트 브릿지 - 버스의 종류

• 이벤트 브릿지는 default event bus라고 불리는 것에 기본적으로 이벤트를 보낸다. 
  • aws 서비스에서 이벤트를 기본 이벤트 버스로 보내는 거다
• 파트너 이벤트 버스라는 것도 있다.
  • aws가 파트너 업체와 협력한 것이다.
  • zendesk, datadog 등에서 이벤트를 보낼 수 있다.
• 마지막으로 사용자 이벤트 버스가 있다. 
  • 사용자가 직접 버스를 만들 수 있다.
  • 사용자가 직접 만든 애플리케이션에서 이벤트 브릿지로 이벤트를 보내기 위해 사용한다.
• 이벤트 버스로 보낸 모든 이벤트를 보관할 수도 있다. 
  • 영구 보관도 가능하며, 기간을 설정할 수도 있다.
  • 이렇게 보관된 이벤트는 나중에 재사용이 가능하다.
  • 나중에 이벤트를 재사용 해서 트러블 슈팅하는 데 매우 유용하다고 한다.

이벤트 브릿지 - schema Registry

• 스키마 레지스트리를 사용하면 이벤트 버스에 담겨오는 이벤트를 자동으로 분석해서 스키마를 생성한다.
  • 스키마는 데이터베이스의 스키마를 생각하면 된다.
• 이후 생성된 스키마를 바탕으로 자동으로 애플리케이션 코드도 작성할 수 있다.
• 나중에 이벤트의 형식이 달라질 수 있다. 이를 위한 버저닝도 존재한다.

이벤트 브릿지 - 리소스 기반 정책

• 특정 이벤트 버스의 권한을 관리하는 것이다.
  • 예를 들어, 다른 계정이나, 다른 리전에서 온 이벤트를 허용한다. 거부한다.
• 사용 사례로 aws 조직 내부에 중앙 이벤트 버스를 두는 것이다.
  • 모든 이벤트는 중앙 이벤트 버스를 통해 처리된다.
  • 중앙 이벤트 버스엔 다른 계정에서 이벤트를 받는 것을 허용하는 IAM Role을 만든다.
  • 이를 통해, 조직 내 모든 계정에 편하게 이벤트를 보낼 수 있다.