인프라 / DevOps·

쏘카·2024년

FMS(Fleet Management System) 주행이벤트 파이프라인 개선기

쏘카 FMS 팀이 차량 관제 플랫폼 구축 과정에서 IoT 주행이벤트 파이프라인을 두 차례 개선한 경험을 공유한다. 1차는 데이터 순서 보장을 위해 RDB 기반 배치 구조를 도입했고, 2차는 스케줄링 기반 배치를 Kafka + NoSQL 이벤트 기반으로 전환해 실시간성·확장성·멱등성까지 확보했다.

핵심 포인트

주행이벤트 특성: 트립 단위(시작→상태→종료), 선행 이벤트 기준 후행 탐지로 데이터 순서가 필수
1차 문제: 서로 다른 프로토콜·데이터 묶음 수 차이로 이벤트 발행 서버에서 순서 미보장
1차 해결: IoT 데이터를 RDB에 먼저 적재 → 스케줄링으로 순서 제어 후 이벤트 탐지
2차 문제: 배치 방식으로 특정 시간대 리소스 집중, RDB는 대량 비동기 처리 비적합, MSA 장애 시 연속성 부재
2차 해결: Kafka + NoSQL 전환 + Check-In & Check-Out 패턴으로 차량별 이벤트 직렬화

상세 정리

원천 데이터: 이동 데이터(위치·속도 등 기하학적 정보) + 상태 데이터(엔진 상태·주유량 등)
IoT 특성: 차량이 최대 2분 단위로 데이터 전송, 서로 다른 프로토콜 혼재
1차 RDB 도입: 팀 숙련도 높은 RDB 선택, 쿼리로 데이터 순서 제어 가능 → 순서 보장 기반 마련
2차 Kafka 선택 이유: 대량 IoT 데이터 고처리량 처리, MSA 환경 서버 일시 중단에 유연 대응, 메시지 재처리 가능
2차 NoSQL 선택 이유: 비동기 드라이버 지원으로 파이프라인 비동기 구간 확장, RDB 대비 효과적 스케일아웃
Check-In & Check-Out 패턴: 차량별로 한 번에 하나의 Chunk만 처리 → 분산 환경 이벤트 순서 보장
DeadLock 방지: Check-In Expire 정책 + 멱등성 있는 앱 설계로 무한 대기 상태 방지
TTL 정책: NoSQL 대용량 시계열 데이터는 TTL 인덱스로 자동 삭제 (원천 데이터는 별도 백업)
정합성 검증: 실차 테스트(실제 차량 운행 데이터 시뮬레이션) + 선행/후행 이벤트 순환 검증
효과: 배치성 리소스 집중 최소화, 서버 간 역할 명확화, 알림 서버 등 확장 구조 개방

왜 읽나IoT 대량 트래픽 환경에서 이벤트 순서 보장과 MSA 연속성을 동시에 해결하기 위해 Kafka + NoSQL + Check-In/Out 패턴을 선택한 실전 파이프라인 진화 과정이 담겨 있다.

쏘카 블로그

원문은 여기서 이어서 읽을 수 있어요

읽음 (0)

·takedown 요청

이 글과 비슷한