Chapter 5. 웹 서비스 운용 1 : 시스템 감시의 기본

5.1 시스템 감시의 개론

  시스템을 감시하는 것은 단순히 시스템을 보고 있는 것이 아닌, 시스템의 정상 상태는 어떤 상태인지를 파악해 그 상태가 무너질 경우의 대응 방법을 사전에 확실히 결정해 두는 것이다. 웹 서비스가 사회에서 중요한 역할을 담당하기 시작하면서 사용 중인 웹 사이트가 갑자기 정지되어 버리는 경우 사용자에게 크리티컬 한 문제가 생기기 시작하였고, 서비스를 제공하는 쪽에서는 갑자기 문제가 생겨 의도하지 않은 서비스의 정지나 성능 저하가 일어나지 않도록 문제 발생 시 신속하게 복구하여 정상 상태를 유지하는 것이 가장 중요한 운용 포인트가 되었다. 이렇게 정상 상태를 유지하는 것이 시스템 감시의 목적이며, 시스템 감시는 아래 4가지 항목으로 정의한다.

 

1. '정상 상태'를 감시 항목 + 정상적인 결과의 형태로 정의한다.
2. '정상 상태'가 아닐 때의 대응 방법을 감시 항목마다 정의한다.
3. '정상 상태'인 것을 지속적으로 확인한다.
4. '정상 상태'가 아닌 경우 '정상 상태'로 복구시킨다. 필요에 따라 재발 방지 대책을 강구한다.

  위 4가지 정의는 항상 세트로 구성되어야 하며, 감시 항목은 정상 상태와 대응 방법을 반드시 함께 정의하여야 한다. '복구' 방법이 아닌 '대응' 방법이라 표기하는 이유는 '대응 방법 = 복구 방법'인 경우도 있지만, 현상에 따라서는 복구가 아닌 다른 것을 목표로 하는 경우도 있기 때문에 대응 방법이라 표현하는 것이 적절하기 때문이다. 운용은 시스템 전반적인 구성을 확장시켜가는 것을 말하므로, 시스템 자체뿐만 아니라 절차나 감시의 정의 등도 처음부터 완벽하게 하려 하지 말고 운용을 하면서 수시로 확장시켜가는 것이 바람직하다.

 

  '정상 상태'를 감시 항목 + 정상적인 결과의 형태로 정의하기 위해서는 우선 시스템의 정상 상태를 정의하는 것이 중요하다. 처음에는 요건의 정의나 현황부터 아는 대로 간단하게 정의하고, 운용해 가며 차츰 확장시켜가며 정의하며, 경험자나 감시용 툴에 포함되어 있는 템플릿 등을 활용하여 정의한다. 감시항목과 세트로 한계값도 결정한다. 한계값을 정하는 방법으로는 요구되는 기능적 요건과 비 기능적 요건을 만족하는지 확인하는 것은 물론, 경보(Alert)가 최대한 감소되도록 조정하는 것도 포함한다. 특히 잘못된 경보나 불필요한 경보는 발생하지 않도록 하며, 만약을 위한 경보는 절대 금지임을 새겨두자.

  '정상 상태'가 아닐 때의 대응 방법을 감시 항목마다 정의하는 것은 복구뿐 아니라 신속한 분리, 사용자에 대한 알림 등도 포함하여 시스템 전체가 정상인 상태를 유지하도록 하기 위한 대응 방법을 정의하는 것이며, 우선은 전체적인 방침으로 복구 우선인지 재발 방지 우선인지를 검토하여 협의하는 것이 중요하다. 웹 시스템이나 미디어 사이트는 복구 우선인 경우가 대부분이지만, 일부 업종에서는 재발 방지를 우선으로 하여 근본적인 대응이 될 때까지는 복구를 하지 않는 경우도 있다. 특히 보안에 관련된 사고인 경우에는 미리 방침을 결정해 둠으로써 신속하게 대응할 수 있게 된다. 기술적인 부분 이외에 연락 방법과 같은 운용의 흐름도 고려하여 에스컬레이션 방법(전화, 메일, SMS, 채팅 등)이나 연락 순서 등을 정해 두어 빠른 대응이 될 수 있도록 한다. 이때 대응이 중복되는 것은 좋지 않으므로, 대응에 관한 내용을 먼저 간단히 언급하고 나서 대응을 시작하는 등의 구체적인 대응 방법을 제대로 정해두는 것이 좋다. 대응 방침을 복구 우선으로 결정한 경우에는 분석에 시간을 허비하지 않도록 하여, 문제에 대한 확증이 없더라도 우선은 복구를 서둘러 대응을 해가는 것이 좋다.

 

정해두어야 할 것  - '복구'와 '재발 방지'중 어느 것을 우선으로 할 것인가  - 에스컬레이션 방법과 연락할 순서  - 연락을 받은 후의 대응 방법

 

  '정상 상태'인 것을 지속적으로 확인하기 위해서는 감시 툴을 이용하여 확인한 후 필요에 따라 인력을 함께 이용하는 방향으로 결정한다. 감시에는 지속적인 테스트가 포함되며, 실시간성을 요구하는 초 단위 감시의 경우에는 초 단위의 장애 대응을 요구하는 것과 동일하므로, 감시뿐만 아니라 장애 대응까지 실시하는 것이 좋다. 초 단위의 감시는 매우 높은 빈도로 대응을 해야 한다는 기술적인 이유로 시스템 감시 툴(Nagios, Zabbix 등)과는 다른 툴로 감시를 진행하는 경우가 많다.

  시스템에 이상을 감지했다면 '정상 상태'가 아닌 경우 '정상 상태'로 복구시키기는 1차 대응(잠정 대응)과 2차 대응(근본 대응)으로 나누어 정의 단계에서 결정한 '방침'에 따라 복구 단계를 실시한다. 아무리 정밀하게 시스템 에러를 예상하고 대응 방안을 마련하더라도 예상하지 못한 사고가 발생하는 것은 피할 수 없다. 그럴 때에는 어떻게 할 것인지 연락 절차만이라도 별도로 준비해 두는 것이 좋다. 누구에게 어떻게 연락해야 하며 그 사람이 어떤 권한을 가질 것인가 등을 명확히 해 두는 것이 중요하고, 연락을 받은 쪽은 설령 만약을 위한 또는 불필요한 연락이더라도 감사하는 모습을 보여주어 다음번에도 위축되지 않고 연락할 수 있도록 해야 한다.

  감시 운용이 시작된 후에는 또다시 필요한 항목이나 감시 요구가 생긴다. 감시 항목의 추가나 삭제, 한계값의 변경, 대응 방법의 변경 등 운용 중의 경험을 수시로 절차에 적용하여 절차와 팀을 확장해 나가도록 하자.

 

5.2 시스템 감시의 구현

  시스템 감시의 요령은 가급적 상위 계층에서 실제 사용자의 조작에 가까운 형식으로 성과를 감시하는 것이다. 또한 CPU 사용률이나 디스크 용량 등의 시스템 리소스도 감시하여야 하지만, 시스템 리소스에 대한 감시는 리소스 모니터링과는 별도로 생각하는 것이 좋고, 리소스 모니터링은 정기적으로 1개월, 6개월 단위 등 장시간 동안의 경향을 검토하는 것을 추천한다. 감시 툴은 앞에서 잠깐 언급한 대로 Nagios나 Zabbix가 주로 사용되며 모니터링 툴은 Cacti, Munin, GrowthForecast가 주로 사용된다.

 

감시 툴	Nagios	감시 기능에 특화
	Zabbix	감시 기능 외에 그래프화 기능도 있음
모니터링 툴	Cacti	사용자 관리 기능이 있음. 풀형 데이터 수집
	Mackerel	SaaS형 서비스. 감시도 가능
	Monit	간단함. 사용자 관리 기능은 없음. 풀형 데이터 수집
	GrowthForecast	간단함. 사용자 관리 기능은 없음. 푸시형 데이터 수집

  시스템 감시에는 시스템의 외부 접속 상황을 감시하는 외형 감시와 시스템의 내부를 감시하는 내부 감시가 있다. 그리고 내부 감시에는 서비스 가동 상황 감시와 시스템 리소스 감시가 있다. 감시 항목을 빠짐없이 파악하는 방법론에는 ① 시스템 요건이나 구축 요건으로부터 기능적 요건과 비 기능적 요건을 파악한다. ② 구축한 서버 자체에서 테스트를 작성한다 의 두 가지가 있다. 이 중 ①의 경우에는 시스템 구축 당시 미리 준비할 수 있는 것이므로 우선적으로 고려 후, 그 후 ②도 추가로 실시하는 것도 좋은 방법이다.

 

효과적으로 빠짐없이 감시하기 위한 방법

  감시의 구현에는 액티브 체크와 패시브 체크 2종류가 있는데, 액티브 체크는 감시 서버 쪽에서 능동적으로 체크하는 방법, 패시브 체크는 감시의 대상 쪽에서 이상을 감지하여 감시 서버로 보고하는 방식이다. 액티브 체크의 장점은 이상을 빠짐없이 감시할 수 있다는 점이다. 패시브 체크는 감시 대상이 이상을 보고하지 못하고 다운된 경우 이상을 감지할 수없다. 반면, 액티브 체크는 체크 간격이 돌아올 때 까지는 이상을 감지할 수 없기 때문에 감시 대상이 보고를 할 수 있는 상황에서는 패시브 체크 쪽이 오히려 실시간 성이 높다.

 

감시의 구현 방법

  외형 감시는 설계 단계에서 명확하게 정의해 둔 기능적 요건을 바탕으로 감시 항목을 작성한다. 만약 현재 시스템이 가동 중이나 시스템 초기 구축 문서를 찾을 수 없다면 방화벽의 설정과 서버의 대기 포트를 확인하거나, 리눅스의 방화벽을 사용한다면 iptables 명령어를 이용하여도 확인이 가능하다. 또한 떠 있는 프로세스의 종류 등을 확인하여 감시 항목을 작성할 수 있다. '현재 서버에서 동작하고 있는 프로세스'를 기반으로 외형 감시와 내부 감시, 서비스 감시와 리소스 감시라는 4개의 축을 고려하여 전개한다면 간단한 기능적 요건은 아래와 같다(그 외의 OS별 주요 항목(암묵적인 기능요건과 비기능 요건)은 별도의 서적을 통해 공부하도록 하자).

 

실행 프로세스 수를 확인하자 I/O가 있다면 그것을 확인하자  - 서비스 계통의 네트워크 입출력이 있는가  - 관리 계통의 네트워크 입출력이 있는가  - 서비스 계통의 파일 입출력이 있는가  - 관리 계통의 파일 입출력이 있는가

 

  외형/내부 감시의 대표적 항목은 아래와 같다.

 

구분	내용
외형 감시	- HTTP 응답 코드, 내용, 응답 시간, 크기  - HTTPS 응답 코드, 내용, 응답 시간, 크기  - POP, SMTP, FTP 등의 동작 여부, 메일 송수신이나 파일 PUT/GET 등  - HTTP 시나리오
내부 감시	- CPU 사용률  - 평균 부하  - 디스크별 사용률  - 디스크별 I/O 요구량  - 디스크별 대기 시간  - 네트워크 인터페이스별 트래픽 IN/OUT  - 로컬에서의 HTTP 접속  - 서비스에 사용할 프로세스의 감시(apache, nginx, mysqld 등)  - 시스템적으로 사용할 프로세스의 감시(ntpd, snmpd 등)

 

5.3 장애가 발생했을 때의 대응 방법

  실제로 장애가 발생하면 기본적으로 아래와 같은 흐름으로 대응을 하는 것이 좋다.

 

  기본적으로는 감시 시스템으로부터의 경보를 계기로 대응을 시작하지만, 시스템을 운용하다 보면 감시 시스템뿐만 아니라 사용자나 관계자로부터의 문의가 계기가 되는 경우도 있다. 경보를 접수한 후에는 실제 상황을 확인한다. 일차적으로는 직접 눈으로 사이트의 표시 등을 확인하고, 실제로 현상이 발생하고 있는지를 추가로 확인한다. 실제로 현상이 확인되면 대응 단계로 넘어간다. 하지만 현상이 확인되지 않는 경우에는 무엇을 복구해야 하는지 알 수 없는 상황이 되므로, 기본적으로는 잘못 감지(오탐)된 것으로 인지하여 대응이 불필요하다고 판단한다. 이와 같이 '눈 앞에서는 발생하지 않지만 시스템이나 사용자 측에서는 계속 발생하고 있는' 경우에는 계속해서 재현 방법(발생 조건)을 확인하거나, 빠른 결론을 위해 1차 대응(잠정 대응)을 시도하게 된다. 이 경우 재현 방법이 확인된다고 하더라도 현상이 해소되는 것이 아니기 때문에 재현 방법의 분석에 시간을 허비하기보다 재현 방법은 모르더라도 현상을 해소하는 것이 최선이므로, 재현 방법이나 원인이 확인되지 않더라도 현상을 해소하는 것을 우선으로 1차 대응을 진행하는 것을 염두에 둔다.

  대응할 때에 가장 중요한 것은 당연한 것을 냉정하게 그리고 제대로 처리하는 것이다. 간단한 듯 어렵지만, 1차 대응에서는 해결까지 생각하지 말고 일단 문제를 회피하는 것만으로도 충분하니 신속하게 대응하도록 한다. 주의할 점은 대응 작업을 진행하는 동안의 작업 로그를 남겨야 한다는 것이다. 대응 시에는 우선 서버에 접속하여 상황을 확인한다. 작업 로그를 남기고 있다는 가정 하에, 접속 후 아래 명령어들을 한 번씩 호출해 둔다.

 

명령어	내용
W	시스템의 가동 시간, 로그인 사용자 수, 평균 부하 확인
ss -lnp	네트워크 접속 수, 접속 소스, 접속 목적지, 실행 프로세스와 PID 확인
df -h	디스크의 사용량 확인
top -b -d 1 -n 1	CPU 사용률이 높은 프로세스 확인
top -b -d 1 -n 1 -a	메모리 사용량이 큰 프로세스를 확인
dstat -taf 1 10	CPU 사용률, 네트워크 사용량, 디스크 I/O의 양, 페이징의 양과 추이를 확인

  추가로 미들웨어나 애플리케이션의 로그(액세스 로그, 에러 로그)도 확인하도록 한다. Linux의 '/var/log/messages'에는 시스템의 로그 파일이 있으니 이것도 확인 해 두도록 한다. 실제로 대응 작업을 하는 경우, 가능하면 2인 1조로 작업을 하여 신중하게 한다는 긴장감을 혼자 짊어지지 않도록 하여 긴장감 때문에 실수가 발생하는 일을 미연에 방지하도록 한다. 또한 정지나 삭제 작업 등은 사용자에게 직접 영향을 미치기 때문에 롤백이 효과가 없는 작업은 신중하게 하여야 한다.

  장애 대응 시 중요한 것은 긴장감을 잃지 말고 신속, 정확하게 대응하는 것이다. 대체적으로 사전에 결정한 대로 대응하면 문제가 없기 때문에 우선은 감에 의존하지 않고 사실과 데이터를 살펴보고, 자신의 의견에 구애되지 않기 위해 단념과 포기는 신속하게 결정한다. 또한, 복구가 잘 되지 않더라도 담당자를 책망하지 않아야 한다. 판단 실수, 결과를 책망하지는 않아야 하지만 부실한 대응은 용서하지 않아야 한다. 위는 당연한 것을 당연하게 하는 것뿐이지만 그것이 중요하고도 어려운 일이다. 대응을 완료하였다면 경보 현상이 해소되었는지 확인하고 동시에 다른 현상이 발생하지 않았는지도 확인한다. 어떠한 경우에는 현상을 복구시킨 이후 그 영향으로 다른 문제가 발생하는 경우도 있기 때문이다. 장애 대응 중에는 현상에 집중하기 때문에 시야가 좁아지므로, 한숨 돌린 후 전체적으로 문제가 발생하지는 않았는지 점검하도록 한다.

  장애 대응은 복구가 완료되었다고 해서 종료되지 않는다. 관련된 각 부서에 보고하고 근본적인 대응을 검토하는 등의 사후 작업이 남아있다. 근본적인 대응은 복구 다음날 진행하는 것이 좋다. 시간과 체력에는 한계가 있으므로 너무 서두르지 않는다. 1차 대응(잠정 대응)이나 1차 보고는 신속하게 하고, 2차 대응(근본 대응), 재발 방지, 원인 분석, 상세 보고는 다음 영업일 이후에 한다. 1차 대응과 1차 보고는 최대한 작고, 적게 하여 신속함을 높임으로써 관계자의 걱정을 최대한 빨리 없애주는 것이 중요하다.

 

5.4 대규모 장애 발생 시의 대응 / 5.5 항상 발생하는 장애의 관리와 리뷰

  대규모 장애는 원인은 알지 못하지만 영향이 크다는 것을 알고 있는 경우, 원인은 알고 있지만 영향이 큰 경우, 영향조차도 잘 알지 못하는 경우 등으로 다양하다. 이러한 대규모 장애가 발생한 경우에는 역할을 분담하여 냉정하게 대처하는 것이 중요하다. 분담하여야 하는 역할과 분담할 때의 핵심은 아래와 같다. 최대한 담당자를 적재적소에 배치하여 가능한 일에 전념할 수 있도록 사전에 정의하도록 하자.

 

대응 담당	실제로 조사 및 대응을 한다. 장애 대응은 기술이 부족한 사람이 하게 되면 시간을 들여도 대응이 되지 않으므로 대응 기술을 가진 사람을 지정한다.
정보 관리 담당	언제 어떤 것들을 했는지에 대한 정보를 기록한다. 언제 어떤 상황이었는지를 기록한다. 현재 어떤 상황인지를 계속해서 기록 및 갱신한다.
커뮤니케이션 창구 담당	고객 및 사내의 다른 팀 등과의 소통 창구 역할을 한다.
지휘 담당	전체를 살펴보며 대응할 사항과 순서 및 대응 방법을 선택한다. 정보 관리 담당이 수집, 정리한 정보를 확인하고 대응 방침을 그때그때 조정한다. 대응 담당과 상담하며 대응을 진행해 나간다.
지휘 담당은 무조건 한 사람으로 한다.  - 지휘 담당과 대응 담당이 각자 주어진 것에 전념 할 수 있도록 한다.  - 팀은 소수 정예로 한다. 커뮤니케이션 경로가 늘어나면 비용이 지수함수적으로 증가한다.  - 다만 인해전술을 사용하는 경우는 제외 확실하게 교대제로 한다.  - 겸임은 매우 어렵다

  장애의 영향이 어디까지 미치고 있는지, 조치해야 할 부분이 어디인지를 지속적으로 냉정하게 파악하자. 또한 대규모 장애일 경우 장애에 따른 영향의 수, 종류, 양이 방대해져 의외로 대응 내용을 빠뜨리기 쉬워지므로 빠짐없는 대응을 위해 항상 필요한 대응사항 목록을 작성하여 유지, 관리하도록 하자. 시스템은 방치해 두면 문제가 생기기 마련이고, 장애는 항상 발생한다. 따라서 정기적으로 발생한 장애와 대응 과정을 축적하여 장애를 트래킹 할 수 있도록 한다. 이때, 반드시 장애별로 개별 ID를 부여하여 구분을 할 수 있도록 한다. 장애 리뷰를 진행할 때에는 한 가지 현상에 대해 다수의 경보가 발생하는 경우가 있으므로 리뷰 집계시 이 부분을 잘 처리하도록 한다.