Flink SQL 기반 스트리밍 앱 도입 및 운영 경험

Flink SQL 도입 배경 및 기술적 선택

레거시 앱의 문제점: CPU 96개를 사용하는 모놀리식 Flink 앱의 높은 운영 피로도와 유지보수 어려움으로 대체 필요성 대두.
기술적 대안 검토: 단일/다중 Flink 앱과 Flink SQL 중 생산성 및 운영 효율성을 고려하여 Flink SQL 채택 결정.
선택의 핵심 요소: Flink의 High Availability, 다양한 고급 스트리밍 기능 (윈도우, 조인, 이벤트 타임 처리, 워터마크), 그리고 UDF & Custom Connector를 통한 확장성.
대안 기술 비교: ksqlDB는 비효율적인 HA로 제외, Spark Structured Streaming은 마이크로 배치 지연 및 팀 경험 부족으로 제외.

운영 환경 구성: Kubernetes 기반 Session mode Flink SQL 클러스터 배포. JobManager는 leader-standby HA 구성, state 저장에 S3 활용.
Kubernetes 연동: high-availability.storageDir 설정, JobManager 컨테이너 실행 인자 조정을 통한 HA 리더 선출 로직 정상 동작 구현.
쿼리 배포 방식: GitOps 패턴 활용. GitHub Actions를 통해 Flink SQL Gateway API를 호출, SQL 파일을 특정하여 쿼리 제출 및 Job 관리.

클러스터 컴포넌트 Fail: JobManager는 HA로 자동 복구, TaskManager는 Kubernetes QoS 및 작업 재분배로 처리 지속.
쿼리 실패 처리: 비정상 JSON 데이터 인입 시 json.ignore-parse-errors 옵션, 함수 에러 시 DEFAULT {VALUE} ON ERROR 활용. 자원 부족 시 TaskManager 리소스 및 parallelism 조정.
클러스터 재시작 시 Job Fail: Job의 timeout 및 retry 설정을 조정하여 클러스터 안정화 후 Job 재시도 보장.
쿼리 수정 및 Savepoint: 간단한 조건식 수정은 Savepoint 복원 가능하나, window 조건 등 State 변경 시 호환성 문제 발생.
모니터링: **numRunningJobs**로 Job 실패 감지, taskmanager.cpu.load, records-lag-max 등의 지표로 클러스터 부하 및 데이터 지연 파악.