데이터 레이크 구축 : 초당 6천 개의 이벤트를 담는 똑똑한 호수

배경

나는 IoT 서비스 회사의 백엔드 개발자이다.

약 260만 개의 기기에서 초당 6천 개에 달하는 기기 상태 이벤트가 발생하고 있다.

나는 이를 수신하여 가공하고, 적재 또는 다음 서비스로 전달하는 파이프라인을 개발한다.

 

수많은 기기 상태 이벤트를 가공 없이 날것 그대로 저장하는 것은 매우 중요하다.

특히 외부 연동 서비스를 담당하는 파트라 더 그러하다.

적재된 데이터는 기기가 과거 특정 시점에 어떤 상태였는지 확인하는 히스토리가 되고,

고객의 기기 동작 문의를 확인하거나 외부 플랫폼의 이벤트 처리 여부를 증명하는 중요한 증적이 된다.

 

데이터 저장소 비교

1차 시도: CloudWatch

처음에는 단순 로그로 취급하여 CloudWatch Logs에 모든 이벤트를 기록했고, 비용 문제를 만났다.

CloudWatch Logs는 수집, 저장, 분석 세 가지 영역에서 비용이 발생하고, 그중 수집 비용의 비중이 가장 크다.

서울 리전 기준 GB당 약 $0.76인데, 하루에 수백 GB가 발생했고 단순 적재를 위한 비용으로는 감당하기는 어려웠다.

 

2차 시도: Loki 또는 ELK

비용 문제를 해결하기 위해 Promtail + Loki으로 오픈소스 조합으로 전환했다.

Loki의 백엔드 저장소를 S3로 설정하여 파일 시스템의 크기에 구애받지 않고, 순수 파일 저장 비용만 낼 수 있었다.

문제는 속도였다.

Loki는 로그 메타데이터(레이블)만 인덱싱 하고 내용은 그대로 저장하는 구조이다.

이 때문에 '최근 1시간 이내의 기기 이벤트 검색'처럼 인덱싱 된 레이블 기반의 좁은 범위 검색은 빠르지만,

'3일 동안 특정 기기의 모든 이벤트 검색'과 같은 전체 데이터 스캔 쿼리에는 매우 취약했고, 타임아웃이 잦아 사용이 어려웠다.

그렇다고 검색 속도가 빠른 ELK는, 그렇게 빠를 필요 없고, 가끔 사용하는 팀 상황에 비해선 과한 비용과 관리 부담이었다.

 

최종 결정 : S3 / 데이터 레이크 구성

결국 S3를 중심으로 한 데이터 레이크를 직접 구성하기로 했다.

S3는 저장 비용이 매우 저렴하고, 용량 확장에 신경 쓸 필요가 없다.

특히 기준 시간이 지난 데이터는 Glacier로 자동 이동시켜, 증적관리를 위한 저렴한 장기 보관이라는 목적에도 적합했다.

 

Athena 와 검색 속도

데이터 조회는 서버리스 쿼리 엔진인 Athena를 사용한다.

Athena는 검색을 위해 스캔한 데이터 양에 따라 속도와 비용이 결정되기에, '어떻게 스캔량을 줄이는가'가 중요했다.

아래는 이를 위해 신경 썼던 세 가지이다.

 

1. Parquet 형식
Parquet은 열 기반으로 데이터를 저장하는 파일 형식이다.

조회 쿼리를 실행하면, Athena는 전체가 아닌 출력이 필요한 컬럼 영역만 확인한다.

저장되는 데이터 중 실제 조회에 사용되는 컬럼은 소수인 팀의 상황에 특히 더 적합했다.

또, 파일 내부에 메타데이터를 가지고 있다.

대표적으로 최댓값, 최솟값 같은 통계 정보를 함께 기록하여 검색 조건에 포함되지 않는 파일은 무시하고 넘길 수 있다.

조건이 포함된 파일만 확인하니 스캔량이 줄고, 이는 곧 쿼리 속도 향상과 비용 절감으로 이어진다.

 

2. 적절한 파일 분리

너무 파일이 많으면 각 파일의 메타데이터를 확인하기 위해 파일을 읽고 닫으며 오버헤드가 발생하고, 이는 성능이 저하로 이어진다.

반대로 너무 큰 파일은 쿼리에 필요 없는 데이터까지 함께 읽을 확률이 높아져 비효율적일 것이다.

이를 해결하기 위해 이벤트를 배치로 모아 한 파일로 묶는 것으로, 최적 크기 파일 하나로 묶어서 저장한다. 

 

3. 파티션 기반 파일 경로

S3에 파일을 저장할 때 year=2026/month=03/day=28/hour=15/ 와 같이 시간 단위로 경로를 구성했다.

이것을 파티셔닝이라 한다.

Athena가 시간을 조건으로 한 검색을 수행할 때, 이 파티션 기준으로 범위 내 경로와 파일만을 스캔 대상으로 삼는다.

 

Athena는 Glue 카탈로그로 테이블 정보 (스키마, 파일 형식, 위치, 파티션 정보)를 저장한다.

쿼리를 실행하기 전 Glue 카탈로그를 확인하여, 스캔할 경로와 파일 형식을 미리 파악해 두게 된다.

많은 양, 빠를 필요는 없는 검색, 저렴한 비용이라는 팀에 맞는 이벤트 조회 시스템을 만들 수 있었다.

 

AWS Glue ETL , 통계 자료 스케줄링

AWS Glue를 사용하면 매시간 통계를 내는 ETL 작업을 쉽게 정의할 수 있다.

ETL은 데이터를 추출하고, 가공한 뒤, 다른 서비스에 전달 또는 다음 저장소에 적재하는 파이프라인을 의미한다.

AWS Glue ETL에선 Spark + Python을 사용한 대용량 데이터 처리 로직과 자동 스케줄링을 정의할 수 있다.

 

한 가지 예시로, 수집한 기기 이벤트에서 제품별 기기 수, 각 제품에서 발생하는 이벤트 추이를 집계하였다.

그리고 그 작업을 매시각 20분에 실행하여, 한 시간 단위로 통계 자료를 저장하게 만들고, 이를 다시 일별, 월별로 반복했다.

이렇게 만들어진 통계는 특정 제품의 비정상적인 이벤트 발생을 감지, 제품팀에 전달되어 펌웨어 개선에 근거가 되었고,

단순 판매 수가 아닌, 시간대 별 활성화 기기 수, 자주 사용되는 기기 제어가 집계되어 마케팅 팀에 전달되었다.

 

이런 작업 스케줄링이 모두 서버 리스 + Full managed 로 구성된다는 것도 큰 장점이다.
스케줄링 정의도 쉽고 명확하며, 작업이 실행되는 컴퓨팅 시간 동안의 비용만 지불하면 되기에 유지비 부담도 없다.

앞선 통계의 경우 2 DPU로 실행했을 때 약 2분이 소요되고, 이는 월 3 ~ 4만 원 수준의 비용이다.

최소한의 운영 부담으로 강력한 데이터 플랫폼을 구축할 수 있었다고 생각한다.

단순 데이터 보관에서 시작하여, 사용자들의 기기 사용 추이를 집계하고 추출하는, 데이터 관리 시스템으로 발전시킬 수 있었다.