데이터 레이크 구축 : 초당 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로 자동 이동시켜, 증적관리를 위한 저렴한 장기 보관이라는 목적에도 적합했다.

 

Parquet 형식

데이터는 기존 로그 형태가 아닌, Parquet 형식으로 저장하기로 했다.

일반적인 RDBMS나 로그는 행 기반으로 데이터가 저장되어, 한 행의 모든 컬럼이 연속으로 디스크에 놓인다.

그래서 특정 로우의 전체 컬럼을 읽을 때는 이 구조가 유리하다.

 

반면 사용하고자 하는 Parquet는 컬럼 기반의 데이터다.

집계에 필요한 컬럼만 사용하고 나머지 컬럼은 아예 읽지 않는다.

또 같은 형태의 데이터끼리 모여있으니 압축률이 높아진다.

필요한 컬럼만 스캔, 그조차도 압축률이 좋으니 조회 시 I/O가 줄어든다.

 

Parquet 파일은 내부에 메타데이터를 갖고 있다.

각 컬럼의 최솟값, 최댓값이 파일 단위로 기록되어 있다.

메타데이터를 보고 범위에 해당하지 않는 파일은 열지도 않는다.

이걸 Predicate Pushdown이라 한다.

 

이렇기에 집계를 위한 데이터로 Parquet 형식을 사용하고자 한다.
컬럼 기반으로 필요한 컬럼만 읽고, 압축률이 높아 I/O가 적고, 메타데이터로 파일 자체를 건너뛸 수 있다.

 

Athena 와 검색 속도

S3에 저장된 Parquet 파일의 조회는 AWS Athena를 사용하면 쉽게 처리할 수 있다.

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

 

1. 적절한 파일 분리

너무 파일이 많으면 각 파일의 메타데이터를 확인하기 위해 파일을 읽고 닫으며 오버헤드가 발생한다.

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

한 파일로 저장할 사이즈를 보통 100 ~ 500MB로 묶어 관리하는 것을 권장한다.

 

2. 파티션 기반 파일 경로

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

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

이것을 Hive 스타일 파티셔닝이라고 한다.

 

Athena는 Glue 카탈로그로 테이블 정보를 저장한다.

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

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

 

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

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

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

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

 

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

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

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

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

 

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

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

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

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