서비스간,네트워크간의 트래픽의 흐름, 즉 로그를 파악하기 위해 AWS CloudTrail,CloudWatch,Config 세가지의 서비스를 지원한다. 이번 포스팅에서는 그 중 CloudWatch에 대해서 다루어 볼 예정이다. 추가로 EventBridge에 대해서도 다루어 볼 것이다.
CloudWatch
AWS리소스의 메트릭스(지표)를 수집하고 수정,시각화 하는 서비스이다. 모든 리소스는 CloudWatch로 자신의 매트릭스를 전송하며 , 매트릭스는 CPU활성화율, S3버킷용량,EBS의 IOPS, DynamoDB의 읽기/쓰기 용량등이 있다. CloudWatch는 이 메트릭스를 수집해 특정 조건을 만족하면 CloudWatch Alarms을 통해 알람을 울리고 알람에 해당하는 액션을 수행할 수 있다.
CloudWatch Metrics
CloudWatch는 EC2와 같은 AWS리소스에서 매트릭스(지표)를 수집해 이것을 통해 알람과 액션을 한다. 이러한 매트릭스는 CloudWatch의 네임스페이스에 저장한다. 쉽게말해 네임스페이스는 컨테이너와 같은 역할을 한다. 예를 들어 EC2에서 CloudWatch에 매트릭스를 보내면 네임스페이스에서 AWS/EC2의 형식으로 저장한다. 하지만 예를 들어 다른 EC2에서 보내온 매트릭스는 이런 형식으로는 구분하지 못하기 때문에 이름/값 쌍으로 이루어진 차원이라는 옵션으로 구분한다.
예를 들어 AWS/EC2에 저장하되, InstanceId라는 차원이름과 인스턴스 리소스 식별자 값을 추가로 저장한다.
기본모니터링 / 상세모니터링
AWS리소스들은 CloudWatch에 얼마의 주기로 자신의 Metrics를 보낼까? 이것을 결정하는 것이 기본모니터링 / 상세모니터링이다.
- 기본 모니터링 : 5분주기마다 지표를 보낸다.
📌 EC2는 기본 모니터링을 선택해도 하이퍼바이저의 종류에 따라 달라진다.
- Xen하이퍼바이저 : 5분간격의 마지막에 해당 기간의 성능 지표 평균값을 전송한다.
예를 들어, 13:00~13:05 간격이고 성능 지표가 25,50,75,80,10%단위로 측정되었다면,
평균값인 48%를 13:00의 타임스탬프 값으로 전송한다. - Nitro하이퍼바이저 : 5분간 매분마다 지표를 전송하지만 각 지표는 바로 앞의 값과 평균이 되어 전송한다.
예를 들어, 13:00의 지표가 25이고 13:01의 지표가 50으로 기록되었으면, 37.5%을 13:00의 타임스탬프 값으로 전송한다.
- Xen하이퍼바이저 : 5분간격의 마지막에 해당 기간의 성능 지표 평균값을 전송한다.
- 상세 모니터링 : 매분마다 자신의 매트릭스를 전송하며 대부분 리소스가 상세모니터링도 지원하다.
📌 EBS의 io1은 default로 상세모니터링을 제공한다.
CloudWatch Logs
AWS리소스와 비 AWS리소스의 로그를 수집할 수 있으며, 검색기능과 커스텀 메트릭스의 추출도 가능하다. Cloudtrail은 리소스에서의 트래픽의 흐름과 같은 좀더 세부적인 로그를 기록한다면,CloudWatch Logs는 애플리케이션, 리소스 자체의 활동기록을 수집,저장한다.
CloudTrail에서 수집한 로그데이터를 트레일이나 이벤트 히스토리에 저장하는데 이것은 검색기능이 없기때문에 CloudWatch Logs로 보내 검색기능을 활용하기도 한다. 다만 전송시에 유의 사항으로 256KB이상의 로그이벤트는 전송할 수 없기때문에 이것을 주의해야 한다.
💡 추가로 이렇게 CloudWatch Logs로 보낸 로그는 검색은 가능하더라도 JSON형식으로 작성되기 때문에 사용자가 읽기 어렵다는 단점이 있다. 이것을 해결하기 위해 S3로 보내 Athena를 이용한 강력한 쿼리를 날려 사용자가 원하는 형태로 포맷화시켜서 읽기 쉽게 할 수도 있다.
로그 스트림 / 로그 그룹
CloudWatch Logs의 개별 로그데이터는 로그 스트림에 저장되며, 로그그룹으로 이 로그 스트림을 비슷한 유형끼리 그룹으로 묶어서 관리 할 수 있다. 개별 로그데이터는 삭제할 수 없으며, 로그 스트림은 삭제가 가능하다.
📌 로그그룹의 보관기간은 최소 1일에서 10년 또는 무기한으로 설정 가능하다.
📌 로그스트림은 로그그룹의 보관기관에 종속된다.
매트릭 필터
매트릭 필터를 사용해 사용자가 원하는 매트릭을 추출해 낼 수 있다. 숫자형 매트릭은 매트릭 필터를 통해서 추출해내는 것이 가능하지만 IP주소와 같은 문자열 매트릭은 추출할 수는 없고 일치하는 요소를 찾고 추적하는 것만 할 수 있다.
CloudWatch Agent
기본적인 매트릭스말고도 메모리 활성화율 등, EC2가 기본적으로 생성하지 못하는 매트릭스를 생성해서 수집가능하다. 이러한 매트릭스를 커스텀 매트릭스라 하며, 커스텀 네임스페이스에 저장된다.
CloudWatch Alarm
특정 지표를 모니터링하다가 값의 변화가 생기면 알람,인스턴스의 재시작 , AutoScailing등의 액션을 수행한다
데이터포인트 / 기준치
충분한 데이터포인트가 쌓이고 특정 기준치를 충족시켰을 때 알람을 울리고 액션을 취한다.
- 데이터 포인트 : 매트릭의 평균값이나 백분율을 통계량으로 설정해 통계치를 분석한다.
15분의 시간동안 Average통계량을 선택하면 5분단위로 세개의 데이터포인트를 수집해서 평균값을 계산한다.
백분위를 통계량으로 선택하고 백분위 p80으로 설정한경우 통계적 유의미성을 얻기위해 10/(1-.8) 또는 50개의 데이터 포인트를 수집해야 한다.
📌만약 p50아래로 설정한 경우 통계적 유의미성을 얻기위해 10/데이터포인트로 계산이 된다.
- 기준치 : 알람이 울리는 데이터포인트의 값을 기준치로 설정한다. 크게 정적 기준치와 이상점 감지 두가지가 있다.
정적 기준치 : 특정 값이나 조건을 이용해 정한다.
예를 들어 , CPU활성화율 >=50으로 설정하면 50이상이 되었을 때 알람이 울린다.
이상점 감지 : 밴드(Band)라 불리는 범위를 벗어났을 때 알람이 울린다.
📌 Band는 표준편차를 이용해 정의한다.
예를 들어, 이상점 감지 기준치를 2로 설정하면 평균값을 기준으로 표준편차가 2를 넘어설 때 알람이 울린다.
알람 상태
알람에는 크게 세가지 상태가 있다.
- ALARM : 데이터포인트가 알람조건에 부합하고 기준치를 초과한 경우
- OK : 데이터포인트는 조건에 부합하지 않지만, 기준치를 초과한 경우
- INSUFFICIENT_DATA : 알람을 울릴 수 있을 정도의 충분한 데이터포인트를 수집하지 못한 경우
액션
각 알람의 상태마다 액션을 부여할 수 있으며 , 알람상태의 전환에도 액션을 부여한다.
📌ALARM상태 외에도 OK나 INSUFFICIENT_DATA상태에도 액션을 부여할 수 있다.
- SNS를 이용한 알림 : SNS서비스를 구독한 리소스 즉, 퍼블리셔라고 부르는 구독개체에 알림을 보낸다.
구독개체는 프로토콜과 엔드포인트로 구성된다.SQS(프로토콜) + 큐(엔드포인트)
HTTP / HTTPS(프로토콜) + URL(엔드포인트)
📌 SNS는 일종의 게시판같은 역할을 하며 , 각종 데이터,알림을 수집하면 SNS뒤에 자신을 구독하고 있는 구독개체들에게 데이터,알림을 전송한다.
💡 SNS에 대해서는 추후 포스팅에서 자세히 다루어 볼 예정이다.
- Autoscailing 액션 : EC2인스턴스에서 수집하는 매트릭스가 특정 데이터 포인트 / 기준치를 초과하면 알림이 울리고 해당 액션으로 자동확장을 통해 인스턴스를 수축 / 확장 한다.
- EC2액션 : 인스턴스의 중지, 복구, 폐쇄, 재부팅을 가능하게 해주는 액션이다. 크게 두가지로 나누어진다.
StatusCheckFailed_Instance : 이 지표가 1이 반환되면 메모리 소진, 파일시스템 오류, 네트워크 오류 등을 의미하며, 인스턴스의 재부팅을 통해서 해결 가능하다.
StatusCheckFailed_System : 이 지표가 1이 반환되면 하드웨어 고장, 하이퍼바이저 오류등 AWS가 개입해야하는 문제가 발생 한 것이며 새 인스턴스를 만들어 복원해야 한다.
📌 인스턴스의 재부팅으로 해결 못한다.
Amazon EventBridge
CloudWatch Alarms는 리소스의 성능 지표를 기반으로 특정 액션을 수행한다면, EventBridge는 이벤트에 반응해 액션을 취한다. 즉 특정 이벤트, 스케줄을 모니터링 하다가 관련 액션을 취한다. 예를 들어 , EC2인스턴스의 중지상태가 하나의 이벤트가 될 수 있는 것이고 이벤트에 대응하는 액션을 취한다.
Event Buses
모든 계정은 이벤트를 수신하고 저장하는 하나의 Event Buses를 가지고 있으며, EventBridge는 이 Event Buses를 모니터링 한다.
📌 커스텀 이벤트도 생성가능하다.
룰 / 타겟
룰 : 이벤트에 반응해 취하게 될 액션을 정의한다.
타겟 : 룰을 통해 타겟을 호출할 수 있다.
예시로 , EC2 Autoscailing이벤트가 발생할 때마다 이메일을 전송하는 룰을 생성할 경우 룰은 Autoscailing이 발생하는지 관찰하고 발생시, 이메일 알람을 보낼 SNS토픽을 선택하는 타겟을 호출할 수 있다.
EventBridge의 장점으로는 스케줄 기반으로 타겟을 호출할 수 있다는 것이다. 따라서 매시간마다 EBS의 스냅샷 생성, 또는 오후 7시에 인스턴스를 중단시키는 등의 스케줄링 작업을 할 수 있기 때문에 비용 효율적이다.
마치며
이번 포스팅을 통해 로드밸런서가 트래픽을 보내고 트래픽에 대한 응답이 없을 때 이상이 있다고 판단하는 헬스체크를 했을 때 이 헬스체크 이후 Cloudwatch가 개입해 어떻게 Autoscailing을 할 수 있는지에 대한 궁금증이 풀렸다. 다음에는 또 다른 로그 수집 서비스인 CloudTrail과 Config에 대해서 다루어 볼 예정이다.
