[Project]공공데이터 수집 DB 모니터링

인턴을 하던 전 직장에서 마지막으로 진행했던 프로젝트이다.

 

해당 프로젝트에 대해 간략하게 설명하자면 공공데이터 포털에서 한시간에 한 번씩 업로드가 되는 환경 관련 데이터를 한시간에 한 번 씩 스케줄러를 돌려서 수집하는 프로젝트가 이미 서버 위에 올라가서 돌아가고 있었다.

 

부장님께 전달 받은 미션은 위 수집한 데이터에 이상이 있는지 없는지 체크하고 한 눈에 알아볼 수 있는 모니터링 웹을 만들라는 것이었다.

 

사실 이 모니터링 웹 페이지는 이미 스프링으로 되어있는 프로젝트가 이미 있었다.(같이 일하는 동기가 스프링 레거시를 이용해 구현하였다.) 하지만 성능상의 이슈가 너무 많았다.

 

메인 페이지

 

이게 메인페이지인데 해당 페이지를 띄우려면 3개의 테이블을 join 해야 한다.

 

 

위 사진 처럼 일단 지역정보를 불러오고 그 지역에 있는 측정소 정보도 불러오고 그리고 해당 시간대에 수집된 데이터도 불러와서 이상이 있는지 없는지 체크해서 이상이 있으면 빨간색으로 표시를 해줘야 했다. 그런데 이 메인페이지를 한 번 보려면 3~5초 정도의 시간이 걸렸다. 수집된 데이터 테이블의 데이터가 시간이 지날 수록 계속 수집해서 쌓이기 때문에 발생하는 문제였다. (처음 개발할 때에는 데이터가 많지 않았기 때문에 이렇게 오래 걸리지 않았다고 한다.) 아무리 사내에서 모니터링용으로 쓸 거라지만 이건 좀 아닌거 같아 이 모니터링 페이지를 동기와 함께 마이그레이션 해본다고 말씀 드렸고 신기술 연구 겸 프론트엔드는 React, 백엔드는 NestJS를 통해 개발하기로 하였다. DB 구조나 쿼리도 싹 갈아 엎고 싶었지만 그건 제지 당했다..(왜냐하면 기존 코드는 model.attribute로 넘겨서 jsp에서 jstl로 받는 구조에 적합하게 짜여있었고 노드를 사용하면 그럴 필요가 없었다. 근데 거절..ㅋㅋㅋ) 물론 신기술 도입으로 진행하는 프로젝트이니 일단 한 번 기능을 먼저 구현해보고 나중에 리팩토링하라고 하시긴 했다. 퇴사해서 못했지만...ㅋㅋㅋ

 

일단 확실히 데이터 입출력에 강한 노드이다보니 그냥 구현만해도 1~2초 정도로 속도가 빨라졌다. 하지만 그래도 느렸다. 상세 페이지는 하루치 데이터를 다 가져와야해서 더 느렸다.

 

 

 

지역마다 있는 측정소를 전부 불러오고 하루치 데이터를 불러와서 어느 시간대에 이상이 있는지 없는지 보여주는 페이지인데 여긴 뭐 30초 정도 걸렸다.. 일단 쿼리를 튜닝했는데 불필요하게 조인이 되는 테이블이 있어서 그 부분을 수정하니 한 20초 정도로 짧아졌다. 그래도 길었다.

 

 

 

이걸 보려고 몇십초를 기다린다고 생각해보자..

 

 

그래서 이걸 그냥 캐시를 사용하면 어떨까라는 생각을 하게 되었다. 어차피 한시간에 한 번씩만 데이터가 insert 되고 해당 데이터를 그냥 보여주기만 하는 페이지인데 데이터베이스에 쿼리를 날릴 필요 없이 해당 요청에 대한 데이터를 캐시처리 해서 보여주면 안되나라는 생각을 하게 되었다. 결국 문제는 데이터베이스에 쿼리를 날려서 그 데이터를 받아오는 시간이 걸리는 것이니까 데이터가 업데이트 되는 타이밍에 맞춰서 스케줄러를 자체적으로 돌려서 데이터베이스에서 데이터를 가져오면 되지 않을까. 그리고 그걸 캐시처리를 해놓으면 사용자는 아주 빠르게 데이터를 확인할 수 있게 된다.

 

그래서 node-cache와 node-cron을 이용해서 구현을 하였다. 사용법은 밑의 링크 참조

 

 

https://velog.io/@koreanhole/Task-SchedulingNestJs

Task Scheduling(NestJs)

https://bk0625.tistory.com/4

[NestJS]캐시 및 NestJS에서의 캐시 사용

 

 

데이터 수집 서버의 스케줄러가 도는 시간은 매시 0분과 30분이다.(누락 데이터가 있거나 공공데이터 포털에 늦게 데이터가 올라오는 경우가 있기 때문) 그래서 넉넉 잡고 매시 2분과 32분에 스케줄러를 돌게 해서 해당 모니터링에서 제공하는 모든 api를 캐시처리하였다. 따라서 사용자는 데이터가 렌더링 되기만 하면 모니터링 서비스의 모든 서비스를 이용할 수가 있게 된다. (제일 응답시간이 짧은 응답이 780ms 정도였는데 4ms 이하로 응답시간을 줄였다. 모든 요청이 캐싱된 데이터를 반환하기 때문에 쿼리를 날릴 필요가 없었기 때문)

 

 

단순 구현 뿐 아니라 사용자 입장에서 어떻게 더 잘 이용할 수 있을까를 고민해볼 수 있었던 좋은 프로젝트였다. 수치로 성과를 나타낼 수 있는 첫 프로젝트였다. 급하게 퇴사하게 되어서 리팩토링도 못하고 배포도 못하고 나와서 아쉽긴 하지만 그래도 기존 모니터링 서비스를 훨씬 개선시킬 수 있었다.