KSETL로 Kafka 스트림 ETL 시스템을 빠르게 구성하기
-
DAY1 15:00-15:20 KST
-
KSETL 은 Kafka Stream ETL. 카프카로 ETL 한다는 뜻.
-
데이터 처리 지연을 줄이기 위해 스트림 처리함.
- ex) 배달주문, 금융거래 사기 판별 등 사용자 컨텐츠 추천시 실시간 처리할 시 성능이 더 좋아지기도 함.
-
배치 처리로는 모아서 처리하기 때문에 느리고, 초 단위로 줄이는 것도 한계가 있어 스트림으로 처리함
-
프로그램 개발, 디버깅, 빌드, 배포, 모니터링
-
KSETL은 이런 작업을 쉽게 할 수 있도록 하는 것을 목표로 함. (라인 자체 개발)
-
개발을 모르는 데이터엔지니어가 스트림 처리를 스스로 만들 수 있도록 하는 것.
-
데엔은 개발은 잘 모르고 SQL은 잘 아는 경우가 많으므로 트림 처리를 위한 SQL 엔진을 도입
-
ksqlDB, flink sql, spark sql 를 검토하여 ksqlDB 를 선택.
-
사용자 정의 함수도 지원하고 스트림 처리만을 위한 시스템이므로 구조가 단순함. 동작도 카프카만 있으면 가능.
-
2개 스트림 조인시 각 파티션별로 처리하고 내부 상태는 인터널 토픽에 저장
- (ksql 이 동적으로 생성 -> 나중에 운영시 문제를 일으켰었음)
-
k8s 를 이용해 ksqlDB 클러스터를 동적으로 생성할 수 있게 하였는데, 이를 ODA(On-Demand Application) 이라고 부름
-
자바, 스칼라 대신 데이터 처리 전용 언어인 SQL을 사용하고
-
빌드도 컴파일 대신 대화형 쉘을 사용
-
배포도 On-Demand 클러스터 사용
-
대시보드는 이미 만들어진 대시보드를 제공.
구축 사례
- AB test (신규 기능 출시 전 시행하는 테스트)
- 라인 서버의 리퀘스트 로그와 클라이언트의 이벤트 로그를 처리(최대 초당 5만건)
- 특정 리퀘스트에 대한 클라이언트 반응을 통계 처리
- 기존
동일한 키를 가지는 이벤트 로그와 리퀘스트 로그를 찾기 위해 레디스의 하나의 스트림을 저장하고 다른 스트림을 읽으며 찾음 -> 시간차를 감안해 딜레이 처리하여 조인 윈도우 구현. (데이터 엔지니어가 못하고 전문 개발자가 프로그램으로 구현함. 로직도 매우 복잡) - ksql 적용 후
- SQL 쿼리 1개로 구현. 이벤트 스트림과 리퀘스트 로그 스트림을 동알한 로우 쿼리 키로 조인하여 간단하게 처리됨.
- 시간,구간별 데이터 취합도 취합하려는 구간을 윈도우로 선언하여 1분단위 ~ 10분단위 취합하도록 함.
ksqlDB 적용 후 개선된 점
- 기존 시스템 대비 Redis 를 뺄 수 있으므로 Redis 별도 설정하고 운영 불필요
- 대화형 쉘을 통해 빠르게 빌드, 릴리즈 가능성
- 대시보드를 통해 릴리즈 이후 성능 모니터링, 튜닝이 빠르게 가능, 문제 발생시 로그를 통해 빠르게 파악 및 대응 가능
ksetl 한계점
- ksqlDB 와 라인의 전사 카프카에 의존성이 있음.
- ksqlDB 도 몇몇 기능이 제공되지 않음 (AB테스트 리포트를 위해 UDF 를 이용해 직접 구현한 기능도 많음.)
- flinkDB 도 개선이 많이 되어 검토할 예정이라 함.
- 라인 카프카팀은 안정적 운영을 위해 동적인 토픽 생성을 금지하기 때문에, ksqlDB의 동적 토픽 문제로 인해 사내 카프카를 사용하지 못하여서 개발 단계에선 별도 카프카 서버 구축 후 테스트 완료 후 카프카팀에 토픽 생성 요청하여 해결함.
future works
- 하이브 테이블을 import 하여 카프카 토픽으로 만드는 기능
- ksqlDB 클러스터에서 쿼리를 실행시키는 방법 개선 필요 (현재는 대화형 쉘인데, 사람이 실수할 가능성이 있으므로 이를 자동화하고자 함)
