어플리케이션을 운영하다 보면, 트래픽 증가나 사용자 경험 개선, 비용 절감 등 다양한 요인으로 인한 성능 개선 요구가 꾸준히 제기됩니다. 저희 팀에서 운영하고 있는 Flink 어플리케이션도 비즈니스 요구사항을 만족시키기 위한 지속적인 성능 튜닝이 필요했습니다. 하이퍼커넥트의 대표 Product인 Azar의 핵심이 되는 1:1 매칭 서비스는 Flink 어플리케이션으로 구현되어 있는데, 특히 스와이프 직후 매칭이 이뤄져야 하는 Azar의 특성상, end-to-end latency는 사용자 만족도와 직결되므로 매우 중요합니다. 이에 따라 성능상 병목 구간을 정확히 찾아내고, 찾아낸 문제를 해결하는 과정이 지속적으로 필요했습니다. 이 글에서는 이러한 Flink 어플리케이션의 end-to-end latency를 낮추기 위해 병목을 진단하고 개선 포인트를 도출해나가는 과정을 소개하고자 합니다.Flink 어플리케이션의 end-to-end latency 개선 포인트를 찾아내는 과정은 크게 두 단계로 나눌 수 있습니다.• Application level: 전체 어플리케이션에 걸쳐 Flink operator 단위로 지표를 상세하게 수집하고 관찰하여 비정상적으로 느린 부분을 찾아냅니다.• Operator level: 찾아낸 Flink operator에 대한 프로파일링을 진행하고, 이후 코드 레벨의 inspection을 수행합니다.지금부터 각 단계에 대해 상세히 다뤄보겠습니다.End-to-end latency를 개선하기 위해서는 먼저 Flink의 각 operator 별로 처리에 소요되는 시간을 정확히 파악해야 할 필요가 있습니다. 이렇게 파악만 하더라도 기대와 다르게 느린 지점을 단번에 찾아낼 가능성이 있습니다.이를 위해서 Flink 어플리케이션의 각 operator에 2종류의 히스토그램 지표를 추가하는 작업이 필요합니다.• 처리 시간: , 와 같은 어플리케이션 코드가 input을 처리해서 output을 생성하기까지 걸리는 시간• 처리 외 시간: 처리 시간 밖의 모든 시간. Flink에서 데이터를 de/serialize하거나 네트워크 I/O를 하는 시간 등이 포함됩니다.지표를 처리 시간과 처리 외 시간의 두 종류로 분리하였는데, 이는 둘 중 어느 곳이 병목이냐에 따라 해결 방식이 완전히 달라지게 되기 때문입니다. 만약 처리 시간이 병목이라면 어플리케이션의 로직을 점검하거나, DB I/O 시간 등을 확인해야 할 수 있습니다. 반대로 처리 외 시간이 병목이라면 네트워크 I/O와 관련된 트러블슈팅을 진행하거나 Flink 내부 코드와 관련된 작업을 해야 할 것입니다.그림 1. 처리 시간과 처리 외 시간 지표가 각각 커버하는 구간의 예시코드 작업을 통해 지표를 추가하고, 운영 환경에 배포하여 각 operator의 처리 시간과 처리 외 시간을 다음과 같이 수집할 수 있습니다. (이 글 끝에 부록으로 지표 추가 코드의 예시를 실어 놓았습니다)그림 2. 위 예시에서 수집한 지표를 모아 파이 차트로 나타낸 것 처리 시간은 Operator 1, 처리 외 시간은 Operator

안녕하세요. Azar Matching Dev Team 의 Zeze 입니다. Flink 는 대다수의 백엔드 엔지니어들에게 친숙한 기술은 아니지만, 이벤트 스트리밍 처리를 위한 대표적인 기술 중 하나입니다. 대규모 실시간 데이터 스트리밍 처리를 위해 분산 환경에서 빠르고 유연하게 동작하는 오픈소스 데이터 처리 엔진이며, 팀 내에서는 Azar 의 핵심 로직인 매칭 서버를 구현하는 데에 사용되고 있고, 사내에서는 보통 Kafka 를 source 및 sink 로 사용하는 애플리케이션 코드를 직접 작성하는 방식으로 많이 사용하고 있습니다. 오늘 소개할 Flink SQL 은 애플리케이션 코드를 직접 작성하지 않고도 SQL 을 통해 이벤트 스트리밍 처리 앱을 구현할 수 있도록 해주는 기능입니다. 이번 글에서는 이벤트 스트리밍 처리를 위해 Flink SQL 을 채택한 이유와 클러스터 환경 구축 및 운영 경험을 공유하려고 합니다.Azar Matching Dev Team 에서 관리하던 여러 Flink 기반 앱들 중, CPU 를 무려 96개나 사용하던 매우 무거운 레거시 앱이 있었습니다. 이 앱은 여러 매치 이벤트를 조인하고, 로직에 따라 조건부로 새로운 이벤트 발행하거나 Redis에 플래그를 저장하는 등 다양한 기능을 한 곳에 몰아넣은 모놀리식 구조였습니다. 유지보수가 어려운 상태에서 전사 인프라 작업으로 인해 해당 앱의 실행 노드를 변경하자, 앱이 정상적으로 동작하지 않는 문제가 발생했고, 몇 차례 단순 튜닝을 시도해 보았지만 빠르게 해결하기 어려웠습니다. 그 결과, 높은 운영 피로도를 감수하며 이 앱을 계속 유지보수 할지 아니면 다른 방법으로 대체할지를 결정해야 했습니다.다행히 기존 앱의 로직 중 중요한 이벤트들을 조인하는 기능은 (아래 그림에서 에 해당하는 부분) 별도의 프로젝트를 진행해 이미 새로운 Flink 앱으로 구현해 놓은 상태였기 때문에 이를 레버리지하는게 유리한 상황이었습니다. 그렇다면 위 그림처럼 이벤트 조인 이후 수행하는 조건부 이벤트 발행 또는 로직 수행 부분을 어떤 방식으로 대체할지를 고민해야 했는데요, 다음과 같은 선택지 및 장단점이 있었습니다.• 하나의 Flink App 으로 구현• 장점 - 하나의 앱만 관리하면 되므로 운영이 간편합니다.• 단점 - 또 다시 거대한 앱이 될 가능성이 크며, 앱의 한 부분이 실패할 경우 다른 기능도 영향받기 쉽습니다.• 여러 Flink App 으로 구현• 장점 - 각 앱을 독립적으로 관리할 수 있어 유연합니다.• 단점 - 앱의 개수가 늘어나면, 클러스터/리소스/배포 관점에서 부담이 증가할 수 있습니다.• Flink SQL 을 사용• 장점 - 쿼리를 통해 로직을 정의하므로 빠른 개발이 가능하며, 하나의 클러스터만 관리하면 됩니다.• 단점 - SQL 만으로는 복잡한 로직을 표현하기 어렵고, 팀이 클러스터 관리에 익숙하지 않다면 어려울 수 있습니다.팀에서는 Flink 의 내부 구현에 대해 꽤나 이해도가 높아져 있는 상태였기 때문에, Flink SQL 을 사용하면 생산성 및 운영 효율성에서 이점이 있

안녕하세요, 데이터분석플랫폼 조직의 루이스입니다.시리즈의 첫 글인 아파치 플링크와 CDC의 만남. 플링크 CDC 맛보기에 이어 두 번째 글을 쓰게 되었습니다. 첫 번째 글에서는 아파치 플링크로 CDC(Change Data Capture)를 수행하여 MySQL 테이블을 다른 MySQL 테이블로 연동하는 내용을 공유드렸었는데요, 이번 글에서는 플링크를 사용하여 MySQL 테이블을 아파치 아이스버그(Apache Iceberg)로 CDC를 수행하고 운영하면서...

이번 글은 쿠버네티스 네이티브 워크플로를 이용한 대용량 스트리밍 파이프라인 검증 자동화 시리즈의 마지막 글입니다. 지난 1편과 2편은 아래 링크에서 확인하실 수 있습니다.• 쿠버네티스 네이티브 워크플로를 이용한 대용량 스트리밍 파이프라인 검증 자동화 - 1편• 쿠버네티스 네이티브 워크플로를 이용한 대용량 스트리밍 파이프라인 검증 자동화 - 2편지난 2편에서는 Tekton 기반으로 성능 테스트 시스템을 구축한 사례를 소개했는데요. 이번 글에서는 LitmusChaos를 이용해 카오스 테스트를 진행한 사례를 소개하겠습니다.카오스 테스트 대상 애플리케이션 소개 및 카오스 테스트가 필요한 이유카오스 테스트의 대상 애플리케이션은 Apache Flink 프레임워크 기반의 전처리기입니다. LINE 광고 데이터 파이프라인에서는 앞서 2편에서 말씀드렸던 Heron 프레임워크 기반의 전처리기를 대체할 다음 버전의 전처리기로 Flink 프레임워크 기반의 전처리기를 준비하고 있으며, 이를 도입하기 준비하는 과정에서 LitmusChaos 기반의 카오스 엔지니어링을 진행했습니다.Apache Flink(이하 Flink)는 데이터 스트리밍을 지원하는 분산 처리 엔진으로, 자체 상태 저장소를 갖추고 있기 때문에 스테이트풀(stateful)한 연산이 가능하다는 특징이 있습니다. 아래는 쿠버네티스 환경에서 실행되는 Flink 애플리케이션의 구조를 간략히 나타낸 그림입니다.Flink 프레임워크에서는 하나의 Flink 애플리케이션을 '잡(job)'이라고 표현합니다. 하나의 잡은 Flink의 기초 실행 단위인 '태스크(task)'로 구성되는데요. Flink는 이 태스크라는 실행 단위를 통해 데이터를 분산 처리합니다.위 구조에서 'Flink 시스템 네임스페이스(Flink-system namespace)'의 'Flink 쿠버네티스 오퍼레이터(Flink Kubernetes operator)'는 쿠버네티스 커스텀 리소스(이하 커스텀 리소스)와 오퍼레이터 패턴을 기반으로 Flink 애플리케이션의 배포와 업그레이드 등의 작업을 담당합니다.오퍼레이터가 배포한 Flink 애플리케이션은 크게 '잡 매니저(job manager)'와 '태스크 매니저(task manager)'로 나뉜 파드들을 갖고 있습니다. 잡 매니저는 잡의 태스크를 어떤 태스크 매니저에서 실행할지 결정하고 태스크 매니저의 상태를 관리하는 등 잡을 관리하는 역할을 담당하며, 태스크 매니저는 태스크를 직접 실행하는 역할을 담당합니다. 이 두 매니저를 묶어서 'Flink 클러스터'라고 칭합니다.Flink 쿠버네티스 오퍼레이터가 관리하는 Flink 애플리케이션에는 크게 두 가지 모드가 있습니다. 각 애플리케이션이 독립적으로 Flink 클러스터를 각각 하나씩 갖는 애플리케이션 모드가 있고, 하나의 Flink 클러스터를 여러 애플리케이션이 공유하며 각 애플리케이션이 해당 Flink 클러스터에 세션 잡(session job) 형태로 제출되는 방식으로 작동하는 세션 모드가 있습니다.애플리케이션 모드는 잡 매니저 및 태스크 매니저를 하나의 애플