1. 모니터링의 정의

“to watch and check a situation carefully for a period of time in order to discover something about it”

모니터링의 사전적 정의는 특정한 것을 발견하기 위해 상황을 주의 깊게 관찰하고 확인하는 행위입니다. IT 서비스를 대상으로 하는 모니터링은 장애와 오류를 발견하기 위해 IT 서비스 요소를 관찰하고 확인하는 행위를 의미합니다.

2. 우리는 왜 모니터링을 해야 하나요?

모니터링의 목적은 장애나 오류를 인지하고 예방하는 것입니다. 그래야만 안정적인 서비스를 제공할 수 있습니다. 여기서 말하는 장애란 무엇을 의미할까요? 안정적인 서비스, 불안정한 서비스는 어떤 기준으로 구분해야 하나요?

3. 장애와 안정성을 관리하고 싶다면?

장애를 관리하고 싶다면 장애와 안정의 기준을 올바르게 정의해야 합니다. 안정성 역시 마찬가지입니다. 안전하지 못한 상황에 대한 기준이 있어야 이를 관리할 수 있습니다.

장애를 관리하기 위해서 내부적으로 관리 기준을 세워두는 경우가 있습니다. 대표적으로 CPU 사용량 또는 파일 시스템 사용량 같은 리소스 사용량을 살펴봅니다. 리소스를 임계치 이상으로 사용하면 장애 상황이 근접했다 혹은 안정적이지 못하다고 기준을 세우는 경우가 있습니다. 이런 경우는 잘못된 장애 기준이라고 말씀드리고 싶습니다.

올바른 장애 기준은 어떻게 정의가 되야 할까요? 평균 응답시간이 10초를 초과했거나 요청에 정상적으로 응답을 반환하지 못한 경우를 장애라고 판단할 수 있습니다.

즉, 장애의 기준은 사용자가 이 서비스를 사용하는 과정에서 불편함을 느끼는지 여부입니다. 올바른 장애 기준을 세운 다음에는 안정성에 관해 정의를 내려야 합니다. 어떤 서비스도 1년 내내 단 한번의 오류 없이 운영되기는 현실적으로 어렵습니다. 그래서 안정성을 정의할 때는 사용자 요청에 몇 초 이내로 정상 응답하는 비율이 특정 기간 동안 몇 퍼센트 이상 되어야 하는지를 목표로 합니다. 장애와 안정성에 대한 올바른 기준을 바탕으로 서비스 목표를 세운 다음에 모니터링 하며 관리합니다.

이 과정에서 반드시 장애, 장애 현상 그리고 장애 원인을 명확히 구분하고 인지해야 합니다.

장애 vs. 장애 현상 vs. 장애 원인

• 장애: 사용자 요청에 서비스가 정상 응답하지 못하는 현상
• 장애 현상
  • CPU 사용량 급증에 따른 응답 지연
  • 프로세스 Down으로 무응답
• 장애 원인
  • CPU 사용량 급증
    • 특정 애플리케이션 로직 오류로 과도한 메모리 사용, 메모리 부족에 따른 잦은 GC 수행
  • 프로세스 Down 으로 인한 무응답
    • 애플리케이션 Memory Access Violation으로 프로세스 Down
      • Fail-Over에 3분 소요

4. 모니터링 해야 하는 것은??

장애, 장애 현상 그리고 장애 원인 3가지 모두 모니터링해야 합니다.

• 장애를 인지 할 수 있는 지표
  APDEX, TPS, 평균 응답시간
• 장애 현상을 나타내는 지표
  리소스 사용량 (CPU, Memory, Network 자원 등), Port 오픈, 프로세스 Down 등
• 장애 원인 분석에 필요한 정보
  Log, 세부적인 리소스 사용량 정보, Stack 정보

5. 누가 모니터링 하나요?

모니터링은 사람이 아닌 도구가 해야 합니다. 장애와 안정성 저해를 유발하는 요소는 너무나 많습니다. 이 많은 지표들을 사람이 휴일 없이 24시간 지켜 볼 수는 없습니다.

모니터링을 도구에게 맡긴다면 사람은 무엇을 해야 할까요? 사람은 도구에게 모니터링을 맡기는 행위를 진행합니다. 도구를 통해 이상 요소가 발견되면 알림을 받을 수 있도록 합니다. 즉, 사람은 알림을 관리하고 근본 원인을 추적해 조치합니다.

6. 모니터링은 어떻게 하나요?

모니터링은 크게 3단계로 이루어집니다. 서비스 목표 수준 정의, 목표 수준 달성 방해 요소 파악 그리고 방해 요소 원인 개선입니다.

제 1단계 – 내 서비스 목표 수준을 정의 합니다.

일반적인 서비스라면 사용자 요청에 3초 이내로 정상 응답하는 비율이 한달에 99.5% 이상 되어야 한다가 일반적인 기준입니다. 한달로 환산하면 이 시간은 3시간 40분* 정도 됩니다.

고가용 서비스인 경우에는 목표 기준이 달라집니다. 한 달에 약 20분 정도의 다운 타임을 소비할 수 있습니다. 이를 위해선 서비스의 다중화, Fail-over가 잘 갖춰져 있어야 합니다. 문제를 인지했을 때 즉각적으로 처리할 수 이는 인력이 배치가 되어야 합니다. 소규모, SMB에서 운영을 담당하시는 분들에게는 99.95% 고가용을 목표로 하는 것을 권장하지 않습니다. 현실적으로 이루지 못할 확률이 높습니다. 99.5% 정도로 목표를 정의하는 것이 좋습니다.

고려사항으로 우선 시스템, 인력 한계에 기반해서 목표치를 설정해야 합니다. 또한, 서비스 목표를 정의할 때는 기준을 최대한 단순하게 정의해야 합니다. 이 기준 이외에 별도의 기준을 추가하는 건 서비스가 성숙되고 난 이후에 해도 늦지 않습니다.

제 2단계 – 목표 수준 달성 방해 요소를 파악합니다.

여러가지 방해 요소가 있을 수 있습니다. 쿼리가 느려졌을 수도 있습니다. 혹은 사용자 유입 자체가 특정 시간대만 몰려서 응답 시간이 지연되는 현상이 발생할 수도 있습니다. 가장 높은 비중을 차지하는 방해 요소를 찾아서 우선 순위가 높은 것부터 하나씩 걷어내야 합니다. 모니터링 도구를 사용한다면 알림 발생 기록이나 트랜잭션 통계를 활용해볼 수 있습니다.

제 3단계 – 방해 요소의 원인을 개선합니다.

프로그램 오류를 수정하고, 서버 자원을 재분배하며 인지한 방해 요소의 원인을 개선합니다.

이 단계에서 반드시 현상과 원인을 구분해야 합니다.

• 예시 1)
• 현상: CPU 사용량이 높다
• 원인: 어떤 프로세스인가? 애플리케이션 소스 어디 인가?

• 예시 2)
• 현상: 프로세스가 다운되었다
• 원인: 다운 전후의 정보 → 정보를 통한 분석

8. 와탭을 사용하면 좋은 점

크게 3가지를 말씀드리고 싶습니다.

손쉬운 설치, 효과적인 알림 정책 그리고 정확한 장애 분석에 도움을 받을 수 있다는 점입니다.

첫째, 적용 자체가 쉽고 간단합니다.

가입하고 에이전트만 설치하면 됩니다. 명령어 몇 줄만 입력하면 설치할 수 있기 때문에 부담 없이 적용하실 수 있습니다.

오픈 소스를 고려해볼 수도 있습니다. 다만, 오픈 소스를 이용하기 위해 번거로운 과정을 거쳐야 한다면 효율이 떨어질 수도 있습니다. 모니터링은 도구에게 맡기고, 절약한 시간엔 더 중요한 비즈니스에 집중해 보는 건 어떨까요?

둘째, 효율적으로 알림을 설정할 수 있습니다.

어떤 조건으로 알림을 설정해야 하는지 시행착오를 겪을 필요가 없습니다. 적절하게 알림을 설정하지 않으면 알림을 너무 받아서 피곤해지거나 중요한 장애를 놓칠 수 있습니다.

와탭은 일반적으로 가장 많이 사용하는 알림 정책을 기본값으로 제공합니다. 알림 수신 방법 역시 다양합니다. 연락처를 등록하고 알람을 켜면 SMS, E-mail, 메신저 등으로 알림을 받을 수 있습니다.

마지막으로, 정확한 장애 분석에 도움을 받을 수 있습니다.

장애가 생겼을 때 정확하게 분석하는 건 정말 중요합니다. 하지만, 경우에 따라 분석에 많은 시간을 할애하기 힘들 수 있습니다.

와탭에선 분석을 위한 정보들을 수집하기 때문에 대부분의 이슈들은 툴을 이용해서 분석이 가능합니다. 다만, 데이터를 어떻게 분석하는지는 사용자의 역량에 따라 다를 순 있습니다.

도움이 필요하시면 와탭랩스 온라인 고객 지원으로 문의하세요. 경험이 풍부한 와탭 전문 컨설턴트들이 다양한 시각에서 새로운 관점을 제시해드립니다.

입문자를 위한 바로 활용하는 모니터링, 도움이 되셨나요?

2부 - 모니터링 화면에서 주목할 지표 소개는 [와탭랩스 웨비나] 입문자를 위한 바로 활용하는 모니터링 유튜브에서 확인해 보세요 😉