Project 03

SFEP : Smart Factory Event Processing System

  • 기간 : 2026.06 ~ 2026.06
  • 규모 : 개인 프로젝트
  • 기여도 : 100%
GitHub Notion 목록으로

Project Summary

Spring Boot와 Kafka 기반 Event-Driven Architecture를 활용하여 대규모 제조 설비 이벤트를 실시간 처리하는 Smart Factory Backend 시스템입니다.

이벤트 수집부터 저장, 이상 예측, 운영 모니터링까지 연결해 제조 데이터 처리의 확장성과 서비스 운영 안정성을 확보했습니다.

Overview

Manufacturing Problem

제조 설비는 여러 센서 데이터를 지속적으로 생성하고, 단순 임계값 기반 판단만으로는 복합 상태와 시간 흐름을 반영한 조기 고장 예측 이 어렵습니다.

Solution

설비 이벤트를 Kafka 기반 Event-Driven Architecture 로 처리하고, AI4I 제조 설비 데이터를 기반으로 이상 예지 모델을 학습했습니다.

학습 모델을 ONNX 형태로 Spring 서버에 통합해 Failure Probability 기반 설비별 고장 확률을 실시간 예측 하도록 구성했습니다.

Spring Boot Kafka Event-Driven Consumer Group JDBC Batch PostgreSQL ONNX Runtime Prometheus

Role

  • Event-Driven Backend Architecture

    Spring Boot 기반 제조 설비 이벤트 수집/처리 백엔드 설계, Kafka 기반 저장·알림·예측 흐름 연결

  • Messaging Architecture

    Storage Consumer Group의 Partition 기반 병렬 소비 구조 구성, Alert Consumer Group의 실시간 위험 알림 전용 흐름 분리

  • Performance Optimization

    Batch Insert, Partition, Consumer Concurrency 기반 대량 이벤트 처리 구조 설계

  • AI Integration

    최근 센서 이벤트 흐름의 모델 입력 변환, Spring 서버 내부 이상 예측 추론 흐름 구현

  • Monitoring

    처리량, 지연 시간, JVM/DB 리소스 관찰을 위한 운영 모니터링 환경 구축

  • Benchmark

    저장/알림 처리 성능 비교 검증을 위한 자동 Benchmark 실험 환경 구성

Project Highlights

01

Kafka

Event-Driven Architecture

02

96.5%

53,611ms → 1,849ms 처리 시간 단축

03

27,056 events/sec

PostgreSQL 저장 처리율

04

Consumer Group

Storage / Alert 독립 처리

05

50,000 events/sec

Consumer 병렬 처리 Benchmark 최대 처리량

06

JDBC Batch Insert

대량 저장 최적화

07

Rolling Window

최근 50개 이벤트 / 52 Features

08

ONNX Runtime

Spring 서버 내 모델 추론

09

F1 0.8889

ROC-AUC 0.9740

10

Prometheus / Grafana

운영 및 성능 모니터링

Event-Driven Architecture

  1. 01

    Simulator

    가상 제조 설비 센서 이벤트 생성

  2. 02

    Kafka Producer

    이벤트를 Topic으로 비동기 발행

03

Kafka Topic

동일 이벤트를 저장 흐름과 알림 흐름이 각각 독립적으로 소비

Storage Consumer Group

저장 전용 처리 흐름

  1. 01

    Storage Consumer Group

    동일 Topic의 이벤트를 저장 목적에 맞게 독립 소비

  2. 02

    JDBC Batch Insert

    이벤트를 묶어서 DB Round Trip 감소

  3. 03

    PostgreSQL

    설비 이벤트 이력 저장

Alert Consumer Group

위험 알림 전용 처리 흐름

  1. 01

    Alert Consumer Group

    저장 흐름과 별도로 위험 이벤트 소비

  2. 02

    Rolling Window

    설비별 최근 이벤트 흐름 유지

  3. 03

    ONNX Runtime

    Spring 서버 내부에서 모델 추론

  4. 04

    Failure Probability

    설비별 고장 확률 계산

  5. 05

    SSE Alert

    운영자 화면으로 실시간 위험 알림 전송

DB 저장 병목이 위험 알림 처리에 직접 전파되지 않도록 Storage Consumer Group과 Alert Consumer Group을 독립적으로 구성했습니다.

Consumer Group Design

Storage Consumer Group

  • 동일 Kafka Topic을 저장 목적 흐름으로 독립 소비
  • JDBC Batch Insert 기반 PostgreSQL 저장

Alert Consumer Group

  • 동일 Kafka Topic을 위험 알림 목적 흐름으로 독립 소비
  • Rolling Window, ONNX 추론, SSE 알림 처리

Storage Consumer Group 기준으로 Kafka Partition 6개를 Consumer 3개가 병렬 처리하도록 구성하여 대량 이벤트 저장 처리량을 향상시켰습니다.

Partition 1 Partition 2
↓

Consumer 1

Partition 3 Partition 4
↓

Consumer 2

Partition 5 Partition 6
↓

Consumer 3

병렬 처리 기능 분리 저장과 알림의 독립성 Consumer Lag 완화 처리량 증가 확장성 확보

Rolling Window Feature Generation

  1. 01

    최근 50개 이벤트

    설비별 시계열 센서 값 유지

  2. 02

    Statistical Features

    Mean / Max / Min / Standard Deviation / Trend 병렬 추출

  3. 03

    52 Features

    모델 입력 Feature Vector 생성

  4. 04

    ONNX Runtime

    Spring 서버 내부에서 모델 추론

  5. 05

    Failure Probability

    설비별 고장 확률 계산

최근 이벤트의 변화 흐름을 반영한 시계열 Feature를 생성하여 단순 임계값 기반 판단이 아닌 모델 기반 고장 확률 예측을 수행했습니다.

Features & Demo

설비 이벤트 시뮬레이터
SFEP 설비 이벤트 시뮬레이터 GIF

Swing 기반 시뮬레이터의 설비 수, 설비당 이벤트 수, 장애 비율 설정 및 가상 설비 이벤트 생성

실시간 처리 성능 모니터링
SFEP 실시간 처리 성능 모니터링 GIF

일정 시간 이벤트 발생 기반 운영 환경 유사 트래픽 처리 안정성 확인

Benchmark Result

Batch Insert 적용 전후 처리 시간과 Consumer Concurrency별 처리량 비교, 대량 이벤트 처리 성능 개선 결과 검증

AI 기반 실시간 설비 고장 위험 알림
SFEP AI 기반 실시간 설비 고장 위험 알림 GIF

설비별 최근 50개 이벤트 기반 52개 Feature 생성, ONNX 모델 기반 고장 확률 예측 및 위험 설비 표시

Prometheus / Grafana 모니터링
SFEP Prometheus Grafana 모니터링 화면

HTTP, JVM, Hikari DB Connection, CPU 지표 확인

System Architecture

SFEP 시스템 아키텍처
System Architecture
SFEP 시스템 플로우
System Flow
SFEP 예측 플로우
Prediction Flow

Tech Stack

01

Backend

API 서버, 이벤트 처리, 모델 추론 연동

Spring Boot Spring Web Spring Kafka Spring JDBC Batch Spring Actuator ONNX Runtime
02

Messaging

설비 이벤트 수집과 실시간 알림 흐름

Apache Kafka Consumer Group Kafka Partition SSE
03

AI / Model

고장 확률 예측 모델 학습과 서버 통합

AI4I 2020 Dataset Rolling Window Feature Scikit-learn ONNX
04

Database

센서 이벤트 저장과 조회 기반

PostgreSQL
05

Monitoring

처리량, 지연 시간, 서버 상태 추적

Prometheus Grafana Micrometer
06

Infra / Tools

로컬 실행 환경과 형상 관리

Docker Compose Git

Benchmark Strategy

자동 Benchmark Script를 통해 JDBC Batch Size, Consumer Concurrency, Kafka Partition, max.poll.records, Hikari Connection Pool 조합을 반복 실행하고, 처리 시간·저장 처리율·Consumer Lag·알림 지연을 비교하여 최적 구성을 검증했습니다.

JDBC Batch Size Consumer Concurrency Kafka Partition max.poll.records Hikari Connection Pool
Processing Time Save Events/sec Consumer Lag Alert Average Latency Alert p95 Alert p99
  1. 01

    Baseline

    Direct DB Write 기준 성능 측정

  2. 02

    Batch Size 증가

    저장 단위 조정으로 DB 호출 횟수 감소

  3. 03

    Poll Records 증가

    Consumer가 한 번에 가져오는 이벤트 수 조정

  4. 04

    Connection Pool 조정

    DB Connection 병목 여부 검증

  5. 05

    Consumer Concurrency 조정

    Consumer 병렬 처리량 확인

  6. 06

    Partition 변경

    병렬 소비 가능한 Topic 구조 검증

  7. 07

    최적 구성 도출

    처리량과 지연 시간을 함께 비교

Why Technology?

Kafka

  • 대량 설비 이벤트 버퍼링
  • Producer / Consumer 비동기 분리
  • 실시간 데이터 처리 구조 확보

Consumer Group

  • Partition 기반 병렬 처리
  • Storage / Alert 처리 흐름 분리
  • Consumer Lag 완화 및 처리량 확장

JDBC Batch Insert

  • DB Round Trip 감소
  • 대량 저장 최적화

ONNX Runtime

  • Python 모델을 Java 환경에서 직접 추론
  • AI 서버 없이 Spring 서버에서 실행 가능

PostgreSQL

  • 대량 이벤트 저장
  • Batch Insert 최적화

Prometheus / Grafana

  • JVM / CPU / Memory
  • HTTP 요청 및 처리량 모니터링

Docker Compose

  • Kafka, PostgreSQL, Prometheus, Grafana 실행 환경 통합
  • 개발 및 테스트 환경 일관성 유지
  • 성능 실험 환경 재현성 확보

Improvements

Direct DB Write 구조에서 발생한 저장 병목

상황 1
AS-IS
  • 시뮬레이터 이벤트를 Spring 서버가 PostgreSQL에 직접 저장
  • 대량 이벤트 유입 시 요청 처리와 DB 저장이 강하게 결합
  • 100,000건 처리 기준 53,611ms 소요, 처리율 933 events/sec 수준
TO-BE
  • Kafka 기반으로 이벤트 수집과 저장 흐름 분리
  • Consumer가 이벤트를 비동기로 처리하고 Batch Insert 적용
  • 53,611ms에서 1,849ms로 약 96.5% 처리 시간 단축
  • 933 events/sec에서 27,056 events/sec로 약 29배 저장 처리율 향상
방식 처리 시간 처리율
Direct DB Write 53,611ms 933 events/sec
Batch Insert 1,849ms 27,056 events/sec

Kafka 기반 수집/저장 분리와 Batch Insert 적용으로 100,000건 이벤트 처리 시간을 53,611ms에서 1,849ms로 줄이고 PostgreSQL 저장 처리율을 약 29배 높였습니다.

Batch Insert 처리 흐름

  1. 01

    Kafka Batch Consumer

    이벤트를 묶어서 소비

  2. 02

    1000 Records

    저장 단위를 Batch로 구성

  3. 03

    JDBC Batch

    PreparedStatement Batch 실행

  4. 04

    rewriteBatchedInserts

    PostgreSQL Multi-row Insert 변환

  5. 05

    PostgreSQL

    대량 이벤트 저장

  6. 06

    ON CONFLICT DO NOTHING

    중복 이벤트 저장 방지

  7. 07

    Commit

    Batch 단위 트랜잭션 확정

Batch Insert와 PostgreSQL Batch Rewrite를 함께 적용하여 DB Round Trip을 최소화하고 저장 성능을 개선했습니다.

단일 Consumer 처리 구조의 처리량 한계

상황 2
AS-IS
  • Kafka를 도입해도 Consumer가 단일 처리 구조이면 이벤트 처리 속도에 한계
  • 이벤트 생산 속도가 소비 속도보다 빨라지면 Consumer Lag 증가
  • Topic에 이벤트가 쌓이며 실시간 처리성이 떨어질 가능성
TO-BE
  • Kafka Topic Partition을 6개로 구성
  • Consumer Concurrency 3 기반 병렬 처리 구조 적용
  • max.poll.records, Batch Size, Hikari Connection Pool 설정을 조합하며 처리량 실험

Kafka Consumer 병렬 처리 Benchmark 기준 최대 50,000 events/sec 수준의 처리량을 확인했습니다.

Consumer Parallel Flow

01

Kafka Topic

6 Partitions

Partition 1 Partition 2
↓

Consumer 1

Partition 3 Partition 4
↓

Consumer 2

Partition 5 Partition 6
↓

Consumer 3

  1. 02

    JDBC Batch Insert

    Consumer별 이벤트를 묶어서 저장

  2. 03

    PostgreSQL

    대량 설비 이벤트 이력 저장

Partition 단위 병렬 처리 Consumer Concurrency 3 적용 Consumer Lag 완화 처리량 확장성 확보 Consumer 수가 Partition 수를 초과하면 일부 Consumer는 할당받을 Partition이 없어 유휴 상태가 됩니다.

저장 처리와 위험 알림 처리가 같은 흐름에 묶이는 문제

상황 3
AS-IS
  • 위험 이벤트 알림이 DB 저장 흐름에 함께 묶인 구조
  • DB 저장이 느려지는 순간 알림 전달도 함께 지연
  • 설비 과열, 진동 이상, 전류 급증 이벤트는 저장보다 빠른 운영자 인지가 중요
TO-BE
  • Kafka Consumer Group을 저장 Consumer와 알림 Consumer로 분리
  • 동일 센서 이벤트를 저장/알림 Consumer가 각각 독립적으로 소비
  • AlertEventBus와 별도 Thread Pool 기반 비동기 알림 처리
항목 p95 알림 지연
저장 흐름 중심 처리 6,959ms
Alert Consumer 분리 후 1,926ms

Alert Consumer 분리 후 p95 알림 지연 시간을 72% 단축했습니다.

Rule-Based 위험 판단의 한계

상황 4
AS-IS
  • 초기 위험 판단은 온도, 진동, 토크 등 단일 임계치 기반 Rule-Based 방식
  • 제조 설비 고장 위험은 여러 센서 값의 조합과 최근 변화 흐름을 함께 봐야 하는 특성
  • 단일 값 기준 판단만으로는 복합적인 이상 징후를 포착하기 어려운 한계
TO-BE
  • AI4I 2020 Predictive Maintenance Dataset 기반 고장 예측 모델 학습
  • 설비별 최근 50개 이벤트를 Rolling Window로 관리하고 52개 Feature 생성
  • Spring 서버에서 ONNX Runtime으로 모델을 직접 로드해 실시간 failure_probability 계산
항목 값
Accuracy 0.9930
고장 Precision 0.9655
고장 Recall 0.8235
고장 F1-score 0.8889
ROC-AUC 0.9740
PR-AUC 0.9088

Rule-Based 판단을 모델 추론 구조로 확장해 고장 예측 F1-score 0.8889, ROC-AUC 0.9740을 달성했습니다.

성능 개선 실험을 검증할 운영 지표 부족

상황 5
AS-IS
  • 초기 성능 측정은 Swing UI의 처리 시간과 서버 로그 중심
  • 전체 처리 시간과 초당 처리율은 확인 가능
  • 처리 중 서버 내부의 CPU, JVM, DB Connection 병목은 파악하기 어려운 상태
TO-BE
  • Spring Actuator, Prometheus, Grafana 도입
  • /actuator/prometheus 엔드포인트로 JVM, HTTP 요청, DB Connection, CPU 사용량 메트릭 노출
  • Grafana 대시보드에서 대량 이벤트 처리 실험 중 자원 사용량 확인

Prometheus/Grafana 기반 운영 지표로 성능 개선 실험 중 서버 내부 병목을 함께 추적할 수 있게 했습니다.

Insights

01

성능 최적화

병목 지점을 수치로 분석하고 설정값과 처리 구조를 단계적으로 변경하여 성능 개선 효과를 반복 가능한 실험으로 검증 했습니다.

02

Event-Driven 구조

이벤트 수집, 저장, 위험 알림을 독립적인 처리 흐름으로 분리하여 실시간성과 확장성을 갖춘 제조 데이터 처리 구조 를 설계했습니다.