BigData

Apache Flink 훑어보기

맥모닝프로 2025. 4. 3. 16:57

소개

  • 대규모 스트리밍 분산 처리 프레임 워크
  • 배치 처리도 스트리밍처럼 처리 가능
  • 상태 기반 처리

Flink  데이터 파이프 라인 예시

  • 이벤트 기반 애플리케이션
    • 하나 이상의 이벤트 스트림에서 이벤트를 수집
    • 계산, 상태 업데이트 또는 외부 작업을 실행
    • 상태 저장 처리를 통해 수집된 이벤트 기록에 따라 단일 메시지 변환 이상의 논리를 구현 가능
  • 데이터 분석 애플리케이션
    • 데이터에서 정보와 인사이트를 추출
    • 지속적인 업데이트, 쿼리 스트리밍 또는 수집된 이벤트를 실시간으로 처리
    • 결과를 지속적으로 내보내고 업데이트하여 분석
  • 데이터 파이프라인 애플리케이션
    • 한 데이터 스토리지에서 다른 데이터 스토리지로 이동할 데이터를 변환 및 강화
    • 프로세스가 지속적으로 작동하여 짧은 대기 시간으로 데이터를 다른 대상으로 이동 가능

Flink의 이점

구분 내용 비고
무제한(스트림) 및 제한된(배치) 데이터 세트 모두 처리
  • 제한되지 않은 데이터 세트와 제한된 데이터 세트(예: 스트림 및 배치 데이터)를 모두 처리 가능
  • 제한된 처리와 무제한 처리를 모두 지원하는 알고리즘과 데이터 구조 제공
  • 제한되지 않은 데이터를 처리하는 애플리케이션은 지속적으로 실행
  •  제한된 데이터를 처리하는 애플리케이션은 입력 데이터 세트의 끝에 도달하면 실행 종료
  
대규모로 애플리케이션 실행
  •  모든 규모에서 상태 저장 애플리케이션을 실행하도록 설계
  • 처리는 수천 개의 작업에 병렬화되고 여러 시스템에 동시에 분산
  
인 메모리 성능
  • 애플리케이션과 상태를 통해 흐르는 데이터는 여러 시스템에 걸쳐 분할
  •  메모리 내 로컬 데이터에 액세스하여 계산 완료 가능
  
정확히 한 번 상태 일관성
  • 오류가 발생, 애플리케이션이 중지, 다시 시작되는 경우에도 내부 상태의 일관성을 보장
  • 애플리케이션 복구 또는 재시작 , 데이터 소스로부터 중복 항목을 수신 여부에 관계없이 항상 정확히 한 번만 적용
    • 중복된 메시지는 두 번 처리하지 않고, 딱 한번만 정리
  
다양한 커넥터
  • Apache Kafka
  • Amazon Kinesis Data Streams
  • Amazon SQS
  • Active MQ
  • Rabbit MQ
  • NiFi
  • OpenSearch 및 ElasticSearch
  • DynamoDB
  • HBase 및 JDBC 클라이언트를 제공하는 모든 데이터베이스
  

Flink HA 동작 방식

  • Task별로 StateBackend + Checkpoint 구조로 저장
  • 중간 저장 데이터 없이 checkpoint만으로 Task 복구

HA 핵심 구성 요소

구성요소역할비고

구성 요소 역할 비고
JobManager (여러 개) 작업 스케줄링과 상태 관리
  • HA를 위해 리더-후보 구조
    • Leader
    • Standby
TaskManager 데이터 처리 실행 (실제 연산 담당)  
Zookeeper
  • 리더 선출
  • 메타데이터 관리 (HA 핵심)
  
State Backend 상태 저장 (RocksDB, Memory, FileSystem 등)  

장애별 처리 흐름

장애 구분 HA 동작 비고
JobManger 다운
  1. 리더 JobManager가 다운됨
    → ZooKeeper가 감지
  2. ZooKeeper가 Standby JobManager 중 1명을 새로운 리더로 자동 승격
  3. 새 리더 JobManager가 ZooKeeper로부터 다음 정보 가져옴
    • 현재 실행 중인 Job 목록
    • 마지막 성공한 Checkpoint 메타정보
  4. TaskManager들은 새 리더에게 자동으로 다시 등록됨
  5. 작업 재개
    • Checkpoint 상태로부터 Job 복원
    • TaskManager들에 작업 재할당
TaskManager 다운
  1. JobManager가 TaskManager의 다운 감지
    → Task heartbeat 누락, 또는 JVM 종료 등으로 인식됨
  2. JobManager가 해당 Task의 실행 실패로 판단하고
    → 현재 유효한 Checkpoint를 기준으로 복구를 시작
  3. 남아 있는 TaskManager 중 유휴 슬롯(slot)이 있는 노드에 작업을 재할당
    → 새 TaskManager가 지정된 Checkpoint 위치에서 상태(State) 로드
  4. Kafka 등의 소스 커넥터는 Checkpoint된 offset부터 다시 데이터를 읽음
    → 중복 없이 이어서 처리 (Exactly-once 보장 가능)
  5. 작업 재시작 → 상태 복구 완료 후 스트리밍 재개
  • checkpoint 스토리지를 모든 TaskManager가 공유할 수 있는 스토리지 사용(NAS)
  • 로컬 디스크 사용시 다른 노드에서 checkpoint 확인 불가

참고자료

 

Apache Flink® — Stateful Computations over Data Streams

 

flink.apache.org