[23/1월] 모니터링 시스템 시계열 DB 전환

[1] 모니터링 시스템에 시계열 데이터베이스 탑재 

 

기존 설계된 시스템 구조에서는 센서 데이터를 2가지 데이터 베이스 시스템을 통해서 관리하고 있었습니다.

1. Redis : 웹에 표시할 센서 데이터 ( 특정 시간 이후로 갱신되는 큐 형식의 구조 ) 
2. SQL : 센서 데이터 저장 목적의 데이터 베이스로 10분 주기의 맥스 샘플링 값으로 보존 

 

InfluxDB를 활용한 웹 모니터링 시스템 구축

하지만 시계열 데이터베이스가 이전 포스팅에서 언급한 내용처럼 효울적이고 in-memory 형식의 캐시 데이터베이스인 Redis의 관리적인 측면에서 어려움이 있었기 때문에 시스템에서 센서 데이터를 시계열 데이터베이스인 influxDB로 통일시키는 결정을 내리게 되었습니다.

 

 

 

먼저 기존의 설계한 Influx DB의 구조는 아래와 같았습니다.

센서 데이터 측면에서의 저장 구조	influx 서버 내부의 센서 데이터용 지속 쿼리 정책과 보존 정책

 

최대한 구축된 Redis 데이터베이스 구조 형식과 비슷하게 설계하여 웹 서버에 붙이기 쉽게 설계하였는데, 이러한 구조는 시계열 데이터베이스를 사용하는데 있어서 비효율적이라고 판단하게 되었습니다.

• 4H, 12H, 24H 같은 경우 4~24초간 샘플링 쿼리가 이루어지는데 이러한 점이 서버에 부하를 줄 가능성 
  • 4H 같은 경우 4s 마다 샘플링을 하는데 ( 센서 노드의 수 ) X ( 특장겂 종류 )를 주기마다 연산하는 것이 비효율적
•  Redis의 경우 샘플링 쿼리 자체가 불가능 했지만, influx는 샘플링 쿼리의 연산 속도가 매우 빠름
• 원본 데이터의 보관 기능은 현재 시스템에서는 메모리 사용률을 고려해 1시간을 맥시멈으로 설정함 
  • influx의 경우 데이터 전송 주기가 일반적으로 1s ~ 2m 가정하고 24시간을 보존해도 무리 없는 것을 확인 

 

따라서 1시간 씩 관리되던 Main measurement와 대시보드에서 사용될 데이터 묶음들인 RP measurements들을 아래와 같이 수정하였습니다.

 

수정된 influx 서버 내부의 센서 데이터용 지속 쿼리 정책과 보존 정책

 

아래의 구조 변경으로 인한 이점을 간단하게 나타내면 다음과 같습니다.

• 기존 4,12,24s 주기로 처리하던 샘플링 쿼리 & 입력 트래픽을 줄일 수 있음 
• 24H를 main measurements로 관리하면서 24시간치 원본 데이터를 확보하는 것이 가능 ( 기존 1시간 ) 
• 인메모리 데이터베이스가 아니기 때문에 DB서버와 웹 서버 물리적으로 분리 가능
  • 그에 따른 쿼리 시간 증가는 influx에서 사용자에게 출력까지 1~2초 이내 출력 가능하다면 보완 가능 

 

 

 

[2] DB 설계&구축 후 테스트 

 

위에서 설계한 형식대로 새로운 구조의 모니터링 시스템 구조로 개편하였습니다.

하지만 구축 후 Redis와 함께 influx를 동시에 서버에서 병행하면서 문제점들이 발생했습니다.

 

기존	개편

 

 

 

[ 이슈 #1 ]

로컬 PC에서 웹 서버를 돌린 경우와 실제 서버 PC 에서의 데이터 처리 속도가 큰 차이가 나는 문제

influxDB의 API 개발을 로컬 PC에서 진행하는 동안은 현재 뷰단에서 사용하는 쿼리들의 시간이 항상 1~2초, 어떤 경우는 ms 단위까지 출력되는 것을 확인하였습니다.

하지만 실제로 서버에 올린 후 확인해보니 로컬 PC에서는 1~2초 대로 걸리는 요청들이 서버에서는 2배에서 10배 이상 차이나는 것을 확인했습니다. 추가로 몇 몇 쿼리는 TimeOut까지 발생하면서 그에 대한 이유에 대한 원인을 찾을려고 노력했습니다.

 

 

개발자 도구로 확인한 데이터 처리 속도 

 

 

 

의심되는 원인 

[1] 서버 PC에 Redis와 influx를 동시에 입력을 넣고 있었기 때문에 트래픽 처리 속도와 관련된 문제일 가능성 

Redis의 경우 샘플링 테이블을 유지하기 위해서 많은 트래픽을 먹고 있었기 때문에 이 영향 떄문에 쿼리가 씹히거나 속도가 늦어지지 않을까 하여 Redis 사용을 잠시 중단 시키고 테스트 해보았습니다.

• 실제로 Windows Resoucre Monitor에서 확인 결과 Redis가 초당 1200만 트래픽을 차지하고 있었습니다.
• 많은 트래픽을 초마다 처리하는데 여기에 influx 관련 트래픽까지 추가되었기 때문에 이 문제를 원인으로 유력하게 생각했습니다.

서버 PC에서의 Netowrk monitor

 

Redis와 관련된 API를 웹 서버에서 전부 내리고 influx만 남기고 테스트 한 경우, 속도는 여전했습니다.

따라서 트래픽과 관련된 문제는 아니라고 생각하게 되었고, node 서버가 초에 많은 트래픽을 처리하는 것이 가능하다는 것을 배울 수 있었습니다.

 

 

[2] 네트워크 속도가 느린 경우

두 연결 간 네트워크 딜레이 문제

웹 서버에서 처리하는 트래픽과 관련이 없다면 두 서버의 연결 상태가 문제의 원인일 가능성이 크다고 판단했습니다.

이 때, 이 원인에 대해서 간과했던 점이 Redis는 이때까지 빠른 속도로 쿼리가 되었기 때문에 네트워크 문제는 아니겠지라고 생각했습니다.

하지만 Redis는 DB서버에서 돌아가는 것이 아닌 웹 서버가 위치한 곳에서 인-메모리 형식으로 구동되었기 때문에 네트워크와 영향이 있지 않았습니다.

 

 

< 네트워크 속도 > 

 

실제로 네트워크 속도를 측정해본 결과는 위와 같이 평균적으로 100Mbps 이하의 속도를 보였습니다.

이전에는 이러지 않았는데 최근에 서버 위치를 옮기면서 관련된 HW와 IP를 교체해야 했는데 이러한 부분이 문제가 되었다고 생각합니다.

일단은 당장 해결할 수 있는 문제가 아니기 때문에 서버 위치를 옮기던지 아니면 대역폭을 늘릴 수 있는 방법을 찾으면 어느 정도 해결 될 것이라고 생각되어 잠깐 동안은 이 상태를 유지하고 추가적인 기능 개발과 에외 처리에 힘을 쏟기로 결정하였습니다.

 

 

CHATGPT가 알려준 정보 

 

 

 

 

 

[ 이슈 #2 ] 

입력 시, 서버 간 네트워크 연결이 끊어진 경우 

 

위의 문제에서 처럼 서버에서 네트워크 속도만 느린것이 아니라 주기적으로 연결이 끊어지는 현상도 발생했습니다.

그 때문인지 센서 입력을 처리하는 단계에서 입력들이 밀리면서 오류들이 발생하고 이러한 딜레이가 생길수록 서버에 부하가 가는지 서버가 재시작되는 오류가 있었습니다.

 

이러한 문제는 influxDB 라이브러리에서 제공하는 옵션으로 해결할 수 있었습니다.

즉 InfluxDB 커낵션 풀을 설정하는 기능을 추가한 것인데, 입력 시도는 최댜 10번 시도하고 , 그 이후의 입력 작업은 반환하게 됩니다.

추가로 쿼리 Timeout을 두어서 요청 시간이 6초를 넘어가게 되면 커낵션을 반환하도록 설정했습니다.

 

 

 

 

추후 계획 

1. 데이터 수집 서버 추가 개뱔 논의 [ Telegraf ]

2.