기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
모니터링
모니터링은 CPU 및 메모리와 같은 다양한 지표를 수집하여 Amazon Managed Service for Prometheus와 같은 시계열 데이터베이스에 저장하는 프로세스입니다. 모니터링 시스템은 푸시 기반 또는 풀 기반일 수 있습니다. 푸시 기반 시스템에서 소스는 주기적으로 메트릭을 시계열 데이터베이스로 푸시합니다. 풀 기반 시스템에서 스크레이퍼는 다양한 소스의 메트릭을 스크랩하여 시계열 데이터베이스에 저장합니다. 개발자는 메트릭을 분석하고, 메트릭을 필터링하고, 시간 경과에 따라 그래프로 표시하여 성능을 시각화할 수 있습니다. 모니터링을 성공적으로 구현하는 방법은 크게 애플리케이션과 인프라라는 두 가지 영역으로 나눌 수 있습니다.
애플리케이션 개발자에게는 다음과 같은 지표가 중요합니다.
-
지연 시간 — 응답을 받는 데 걸린 시간
-
요청 처리량 — 초당 처리된 총 요청 수
-
요청 오류율 — 총 오류 수
비즈니스 트랜잭션과 관련된 각 리소스 (예: 애플리케이션 컨테이너, 데이터베이스) 에 대한 리소스 사용률, 포화도 및 오류 수를 캡처합니다. 예를 들어 CPU 사용량을 모니터링할 때 성능 테스트 실행 중 평균 CPU 사용률, 평균 부하 및 최대 부하를 추적할 수 있습니다. 스트레스 테스트 중에는 리소스가 포화 상태에 도달했지만 더 짧은 기간 동안 성능 실행 중에는 포화 상태에 도달하지 못할 수 있는 경우
지표
애플리케이션은 스프링 부트 액추에이터와 같은 다양한 액추에이터를 사용하여 애플리케이션을 모니터링할 수 있습니다. 이러한 프로덕션 등급 라이브러리는 일반적으로 실행 중인 애플리케이션에 대한 정보를 모니터링하기 위해 REST 엔드포인트를 노출합니다. 라이브러리는 기본 인프라, 애플리케이션 플랫폼 및 기타 리소스를 모니터링할 수 있습니다. 기본 메트릭이 요구 사항을 충족하지 않는 경우 개발자는 사용자 지정 메트릭을 구현해야 합니다. 사용자 지정 지표는 기본 구현의 데이터로는 추적할 수 없는 비즈니스 핵심 성과 지표 (KPI) 를 추적하는 데 도움이 될 수 있습니다. 예를 들어 타사 API 통합 지연 시간이나 완료된 총 트랜잭션 수와 같은 비즈니스 작업을 추적하고 싶을 수 있습니다.
카디널리티
카디널리티는 지표의 고유 시계열 수를 나타냅니다. 추가 정보를 제공하기 위해 지표에 레이블이 지정됩니다. 예를 들어, 특정 API의 요청 수를 추적하는 REST 기반 애플리케이션은 카디널리티가 1임을 나타냅니다. 사용자당 요청 수를 식별하기 위해 사용자 레이블을 추가하면 카디널리티가 사용자 수에 비례하여 증가합니다. 카디널리티를 생성하는 레이블을 추가하여 다양한 그룹별로 지표를 분류할 수 있습니다. 카디널리티는 백엔드 모니터링 시계열 데이터베이스의 지표 시리즈 수를 증가시키기 때문에 올바른 사용 사례에 적합한 레이블을 사용하는 것이 중요합니다.
해결 방법
일반적인 모니터링 설정에서 모니터링 애플리케이션은 애플리케이션의 메트릭을 주기적으로 스크레이핑하도록 구성되어 있습니다. 스크래핑 주기에 따라 모니터링 데이터의 세분성이 정의됩니다. 짧은 간격으로 수집된 지표는 더 많은 데이터 포인트를 사용할 수 있기 때문에 성능을 더 정확하게 파악할 수 있는 경향이 있습니다. 그러나 더 많은 항목이 저장될수록 시계열 데이터베이스의 부하가 증가합니다. 일반적으로 60초의 세분화는 표준 해상도이고 1초는 고해상도입니다.
DevOps 팀
애플리케이션 개발자는 종종 DevOps 엔지니어에게 인프라 및 애플리케이션의 메트릭을 시각화하기 위한 모니터링 환경을 설정하도록 요청합니다. DevOps 엔지니어는 확장 가능하고 애플리케이션 개발자가 사용하는 데이터 시각화 도구를 지원하는 환경을 설정해야 합니다. 여기에는 다양한 소스의 모니터링 데이터를 스크랩하여 Amazon Managed Service for Prometheus와 같은 중앙 시계열 데이터베이스로 데이터를 보내는 작업이 포함됩니다.
백엔드 모니터링
모니터링 백엔드 서비스는 지표 데이터의 수집, 저장, 쿼리 및 시각화를 지원합니다. 일반적으로 Prometheus용 Amazon Managed Service 또는 InfluxDB와 같은 시계열 데이터베이스입니다. InfluxData 모니터링 수집기는 서비스 검색 메커니즘을 사용하여 다양한 소스에서 지표를 수집하여 저장할 수 있습니다. 성능 테스트 중에는 나중에 검색할 수 있도록 지표 데이터를 저장하는 것이 중요합니다. 지표용으로 최소 15일의 데이터를 저장하는 것이 좋습니다. 그러나 지표를 더 오래 저장해도 큰 이점이 추가되지 않고 불필요한 스토리지 비용이 발생합니다. 성능 테스트를 통해 대량의 메트릭이 생성될 수 있으므로 빠른 쿼리 성능을 제공하면서 메트릭 인프라를 확장하는 것이 중요합니다. 모니터링 백엔드 서비스는 지표 데이터를 보는 데 사용할 수 있는 쿼리 언어를 제공합니다.
시각화
애플리케이션 데이터를 표시하여 의미 있는 통찰력을 제공할 수 있는 시각화 도구를 제공합니다. DevOps 엔지니어와 애플리케이션 개발자는 모니터링 백엔드의 쿼리 언어를 배우고 긴밀하게 협력하여 재사용할 수 있는 대시보드 템플릿을 생성해야 합니다. 대시보드에는 지연 시간 및 오류를 포함시키고 인프라 및 애플리케이션 리소스 전반의 리소스 사용률 및 포화 상태도 표시하십시오.
모니터링 인프라 자동화
로깅과 마찬가지로 모니터링 인프라의 설치 및 운영을 자동화하여 다양한 애플리케이션의 다양한 요구 사항을 수용할 수 있도록 하는 것이 중요합니다. IaC 도구를 사용하여 모니터링 인프라의 백엔드를 프로비저닝하십시오. 그런 다음 모니터링 인프라를 공유 서비스 또는 특정 애플리케이션을 위한 독립적인 맞춤형 배포로 프로비저닝할 수 있습니다.
CD 파이프라인을 사용하여 다음을 자동화하십시오.
-
필요에 따라 모니터링 인프라를 배포하고 필요하지 않을 때는 해체하십시오.
-
모니터링 구성을 업데이트하여 지표를 필터링하거나 집계하세요.
-
애플리케이션 대시보드를 배포하십시오.
모니터링 도구
Prometheus용 Amazon Managed Service는 Prometheus와 호환되는 컨테이너 인프라 및 컨테이너용 애플리케이션 메트릭을 위한 모니터링 서비스로서
CloudWatch Amazon은 에서 풀스택 모니터링을 제공합니다. AWS CloudWatch AWS 네이티브 솔루션과 오픈 소스 솔루션을 모두 지원하므로 언제든지 기술 스택 전반에서 일어나는 일을 이해할 수 있습니다.
기본 AWS 도구에는 다음이 포함됩니다.
CloudWatch Amazon은 Container Insights를 통한 CloudWatch 컨테이너 모니터링과 같은 특정 사용 사례를 처리하는 특수 목적의 기능을 제공합니다. 이러한 기능이 내장되어 CloudWatch 있어 로그, 지표 수집 및 모니터링을 설정할 수 있습니다.
컨테이너화된 애플리케이션 및 마이크로서비스의 경우 Container Insights를 사용하여 지표와 로그를 수집, 집계 및 요약할 수 있습니다. 컨테이너 인사이트는 아마존 엘라스틱 컨테이너 서비스 (Amazon ECS), 아마존 Elastic Kubernetes Service (Amazon EKS) 및 아마존 Elastic Compute Cloud (아마존 EC2) 의 쿠버네티스 플랫폼에서 사용할 수 있습니다. 컨테이너 인사이트는 데이터를 임베디드 지표 형식의 성능 로그 이벤트로 수집합니다. 이러한 성능 로그 이벤트 항목은 카디널리티가 높은 데이터 수집 및 대규모 저장을 지원하는 구조화된 JSON 스키마를 사용합니다.
Amazon EKS를 사용하여 컨테이너 인사이트를 구현하는 방법에 대한 자세한 내용은 Distro를 사용하는 Amazon EKS Fargate용 Amazon CloudWatch 컨테이너 인사이트 소개
