Kafka Topic 설계와 데이터 분석 구조 정리
오늘은 제조 데이터 처리 구조와 Kafka 도입 범위에 대해 팀원들과 구체적으로 논의했다.
현재 프로젝트는 실제 MES 데이터를 수집하는 구조가 아니라, AI 서비스에서 생성한 Sample 데이터를 기반으로 제조 시뮬레이션을 수행하고 있다.
현재 데이터 흐름 구조
현재 데이터 흐름은 다음과 같이 구성되어 있다.
AI-Service
↓
Sample DB
↓
Backend
↓
분석 수행
↓
Main DB 저장
↓
Frontend 조회AI-Service가 제조 이벤트 데이터를 생성하고 Sample DB에 저장한다.
Backend는 Sample DB 데이터를 읽어 이상 탐지 및 집계 분석을 수행한 뒤 Main DB에 저장한다.
Frontend는 Main DB를 조회하여 대시보드에 데이터를 표시한다.
왜 Main DB에 저장할까?
단순히 실시간 데이터만 보여준다면 Backend에서 분석 후 바로 Frontend로 전달할 수도 있다.
Sample DB
↓
Backend 분석
↓
Frontend하지만 이렇게 되면 과거 데이터 조회가 불가능하다.
관제 시스템에서는 다음과 같은 기능이 필요하다.
과거 이상 이력 조회
위험도 추이 분석
공정별 통계 확인
설비 가동률 히스토리 확인따라서 분석 결과를 Main DB에 저장하는 구조를 유지하기로 했다.
AI-Service와 Backend의 역할 분리
초기에는 데이터 분석 기능을 AI-Service로 이동하는 방안도 검토했다.
하지만 현재 분석 로직은 대부분 규칙 기반 계산 수준이기 때문에 Backend에서 처리하는 것이 더 효율적이라고 판단했다.
최종 역할은 다음과 같이 정리되었다.
Backend
생산 데이터 집계
설비 가동률 계산
이상 여부 판정
분석 결과 저장AI-Service
Sample 제조 데이터 생성
공정 불량 분석
병목 현상 분석Assembly Service
규칙 기반 이상 탐지Kafka를 어디에 적용할 것인가?
현재 가장 많이 논의한 부분은 Kafka를 어느 구간에 사용할지였다.
Kafka를 사용하는 목적은 다음과 같다.
서비스 간 결합도 감소
비동기 처리
이벤트 기반 구조
서비스 확장성 확보현재 고려 중인 구조는 다음과 같다.
Sample DB
↓
Scheduler
↓
Kafka
├── Manufacturing Service
├── Alert Service
├── Equipment Service
├── Dashboard Service
└── AI ServiceScheduler가 Producer 역할을 수행하고,
각 서비스가 Consumer가 되어 동일 이벤트를 독립적으로 처리하는 구조이다.
Kafka Topic 설계
제조 서비스에서 사용할 Topic은 다음과 같이 정의하였다.
factory.manufacturing.raw 제조 원천 이벤트
factory.manufacturing.analysis 분석 결과
factory.manufacturing.alert 위험 이벤트
factory.manufacturing.equipment 설비 상태현재는 각 Topic당 Partition 2개를 고려하고 있다.
Kafka Partition에 대한 이해
회의 중 가장 많이 헷갈렸던 부분은
"브로커가 2대면 토픽도 반으로 나뉘는가?"였다.
예를 들어
Broker 1
Broker 2가 존재하고
Topic 10개
Partition 1개
라면
토픽이 5개씩 나뉘는 것이 아니다.
실제로는
Topic
└─ Partition
↓
Broker 배치구조가 된다.
즉,
Topic
↓
Partition
↓
Broker순서로 생각해야 한다.
토픽은 논리적인 이름일 뿐이고 실제 데이터 저장 단위는 Partition이다.
Kafka는 Partition 리더를 여러 브로커에 분산 배치하여 부하를 분산한다.
제조 분석 결과 테이블 구조 정리
분석 결과는 공통 테이블과 공정별 상세 테이블로 분리하기로 했다.
공통 분석 결과
manufacturing_analysis_result저장 정보
이벤트 ID
차량 ID
설비 ID
공정 코드
이상 여부
위험도 점수
심각도
분석 메시지공정별 상세 결과
Press
press_analysis_result- 사이클 타임
- 지연 시간
- 생산 카운트 증가 여부
Body
body_analysis_result- 진동 분석
- 주파수 분석
- 로봇 상태
Paint
paint_analysis_result- 도장 두께
- 표면 품질
- 비전 분석 결과
Assembly
assembly_analysis_result- 작업 순서 오류
- 누락 부품
- 체결 오류
설비 가동률 계산 방식
설비 상태 이력을 저장하는 테이블도 추가하였다.
equipment_status_history공정별 가동률은 다음과 같이 계산한다.
가동률 = 현재 RUNNING 설비 수 / 전체 설비 수 × 100이를 통해 대시보드에서 실시간 설비 가동 현황을 시각화할 수 있다.
강사님 피드백
오늘 받은 주요 피드백은 다음과 같다.
- Kafka는 로컬에서 먼저 검증
MSK를 바로 구축하기보다
Docker Kafka
→ 기능 검증
→ AWS MSK순서로 진행하는 것이 좋다.
- 서비스 간 데이터 흐름 명확화
각 서비스가 어떤 데이터를 생산하고 소비하는지
팀원 전체가 동일하게 이해할 수 있도록 데이터 흐름도를 정리할 필요가 있다.
- 관제 시스템만의 강점 강조
발표 시
로그를 직접 분석해야 하는 기존 방식
VS
한 화면에서 전체 공정을 파악할 수 있는 관제 시스템
이라는 차별점을 강조하는 것이 좋다는 피드백을 받았다.
마무리
오늘은 Kafka 도입 범위와 제조 데이터 분석 구조를 상당히 구체화할 수 있었다.
특히 Kafka Topic, Consumer Group, Partition 구조를 실제 서비스 관점에서 정리하면서 단순히 "Kafka를 사용한다" 수준이 아니라 어떤 데이터를 어디서 발행하고 누가 소비할 것인지까지 정의할 수 있었다.
다음 단계에서는 Docker 기반 Kafka 환경을 먼저 구축하고,
Scheduler → Kafka → Consumer 구조를 실제로 연결해보면서 이벤트 흐름을 검증할 예정이다.
