Telemetry란?
마이크로서비스는 분산 환경에서 운영되며, 다수의 마이크로서비스가 동작하게 됩니다. 이러한 특징 때문에 장애, 운영 이관 등의 실행중인 프로세스에서 발생하는 이벤트의 흐름을 보고 원인을 파악하는데 오랜 시간이 소모 됩니다.
각 서비스별로 발생하는 이슈들을 Tracing 하기 위하여 Monitoring, Logging, Tracer 도구를 활용하여 지속적이고 자동으로 이슈에 대응할 수 있도록 환경을 구성합니다. - MSA school
여기서 key point 는
- Monitoring
- Logging
- Tracer
로 볼 수 있다.
Main functions of Telemetry
Monitoring
인프라 및 응용 프로그램 서비스 모니터링을 위해서는 매트릭 수집, 로깅 및 추적 이라는 세가지 도메인에서 데이터 수집, 저장 및 분석이 필요합니다. 또한 Alert 기능은 세가지 도메인의 기능을 서포팅 하기 위해 반드시 필요한 기능입니다.
Monitoring은 마이크로서비스 아키텍처의 성능이나 효율성을 확인합니다. AWS에서는 Amazon Cloudwatch가 있고, OSS로는 Prometheus, Grafana등이 있습니다. Monitoring은 각 대상에서 수집한 Metric을 통해 대상 리소스의 사용률 등을 수치로 표현하는 기능을 수행합니다.
Prometheus + Grafana
- 스프링 부트 액츄에이터와 마이크로미터를 사용하면 수 많은 메트릭을 자동으로 생성한다.
- 프로메테우스는 이렇게 만들어진 메트릭을 지속해서 수집한다.
- 프로메테우스는 수집한 메트릭을 내부 DB에 저장한다.
- 사용자는 그라파나 대시보드 툴을 통해 그래프로 편리하게 메트릭을 조회한다. 이때 필요한 데이터는
프로메테우스를 통해서 조회한다.
Logging
Logging은 마이크로서비스 아키텍처에서 발생하는 Log들을 수집해서 보여줍니다.
Log는 실행 중인 프로세스에서 발생하는 이벤트의 흐름을 의미하며 마이크로서비스 아키텍처에서는 컨테이너에서 실행중인 프로세스들의 수가 모놀리식 아키텍처에 비해서 매우 많기 때문에 장애와 같은 이벤트 발생 시 파악하기가 힘이 들며 root cause를 찾기가 어렵습니다.
따라서 많은 로그들을 빠르게 수집하여 사용자에게 보여줌으로써 어느 마이크로 서비스에서 장애가 발생하였는지 쉽게 파악할 수 있습니다.
AWS에서는 Amazon Elastic Search 등이 Logging을 담당하는 요소이며, OSS로는 EFK(Elastic Search - FluentD - Kibana) 가 대표적입니다.
각 서비스에 심어진 Agent가 해당 서비스의 Log정보들을 수집하고, Log Server(Aggregator)를 통해 취합됩니다. 최종적으로 Kibana와 같은 툴을 통해 시각화된 데이터를 관리자에게 보여줍니다.
EFK(Elastic Search - FlunetD - Kibana)
- 각 쿠버네티스 환경에 배포된 시스템에서 나오는 데이터를 fluentd가 수집한다
- fluentd가 이 데이터를 elasticsearch에서 보내주면, elasticsearch는 인덱싱하여 저장한다.
- elasticsearch와 연결된 kibana UI에서 해당 데이터를 볼 수 있다.
ELK(Elastic Search - Logstash - Kibana)
EFK와 동일하게 데이터 수집 및 시각화 목적의 스택이지만, fluentd 대신 logstash를 사용한다.
- 데이터 원천에 beat가 붙어서 데이터를 수집한다. EFK 아키텍쳐와 마찬가지로 여러 대의 데이터 원천 각각에 beats가 붙어서 데이터를 수집할 수 있다.
- beats가 수집한 데이터를 logstash에서 적절하게 처리한 뒤 es로 보낸다 ex) GMT 형식의 timestamp값을 KST로 변환 등
- elasticsearch는 이 데이터를 인덱싱하여 저장한다.
- elasticsearch와 연결된 kibana UI에서 해당 데이터를 볼 수 있다.
Tracing
Tracing은 마이크로서비스 아키텍처에서 발생한 Event를 발생한 순서대로 나열해서 보여줍니다.
AWS에서는 Amazon X-Ray가 있고, OSS로는 Zipking, Jaeger, Spring Cloud Sleuth ,pinpoint등이 있습니다. 시간 순으로 요청을 보여주고 어떤 단계에서 성공 혹은 실패를 했는지 보여줌으로써 어떤 구간에서 이벤트가 발생했는지 파악할 수 있습니다.
Spring Cloud Sleuth + Zipkin
MSA 환경에서는 클라이언트의 호출은 내부적으로 여러 단계들을 거쳐서 일어나기 때문에 추적이 쉽지 않다.
추적을 하기 위로서는 서로 연관된 ID(span, trace)가 필요한데, 이를 자동으로 생성해주는 것이 Spring Cloud sleuth이다.
Trace ID
- 최초 호출시 실행되는 서비스에서 생성
Span ID
- 하나의 작업 단위, 각 서비스 호출시 새로운 Span ID가 생성
- Trace중 첫번째 생성된 Span ID를 Root Span이라 부름
참조
'세션 > MSA' 카테고리의 다른 글
| 4. Backing Service (0) | 2024.04.02 |
|---|---|
| 2. Service Mesh (0) | 2024.03.29 |
| 1. API Gateway (0) | 2024.03.29 |