개인 프로젝트

IoT 센서 로그 데이터 수집 및 적재 파이프라인 구축

Personal Cloud Project · 2022 · 1명 · 4 min read 읽기

RaspberryPi(+SenseHAT)로 실시간 수집한 센서 데이터를 Kappa Architecture 기반으로 AWS IoT Core → Kinesis → S3/OpenSearch 이원 구조에 적재하고, Lambda와 Athena CTAS로 파일 단위 자동 압축까지 구현한 개인 학습 프로젝트입니다. AWS 클라우드 서비스 8종 이상을 엮어 하나의 데이터 파이프라인으로 설계·검증했습니다.

Overview

RaspberryPi 4B와 SenseHAT 센서를 이용해 실시간으로 발생하는 온·습도 데이터를 Kappa Architecture 기반 파이프라인으로 처리하는 프로젝트를 개인적으로 진행했습니다. 센서 데이터는 Kinesis Data Stream을 통해 Pub/Sub 구조로 분산되고, 두 개의 Consumer(OpenSearch, S3)가 이를 각각 검색·시각화 목적과 배치 저장 목적으로 소비하도록 설계했습니다. S3에 쌓인 데이터는 일정 파일 개수가 모이면 Lambda와 Athena를 통해 자동으로 압축되어 별도 디렉토리에 저장되도록 구성했습니다.

Constraints

  • 단일 RaspberryPi 기기, 개인 실습 환경이라 관리형 서비스 위주로 구성해 운영 부담을 최소화해야 함
  • 검색·시각화용 저장소와 배치 압축 저장소, 두 갈래로 데이터를 동시에 소비해야 함
  • AWS 서비스 간(IoT Core ↔ Kinesis 등) 통신을 위한 IAM Role 설정 및 권한 구조를 직접 설계해야 함
  • 비동기 통신과 동기 통신의 차이를 실제로 검증해 적합한 프로토콜을 선택해야 함

Tech Stack

  • RaspberryPi 4B + SenseHAT
  • AWS IoT Core (MQTT Bridge)
  • mosquitto
  • AWS IoT Rule
  • Amazon Kinesis Data Streams
  • Kinesis Data Firehose
  • Amazon S3
  • AWS Lambda (Python)
  • Amazon DynamoDB
  • Amazon Athena (CTAS Query)
  • Amazon OpenSearch (Elasticsearch) Service
  • EC2 (Windows Server 2016)

Learnings

  • AWS 서비스 간 통신에서 IAM Role 설정 이슈를 직접 겪고 해결했습니다. 일반 IAM 메뉴에서 생성한 Role을 그대로 적용했을 때는 계속 에러가 발생했고, IoT Rule 생성 시 Role을 자동 생성하도록 하자 해결됐습니다 — IoT Rule에 적용되는 Role은 일반 IAM 목록과 별도로 관리된다는 것을 이 과정에서 알게 됐습니다.
  • MQTT 브로커(mosquitto)가 클러스터링을 지원하지 않는다는 한계를 직접 확인했고, 향후 HiveMQ나 RabbitMQ처럼 클러스터링을 지원하는 브로커로 검증을 확장할 필요성을 인지했습니다.
  • 단일 기기 환경이라 실제 병목(Bottleneck)은 발생하지 않았지만, Kinesis shard 수와 Consumer 증가에 따른 비용·성능 트레이드오프를 미리 시뮬레이션해보며 확장 시나리오를 고민했습니다.

Problem

실시간으로 발생하는 IoT 센서 데이터를 처리할 때, 서로 다른 목적(실시간 검색·시각화 vs 배치 저장)을 가진 두 소비자가 같은 데이터 스트림을 안정적으로 각자 소비할 수 있는 구조가 필요했습니다. 또한 데이터가 계속 쌓이는 환경에서 개별 파일이 무한정 늘어나면 저장 효율과 관리 비용이 나빠지므로, 이를 자동으로 압축·정리하는 장치도 함께 고민해야 했습니다. 더불어 AWS 클라우드 환경에서 서비스 간 통신을 위한 IAM 권한 구조를 처음부터 직접 설계하고 검증해야 하는 러닝커브도 있었습니다.

Approach

(1) 디바이스 → 클라우드 진입점. RaspberryPi(SenseHAT)의 센서 데이터를 MQTT Protocol Bridge를 제공하는 AWS IoT Core에 연결했습니다. 실제 전송 전 mosquitto 오픈소스 브로커로 송수신을 먼저 검증했고, HTTP(동기식, stateless)보다 MQTT(비동기식, pub/sub 구조)가 저전력 IoT 기기에 적합하다는 걸 확인한 뒤 AWS IoT Core를 브릿지로 채택했습니다. (2) 스트리밍 허브 구성. AWS IoT Rule로 수신 메시지에 대한 처리 규칙(SQL 쿼리 기반)을 정의하고, Kinesis Data Stream으로 데이터를 전달했습니다. Kinesis를 선택한 이유는 다중 Consumer가 동일 스트림을 독립적으로 소비할 수 있어, 파이프라인 구성 요소들이 서로 장애 영향 없이 분리되기 때문입니다. (3) 이원화된 소비 구조. Kinesis Data Firehose를 두 갈래로 구성해, 한쪽은 OpenSearch(Elasticsearch) 서비스로 실시간 인덱싱(시간대별 Index rotation)하고, 다른 한쪽은 S3에 원본 데이터를 적재했습니다. OpenSearch는 별도 VPC/Subnet에 생성해 보안 통신을 확보했고, 같은 도메인의 EC2(Windows Server 2016)를 통해 대시보드에 접근하도록 구성했습니다. (4) 배치 압축 자동화. S3에 데이터가 쌓이면 Lambda가 트리거되어 DynamoDB에 파일 개수를 카운트하고, 100개 단위로 임계치에 도달하면 Athena의 CTAS 쿼리를 실행해 데이터를 압축된 형태로 별도 디렉토리에 저장하도록 자동화했습니다. 압축 후에는 원본 디렉토리를 비우고 카운터를 초기화하는 로직까지 포함했습니다.

Key Decisions

MQTT 비동기 통신 채택 — HTTP 대신 AWS IoT Core(MQTT Bridge) 선택

Reasoning:

HTTP는 클라이언트가 서버 응답까지 기다려야 하는 동기식 통신이고 상태를 기억하지 않는(stateless) 방식이라 비효율적이었습니다. 반면 MQTT는 비동기 pub/sub 구조로 브로커에 메시지를 전달하기만 하면 되어 응답 대기 시간이 필요 없고, 경량 프로토콜이라 저전력 IoT 기기에 적합했습니다.

Alternatives considered:
  • HTTP 기반 동기식 통신

Kinesis Data Stream을 통한 Pub/Sub 구조 설계

Reasoning:

다중 Consumer(OpenSearch, S3)가 동일한 데이터 스트림을 동시에 독립적으로 읽을 수 있어야 했습니다. Pub/Sub 구조로 생산과 소비 양 끝단을 분리하면 각 구성 요소가 독립적으로 실행되고, 장애가 발생해도 시스템 전체의 내결함성이 향상된다고 판단했습니다.

Alternatives considered:
  • Consumer 없이 단일 파이프라인으로 직접 연결

대규모 확장 시 스트리밍 플랫폼 대안 검토 — EC2 자체 Kafka vs AWS MSK

Reasoning:

데이터 양이 늘어나고 Consumer 구조가 복잡해지면 Kinesis shard 확장 비용과 서비스 사용 비용이 함께 증가하는 한계가 있었습니다. 이를 대비해 두 가지 대안을 검토했는데, 유지·관리 인적 리소스가 충분하면 EC2에 Kafka를 직접 구축하는 방법을, 그렇지 않다면 AWS MSK 완전 관리형 서비스로 관리 비용을 최소화하는 방법을 최종 대안으로 정리했습니다. 관리 대상을 최소화하고 서비스 자체에 집중하는 방향이 낫다고 판단해, 관리형 서비스 쪽에 무게를 뒀습니다.

Alternatives considered:
  • EC2 인스턴스에 Kafka 직접 설치·운영
  • AWS MSK(Fully Managed Apache Kafka) 사용

Lambda + DynamoDB + Athena CTAS를 통한 자동 압축 트리거 설계

Reasoning:

파일이 압축 없이 계속 쌓이면 저장 비용과 관리 부담이 커집니다. S3 적재를 Lambda 트리거로 감지하고 DynamoDB로 파일 개수를 카운트해, 100개 단위(설정값)로 임계치에 도달하면 Athena CTAS 쿼리로 자동 압축되도록 설계해 사람이 개입하지 않아도 되는 구조를 만들었습니다.

Alternatives considered:
  • 수동 배치 스크립트로 주기적 압축 실행

Result & Impact

  • RaspberryPi + SenseHAT 센서 데이터 → AWS 서비스 8종 이상을 엮은 파이프라인으로 통합
    아키텍처 규모
  • Kinesis 기반 Pub/Sub 구조로 OpenSearch·S3 이원화 소비 구조 구현
    데이터 소비 구조
  • Lambda + Athena CTAS로 100개 파일 단위 자동 압축 파이프라인 구축
    저장 최적화

AWS IoT Core부터 Kinesis, Lambda, DynamoDB, Athena, OpenSearch까지 이어지는 파이프라인을 개인적으로 설계·구축하며, 단일 클라우드 서비스가 아니라 여러 서비스를 목적에 맞게 조합하고 그 이유를 검증하는 경험을 쌓았습니다. IAM 권한 이슈처럼 실제로 부딪힌 문제를 직접 해결하며 AWS 환경에 대한 실전 감각을 키운 프로젝트입니다.

전체 프로젝트