10. 모니터링 시스템과 장애관리 조직 필요성
대규모 인프라관리는 모든 업무는 시스템화되어야 한다.
사람이 일일이 챙기는 게 아니고, 시스템적으로 프로세스화되어 있어야 한다.
프로세스가 없어 관리 안 되는 경우도 있다.
너무 프로세스가 있어 업무가 안 되는 기업도 본다 - -
<1> 모니터링 시스템에 대한 구분
<2> 서버 모니터링
<3> 서비스 모니터링
<4> 장애관리 조직 필요성
<1> 모니터링 시스템에 대한 구분
모니터링은 서버 모니터링과 서비스 모니터링 2가지가 있다.
1) 서버모니터링
서버 여러 대중 1대라도 죽는 경우 모니터링하는 것을 말한다.
2) 서비스 모니터링
사용자 입장에서 서비스가 안 되는 경우 모니터링하는 것을 말한다.
일반 기업은 서버 모니터링을 하고 있으나, 서비스 모니터링 부분이 부족한 경우가 많다.
왜냐하면, 서비스 모니터링하기 위해서는 전담 모니터링 조직과 전용 모니터링툴, 개발부서의 많은 지원이 필요하기 때문이다.
서버를 모니터링하는 것과 서비스를 모니터링하는 것은 다르다.
<2> 서버 모니터링
1
서버 여러 대중 1대라도 죽는 경우 모니터링하는 것을 서버 모니터링이라 한다.
2
용어 통일
서버가 전원문제등으로 다운될 시 '서버 1대 다운이 발생했다' 또는
'서버 1대 폴트(Fault)가 발생했다'라고 이야기하기로 하자.
서버 장애가 발생했다고 하지 말자.
장애는 서비스가 안 된 경우 장애라고 하도록 하자.
3
모니터링 인원
IDC에 24시간 근무하는 OP근무자가 서버 물리적인 다운이나 애플리케이션 다운을 모니터링한다.
4
모니터링 툴
이를 모니터링하는 툴은 주로 쟈빅스, 나기오스, 자체개발 에이젠트 등을 사용한다.
보통 서버에 에이젼트를 설치하는 방식을 사용한다.
자빅스(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
자체개발 툴 등 수십 가지 다양한 모니터링 툴이 있다.
5
처리 담당자
2대 이상의 서버로 이중화되어 운영 중인 경우,
서버 1대가 다운되더라도 서비스에는 이상이 없다 = 사용자가 해당 게임을 계속 잘하고 있다.
이경우는 대부분 실무 담당자(인프라, 개발담당자) 선에서 처리가 끝난다.
6
처리 프로세스
각 기업의 정책에 따라 다르지만 일반적으로 서버다운은
인프라담당자, 어플케이션 다운은 개발자가 처리한다.
24시간 근무하는 OP근무자가 모니터링툴을 통해 모니터링하다,
서버 물리적 다운이나 네트워크 접속이 안 되는 부분이면, 인프라 담당자에게 연락한다.
서버에 올라간 애플리케이션(데몬)이 다운되는 경우 개발자에게 연락해 조치하게 된다.
기업의 정책에 따라 OP근무자가 1차적으로 애플리케이션(데몬) 다운을 조치하기도 한다.
<3> 서비스 모니터링
1
서비스 모니터링은?
사용자 입장에서 서비스가 안되는 것을 모니터링하는 것을 서비스 모니터링이라고 한다.
2
서비스 모니터링 예)
1) 네트워크장비나 스토리지가 죽어 사용자가 정상 서비스를 받지 못하는 경우
2) 애플리케이션 성능장애로 사용자가 정상 서비스를 받지 못하는 경우
3) 서버 2 대중 2대가 다 죽어 사용자가 정상 서비스를 받지 못하는 경우
3
모니터인원
1) 일반 회사는 24시간 근무하는 IDC OP근무자가 서버와 서비스 모니터링을 같이 한다.
2) 대규모 시스템을 운영하는 회사는 전담 서비스 모니터링 조직이 24시간 집중모니터링한다.
4
모니터링 툴
1) '서비스 전용 모니터링'툴을 사용한다.
Topaz와 아르고스 등과 같이 사용자단부터 서버까지 모니터링을 하는 툴이용한다.
2) 또는, 서버 모니터링툴을 이용하여 서비스 모니터링한다.
서버에 개발자가 서비스 로직이 포함된 스크립트를 만들고, 서버 모니터링 툴을 이용해 그 스크립트를 감시하는 방법이다.
5
조치
1) 서비스 모니터링 툴로 24시간 모니터링하다
이벤트가 발생 시 , 변경관리시스템을 통해 작업인지 확인한다.
2) 작업이 아닌 경우 PC나 스마트폰으로 재현해 본다.
3) 오류로 확인되면, 장애전파 시스템을 통해 장애 전파를 한다.
이때 장애전파시스템에 해당 서비스 담당자로 되어있는
인프라/개발/사업 담당자에게 동시에 장애 전파가 된다.
4) 각 담당자는 담당 영역에서 이슈가 없는지 점검하고,
메신저상으로 커뮤니케이션하며 장애처리를 한다.
5) 서비스 모니터링 조직은 장애해결 전파를 한다.
24시간 근무서는 전문기술 조직이 있다면, 해당 부서에서 선조치 후 공유를 하는 경우도 있다.
<4> 장애관리 조직 필요성
1
서비스 모니터링과 장애전파 조직은 대부분 사업부 요청으로 만들어진다.
장애가 생겨도 모르고, 조치도 제대로 되고, 장애보고서도 제대로 정리가 안되고,
다음 장애가 안 일어나게 되는지 확인이 힘들기 때문에, 이를 대신해주는 조직이 필요하다.
장애가 반복되면 요청은 더 자주 일어나게 된다.
2
장애가 반복되는 이유
근원적인 조직문제나 비용 문제는 해결하지 않고, 사람이 무조건 해주기를 바라기 때문에 장애는 반복된다.
프로세스적으로 기능적으로 개선이 필요하다.
근본 이유를 찾아내고 재발방지 되지 않도록 개선하는 것이 장애관리 조직의 일이 되기도 한다.
3
네이버처럼 여러 데이터 센터를 운영하는 대규모 시스템을 운영하면 서비스 모니터링 24시간 근무자와 인프라 모니터링 24시간 근무자가 각각 필요하다.
일반적으로 크지 않은 규모는 인프라 모니터인 24시간 OP에서 서비스 모니터링을 같이 하면 된다.
단지, 서비스 모니터링 시스템을 별도로 구축한다.
다음은 법적인 요건을 알아보자~
https://brunch.co.kr/@topasvga/70
