cacti 사용기

지난번에 호스팅 업체를 떠나 라이트세일로 이사히면서 깨닫게 된 점 중 하나는 이제부터 서버 모니터링을 내가 직접 해야 한다는 것이었습니다. 호스팅 업체를 사용할 때는 단 한번도 모니터링 비슷한 것에도 신경써본 적이 없었습니다. 서버는 항상 그냥 돌아갔고 자잘한 중단 사고에도 불구하고 제가 사용하는데는 아무런 문제가 없었습니다. 만약 서비스가 중단된다면 저보다 먼저 호스팅 업체에서 문제를 해결해줄 겁니다. 그런데 VPS서비스를 사용하기 시작하면서 이야기가 달라졌습니다. 만약 서비스가 중단되면 제가 다시 확인해보기 전까지는 아무도 알려주지 않았습니다. 같은 사양을 호스팅 업체를 통해 사용하는데 비해서 VPS 서비스가 훨씬 저렴한데는 아마도 이런 이유가 있었겠구나 싶었습니다.

서버 모니터링 방법을 찾아보니 가장 가까이에 클라우드워치라는 제품이 있었습니다. EC2만큼 훌륭하게 통합되어 동작하지는 않지만 라이트세일에도 어렵지 않게 연동할 수 있었고 기초적인 통계를 제공하고 각 지표들이 내가 설정한 임계치를 지날 때 지정한 방법으로 경고하도록 설정할 수 있었습니다. 같은 회사의 VPS서비스를 사용하고 있으니 일단 사용해보기 시작했습니다. 순조롭게 동작했지만 한달이 지나고 청구된 요금을 살펴보니 이건 뭔가 잘못됐다는 생각이 들었습니다. 라이트세일 사용요금은 크게 세 부분으로 나뉩니다. 인스턴스 자체의 사용료, 백업용 스냅샷의 스토리지 사용료, 그리고 트래픽 요금입니다. 지금은 한달에 10달러짜리 인스턴스 번들을 사용하고 있는데 인스턴스 요금 10달러와 백업 비용 3달러 정도를 예상했습니다만 여기에 클라우드워치의 모니터링비용이 7달러 가까이 추가되어 있었습니다.

클라우드워치 요금의 핵심은 매트릭 개수인데 처음 10개까지는 무료지만 그 다음부터는 매트릭 하나 당 0.3달러가 청구됩니다. 그런데 저는 매트릭을 20개 가량 사용하도록 설정하고 있었고 이걸로만 6달러가 추가로 청구된 겁니다. 거대한 비용은 아니지만 VPS 자체의 핵심비용이 10달러인 마당에 모니터링 비용이 그 절반을 초과하는 상황은 영 불편했습니다. 잠깐 고민하다가 아마존에 돈을 내며 빈털터리가 되는 대신 클라우드워치를 대신할 모니터링 방법을 찾아보기 시작했습니다.

이런 질문을 딱히 할만한 대상이 없었기에 구글에게 물어봤습니다. 웹서버 모니터링하는데 사람들이 사용하는 적당한 도구 하나를 선택할 생각이었는데 맨 먼저 그럴싸하게 보인 것은 cacti였습니다. 일단 꽤 오래전부터 개발중인 것 같았고 소스가 공개되어 있었으며 많은 사람들이 사용하고 포럼이 활성화된 것으로 보였습니다. 모니터링에 사용할 가장 작은 인스턴스 하나를 만들고 cacti를 설치했습니다. 설치과정이 썩 편안하지는 않았습니다. 이 도구는 크게 MySQL, SNMP, RRD라는 도구에 의존하고 있었는데 인스톨러가 bitnami LAMP 스택으로 만든 인스턴스에서 문제를 일으켰습니다. 한동안 설치 자체에 트러블슈팅을 시도하다가 우분투만 설치된 인스턴스를 다시 만들고 나서야 설치에 성공할 수 있었습니다.

cacti는 SNMP라는 소프트웨어를 통해 서버의 정보를 얻은 다음 이를 RRD라는 일종의 차량용 블랙박스 메모리 같은 방식으로 기록했다가 이 정보를 그래프로 그려주고 또 내가 설정한 임계점을 넘는 값을 경고해주는 역할을 합니다. 클라우드워치가 거의 아무런 의존성 없이 같은 동작을 했다면 cacti는 방금 이야기한 여러 다른 소프트웨어에 의존해 동작합니다. SNMP를 통해 서버 정보를 얻는 컨셉은 쉽게 이해할 수 있었지만 그걸 왜 RRD라는 이상한 형식으로 기록해야 하는지는 잘 이해할 수 없었습니다. 설명을 찾아보니 여러 산업용 소프트웨어가 장기간에 걸쳐 데이터를 기록할 때 용량이 무한정으로 증가하지 않도록 제한된 공간을 끝까지 사용하면 처음부터 최신 데이터를 기록하거나 오래된 데이터의 정확도를 낮춰 용량을 관리하는 도구처럼 보였는데 그 의도는 이해했지만 요즘처럼 스토리지 가격이 낮은 시대에 웹 모니터링 도구가 이런 데이터 기록 방식에 의존하는 점은 이해할 수 없었습니다. 게다가 이럴거면 MySQL 데이터베이스는 왜 사용하는 건지 이해하려고 잠깐 시도했습니다만 잘 되지 않았습니다.

cacti 사용은 8시간만에 실패로 끝났습니다. 8시간 동안 온갖 트러블슈팅에 시달려야만 했는데 8시간이 지나고나서도 제대로 된 첫 데이터를 얻는데 실패했습니다. 제 상황을 검색해보니 Why I Enthusiastically Switched from Cacti to Zabbix for System Monitoring 같은 글이 있었고 이 분의 경험 역시 저와 비슷했습니다. cacti 트러블슈팅을 중단한 가장 큰 계기는 자꾸 중단되는 코드를 열어 sizeof()를 strlen()으로 고치는 순간이었습니다. 이 거대한 코드 덩어리는 기초적인 수준의 예외처리도 없었고 많은 부분이 아슬아슬한 상태로 돌아가고 있었습니다. 하다못해 제가 한동안 사용하고 있는 도쿠위키는 커밋을 풀 할 때마다 주요 의존성 환경을 바꿔가며 테스트를 거칩니다. cacti는 온갖 환경에 의존성이 있었지만 아무런 테스트도 없어 보였고 PHP 버전이 달라지면 온갖 에러를 뱉어내며 정상 동작하지 않았습니다. 몇몇 코드를 고쳐 한참만에 처음으로 정상 동작하게 만들었지만 그 사이에 겪은 일들은 이 도구에 더이상 의존하다가는 혈압으로 곧 죽겠다 싶었고 인스턴스째로 삭제해버렸습니다.

교훈은 도구를 선택할 때 도구가 얼마나 오래됐는지, 또 얼마나 많은 사람들이 사용하는지, 소스에 접근 가능한지도 중요하지만 이 도구가 얼마나 안정적으로 동작하며 도구의 목적에 집중할 수 있게 해주는지 포럼을 좀 더 관찰해야 한다는 점입니다. 사실 포럼을 둘러볼 때는 대강 글이 어느 정도 빈도로 올라오고 글에 답변이 어느 정도로 되는지를 대강 살펴봤습니다. 하지만 정작 제거 문제를 겪는 상황에서 다시 찾은 포럼은 엄청나게 많은 문제가 쌓여 있을 뿐 각각의 문제들이 제대로 파악되어 수정되지는 않고 있었습니다. 또 워낙 문제가 많은 탓에 답변들은 약간 지쳐 보였고 도구의 핵심에 접근하기는 커녕 의존성의 바다에서 허우적거리게 만들었습니다. 가령 그래프가 안 그려지는 원인을 찾기 위해 RRD 파일을 열어 값이 정상적으로 기록됐는지 알아보고 MySQL 데이터베이스를 열어 RRD 파일에 연결된 정보가 정상적으로 기입되었는지, SNMP가 정상적으로 호출되는지 따위에 계속해서 신경써야 했습니다. 도구를 사용해보기 전에 포럼을 조금만 더 둘러봤으면 바로 뭔가 이상한 점을 발견하고 다른 도구를 시도했을텐데 아쉬웠습니다. 시간과 혈압 모두요. 얼마 동안 방황한 끝에 zabbix라는 모니터링 도구를 선택했고 지금은 평화로워졌습니다. 모니터링비용은 월 3.5달러로 고정됐고 클라우드워치를 사용하던 때보다 다양한 매트릭을 모니터링할 수 있게 됐고 cacti에 비해 모니터링이라는 목적 자체에만 집중할 수 있는 상태가 됐습니다.