brunch

You can make anything
by writing

C.S.Lewis

by Master Seo May 25. 2016

대규모인프라운영2.모니터링  시스템1

대규모 인프라관리는  모든 업무는 시스템화 되어야 한다.

사람이 일일이 챙기는게 아니고,  시스템적으로 프로세스화되어 있어야 한다.

프로세스가  없어 관리 안되는 경우도 있지만, 너무 프로세스가 있어 업무가 안되는 기업도 본다 - -


오늘은 모니터링 시스템에 대해 간단히 구분 설명 하고자한다 ^^


모니터링은 서버 모니터링과 서비스 모니터링 2가지가 있다.
1)서버모니터링은 서버 여러대중 1대라도 죽는 경우 모니터링 하는것을 말한다.
2)서비스 모니터링은 사용자 입장에서 서비스가 안되는 경우 모니터링 하는것을 말한다.


일반 기업은 서버 모니터링을 하고 있으나, 서비스 모니터링 부분이 부족한 경우가 많다.
왜냐하면, 서비스 모니터링하기 위해서는 전담 모니터링 조직과  전용 모니터링툴 , 개발부서의 많은 지원이 필요하기 때문이다.


서버를 모니터링 하는것과 서비스를 모니터링 하는것은 다르다.

1. 서버 모니터링
서버 여러대중 1대라도 죽는 경우 모니터링 하는것을 서버 모니터링이라한다.

용어정의

서버가 전원문제등으로 다운될시 '서버 1대 다운이 발생했다' 또는 '서버 1대 Fault가 발생했다' 라고 이야기 하기로 하자.

서버 장애가 발생했다고 하지말자.  

장애는 서비스가 안된경우 장애라고 하도록 하자.


모니터링 인원

IDC에 24시간 근무하는 OP근무자가 서버 물리적인 다운이나 어플리케이션 다운을 모니터링 한다.

모니터링 툴

이를 모니터링하는 툴은 주로  쟈빅스,나기오스, 자체개발 에이젠트 등을 사용한다.

보통 서버에 에이젼트를 설치하는 방식을 사용한다.

자빅스(Zabbix) http://www.zabbix.com/
나기오스(Nagios) https://www.nagios.org/downloads/nagios-core/
Ganglia http://ganglia.info/
PRTG https://www.paessler.com/manuals/prtg
제니퍼 http://jennifersoft.com/ko/
What'up Gold http://www.whatsupgold.com/
ping mon http://emcosoftware.com/ping-monitor/download

자체개발

외에 수십가지 다양한 모니터링 툴이 있다.



처리 담당자

2대이상의 서버로 이중화 되어 운영중인 경우, 서버 1대가 다운되더라도 서비스에는 이상이 없다= 사용자가 해당 게임을 계속 잘 하고 있다.
이경우는 대부분 실무 담당자선에서 처리가 끝난다.

처리 프로세스

각 기업의 정책에 따라 다르지만 일반적으로 서버다운은 인프라담당자, 어플케이션 다운은 개발자가 처리한다.
24시간 근무하는 OP근무자가 모니터링툴을 통해 모니터링하다, 서버 물리적 다운이나 네트워크 접속이 안되는 부분이면, 인프라 담당자에게 연락한다.
서버에 올라간 어플리케이션(데몬)이 다운되는경우 개발자에게 연락해 조치하게 된다.
기업의 정책에 따라 OP근무자가 1차적으로 어플리케이션(데몬) 다운을 조치하기도 한다.






2. 서비스 모니터링
서비스 모니터링은 사용자 입장에서 서비스가 안되는것을 모니터링 하는것을  서비스 모니터링 이라고 한다.


서비스 모니터링 예)

1) 네트워크장비나 스토리지가 죽어 사용자가 정상 서비스를 받지 못하는 경우

2) 어플리케이션 성능장애로 사용자가 정상 서비스를 받지 못하는 경우

3) 서버 2대중 2대가 다 죽어 사용자가 정상 서비스를 받지 못하는 경우


모니터인원

1) 일반 회사는 24시간 근무하는 IDC OP근무자가 서버와 서비스 모니터링을 같이 한다.

2) 대규모 시스템을 운영하는 회사는 전담  서비스 모니터링 조직이 24시간 집중모니터링한다.


모니터링 툴  

1)  '서비스 전용 모니터링'툴을 사용한다.

    Topaz 와 아르고스 등과 같이 사용자단부터 서버까지  모니터링을 하는 툴이용한다.


2) 또는, 서버 모니터링툴을 이용하여  서비스 모니터링한다.  

 서버에 개발자가 서비스 로직이 포함된 스크립트를 만들고, 서버 모니터링 툴을 이용해 그 스크립트를 감시하는 방법이다.



조치

1) 서비스 모니터링 툴로 24시간 모니터링하다 이벤트가 발생 시 , 변경관리시스템을 통해 작업인지 확인한다.

2)  작업이 아는경우  PC나 스마트폰을 이용해 재현해본다.

3) 실제 오류로 확인되면, 장애전파 시스템을 통해 장애 전파를 한다.

이때 장애전파시스템에 해당 서비스 담당자로 되어있는  인프라/개발/사업 담당자에게 동시에 장애 전파가 된다.

4) 각 담당자는 담당 영역에서 이슈가 없는지 점검하고, 메신져상으로 커뮤니케이션하며 장애처리를 한다.

5) 서비스 모니터링 조직은 장애해결 전파를 한다.

   24시간 근무서는 전문기술 조직이 있다면, 해당 부서에서 선조치후 공유를 하는 경우도 있다.


필요

서비스 모니터링과 장애전파 조직은 대부분 사업부 요청으로 만들어진다.

장애가 생겨도 모르고, 조치도 제대로 되고, 장애보고서도 제대로 정리가 안되고, 다음 장애가 안 일어나게 되는지 확인이 힘들기 때문에,  이를 대신 해주는 조직이 필요하다.

장애가 반복되면  요청은 더 자주 일어나게 된다.


장애가 반복되는 이유

근원적인 조직문제나  비용 문제는 해결하지 않고,  사람이 무조건 해주기를 바라기 때문에 장애는 반복된다.

근본 이유를 찾아내고 프로세스적으로 개선하는게 서비스모니터링 조직의 일이 되기도한다.




감사합니다.



다음은  작업을  공유하기  위한 '변경관리 시스템'

장애를 빠르게 전파하고 관리하는  '장애 관리 시스템'에 대해 이야기 하고자 한다.

https://brunch.co.kr/@topasvga/4

매거진의 이전글 1.(용어) AWS용어 자세히 알아보자!
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari