진화하는 스트리밍 플랫폼: 견고함을 향한 여정과 인사이트 #우아콘2025 #우아한형제들

우아한테크·우아콘 2025 2025·7개월 전·

#kubernetes#data-platform#stream-processing#apache-flink#schema-registry#apache-kafka

AI 요약

실시간 요구에 빠르게 답하려 Spark Structured Streaming·Kafka·Airflow로 시작한 스트리밍 파이프라인이, 확장성 한계에 부딪혀 Managed Flink를 거쳐 Flink Kubernetes Operator 자체 운영으로 진화한 과정을 담는다. '작동하는 파이프라인'에서 '견고한 self-service 플랫폼'으로 넘어가는 단계별 판단이 핵심이다.

핵심 포인트

초기엔 이미 쓰던 Kafka·Spark로 빠르게 만들고 참조 table은 Airflow가 하루 한 번 재시작하는 값싼 방식을 택했지만, EMR 종료와 application lifecycle 결합·매일 재시작·scale-out 부족이 한계로 드러남
설계 시간이 충분한 MyData workload부터 낮은 latency의 Flink를 managed service로 도입했다가, 비용 급증·version/설정 제약·debugging 어려움 때문에 기존 Kubernetes cluster·spot instance를 공유하는 Flink Kubernetes Operator로 재이전 (19개 app 기준 비용 62%, 연 약 1억 1,300만 원 절감)
Schema Registry로 type·null·호환성을 발행 단계에서 강제하고 Avro·Protobuf로 payload 축소, business rule 위반 event는 DLQ로 격리, source-sink 건수 비교와 Iceberg 원본 backup·StarRocks 실시간 serving으로 조용한 누락을 조기 탐지
최소한의 Flink 지식만으로 YAML·SQL·UDF·notebook으로 파이프라인을 만드는 self-service 플랫폼으로 확장, 다음 목표는 Paimon lakehouse

왜 읽나스트리밍 인프라를 어디까지 관리형에 맡기고 언제 자체 운영으로 넘어갈지 고민하는 데이터 플랫폼 팀에게, 비용·통제·안정성을 저울질하며 진화시킨 의사결정 레퍼런스.

챕터별 상세

013:57 – 9:03

기존 도구로 빠르게 만든 첫 streaming pipeline

실시간 dashboard와 주문 집계 요구에 빠르게 답하기 위해 이미 운영하던 Kafka와 Spark Structured Streaming을 사용하고 결과를 RDB에 저장했다. 매일 갱신되는 참조 table은 복잡한 동적 갱신 대신 Airflow가 application을 하루 한 번 재시작하게 해 작은 비용으로 요구를 충족했으며, 처음에는 완벽한 platform보다 작동하는 pipeline을 우선했다.

Spark streaming은 EMR 종료와 application lifecycle이 결합되고 최신 참조를 위해 매일 재시작해야 하며 traffic에 따른 scale-out도 부족했다. 충분한 설계 시간이 주어진 MyData pipeline에서는 낮은 latency와 streaming 중심 구조를 가진 Flink를 선택하고, cluster 관리보다 business logic에 집중하도록 autoscaling·고가용성·monitoring을 제공하는 managed service에 배포했다.

Pipeline 수가 늘면서 managed Flink의 비용이 급증하고 지원 version·세부 설정·환경 접근이 제한돼 debugging과 tuning이 어려워졌다. 기존 Kubernetes cluster와 spot instance를 공유하고 GitOps 배포, 원하는 Flink version, logging·monitoring을 직접 제어하도록 Flink Kubernetes Operator로 이전했으며, 이중 실행 결과를 자체 검증해 migration한 결과 19개 app 기준 비용을 62%, 연간 약 1억 1,300만 원 절감했다.

Schema Registry가 type과 null 제약 및 호환성을 발행 단계에서 강제하고 Avro·Protobuf로 payload까지 줄이며, business rule을 위반한 event는 DLQ로 격리해 application 전체 종료를 막는다. Source와 sink 건수를 비교하는 검증, 상태·처리량 dashboard와 alert, Kafka Connect 기반 Iceberg 원본 backup·재처리, StarRocks 실시간 serving을 더해 조용한 누락과 장애를 빠르게 발견하고 복구한다.

내부 팀의 배포·log·monitoring·autoscaling 불편을 조사한 뒤 최소한의 Flink 지식만으로 YAML과 SQL을 작성해 pipeline을 만들고 공통 dashboard와 운영 지원을 받는 platform을 제공했다. 복잡한 record logic은 UDF interface로 확장하고 notebook에서 SQL과 결과를 즉시 검증하게 했으며, 현재 여러 조직의 기존·신규 pipeline을 운영하면서 Paimon lakehouse와 지연·유효성 검증 강화를 다음 목표로 삼고 있다.