dev/2024/06/11/fms-trip-event-pipeline

[utterances-bot]

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

FMS 엔지니어링팀에서 파이프라인을 지속적으로 개선한 경험을 공유합니다.

https://tech.socarcorp.kr/dev/2024/06/11/fms-trip-event-pipeline.html

[jjhangu]

Check-In & Check-Out

이거 개념을 적용했다고 하셨는데 조금 자세하게 설명 가능할까요?? kafka에서는 partitionKey를 이용해서 특정 유니크한 아이디 값을 동일한 consumer가 consume하도록 해서 순서를 보장하는데 이와 비슷한 방법일까요?

좋은 글 감사합니다 👍

[socar-marco]

Check-in & Check-out은 한 사이클(IoT 데이터 Mongo -> 이벤트 발행 서버(비동기) -> 완료) 동안 차량당 하나의 이동 정보 데이터만 처리하면서 순서를 보장하기 위해 도입되었습니다. 이는 분산 락 개념을 도입한 것과 유사합니다.

분산 락을 사용하지 않은 이유는 데이터가 특정 시간에 의존적이지 않도록 하기 위함입니다. 락의 대기 시간(wait time)과 임대 시간(lease time) 등에 의존하게 되면, 필수적으로 처리해야 할 데이터가 처리되지 않는 상황이 발생할 수 있습니다. 또한, 락이 해제될 때 두 개의 데이터가 락을 경합하면 순서대로 처리되지 않을 가능성도 있습니다.

따라서 저희는 한 사이클이 완료될 때마다 다음 데이터를 처리할 수 있도록 Check-in & Check-out을 도입했습니다.

또한, 말씀하신대로 partitionKey를 사용하여 Consumer가 동기적으로 처리하면 락 없이도 데이터 처리 순서를 보장할 수 있습니다. 그러나 차량 수가 증가할수록 하나의 Consumer가 여러 차량의 데이터를 처리하는 속도에 영향을 받을 수 있습니다. 이를 방지하고 데이터 처리량을 높이기 위해 비동기 서버로 파이프라인을 구성하였고, 비동기 서버에서의 순서를 보장하기 위해 Check-in & Check-out 개념을 도입했습니다.