12시간 배치에서 Flink 스트리밍으로 옮긴 운전습관 분석 (2021-12)

운전습관 서비스

TMAP 운전습관은 길안내를 받는 동안 주행이력을 기록해 과속, 급제동, 급가속을 분석합니다. 점수와 등수를 보여 주고, 점수가 높으면 자동차 보험 할인도 받을 수 있습니다. 원문은 교통사고와 이산화탄소를 줄이는 사회적 가치도 강조하며 두 건의 외부 기사를 링크했습니다.

12시간 배치의 한계

예전 구조는 앱이 주기적으로 주행정보를 올리면 Kafka에 쌓고, Hadoop(HDFS)에 저장한 뒤 12시간마다 Hive 쿼리로 분석해 서비스 DB에 넣는 배치였습니다. 운전습관은 주행이력을 분석하는 데이터 파트와, 결과를 서비스용으로 가공하는 서비스 파트로 나뉩니다.

문제는 주행이 끝나도 최대 12시간은 결과를 볼 수 없다는 점이었습니다. 12시간치 대용량을 Hive로 분석하는 시간도 오래 걸렸습니다.

Flink 기반 실시간 구조

이용자가 늘며 실시간 분석 요구가 커져 스트리밍 처리가 되는 Apache Flink를 도입했습니다. Flink는 앱이 올린 메시지를 Kafka에서 바로 소비해 분석합니다. 세션 윈도우로 주행별 데이터를 모으고, 그 세션을 분석하면 주행 하나가 분석됩니다.

전체 주행정보를 HDFS에 두던 방식과 달리, 지금 달리고 있다고 판단되는 주행정보만 메모리에 두고, 주행이 끝났다고 판단하면 분석을 끝내 결과를 Kafka로 내보냅니다.

Flink를 고른 이유와 세션 윈도우

원문이 든 대안과 탈락 이유는 다음과 같습니다.

• Spark: 마이크로 배치라서 최저 지연이라는 목적과 맞지 않습니다.
• Kafka Streams: 데이터 소스가 Kafka뿐이라 다양한 서비스를 쓰기 어렵습니다.
• Storm: 정확히 한 번 처리를 지원하지 않습니다.

Flink는 이벤트가 생기는 즉시 처리하고, Kinesis나 RabbitMQ 같은 여러 커넥터를 지원하며 정확히 한 번 처리를 보장합니다.

세션 윈도우는 수백만 주행을 뭉치지 않고 주행별로 데이터를 분리해 다른 주행이 결과에 영향을 주지 않게 합니다. 네트워크 지연이나 터널 통과로 데이터 순서가 뒤바뀔 수 있는데, 세션 단위로 관리하면 이벤트 발생 순서대로 정렬해 분석하기 쉽다고 합니다.

체크포인트와 복구

장애가 나도 데이터가 유실되지 않고, 버전 업그레이드나 클러스터 구성 변경 때도 서비스에 영향이 없어야 해서 체크포인트와 세이브포인트를 씁니다. 기본 방식은 유입을 멈추고 처리 중인 데이터를 마친 뒤 각 태스크 상태를 외부 저장소에 복사하고 재개하는 것입니다. Flink는 멈춤 문제를 피하려고 Chandy-Lamport 알고리즘 기반의 분산 스냅샷을 구현했습니다. 스트림에 체크포인트 배리어 레코드를 넣어 어느 상태가 어느 체크포인트에 속하는지 구분하고, 모든 파티션에서 배리어가 정렬될 때까지 기다린 뒤 저장합니다.

복구 때는 저장된 상태를 불러오고 데이터 소스의 offset을 그 시점으로 되돌려 재처리합니다. 소비하면 지워지는 큐로는 불가능해서 Kafka나 Kinesis처럼 여러 번 읽을 수 있는 브로커를 씁니다. 복구 중 일부 레코드가 여러 번 기록될 수 있으므로 저장 방식은 멱등해야 합니다.

AWS 이전 계획

티맵모빌리티는 2020년 12월에 SK텔레콤에서 분사했습니다. 운영 조직이 작아져 온프레미스에서 AWS로 옮기는 중이고, Kinesis Data Analytics의 Flink와 Kinesis Data Streams로 Kafka를 대체하는 프로토타입까지 가능성을 확인했다고 합니다. 남은 과제가 많다고만 밝혔습니다.