바닥부터 알아보는 웹 서비스 모니터링 시스템 구조

어떤 서비스를 운영할 때 그 서비스가 잘 돌아가고 있는지 확인하는 것은 중요하다.

보통 이런 행동을 모니터링 한다고 말한다.

 

웹 서비스가 아니라 다른 다양한 일을 할 때도 모니터링이라는 말은 익숙하다.

"그 서비스 모니터링은 잘 진행되고 있나요?"

와 같이.

 

그런데 웹 서비스는 특히 모니터링이 중요하다.

 

왜냐하면,

'실시간(Realtime)' 으로 돌아가기 때문이다.

 

한 번 돌리면 끝인 프로그램은 솔직히 모니터링이 크게 필요하지 않을 수도 있다.

일단 돌려보고 결과물이 좋으면 그 과정 쯤은 신경쓰지 않아도 된다. 

 

그렇지만 웹 서비스는 실시간 서비스이기 때문에,

어떤 문제가 생길지 알 수가 없어 그 과정을 매 시간 확인해야 한다.

 

그 방법은 눈으로 직접 확인하는 것일 수도 있고,

문제가 생길 것 같을 때, 또는 생겼을 떄 알림을 보내주는 방법일 수도 있다.

 

결과적으로 사용할 모니터링 시스템의 모습은 다음과 같을 것이다.

 

출처: https://play.grafana.org/

위의 그림은 'Grafana'의 사용 예시 페이지인데, 

대시보드에서 여러 그래프들을 확인하게 되어있다.

대부분의 모니터링 시스템이 다음과 같이 생겼을 것이다.

 

그리고 우리는 이런 시스템의 배경이 어떻게 구성되는지를 확인해 볼 것이다.

 

---

어떤 것을 모니터링할까?

구성을 알아보기 전에 어떤 것들을 모니터링 해야할지 부터 알아보려고 한다.

보통 간단하게 세 가지 정도로 구분해 볼 수 있을 것 같다.

 

1. 컴퓨터 자원에 대한 모니터링

컴퓨터의 자원이라면 대표적으로 cpu, memory, disk, network 같은 것들을 말한다.

'내 컴퓨터의 자원이 문제없이 돌아가는가'는 가장 먼저 확인해야할 기본적인 대상들이다.

이런 자원의 모니터링은 'APM(Application Performance Management)' 라고 하여 이미 익숙한 분야이며

이에 대한 솔루션들도 굉장히 많이 존재한다.

 

2. 서비스의 로그에 대한 모니터링

보통 프로그램을 동작할 때는 로그들이 많이 발생한다.

대표적으로는 http API에 대한 로그들, 이외에도 본인이 필요한 정보들(info), 아니면 경고(warning), 오류(error) 등이 있을 것이다.

이런 것들이 보통 모니터링의 대상이 되곤 한다. 

 

3. 저장된 데이터들에 대한 모니터링

요새는 각 서비스별로 적은 수준의 데이터부터 시작해서, 대량의 데이터까지 많은 데이터들을 다룬다.

그리고 그 중에서 유의미한 정보를 통계를 통해서 도출해내기를 원한다.

예를 들면, 최근 수집된 '이벤트 응모' 데이터들에 대해서 추이를 확인하거나 하는 식이다.

 

결론적으로

 

내가 모은 어떤 데이터든 모니터링의 대상이 될 수 있다.

실시간으로 시간에 따른 변화가 있는 데이터라면 모두 모니터링을 할 수 있게 된다.

---

왜 모니터링 시스템의 구조를 알아야 하는가

사실 모니터링 시스템은 굳이 직접 구축할 필요가 없기는 하다.

이미 오픈소스 모니터링 시스템들이 많이 있고,

돈을 내고 기업 단위에서 사용할 수 있는 솔루션들도 많이 있다.

 

특히 요새는 'Prometheus' 라는 괜찮은 오픈소스 모니터링 솔루션도 있다.

이것과 시각화 툴인 'Grafana'를 같이 사용한다면 모니터링 시스템은 어렵지 않게,

그리고 강력하게 구축이 가능하다.

 

그렇다면 굳이 만들 필요가 없는데,

왜 나는 모니터링 시스템을 어떻게 만드는 지에 대하여 설명하려고 하는가. 

또한 내가 이 글을 쓰는 이유는 무엇인가.

 

1. 먼저는 내부적인 구조를 안다면 더 잘 사용할 수 있기 때문이다.

    모니터링 시스템의 개요를 이해한다면 이후에 사용하기도 쉽고, 더 유용하게 사용할 수 있을 것이다. 

 

2. 다음으로는 혹시나 직접 모니터링 시스템을 개발해야 할 일이 생겼을 때 밑그림을 제공하기 위해서이다.

 

---

모니터링 시스템 구성 개요

모니터링 시스템의 구조를 크게 다음과 같이 그림으로 그려 보았다.

 

가장 기본적으로는 다음 그림처럼 세 대의 컴퓨터(또는 서버, 또는 프로그램)가 필요하다.

그리고 추가적으로 그 데이터를 전달하는 두 통로(대체로 네트워크)가 필요하다.

 

각 부분을 간단하게 설명하면 다음과 같다.

 

1. 데이터 수집(데이터 저장소): 필요한 데이터가 저장되는 컴퓨터

2. 데이터 처리(모니터링 서버): 모니터링을 위해서 수집된 데이터들을 가지고 처리하는 컴퓨터

3. 데이터 표현(화면): 모니터링 자료를 실질적으로 보여주는 웹 페이지 또는 앱

 

---

1. 데이터 수집

가장 먼저, 이 부분에서는 각 서비스에 알맞게 데이터를 수집한다.

DB로 만들든 text로 저장을 하든, 아니면 수집 프로그램을 사용하든 다양한 방법이 존재한다.

 

예를 들면,

APM을 위한 자료를 수집하려면 보통은 Agency를 설치하기도 하며,

Java 어플리케이션에서 로그를 수집하려는 경우 각종 로그 라이브러리들을 이용하기도 한다.

그리고 만약 ELK Stack을 사용할 경우 이 부분에서는 Filebeat, Logstash가 사용된다.

 

---

2. 데이터 전달

이제 데이터를 어떻게 서버와 주고 받을지를 결정을 해야 한다.

보통은 모니터링 시스템에서는 두 가지 방법이 있다. 

- Polling: 일정 주기마다 저장된 데이터를 서버에서 불러오는 방법

- Streaming: 연결 통로를 만들어서 데이터가 수집될 때마다 실시간으로 보내는 방법

 

두 방식 중 어떤 것을 선택하느냐에 따라 전체적인 개발 방식이 크게 바뀐다. 

대략적으로 보면 아마도 Polling 방식이 우리가 익숙하며 쉬운 방식일 가능성이 크며,

반면 Stremaing 방식을 도입할 경우, 새로운 기술을 공부해야할 수도 있다.

 

다음부터 두 방식에 대해서 각각 알아보려고 한다.

 

1) Polling

Polling 방법은 모니터링 서버에 주도권이 있다.

서버에서는 일정 시간마다 한 번씩 데이터를 가져오는 식으로 구현하게 될 것이다.

 

예를 들어 데이터 저장소가 DB일 경우라면, 

1분에 한 번씩 '특정 시간 대의 새로운 데이터들 가져오라'는 쿼리를 하면 된다.

 

2) Streaming

스트림(Streaming) 방식은 데이터가 수집되는 대로 나의 모니터링 서버로 전달을 하는 방식이다.

그리고 그 구현은 보통 다른 기술의 도움을 받아 이루어진다.

 

Streaming을 지원하는 Agent를 설치하거나(ELK Stack의 로그수집기 Filebeat),

Messege Queue(Kafka, RabbitMQ) 같은 것들을 사용할 수도 있다.

이외에도 방법은 여러 가지가 있을 것이다.

 

3) 두 방식의 실시간성 비교

실시간성은 일반적으로 Streaming이 우세하다.

데이터가 생기는 족족 서버로 보내기 때문에 무조건 최신의 데이터를 가장 빠른 시간 내에 확인할 수 있다.

아무리 Polling에서 주기를 좁힌들 요청-응답의 두 단계를 거치기 때문에 느릴 수 밖에 없다.

 

게다가 자원 사용 쪽에서도 Streaming이 우세할 가능성이 높다.

왜냐하면 Streaming은 한 번의 Network 연결을 이용하는 반면에,

Polling 방식은 요청마다 Network 연결을 새로 만들기 때문이다.

 

이렇게 보니까 Streaming이 방식이 무조건 좋아보이는데,

사실 직접 구현이 좀 어렵다는 단점이 있다.

 

Polling은 구현 대체로 쉬운 편이다. 만약 DB를 사용할 경우라면 쿼리만 보낼줄 알면 구현이 가능하다.

 

Streaming은 데이터를 실시간으로 받는다고 하더라도,

그것들을 받는 쪽에서는 그 데이터를 집계하는 과정이 복잡하다. 

 

만약 특정 통계를 1분 단위로 내려고 하면,

스트리밍된 데이터들을 모아두고 그것을 처리하는 과정을 따로 만들어야 한다. 

 

이런 복잡한 처리를 위해서 Streaming은 웬만하면 다른 서비스들의 도움을 받는 것이 좋은데,

다행히도 최근에는 스트리밍 처리를 위한 오픈소스들이 많이 나와 있다.

Apache Flink, Kafka Streams API 등을 사용하면 Streaming된 데이터들을 더 쉽게 처리할 수 있다.

 

---

3. 데이터 처리

보통 모니터링 시스템을 개발한다고 하면, 직접 코딩을 해야하는 부분이 바로 이 3번 부분이다.

각자의 언어와 프레임워크를 이 부분에서 선택하게 된다.

 

여기 '데이터 처리' 부분에서는 데이터를 분석하고 집계한다.

즉 모인 무의미한 데이터들을 유의미한 데이터로 가공하는 부분이기 때문에 가장 핵심 부분이라고 할 수 있다.

 

데이터 처리 부분은 웬만하면 위의 '데이터 전달' 에서 선택하는 기술에 따라 결정될 것이다.

전달 부분에서 Polling을 사용하느냐 Streaming을 사용하느냐에 따라 그에 대한 처리가 굉장히 달라지기 때문에,

이번에도 그 두가지를 나눠서 설명하고자 한다.

 

1) Polling 방식을 사용할 경우 데이터 처리

Polling 방식을 사용한다면 데이터를 가져오는 방법은 보통 두 가지를 고민할 수 있다.

보통은 '데이터 전달' 방식에 따라서 달라진다.

 

- 데이터 처리를 저장소에서 직접 진행하고 그 결과만 가져오기

만약 DB를 사용한다면 어떤 데이터든 통계 처리 쿼리를 제공하고 있을 것이다.

DB에서 적절한 Aggregation, Reduce 기능을 수행하면 데이터를 쉽게 가져올 수 있다.

최근에 ElasticSearch를 사용해서 개발을 했었는데, 굉장히 집계 쿼리를 실행하기 쉽게 되어 있었다.

 

- 데이터를 저장소에서 가져와서 모니터링 서버에서 처리하기

두 번째 방식은 데이터들을 가져와서 내 메모리에 저장해 놓고 내 방식으로 처리를 하는 방식이다.

언어에서 각종 라이브러리들을 사용하면 자유롭게 데이터를 다룰 수 있다.

 

두 방법의 가장 큰 차이는 부하가 어디에 존재하느냐이다. 

1번 방법은 저장소에 더 부담을 줄 것이고,

2번 방법은 내 서버가 더 많은 부담을 갖게 될 것이다.

 

2) Streaming 방식을 사용할 경우 데이터 처리

실시간으로 데이터가 밀려들려오는 상황에서 어떻게 데이터들을 가공할 수 있을까.

 

아마도 직접 구현을 한다고 하면 다음의 방법을 사용할 수 있을 것 같다.

특정 시간 동안 들어온 데이터들을 모아서, 내 메모리에 저장한 다음 집계하는 방법이다.

 

최근에는 이런 스트리밍 방식을 위한 오픈소스 라이브러리들이 많이 등장하여 좀 편리해졌다.

특히 최근 많이 사용되는 것으로는 Apache Flink가 있으며,

Kafka를 사용한다면 Kafka Streams API를 사용하면 된다.

 

이런 최신 라이브러리들은 분산처리도 기본적으로 제공하기 때문에

어플리케이션을 확장하기 위한 환경에서도 굉장히 유용할 것이다. 

 

또한 특정 시간대에 대한 배치처리 기능도 존재하기 때문에 데이터들을 다루기가 크게 어렵지도 않다.

---

4. 데이터의 시각화

시각화 부분은 최종적으로 처리된 데이터를 어떻게 화면에 보여주느냐에 대한 부분이다.

보통은 프런트엔드나 앱 개발에서 담당하는 영역이다.

Grafana 같은 시각화 소프트웨어가 이 부분을 담당한다고 볼 수 있다.

위의 '2. 데이터 전달'과 똑같이 여기도 두 가지로 나뉜다.

Polling vs Streaming

 

1) Polling 방식

만약 웹 페이지를 만든다면 가장 간단한 방식은 일정 시간마다 서버에 API를 호출하는 방법이다.

'2. 데이터 전달' 에서 Polling 방식을 사용했다면, 아마 그 시작은 여기에서부터일 것이다.

 

1. 페이지에서 서버로 데이터 호출

2. 서버에서 저장소로 데이터 호출

3. 페이지에서 데이터 렌더링

 

페이지에서는 매 n초마다 한 번씩 위의 과정을 반복하면 된다.

 

2) Streaming 방식

이 방식을 사용한다면 일반적으로는 WebSocket 같은 기술을 이용하면 된다.

한 번 연결을 만들어 놓은 다음, 서버에서 처리된 데이터들을 실시간으로 받아서 렌더링하면 된다.

 

최종적으로,

가져온 데이터들을 이용해서 표나 그래프로 그려주면 된다.

최종적으로 가져온 데이터들을 받아서 각종 FE 라이브러리들을 사용해서 그려주면 된다.

JS에는 괜찮은 Chart 라이브러리들이 많이 존재한다.  

D3.js, chart.js, Google Charts 등 다양하게 있기 때문에 마음에 있는 것들을 사용하면 된다.

 

---

마무리

이 글을 쓰면서 느낀 것은 결국 모니터링 시스템을 구축한다는 것은

하나의 데이터 파이프라인을 구성하는 것과 비슷한 것 같다.

 

데이터를 잘 모으고 그것들을 어떻게 처리하고 확인하느냐에 대한 과정이 동일하기 때문이다.

물론 그와는 다르게 실시간성이 중요하다는 점에서, 조금 더 난이도 있는 어플리케이션임은 확실하다.

 

다시 한 번 말하지만, 아마 모니터링 시스템을 직접 구성할 일은 없을 가능성이 크다.

좋은 모니터링 서비스를 잘 골라 사용하면 된다.

 

이후에 그 서비스를 이용할 때 더 잘 이용할 수 있기를 바라며 이 글을 정리해 보았다. 

과연 이 모니터링 서비스가 Polling을 사용하는지 Streaming을 사용하는지 정도는 알 수 있지 않을까?