Amazon CloudWatch Application Signals – 애플리케이션 자동 계측 (미리 보기)

분산 시스템의 문제 중 하나는 상호 의존적인 여러 서비스로 구성되어 성능을 모니터링하려고 할 때 상당한 복잡성이 추가된다는 것입니다. 지연 시간이 길거나 가용성이 저하되는 서비스와 API를 파악하려면 텔레메트리 신호를 수동으로 수집해야 합니다. 이로 인해 지표, 추적, 로그, 실제 사용자 모니터링 및 합성 모니터링 전반에서 일관되지 않은 환경으로 인해 시스템 문제의 근본 원인을 파악하는 데 시간과 노력이 소요될 수 있습니다.

고객에게 지속적으로 사용할 수 있는 고성능 애플리케이션을 제공하려고 합니다. 동시에 이를 보장하는 모니터링은 효율적이고 비용 효율적이어야 하며 번거로운 작업을 차별화해야 합니다.

Amazon CloudWatch Application Signals를 사용하면 애플리케이션 성능 모범 사례에 따라 애플리케이션을 자동으로 계측할 수 있습니다. 수동 작업, 사용자 지정 코드 및 사용자 지정 대시보드가 없습니다. 요청량, 가용성, 지연 시간 등과 같은 가장 중요한 애플리케이션 성능 지표를 보여주는 사전 구축되고 표준화된 대시보드를 얻을 수 있습니다. 또한 SLO(서비스 수준 목표)를 애플리케이션에 정의하여 비즈니스에 가장 중요한 특정 작업을 모니터링할 수 있습니다. SLO의 예로 웹페이지가 28일 롤링 간격 중 99.9%의 시간인 2,000ms 이내에 렌더링되어야 한다는 목표를 설정하는 것일 수 있습니다.

Application Signals는 지표, 추적, 로그, 실제 사용자 모니터링, 합성 모니터링 전반에서 텔레메트리의 상관 관계를 자동으로 분석하여 문제 해결 속도를 높이고 애플리케이션 중단을 줄입니다. Application Signals에서 애플리케이션 컨텍스트에서 성능을 분석할 수 있는 통합 환경을 제공함으로써 가장 중요한 비즈니스 기능을 지원하는 애플리케이션에 초점을 맞춰 생산성을 향상시킵니다.

개인적으로 가장 좋아하는 것은 Application Signals를 통해 수행할 수 있는 팀 간의 협업입니다. 이 게시물은 분산 시스템이 상호 의존적인 여러 서비스로 구성되어 있다는 점을 언급하면서 시작했습니다. 이 게시물의 뒷부분에서 살펴볼 서비스 맵에서 서비스 소유자가 다른 서비스로 인해 발생한 문제를 식별하는 경우 분류 작업에 효율적으로 협력하기 위해 다른 서비스의 소유자에게 링크를 보낼 수 있습니다.

CloudWatch Application Signals 시작
새 Amazon CloudWatch Observability EKS 추가 기능을 활성화하면 Amazon EKS 콘솔에서 새 Amazon EKS 클러스터를 생성할 때 애플리케이션 및 컨테이너 텔레메트리를 쉽게 수집할 수 있습니다. 또 다른 옵션은 Amazon CloudWatch 콘솔에서 직접 기존 Amazon EKS 클러스터 또는 기타 컴퓨팅 유형을 활성화하는 것입니다.

Amazon EKS 추가 기능 또는 다른 컴퓨팅 유형에 대한 사용자 지정 옵션을 통해 Application Signals가 활성화되면 Application Signals에서 자동으로 서비스를 검색하고 요청량 및 지연 시간 스파이크 또는 API 및 종속성에 대한 가용성 저하와 같은 표준 애플리케이션 지표 세트를 생성합니다.

검색된 모든 서비스와 해당 골든 지표(요청량, 지연 시간, 결함 및 오류)는 자동으로 서비스 페이지와 서비스 맵에 표시됩니다. 서비스 맵은 서비스 상태, 해당 작업, 종속성, 작업과 종속성 간의 모든 호출 경로를 평가할 수 있는 시각적 심층 분석을 제공합니다.

Application Signals에서 활성화되는 서비스 목록은 모든 서비스 및 종속성에 대한 운영 지표와 함께 서비스 대시보드에도 표시되어 이상 항목을 쉽게 찾아낼 수 있습니다. EKS 클러스터가 AppRegistry에서 태그가 지정된 애플리케이션에 속하는 경우 Application 열이 자동으로 채워집니다. Hosted In 열은 서비스 요청이 실행 중인 EKS 포드, 클러스터 또는 네임스페이스 조합을 자동으로 탐지합니다. 하나를 선택하여 Container Insights로 직접 이동하면 CPU 또는 메모리 사용률과 같은 자세한 컨테이너 지표를 확인할 수 있습니다.

Application Signals를 통한 팀 협업
이제 이 게시물의 시작 부분에서 언급한 팀 협업에 대해 더 자세히 살펴보겠습니다. 서비스 대시보드를 참조하여 온전성 검사를 수행하고 pet-clinic-frontend라는 서비스 중 하나에 대해 2가지 SLO 문제를 발견했다고 가정해 보겠습니다. 회사에서는 일단의 SLO를 유지 관리합니다. 이를 통해 애플리케이션이 목표에 따라 실행되고 있는 상황을 파악할 수 있습니다. 태그가 AppRegistry에 지정된 서비스의 경우 모든 팀은 애플리케이션의 정의와 소유권을 한 곳에서 볼 수 있습니다. 서비스 맵을 더 자세히 탐색하면 이 서비스의 상태에 대한 더 자세한 정보를 얻을 수 있습니다.

이제 AppRegistry에서 세부 정보를 찾은 Sarah에게 pet-clinic-frontend 서비스 링크를 보내기로 결정합니다. Sarah는 이 서비스에 대한 대기 담당자입니다. 문제 검색 기반 상황에 맞는 분류 보기로 바로 이동할 수 있도록 큐레이팅되어 있으므로 이 링크를 사용하면 Sarah와 효율적으로 협업할 수 있습니다. Sarah는 여러 요청에 대해 POST /api/customer/owners 지연 시간이 2,000ms로 증가했음을 확인하고 서비스 소유자로서 근본 원인을 찾기 위해 심층적으로 분석합니다.

지연 시간 그래프를 클릭하면 직접적으로 작업, 지표 및 특정 시점에 해당하는 상관 관계 추적 목록이 반환됩니다. 이는 Sarah가 지연 시간 증가로 이어질 수 있는 정확한 추적을 찾는 데 도움이 됩니다.

Sarah는 Amazon CloudWatch Synthetics 및 Amazon CloudWatch RUM을 사용하고, 서비스와 상관 관계가 있는 관련 카나리아 및 페이지 목록을 자동으로 볼 수 있도록 X-Ray 활성 추적 통합을 활성화했습니다. 이제 이 통합 보기를 통해 Sarah는 애플리케이션 성능에 대한 다양한 관점을 얻고 단일 보기에서 이상 항목 문제를 빠르게 해결할 수 있습니다.

미리보기 출시
Amazon CloudWatch Application Signals는 미리 보기로 제공되며, 이제 미국 동부(버지니아 북부), 미국 동부(오하이오), 미국 서부(오레곤), 유럽(아일랜드), 아시아 태평양(시드니), 아시아 태평양(도쿄)의 AWS 리전에서 사용할 수 있습니다.

자세한 내용은 Amazon CloudWatch 사용 설명서를 참조하세요. 질문은 Amazon CloudWatch에 대한 AWS re:Post에 제출하거나 일반적인 AWS Support 문의를 통해 제출할 수 있습니다.

– Veliswa