[MSA] 모니터링 (Monitoring, Logging, Tracing)

MSA(Microservice Acchitecture)에서는 서비스가 분산되어 있는데 모니터링을 어떻게 해야 될까?

 

클라우드 환경에서는 디스크에 기록된 로그들은 사라질 수 있고 수 많은 서비스의 로그를 각각 관리하기는 굉장히 힘들고 시간도 오래 걸린다. 그렇기 때문에 장비의 디스크에 기록하는 것에 의존해서는 안되고 모든 로그들을 한 눈에 볼 수 있도록 구성하여 문제가 발생했을 때 빠른 대처가 가능하다.

 

MSA에서의 모니터링, 로깅, 트레이싱에 대해서 알아보자.

---

모니터링 (Monitoring)

인프라 및 응용프로그램의 성능이나 효율성을 확인하는 작업으로 각 대상에게서 수집한 Metric정보를 통해서 대상 리소스의 사용률, 트래픽 등을 수치로 표현하는 기능을 수행한다. 자체적으로 시각화하여 수치와 그래프로 보여주기도 하지만 더 상세하고 다양한 기능을 위해 시각화 도구와 연동하여 사용하기도 한다.

 

Metric 정보를 수집하는 방법에는 Push와 Pull 2가지 방식이 있다.

 

Push-based System

애플리케이션에서 필요한 데이터들을 직접 모니터링 시스템으로 보내주는 방식이다.

Push-based System

수집 대상이 Auto-Scaling 등으로 가변적일 때는 Push 방식이 유리하다.

Push방식에서는 모니터링 시스템에 수집데이터를 보내주면 되기 때문에 만약 새로운 애플리케이션이 추가되더라도 수집데이터를 보내주기만 하면 된다. 하지만 Metric을 중앙에서 정의하기 때문에 새로운 Metric을 수용하기 위해서는 중앙서버에 계속적으로 해당 변경사항을 반영해줘야 된다.

 

많은 모니터링 시스템들이 Push방식을 사용하고 있고 종류로는 InfluxDB, Graphite, Zabbix, Nagios 등이 있다.

 

Pull-based System

모니터링 시스템에서 모니터링할 애플리케이션에 직접 접속하여 필요한 데이터를 가져가는 방식이다.

Pull-based System

Push 방식과 반대로 애플리케이션에서 직접 데이터를 가져오기 때문에 각 애플리케이션에서 부담이 덜하지만 Pull해야되는 목록을 관리해야 된다.

 

대표적으로 Prometheus, Datadog, collectd 등이 있다.

 

TICK (Telegraf + InfluxDB + Chronograf + Kapacitor)

InfluxDB는 시계열 데이터베이스로 TICK Stack을 구성해서 사용한다.

TICK Stack

Telegraf는 Metric 및 Event를 수집하여 InfluxDB로 보내주는 역할을 하고, InfluxDB에 저장된 데이터를 Chronograf를 통해 웹으로 시각화하여 보고준다. Kapacitor는 필수요소는 아니고 선택사항이며 이벤트 발생을 감지하고 사용자에게 알리는 역할을 한다.

 

Prometheus + Grafana

각 서버에 클라이언트를 띄우고, 서버가 클라이언트에 주기적으로 접속해 데이터를 Pull 방식을 통해 Metric정보를 가져온다. Metric을 이용하면 애플리케이션의 각 시스템에서의 대기 시간과 처리하는 데이터의 양을 추적해서 성능 저하의 원인이 정확히 무엇인지 손쉽게 확인이 가능하다.

Prometheus + Grafana

구조가 간단해서 운영이 쉽고, PromQL이라는 사용자가 실시간으로 시계열 데이터를 선택하고 집계할 수 있는 강력한 쿼리 언어를 제공하며, Grafana라는 시각화 도구와 연동하여 여러 대시보드를 지원하고 있다.

 

장점

• 독립형 서버이기 때문에 광범위한 인프라를 설정할 필요없다.
• 생명주기가 짧은 서비스일 경우 Push Gateway 기능을 지원하고 있어 Push 방식으로 수집이 가능하다.
• 모든 데이터를 수집하지 않고 일정 주기로 Metric을 수집한다.
• Pull 방식이기 때문에 각 서비스 애플리케이션에서 CPU 사용이 불필요하다.
• 많은 양의 Metric 정보를 직접 보지 않고 쿼리를 통해 그때그때 보기때문에 트래픽 및 오버헤드가 감소된다.

단점

• 수집된 데이터가 상세하고 완벽하지 않기 때문에 100%의 정확성이 필요한경우 다른 솔루션을 이용해야 한다.
• 저장공간이 부족할 경우 디스크의 용량을 늘려야한다.
• 재시작할 경우나 Prometheus에 문제가 있을 경우 Metric 정보가 유실될 수 있다.

 

Datadog

데이터독(Datadog)은 서버, 데이터베이스, 클라우드 등에 대한 모니터링 서비스를 제공한다.

Datadog

자체 UI를 통해 대시보드를 제공하며 커스텀 대시보드를 만드는 것도 가능하다.

 

장점

• 여러 분야에 대한 상세한 모니터링이 가능하다.
• 로그 적재를 무제한으로 가능하다.

단점

• 제대로 이용하려면 유료전환이 필요하다.

---

로깅 (Logging)

MSA의 경우 서비스들이 분산되어 있어 각각의 서비스 로그를 한 곳에서 확인할 수 있어야 하는데, 로깅은 대상이 되는 서비스들의 로그를 수집해서 한 곳에서 확인 가능하도록 해주는 기능이다.

 

여러가지 방법이 있지만 대표적으로 Elasticsearch를 활용한 ELK(Elasticsearch + Logstash + Kibana) Stack과 EFK(Elasticsearch + Fluentd + Kibana) Stack이 있고, Grafana Loki를 활용한 PLG(Promtail + Loki + Grafana) 등이 있다.

 

ELK (Elasticsearch + Logstash + Kibana) + Beats

Logstash는 로그 데이터를 수집하고 파싱하는 역할을 수행하고 그 데이터를 Elasticsearch로 보내 분석하고 분석한 내용을 Kibana를 이용하여 시각화한다.

ELK, ELK + Beats

기본적으로 ELK는 Elasticsearch, Logstash, Kibana로 구성되어 있지만,

Logstash는 상대적으로 좀 무거운 편이기 때문에 Beats라는 데이터 수집 기능만 하는 역할이 생기게 되었다.

 

Beats는 데이터 수집을 Logstash는 데이터의 가공(입출력)을 담당하게 변경되었는데, 크게 데이터 가공이 필요 없다면 Logstash없이 Beats만으로도 구성이 가능하다. (Beats에도 필터기능은 있지만 제한적이다.)

 

장점

• 별도의 추가적인 개발 과정이 필요없기 때문에 접근성이 높다.
• Logstash의 역할이 Beats와 분담되어 오버헤드가 감소한다.
• Logstash 없이 Beats만으로 구성이 가능하여 경량화할 수 있다.

단점

• Logstash는 상대적으로 무겁고 메모리 사용량이 높다.
• 재시작시 지속성을 위해서는 외부 큐에 의존이 필요하다.
• Beats만으로 구성이 가능은 하지만 데이터의 입출력이 제한적이다.

 

EFK (Elasticsearch + Fluentd + Kibana) + Fluent-bit

ELK Stack에서 Logstash 대신 Fluentd를 사용하는 스택으로 Fluentd는 인 메모리 또는 디스크를 활용할 수 있는 고도화된 버퍼링 시스템을 지원한다.

EFK

EFK는 ELK의 단점을 보완하면서 나온 스택이라 기능은 거의 비슷하고 훨씬 경량화되어 있다고 생각하면 된다.

 

장점

• Docker, Kubernetes 환경에서 유리하다.
• Logstash에 비해 많이 경량화되었다.
• Fluentd 대신 Fluent-bit만으로 대체하여 더 경량화 가능하다.

로깅의 대표적인 방법은 ELK로 유명한데, EFK를 사용하는 것도 좋은 것 같다.

 

PLG (Promtail + Loki + Grafana)

로그를 수집하고 전달하는 Promtail과 데이터를 저장하는 Loki, 시각화해주는 Grafana로 구성된다.

소개한 3가지 방식 중 가장 가볍다고 사용이 쉽다고 생각된다.

 

Loki는 Grafana에서 제공하는 오픈소스 기반의 로그 집계 시스템으로 다른 로그수집 시스템과 다르게 로그의 label만 인덱싱하고 원본 로그 메시지는 인덱싱하지 않기 때문에 자원소모가 적어 효율적인 운영을 할수있다.

 

장점

• 전체적으로 가볍고 설치가 간편하며 조작이 용이하다.
• 자원소모가 적다.

단점

• LogQL을 지원하지만 고급 쿼리기능은 부족하다.

---

트레이싱 (Tracing)

MSA 구조에서는 서비스에서 다른 서비스를 호출하기 때문에 추적하지 않으면 어디서 호출했는지 확인하기가 어렵다. 이런 이벤트들을 일어난 순서대로 나열해서 보여주는 작업이다.

 

시간 순으로 요청을 보여주고 어떤 단계에서 성공했는지 실패했는지를 보여주기 때문에 어떤 부분에서 오류가 발생했는지를 쉽고 빠르게 확인이 가능하다.

 

대표적으로는 AWS X-Ray, Zipkin, Jaeger 등이 있다.

 

Spring Cloud Sleuth + Zipkin

MSA 환경에서는 클라이언트의 호출은 내부적으로 여러 서비스들을 거쳐서 일어나기 때문에 추적이 쉽지 않다. 추적을 하기 위해서는 서로 연관된 ID가 필요한데, ID를 자동으로 생성해주는 Spring Cloud Sleuth를 사용한다.

Zipkin

서비스에서 트레이스 정보를 수집하여 저장하고, 저장된 정보들을 검색하여 Web UI를 통해 대시보드로 시각화하여 보여준다. 대시보드에서는 기본적으로 서비스, 시간, 어노테이션 기반으로 데이터 확인이 가능하고 Elasticsearch를 사용하고 있다면 Kibana를 통해서도 정보를 보여줄 수 있다.

 

개인적으로 모니터링, 로깅, 트레이싱에 대해 공부하면서 정리를 했는데,

나중에 직접 사용하게 된다면 좀 더 자세하게 작성할 예정이다.