티스토리 뷰
데이터를 수집, 분석 및 사용하는 행위
•모니터링 목적
–IT 리소스 및 시스템에 대한 여러가지 질문의 답 산출 및 의사 결정
–매일 몇 명이나 사이트를 방문하고 있는가?
–시간 경과에 따른 방문자 수를 추적하려면 어떻게 해야 하는가?
–웹 사이트에 성능 또는 가용성 문제가 있는지 있었던 적이 있는가?
–Amazon Elastic Compute Cloud(EC2) 인스턴스의 용량이 부족해지는 것은 아닌가?
–웹 사이트가 정상 동작하고 있는가?
•리소스 과다 사용, 애플리케이션 결함, 리소스 구성 오류 또는 보안 관련 이벤트로 인한 운영 문제 감시가능
메트릭(Metric)
리소스가 생성하는 다양한 형태의 데이터 중 모니터링을 통해 수집된 데이터
•메트릭 예
–시간 경과에 따라 EC2 인스턴스에서 수집 및 분석되는 메트릭
–평균 CPU 사용률
–네트워크 사용률
–디스크 성능
–메모리 사용률
–각종 로그(서버 또는 IT 시스템의 작업, 활동 및 사용 패턴에 대한 정보)
AWS의 리소스마다 다른 유형의 메트릭 생성
–
Amazon Simple Storage Service(Amazon S3) 버킷
–
앞서 살펴본 EC2 인스턴스처럼 CPU 사용률은 없음
–
버킷에 저장된 객체와 관련된 메트릭 (버킷 전체 크기 또는 버킷 내 객체 수 등)
–
버킷에 대한 요청과 관련된 메트릭 (객체 읽기 또는 쓰기 등)
–
Amazon Relational Database Service(Amazon RDS)
–
데이터베이스 연결, 인스턴스의 CPU 사용률, 디스크 공간 소비 등
•
리소스, 목표 및 상황에 따라 다양한 메트릭이 존재 가능
모니터링의 이점 및 중요성
•최종 사용자가 운영 문제를 인식하기 전에 사전 대응 가능
–메트릭을 활용하여 문제 발생 징후를 확인하거나 문제 발생 시 빠른 인식 가능
–이를 통해 자동 혹은 수동으로 필요한 작업을 수행하여 문제 해결가능
•리소스의 성능 및 안정성을 개선
–모니터링은 제대로 수행할 경우 병목 현상과 비효율적인 아키텍처를 확인 가능
•보안 위협 및 이벤트를 인식
–시간 경과에 따라 리소스, 이벤트 및 시스템을 모니터링하면 기준선(Base-line: 정상적인 활동을 정의) 생성 가능
–이를 이용하여 비정상적인 트래픽 스파이크 또는 리소스에 액세스하는 비정상적인 IP 주소와 같은 이상 현상을 발견가능
•비즈니스를 위해 데이터 중심의 의사 결정을 수립
–IT 운영 상태를 주시하고 비즈니스 의사 결정 지원
–ex) 새로운 앱 기능 사용자 수를 통한 투자 여부 판단 가능
•보다 비용 효율적인 솔루션을 구축
–사용량이 부족한 리소스를 확인하고 리소스를 사용량에 맞게 조정하여 비용을 최적화가능
Troubleshooting Process
•일반적인 문제 발생시 트러블슈팅 프로세스
Detect -> Identify = MTTI
그 후에 > FIX > Verify
*MTTI (Mean Time to Identify) : 문제를 인식하여 원인을 파악하기 까지의 시간
모니터링 솔루션
•리소스의 운영 상태 및 사용량에 대한 데이터를 수집하고 분석하는 방법 필요
•중앙 집중 식 모니터링 필요
–분산된 리소스는 메트릭, 로그, 네트워크 트래픽, 이벤트 등을 통해 다양한 데이터를 각각 생성
–이렇게 분산된 데이터를 중앙집중식으로 모니터링하지 않을 경우 관리가 어려울 수 있음
•데이터 가시성 확보 필요
–단순 데이터의 축적 만으로는 데이터를 활용하기에 어려움이 있을 수 있음
•모니터링 솔루션 예
–AWS CloudWatch, Prometheus, Grafana
AWS CloudWatch
•AWS 리소스 및 애플리케이션을 관측하고 모니터링 하는 도구
•수행 가능 작업
–환경에서 이상 동작을 감지
–문제가 있을 때 알리도록 경보를 설정
–AWS 관리 콘솔을 사용하여 로그 및 메트릭을 시각화
–크기 조정과 같은 자동화된 작업을 수행
–애플리케이션을 정상으로 유지하기 위한 인사이트를 발견
CloudWatch 구조 Overview
•CloudWatch Dashboard
–메트릭 정보를 통합된 화면에서 그래프로 표현하여 시각화
•Cloud Watch 메트릭
–리소스 성능 관련 메트릭 확인 가능
•CloudWatch Insight
–수집된 데이터를 기반으로 가시성을 확보
•CloudWatch Log
–사용하는 AWS 서비스들을 모니터링 하기 위해 발생하는 로그들을 수집, 저장, 탐색, 분석
•CloudWatch Alarm
–특정 기준이 되면 특정 이벤트를 발생시켜 사용자에게 알림
•Cloud Watch Event
–AWS 리소스의 변경사항에 관한 시스템 이벤트 기록
•Cloud Watch Service Lens
•CloudWatch Synthetics
CloudWatch 개요
•메트릭 및 로그 리포지토리
•모니터링 가능 범위
–EC2, RDS 등 AWS 서비스
–온프레미스 애플리케이션 리소스
•수집 데이터
–사전 정의 된 메트릭
–사용자 지정 메트릭
CloudWatch Dashboard
•클라우드 리소스와 애플리케이션의 메트릭 및 경보를 시각화
•원하는 메트릭을 모아 대시보드로 생성
•CloudWatch cross-account observability 설정을 통해여러 AWS 계정에 공유되고 있는 애플리케이션을 모니터링하고 문제를 해결 가능
•애니메이션 대시보드를 통해시간에 따라 변화하는 메트릭 데이터를 재생
•AWS 계정에 직접 접근 할 수 없는 사람들과 대시보드 공유 가능
CloudWatch Alarm
•이벤트 및 메트릭 변경에 대한 경보(Alarm) 제공
•대시보드에 경보 추가 하거나 지정 작업 수행 가능
–3가지 알람 상태 (OK / ALARM / INSUFFICIENT_DATA) 사이에서 상태가 변경될 때 수행하는 작업을 지정
CloudWatch Metric
•리소스 성능 관련 메트릭 확인 가능
•AWS 서비스의 5분 주기의 메트릭 제공
–1분 단위로 주기 조절 가능(유료)
•메트릭 보존 일정 -무료
–1분 데이터 포인트 -15일
–5분 데이터 포인트 -63일
–1시간 데이터 포인트 - 455일
•맞춤형 애플리케이션 메트릭 수집 가능
–ex)애플리케이션에 대한 사용자 활동 또는 로그인 수
•Metrics Explorer 를 통해 태그별 운영상태, 성능 메트릭 필터링, 수집 및 시각화를 지원
CloudWatch에서 보이는 정보는 “통계값”이다.
–메트릭 데이터를 지정한 기간으로 집약한 것
–각 메트릭에 따라 적합한 통계 값을 보는 것이 중요
Minimum : 특정 기간 동안에서의 측정된 가장 낮은 값
Maximum :특정 기간 동안에서의 측정된 가장 높은 값
Sum :해당 메트릭에 가산 된 모든 합계
Average :지정 기간 Sum/SampleCount 값
SampleCount :통계 계산에 사용되는 데이터의 포인트 개수
CloudWatch Log
•시스템, 애플리케이션 및 AWS 서비스의 로그 파일을중앙 집중화 하여 저장 및 액세스
–로그 데이터 보관
–무기한 (기본값)
–1일~ 10년 사이로 변경 가능
–이벤트 내 특정 메시지, 오류 검색 가능
–ex)애플리케이션에서 발생하는 오류 수 추적 및 임계 값 초과 시 알림 가능
–특정 필드의 로그를 필터링 및 보관 가능
–Live Tail을 통한 감지 및 디버그 (유료)
로그 이벤트
–로그 이벤트는 모니터링 중인 응용 프로그램 또는 리소스에 의해 기록되는 일부 활동의 기록
–기록은 이벤트가 발생한 타임스탬프와 이벤트 메시지라는 두 가지 속성으로 구성
–이벤트 메시지는 UTF-8로 인코딩
•로그 스트림
–특정 소스의 로그 이벤트
–ex)일반적으로 모니터링 중인 애플리케이션 인스턴스 또는 리소스와 관련한 일련의 이벤트
•로그 그룹
–동일한 보존, 모니터링 및 액세스 제어 설정을 공유하는 로그 스트림 그룹
–각 로그 스트림은 하나의 로그 그룹에 속해야 함
AWS 주요 리소스 모니터링 & 비용 모니터
EC2 메트릭(표준 메트릭)
–CPUUtilization
–CPUCreditBalance
–CPUCreditUsage
–DiskReadBytes
–DiskWriteBytes
–DiskWriteOps
–NetworkOut
–NetworkIn
–StatusCheckFailed_Instance
–StatusCheckFailed_System
사용자 지정 메트릭 (Custom Metric)
•기본 메트릭들 이외에 사용자 지정 메트릭 수집 가능
–ex) 인스턴스 ID 및 인스턴스 유형(type)의 차원을 사용한 메모리 사용 백분율을 메트릭으로 수집
–인스턴스 ID 또는 인스턴스 유형별로 필터링가능
–더 많은 차원을 추가하면각 메트릭과 고유한 차원 값 조합으로 인해 새로운 메트릭 생성가능
–분석 기능과 전체 비용이 증가
EC2 모니터링 주요 메트릭
•CPUUtilization: 현재 인스턴스에서 사용하고 있는 컴퓨팅 파워
•CPUCreditUsage: 특정 기간동안 사용된 CPU 크레딧 갯수
•DiskReadOps: 해당 인스턴스에 연결된 모든 로컬 디스크에서 읽어 들인 오퍼레이션의 수
•Network Out Traffic : 인스턴스의 네트워크 인터페이스를 통해 나간 바이트 량
•Status Check
–System status check -재배포 등을 통한 개입 정도만 가능
–네트워크 연결
–시스템 파워
–물리서버 이슈 등
–Instance status check -설정 변경을 통한 개입 가능
–잘못된 네트워킹 또는 시작 구성
–메모리 부족
–파일 시스템 손상
–호환되지 않는 커널 등
EBS 모니터링 주요메트릭
•VOLUMEIDLETIME: 지정된 기간 동안 제출된 읽기 또는 쓰기 작업이 없는 총 시간(초)
–비용을 최적화하기 위하여 사용하지 않는 볼륨 제거 시 참고 가능
•VOLUMEQUEUELENGTH: 디바이스에서 보류 중인 I/O 요청의 수
–특정 EC2 인스턴스 유형과 관련된 병목 현상을 식별해야 할 때 유용
•BURSTBALANCE: 볼륨에 대한 버스트 버킷의 크레딧 백분율
–I/O 크레딧(gp2의 경우) 또는 처리량 크레딧(st1 및 sc1의 경우)
•EBS volumes 모니터링 옵션 변경 가능
–기본(5분 주기 수집): 일반적인 volume type의 기본값
–상세(1분 주기 수집): io1 type volumes 의 기본값
•Status Check (io1, io2, gp3)
–OK (정상) / Warning (성능저하) /Impaired(중단됨 or I/O비활성화) / Insufficient-data
–데이터가 일치하지 않은 것으로 확인되면 데이터 손상을 방지하기 위해 Volume의 I/O가 비활성화
–IO 자동 사용(Auto-Enable IO) 옵션을 사용하면 데이터 일치 여부와 무관하게 I/O 활성화 지속가능
ELB 모니터링 주요 메트릭 (1/2)
•Backend Connection Error–
ELB와 등록된 인스턴스 간에 성공적으로 커넥션이 맺어지지 않은 숫자
•Latency
–외부 요청을 받아 타겟 그룹으로 전달 한 ELB가 EC2 인스턴스로 부터 응답을 받을 때까지의 지연 시간
–평균 or 최대값
•
Surge Queue Length
–로드밸런서에서 라우팅이 지연되고 있는 총 요청 수
–큐 최대 사이즈 1024 -큐가 가득 차면 추가 요청이 거부 됨
–권장 수치 0
•Spill Over Count
–거부 된 요청 값
–0 초과되는 경우 조치 권장