IT/모바일
제공 : 한빛 네트워크
저자 : Andy Oram
역자 : 한순보
원문 : The new stage of system monitoring is better integrated
현재의 도구가 수집과 시각화를 더 쉽게 하지만 일을 줄이지는 않는다.
새로운 도구가 시스템 관리자에게 요즘 쏟아져 나오면서, 불과 1년 전 만연했던 "모니터링이 형편없다"는 논의에 대처하고 있다. 오픈 소스와 상용 모두에서 새 도구는 이전보다 유연하고 가벼울 수 있다. 변화무쌍한 클라우드 서버에서도 적절하고, 이벤트 기록과 시각화를 쉽게 한다. 하지만 나는 그 이상인 새로운 수준의 데이터 통합을 기대한다. 다른 컴포넌트 모니터링 도구가 서로 메시지를 보내고 관리자로부터 이벤트 원인을 추적하는 일을 넘겨받을 수 있다면 어떨까?
현재는 시스템 자원, 네트워크 활동, 애플리케이션에 대한 각각 정보 조각을 분리한다. 일반적으로 시스템 관리자는 다음과 같은 작업 흐름으로 문제에 반응해야 한다.
시스템 관리자는 시각화 도구를 좋아한다. 그들에게 현재 가장 중요한 오픈 소스인 Graphite와 수많은 상용 솔루션을 함께 사용한다. 민감한 이슈로 이끄는 그래픽 인터페이스도 소중하다.
예를 들면, Boundary.com은 이벤트를 브라우징할 수 있고, 이벤트 하나를 클릭해 상세 정보 검색을 할 수 있다. Boundary.com은 애플리케이션 트래픽에 집중한다. Technical Services 임원인 Dustin Lawler에 따르면, 이것의 용도는 스트리밍 데이터를 위한 Hadoop 사용처럼 서비스 용량을 검사하는 것과 지속적 통합처럼 새로운 서비스나 변화가 서비스에 미치는 영향을 검사하는 것을 포함한다. 그들을 이벤트도 추적하여, 원인과 영향을 이해하기 위해 애플리케이션 트래픽 양상의 상관관계를 보여준다. 이는 하나의 빅 데이터 솔루션이다. Boundary.com은 최신 데이터 저장소 몇 곳을 사용해 부피를 다룬다. Splunk가 비슷한 이유로 Hadoop 서비스를 제공한다.
더욱 매끄러운 모니터링을 위해, 데이터 수집(data collection)과 연결(linkage)이라는 두 가지 주요 영역에서 발전이 필요하다.
데이터 수집
통합 모니터링 도구를 구축하려면 각 컴포넌트(운영 체제와 애플리케이션)에서 훨씬 많은 데이터를 기록해야 한다. 운영 체제는 디스크 사용량, 네트워크 사용량, 그리고 모든 종류에 대한 풍부한 데이터를 제공한다. 하지만 애플리케이션은 기록하는 것에 대해 여지를 두는 경향이 있다. 둘 다 데이터를 더 많이 저장해야 한다. 많은 관리상의 문제는 오랜 시간에 걸쳐 일어난 기록인 종적인 데이터가 필요하기 때문이다.
최근 VividCortex를 설립한 MySQL 성능 전문가인 Baron Schwartz는 이러한 바람이 (비록 효율적으로 구현되진 않았지만) Configuration Management Database(CMDB)라는 솔루션에 이르게 했다고 내게 말했다. 많은 서버와 애플리케이션에 분산된 것에 대한 이 같은 무언가를 나는 바라고 있다. 모든 데이터를 어떤 중앙 노드에 저장하는 것을 타당하다고 생각지는 않는다. 애플리케이션과 운영 체제가 로컬 노드에 있는 모니터에 관한 (버퍼 크기, 할당 메모리 등의) 데이터와 함께 메시지를 보낼 수 있다면, 어떤 압축된 포맷으로 데이터를 저장할 수 있다. 그래서 시스템 관리자 필드에 몇 가지 표준 프로토콜과 포맷을 정의하고 모든 데이터를 균일한 형태로 제공해야 한다.
그 대신에, 로컬 애플리케이션을 위해 라이브러리를 제공하여 데이터를 저장할 수 있다. 예를 들면, 데이터베이스가 버퍼 사용과 질의에 든 시간 기록을 보관할 수 있다.
어떤 조사에는 원데이터(raw data)가 유용할 테지만, 현실적 이유로 결국 버려야 한다. 데이터를 추적하는 각 앱 혹은 다른 컴포넌트는 요약(최대 사용(peak use), 트래픽 변화율)을 만들어야 한다. 바로 이 요약을 중앙 관리 도구에 보낸다. 시스템 관리자가 필사적이라면, 요약 데이터가 문제를 디버그하는데 충분치 않을 때 특정 노드에서 원데이터를 확인할 수 있다.
예를 들면, 웹 서버가 각 요청을 기록할 수 있으나, 매초 특정 사이트나 도메인별 요청 수와 처리 요청 수 형태로 요약 데이터를 만든다.
그래서 관리자가 다음을 구성할 수 있어야 한다.
예를 들어, 보안 전문가는 의심스러운 IP 주소 목록을 유지하며 그것들이 웹 서버에게 요청했는지를 묻고, 의심스러운 연결과 종료 패턴을 살펴볼 수 있다. (O"Reilly가 곧 그런 기술을 다루는 Network Security Through Data Analysis라는 책을 출간할 것이라서, 내가 여기에서 약간의 마케팅을 할 필요가 있다.) 일반적으로, 보안은 이 기사의 주제와 통합하려 하지 않을 전문적인 기능이다.
연결
이제 네트워크나 호스트의 다른 뷰를 편하게 이동하는 방법을 고려해야 한다. 갑자기 애플리케이션이 느려질 때, 관리자가 시스템 CPU와 메모리 사용량 차트를 요청할 수 있어야 한다. 이는 데이터베이스 관리 시스템의 버퍼 사용량이 운영 체제의 메모리 사용량과 관련 있다는 사실을 모니터링 시스템이 알아야 한다는 것을 의미한다. 숙달된 사람에게 당연하지만, 컴퓨터에는 분명하게 알려줄 필요가 있다.
데이터를 지식으로 전환하려고, 다른 많은 서브 시스템에서 관련 데이터를 애자일 시각화 도구(당신이 기대하는 통계상의 변화를 반영해 변하는 애니메이션)에 전송하기를 원한다. "이 애플리케이션이 일정 이상 버퍼 공간을 사용하면, 운영 체제 메모리 사용량 차트를 만들라."와 같은 규칙을 정할 필요가 있다.
SaaS 솔루션 Librato가 여기에서 제안한 내용을 따르는 간결한 리포팅 메커니즘을 RESTful API와 함께 제공한다. Librato는 많은 독립적인 소스의 통계를 종합할 수 있다. uptime 소프트웨어의 up.time은 또 하나의 종합적이며 통합된 모니터링 도구이다. 모든 서버, 애플리케이션, IT 서비스와 네트워크를 위해 이런 형태로 통합을 약속한다.
Librato의 Fred van den Bosch가 모니터링 데이터 분석과 저장의 미래가 SaaS 도구에 있다고 주장한다. (다른 사람들이 그를 지지하는 것을 들었다.) 그의 블로그 포스팅이 자세히 설명하겠지만, 본질적인 이유는 이것이다. 데이터 수집은 모니터링하는 (애플리케이션과 인프라 구조) 자원 특유의 것이다. 오픈 소스 도구와 애플리케이션의 직접적인 도움으로 효과적으로 할 수 있다. 그러나 거대한 양의 모니터링 데이터에 대한 믿을만한 종합, 분석과 저장은 갈수록 전문가가 만든 SaaS 솔루션에 의지하는 편이 낫다.
도구와 API가 오픈 소스로 개발되는 한 모두가 괜찮아 보인다. 아니라면, 모니터링 분야가 분열되고 다양한 회사가 경쟁하는데, 그들이 협업하여 만들 수 있는 것보다 적은 기능을 제공한다.
연결을 빨리 원하는 명백한 상황 하나는 오류가 폭포수처럼 얽혀 있는 흔한 상황이다. 그 상황에서 웹 서버가 충돌(crash)한 것을 발견한다. 하부 호스트가 충돌하고, 의존하는 클라우드 플랫폼이 충돌해서이다. 시스템 관리자인 Luke Tymowski가 제게 이 시나리오를 지적했다.
모니터링 도구에 구조화된 방식으로 이러한 규칙을 전달해야 한다. 예를 들어, 운영 체제가 지난 5분 동안 사용하지 않은 InnoDB 버퍼 풀 공간이 1MB 미만이 될 때마다 여러 측정 지점에서 사용 가능한 메모리가 얼마인지 보여준다고 하자. 다음 같은 설정 문법을 생각하고 있다.
이제 어떻게 이 요청을 수행하는지 생각해보자.
초기화
중앙 모니터링 소프트웨어는 시시각각으로 MySQL 데이터베이스에 버퍼 풀 크기와 사용 가능한 공간의 양이 중요한 변수라는 것을 알려준다. MySQL은 (Innodb_buffer_pool_pages_free와 같은 다양한 시스템 변수로 관리자에게 보고하며) 이미 사용 가능한 공간을 추적하고 있어, 이것이 충족하기 어려운 요구사항은 아니다. 시나리오에서 MySQL은 사용 가능한 공간이나 크기를 중앙 모니터링 소프트웨어에 보고하지 않는다는 점에 주목하라. MySQL은 단지 이 데이터 지점을 내부적으로 사용해 트리거를 계산한다. 그러나 MySQL은 중앙 모니터링 소프트웨어와 같은 프로토콜을 사용하고, 그 요청을 지원해야 한다. 아니라면, 중앙 모니터링 소프트웨어는 초기화 동안 사용자에게 에러를 보고한다.
중앙 모니터링 소프트웨어가 운영 체제에 비슷한 요청을 보내 사용 가능한 메모리를 보고할 수 있게 한다. 이번에는 실제로 중앙 모니터링 소프트웨어에 정보를 전달한다.
물론 재앙처럼 서버가 오류를 일으키고 경고 없이 정보 수집이나 보고를 멈출 수 있다. 이것은 다른 계층의 심장박동(heartbeat) 모니터링으로 발견해야 한다.
트리거
우리 시스템이 동작하려면, MySQL이 자신의 모니터링 소프트웨어를 유지해야 한다. 물론, 이것을 내부 코드에 친밀하게 결부해야 한다. MySQL은 항상 풀을 플러시(flushing) 하는 액션을 취하려고 이미 메모리 수준을 모니터링한다. 메모리 체크를 만족하려면, InnoDB 버퍼가 메모리 압박을 받을 때 MySQL이 신호를 보내야 한다. 아마도 중앙 모니터링 소프트웨어에 신호가 발생했다는 알림과 그 신호를 표준 프로토콜로 직접 운영 체제에 전달한다. 혹은 아마도 MySQL이 중앙 모니터링 소프트웨어에 알린 후, 차례로 운영 체제에 요청한다. 두 경우에서, 운영 체제가 신호를 듣고 있어야 한다. (인터넷 소켓을 통해 원격 호스트의 중앙 모니터링 소프트웨어의 신호를 받을 수 있고, 이 통신을 전담하는 소켓을 정의해야 한다.)
반응
운영 체제는 이미 사용 가능한 메모리의 테이블을 규칙적인 간격으로 유지하도록 요청받는다. 운영 체제는 5분이 지난 정보는 버릴 수 있다는 것을 안다. 중앙 모니터링 소프트웨어가 그 정보를 요청할 때, 운영 체제는 유용한 정보를 주는 응답을 한다. 비록 이 단순한 예는 원데이터 전송을 해야 하지만, 다른 시나리오에서는 평균 제공처럼 OS가 데이터를 특정 방식으로 압축해야 한다. 중앙 모니터링 소프트웨어는 유명한 시각화 도구를 사용해 데이터를 관리자에게 보여주거나, 독립적인 액션을 하는 데에도 사용할 수 있다. 어떤 경우에서도 관리자가 MySQL 서버가 버퍼 공간이 부족하다는 것을 재빨리 알고, 동시에 운영 체제의 메모리 사용량을 볼 수 있어야 한다.
여러 표준에 관해서 이야기하지만, 내가 제안한 전부는 손쉽게 사용할 수 있는 데이터를 포함한다. 이런 구조가 다수의 시스템 관리자를 많은 머뭇거림과 지연에서 벗어나게 할 수 있다. 예제에서는 매우 단순한 트리거를 보여줬지만, 많은 종적 데이터를 기록해 관리자에게 발생하고 있는 문제를 경고하는 데 사용할 수 있다.
관리자는 트리거 설정과 정보 요청을 선별적으로 해야 한다. 입수한 잘못된 정보를 선택하는 데 심혈을 기울였다는 사실을 알고 매우 화가 날 수도 있다. 그러나 모든 일은 학습 경험이며 다음 차례 모니터링에 포함시킬 수 있다. 그런 모니터링 시스템을 마련하면, 커뮤니티가 Nagios에 대해 오랫동안 한 것처럼 공통 액티비티를 위한 레시피(recipes, 역자주: 방안)와 플러그인을 빠르게 공급할 것이다. 네트워크 효과 덕분에 그 시스템을 채택(adoption)하는 경우가 눈덩이처럼 불어날 수 있다. 더 많은 서버와 시스템을 업데이트하여 통신 프로토콜을 알고 필요한 데이터를 기록한다면, 소프트웨어가 더 많은 서버에서 정보를 얻고 지원을 받게 된다.
모니터링 방법 최적화의 긴급함
시각화와 높은 가용성 아키텍처의 증가로, 뭔가 고장 나려는 것을 알아채는 관리자의 능력을 이미 혹사하고 있다.
Tymowski는 단순한 단일 서버 시나리오가 오래 전에 티어(tiers) 로드 밸런서, Memcached 같은 캐시 서버, 그리고 웹을 통한 전달을 위해 복잡하게 얽힌 다중 데이터 소스에 대한 문제로 바뀌었다고 지적했다.
Schwarts가 말하듯, 두세 개의 물리적 기계를 관리하던 관리자가 이제는 수백 개의 가상 서버를 책임지고 있다. 데이터와 트래픽도 기하급수적으로 증가하며, 코드 개발과 배포 역시 엄청난 속도로 성장했다. 그는 관리자가 생각할 수 있는 모든 것을 측정하려는 과도한 시도가 크기 규모를 모두 확대하므로 실패한다고 지적한다.
인간 지능을 병에 담는다고 할 때, 경험과 (보통) 직관은 어려운 목표이다. 모니터링에서 급격한 발전을 찾는 것은 확실히 그런 목표이다. 하지만 구성 요소들이 감질나게 가까워 보인다.
Dustin Lawler, Slawek Ligus (Effective Monitoring and Alerting의 저자), Baron Schwartz, Luke Tymowski, and Fred van den Bosch의 지적과 비평에 감사한다.
저자 : Andy Oram
역자 : 한순보
원문 : The new stage of system monitoring is better integrated
현재의 도구가 수집과 시각화를 더 쉽게 하지만 일을 줄이지는 않는다.
새로운 도구가 시스템 관리자에게 요즘 쏟아져 나오면서, 불과 1년 전 만연했던 "모니터링이 형편없다"는 논의에 대처하고 있다. 오픈 소스와 상용 모두에서 새 도구는 이전보다 유연하고 가벼울 수 있다. 변화무쌍한 클라우드 서버에서도 적절하고, 이벤트 기록과 시각화를 쉽게 한다. 하지만 나는 그 이상인 새로운 수준의 데이터 통합을 기대한다. 다른 컴포넌트 모니터링 도구가 서로 메시지를 보내고 관리자로부터 이벤트 원인을 추적하는 일을 넘겨받을 수 있다면 어떨까?
현재는 시스템 자원, 네트워크 활동, 애플리케이션에 대한 각각 정보 조각을 분리한다. 일반적으로 시스템 관리자는 다음과 같은 작업 흐름으로 문제에 반응해야 한다.
- 경보를 일으킨 액티비티를 찾는다. 예를 들면, 오류가 발생한 애플리케이션.
- 새너티 체크(sanity checks, 역자주: 에러 진단 코드로 검사)를 몇 가지 실행한다. 액티비티가 동작하던 호스트가 실행 중인지 확인하고, 애플리케이션 로그 파일을 살펴봐서 오류 전에 무슨 일이 있었는지 등을 살펴본다.
- 호스트에서 CPU가 과부하였는지, 애플리케이션이 크리티컬 디렉터리에 접근하지 못했는지 같은 관련 문제를 살펴본다. 문제 원인을 만족스럽게 찾을 때까지 이 단계를 반복한다.
시스템 관리자는 시각화 도구를 좋아한다. 그들에게 현재 가장 중요한 오픈 소스인 Graphite와 수많은 상용 솔루션을 함께 사용한다. 민감한 이슈로 이끄는 그래픽 인터페이스도 소중하다.
예를 들면, Boundary.com은 이벤트를 브라우징할 수 있고, 이벤트 하나를 클릭해 상세 정보 검색을 할 수 있다. Boundary.com은 애플리케이션 트래픽에 집중한다. Technical Services 임원인 Dustin Lawler에 따르면, 이것의 용도는 스트리밍 데이터를 위한 Hadoop 사용처럼 서비스 용량을 검사하는 것과 지속적 통합처럼 새로운 서비스나 변화가 서비스에 미치는 영향을 검사하는 것을 포함한다. 그들을 이벤트도 추적하여, 원인과 영향을 이해하기 위해 애플리케이션 트래픽 양상의 상관관계를 보여준다. 이는 하나의 빅 데이터 솔루션이다. Boundary.com은 최신 데이터 저장소 몇 곳을 사용해 부피를 다룬다. Splunk가 비슷한 이유로 Hadoop 서비스를 제공한다.
더욱 매끄러운 모니터링을 위해, 데이터 수집(data collection)과 연결(linkage)이라는 두 가지 주요 영역에서 발전이 필요하다.
데이터 수집
통합 모니터링 도구를 구축하려면 각 컴포넌트(운영 체제와 애플리케이션)에서 훨씬 많은 데이터를 기록해야 한다. 운영 체제는 디스크 사용량, 네트워크 사용량, 그리고 모든 종류에 대한 풍부한 데이터를 제공한다. 하지만 애플리케이션은 기록하는 것에 대해 여지를 두는 경향이 있다. 둘 다 데이터를 더 많이 저장해야 한다. 많은 관리상의 문제는 오랜 시간에 걸쳐 일어난 기록인 종적인 데이터가 필요하기 때문이다.
최근 VividCortex를 설립한 MySQL 성능 전문가인 Baron Schwartz는 이러한 바람이 (비록 효율적으로 구현되진 않았지만) Configuration Management Database(CMDB)라는 솔루션에 이르게 했다고 내게 말했다. 많은 서버와 애플리케이션에 분산된 것에 대한 이 같은 무언가를 나는 바라고 있다. 모든 데이터를 어떤 중앙 노드에 저장하는 것을 타당하다고 생각지는 않는다. 애플리케이션과 운영 체제가 로컬 노드에 있는 모니터에 관한 (버퍼 크기, 할당 메모리 등의) 데이터와 함께 메시지를 보낼 수 있다면, 어떤 압축된 포맷으로 데이터를 저장할 수 있다. 그래서 시스템 관리자 필드에 몇 가지 표준 프로토콜과 포맷을 정의하고 모든 데이터를 균일한 형태로 제공해야 한다.
그 대신에, 로컬 애플리케이션을 위해 라이브러리를 제공하여 데이터를 저장할 수 있다. 예를 들면, 데이터베이스가 버퍼 사용과 질의에 든 시간 기록을 보관할 수 있다.
어떤 조사에는 원데이터(raw data)가 유용할 테지만, 현실적 이유로 결국 버려야 한다. 데이터를 추적하는 각 앱 혹은 다른 컴포넌트는 요약(최대 사용(peak use), 트래픽 변화율)을 만들어야 한다. 바로 이 요약을 중앙 관리 도구에 보낸다. 시스템 관리자가 필사적이라면, 요약 데이터가 문제를 디버그하는데 충분치 않을 때 특정 노드에서 원데이터를 확인할 수 있다.
예를 들면, 웹 서버가 각 요청을 기록할 수 있으나, 매초 특정 사이트나 도메인별 요청 수와 처리 요청 수 형태로 요약 데이터를 만든다.
그래서 관리자가 다음을 구성할 수 있어야 한다.
- 어떤 종류와 밀도(resolution)로 각 애플리케이션의 데이터를 기록해야 하는지
- 원데이터를 얼마나 오래 보존해야 하는지
- 원데이터에서 어떤 요약 데이터를 생성해야 하는지
- 요약 데이터를 얼마나 오래 보존해야 하는지
예를 들어, 보안 전문가는 의심스러운 IP 주소 목록을 유지하며 그것들이 웹 서버에게 요청했는지를 묻고, 의심스러운 연결과 종료 패턴을 살펴볼 수 있다. (O"Reilly가 곧 그런 기술을 다루는 Network Security Through Data Analysis라는 책을 출간할 것이라서, 내가 여기에서 약간의 마케팅을 할 필요가 있다.) 일반적으로, 보안은 이 기사의 주제와 통합하려 하지 않을 전문적인 기능이다.
연결
이제 네트워크나 호스트의 다른 뷰를 편하게 이동하는 방법을 고려해야 한다. 갑자기 애플리케이션이 느려질 때, 관리자가 시스템 CPU와 메모리 사용량 차트를 요청할 수 있어야 한다. 이는 데이터베이스 관리 시스템의 버퍼 사용량이 운영 체제의 메모리 사용량과 관련 있다는 사실을 모니터링 시스템이 알아야 한다는 것을 의미한다. 숙달된 사람에게 당연하지만, 컴퓨터에는 분명하게 알려줄 필요가 있다.
데이터를 지식으로 전환하려고, 다른 많은 서브 시스템에서 관련 데이터를 애자일 시각화 도구(당신이 기대하는 통계상의 변화를 반영해 변하는 애니메이션)에 전송하기를 원한다. "이 애플리케이션이 일정 이상 버퍼 공간을 사용하면, 운영 체제 메모리 사용량 차트를 만들라."와 같은 규칙을 정할 필요가 있다.
SaaS 솔루션 Librato가 여기에서 제안한 내용을 따르는 간결한 리포팅 메커니즘을 RESTful API와 함께 제공한다. Librato는 많은 독립적인 소스의 통계를 종합할 수 있다. uptime 소프트웨어의 up.time은 또 하나의 종합적이며 통합된 모니터링 도구이다. 모든 서버, 애플리케이션, IT 서비스와 네트워크를 위해 이런 형태로 통합을 약속한다.
Librato의 Fred van den Bosch가 모니터링 데이터 분석과 저장의 미래가 SaaS 도구에 있다고 주장한다. (다른 사람들이 그를 지지하는 것을 들었다.) 그의 블로그 포스팅이 자세히 설명하겠지만, 본질적인 이유는 이것이다. 데이터 수집은 모니터링하는 (애플리케이션과 인프라 구조) 자원 특유의 것이다. 오픈 소스 도구와 애플리케이션의 직접적인 도움으로 효과적으로 할 수 있다. 그러나 거대한 양의 모니터링 데이터에 대한 믿을만한 종합, 분석과 저장은 갈수록 전문가가 만든 SaaS 솔루션에 의지하는 편이 낫다.
도구와 API가 오픈 소스로 개발되는 한 모두가 괜찮아 보인다. 아니라면, 모니터링 분야가 분열되고 다양한 회사가 경쟁하는데, 그들이 협업하여 만들 수 있는 것보다 적은 기능을 제공한다.
연결을 빨리 원하는 명백한 상황 하나는 오류가 폭포수처럼 얽혀 있는 흔한 상황이다. 그 상황에서 웹 서버가 충돌(crash)한 것을 발견한다. 하부 호스트가 충돌하고, 의존하는 클라우드 플랫폼이 충돌해서이다. 시스템 관리자인 Luke Tymowski가 제게 이 시나리오를 지적했다.
모니터링 도구에 구조화된 방식으로 이러한 규칙을 전달해야 한다. 예를 들어, 운영 체제가 지난 5분 동안 사용하지 않은 InnoDB 버퍼 풀 공간이 1MB 미만이 될 때마다 여러 측정 지점에서 사용 가능한 메모리가 얼마인지 보여준다고 하자. 다음 같은 설정 문법을 생각하고 있다.
when mysql::innodb::pool+1mb > mysql::innodb_buffer_pool_size get os:free for n = now-5min to now ;해당 문법이 호스트 명도 요구할 수 있지만, 아마도 파서가 MySQL이 실행 중인 호스트에 요청할 수도 있다. 다른 소스의 설정 정보에서 호스트를 알 수도 있다. 파서는 정보를 준 "os"가 영향받은 MySQL 서버를 실행하고 있는 운영 체제라고 짐작한다.
이제 어떻게 이 요청을 수행하는지 생각해보자.
초기화
중앙 모니터링 소프트웨어는 시시각각으로 MySQL 데이터베이스에 버퍼 풀 크기와 사용 가능한 공간의 양이 중요한 변수라는 것을 알려준다. MySQL은 (Innodb_buffer_pool_pages_free와 같은 다양한 시스템 변수로 관리자에게 보고하며) 이미 사용 가능한 공간을 추적하고 있어, 이것이 충족하기 어려운 요구사항은 아니다. 시나리오에서 MySQL은 사용 가능한 공간이나 크기를 중앙 모니터링 소프트웨어에 보고하지 않는다는 점에 주목하라. MySQL은 단지 이 데이터 지점을 내부적으로 사용해 트리거를 계산한다. 그러나 MySQL은 중앙 모니터링 소프트웨어와 같은 프로토콜을 사용하고, 그 요청을 지원해야 한다. 아니라면, 중앙 모니터링 소프트웨어는 초기화 동안 사용자에게 에러를 보고한다.
중앙 모니터링 소프트웨어가 운영 체제에 비슷한 요청을 보내 사용 가능한 메모리를 보고할 수 있게 한다. 이번에는 실제로 중앙 모니터링 소프트웨어에 정보를 전달한다.
물론 재앙처럼 서버가 오류를 일으키고 경고 없이 정보 수집이나 보고를 멈출 수 있다. 이것은 다른 계층의 심장박동(heartbeat) 모니터링으로 발견해야 한다.
트리거
우리 시스템이 동작하려면, MySQL이 자신의 모니터링 소프트웨어를 유지해야 한다. 물론, 이것을 내부 코드에 친밀하게 결부해야 한다. MySQL은 항상 풀을 플러시(flushing) 하는 액션을 취하려고 이미 메모리 수준을 모니터링한다. 메모리 체크를 만족하려면, InnoDB 버퍼가 메모리 압박을 받을 때 MySQL이 신호를 보내야 한다. 아마도 중앙 모니터링 소프트웨어에 신호가 발생했다는 알림과 그 신호를 표준 프로토콜로 직접 운영 체제에 전달한다. 혹은 아마도 MySQL이 중앙 모니터링 소프트웨어에 알린 후, 차례로 운영 체제에 요청한다. 두 경우에서, 운영 체제가 신호를 듣고 있어야 한다. (인터넷 소켓을 통해 원격 호스트의 중앙 모니터링 소프트웨어의 신호를 받을 수 있고, 이 통신을 전담하는 소켓을 정의해야 한다.)
반응
운영 체제는 이미 사용 가능한 메모리의 테이블을 규칙적인 간격으로 유지하도록 요청받는다. 운영 체제는 5분이 지난 정보는 버릴 수 있다는 것을 안다. 중앙 모니터링 소프트웨어가 그 정보를 요청할 때, 운영 체제는 유용한 정보를 주는 응답을 한다. 비록 이 단순한 예는 원데이터 전송을 해야 하지만, 다른 시나리오에서는 평균 제공처럼 OS가 데이터를 특정 방식으로 압축해야 한다. 중앙 모니터링 소프트웨어는 유명한 시각화 도구를 사용해 데이터를 관리자에게 보여주거나, 독립적인 액션을 하는 데에도 사용할 수 있다. 어떤 경우에서도 관리자가 MySQL 서버가 버퍼 공간이 부족하다는 것을 재빨리 알고, 동시에 운영 체제의 메모리 사용량을 볼 수 있어야 한다.
여러 표준에 관해서 이야기하지만, 내가 제안한 전부는 손쉽게 사용할 수 있는 데이터를 포함한다. 이런 구조가 다수의 시스템 관리자를 많은 머뭇거림과 지연에서 벗어나게 할 수 있다. 예제에서는 매우 단순한 트리거를 보여줬지만, 많은 종적 데이터를 기록해 관리자에게 발생하고 있는 문제를 경고하는 데 사용할 수 있다.
관리자는 트리거 설정과 정보 요청을 선별적으로 해야 한다. 입수한 잘못된 정보를 선택하는 데 심혈을 기울였다는 사실을 알고 매우 화가 날 수도 있다. 그러나 모든 일은 학습 경험이며 다음 차례 모니터링에 포함시킬 수 있다. 그런 모니터링 시스템을 마련하면, 커뮤니티가 Nagios에 대해 오랫동안 한 것처럼 공통 액티비티를 위한 레시피(recipes, 역자주: 방안)와 플러그인을 빠르게 공급할 것이다. 네트워크 효과 덕분에 그 시스템을 채택(adoption)하는 경우가 눈덩이처럼 불어날 수 있다. 더 많은 서버와 시스템을 업데이트하여 통신 프로토콜을 알고 필요한 데이터를 기록한다면, 소프트웨어가 더 많은 서버에서 정보를 얻고 지원을 받게 된다.
모니터링 방법 최적화의 긴급함
시각화와 높은 가용성 아키텍처의 증가로, 뭔가 고장 나려는 것을 알아채는 관리자의 능력을 이미 혹사하고 있다.
Tymowski는 단순한 단일 서버 시나리오가 오래 전에 티어(tiers) 로드 밸런서, Memcached 같은 캐시 서버, 그리고 웹을 통한 전달을 위해 복잡하게 얽힌 다중 데이터 소스에 대한 문제로 바뀌었다고 지적했다.
Schwarts가 말하듯, 두세 개의 물리적 기계를 관리하던 관리자가 이제는 수백 개의 가상 서버를 책임지고 있다. 데이터와 트래픽도 기하급수적으로 증가하며, 코드 개발과 배포 역시 엄청난 속도로 성장했다. 그는 관리자가 생각할 수 있는 모든 것을 측정하려는 과도한 시도가 크기 규모를 모두 확대하므로 실패한다고 지적한다.
인간 지능을 병에 담는다고 할 때, 경험과 (보통) 직관은 어려운 목표이다. 모니터링에서 급격한 발전을 찾는 것은 확실히 그런 목표이다. 하지만 구성 요소들이 감질나게 가까워 보인다.
Dustin Lawler, Slawek Ligus (Effective Monitoring and Alerting의 저자), Baron Schwartz, Luke Tymowski, and Fred van den Bosch의 지적과 비평에 감사한다.
TAG :
최신 콘텐츠