hub-api 10분 단위 집계 정보 저장 로직 구현

윌로그 재직 중 사내 공유 문서

배경

1. hub-api에서 차량 서비스가 시범적으로 구현되면서, 각 고객사에 납품된 하드웨어를 통해 인입되는 온도 및 습도, 위치정보 등을 조회해야 하는 요구사항이 생겼습니다.

   기본적으로 하드웨어를 통해 측정되는 정보들은 결과적으로 InfluxDB에 저장됩니다. 문제는 현재 Platform 서비스는 사실상의 모든 조회 기능 구현을 InfluxDB에 의존합니다. (준)실시간성 정보를 조회하는 경우라면 타당하지만, 과거 시점의 정보를 조회할때 역시 InfluxDB를 사용합니다.

   hub-api를 기반으로 구현되는 비즈니스 도메인도 (준)실시간성 정보를 조회하는 경우라면 InfluxDB에 의존할 수밖에 없습니다. 다만 [1일 전 / 1주일 전 / 1개월 전] 등의 과거시점 정보를 조회하는 경우에 미리 집계를 해둔 정보가 있다면 굳이 InfluxDB에 불필요한 조회 Request를 줄일 수 있다고 판단했습니다.

2. 회사에서 기획하는 차량 관련 서비스를 운영하기 위해 법적인 준비사항으로 개인 위치정보 사업자 인가를 받아야 했습니다. 이를 위해서는 윌로그의 백엔드 정보 저장소에 위치 정보를 암호화하여 저장해야 하는 요구사항이 있습니다.

   InfluxDB에 적재 및 관리되는 모든 위치정보를 암호화하고, 이를 꺼내 사용할때 복호화 처리하는 것은 기존 Platform 비즈니스에 사이드 이펙트가 가늠이 어려웠습니다. 따라서 InfluxDB가 아닌 새롭게 setup되는 hub-api의 DB에 관련 위치 정보를 집계하여 저장하고, 이때 이 위치정보를 AES로 암호화하여 저장합니다. (현재 해당 값을 사용할때는 서버에서 복호화하여 사용합니다.)

   이 형태의 아키텍처를 제시하여 윌로그는 25년도 11월 경에 개인 위치정보 사업자 인가를 취득했습니다. (상황에 따라서는 관련 기관에서 연단위로 주기적인 check가 들어올 수도 있습니다.)

구현 및 Flow

• 기본적으로는 10분 단위로 기기의 프로브온도 / PCB 온도 / 습도 / 위치 정보 / 배터리 잔량을 집계합니다. 이때 위치 정보는 배경에서 언급한 상황을 고려하여 AES로 암호화하여 저장합니다.
• 일부 하드웨어 세팅 상황에 따라 집계가 passing되는 상황이 있습니다.
  • 예시) 하드웨어의 온도 측정 시점은 16시 02분. 실제로 InfluxDB에 적재되는 시점은 16시 14분으로 측정시점과 적재되는 시점이 10분 단위로 차이가 나는 경우 집계 대상으로 판단이 안 됨.
  • ⇒ 이 문제를 일부 해소하기 위해 2시간 단위로 backfill 집계를 진행합니다. 큰 틀의 방식은 위 흐름과 동일합니다.
• 각 집계 테이블은 기본적으로 vendor - model - serial 로 하드웨어 기기가 구분됩니다.
• 각 집계 테이블은 10분 단위 집계 시점으로 집계된 모든 raw data를 저장해 두고 있습니다. 이때 위치정보의 경우는 역시 AES로 암호화하여 저장합니다.
• 집계 테이블 목록 (26년 3월 기준)
  • temperature_aggregations (probe 온도)
  • pcb_temperature_aggregations (PCB 온도)
  • humidity_aggregations (습도)
  • location_aggregations (위도, 경도)
  • battery_aggregations (배터리 잔량)
  • acc_aggregations (충격 가속도)
  • ambient_light_aggregations (조도)