Technical Challenges

1. 실시간 데이터 처리 파이프라인 구축

Event-Driven Streaming Architecture 전환

문제 상황

초기 시스템은 FastAPI 크롤러가 LibreView에서 데이터를 수집하여 MySQL에 저장하면, Spring Boot Scheduler가 주기적으로 조회하는 단순 배치 구조였습니다. 이로 인해 급격한 혈당 변화를 실시간으로 감지하지 못했고, 사용자는 지연된 데이터를 확인하게 되는 한계가 있었습니다.

기술적 해결

실시간성 확보를 위해 Event-Driven Streaming Architecture로 전환했습니다.

아키텍처 구성

• Airflow: 크롤링 스케줄 관리 및 ETL 워크플로우 조율

• Kafka: 데이터 스트림 전달 및 메시지 유실 방지

• Spring Boot Consumer: Kafka 메시지 구독 후 MySQL 적재

• Redis Cache: 최신 데이터 캐싱으로 빠른 조회 지원

• WebSocket (STOMP): 클라이언트에 실시간 푸시

Kafka Topic으로 발행된 데이터는 Consumer에서 처리되는 즉시 MySQL에 저장되고, WebSocket을 통해 대시보드에 실시간 전송됩니다.

LibreView → Airflow (ETL) → Kafka (Producer)
                              ↓
                        Spring Boot (Consumer)
                        ├── MySQL (Storage)
                        ├── Redis (Cache)
                        └── WebSocket → Dashboard

결과

데이터 수집 즉시 클라이언트에 반영되는 구조를 구축하여 실시간 혈당 변화 모니터링이 가능해졌습니다.

---

2. 안정적인 파이프라인 재구성

Modular DAG 기반 안정성 확보

문제 상황

초기 파이프라인은 단일 스케줄러로 구성되어, 작업 실패 시 전체 프로세스가 중단되고 재실행이 필요했습니다. 또한 순차 처리로 인한 병목 현상이 발생했습니다.

기술적 해결

Modular DAG 기반 파이프라인을 Airflow로 재설계했습니다.

핵심 개선사항

• Task 독립화: crawl → validate → store → aggregate로 분리

• 병렬 처리: S3 저장과 MySQL 적재 동시 수행

• 부분 재실행: XCom을 활용해 실패한 Task만 재실행

• 결합도 완화: Kafka로 수집(Producer)과 처리(Consumer) 분리

• 실시간 처리: Spark Streaming으로 데이터 스트림 처리

• 배치 집계: Spark Batch로 일일 통계 자동 계산

Airflow DAG
├── Crawl Task → Kafka Topic (Raw Data)
├── Validate Task → Data Cleaning
├── Store Task → [S3, MySQL] (병렬 처리)
└── Aggregate Task (Spark Batch → Daily Summary)

결과

병렬 처리로 전환하여 파이프라인의 안정성과 유지보수성을 향상시켰습니다.

---

3. 데이터 품질 관리 체계 구축

다층 검증을 통한 신뢰도 확보

문제 상황

외부 크롤링 데이터에서 누락, 중복, 비정상 값이 발견되어 통계 분석 결과의 신뢰도가 저하되었습니다.

기술적 해결

Airflow에 Data Validation Layer를 추가하고, 다층 검증 구조를 구축했습니다.

검증 로직

• 범위 검증: 비정상 혈당값(40~400mg/dL 범위 외) 제거

• 중복 제거: pet_id + timestamp 기준 deduplication

• 타임존 정규화: UTC → KST 변환

• 멱등성 보장: Kafka Consumer에 idempotency 로직 적용

• DB 제약: MySQL UNIQUE INDEX로 중복 차단

• 자동 알림: 이상치 비율 초과 시 Slack Webhook 발송

Airflow → Validate Task → Kafka (Cleaned Data)
                              ↓
                        Spring Boot Consumer
                        ├── MySQL (with UNIQUE INDEX)
                        └── S3 (Raw Backup)

결과

데이터 정합성이 강화되어 통계 분석에 신뢰할 수 있는 데이터를 제공할 수 있게 되었습니다.

---

4. 처리 계층 분리 설계

Lambda Architecture 기반 역할 분담

문제 상황

모든 데이터 처리를 실시간으로 수행하면서 서버 부하가 증가했고, 통계 집계 쿼리 실행 시 응답 지연이 발생했습니다.

기술적 해결

Lambda Architecture 패턴으로 데이터 처리 계층을 분리했습니다.

계층별 역할

• Speed Layer (실시간): Kafka + Spark Streaming → Redis 캐싱

• Batch Layer (정기 집계): Airflow + Spark Batch → MySQL Summary Table

• Serving Layer (조회): Spring Boot → MySQL & Redis

Spark Batch는 매일 새벽 Airflow DAG에 의해 실행되며, 전날 데이터를 집계하여 평균 혈당, 스파이크 횟수 등을 계산합니다.

Kafka Stream → Spark Streaming → Redis (Speed Layer)
                 ↓
            Spark Batch (via Airflow) → MySQL Summary (Batch Layer)
                 ↓
                 API (Serving Layer) → Dashboard

결과

실시간성과 집계 효율성을 동시에 확보하고, 서버 부하를 분산시킨 안정적인 운영 환경을 구축했습니다.

---

5. 사료 데이터베이스 구축

크롤링 기반 정보 수집 및 관리

문제 상황

반려동물 사료에 대한 체계적인 정보가 부족하여, 사용자가 영양 성분을 기반으로 사료를 비교하기 어려웠습니다.

기술적 해결

Selenium을 활용해 사료 정보를 자동 수집하고 MongoDB에 저장했습니다.

구현 내용

• 다나와에서 개·고양이 사료 정보 크롤링

• 영양 성분 데이터 정규화 (단백질, 탄수화물, GI 지수 등)

• MongoDB 스키마 설계 및 인덱싱

• 카테고리별 필터링 API 구현 (저탄수화물, 저GI, 고단백 등)

Django Crawler (Celery) → Data Normalization → MongoDB
                                                  ↓
                                          Spring Boot API
                                                  ↓
                                        Category Filter → Frontend

결과

사용자가 원하는 영양 기준에 맞는 사료를 빠르게 검색할 수 있는 데이터베이스를 구축했습니다.

향후 개선 방향 현재는 카테고리 기반 필터링만 제공하며, 향후 혈당 데이터와 연계하여 개체별 맞춤형 사료 추천 알고리즘으로 발전시킬 예정입니다.

---

6. 도메인 기준 정립

수의사 협업을 통한 임계값 표준화

문제 상황

팀 내부에 반려동물 건강 데이터 해석 전문 지식이 부족해, 혈당 정상 범위와 알림 기준이 명확하지 않았습니다.

기술적 해결

수의사 및 반려동물 보호자 인터뷰를 통해 도메인 지식을 수집하고, 시스템 설계에 반영했습니다.

확립된 기준

• 수의사 자문으로 혈당 정상 범위(80~120mg/dL) 및 스파이크 정의(30분 내 30% 이상 변화) 확립

• 보호자 인터뷰로 알림 빈도 및 리포트 지표 검증

• 알림 우선순위(저혈당 > 고혈당 > 스파이크) 로직 구현

Sensor Data → Validation (Airflow)
   ↓
Alert Rule Engine (Spring Boot)
   ↓
WebSocket → User Notification

결과

도메인 기준을 명확히 정의하여 데이터 해석의 일관성과 알림 로직의 신뢰도를 높였습니다.