센서 데이터 수집 및 전처리 서비스 (Processing Service) - nhnacademy-aiot3-4iren/4iren-wiki GitHub Wiki

1. 개요

MQTT 브로커를 통해 유입되는 LoRaWAN 기반 센서 원시 데이터(Raw Message)를 수신하고, 이를 표준 형식으로 파싱 및 정제하는 데이터 처리 서비스이다. 추출된 센서 데이터는 목적(환경 데이터, 기기 상태 데이터, 통신 품질 데이터)에 따라 분류되며, 각 분류별로 서로 다른 검증·저장·발행 정책을 적용한다.

2. 기능 요구사항

2.1 MQTT 데이터 수신 및 파싱 (Data Ingestion & Parsing)

  • MQTT 브로커로부터 센서 측정값 및 네트워크 메타데이터가 포함된 JSON 형태의 원시 데이터를 수신한다.
  • 수신된 데이터를 시스템 내부에서 사용할 수 있는 표준 형식으로 역직렬화한다.
  • 역직렬화에 실패한 메시지는 로그를 기록한 후 폐기하여 동일 메시지의 반복 처리로 인한 장애를 방지한다.

2.2 데이터 정제 및 메타데이터 추출 (Data Refining)

  • 수신된 데이터에서 애플리케이션 ID, 디바이스 식별자(devEui), 디바이스 이름 등의 메타데이터를 추출한다.
  • 디바이스 식별자(devEui)를 기준으로 내부 API(Sensor Context API)를 조회하여 위치 정보(roomId)를 확인한다.
  • 조회 결과는 메모리에 캐싱하여 동일 디바이스에 대한 반복 조회를 최소화한다.
  • 위치 정보 조회에 실패하거나 등록되지 않은 디바이스인 경우, 위치 미상(unknown) 상태로 처리하며 해당 데이터는 후속 메시지 발행(RabbitMQ) 대상에서 제외한다.
  • 센서 데이터의 타입을 표준화하여 일관된 형식으로 변환한다.
    • 수치 데이터는 실수형(Double)으로 변환한다.
    • 상태값(Boolean)은 저장 규격에 맞는 수치값(1.0/0.0)으로 변환한다.

2.3 센서 데이터 분류 (Data Classification)

수신된 단일 메시지에 포함된 센서 데이터를 목적에 따라 세 가지로 분류한다. 분류별로 적용되는 처리 정책이 서로 다르다.

분류 항목 설명
환경 데이터 Temperature, Humidity, CO₂, TVOC, Illuminance, Pressure, Door 등 임계치 검증 및 이상치 탐지 대상. 룰 엔진 발행 대상
기기 상태 데이터 Battery 디바이스 자체의 상태 정보. 임계치 검증은 없으나 룰 엔진 발행 대상(배터리 부족 시 점검 알림)
통신 품질 데이터 RSSI, SNR 신호 수신 품질 정보. 저장만 하며 룰 엔진 발행 대상 아님

2.4 검증 (Validation)

임계치 검증

  • 센서별 최소값(Min) 및 최대값(Max) 규칙을 메모리에 캐싱하여 검증 시 데이터베이스 조회를 최소화한다.
  • 환경 데이터에 한해 센서별 임계치 기준으로 물리적으로 유효한 값인지 판별한다.

검증 결과는 VALID(정상) / OUT_OF_RANGE(범위 이탈) / NO_RULE_DEFINED(규칙 미정의) 세 가지로 구분하며, 이 결과가 후속 저장·발행 처리에 활용된다.

기기 상태 데이터(Battery), 통신 품질 데이터(RSSI, SNR)는 임계치 검증 대상에서 제외한다.

이상 발생 누적 판정

  • 임계치를 이탈한 환경 데이터는 Redis 카운터로 누적한다. (1시간 고정 윈도우)
  • 설정된 횟수 이상 누적된 경우에만 알림 이벤트를 발행하며, 발행 후 2시간 동안은 동일 대상에 재발행하지 않는다. (쿨다운)

슬라이딩 윈도우 기반 통계적 이상치 탐지(고정값 Stuck, 이탈값 Spike, 센서 간 불일치 Mismatch)는 현재 구현되어 있지 않다. 검증은 센서별 최소/최대 범위 비교만 수행한다.

2.5 데이터 저장 및 메시지 라우팅 (Storage & Routing)

정상 데이터

분류 저장(InfluxDB) 발행(RabbitMQ)
환경 데이터 (검증 통과) O O
기기 상태 데이터 O O (룰 엔진의 기기 점검 알림 판단용)
통신 품질 데이터 O X

이상 데이터

  • 임계치를 벗어난 환경 데이터는 InfluxDB 저장 및 RabbitMQ 발행 대상에서 제외한다.
  • 이상 발생 정보와 관련 메타데이터(디바이스 식별자, 측정값, 발생 시각, 이상 유형, 위치 정보)를 로그 시스템(Elasticsearch/Kibana)으로 전달하여 모니터링 및 분석에 활용한다.
  • 위치 정보(roomId) 조회에 실패한 정상 값은 InfluxDB에는 저장하되, RabbitMQ 발행 대상에서는 제외한다.

2.6 환경 컨텍스트 캐싱

  • 발행 대상 환경 데이터는 강의실별 최신값 해시(env:context:{roomId})로 Redis에 갱신한다.
  • 이 캐시는 룰 엔진의 임계치(THRESHOLD) 판정 등에서 강의실의 현재 상태를 참조하는 데 사용된다.
  • 갱신에 실패하더라도 파이프라인은 중단하지 않고 오류만 별도 채널로 라우팅한다.

2.7 MQTT 브로커 관리

  • 건물 단위로 MQTT 브로커 접속 정보와 구독 토픽을 등록·수정·삭제할 수 있다. (관리자 권한)
  • 애플리케이션 기동 시 활성화된 브로커별로 구독 어댑터를 생성한다.
  • 브로커 또는 건물 삭제 시 연관된 센서·측정 항목 메타데이터도 함께 정리된다.

3. 비기능 요구사항

  • 센서 데이터를 실시간으로 처리할 수 있어야 한다.
  • 임계치 검증 및 위치 정보(roomId) 조회 시 데이터베이스·외부 API 호출을 최소화하여 처리 성능을 확보해야 한다.
  • 데이터 파싱 실패 및 검증 실패는 동일 메시지 내 다른 필드, 그리고 다른 메시지의 처리에 영향을 주지 않아야 한다.
  • 저장소, 메시지 브로커, 외부 API(Sensor Context API) 장애 발생 시 오류 로그를 기록하고 서비스가 비정상 종료되지 않아야 한다.
  • 데이터 저장과 메시지 발행은 확장 가능한 구조를 제공해야 한다.