CloudWatch와 x-ray를 통해 관찰 가능성 확보하기

Cloud Watch?

Amazon CloudWatch는 AWS, 온프레미스, 하이브리드, 기타 클라우드 애플리케이션 및 인프라 리소스에 대한 데이터와 실행 가능한 인사이트를 제공하는 모니터링 및 관리 서비스입니다. 모든 성능 및 운영 데이터를 사일로(서버, 네트워크 또는 데이터베이스)에서 모니터링하는 대신 단일 플랫폼에서 로그와 지표 형태로 수집하고 액세스할 수 있습니다. CloudWatch는 애플리케이션 성능을 최적화하고, 리소스 사용률을 관리하고, 시스템 전반의 운영 상태를 파악하는 데 도움이 되는 실행 가능한 인사이트를 제공합니다.

 

CloudWatch는 AWS 외에 다른 온프레미스에서도 사용가능한 서비스다. 로그, 지표, 이벤트 등의 운영 데이터를 수집해 시각화 및 처리하며 경보 생성을 통해 자동화된 대응도 가능하다.

CloudWatch의 주요기능

1. 지표 수집

지표란 시간 순서 별 데이터 요소의 집합이다.

aws의 거의 대부분 서비스에서 이 지표를 생성해준다. 필요에 따라 커스텀 지표도 만들 수 있는데 외부에서 볼 수 없는 지표의 예인 EC2 메모리 사용량의 경우 Agent나 api로 지표를 생성해서 확인해야 한다.

 

2.경보(Alarm)

수집된 지표 값에 따라 알림 생성 가능하다. 일정 수치 도달 혹은 미만일 때 이벤트가 발생하다.

sns(소셜 네트워크 아님)로 Lamda를 실행하거나 이메일을 전달해서 대응할 수 있다. 

 

3. 로그 수집 관리

로그란 지표와 달리 시간이 지남에 따라 발생하는 불연속적인 타임 스탬프다. 긴급하고 예측할 수 없는 동작을 발견하는 데 유용하다. 여러 aws서비스 로그를 수집하고, 수집된 로그를 kinesis, s3등 다른 서비스 및 계정으로 전달하며, 자체적으로 확인하거나 커리를 통해서도 가능하다.

 

4. 대시보드

수집한 로그와 지표를 기반으로 대시보드를 구성한다.

 

지표에 대해서 : 지표의 구성 요소

네임스페이스

cloudWatch 지표 컨테이너로 지표의 출신과 성격에 따라 논리적으로 묶은 단위다(시계열 데이터). aws/{서비스명} 형식으로 적힌다. 반드시 직접 명시해야 한다.

 

지표 이름

지표의 고유 이름

 

데이터 포인트

데이터 포인트는 지표를 구성하는 시간 - 값 단위 시간은 초 단위까지.

 

데이터 포인트의 resolution

데이터가 얼마나 자주 수집되는가(양)을 나타내는 단위다. 기본적으로 60초 단위라 60의 배수로 모집 가능하다.

 

데이터 포인트의 기간(period)

데이터가 얼마 만큼 기준으로 묶여서 모여지는지?
timestamp - data value의 key-value로 나타내며 최소 1초에서 하루까지 보관한다. 보관 기간은 15개월이며, 기간이 지난 뒤 삭제되는 게 아니라 작은 단위의 보관기간은 큰 단위로 계속 합쳐진다. 2주 이상 데이터가 업데이트가 되지 않은 메트릭의 경우 콘솔로만 CLI에서만 확인가능하다.

 

차원

지표를 구분할 때 사용한다. 인스턴스 개별로 보거나, 인스턴스 유형(type) 으로 묶어서 보거나 같은 오토스케일링 그룹으로 묶어서 보는 것

경보(알람)에 대해서

수집된 지표 값의 변동에 따라 발생하는 알람을 생성하며 상태는 다음과 같다.

• ok : 정상
• alarm : 알람상태
• INSUFFICIENT_DATA : 알람 상태를 확인하기 위한 정보 부족

인스턴스 중지, auto scaling 및 Amazon SNS 작업 시작, 종료 등으로 구성할 수 있다.

 

 

---

What is Observability?

In control theory, Observability is measure of how well internal states of a system can be inferred from knowledge of its external outputs

 

제어 이론에서 외부 출력으로부터  시스템 내부의 상태를 얼마나 잘 추론할 수 있는지 측정하는 개념을 뜻한다.

Observability는시스템이 제대로 동작하는지 확인할 수 있게 해주며, Observability를 통해 시스템이 작동하지 않는 이유를 이해할 수 있다. 이를 잘 갖추면 어떻게 찾아야 할지 모르는 문제에 대한 답을 찾을 수 있게 해준다.

이때 모니터링은 관찰가능성의 하위 태그로 추적과 로깅 같은 다른 활동과 함꼐 시스템을 관찰 가능하게 만드는 활동이며 관찰가능성은 관찰한 사실을 바탕으로 문제의 원인을 역으로 파악하는 것을 말한다. 이때 프로파일러나 AI/OPS같은 도구를 사용한다.

 

서비스에서 발생하는 문제를 해결하기 위해 다음과 같은 Issue timeline을 거치게 된다.

그림1

 

(1) Detect

페이지가 로딩되지 않는 등 장애 상황 발생 시 이메일로 알림을 받아 detect하게 된다. 만약 알람이 오지 않으면 문제 상황을 아주 늦은 시간 뒤에 대처하게 될 것이다. 이때 문제 상황을 감지하기까지 걸리는 시간을 MMTD라고 하며 이를 줄이는 것이 중요하다.

 

(2) Identify

문제에 대한 식별단계다. 어떤 문제가 발생했는지 알아내는 단계며 이때까지 걸리는 시간을 MTTI라고 한다.

 

(3) Fix, Verify

어떤 문제가 발생했는지 알아냈다면 이를 해결하고 검증하는 과정이 필요하다. 이때까지 걸리는 시간을 MTTR이라고 한다. 하지만 대개 해결은 시간이 별로 걸리지 않아 관건은 MTTI를 줄이는 것이다.

그래서 Observability를 잘 확보하다는 것은 모니터링을 넘어 분석 능력과 INSIGHT를 얻고 자동화를 할 수 있어야 한다는 것이다.

 

그림1을 보면 기존에는 AWS Watch없이 detect와 identify를 하려면 서로 다른 사건들의 로그와 메트릭들을 분석해서 상관관계를 분석해야 한다. 하지만 이렇게 하기가 쉽지 않다. 그러나 AWS observability 도구를 사용하면 여러 인스턴스를 아우를 수 있는 중앙집중형 관리를 시작할 수 있다.. 다음은 observability을 위한 AWS 도구들이다.

 

(1) CloudWatch Logs

어플리케이션의 버그나 혹은 이상행동을 감지하기 위해서 로그를 살펴볼 필요가 있다. 예전에는 서버에 직접 들어가 로그를 확인하곤 했는데 이런 방식으로는 시간이 매우 많이 걸리며 서버의 개수가 늘어날 경우 과정이 매우 복잡해진다. CloudWatch Logs의 경우엔 내부로 들어가지 않고도 여러 인스턴스의 로그 값을 외부 출력 값으로 받아올 수 있다.

aws의 대부분 서비스는 로그를 제공한다. 하지만 정보가 너무 많기 때문에 선별해서 확인할 필요가 있다. 이를 위해 Log Insight를 제공하는데 집계, 필터 및 정규 표현식을 사용해 쿼리를 사용해 확인할 수 있다.

 

(2) CloudWatch metrics

cpu 값은 메트릭에 대한 정보를 얻어 대쉬보드를 생성 후 모니터링하여 알람을 만들 수 있다. 개별 로그 분석이 아니라, cpu, connection, 메모리, i/o같은 지표로 서비스의 가시성을 확인할 수 있다. 로그로 순차적인 행동들에 대한 이해가 가능하지만 지표를 통해 계속 대쉬보드를 관찰할 수 없으니 알람을 통해 작업을 트리거할 수 있다. 알림 또한 해당 데이터들을 min, average 같은 math 도구를 통해 분석하기 위해 Metric Math가 제공된다. 메트릭 값에 따라 sns 혹은 이메일로 전달될 수 있다. 대시보드에 경보를 추가해서 시각화도 가능하다.

 

(3) x-ray traces

위 두 가지 정보로는 컴포넌트의 병목이나 지연을 확인할 수 없다. x-ray를 통해 서비스를 통해 어플리케이션의 전체 흐름을 확인할 수 있다. trace로 전체 흐름을 파악하고 segment와 sub-segment로 나눠 세부 사항을 확인한다.

 

참고:

Optimize Application Performance with AWS X-Ray

 

코로나 증상을 세 가지 도구로 비유하자면,

코로나에 걸린 후 본인의 이상 행동 -> logs

본인의 열이 29도까지 찍었다 -> metrics

머리에 열이 왜 났는지, 몸의 장기들이 어디서 과부하가 걸렸는지 전체적인 걸 확인 ->:x-ray

Cloud Insights?

이외에도 Cloud에는 많은 insight를 제공하고 있다.

• CloudWatch Container Insights : 컨테이너 환경에서 서비스들의 많은 하드들의 모니터링이 어렵기 땜에 컨테이너 인사이트를 제공하고 있다. 서비스 맵, cpu….등을 제공한다.
• CloudWatch Lambda Insights : 람다에 대한 멀티 function에 대한 mertic 제공.
• CloudWatch Container Insights : 시계열 데이터 분석해서 시스템 성능에 영향을 미치는 Top-N Contributor를 확인한다. 실시간 검색에서 어떤 것들이 가장 많이 hitting이 되고 있는지, 어떤 ip에서 request들이 가장 많이 들어오고 있는지… 등
• Synthetics : 주기적으로 인공 신호를 보내 엔드 포인트의 유저(고객)가 알아차리기 전에 오류를 확인함(알람을 주거나..) 스크린샷을 확인해서 어느 부분 ui가 깨졌는지도 확인할 수 있음
• ServiceLens : 어플리케이션의 상관관계(로그, 메트릭, 트레이스)를 시각화하는 것도 가능하다.

aws 서비스를 반영한 새로운 timeline이다.

 

탐지 단계에서 사용자가 오류를 보고할 때까지 기다리거나 커스텀 오류 감지 툴을 사용하는 대신 synthetics을 통해 주기적인 인공 신호를 보내서 에러가 발생한 즉각적인 시간에 알람을 보낼 수 있다.

수집된 traces통한 이상 현상에 대한 알람을 받아 mtti를 단축시킬 수 있다.

식별단계를 통해 serviceLens analysis를 통해 logs, metrics, traces들의 상관관계를 지정할 수 있다.

 

이런 방식을 통해 근본 원인 식별과 이슈 식별에 대한 전반적인 노력을 매우 줄일 수 있다!