3번째 프로젝트는 Semes 기업 멘토님의 조언과 함께 만들게 되었습니다.
반도체 설비를 모니터링 하는 시스템을 만들어보기로 했습니다.
github : https://github.com/Projcet-E201
notion : https://www.notion.so/PJT-770f43012e344dfa9aad09a5a6d324f6
목표
추구하는 목표는
1. 누구나 쉽게 볼수 있도록 직관적으로 만들자
2. 사용자가 보기 편한 방법으로 구성할 수 있도록 커스텀 영역을 두자
였습니다.
화면 모습
위 모습은 메인화면이며 사용자가 클릭을 하면 원하는 방식으로 데이터를 보여줍니다.
또한 커스텀을 해서 사용자가 원하는 범위를 지정하면 그 범위에 대한 알람을 줄수 있습니다.
이 화면은 분당 200만개의 데이터를 전송한 결과였고, DB를 replica를 통해 더 많은 쿼리도 수용가능하다고 판단했습니다.
Client는 공장을 의미하고, 공장에서 오는 데이터를 초단위로 받아 메인 화면에 보여줍니다.
위 화면은 공장 하나에서 오는 데이터입니다.
고민한 내용
고민한 내용
이렇게 구성하기 위해서 고민한 것은 총 3가지 였습니다.
1. DB를 무엇을 써야할 것인가.
저희 데이터는 최대 1달간 보관을 해야했으며 데이터마다 상이한 보관기관과 전송기간을 가지고 있었습니다.
RDBMS는 적합하지 않다고 봤고, 시계열 DB를 가장 적합한 DB로 판단했습니다.
23년 5월 기준 세계적으로 가장 많이 쓰는 시계열 DB는 influxDB였고, 이를 통해 구현해보고자 했습니다.
여기서 influxDB는 flux라는 쿼리문을 통해 전송하고 있었고 이를 학습해서 전송 로직을 사용해야했습니다.
이 부분이 학습 시간이 걸렸습니다.
그리고 아래와 같이 아키텍처를 만들고 진행했습니다.
2. DB의 과부하를 어떻게 해결할 것인가.
저희가 처음 분당 200만개의 데이터를 CPU 4core, 8GB 메모리와 100GB의 하드를 가진 클라우드 환경에서 구현을 했습니다.
하지만 12시간을 테스트해본 결과 너무 많은 쿼리로 인해 큐가 밀려서 데이터가 나오는 속도가 1시간 정도 딜레이가 생겼습니다.
해결법 1.
그래서 처음 적용한 방법은 db를 저장하는 로직과 가져오는 로직을 분리하는 것이었습니다.
io스위칭 부하가 많이 생긴다는 것을 알게되었고, 이를 해결하기 위해 read DB, write DB로 구현하고 이를 동기화해주었습니다.
해결법 2.
저희 서비스가 초단위로 보여주는 것이기에 msec단위로 DB에 저장하면 DB의 부하가 너무 많다는 것이었습니다. 데이터를 저장할때 CPU사용률이 400%로 지속적으로 치솟았습니다. 그래서 서비스 화면에 sec단위로 보여주는 만큼 back에서 초단위로 데이터를 모아서 저장하는 로직을 구현했습니다.
해결법 3.
쿼리 최적화
flux문을 처음 사용하는 만큼 처음 사용했던 쿼리는 원하는 데이터만 바로 가져오는 방식이었습니다. 하지만 DB의 부하가 많은 만큼 DB의 부하를 줄이기 위해 집계를 back서버에서 해주자는 판단을 했고, 이를 통해 데이터 가공 서버를 따로 만들어 관리했습니다.
이러한 노력으로 12시간 저장했을때 1시간의 지연을 0.03초로 낮출수 있었습니다.
즉, 화면에 보여지는 모든 데이터가 1초 이내의 실시간 데이터로 볼수 있다는 것을 의미합니다.
3. 화면을 사용자가 원하는 데로 구성하려면 어떻게 할것인가?
이 부분은 기업 관계자 분이 외주 관계자처럼 해주셔서 저희는 여러가지 선택 방안을 제시했습니다.
그리고 그 결과에 맞춰서 가져갈려고 노력했습니다.
figma를 통해 다양한 후보를 만들어보았고 이중 가장 직관적인 방법을 구현하고자 했습니다.
그러다가 생각한 것이
하나만 고르는 것이 아니라 모든 만들어서 사용자가 선택할 수 있도록 만들자라고 생각하게 되었습니다.
그래서 아래 버튼을 통해 사용자가 클릭을 하면 바뀔 수 있도록 구성했습니다.
특히 커스텀 화면에서는 양옆으로 비교를 통해
몇번 공장에서 몇번의 센서 또는 모든 센서를 볼수 있고, 한개를 원하면 한개만 볼수 있도록 만들었습니다.
즉, 메인화면 자체를 사용자가 평균 그래프, 막대 그래프, 선 그래프 등 다양한 방식으로 구성할 수 있도록 만들었습니다.
후기
많은 데이터를 처리하는 방법에 대해 고민할 수 있었던 프로젝트였습니다.
그리고 모니터링을 직관적이고 사용자 친화적으로 개발할 방법에 대해 많이 고민한 프로젝트 였습니다.
익숙한 sql이 아닌 flux라는 influxDB에 사용되는 쿼리문을 공부하게 되었고,
front로 api를 실시간으로 보내기 위해 http, sse, socket을 모두 사용해보며 시간을 측정해보았던 프로젝트였습니다.
또한 팀장으로서 기업 관계자 분을 클라이언트로써 소통의 커뮤니케이션을 통해 적합점을 찾으려고 노력했습니다.
그 결과 SSAFY 전국 10개의 기업 프로젝트에서 2등을 달성할 수 있었습니다. vv
앞으로 조금더 MSA 환경에 대해 공부하고 데이터 전송방법에 대해 고민해볼 것같습니다.
'프로젝트 > 프로젝트' 카테고리의 다른 글
현업 프로젝트(기술스텍 변경) FireBase에서 SpringBoot로 (1) | 2024.09.08 |
---|---|
두번째 프로젝트 Tracer 복기 (0) | 2023.04.12 |
첫번째 프로젝트 Sodam 복기(2) (0) | 2023.02.20 |
첫번째 프로젝트 Sodam 복기(1) (3) | 2023.02.19 |