Recommanded Free YOUTUBE Lecture: <% selectedImage[1] %>

Contents

모니터링

물론 여기에서 말하는 모니터링은 시스템/네트워크 모니터링으로, 클라우드 환경을 대상으로 한다.

왜 클라우드 환경을 대상으로 하냐면, 지금 내가 관리하는 서비스들이 클라우드 위에서 돌아가기 때문이다.

진단이 어려워지고 있다.

증상을 찾아서 문제를 해결할 수 있다면, 진단이 어려울 건 없다. 하지만 시스템이 복잡해 질 수록 특히 진단의 대상이 네트워크화 되어있을 수록 진단을 하기가 힘들어진다.

연결되는 정보소스가 늘어남에 따라서 복잡도가 (산술적이 아닌)기하급수적으로 늘어나는 네트워크 효과 때문이다. 의료진단이 대표적인 케이스가 되겠다. 워낙에 다양한 요인들이 증상의 원인으로 작용하기 때문에 진단을 하려면 현재의 증상뿐만 아니라 개인의 병력, 가족 병력, 주거 환경, 최근 이동 경로(여행 한적이 있는지), 식생활 뭐 엄청나게 많은 요인들을 확인해야 한다.

컴퓨터 분야역시 진단이 중요한 대상이 됐다. 진단의 대상이 된 이유는 컴퓨터가 고성능이 되어서가 아니고, 네트워크로 서로 연결 되었기 때문이다. 다양한 장비, 운영체제, 소프트웨어 들이 묶이고 서로에게 영향을 주다 보니 결과를 예측하고 증상의 원인을 찾는게 어려워졌다.

모니터링 시스템

서비스는 전 지구적으로 전개가 된다. 진단은 점점 어려워진다. 문제가 생겼을 때, 빠르게 대응하지 못하면 돈과 신뢰를 잃어버린다.

해서 모니터링 툴을 이용해서 백데이터를 수집하기 시작했다. 시스템 곳곳에 센서를 부착해서, 센서 정보를 수집해서 분석하겠다는 이야긴데. 목적은 대략 다음과 같다.

문제가 터지기 전에, 문제가 될 만한 부분을 찾아낸다.

모든 문제가 그렇지만 갑작스럽게 빵하고 터지는 일은 드물다. 문제가 터지기 전에 이상징후를 보이기 마련이다. 웹 서비스를 제공하는데, 갑자기 로그인한 유저가 계속 팅긴다.

어.. 데이터베이스에 문제가 생긴건가 ? 데이터베이스를 막 살펴본다. 아무 문제가 없다. 로그인 관리하는 코드가 문제인가 ? 역시 문제가 없다. 뭐가 문제지 ? 알고 봤더니 디스크가 꽉찼더라. 초기에 웹서비스 할 때, 실제 겪었던 문제다. 지금이야 비슷한 류의 문제가 생기면, 디스크 가용량을 먼저 확인하지만 삽질 경험때문에 요령을 터득한 거고.

그때는 반나절정도 삽질을 했다. 원인을 알았을 때의 허탈함이란. 평소에 디스크를 모니터링하고 있었다면, 문제가 터지기 전에 대처가 가능했을 거다.

한 5년전인가 ? ROR을 서비스를 하던 때가 있었다. 몇일 간격으로 주기적으로 뻗는거다. 도대체 왜 뻗는거니 ? 결국 모니터링 시스템을 도입하고 나서야 ROR에 메모리 누수가 있었다는 걸 알아냈다. 유저 요청이 있을 때마다 메모리가 세는데, 결국에는 스왑까지 몽땅 잡아먹고 서비스가 다운되는 거다. 3일 정도 모니터링 툴 돌리다 보니, 메모리 누수가 눈에 보이더라.

문제가 터진 원인을 찾아서 빠르게 대응한다.

시스템/네트워크 관리의 목표는 문제가 터지지 않게 하는데 있지 않다. 서비스들이 클라우드 환경에 올라가면서, 인스턴스 하나가 뻗어도 하나의 네트워크 존이 맛이가도 서비스를 수행할 수 있는 세상에 살고 있다.

예컨데, 클라우드 환경이 도입되기 전에는 고가용성(HA)을 달성하기 위해서는 상당한 돈과 기술, 전문 인력이 필요한 작업이었다. 웹 서비스를 예로 들어보자.
  1. 웹 서버는 두 대 이상으로 구성해야 한다. 이들 웹 서버 앞에는 로드밸런서를 둬야 하는데, 로드밸런서도 이중화 구성을 해야 한다.
  2. WAS도 두 대 이상으로 구성해야 한다. 웹 서버와 WAS 서버사이에 로드밸런서를 두기도 하는데, 마찬가지로 제대로 하려면 로드밸런서도 이중화 구성을 해야 한다.
지금은 ? AWS라면 그냥 ELB 구성 하면 된다.

문제를 빠르게 발견하고, 문제가 발견되면 빠르게 원인을 찾아서 조치하는게 시스템/네트워크 관리의 가장 중요한 목표가 됐다.

성능 튜닝

AWS를 이용하면 초기에 빠르고 쉽게 (글로벌하게)서비스를 전개할 수 있기 때문에 AWS를 이용해서 서비스를 배포하고 있다. 흔히 AWS는 저렴하다고 하지만, 절대로 저렴하지 않다. 저렴하게 사용하기 위해서는 그만큼의 노력이 필요하다.

적절한 타입의 적당한 갯수의 인스턴스 실행. 효율적인 데이터베이스 사용. 좋은 성능의 애플리케이션 선택. 좋은 선택을 위해서는 선택을 도와주기 위한 정보를 수집해야 한다.

Cloud 환경에서의 모니터링 정책

클라우드 환경에서의 모니터링 정책 수립 방향에 대한 나의 생각들을 적어보려 한다.

장애허용

Cloud를 기반으로 하는 서비스들은 장애를 허용하도록 설계한다. 물론 (클라우드 기반이 아닌)베어메탈 장비를 기반으로 하는 서비스들도 장애를 허용하는 것을 기본원칙으로 설계한다. 하지만 클라우드는 그 특유의 유연성을 무기로 "자연스럽게" 장애를 허용하는 환경을 만들 수 있다.

Cloud 환경에서 내 모니터링 정책은 "장애 허용"이다. "장애는 일상적으로 발생할 수 있으며, 중요한 이슈가 아니다"라는 생각을 가지고 정책을 수립한다.
  1. 인스턴스가 죽는 것도 심각한 오류가 아니다. 인스턴스도 죽을 수 있다. 관리자는 단지 인스턴스가 죽었다는 사실만 알고 있으면 된다. 심각하지 않냐고 ? 버튼클릭 한번이면 5분만에 인스턴스를 올릴 수 있다. 서비스를 사용하는 일반 유저에게까지 장애가 확산되지만 않으면 되며, 이는 ELB를 구성하는 것으로 달성할 수 있다. 베어메탈 환경에서도 [wikI:man/12/switch L4 스위치]를 이용하면, 동일하게 구성가능 하다라고 반문할 수 있겠다. 물론 그렇다. 하지만 클라우드 환경에서는 베어메탈 환경과는 비교도 할 수 없을 정도로 간단하고, 유연하게 그 일을 할 수 있다.
  2. 인스턴스는 프로세스와 같다. 고정되서 움직이기 힘든 자원이 아니고, 소프트웨어의 프로세스 처럼 늘렸다 줄였다 할 수 있는 자원이다. 인스턴스 입장에서는 기분이 나쁠 수 있겠다.

모니터링 조직 분류에 따른 정책

모니터링 조직은 아래의 두 개로 나누어서 관리한다.
  1. 인프라 관리 조직 : 인프라 담당자는 클라우드 자원을 관리하는 담당자다. 당연히 이들 담당자는 클라우드 자원에 대한 모든 장애를 확인한다.
  2. 서비스 관리 조직 : 서비스 담당자는 서비스 운영주체다. 서비스를 개발하는 조직이거나 개발조직으로 부터 운영이관을 받은 전문 운영 조직일 수도 있다. 개발과 운영 모두를 처리하는 조직일 수도 있다.
조직을 이렇게 두 개로 나누는 것은 "장애는 일상적인 사건 이라고"간주 하고 있기 때문이다. 인스턴스가 아예 뻗거나 뻗지는 않았는데, 프로세스가 맛이가거나, 데이터베이스가 죽거나 뭐 이런건 시시때때로 일어난다. 시시때때로 일어난다고 해도 서비스에는 문제가 없다. 그러니 사고가 아니고, 이런 문제는 인프라 관리 조직에서 "서비스 영역으로 문제가 확대되지 않도록" 관리해주면 된다.

서비스 관리 조직 에는 굳이 문제의 사실을 알려줄 필요가 없거나 알려주더라도 단문메시지등이 아닌 메일 정도로만 알려주는 걸로 마무리 한다 물론 서비스 수준에서 장애가 발생할경우에는 서비스 관리 조직에도 단문메시지등의 미디어로 통지해야 할 거다. 즉 조직에 따라서 서로 다른 모니터링(통지) 정책이 적용될 수 있어야 한다.

모니터링 발생 범주에 따른 정책

모니터링은 2가지 발생 범주로 나누어서 서로 다른 정책을 적용한다.
  1. 인스턴스 레벨 : 운영체제 레벨의 모니터링이라고 보면 되겠다. 인스턴스가 죽었는지 살았는지와 운영체제에서 얻을 수 있는 정보들 즉, CPU, Meory, 프로세스, Disk, Network traffic, 로그 모니터링등이 여기에 포함된다.
  2. 서비스 레벨 : 앞서 언급했듯이 나는 장애는 일상적으로 발생할 수 있는 사건으로 취급하고, 이에 맞춰 시스템을 구성한다. 대신 서비스에 대한 장애는 1. 99.9999%의 가용성을 유지, 2. 최대한 빠르게 장애를 인지, 3. 최대한 빠르게 장애를 제거 하는 것을 목적으로 한다. 여기에서 서비스 장애란 유저 입장에서의 장애다. 웹 서비스라면, 인터넷 상에서 웹 브라우저를 이용해서 접근이 실패하는 것을 의미한다.
인스턴스 레벨에서 발생하는 장애와 서비스 레벨에서 발생하는 모니터링 정보는 등급을 따로 관리한다. 장애 등급은 중요도에 따라서 1단계 부터 5단계로 나누는게 일반적이다. 인스턴스 레벨에서 발생하는 모니터링 정보는 "1~3 단계"로 취급한다. 이 단계의 모니터링 결과는 인프라 관리 조직에만 통보한다. 서비스 레벨에서 발생하는 모니터링 정보는 "4~5 단계"로 취급한다. 이들 모니터링 결과는 인프라 관리 조직 뿐만 아니라 서비스 관리 조직에까지 즉시 통보한다.

모니터링 시스템 구성 요소

내가 생각하는 모니터링 시스템의 구성이다.

  1. 모니터링 대상
    • 인스턴스(운영체제) 혹은 클라우드에서 제공하는 서비스들 - RDS, SQS, REDIS 같은 -을 모니터링 한다.
    • Zabbix agent로 모니터링한다. 클라우드 서비스의경우 클라우드에서 제공하는 (CloudWatch 같은) API를 이용해서 모니터링 한다.
  2. 모니터링 서버
    • 모니터링 대상으로 부터 메트릭을 수집한다.
    • 수집한 메트릭은 정책에 따라서 이벤트를 발생한다.
    • 나는 zabbix를 사용한다.
  3. SMS & SMTP Server
    • 이벤트는 처리할 수 있는 담당자에게 SMS 혹은 메일로 알려줘야 한다. 중요도에 따라서 전송 미디어를 선택할 수 있어야 한다.
  4. Issue 관리 시스템
    • 이벤트는 SMS & SMTP server와 동시에 Issue 과리 시스템 으로도 발행한다. 나는 Jira를 사용한다.
    • SMS & SMTP와 다른 점은 Open -> In progress -> assign -> Close의 이슈관리 프로세스를 거친다는 점이다.
    • 급한 작업은 SMS로 통지를 하고, Jira를 이용해서 처리하면 된다.
  5. 통합 모니터링 dash board
    • 나는 공개 소프트웨어로 시스템을 구성한다. 전체 시스템을 제대로 관리하기 위해서는 dash board를 제공하는 통합 모니터링 시스템이 필요하다.
    • 나는 moniwiki를 이용해서 개발한다.
  6. 각 구성요소들에 대해서 자세히 정리 한다.

    메트릭 수집 및 분석 시스템

    모니터링 서버가 하는 일이다. 공개 소프트웨어 기준으로 Nagios를 가장 많이 사용하고 다음으로 zabbix를 사용한다. 특징을 정리했다.

    Zabbix
    • HTTP, FTP, SSH, POP3, SMTP, SNMP, MySQL 등 대부분의 주요 프로토콜을 모니터링 할 수 있다.
    • E-mail이나 SMS, 메신저등 다양한 미디어를 이용해서 경고 메시지를 전송할 수 있다.
    • Information, WARNING, ERROR 등 경고 레벨을 설정할 수 있다.
    • Windows, OS X, Linux, FreeBSD를 위한 네이티브 에이전트를 사용할 수 있다.
    • 시나리오 기반의 웹 애플리케이션 모니터링이 가능하다.
    • Template를 지원한다.
    • 파일의 내용을 모니터링 할 수 있다. 정규표현을 지원한다. 나는 주로 보안 감사를 위해서 사용한다.
    • 분산 모니터링을 위한 Proxy를 지원한다.
    • 대시보드를 커스터마이징 할 수 있다.
    • SLA 리포팅
    Nagios
    • HTTP, FTP, SSH, POP3, SMTP, SNMP, MySQL 등 대부분의 주요 프로토콜을 모니터링 할 수 있다.
    • E-mail이나 SMS, 메신저등 다양한 미디어를 이용해서 경고 메시지를 전송할 수 있다.
    • Information, WARNING, ERROR 등 경고 레벨을 설정할 수 있다.
    • Automatic topography display
    • 웹 컨텐트 모니터링
    기능상으로 별 차이가 없다는 이야기가 되겠다. 어느 것을 사용해도 상관 없다.

    장애 통지 시스템

    장애 통지를 위해서 사용할 수 있는 도구들을 정리했다.
    • SMTP : 가장 쉽게 사용할 수 있는 통지 도구다. 단점은 통지 메일이 왔을 때, 정확히 인지하기가 쉽지 않다는 점과 이동 중이거나 네트워크 상황이 좋지 않을 경우 확인이 늦어질 수 있다는 점이다. 뭔가 시스템을 구축하기가 짜증난 다면, AWS의 SMS를 이용하는 것도 방법이다.
    • SMS : 단문 메시지를 이용해서 장애를 통지한다. 빠르고 안정적으로 메시지를 통지할 수 있다는 장점이 있다. 대신 비용이 꽤 쎈편. 국가를 벗어날 경우 사용이 힘들다는 단점도 있다.
    • IRC : 장애 메시지를 실시간으로 확인할 수 있다. 사람과 함께 메시지를 교환할 수 있다는 장점이 있다. 시스템 관리를 위한 IRC Bot을 개발할 수도 있다. 활용성 측면에서 XMPP보다 더 낫다고 생각한다.
    • LINE : LINE은 공식 계정서비스를 제공한다. IRC Bot과 같은 개념의, Bot 서버를 만들어서 LINE 클라이언트 프로그램과 메시지를 주고 받을 수 있다.
    • XMPP : 이놈은 써본적이 없어서 딱히 뭐라고 말 할게 없다.

    장애 이슈 관리 시스템

    발생한 이벤트는 모두 관리해야 한다. 여러 이슈 관리 시스템들 중 Jira를 사용하기로 했다. 사용한 이유는
    1. 기능이 훌륭하고
    2. 개발 없이 지금 즉시 사용가능 하며 : 오픈 소스 소프트웨어들은 당장 사용하기는 힘들다. 원하는 용도로 사용하기 위해서는 개발이 필요한 경우가 많다.
    3. 저렴한 비용
    때문이다. On demand구입할 경우 25인 라이센스 기준으로 월 100 달러, 패키지를 구입할 경우 1,200 달러 정도니 회사 입장에서는 부담도 없다.

    이슈 관리 시스템은 이벤트 통지 시스템과 연동해서 자동으로 이슈를 담당자에게 전송할 수 있어야 한다. 아래와 같이 구성할 수 있다. 구성은 환경에 따라 달라질 수 있는데, 내가 설정한 환경은
    1. 시스템/네트워크 관리 그룹과 개발 그룹이 분리돼 있다.
    2. 여러 개의 서브 프로젝트로 구성된다. 즉 하나 이상의 개발 그룹이 있다.

    시스템/네트워크 관리 그룹과 개발 그룹이 받아보는 Issue는 서로 다르다. 개발 그룹은 "서비스 영역에서의 issue"만 받는다. 서비스에 영향을 주지 않는 다른 이슈들은 시스템/네트워크 관리자 그룹만 받는다. 어느 영역의 이슈인지는 issue level로 구분한다. 서비스 레벨의 이슈는 high이상으로 했고, 나머지 이슈는 high 미만으로 정했다.

    Issue 레벨 정책은 다르게 구성할 수도 있다. 예컨데, 서비스 issue type시스템 관리 issue type을 나누고, 각각의 issue type마다 issue level을 설정하는 방법등이 있다. 나는 단순한 구성을 선호 한다.

    위 구성을 요약하자면
    1. Zabbix에서 모니터링 이슈가 발생하면, Zabbix는 이슈의 호스트 그룹과 유저 그룹, Alarm level를 매개변수로 Jira 이슈를 만든다.
    2. 관리자 혹은 시스템/네트워크 관리자는 우선 메일이나 SMS로 이슈가 생겼음을 확인하고, Jira를 이용해서 이슈를 처리한다.

    이슈 레포팅 시스템

    지금까지 구축한 장애 통지와 관리하는 시스템에는 중요한 헛점이 있다. 서비스 담당자는 "서비스에 영향을 주는 이슈만 관리한다"라는 정책 때문이다.

    하인리히의 법칙이 있다. 큰 재해와 작은 재해, 사소한 사고의 비율은 1:30:300이라는 법칙이다. . 산업재해 예방과 관련된 법칙인데, 시스템/네트워크 관리 분야에도 적용할 수 있다. 현재의 정책은 시스템/네트워트 담당자는 30030을 관리하고, 서비스 담당자는 1을 관리하는 방식이다.

    문제는 30030, 즉 High 미만의 이슈들을 시스템/네트워크 담당자들이 제대로 관리하기는 힘들다는 거다. 첫째, 이슈가 많아지면 판단을 할 수 없다. 둘째, 어떤 이슈와 어떤 모니터링 결과가 서비스에 어느 정도의 영향을 미칠지에 대한 판단은 서비스 담당자들이 제일 잘 안다. 이슈를 분산해서 잘 할 수 있는 조직이 처리할 수 있도록 해야 한다.

    가장 좋은 방법은 모니터링과 이슈를 레포팅하는 거다. 레포트에는 많은 정보를 포함할 필요가 없다. 그날의 이슈들의 목록과 하루, 1주, 1달, 6개월 간의 모니터링 추이만 보여주면 된다.

    1. Jira API를 이용해서, 레포트에 사용할 이슈들을 가져올 수 있다. 서비스 담당자는 어떤 이슈가 얼마나 많이, 자주, 어떤 주기로 발생하는지 그리고 어떻게 처리하는지를 확인할 수 있다.
    2. Zabbix API를 이용해서, 주요 메트릭에 대한 그래프를 그릴 수 있다.
    3. 주기적으로 레포트 메일을 보내면 된다.
    역시 Moniwiki를 기반으로 개발한다.

    지역간 통합 모니터링 시스템 구축

    참고