레디스 활용기 - 1

📌 개요

현재 사물 또는 사람에게 부착된 IoT 기기로부터 BLE 신호 형태로 수신되어 정제된 데이터를 RDB 에 쓰고, 다시 읽어서 상태 (위치 등) 를 모니터링 할 수 있는 소프트웨어 개발 및 운영에 참여하고 있는 중이다.

사업은 병원들을 위주로 전개하고 있으며, 각 클라이언트마다 서로 다른 요구사항들을 갖고 있다.

약 3년 전 이 모니터링 소프트웨어를 설치하여 지금까지 개발 및 유지보수를 해주고 있는 Y 병원에서 한 달 전쯤 이슈제기를 해왔다:

방문자 출입기록과 로그 데이터가 일치하지가 않습니다!

 

 

방문자 출입기록은 말 그대로 병원에 각기 다른 목적으로 방문하는 다양한 사람들의 현황을 IoT 기기 (Y 병원에서는 스마트폰 앱) 를 이용하여 파악하고 정리한 기록이다. 회사에서 개발 중인 모니터링 소프트웨어에는 IoT 기기로부터 신호를 받을 때 이미 이 IoT 기기를 사용하는 사람의 프로필을 알 수 있다. 그리고 수신된 정보를 잘 정리해서 기록해놓는다. 모든 사람에 대해 출입 유형을 분석하고 내용을 재구성해서 DB 에 써넣는다.

그런데, 프로세스에 무엇인가 문제가 있었다는 이야기였다.

 

😱 기존 프로세스의 문제점

기존 프로세스는 아래와 같았다:

먼저 로그 테이블에 넣고, 하루에 두 번씩 방문자 출입기록 테이블로 옮긴다.

 

 

위 그림에서 하루 두 번씩 스케줄러가 돌면서 로그 테이블에 있는 데이터를 재조합해 방문자 출입기록 테이블에 넣는 형태였다. 데이터를 재조합하는 쿼리는 꽤 복잡했는데, 테이블들의 구조가 아래와 같은 차이와 공통점이 있었기 때문이었다:

	PK	각 컬럼이 나타내는 것	유니크 키	특징
로그 테이블	로그 번호	로그의 다양한 정보	로그 등록 날짜 / 시간	각 row 가 단일 정보를 담음
방문자 출입기록 테이블	로그 번호	방문자 종류 별 카운트	통계, 로그 등록 날짜 / 시간	각 row 가 여러 정보의 통계임

 

즉, 로그 테이블에서는 데이터의 통계를 내서 방문자 출입기록 테이블로 insert 해야 하는 상황이었고, 이슈가 발생한 시점에는 1억 6천만 건의 데이터가 저장되어 있었다. 통계 쿼리 수행에는 383.437 초 = 약 6분이 걸리고 있었는데, 이는 다른 스케줄러가 돌기 시작할 때까지의 간격 이상의 시간이 쿼리에 소요되고 있었다는 의미였다.

 

🤩 변경된 프로세스

처음에는 쿼리를 튜닝하고자 했는데, 이미 인덱스도 걸려 있었고 통계를 내기 위해 반드시 수행되어야 하는 로직으로만 구성되어 있는 것을 확인하고서 다른 방법을 고민해보게 되었다. 먼저 떠오른 방법은 간단했다. 바로 IoT 기기에서 신호가 들어오면 로그 테이블에 쌓은 뒤 방문자 출입기록 테이블에 넣지 않고, 바로 방문자 출입기록 테이블에 기록하도록 하는 것이었다. 이 때 몇 가지 걸리는 것이 있었다:

• 첫째, 신호 수신 시 곧바로 어떤 종류의 방문자인지 알 수 있는가?
• 둘째, 몇 초 단위로 신호를 받는데, 다른 로직에 영향 없이 수신된 데이터를 RDB 에 쓰는 로직을 추가할 수 있는가?

회사 동료 분들과 이 두가지 문제에 대해 상의했고, 내린 결론은 아래와 같았다:

• 첫째, 신호 수신에는 대상의 카테고리 정보 등 신호에 대한 정보들이 포함된다. 여기서 대상의 카테고리 정보가 방문자 종류와 같은 데이터이다.
• 둘째, 수초 단위로 RDB 에 쓰는 로직은 부하가 심할 수 있으므로, 쓰기/읽기가 빠른 NoSQL 기반 데이터 저장소인 레디스를 활용하면 된다.

다음 포스팅에서는 결론으로 도출된 해결 방법들을 구체적으로 어떻게 구현했는지 소개하도록 하겠다.