WARD

2021.09 ~ 2022.03

문제점

• 클라우드 서비스와 관련된 모니터링 도구가 많고, 알림 채널이 파편화되어 있음
• 신규 서비스와 리전이 추가될수록 점점 더 많은 양의 모니터링 알림을 받게 됨
• 많은 메신저 알림이 발생하는 만큼, 스팸성 알림도 존재하며 알림의 중요도를 판단하기 어려움
• 단일화된 알림 채널이 없어 놓치는 알림도 자주 발생하게 됨

해결 방법

• 모니터링 도구에서 발생하는 모든 알람의 수신 채널을 통합
• 대부분의 알림은 웹으로 조회하도록 하고, 꼭 필요한 알림을 메신저로 전송하도록 변경
• 그래프를 통해 알림 발생 추이를 시각적으로 확인할 수 있는 기능 추가

구조

기술 스택

• RMQ
• Docker
• FastAPI + Celery
• Vue.js

도전

시스템 구현 단계부터 확장성이 좋은 서비스를 만들고자 했습니다. 더 많은 모니터링 서비스가 추가될 것이 자명했고, 각각의 시스템에서 보내는 데이터 형식 또한 다양할 것으로 예상했기 때문입니다.
따라서 시스템을 설계하는 단계에서 메세지 큐 방식을 고려했고, 범용적인 데이터를 받아 후처리하는 celery worker를 구성했습니다.
이후 실제로 발생하는 이벤트가 많아짐에 따라 처리하는 데이터의 양은 매우 증가했지만, 백엔드 DB를 MariaDB 에서 ElasticSearch로 변경한 것 이외에 로직과 구성은 큰 변경 없이 안정적으로 운영하고 있습니다.

결과

• 7개 이상의 이벤트 시스템을 WARD 플랫폼으로 통합
• 불필요한 메세지 채널 통합 및 제거
• 현재 일일 1.2천만개 이상의 모니터링 데이터를 처리하는 플랫폼으로 확장해 운영중

기여도

• 모니터링 시스템에서 전송하는 데이터 분류 (80%)
  • 모니터링 주체, 중요도에 따라 분류
• 모니터링 이벤트 처리 모듈 개발 (50%)
  • 정규표현식을 활용해 호스트명에 따른 리전 구분 코드 작성
  • 정크로 수신한 데이터를 key, value로 나누어 ES에 저장
• 통합 모니터링 웹 프론트엔드 개발 (30%)