기술자료

DBMS, DB 구축 절차, 빅데이터 기술 칼럼, 사례연구 및 세미나 자료를 소개합니다.

안정적인 서비스를 위한 선택 : 모니터링 시스템 파악하기

기술자료
DBMS별 분류
Etc
작성자
dataonair
작성일
2014-04-07 00:00
조회
9837


◎ 연재기사 ◎


안정적인 서비스를 위한 선택 : 모니터링 시스템 파악하기


안정적인 서비스를 위한 선택 : 모니터링 시스템 구축하기



안정적인 서비스를 위한 선택

모니터링 시스템 파악하기



운영 중인 서비스에 장애가 발생할 경우 유·무형의 적잖은 손실을 야기할 수 있어 많은 기업이 높은 가용성 유지를 위한 노력에 심혈을 기울인다. 필자는 안정적인 서비스를 구현하기 위한 모니터링 시스템을 오픈소스를 활용해 구축하는 방법에 관해 이야기할 것이다.



하나의 서비스를 제공하고자 할 때, 그 서비스 안에는 여러 개의 내부 시스템과 외부 시스템들이 연동돼 구성되는 경우가 많다. 이러한 복잡한 시스템 구성은 장애 관리를 어렵게 할 뿐 아니라, 장애가 발생했을 때 정상화하는 데 더 많은 시간을 요하는 문제가 발생한다. 즉, 장애에 대한 몇 가지 가정을 검증하고 확인하는 데 드는 시간이 길어질 수밖에 없는 것이다. 이 때문에 장애가 발생했을 경우 유·무형의 많은 손실을 입게 되고 서비스 관리자 입장에서는 더 높은 가용성(서비스 사용 가능 시간)을 요구할 수밖에 없다.

필자에게 기업의 안정적인 서비스 구현을 위해 가장 필요한 것이 무엇인지 묻는다면 모니터링이라고 말할 것이다. 서비스 기능이 정상적인지, 사용자가 느끼기에 만족할 만한 성능을 발휘하는지, 서비스는 다운되지 않는지 등을 모니터링하고 관리자에게 알려주는 것이 안정적인 서비스의 핵심이다. 모니터링 시스템은 장애 상황으로 발전하지 않게 사전에 관리자의 판단을 돕고, 고가용성을 유지해 고품질의 서비스를 제공할 수 있게 만들어 준다.



모니터링 시스템이란

모니터링 시스템을 정의하기에 앞서 ‘모니터링’이 무엇인지 먼저 알아보도록 하자. 모니터링이란 시스템 상의 상태 변화를 지속적으로 감시하는 과정이라고 정의할 수 있다. 그래서 모니터링 과정 중에 생산된 데이터를 수집·저장한 뒤 관리자의 의사결정에 큰 도움을 주기 위해서는 단편적인 데이터 제공만으로는 부족하다. 지속적인 감시 과정 속에 생성된 데이터를 관리자가 효과적으로 분석할 수 있도록 실직적인 도움을 주어야 한다. 결론적으로 모니터링 시스템이란 이런 데이터의 수집, 처리, 분석, 표현 등을 구현하는 소프트웨어의 집합이라고 정의할 수 있다. 모니터링을 구현하기 위해 필요한 데이터 수집, 처리, 분석 기술에 대해 알아보자.



모니터링 시스템의 목적

먼저 모니터링 시스템의 목적에 대해 살펴보자. 모니터링 시스템의 목적은 빠른 장애 탐지, 다운타임의 최소화, 의사결정에 도움주기, 자동화 등 네 가지다.

첫 번째는 빠른 장애 탐지이다. 시스템에 장애가 일어났을 때 그것을 빠르게 탐지하는 것은 모니터링의 가장 중요한 역할이다. 장애 파악은 빠른 속도, 정확성이라는 어찌 보면 상충되는 두 가지 목표로 구성된다. 시스템 관리자는 장애가 일어났을 때 문제가 일어난 상황과 시점에 대해 당연히 정확하고 빠르게 알기를 원한다. 하지만 큰 영향을 주지 않는, 무시해도 될 만큼의 일시적인 문제까지 자세하게 보고받고 싶지는 않을 것이다. 즉, 시스템에 문제를 일으킬 만한 수준의 정확한 정보만 신속하게 얻는 것이 중요한 것이다. 하지만 이를 위해 그 수준의 정도를 수동으로 설정하는 것은 매우 어렵다. 알림 한계를 너무 낮거나 높게 설정할 경우 불만족스러운 모니터링 시스템이 구축되기 때문이다. 이와 같이 빠르게 문제를 탐지해 시스템 관리자에게 효과적으로 알림을 제공하기 위해 모니터링 시스템이 필요한 것이다.

두 번째는 다운타임의 최소화다. 서비스를 운영하는 입장이라면 다운타임이란 단어만은 피하고 싶을 것이다. 다운타임이 짧거나 긴 경우 모두 직접적인 유·무형의 손실을 야기하기 때문이다. 시스템이 다운됐을 때 다운타임을 최소화하기 위해 적절한 탐지를 하도록 하는 모니터링 설정이 반드시 필요하다. 모니터링 시스템은 관리자가 개략적인 통계자료부터 세세한 상세 항목까지 검색할 수 있도록 구축해야 한다. 그래야만 표면적인 문제 수정이 아닌 근본적인 원인을 찾아 같은 장애가 발생하지 않도록 할 수 있다. 일반적으로 장애들은 재현하기 어려운 경우가 많은데, 모니터링 시스템이 없다면 장애를 재현하기 위해서 많은 시간의 회귀 테스트를 해야 할 것이다. 그러므로 모니터링 시스템을 통해 장애 위치를 정확하게 찾아내고 상세 항목까지 검색할 수 있다면 장애를 판단하고 조치하는 일이 더 쉬워질 것이다.

세 번째는 의사결정에 도움을 주는 것이다. 관리자들은 사용자의 서비스 이용 형태의 변화에 대한 정확하고 빠른 직관력을 가지길 원한다. 왜냐하면 시스템을 운영하다보면 관리자들이 변화에 맞추어 빠르게 결정을 내려야 할 때가 종종 있기 때문이다. 이런 중요한 상황에서 자신의 시스템을 잘 파악하고 있다면 새로운 결정으로부터 발생할 수 있는 사소한 실수를 줄임으로써 장애를 성공적으로 피할 수 있다. 근거 없는 추정과 행동으로 이어지는 직관력은 큰 장애로 발전할 가능성이 높다. 모니터링 시스템은 이런 추측과 직감을 정확히 확인하는 데 많은 도움을 준다. 그러므로 모니터링 시스템은 현재 상태에 대한 정보를 빠르게 시각화해 제공해야 하며, 축적된 데이터를 의미있는 범위 내에서 관리자가 받아들이고 올바른 기준을 설정하도록 가이드라인을 제시해야 하는 것이다.

네 번째는 자동화이다. 자동화란 장애가 발생했을 때 알림이 작동되고 관리자가 직접 이를 정상화하는 것이 아닌, 모니터링을 통해 예상 가능한 범위의 장애가 발생하면 관리자가 미리 설정해 둔 프로세서대로 시스템이 스스로 이를 수행하는 것이다. 가령 CPU에 부하가 발생했을 때 시스템이 스스로 서버 1대를 추가 연결해 부하를 줄일 수 있어야 한다. 이처럼 모니터링 시스템은 단순한 알림 외에 다운타임을 최소화하기 위한 자동화 관리를 지원할 필요가 있다. 주어진 시나리오대로 시스템이 자동복구를 수행할 수 있어야 중단 없는 서비스를 제공할 수 있기 때문이다.



모니터링 시스템 프로세스

대부분의 모니터링 시스템은 에이전트 모듈을 통해 데이터를 수집하고 이를 분석, 저장, 시각화하는 프로세스를 가진다. 모니터링 시스템의 아키텍처를 구성하는 프로세스에 대해 자세히 알아보자.

tech_img1178.jpg

첫 번째는 데이터 수집이다. 이 단계에서는 서버, 데이터베이스, 네트워크 장비로부터 생성된 다양한 데이터를 에이전트에 의해 수집한다. 예를 들면 시스템 로그 정보, 장비 통계 정보, 시스템 상태 측정 등이 이에 해당된다. 에이전트 모듈은 이런 여러 정보 중에 관리자가 미리 설정한 필요한 메트릭스만 수집해 모니터링 시스템으로 전달한다.

두 번째는 수집된 데이터의 분석이다. 모니터링 시스템은 에이전트로부터 전달 받아 수집된 데이터에 대해 실시간 감시 엔진을 통해 관리자가 사전 설정한 기준으로 정상 여부를 판단한 뒤 운영자에게 알림을 보낼지 여부를 판단한다. 예를 들면 2분간 CPU 평균 사용량이 20% 이상이면 알림을 보내고, 그 미만이면 알림을 보내지 않는 것이다.

세 번째는 데이터의 저장이다. 모니터링 시스템은 에이전트 모듈에 의해 수집된 모든 정보를 사전에 정의된 속성에 따라 분류해 연속적인 데이터로서 저장한다.

네 번째는 시각화 단계이다. 운영자가 알림을 받았다면 현재 상태에 관한 정보를 보기 쉬운 형태로 볼 필요가 있다. 모니터링 시스템은 장애를 식별하고 적절한 조치가 수행될 수 있도록 그래프와 도표 등을 이용해 즉각적인 피드백을 제공해야 한다. 또한 시각화는 알림을 받지 않았을 때에도 여러 의사결정을 하는 데 꼭 필요한 단계이다.



알림 시스템

모니터링 시스템 중 알림 시스템에 대해 자세히 알아보자. 알림 시스템은 실시간 감시 엔진을 통해 중대한 변화를 나타내는 이벤트가 발생할 경우 의미 있 시스템이다. 이제 알림 시스템을 구성하는 주요 기능에 대해 살펴보자.

첫 번째, 알림 시스템은 이메일, SMS, 인스턴스 메신저, 전화 등 다양한 연락 수단과 쉽게 연동이 돼야 한다. 또 발생한 이벤트는 적절한 처리 담당자에게 효과적으로 전달돼야 한다. 예를 들어 <그림 2>와 같은 시나리오를 생각해 보자. <그림 2>의 알림 시나리오는 다음과 같다.

tech_img1179.jpg

tech_img1180.jpg

1. 문제를 감시했을 경우 관리자에게 이메일을 전송한다.
2. 10분이 경과해도 처리가 되지 않으면 관리자에게 SMS를 전송한다.
3. 10분이 경과하면 이슈 시스템으로 등록한다.
4. 30분이 경과하면 2차 보고자들에게 이메일을 전송한다.
5. 1시간이 경과하면 2차 보고자들에게 SMS를 전송한다.

<그림 2>의 시나리오처럼 감지된 이벤트에 따라 시간, 알림 방법, 담당자를 지정할 수 있는 프로세스가 지원된다. 최근에는 이메일, SMS, 인스턴스 메신저, 전화 전달 외에 모바일 푸시 알림 서비스를 지원하기도 한다. 이밖에 외부에서 발생한 이벤트를 빠르게 확인할 수 있도록 모바일 서비스를 지원하는 솔루션도 존재한다.

두 번째는 알림의 구분이 가능해야 한다. 관리자는 발생한 이벤트가 장애일 경우 이를 최대한 빨리 알려 장애가 복구되길 원한다. 반면 무시해도 될 만큼의 일시적인 문제에 대해서는 알림 받기를 원하지 않을 것이다. 이처럼 알림 시스템은 이벤트를 판단해 관리자에게 알려주는 기능이 필요하다.

세 번째는 이슈 시스템과 연동이 가능해야 한다. 대부분의 이벤트는 일시적일 수 있지만, 같은 이벤트가 다시 발생할 수도 있다. 이런 이벤트들은 장애의 원인이 될 수 있다. 무시해도 될 만큼의 일시적인 문제에 대해서는 알림을 발생하지는 않지만 이슈 시스템에 등록해 관리함으로써 추적과 분석을 용이하게 도와줄 수 있다.

알림 시스템을 운영함에 있어서 관리자는 중요한 역할을 수행하게 되는데, 알림 시스템의 기준을 만들고 정상 조건에서 성능과 시스템 동작 수준에 대한 정보를 수집하는 일이다. 이런 조건 설정은 초기 알림 조건 구성을 위한 기본 역할이다. 초기 설정은 메트릭스의 값에 임계값을 정의해 비정상적인 조건을 정의한다. 이상적인 알림 시스템은 실제 장애에 대해 경고를 생성해야 한다. 하지만 이런 설정이 쉽지는 않다.

임계값이 높게 설정돼 있을 경우 시스템은 결국 다운타임으로 이어질 수 있고 성능 저하를 일으킬 위험이 발생한다. 이런 다운타임이 발생할 경우 임계값을 적정한 수준으로 다시 설정해야 한다. 반면 임계값이 낮으면 알림이 자주 발생하게 되므로 좋지 않다.

이상으로 모니터링 시스템을 구성하는 모니터링, 알림 시스템에 대해 알아봤다. 이와 같은 모니터링 시스템이 목적을 달성하기 위해 어떻게 활용되는지 인스타그램의 사례를 통해 알아보자. 인스타그램은 Munin이라는 툴을 이용하는데, 이 툴은 모든 시스템을 그래프(Graph) 형태로 보여주고 정상 범위를 넘기면 경고를 보낸다. Python-Munin 기반으로 많은 Custom Munin plugin을 만들었으며, 시스템 수준이 아닌 것들도 그래프 형태로 표현한다. 예를 들면 분당 등록 유저 수, 초당 사진 등록 수 등이다. 서비스의 외부 모니터링 용도로는 Pingdom을 이용하고 PagerDuty를 사고나 알림을 다루기 위해 사용한다. 파이썬 에러 리포팅을 위해서는 Sentry를 사용한다. Sentry는 Disqus를 포크한 멋진 오픈소스 Django 앱으로, 시스템에 무슨 에러가 발생하고 있는지 실시간으로 등록하고 확인할 수 있다.

인스타그램의 사례처럼 시스템 모니터링, 알림, 로그 리포팅 등을 위해 여러 개의 모니터링 솔루션을 적절히 배합해 사용하는 경우가 많다. 고객에게 안정적인 서비스 환경을 제공하기 위해 많은 업체들이 다양한 모니터링 솔루션을 사용하고 있으며, 이를 통해 빠르고 정확한 정보를 얻고자 하는 것이다.

이와 같이 모니터링 시스템은 내부적인 용도로 사용되는 것이 일반적이다. 그러나 최근에는 페이스북이나 트위터처럼 오픈 API 형태로 서비스를 외부에 공개하는 경우도 있다. 외부 시스템과 연동해 장애가 발생 했을 경우 내부 서비스 문제인지, 혹은 외부 서비스 문제인지 파악할 수 있도록 한 것이다. 자사의 모니터링 정보를 오픈하는 것은 플랫폼 서비스를 제공하는 입장에서 외부 연동 업체들이 이를 안정적으로 사용함으로써 플랫폼 서비스에 대한 신뢰를 얻을 수 있다는 장점이 있다. 페이스북의 경우 플랫폼 Status를, 트위터는 API Status를 통해 현재 제공되는 API의 상태 정보와 관련된 이슈 정보 등을 공유하고 있다.

이처럼 기존에는 내부에서만 사용됐던 모니터링 시스템이 최근에 와서 서비스 형태의 플랫폼 서비스로 발전하고 있다. 플랫폼 서비스 업체의 경우라면 앞의 사례들처럼 외부 업체들을 위해 모니터링 정보를 공개하는 정책도 고려해 볼 수 있겠다.



tech_img1181.png

tech_img1182.png

오픈소스 모니터링 솔루션

이제 모니터링 시스템으로 활용할 수 있는 오픈소스를 소개하고자 한다. 먼저 네트워크, 시스템 분야의 대표적인 오픈소스 Cacti, Nagios, Ganglia, Zabbix에 대해 알아보자. 이런 네트워크 모니터링 시스템은 60여개 이상의 오픈소스가 존재한다. 좀더 자세한 내용은 위키피디아의 Comparison of network monitoring systems(goo.gl/ib5Hr6)를 참조하기 바란다.

● Cacti
Cacti의 화면은 RRDTool과 연계돼 있다. RRDTool은 SQL 서버나 다른 구성요소로부터 데이터를 수집한다. Cacti는 트리 구조를 가지고 있는데, 이는 특정 사용자에 대한 보고서를 관리자가 쉽게 작성할 수 있게 해준다. 또 다양한 플러그인과 템플릿, 스크립트 등을 추가할 수 있다. Cacti는 GPL 라이선스로 공개돼 있다.

tech_img1183.png

● Nagios
Nagios는 오픈소스 기반의 모니터링 통합 관제 솔루션이다. Nagios는 클라우드나 서비스 환경을 구성하는 물리 서버 또는 가상화 서버 플랫폼의 전반적인 관제 정보를 제공한다. 시스템에 장애가 발생할 경우 관리자에게 자동으로 알림 메시지를 전달하며 커스터마이징이 가능하다.

tech_img1184.png

● Ganglia
Ganglia는 클러스터 및 고성능 컴퓨팅 시스템(HPC)을 위한 확장 가능한 분산 모니터링 도구이다. BSD 라이선스를 따르는 오픈소스 프로그램이며, 홈페이지(ganglia.sourceforge.net)를 통해 배포되고 있다. 메모리, CPU, 디스크, 네트워크 자원 사용률뿐 아니라 Hadoop dfs, mapred와 관련된 200여개 이상의 Hadoop 성능 지표를 나타낼 수 있다. Ganglia는 기존의 호스트 단위 모니터링 툴과는 달리 클러스터 또는 그리드 등 통합 리소스 모니터링이 요구되는 환경에서 사용된다. Scale-out 형태의 클러스터링을 모니터링하며, 웹 인터페이스를 제공한다.

tech_img1185.png

● Zabbix
중앙 집중형 모니터링 방식의 Zabbix는 모니터링하려는 대상 시스템의 중앙에서 각각의 시스템에 설치돼 있는 에이전트를 통해 모니터링 데이터를 전송받는다. 대시보드 또는 웹 인터페이스를 통해 모니터링하는 방식을 취하고 있다.

tech_img1186.png

다음은 로그 수집과 관련된 오픈소스들이다. 네트워크나 시스템의 상태를 모니터링하는 것만으로는 해당 시점에 대한 에러 정보를 정확히 판단하기 어렵다. 이를 보완하기 위해 다양한 서비스에서 산출되는 로그를 파악해야 한다. 이번에는 로그를 수집하는 오픈소스에 대해 알아보자.

● Sentry
Sentry는 Django 기반의 에러·로그 수집 오픈소스이다. 내장된 TCP/UDP 서버로 동작하며 Python, PHP, Ruby, Node.js, Java 등에서 일어나는 에러와 로그를 수집할 수 있다. 특히 웹 프레임워크인 Django, Flask, Rails, Express 등을 사용할 때 복잡한 설정 없이 잘 호환되어 효과적인 에러 수집 및 분석이 가능하다. Sentry는 BSD 라이선스로 공개돼 있다.

tech_img1187.png

● Logstash
Logstash는 끝없는 데이터 흐름을 보기 좋게 정리해 주는 오픈소스 패키지다. 항목의 구문을 분석해 분류하고 그래프를 그려주어 관리자가 웹 인터페이스를 통해 조사가 필요한 항목을 단계적으로 세분화해서 살펴볼 수 있도록 돕는다. 시스템을 커스터마이징해야 한다면 데이터 흐름에 끼워 넣을 때 필터 플러그인을 만들면 된다. Logstash는 아파치 2.0 라이선스로 배포된다.

● Kibana
Logstash는 기본적인 쿼리를 통해서만 검색이 가능하다는 단점이 있다. Kibana는 기본적인 기능을 제공하는 Logstash와 Elasticsearch 사이에 붙어서 Logstash의 로그 정보를 검색할 수 있는 인터페이스를 제공한다. 관리자는 루신(Lucene) 쿼리를 작성해 원하는 것을 찾으면 된다. 대시보드는 RSS나 기타 몇 가지 표준을 통해 게시가 가능하다. Kibana는 MIT 라이선스에 따라 제공된다.

마지막으로 모니터링 시스템의 자동화를 위한 오픈소스를 소개하도록 하겠다.

● Chef
Chef는 구성 관리에 사용되는 두 가지 주요 도구 중 하나다. 새 시스템용 패키지 설치를 위해 루비로 간단한 코드 작성을 선호하는 사람이라면 Chef가 적당하다. 어떤 패키지를 어떤 순서에 따라 설치해야 하는지에 대한 명령을 작성하면 이를 Chef가 알아서 처리해 준다. 또 여러 일반적인 패키지를 설치할 수 있는 다양한 플러그인을 보유하고 있는 것도 Chef의 특징 가운데 하나다.

● Pupet
Pupet은 많은 기능이 Chef와 동일하지만 필요한 패키지를 지정하기 위한 주 언어가 약간 다르다. Pupet은 사용자에게 종속성 목록을 요청한 다음 필요한 패키지를 어떻게 설치해야 할지 파악해서 모든 요소가 완벽한 준비 상태가 되도록 한다. Pupet 랩은 여러 복잡한 부분을 간소화하는 방대한 플러그인을 보유하고 있다.

● Athena Peacock
Athena Peacock은 서비스 운영을 위한 OS, DMBS, WEB, WAS 등의 설치, 구성, 배포, 패치 관리 등에 필요한 운영 자동화 서버와 에이전트로 구성돼 있다. 소프트웨어 로드 밸런서를 활용한 동적 로드밸런싱 기능 추가와 후단 머신에 대한 다양한 알고리즘 적용, 구성의 관리 기능을 제공한다. Athena Peacock은 GPL 라이선스로 배포된다.

tech_img1188.jpg

<표 1>은 오픈소스 소프트웨어의 라이선스를 비교한 표이다. tech_img1189.jpg

우리는 지금까지 모니터링 시스템의 목표 달성을 위해 네트워크, 시스템, 로그 수집, 자동화 설정을 수행하는 오픈소스 솔루션을 살펴봤다. 운영하는 시스템의 특성이 각각 다르므로 소개한 솔루션들이 모든 사람의 입맛에 딱 들어맞지는 않을 수 있다. 다음 시간에는 모니터링 시스템 아키텍처에 대해 좀더 자세히 알아보고 구축 방법에 대해 설명할 것이다.



필자 메모
이슈 관리 시스템이란
소프트웨어를 개발하다보면 본래의 의도와는 다르게 모든 사항을 파악하는 것이 쉽지 않다.
특히 소프트웨어 제품의 덩치가 커지면 커질수록 그런 현상은 심화된다. 어떤 소프트웨어 상의
문제점이 과거 작업 내용이나 과거 히스토리와 연관돼 있다면, 해당 문제의 크기와 상관 없이
상당한 커뮤니케이션 비용이 발생하게 된다.
또 대부분 이런 문제점의 경우 소프트웨어의 복잡도를 증가시키는 경향이 있다.
이슈 관리 도구는 이를 손쉽게 해결할 수 있도록 도와준다. 모든 이슈의 기록들이
데이터베이스에 저장돼 있어 검색이 가능하다. 덕분에 과거의 일들을 추적할 수 있으며,
이를 통해 정량적 분석이 가능하다.
우선순위와 보고된 문제의 적절한 추적이 가능하고 개인과 팀의 협업을 용이하게 한다.