순서를 지키는 FMS 주행이벤트 파이프라인의 두 차례 교체 (2024-06)

선행 이벤트에 기대는 주행이벤트

FMS 엔지니어링팀은 쏘카 외 차량을 관제하는 PoC에서 주행이벤트 탐지 파이프라인을 만들었습니다. 주행 시작부터 종료까지를 하나의 트립으로 보고, 그 사이에 생기는 차량 상태와 Geofence 이벤트를 주행이벤트로 부릅니다. 후행 이벤트는 선행 이벤트를 기준으로 탐지되므로 순서가 어긋나면 안 됩니다.

입력은 두 종류입니다. 위치와 속도 같은 이동 데이터, 엔진 상태와 주유량 같은 상태 데이터입니다. 두 데이터를 조합해 이벤트를 만들고, 이 이벤트가 실시간 관제와 운행일지, 이동 히스토리 화면의 원천이 됩니다. IoT 데이터는 최대 2분 동안의 이동 정보와 차량 상태 프로토콜로 올라옵니다. 같은 FMS 팀의 데이터 파이프라인은 1편과 2편에도 정리돼 있습니다.

단말 데이터를 먼저 DB에 쌓은 1차 개선

처음 파이프라인은 단말에서 올라온 데이터를 아무 제어 없이 바로 처리했습니다. 프로토콜이 다르면 순서가 지켜지지 않았고, 같은 프로토콜이라도 묶음 크기에 따라 도착 주기가 달라지면 이벤트 발행 서버가 동시에 처리해 순서가 뒤바뀌었습니다.

팀은 쿼리로 순서를 제어할 수 있다고 보고 데이터를 먼저 DB에 적재하기로 했습니다. 이벤트 발행 서버가 일정 주기마다 스케줄링으로 탐지를 돌렸고, DB는 팀이 가장 익숙한 RDB를 골랐습니다. 순서를 보장할 기반이 생겨 플랫폼 정합성이 올랐습니다. 다만 개선을 서둘렀던 탓에 비효율이 남았다고 원문은 설명합니다.

배치성 동작, RDB, 데이터 유실이라는 남은 문제

• 평일 낮에 부하가 몰리는 고객사 특성에도 트래픽이 적은 시간까지 같은 로직이 주기적으로 돌아 자원이 낭비됐고, 배치 특성상 부하가 한 시점에 집중됐습니다.
• 중복 탐지를 막으려고 차량 하나를 Pod 하나만 처리하도록 Lock을 썼는데, 특정 서버가 차량을 많이 선점하면 부하가 고르게 나뉘지 않았습니다.
• RDB는 비동기 처리에 맞지 않았고, 차량이 계속 늘 예정이라 필요한 스케일 아웃과 관리 편의도 충족하지 못했습니다.
• API로 서로 묶인 MSA에서는 배포나 장애로 서버 하나가 멈췄을 때 파이프라인의 연속성을 유지할 방법이 필요했습니다.

Kafka와 NoSQL, Check-In과 Check-Out

2차 개선에서는 RDB를 NoSQL로, 스케줄링을 Kafka 기반 이벤트 구조로 바꿨습니다. Kafka는 대량의 IoT 데이터를 안정적으로 처리할 수 있고, 메시지 큐 기반이면 서버가 잠깐 멈춰도 유연하게 대처할 수 있다고 판단해서 골랐습니다. NoSQL은 비동기 드라이버를 지원하고 RDB보다 스케일 아웃이 쉽다는 점이 이유였습니다. 배치성 로직이 사라졌고 비동기 구간은 넓어졌습니다.

순서 보장은 분산 파이프라인에 Check-In과 Check-Out 개념을 넣어 해결했습니다. 차량별로 한 번에 하나의 Chunk만 순서대로 처리하게 한 방식입니다. 무한 대기를 막으려고 Check-In에 만료 정책을 두었고, 애플리케이션도 멱등하게 설계했습니다. 그 결과 시계열 데이터 적재부터 이벤트 발행까지가 엄격한 트랜잭션 아래 놓였고, 중단 뒤 회복도 빨라졌다고 합니다. NoSQL에 쌓이는 시계열 데이터는 원천 데이터를 이미 백업하고 있어서 TTL 인덱스로 일정 시간이 지나면 지우도록 했습니다.

실차 데이터로 확인한 정합성

새 파이프라인이 기존보다 정확한지 확인하려고 실제 차량을 운행하며 모은 데이터로 시뮬레이션 테스트를 병행했습니다. 판단 기준은 차량별로 발행된 이벤트를 모두 순회하면서, 선행 이벤트 뒤에 올 수 있는 후행 이벤트 조합이 맞게 발행됐는지 보는 것입니다. 팀은 기존 파이프라인을 웃도는 정합성을 확보했다고 밝혔고, 구체적인 수치는 싣지 않았습니다.

결과적으로 짧은 배치성 작업이 사라져 특정 시간대의 부하 집중이 줄었습니다. 서버 간 역할이 분리돼 이슈 대응도 빨라졌고, 알림 서버처럼 이벤트를 받는 서비스로 확장하기도 쉬워졌습니다. 애플리케이션뿐 아니라 데이터 스토리지도 스케일 아웃이 쉬워졌다고 정리합니다.