Apache Flink편집자 확인

Apache Flink는 데이터 처리 패러다임에 따라 두 가지 핵심 API를 제공한다. 하나는 유한 데이터 집합을 대상으로 하는 배치 처리를 위한 DataSet API이며, 다른 하나는 무한 데이터 스트림을 대상으로 하는 스트림 처리를 위한 DataStream API이다. 이 두 API는 Flink가 통합된 엔진으로 배치와 스트림을 모두 처리할 수 있는 근간이 된다.

DataSet API는 HDFS나 로컬 파일 시스템 등에 저장된 유한한 크기의 데이터를 읽어 처리하는 데 사용된다. 이 API를 사용하는 프로그램은 맵, 리듀스, 조인과 같은 변환 연산을 정의하며, Flink는 이러한 연산을 최적화된 실행 계획으로 변환하여 분산 클러스터에서 실행한다. 초기 Flink는 이 배치 처리 API를 중심으로 발전했다.

반면 DataStream API는 카프카, Kinesis, TCP 소켓 등에서 실시간으로 유입되는 무한한 데이터 스트림을 처리하기 위해 설계되었다. 이 API는 데이터 스트림에 필터링, 매핑, 집계, 윈도우 연산 등을 적용할 수 있도록 한다. Flink의 핵심 강점인 이벤트 시간 처리, 정확히 한 번 의미론, 상태 관리 기능들은 주로 이 DataStream API를 통해 제공된다.

최근 Flink의 발전 방향은 두 API를 통합하는 데 있다. Table API와 SQL이라는 더 높은 수준의 추상화를 도입하여, 사용자는 동일한 쿼리로 배치 데이터와 스트리밍 데이터를 모두 처리할 수 있게 되었다. 내부적으로는 이러한 쿼리들이 최종적으로 DataStream API나 DataSet API 프로그램으로 변환되어 실행된다.

윈도우는 Apache Flink에서 무한 데이터 스트림을 유한한 크기의 "버킷"으로 나누는 핵심 메커니즘이다. 스트림 처리에서 집계, 통계, 조인과 같은 연산은 일반적으로 전체 무한 스트림에 대해 수행될 수 없기 때문에, 특정 기준에 따라 데이터를 그룹화하는 윈도우가 필요하다. Flink는 이러한 윈도우를 정의하고 할당하는 유연하고 풍부한 API를 제공하여 복잡한 스트림 처리 로직을 구현할 수 있게 한다.

Flink의 윈도우는 크게 시간 기반 윈도우와 개수 기반 윈도우로 구분된다. 시간 기반 윈도우는 가장 일반적으로 사용되며, 처리 시간 또는 이벤트 시간을 기준으로 데이터를 그룹화한다. 예를 들어, "5분 간의 이동 평균"을 계산하는 경우 5분 간격의 롤링 윈도우를 사용할 수 있다. 개수 기반 윈도우는 들어오는 데이터 요소의 개수를 기준으로 윈도우를 정의한다. 또한, 데이터 스트림의 특정 속성(예: 키 값)에 따라 각 키별로 독립적으로 윈도우가 적용되는 키별 윈도우 방식도 지원한다.

윈도우의 동작을 정의하는 주요 구성 요소로는 윈도우 할당자, 트리거, 에비터터가 있다. 윈도우 할당자는 각 데이터 요소가 어떤 윈도우에 속하는지 결정한다. 트리거는 윈도우의 내용을 언제 처리할지(예: 윈도우가 끝날 때, 또는 중간에 일정 시간마다) 결정하며, 초기 트리거 설정을 통해 윈도우가 닫히기 전에 중간 결과를 얻을 수 있다. 에비터터는 윈도우의 내용을 처리하기 전에 특정 요소를 필터링할 수 있는 선택적 기능을 제공한다.

Flink는 고정 윈도우, 슬라이딩 윈도우, 세션 윈도우 등 다양한 윈도우 유형을 내장하고 있어 다양한 비즈니스 로직을 모델링할 수 있다. 특히 세션 윈도우는 사용자 활동 데이터와 같이 비활성 기간에 따라 동적으로 윈도우 크기가 결정되는 경우에 유용하다. 이러한 강력한 윈도우 메커니즘은 Flink를 실시간 대시보드, 사기 탐지, 이상 감지와 같은 복잡한 이벤트 처리 애플리케이션에 적합하게 만드는 핵심 요소 중 하나이다.

상태 관리는 Apache Flink가 분산 시스템에서 스트리밍 데이터 처리를 수행할 때 연산의 중간 결과나 정보를 안정적으로 유지하고 접근할 수 있게 하는 핵심 메커니즘이다. 스트림 처리 작업은 종종 무한한 데이터 스트림을 다루며, 윈도우 집계나 패턴 감지와 같은 연산은 이전에 처리한 데이터에 대한 정보를 기억해야 한다. 이러한 정보를 상태라고 하며, Flink는 이를 효율적으로 관리하기 위한 다양한 기능을 제공한다.

Flink에서 상태는 크게 키드 스트림과 연관된 키드 상태와 연산자 전체에 걸친 연산자 상태로 구분된다. 키드 상태는 해시 테이블과 유사한 구조로, 각 데이터 레코드의 키별로 상태가 분리되어 저장되어 조인이나 그룹화 연산에 적합하다. 반면 연산자 상태는 연산자 인스턴스에 바인딩되어, 모든 입력 레코드가 공유하는 상태를 관리할 때 사용된다. 상태의 저장소 백엔드로는 메모리, 파일 시스템, RocksDB 등이 있으며, 특히 대용량 상태를 다룰 때는 디스크 기반의 RocksDB가 일반적으로 활용된다.

상태 관리는 체크포인트 메커니즘과 밀접하게 연동되어 장애 복구를 보장한다. Flink는 정기적으로 모든 연산자의 상태 스냅샷을 영구 저장소에 저장하는 체크포인트를 생성한다. 시스템에 장애가 발생하면 Flink는 가장 최근의 성공적인 체크포인트로 작업을 롤백하고 저장된 상태를 복원하여 처리의 정확성을 유지한다. 이 과정은 정확히 한 번 의미론을 구현하는 데 필수적이다. 또한 상태 백엔드를 통해 상태의 저장 방식과 접근 성능을 애플리케이션 요구사항에 맞게 구성할 수 있다.

Apache Flink는 장애 발생 시에도 데이터 처리의 정확성을 보장하기 위해 체크포인트와 세이브포인트라는 두 가지 중요한 메커니즘을 제공한다. 체크포인트는 시스템의 장애 복구를 위한 핵심 기능으로, 실행 중인 데이터 스트림 애플리케이션의 상태를 주기적으로 분산 스토리지에 저장한다. 이는 Chandy-Lamport 알고리즘에 기반한 분산 스냅샷 메커니즘을 사용하여 구현되며, 스트림 소스의 위치 정보와 모든 연산자의 상태를 일관되게 기록한다. 장애가 발생하면 Flink는 마지막으로 성공한 체크포인트로 작업을 롤백하고 저장된 상태에서 처리를 재개함으로써 정확히 한 번 의미론을 달성할 수 있게 한다.

세이브포인트는 체크포인트와 유사하게 애플리케이션 상태를 저장하지만, 그 목적과 특성이 다르다. 세이브포인트는 사용자가 수동으로 트리거하거나 작업 스케줄러를 통해 예약하여 생성하며, 체크포인트와 달리 애플리케이션 업그레이드나 클러스터 유지 보수, A/B 테스트 또는 버전 관리와 같은 운영 목적으로 사용된다. 세이브포인트는 생성 시점의 애플리케이션 상태를 완전히 캡처하여 저장하며, 이후 동일한 상태에서 처리를 정확히 재시작하는 데 활용된다. 체크포인트는 장애 복구 후 자동으로 삭제되는 반면, 세이브포인트는 사용자가 명시적으로 삭제할 때까지 유지된다.

이 두 메커니즘은 Apache Flink가 스트림 처리에서 높은 신뢰성과 운영 유연성을 제공하는 데 기여한다. 체크포인트를 통해 시스템은 예기치 않은 장애로부터 복구할 수 있고, 세이브포인트를 통해 운영자는 애플리케이션의 상태를 보존하면서 유연한 배포 및 테스트 사이클을 관리할 수 있다. 둘 다 HDFS, S3, NFS와 같은 지속적인 분산 파일 시스템에 저장되어 안전성을 보장한다.

이벤트 시간 처리는 Apache Flink가 스트림 처리의 핵심 난제 중 하나를 해결하기 위해 제공하는 중요한 기능이다. 이는 데이터가 생성된 실제 시간(이벤트 시간)을 기준으로 처리하는 방식을 의미한다. 스트리밍 데이터는 네트워크 지연이나 시스템 장애로 인해 처리 시스템에 도착하는 순서가 뒤섞일 수 있으며, Flink의 이벤트 시간 처리는 이러한 도착 순서의 무질서함과 무관하게 애플리케이션 로직이 올바른 시간 기반 계산을 수행할 수 있도록 보장한다.

이 기능을 구현하기 위해 Flink는 워터마크라는 메커니즘을 사용한다. 워터마크는 스트림에 삽입되는 특수한 타임스탬프로, "이 시점까지의 모든 데이터는 이미 도착했다"는 의미를 가진다. 예를 들어, 10시 05분의 워터마크는 10시 05분 이전에 생성된 모든 이벤트의 처리가 이미 시작될 수 있음을 시스템에 알린다. 이를 통해 Flink는 정확한 시간 윈도우의 종료 시점을 결정하고, 지연 도착 데이터를 적절히 처리할 수 있다.

이벤트 시간 처리는 특히 이벤트 시간과 데이터 처리 시간 사이에 변동이 큰 사용 사례에서 필수적이다. 로그 분석, 거래 모니터링, 사용자 행동 분석과 같은 애플리케이션에서는 데이터 생성 순서와 처리 순서가 일치하지 않을 수 있으며, Flink의 이벤트 시간 지원은 이러한 환경에서도 정확하고 재현 가능한 결과를 산출하는 데 기여한다. 이는 처리 시간이나 수신 시간에 의존하는 다른 시스템과 구별되는 Flink의 주요 강점 중 하나로 꼽힌다.

정확히 한 번 의미론은 분산 시스템에서 데이터 처리가 중복되거나 누락 없이 정확히 한 번만 수행됨을 보장하는 것을 의미한다. 스트림 처리 시스템에서는 네트워크 장애, 노드 장애, 재시도 등으로 인해 동일한 데이터가 여러 번 처리될 가능성이 높기 때문에, 이러한 의미론을 보장하는 것은 금융 거래, 주문 처리, 정산과 같이 정확성이 매우 중요한 비즈니스 로직을 구현할 때 필수적이다.

Apache Flink는 체크포인트 메커니즘과 분산 스냅샷 알고리즘을 기반으로 정확히 한 번 의미론을 구현한다. 작업 관리자는 주기적으로 모든 연산자의 상태를 스토리지에 저장하는 체크포인트를 생성한다. 체크포인트 생성 과정은 체이닝된 태스크 간의 상태 일관성을 유지하며, 장애 복구 시 시스템은 마지막으로 성공한 체크포인트로부터 상태를 복원하고 데이터 처리를 재개한다. 이를 통해 장애 발생 시에도 중복 계산 없이 정확히 한 번의 처리를 보장한다.

이러한 보장은 소스 커넥터와 싱크 커넥터의 지원 수준에 따라 달라진다. Flink 자체의 상태 관리와 연산 보장은 엔드투엔드 의미론을 완성하기 위해 외부 시스템과의 통합이 필요하다. 따라서 카프카와 같은 엔드투엔드 정확히 한 번 데이터 소스 및 데이터 싱크를 함께 사용할 때 가장 강력하게 발휘된다.

아파치 플링크의 고가용성 설계는 시스템 장애 발생 시에도 작업이 중단되지 않고 지속적으로 실행될 수 있도록 보장한다. 이는 주로 마스터-슬레이브 구조를 기반으로 하며, JobManager와 TaskManager라는 핵심 컴포넌트의 장애 복구 메커니즘을 통해 구현된다. JobManager는 작업의 중앙 조정자 역할을 하므로, 그 장애는 전체 클러스터에 치명적일 수 있다. 이를 방지하기 위해 플링크는 Apache ZooKeeper와 같은 분산 코디네이터를 활용한 리더 선출 방식을 채택하여, 활성 JobManager에 장애가 발생하면 대기 중이던 JobManager 인스턴스가 자동으로 새로운 리더로 승격되어 작업을 인수한다.

작업 실행 상태의 지속성은 체크포인트와 세이브포인트를 통해 유지된다. 체크포인트는 주기적으로 애플리케이션 상태의 일관된 스냅샷을 분산 스토리지 (예: HDFS 또는 S3)에 저장한다. 장애 복구 시 시스템은 마지막으로 성공한 체크포인트로 롤백하여 상태를 복원하고, 데이터 소스(예: Apache Kafka)로부터 해당 지점부터 데이터 처리를 재개한다. 이는 정확히 한 번 의미론을 실현하는 기반이 된다. 세이브포인트는 수동으로 트리거할 수 있는 특별한 유형의 체크포인트로, 애플리케이션 업그레이드나 클러스터 유지보수 시 상태를 보존하는 데 사용된다.

TaskManager의 장애는 JobManager가 감지하며, 영향을 받는 작업의 모든 태스크를 사용 가능한 다른 TaskManager 슬롯에 재배포하여 복구한다. 이 과정에서 해당 태스크들의 상태는 가장 최근의 체크포인트에서 복원된다. 이러한 설계는 하드웨어 장애, 네트워크 문제, 또는 개별 프로세스 실패와 같은 다양한 장애 시나리오에서도 서비스의 연속성을 제공한다. 결과적으로 플링크는 금융 서비스, 실시간 모니터링, 이벤트 기반 애플리케이션과 같이 높은 가용성이 요구되는 생산 환경에 적합한 플랫폼이 된다.

Apache Flink는 다양한 클러스터 관리자와 통합되어 분산 컴퓨팅 환경에서 애플리케이션을 실행할 수 있다. 가장 기본적인 방식은 Flink 자체에 포함된 독립 실행형 클러스터를 구성하는 것이다. 이 모드는 별도의 외부 의존성 없이 빠르게 클러스터를 구축하고 테스트하는 데 적합하다.

보다 프로덕션 환경에서는 Apache Hadoop YARN이나 Apache Mesos와 같은 리소스 관리자 위에서 Flink를 실행하는 것이 일반적이다. 특히 YARN은 Hadoop 생태계와의 긴밀한 통합이 필요한 경우 널리 사용되는 선택지이다. 또한 Kubernetes에 대한 네이티브 지원을 통해 현대적인 컨테이너 오케스트레이션 플랫폼에서도 Flink 애플리케이션을 쉽게 배포하고 관리할 수 있다.

각 클러스터 관리자는 리소스 할당, 장애 복구, 확장성 관리 등에서 서로 다른 특징을 가지며, 사용자는 인프라 환경과 운영 요구사항에 맞게 적절한 방식을 선택할 수 있다. 이러한 유연성은 Flink가 다양한 데이터센터 및 클라우드 컴퓨팅 환경에 적용될 수 있게 하는 핵심 요소 중 하나이다.

Apache Flink는 애플리케이션을 실행하기 위한 세 가지 주요 모드를 제공한다. 이 모드들은 애플리케이션의 라이프사이클과 클러스터 관리자와의 관계에 따라 구분된다.

첫 번째는 애플리케이션 모드이다. 이 모드에서는 사용자가 제출한 애플리케이션 JAR 파일이 클러스터의 JobManager에서 직접 실행된다. 애플리케이션의 main() 메서드가 JobManager 프로세스 내에서 호출되므로, 클라이언트 머신에 애플리케이션 의존성을 설치할 필요가 없다. 이는 클라이언트 머신이 가벼워지고, 여러 사용자가 공유 클러스터를 사용하는 환경에 적합한 방식이다.

두 번째는 퍼-잡 모드이다. 이는 전통적인 방식으로, 클라이언트가 애플리케이션 JAR과 의존성을 가져와 JobManager에 제출한다. 클라이언트는 작업이 제출된 후에도 계속 실행되어야 하며, 작업 실행 상태를 모니터링하고 결과를 검색하는 역할을 한다. 이 모드는 작업 제출과 관리를 클라이언트가 주도하는 시나리오에 유용하다.

세 번째는 세션 모드이다. 이 모드에서는 미리 장기 실행되는 Flink 세션 클러스터가 시작되어 대기하고 있으며, 여러 애플리케이션 작업을 이 클러스터에 제출하여 실행한다. 모든 애플리케이션이 동일한 클러스터 자원을 공유하므로 자원 관리 효율성이 높지만, 애플리케이션 간 격리 수준은 낮아질 수 있다. 이는 짧은 지연 시간으로 작업을 자주 제출해야 하는 경우에 적합하다.