소프트웨어 요구 사항

  • 많은 플링크 개발자가 선호하는 환경인 유닉스 기반으로 설정 시 여러 도구 사용 가능해 편리
  • 플링크 DataStream API는 자바와스칼라에서 사용 가능
    • 자바 JDK(8또는 그 이상의 버전) 필수
  • 플링크 애플리케이션 개발에 필수는 아니지만 아래 소프트웨어 설치됐다고 가정
    • 아파치 메이븐 3.x.
    • 자바나 스칼라 개발용 IDE

 

 

IDE에서 플링크 애플리케이션 실행과 디버깅

  • 플링크가 분산 데이터 처리 시스템이긴 하지만 로컬 머신에서도 개발과 기본 테스트가능

 

 

IDE에서 예제 코드 불러오기

 

 

IDE에서 플링크 애플리케이션 실행

  • AverageSensorReadings
    • 여러 온도 센서에서 이벤트 발생하는 것을 흉내내는 이벤트 생성, 이벤트의 온도 화씨에서 섭씨로 변환해 매초 각 센서의 평균 온도 계산. 표준 출력 아웃풋
    • 프로그램 출력 - 여러 연산 태스크 진행상황 나타내는 SCHEDULING, DEPLOYING, RUNNING과 같은 문장으로 시작
  • 플링크 애플리케이션 실행 태스크를 여러 태스크매니저로 배포하는 잡매니저(마스터)에 데이터플로우 제출
    • 잡매니저와 태스크매니저는 여러 머신에서 별도의 JVM 프로세스로 실행
    • 보통 프로그램의 main() 메서드에서 데이터플로우 조립하고 StreamExecutionEnvironment.execute()가 실행될 때 원격의 잡매니저에 데이터플로우 제출
    • 플링크는 execute() 메서드 호출 시 잡매니저와 태스크매니저를 동일 JVM에서 별도 스레드로 시작할 수 있는 모드 제공
      • 전체 플링크 애플리케이션을 하나의 JVM 프로세스에서 멀티스레드로 실행 - 플링크 프로그램 IDE에서 실행시 유용

 

 

IDE에서 플링크 애플리케이션 디버깅

  • 단일 JVM 실행 모드 덕분에 플링크 애플리케이션 IDE에서 디버깅 가능
  • 디버깅 시 고려 사항
    • 병렬 값 지정하지 않으면 개발 머신의 CPU 코어 개수만큼 스레드 생성해 프로그램 실행 (멀티스레드로 실행되는 프로그램 디버깅)
    • 단일 JVM에서 프로그램이 실행되므로 클래스 로딩과 같은 문제 제대로 디버깅 되지 않을 수 있음
  • 단일 JVM에서 실행하지만 스레드 간에 통신할 때나 상태를 저장할 때 레코드 직렬화

 

 

플링크 메이븐 프로젝트 부트스트랩

  • 플링크는 자바나 스칼라 플링크 애플리케이션을 메이븐 프로젝트로 생성하는 메이븐 아키타입(archetype) wprhd
    • Flink Maven Quickstart Scala 프로젝트 생성 및 개발 시작 시 사용하는 명령어

mvn archetype:generate

mvn archetype:generate \\
-DarchetypeGroupId=org.apache.flink \\
-DarchetypeArtifactId=flink-quickstart-scala \\
-DarchetypeVersion=1.7.1 \\
-DgroupId=org.apache.flink.quickstart \\
-DartifactId=flink-scala-project \\
-Dversion=0.1 \\
-Dpackage=org.apache.flink.quickstart \\
-DinteractivateMode=false
  • 플링크 1.7 메이븐 프로젝트를 flink-scala-project에 생성
  • mvn 명령의 각 파라미터 변경하면 플링크 버전, 그룹과 아티팩트 식별자(artifact id), 버전과 패키지 변경 가능
  • src/ 폴더와 pom.xml 파일 포함
src \\
ㄴ main
     ㄴresources
        ㄴlog4j.properties
     ㄴscala
         ㄴorg
             ㄴapache
                 ㄴflink
                     ㄴquickstart
                        ㄴBatchJob.scala
                        ㄴStreamingJob.scala
  • 기본 골격이 되는 BatchJob.scala, StreamingJob.scala 필요 없을 시 삭제
  • 다음 명령으로 JAR 파일 빌드

상태 관리

  • 보통 태스크의 상태는 태스크가 유지하고 있는 데이터와 함수의 결과를 게산할 때 사용하는 모든 데이터 포함
    • 그림 3-10. 상태가 있는 스트림 처리 태스크
    • 상태 일관성과 관련된 모든 문제, 실패 처리와 저장소의 효과적인 접근 등은 플링크가 책임지므로 개발자는 애플리케이션 로직에만 집중 가능
    • 상태의 종류 : 연산자 상태(operator state), 키 상태(keyed state)
      • 스코프(scope)에 따라 접근 제한됨

 

 

연산자 상태

  • 스코프 : 연산자 태스크 하나
    • 한 태스크가 처리하는 모든 레코드가 동일 상태에 접근 가능
    • 그림 3-11. 연산자 상태를 가진 태스크
    • 플링크가 제공하는 세 종류의 기본 연산자 상태
      • 리스트 상태(List state)
        • 리스트의 요소들로 상태 표현
      • 유니온 리스트 상태(Union List state)
        • 리스트의 상태를 나타내는 것은 같으나 장애를 복구하거나 애플리케이션을 세이브포인트에서 시작할 때 리스트 상태와 차이 있음
      • 브로드캐스트 상태(Broadcast state)
        • 연산자의 모든 태스크 상태가 동일한, 특수한 경우에 사용하는 연산자 상태
          • 체크포인팅을 수행하거나 연산자를 재확장(rescaling)할 때 사용

 

 

키 상태(keyed state)

  • 레코드의 각 키 값별로 유지하고 접근할 수 있는 상태
  • 플링크는 각 키 값별로 하나의 상태 인스턴스 유지. 이 키 상태를 관리하는 연산자 태스크로 동일 키의 모든 레코드 전송
    • 태스크가 어떤 레코드를 처리할 때 현재 처리중인 레코드의 키와 일치하는 키 상태만 접근 가능 -> 동일 키를 가진 모든 레코드는 같은 상태에 접근
  • 그림 3-12. 키 상태를 사용하는 태스크
  • 키-값 맵(key-value map)처럼 키 값으로 연산자 병렬 태스크에 레코드를 분배한 것
  • 플링크는 이 분산 키-값 맵에 키 별로 저장할 수 있는 여러 상태 값 종류 제공
    • 값 상태(Value state)
      • 임의 타입의 값을 키 별로 저장. 복잡한 데이터 구조도 값 상태로 저장 가능
    • 리스트 상태(List state)
      • 각 키별로 값 리스트 저장. 리스트의 요소는 어떤 타입이라도 가능
    • 맵 상태(Map state)
      • 키별로 키-값 맵을 저장. 맵의 키와 값은 어떤 타입이든 가능

 

 

상태 백엔드

  • 연산자 태스크는 상태를 로컬에 유지해 고속의 상태 접근 보장
  • 상태의 정확한 저장, 접근, 유지는 상태 백엔드(state backend)라 부르는 플러그인 가능한 컴포넌트가 결정
  • 상태 백엔드는 로컬 상태 관리와 원격 저장소에 상태를 체크포인팅 하는 두 가지 책임 지고있음
  • 플링크
    • JVM 힙(heap)의 메모리 데이터 구조인 객체(object)를 저장하는 것처럼 상태를 관리하는 메모리 상태 백엔드 제공
      • 고속의 상태 접근 제공, 메모리 크기에 제약
    • 상태 객체를 직렬화하고 이 데이터를 RocksDB에 저장
      • 상태 접근은 느리지만 상태 크기는 천천히 증가
  • 태스크매니저 저장소는 프로세스가 언제라도 장애가 발생할 수 있으니 휘발성(volatile)이라 생각해야함
    • 상태 백엔드는 원격의 영구적인 저장소에 태스크의 상태를 체크포인팅함

 

 

상태가 있는 연산자의 수평 확장

  • 상태가 있는 연산자의 병렬 값 변경은 상태를 재분할해(repartitioning) 늘어난 병렬 태스크에 다시 할당해야 하므로 어려움
  • 플링크의 상태 수평 확장 지원의 네 가지 패턴
    • 키 상태를 사용하는 연산자
      • 수평 확장 시 병렬 태스크가 갖고 있는 키들을 더 적거나 많게 재분할
      • 키를 키 그룹(key group)으로 구조화. 하나의 키 그룹은 하나의 키 파티션. 플링크는 이 키 그룹 단위로 태스크에 여러 키 할당
      • 그림 3-13. 키 상태를 사용하는 연산자 수평 확장과 축소
    • 리스트 상태를 사용하는 연산자
      • 리스트 요소를 재분배해 확장
      • 연산자의 모든 병렬 태스크가 갖고 있는 리스트 요소를 수집해 새 태스크로 균등하게 재분배
      • 그림 3-14. 리스트 상태를 사용하는 연산자의 수평 확장과 축소
    • 브로드캐스트 상태를 사용하는 연산자
      • 상태를 새로운 태스크로 복사해 확장
      • 모든 태스크가 동일한 상태를 가졌다는 것을 보장하므로 이런 동작이 가능
      • 3-16. 브로드캐스트 상태를 사용하는 연산자의 수평 확장과 축소

 

체크포인트, 세이브포인트, 상태 복구

  • 정확히 한번(exactly-once) 상태 일관성을 보장하려고 플링크가 사용하는 체크포인트와 복구 방식

 

 

일관성 체크포인트(consistent checkpoint)

  • 모든 태스크가 정확히 동일한 시점에 각 태스크의 상태 복사
    1. 모든 입력 스트림 인입 금지
    2. 현재 처리 중인 데이터가 완료되기까지 대기
    3. 각 태스크의 상태를 복사해 원격의 영구저장소로 체크포인트 지정
    4. 모든 스트림의 인입 재시작
  • 그림 3-17. 스트리밍 애플리케이션의 일관성 체크포인트

 

 

일관성 체크포인트에서 복구

  • 플링크는 주기적으로 일관성 체크포인팅을 수행해 상태를 원격 저장소에 저장
  • 장애 발생 시 가장 최신 체크포인트를 사용해 일관성 있게 애플리케이션 상태 복구. 레코드 처리 재시작.
  • 그림 3-18. 체크포인트에서 애플리케이션 복구
  • 애플리케이션 세 단계 복구
    1. 전체 애플리케이션 재시작
    2. 상태가 있는 모든 태스크 상태를 가장 최신의 체크포인트로 재설정
    3. 모든 태스크 처리 시작
  • 모든 연산자가 체크포인팅 수행하고 모든 상태 복구한 후 모든 입력스트림의 위치가 체크포인팅 수행 당시 마지막으로 소비했던 위치로 재설정 된다면 애플리케이션 정확히 한번(exactly-once) 일관성 제공 가능
    • 애플리케이션의 모든 입력 스트림이 재설정 가능한 데이터 소스에서 데이터 소비하면 정확히 한 번 상태 일관성 운영 가능(ex. 아파치 카프카)
  • 상태 복구 후 애플리케이션은 체크포인팅 수행과 장애로 처리 중단된 시간 동안 쌓여있던 모든 데이터 재처리
    • 모든 연산자 상태가 이 데이터들을 처리하지 않은 시점으로 재설정되어서 정확히 한번 상태 일관성 보장

 

플링크의 체크포인트 알고리즘

  • 스트림 애플리케이션 전체에서 동시에 체크포인팅을 수행하는 단순 접근 방식은 짧은 지연 요구하는 애플리케이션에선 사실상 사용 불가능
    • 스탑더월드(stop-the-world) 일으킴 (gc 실행 위해 jvm이 애플리케이션 실행 멈춤)
  • 플링크는 챈디-램포트(Chandy0Lamport) 알고리즘을 기반으로 분산 스냅샷(distributed snapshot) 체크포인팅 구현
    • 애플리케이션 전체를 정지하지 않고 체크포인트와 데이터 처리 간의 결합 분리
    • 일부 태스크는 상태 저장하고 일부는 데이터 계속 처리
    • 배리어(barrier) 레코드 사용
      • 소스 연산자가 레코드 스트림에 체크포인트 배리어 주입
      • 체크포인트 배리어 이전에 처리한 레코드가 만든 상태 변경은 배리어의 현재 체크포인트에 포함. 이후는 다음 체크포인트에 포함
  • 그림 3-19. 상태가 있는 소스 두 개, 상태가 있는 태스크 두 개, 상태가 없는 싱크 두 개를 가진 스트리밍 애플리케이션
  • 그림 3-20. 잡매니저는 모든 소스로 메시지를 보내 체크포인트 초기화
  • 그림 3-21. 소스는 자신의 상태를 체크포인팅하고 체크포인트 배리어 내보냄
    • 체크포인트 메시지 수신 시 레코드 내보내지 않음
    • 소스 태스크는 로컬 상태를 상태 백엔드에 체크포인팅하고 체크포인트를 배리어 밖으로 향하는 모든 스트림 파티션으로 브로드캐스트
    • 상태 체크포인팅 완료시 태스크에 알리고, 태스크는 잡매니저에게 알림
    • 모든 배리어 전송 후 소스는 자신의 연산 계속 수행
    • 입력스트림은 체크포인팅이 수행됐던 시점의 위치에서 다시 시작
  • 그림 3-22. 태스크는 각 입력 파티션에서 배리어를 수신하고자 기다림. 배리어가 이미 도착한 입력스트림의 레코드는 버퍼링됨. 배리어가 도착하지 않은 입력 스트림의 레코드는 계속 처리됨
    • 배리어 정렬(barrier alignment) : 모든 배리어가 도착하기를 기다리는 것
  • 그림 3-23. 모든 배리어를 받자마자 자신의 상태를 체크포인티하고 체크포인트 배리어를 내보내는 태스크
  • 그림 3-24. 체크포인트 배리어를 내보낸 후 원래의 처리를 계속 수행하는 태스크
  • 그림 3-25. 싱크가 체크포인트 배리어의 수신 여부를 잡매니저에 알리고 모든 태스크가 자신의 상태 체크포인팅이 성곶적으로 끝났음을 잡매니저에 알리면 체크포인팅 완료

 

 

체크포인트가 성능에 미치는 영향

  • 플링크 설계상 체크포인팅 수행은 상태 백엔드의 책임. 상태 백엔드 구현에 따라 태스크의 상태 복제하는 방식 다름
    • 파일 시스템(FileSystem) 상태 백엔드와 RocksDB 상태 백엔드는 비동기 체크포인팅 지원
      • 체크포인팅 시작되면 상태 백엔드는 상태를 로컬에 복사. 복사 완료시 태스크 하던 일 계속 진행
    • 백그라운드 스레드는 로컬 스냅샷을 원격 저장소에 비동기로 복사. 체크포인팅 완료되면 태스크에 알림
      • 비동기 체크포인팅은 태스크의 데이터 처리 재시작까지 걸리는 시간 줄여줌
      • RocksDB 상태 백엔드는 증분 체크포인트(Incremental checkpoint) 기능도 있어서 전송할 데이터양 많이 줄일 수 있음
  • 배리어 정렬(Barrier Alignment) 단계 변형
    • 매우 짧은 지연과 최소 한 번(at-least-once) 상태 보장으로 충분한 애플리케이션은 배리어 정렬 시 배리어 도착 후 들어오는 레코드를 버퍼에 쌓는 대신 계속 처리하도록 플링크에 설정

 

 

세이브포인트(savepoint)

  • 체크포인트에 몇 가지 메타데이터를 추가한 것
  • 사용자가 명시적으로 세이브포인트 생성해야 함. 자동 삭제x

 

 

세이브포인트 사용

  • 애플리케이션을 세이브포인트에서 시작 가능(애플리케이션과 호환성 가진 세이브포인트- 애플리케이션이 세이브포인트 상태 읽기 가능)
    • 세이브포인트와 호환되는 다른 애플리케이션 시작 가능
    • 애플리케이션 로직 버그 수정, 상태 복구 후 입력 스트림의 이벤트 재처리 가능
  • 동일 애플리케이션을 다른 병렬 값으로 시작하거나 규모 확장, 축소 가능
  • 다른 클러스터에서 동일 애플리케이션 실행 가능
  • 세이브포인트 이용해 애플리케이션 정지시키고 나중에 재시작 가능
  • 애플리케이션의 상태를 이력으로 남기거나 아카이빙 가능

 

 

세이브포인트에서 애플리케이션 시작

  • 실행중인 애플리케이션의 세이브포인팅 수행 후 애플리케이션 시작 시 상태 복구에 세이브포인트 사용
  • 그림 3-26. 애플리케이션에서 세이브포인팅 수행하고 이 세이브포인트에서 애플리케이션 복구
    • 세이브포인트 실행되면 모든 태스크의 상태를 영구 저장소로 복사
    • 세이브포인트의 상태 데이터는 연산자 식별자(ID)와 상태이름 가지고 있음
      • 세이브포인트와 관련된 연산자가 있는 태스크로 세이브포인트 데이터 재분배
    • 수정한 애플리케이션을 세이브포인트에서 시작한다면 애플리케이션이 세이브포인트와 일치하는 식별자와 상태 이름을 가진 연산자를 포함할 때만 세이브포인트의 상태 복구 가능
    • 플링크는 연산자에 고유 식별자 설정되어 있지 않으면 자동으로 할당
      • 연산자 식별자는 앞쪽의 연산자 식별해 생성됨 - 앞쪽의 연산자 식별자 변경시 현재 연산자 식별자도 변경됨
      • 상태를 유실해도 관계없는 애플리케이션일 때만 기본 연산자 식별 사용하도록 제한해야 함

시스템 아키텍처

  • 플링크는 상태가 있는 병렬 스트림을 처리할 수 있는 분산 시스템
    • 분산시스템은 일반적으로 클러스터의 컴퓨팅 자원 관리, 프로세스 조율, 신뢰성과 고가용성을 갖춘 데이터 저장소 및 장애 복구와 같은 여러 어려운 문제 다뤄야 함
    • 플링크는 핵심 기능인 분산 데이터 스트림 처리에만 집중하고 나머지 기능은 기존 클러스터 인프라와 서비스를 이용
      • 아파치 메소스, YARN, 쿠버네티스와 같은 클러스터 자원관리자와 통합. 독립형(standalone)클러스터로도 설정해 실행 가능
      • 신뢰성 있는 분산 저장소 제공하지 않지만 HDFS나 객체 저장소인 S3같은 파일 시스템 이용
      • 고가용성에서 필요한 리더 선출(leader election) 기능은 아파치 주키퍼 사용

 

플링크 컴포넌트

  • 네 개의 컴포넌트로 구성 : 잡매니저(JobManager), 리소스매니저(ResourceManager), 태스크매니저(TaskManager), 디스패처(Dispatcher)
  • 플링크는 자바와 스칼라로 구현됐기 때문에 모든 컴포넌트를 자바 가상머신(JVM)에서 실행 가능
  • 잡매니저
    • 애플리케이션의 실행을 제어하는 마스터 프로세스
    • 애플리케이션은 잡그래프(JobGraph)라 부르는 논리 데이터플로우 그래프와 애플리케이션에 필요한 모든 클래스, 라이브러리, 기타 자원을 포함하는 JAR로 구성
    • 잡매니저는 잡 그래프를 실행그래프(ExecutionGraph)라 부르는 물리 데이터플로우 그래프로 변환
    • 리소스매니저에서 태스크 실행에 필요한 자원(태스크매니저 슬롯(slot))을 요청
    • 애플리케이션을 실행할 수 있는 충분한 태스크 슬롯을 할당받으면 잡매니저는 작업을 처리할 태스크로 실행그래프 배포
    • 애플리케이션 실행 중 체크포인트를 조율하고 중앙에서 제어해야 하는 모든 동작을 책임짐
  • 리소스 매니저
    • YARN, 메소스, 쿠버네티스, 독립형 클러스터와 같은 각 환경에서 자원을 관리할 수 있는 리소스매니저를 지원
    • 플링크의 실행 단위인 태스크매니저 슬롯을 관리
    • 잡매니저가 태스크매니저 슬롯을 요청하면 리소스매니저는 유휴(idle) 슬롯을 잡매니저에게 제공하도록 태스크매니저에 지시
    • 잡매니저의 요청을 수용할 만큼 충분한 슬롯을 갖고 있지 않다면 자원 제공자(YARN, 메소스, 쿠버네티스 등)에게 태스크매니저 프로세스를 실행할 컨테이너를 제공(프로비전)하도록 요청
    • 유휴 태스크매니저를 종료해 계산 자원을 반환
  • 태스크매니저
    • 플링크의 워커(worker) 프로세스
    • 일반적으로 한 플링크 클러스터는 여러 태스크매니저 가지고 있고 각 태스크매니저는 여러 슬롯을 제공
    • 슬롯의 개수는 태스크매니저가 실행할 수 있는 최대 태스크 개수를 제한
    • 태스크매니저를 시작할 때 태스크매니저는 자신의 모든 슬롯을 리소스매니저에 등록
    • 리소스매니저에서 슬롯 제공 지시가 내려오면 태스크 매니저는 하나 이상의 슬롯을 잡매니저에 제공. 잡매니저는 실행 태스크를 이 슬롯에 할당
    • 태스크가 다른 태스크매니저에 있는 태스크와 통신이 필요하면 태스크매니저를 통해 데이터를 교환
  • 디스패처
    • 여러 잡을 실행할 때 사용하며, 애플리케이션을 제출할 수 있는 REST 인터페이스 제공
    • 사용자가 디스패처에 애플리케이션을 제출하면 디스패처는 잡매니저를 시작하고 애플리케이션을 잡매니저에게 넘김
    • REST 인터페이스 덕분에 방화벽 뒤에 있는 클러스터도 HTTP를 통해 디스패처 서비스 제공 가능
    • 잡 실행의 정보를 제공하는 대시보드도 실행
    • 애플리케이션 제출 방식에 따라 디스패처 불필요할 수도 있음
  • 그림 3-1. 애플리케이션 제출과 컴포넌트 상호작용

 

애플리케이션 배치

  • 프레임워크 방식(Framework style)
    • 플링크 애플리케이션을 하나의 JAR 파일로 패키징한 후 클라이언트를 이용해 현재 실행 중인 서비스(플링크 디스패처, 플링크 잡매니저, YARN의 리소스매니저) 중 하나로 제출
    • 어떤 서비스든 클라이언트가 제출한 플링크 애플리케이션을 받아 실행하는 것 보장
      • 잡매니저로 애플리케이션을 제출하면 잡매니저는 즉시 애플리케이션 실행
      • 디스패처, YARN 리소스매니저로 제출하면 먼저 잡매니저를 기동하고 제출한 애플리케이션을 잡매니저로 넘김 -> 잡매니저 해당 애플리케이션 즉시 실행
  • 라이브러리 방식(Library style)
    • 플링크 애플리케이션을 도커(Docker) 이미지처럼 애플리케이션에 특화된 컨테이너 이미지(container image)로 만듦
      • 잡매니저와 리소스매니저를 실행할 코드를 포함
      • 리소스매니저와 잡매니저를 자동으로 구동하고 번들링돼 있는 잡을 제출
      • 태스크매니저 컨테이너 배포는 잡과 무관한 이미지를 사용
      • 이 이미지에서 시작한 컨테이너는 태스크매니저를 시작하며, 태스크매니저는 리소스매니저에 연결해 슬롯 등록
      • 쿠버네티스와 같은 외부 자원 관리자가 컨테이너 이미지를 시작시키면 장애가 발생할 때 컨테이너 재시작 보장
  • 프레임워크 방식은 실행 중인 서비스에 애플리케이션을 제출하는 전통적 접근 방식을 따름
  • 라이브러리 방식에서는 플링크를 이용하지 않음
    • 플링크 서비스를 애플리케이션과 함께 컨테이너 이미지 안에 라이브러리로 패키징
    • 마이크로서비스 아키텍처는 일반적으로 이런 배치 방식 사용

 

태스크 실행

  • 태스크매니저는 여러 태스크를 동시에 실행 가능
  • 같은 연산자(데이터 병렬화), 다른 연산자(태스크 병렬화), 또는 다른 애플리케이션(잡 병렬화) 태스크가 태스크매니저의 태스크가 될 수 있음
  • 태스크매니저는 데이터 처리 슬롯 개수 설정을 제공해 동시 실행 가능한 태스크의 개수 제어
  • 슬롯은 연산자의 병렬 태스크 같이 스트리밍 애플리케이션의 일부분 실행
  • 그림 3-2. 연산자, 태스크 처리 슬롯
    • 연산자 A, C - 소스. 연산자 E - 싱크. 연산자 C, E - 병렬값이 2, 나머지 4.
    • 최대 병렬 값이 4이므로, 애플리케이션 실행해 최소 4개 처리 슬롯 필요 - 각 두 개의 처리 슬롯을 가진 태스크 매니저 두 개가 있다면 요구 사항 충족 가능
    • 잡매니저는 잡그래프를 실행그래프로 변환하고 네 개의 슬롯에 태스크 할당. 플링크는 병렬 값이 4인 연산자의 태스크를 각 슬롯에 할당
    • 연산자를 태스크로 분할해 슬롯에 할당하면 여러 태스크를 같은 태스크매니저에 배포할 수 있는 이점 (C - 1.1, 2.1 E - 1.2, 2.2에 할당)
      • 같은 프로세스 안에 있는 태스크들이 네트워크를 사용하지 않고도 데이터 교환을 효과적으로 할 수 있음
      • 너무 많은 태스크를 같은 태스크매니저에 할당하면 태스크매니저에 부하가 발생해 성능이 나빠지는 역효과
  • 태스크매니저는 JVM 프로세스 안에서 멀티스레드로 태스크 실행
  • 스레드는 프로세스보다 더 가볍고 태스크 간 통신 비용이 싸지만 태스크 각각을 완전히 고립시킬 수 없음
  • 태스크 중 하나만 오동작해도 전체 태스크매니저 프로세스가 죽고, 따라서 해당 태스크매니저에서 실행 중인 모든 태스크도 죽음
    • 태스크매니저당 하나의 슬롯만 설정하면 애플리케이션을 태스크매니저 장애에서 고립시킬 수 있음
  • 태스크매니저 안에서는 스레드를 이용한 병렬 방법을 사용하고, 한 호스트에 여러 태스크매니저 프로세스 배치 가능
    • 플링크에 성능과 자원 고립의 상충 문제를 같이 해결할 수 있는 유연성 제공

 

고가용성 설정

  • 애플리케이션 중 일부에 장애가 발생하더라도 애플리케이션 실행은 중단되지 않게하는 것이 중요
  • 태스크매니저 실패
    • 태스크매니저 중 하나가 실패하면 가용 슬롯이 떨어짐
    • 이 상황에서 잡매니저는 리소스매니저에게 더 많은 슬롯을 제공하도록 요청
    • 이 요청이 불가능할 때(ex. 애플리케이션이 독립형 클러스터에서 실행 중일 때) 잡매니저는 충분한 슬롯을 확보할 수 있을 때까지 애플리케이션 재실행 불가
    • 애플리케이션이 재시작 전략은 잡매니저가 얼마나 자주 애를리케이션을 재시작하고 재시작 시도 동안 얼마나 오래 기다릴지 결정
  • 잡매니저 실패
    • 잡매니저는 완료한 체크포인트 정보와 스트리밍 애플리케이션 실행 제어 관련 메타데이터 유지
    • 잡매니저가 사라지면 스트리밍 애플리케이션은 레코드 더 처리 불가
      • 플링크 잡매니저는 애플리케이션의 단일 실패 지점(single point of failure)
      • 잡매니저가 죽으면 다른 잡매니저로 책임과 메타데이터를 넘기는 고가용성 기능을 제공해 이 문제 해결
    • 플링크의 고가용성 모드는 조율(coordination)과 합의(consensus) 기능을 분산 서비스로 제공하는 아파치 주키퍼를 기반으로 함
      • 신뢰성 있는 데이터 저장소인 주키퍼를 사용해 리더 선출과 고가용성 기능 구현
      • 고가용성 모드로 운영할 때 잡매니저는 잡그래프와 애플리케이션 JAR 파일처럼 필수 메타데이터를 원격의 영구 저장 시스템에 저장
        • 잡매니저는 메타데이터 저장 위치 정보를 주키퍼에 저장
        • 애플리케이션 실행 중 잡매니저는 각 태스크의 체크포인트 위치 정보 수집
        • 모든 태스크가 자신의 상태를 원격 저장소에 저장하는 체크포인트 완료 시점이 되면 잡매니저는 태스크의 상태 정보를 원격 저장소에 저장하고 그 위치를 주키퍼에 저장
      • 플링크는 잡 매니저가 실패할 때 복구에 필요한 모든 데이터를 원격 저장소에 저장하고, 주키퍼에는 저장 위치 정보를 보관
      • 그림 3-3. 플링크의 고가용성 설정
        • 잡매니저가 실패하면 애플리케이션에 속한 모든 태스크는 자동으로 취소되고, 실패한 잡매니저에서 모든 작업을 인계받은 새 잡매니저는 다음 절차 수행
          1. 원격 저장소의 잡그래프, JAR 파일, 마지막 체크포인트 위치를 주키퍼에 요청
          2. 애플리케이션을 계속 실행할 때 필요한 처리 슬롯을 리소스매니저로 요청
          3. 애플리케이션을 재시작하고 모든 태스크의 상태를 마지막 완료한 체크포인트로 재설정
        • 쿠버네티스와 같은 컨테이너 환경에서 라이브러리 방식으로 애플리케이션을 실행할 때 보통 컨테이너 오케스트레이션 서비스(orchestration service)가 잡매니저나 태스크매니저 컨테이너를 자동으로 재시작
        • YARN이나 메소스에서 실행할 때는 남아있는 플링크 프로세스가 잡매니저나 태스크매니저 프로세스를 재시작하는 트리거 역할을 함
        • 독립형 클러스터 환경에서는 실패한 프로세스를 재시작하는 도구를 제공하지 않음
          • 실패한 프로세스의 작업을 넘겨받을 수 있는 대기(standby) 잡매니저와 태스크매니저를 실행하는 것이 나을 수 있음

 

플링크 내부의 데이터 전송

  • 태스크매니저는 전송 태스크에서 수신 태스크까지 데이터를 전송하는 역할
  • 태스크매니저의 네트워크 컴포넌트는 데이터를 전송하기 전에 버퍼에 레코드를 배치(batch)로 모아서 보냄( 네트워크 버퍼 풀(network buffer pool)
    • 네트워크 자원을 효율적으로 사용하고 높은 처리율을 낼 수 있는 기본적인 기술이며 네트워크나 디스크 IO에서 사용하는 버퍼링 기술과 유사
  • 태스크매니저는 일대일 관계의 전용 TCP 연결을 유지해 다른 태스크매니저와 데이터를 교환
    • 셔플 연결 패턴(Shuffle connection pattern)에서 각 전송 태스크는 각 수신 태스크로 데이터를 전송할 수 있어야 함
    • 태스크매니저는 내부적으로 각 전송 태스크가 각 수신 태스크로 데이터를 보낼 때 사용할 수 있는 전용 네트워크 버퍼 갖고 있어야 함
    • 그림 3-4. 태스크매니저 간의 데이터 전송
      • 네 개의 전송 태스크는 각 수신 태스크로 데이터를 전송할 때 필요한 버퍼를 적어도 하나씩 갖고 있으며, 수신 태스크도 데이터를 받는 버퍼를 적어도 하나씩 가지고 있어야 함
      • 동일 태스크매니저로 전송할 태스크 버퍼들은 동일 네트워크 연결을 통해 다중 전송(multiplex)됨
      • 데이터를 셔플링하거나 브로드캐스트하는 연결일 때 각 전송 태스크는 각 수신 태스크에 대한 버퍼 하나씩 가지고 있어야 함 - 연산에 참여한 태스크 수의 제곱
      • 플링크의 기본 네트워크 버퍼 설정은 중소규모 클러스터에서 사용하기 충분
      • 전송 태스크와 수신 태스크가 동일 태스크매니저 프로세스에서 실행될 때 전송 태스크는 외부로 나가는 레코드를 바이트 버퍼로 직렬화한 후 버퍼가 꽉 차면 큐(queue)에 넣음
        • 수신 태스크는 큐에서 버퍼를 꺼낸 후 역직렬화해 레코드 만듦
        • 따라서 동일 태스크매니저에서 실행 중인 태스크는 네트워크 통신을 유발하지 않음

 

크레딧 기반 흐름 제어

  • 버퍼링 사용은 네트워크 연결의 대역폭을 최대한 이용하는데 있어서 꼭 필요
  • 스트리밍 처리 관점에서 버퍼링의 한 가지 단점은 레코드가 생성되는 즉시 전송되지 않고 버퍼에 모이면서 발생하는 지연 시간의 증가
  • 플링크의 크레딧 기반 흐름 제어
    • 수신 태스크가 전송 태스크에 크레딧 부여(크레딧 : 수신 태스크가 데이터를 수신하려고 예약한 네트워크 버퍼 개수)
    • 수신 태스크가 전송 태스크에 크레딧 알려주면 알림을 받은 전송 태스크는 부여받은 크레딧만큼의 버퍼와 백로그 크기(backog size - 가득 차서 전송할 준비가 된 네트워크 버퍼 수)를 수신 태스크에 전송
    • 수신 태스크는 예약한 버퍼로 도착한 데이터를 처리하고, 전송 태스크의 백로그 크기를 이용해 연결돼 있는 모든 전송 태스크의 다음 크레딧을 우선순위 방식으로 정함
  • 수신 태스크가 데이터를 받을 수 있는 충분한 자원을 준비하자마자 데이터를 전송하므로 지연 시간 감소 가능
  • L 데이터 전송이 특정 태스크에 편향(skewed) 있을 때 전송 태스크의 백로그 크기에 따라 크레딧을 부여하므로, 네트워크 자원을 균등하게 분배하는 효과적인 방식
  • 플링크가 높은 처리율과 짧은 지연을 낼 수 있도록 도와주는 중요한 특징

 

 

태스크 체이닝

  • 플링크는 특정 조건에서 로컬 통신의 부하를 줄여주는 태스크 체이닝(task chaining) 최적화 기법 사용
  • 태스크 체이닝 요구 조건
    1. 두 개 이상의 연산자가 동일한 병렬값으로 설정돼 있어야 함
    2. 연산자들이 로컬 포워드 채널(local forward channel - 동일 프로세스에서 앞으로만 흐르는 통신 채널)로 연결돼야 함
  • 그림 3-5. 태스크 체이닝 요구 조건에 따라 구성한 연산자 파이프라인
  • 그림 3-6. 모든 함수를 하나로 합쳐 단일 스레드에서 실행되는 태스크에 넣고 데이터는 메서드 호출로 전달하는 태스크 체이닝
    • 함수 간의 레코드 전달에 어떤 직렬화나 통신 비용이 들지 않음
    • 로컬 태스크 간의 통신 비용을 극적으로 줄여줌
    • 태스크 체이닝 없이 파이프라인을 실행하는 것이 옳을 때
      • 많은 태스크로 구성된 긴 파이프라인을 분할하거나 태스크 체인을 여러 개로 쪼개 부하가 큰 함수를 서로 다른 슬롯에 할당
      • 그림 3-7. 태스크 체이닝 없이 한 스레드에 한 태스크를 실행하여 버퍼와 직렬화를 통해 데이터 전송
  • 플링크의 태스크 체이닝 기능은 기본적으로 활성화됨

 

이벤트 시간 처리

  • 이벤트 시간 애플리케이션은 처리 시간 애플리케이션보다 추가적인 설정 필요
  • 순수하게 처리시간 환경에서 동작하는 시스템 내부보다 이벤트 시간을 지원하는 스트림 처리기의 내부가 좀 더 복잡
  • 플링크는 일반적인 이벤트 처리 연산에서 사용가능한 직관적이며 사용이 쉬운 여러 기본 연산자를 제공할 뿐 아니라 사용자 정의 연산자로 좀 더 복잡한 이벤트 시간 애플리케이션을 개발할 수 있도록 표현력이 풍부한 API 제공

 

타임스탬프

  • 플링크 이벤트 시간 애플리케이션이 처리하는 모든 레코드는 타임스탬프 동반 필요
  • 타임스탬프는 레코드를 특정 시점(레코드가 표현하고 있는 이벤트의 발생 시점)과 결부
    • 레코드의 타임스탬프가 스트림 속도와 얼추 비슷하게 앞으로 나간다면 타임스탬프의 의미를 애플리케이션이 자유롭게 정할 수 있음)
  • 이벤트 시간 모드로 데이터 스트림을 처리할 때 플링크는 레코드의 타임스탬프를 이용해 시간 기반 연산자 실행
    • ex. 시간-윈도우 연산자는 타임스탬프를 이용해 윈도우에 레코드 할당
  • 플링크는 타임스탬프를 16바이트의 Long값으로 변환해 레코드의 메타데이터에 첨부
    • 사용자 정의 연산자에서 Long값을 마이크로초로 해석 가능

 

워터마크

  • 이벤트 시간 애플리케이션은 레코드 타임스탬프 뿐만 아니라 워터마크도 제공해야 함
  • 이벤트 시간 애플리케이션의 각 태스크는 워터마크를 사용해 현재 이벤트 시간을 얻음
  • 시간 기반 연산자는 이벤트 시간을 사용해 연산을 시작하거나 스트림을 앞으로 진행시킴
    • ex. 시간-윈도우 태스크는 이벤트 시간이 윈도우 경계 끝을 지날 때 윈도우에 모인 레코드들을 계산하고 그 결과를 내보냄
  • 플링크는 워터마크를 Long 값의 타임스탬프를 갖고 있는 특별한 레코드를 추가해 구현
  • 그림 3-8. 타임스탬프를 포함하고 있는 레코드와 워터마크가 있는 스트림
  • 워터마크의 기본 속성
    • 태스크의 이벤트 시간 시계(event-time clock)가 앞으로만 흘러가게 하고 역행하지 않게 함
    • 레코드의 타임스퀘어와 관련 있음. T 타임스탬프를 갖고 있는 워터마크는 이후에 오는 모든 레코드의 타임스탬프가 T보다 커야 한다는 것 의미
      • 레코드의 타임스탬프 순서가 바뀐 스트림을 처리하는 데 사용
      • 시간 기반 연산자를 실행하는 태스크는 순서가 바뀌었을 수도 있는 레코드들을 수집하고 이벤트 시간 시계(워터마크를 수집하면서 앞으로 가는 시계)가 해당 타임스탬프와 관련된 레코드가 더 들어오지 않을 것이라 예상할 때 연산을 시작
      • 태스크가 워터마크 속성을 위반하는 레코드를 받으면 이 레코드의 타임스탬프가 속해야 하는 연산은 이미 종료됐을 가능성 높음 - 연착 레코드(late records)라 함
        • 플링크는 연착 레코드를 처리하는 여러 방법 제공
    • 워터마크의 흥미로운 속성 중 하나는 애플리케이션 결과의 완성도와 지연을 애플리케이션이 제어할 수 있게 한다는 것
      • 레코드 타임스탬프에 가까운 매우 빠듯한 워터마크는 처리 지연을 짧게 만듦 - 결과의 완성도 떨어짐 (관련 레코드가 결과에 미포함 - 연착 레코드로 생각함)
      • 보수적으로 워터마크(타임스탬프에서 멀리 떨어진 워터마크)를 정하면 처리 지연 길어짐 - 결과의 완성도 높아짐

 

워터마크 전파와 이벤트 시간

  • 플링크는 워터마크를 연산자 태스크가 받아서 내보내는 특별한 레코드로 구현
  • 태스크는 내부에 타이머 서비스(timer service)를 갖고 있으며, 이 서비스는 타이머(timer)를 유지하고 워터마크가 도착할 때마다 타이머를 활성화함
  • 태스크는 이 타이머 서비스에 타이머를 등록해 미래의 특정 시점에 어떤 연산 수행 가능 (ex. 윈도우 연산자)
  • 태스크가 워터마크를 받으면 다음과 같은 동작 벌어짐
    1. 태스크는 내부 이벤트 시간 시계를 워터마크의 타임스탬프 기준으로 갱신
    2. 태스크의 타이머 서비스는 갱신한 이벤트 시간보다 오래된 타이머를 모두 찾음. 시간이 만료된 타이머를 등록한 태스크는 어떤 연산을 수행하거나 레코드를 내보내는 콜백 함수 호출
    3. 태스크는 갱신한 이벤트 시간을 워터마크에 실어서 내보냄
  • 플링크는 데이터 스트림을 파티션으로 분할하고 각 파티션을 개별 연산자 태스크에 할당해 병렬로 처리
    • 각 파티션은 타임스탬프가 있는 레코드와 워터마크를 흘려보내는 스트림
  • 태스크 앞뒤에 어떤 연산자와 연결돼 있는지에 따라 태스크는 여러 입력 파티션에서 레코드와 워터마ㅡ를 수신하고 여러출력 파티션으로 레코드와 워터마크 전송 가능
  • 태스크는 각 입력 파티션에 대해 하나의 워터마크 유지
    • 입력 파티션에서 워터마크 받으면 해당 파티션의 현재 워터마크 값과 새 워터마크 값 비교해 최댓값을 새로운 워터마크로 갱신
    • 태스크는 모든 입력파티션의 워터마크 중 최솟값으로 이벤트 시간 시계 값 갱신
    • 이벤트 시간 시계가 앞으로 흐르면 태스크는 등록된 타이머 중 시간이 만료된 모든 타이머 활성화
    • 마지막에는 연결괸 모든 출력 파티션으로 새 워터마크를 내보내 전체 하위 스트림 태스크가 새 이벤트 시간 받게 함
    • 그림 3-9. 워터마크로 태스크의 이벤트 시간 갱신
    • Union이나 CoFlatMap과 같은 두 개 이상의 입력 스트림을 갖고 있는 연산자의 태스크도 모든 파티션의 워터마크 중 최솟값으로 이벤트 시간 시계 계산
      • 워터마크가 다른 입력 스트림에서 나오더라도 같은 파티션에서 나온 워터마크로 취급
      • 결과적으로 두 입력의 레코드는 같은 이벤트 시간 시계를 기바으로 처리됨
      • 두 입력 스트림에서 받은 이벤트 타임스탬프가 동기화돼 잇지 않으면 이런 동작은 문제 일으킬 수 있음
    • 플링크의 워터마크 처리오 전파 알고리즘은 연산자 태스크가 생성한 레코드가 워터마크와 최대한 동기화된 타임스탬프 갖도록 보장
      • 이를 위해서 모든 파티션이 지속적으로 증가하는 워터마크 제공해야 함
        • 어떤 파티션의 워터마크가 더이상 아픙로 가지 않고 아무런 레코드나 워터마크 내보내지 않는다면 태스크의 이벤트 시간 시계 더 진행하지 않고 태스크 타이머도 트리거 되지 않음
          • 시간 기반 연산자의 처리 지연과 상태 크기 굉장히 커질 수 있음

 

타임스탬프 할당과 워터마크 생성

  • 보통 스트림 애플리케이션으로 스트림 데이터가 들어올 때 타임스탬프를 할당, 우터마크 생성
  • 타임스탬프 결정은 애플리케이션이 하고 워터마크는 타임스탬프와 스트림의 특성에 의존하므로 애플리케이션이 명시적으로 타임스탬프를 할당하고 워터마크 생성해야 함
  • 타임스탬프, 워터마크 생성 방식
    1. 소스에서
      • SourceFunction을 통해 애플리케이션으로 스트림이 들어올 때 타임스탬프 할당, 워터마크 생성
      • SourceFunction은 레코드 스트림을 내보냄. 타임스탬프는 레코드와 함께 나가고 워터마크는 특별한 레코드로 특정시점에 나감
      • SourceFunction이 일시적으로 더 이상의 워터마크 내보내지 않는다면 자신을 유휴(idle)상태로 선언 가능
      • 플링크는 SourceFunction의 유휴 상태 스트림 파티션을 다음 연산자의 워터마크 계산에서 제외
    2. 주기적인 할당자(periodic assigner)
      • DataStream API : 각 레코드에서 타임스탬프를 추출하는 AssignerWithPeriodicWatermarks라 부르는 사용자 정의 함수 지원, 이 함수를 주기적으로 질의 해 현재 워터마크 알아냄
      • 플링크는 추출한 타임스탬프를 각 레코드에 할당, 질의한 워터마크는 스트림에 주입
    3. 구두점 할당자(punctuated assigner)
      • AssignerWithPunctuatedWatermarks : 각 레코드에서 타임스탬프를 추출하는 또 다른 사용자 저으이 함수. 특별한 입력 레코드에 포함된 워터마크를 추출하는데 사용 가능
        • 필수는 아니지만 각 레코드에서 워터마크 추출 가능
  • 연산자에 따라 레코드를 처리하고 나면 레코드의 타임 스탬프나 순서 파악이 매우 어려워질 수 있으므로 보통 소스 연산자에 가까운 곳에 사용자 정의 타임스탬프 함수 적용

데이터플로우 그래프

  • 데이터플로우 프로그램
    • 데이터 처리 연산 사이로 데이터가 어떻게 흐르는지(flow) 기술
  • 방향성 그래프(directed graph)
    • 데이터플로우 프로그램을 표현하는 일반적 방법
    • 노드(node)
      • 연산자(operator)라 부르고 계산 표현
      • 연산자 : 데이터플로우 애플리케이션의 기본 기능 단위
        • 입력으로 들어온 데이터를 소비하고 어떤 계산을 수행한 후 그 결과를 다음처리에서 사용할 수 있도록 출력으로 내보냄
        • 데이터 소스(data source) : 입력이 없는 연산자
        • 싱크(sink) : 출력이 없는 연산자
      • 논리적(logical) 데이터플로우 그래프 : 개념적 수준에서 바라본 계산 로직의 모습
        • 그림 2-1. 지속적으로 해시 태그를 카운트하는 논리적인 데이터플로우 그래프
        • 논리적 데이터플로우 그래프를 실행하려면 논리적 데이터플로우 그래프를 물리적 데이터플로우로 변환해야 함
        • 물리적 데이터플로우 : 프로그램을 어떻게 실행해야 하는지 자세히 지정 (ex. 분산 처리 엔진 사용 시 각 연산자는 각각 다른 물리적 장비에서 돌아가는 여러 병렬 태스크가 됨)
          • 그림 2-2. 해시 태그를 카운트하는 물리적 데이터플로우 그래프(노드는 태스크 표현)
            • '해시 태그 추출'과 '카운트' 연산자는 두 개의 병렬 연산 태스크를 갖고 있으며, 각 태스크는 입력 데이터 분할해 연산 수행
        • 에지(edge)
          • 의존 관계 표현

 

 

데이터플로우 프로그래밍 소개

    • 데이터플로우 프로그램
      • 데이터 처리 연산 사이로 데이터가 어떻게 흐르는지(flow) 기술
    • 방향성 그래프(directed graph)
      • 데이터플로우 프로그램을 표현하는 일반적 방법
      • 노드(node)
        • 연산자(operator)라 부르고 계산 표현
        • 연산자 : 데이터플로우 애플리케이션의 기본 기능 단위
          • 입력으로 들어온 데이터를 소비하고 어떤 계산을 수행한 후 그 결과를 다음처리에서 사용할 수 있도록 출력으로 내보냄
          • 데이터 소스(data source) : 입력이 없는 연산자
          • 싱크(sink) : 출력이 없는 연산자
        • 논리적(logical) 데이터플로우 그래프 : 개념적 수준에서 바라본 계산 로직의 모습
          • 그림 2-1. 지속적으로 해시 태그를 카운트하는 논리적인 데이터플로우 그래프
            •  
  • 데이터 병렬화와 태스크 병렬화
    • 데이터플로우 그래프의 병렬화 방식
      • 데이터 병렬화(data parallelism) : 동일 연산 수행하는 태스크를 각 입력 파티션에 할당해 병렬로 실행
        • 대용량 데이터 처리의 부하를 여러 장비로 분산시킬 수 있어서 매우 유용
      • 태스크 병렬화(task parallelism) : 같거나 다른 데이터에 여러 연산을 수행하는 태스크 할당
        • 클러스터의 계산 자원을 좀 더 효율적으로 사용 가능
  • 데이터 교환 전략
    • 데이터 교환 전략(data exchange strategy) : 물리적 데이터플로우 그래프에서 어떤 태스크로 레코드를 할당할지 정의
    • 그림 2-3. 데이터 교환 전략

      • 전진(Forward) 전략 : 한 태스크로 들어온 데이터를 다른 태스크쪽으로 내보냄
        • 두 태스크가 동일한 물리적 장비에 할당된다면(보통 태스크 스케줄러가 결정), 이 교환 전략에서는 네트워크 통신 없이도 데이터 교환 가능
      • 브로드캐스트(Broadcast) 전략 : 모든 레코드를 연산자의 모든 병렬 태스크로 내보냄
        • 데이터를 복제하고 네트워크 연산자를 사용하므로 비용이 다소 비싼 편
      • 키 기반(Key-based) 전략 : 데이터를 키 기준으로 모아 같은 키 값을 가진 데이터는 같은 태스크에 모이도록 보장
        • 그림 2-2의 '해시태그 추출'의 출력데이터를 같은 키(해시태그)를 가진 데이터끼리 모으면 카운트 연산자 태스크는 각 해시태그의 등장 횟수 정확히 계산 가능
      • 랜덤(Random) 전략 : 각 계산 태스크의 부하를 균등하게 분산시키고자 모든 연산자 태스크로 데이터를 균등하게 분배

 

 

병렬 스트림 처리

데이터 스트림 : 무한 이벤트 순서열(unbounded sequence of events)

데이터 스트림의 이벤트는 모니터링 데이터, 센서 측정, 신용카드 거래, 기상 관측소의 관찰 기록, 온라인 사용자 상호작용, 웹 검색등을 표현 가능

 

 

지연과 처리율

  • 성능 측정할 때의 요소
  • 배치 어플리케이션
    • 보통 잡의 총 실행 시간이나 사용 중인 처리 엔진이 입력을 읽고 결과를 쓰는 데 얼마나 많은 시간을 소모하는지 측정
  • 스트리밍 애플리케이션
    • 지속적으로 실행되고 입력이 무한이므로 전체 실행시간은 중요하지 않음
    • 대신 빠른 속도로 이벤트를 처리하면서 최대한 빠르게 계산 결과 제공해야 함
      • 성능 요건 - 지연(latency)과 처리율(throughput)
    • 지연
      • 이벤트를 처리하는 데 얼마나 많은 시간이 걸리는지 나타냄
      • 기본적으로 이벤트 수신과 이벤트 처리 결과(효과)를 출력해서 볼 때까지의 경과 시간을 의미
      • 데이터 스트리밍에서 지연은 밀리초 같은 시간으로 측정. 애플리케이션에 따라 평균 지연 최대 지연, 또는 퍼센타일(percentile) 지연에 관심을 가질 수 있음
        • ex. 평균 지연 10밀리초 : 이벤트를 처리하는 데 평균 10밀리초가 걸림
        • ex. 95번째 퍼센타일 지연 값이 10밀리초 : 이벤트의 95%를 처리하는데 10밀리 초가 걸림
          • 평균값은 처리 지연의 실제 분포값을 가려 문제 숨길 수 있음
      • 짧은 지연 보장은 사기 감지(fraud detection), 시스템 알람, 네트워크 모니터링, 엄격한 서비스 수준 협약(service level agreements)과 같은 여러 스트리밍 애플리케이션에서 아주 중요
      • 짧은 지연은 스트림 처리의 핵심 특징이며, 짧은 지연 덕분에 실시간(real-time) 애플리케이션의 구현 가능
        • 아파치 플링크 같은 최신 스트림 처리기는 몇 밀리초 단위의 지연 제공 가능
        • 이벤트가 시스템에 도착하자마자 처리, 지연은 각 이벤트를 처리할 때 소모한 실제 작업 시간 반영
    • 처리율
      • 시스템의 처리량을 측정하는 메트릭. 단위 시간당 얼마나 많은 이벤트를 처리할 수 있는지 알려줌
      • 단위 시간당 처리한 이벤트 개수나 또는 연산 호출 횟수 측정
      • 처리율은 이벤트 도착 비율에 의존한다는 것을 명심해야함.(낮은 처리율 =/= 나쁜 성능)
      • 최대 처리율 : 시스템이 최대 부하에 다다랐을 때 성능의 한계
      • 배압(backpressure) : 시스템이 처리할 수 있는 비율보다 높게 데이터를 계속 받으면 버퍼링도 불가능하게 돼 데이터를 잃을 수 있는 상황
  • 지연과 처리율
    • 지연과 처리율은 독립적인 메트릭이 아님
    • 지연과 처리율에 영향을 주는 요소
      • 부하가 없다면 지연은 최적 - 처리율 증가
      • 이벤트를 처리하는 데 걸리는 시간 증가 - 처리율 감소
    • 짧은 지연과 높은 성능 가지려면 (짧은 지연이 처리율도 높일 수 있음)
      • 이벤트 처리 속도 증가 (최대 부하에서 처리율 높아짐)
      • 스트림 처리 파이프라인의 병렬화 (같은 시간에 더 많은 이벤트 처리 가능)

 

 

데이터 스트림 연산

  • 스트림 처리 엔진은 보통 인입, 변환, 출력에서 사용할 수 있는 여러 기본 연산 제공
    • 스트리밍 애플리케이션 로직을 구현할 때 데이터플로우 처리 그래프에서 이런 연산 조합해 사용 가능
  • 상태가 없는 연산
    • 어떤 내부 상태도 유지하지 않기 때문에 이벤트에 대한 처리가 과거의 다른 이벤트에 의존하지 않으며 아무런 이력도 유지하지 않음
    • 이벤트는 서로 독립적이고 도착하는 순서에 의존하지 않으므로 병렬화 쉬움
    • 장애 발생 시 단순히 마지막에 처리했던 지점부터 재시작해 처리 이어나감
  • 상태가 있는 연산
    • 이전에 받은 이벤트의 정보 유지. 새로 들어온 이벤트는 이 상태를 갱신하고, 미래의 이벤트는 이 상태를 이벤트 처리 로직에서 사용
    • 상태가 있는 스트림 처리 애플리케이션은 상태를 효과적으로 분할하고 장애가 발생할 때 안정적으로 복구해야 하므로 병렬화와 내고장성을 유지하는 것이 큰 도전 과제
      • 내고장성 : 시스템의 일부가 고장이 나도 전체에는 영향을 주지 않고, 항상 시스템의 정상 작동을 유지하는 능력
  • 데이터 인입(ingestion)과 방출(egress)
    • 스트림 처리기가 외부 시스템과 통신하는 연산
    • 데이터 인입
      • 외부 소스에서 원시(raw) 데이터를 가져와 스트림 처리에 맞는 형식으로 변환하는 연산
        • 데이터 소스(data source) : 데이터를 가져오는 로직을 구현한 연산자. TCP 소켓, 파일, 카프카 토픽, 또는 센서 데이터에서 데이터 가져올 수 있음
    • 데이터 방출
      • 데이터를 수신할 외부 시스템의 소비 형태에 맞게 데이터 형식을 변환해 내보내는 연산
        • 데이터 싱크(data sink) : 데이터 방출을 수행하는 연산자. 파일, 데이터베이스, 메시지 큐, 모니터링 서비스의 엔드포인트 등
  • 변환 연산(transformation)
    • 단일 경로(single path)연산으로, 각 이벤트 독립적으로 처리
    • 이벤트를 하나씩 소비하면서 각 이벤트 데이터에 변환 연산을 적용한 후 변환된 이벤트를 새 출력 스트림으로 내보냄
    • 변환 로직은 연산자 안이나 사용자 정의 함수로 구현해 제공 가능
      • 그림 2-4. 각 인입 이벤트를 더 어둡게 변환하는 함수를 포함하는 스트림 연산
      • 연산자는 여러 입력스트림에서 이벤트 받아 여러 출력 스트림 생성 가능
      • 연산자는 하나의 스트림을 여러 스트림으로 나누거나 여러 스트림을 하나의 스트림으로 변환하는 등 데이터플로우의 그래프 구조를 변경할 수 있음
  • 롤링 집계 연산(Rolling aggregation)
    • 합계(sum), 최솟값(min), 최댓값(max)과 같은 집계 연산으로, 이벤트가 들어올 때마다 계속해서 상태 갱신
    • 집계 연산은 상태가 있으며 새로 들어온 이벤트와 현재 상태를 결합해 집계 값을 계산
      • 집계 값을 효과적으로 계산하기 위해 결합 법칙과 교환 법칙이 성립해야 함 (성립 안할 시 모든 이벤트 스트림 이력 저장 필요)
      • 그림 2-5. 롤링 최솟값 집계 연산
        • 현재 최솟값 유지 및 인입되는 이벤트마다 최솟값을 계산해 현재 상태 갱신
      • 윈도우 연산
        • 결과를 계산할 때 일정량의 이벤트를 모아 보관하고 있어야 하는 연산 존재 (스트림 조인(join)이나 평균 함수와 같은 전체 집계 연산(holistic aggregate))
          • 무한 스트림에서 효과적으로 수행하려면 각 연산은 자신의 상태에 보관 가능한 수준으로 데이터양 제한 필요
        • 실제 값(집계와 같은 값)을 구하는 것 외에도 윈도우를 이용하면 스트림에서 의미 있는 질의 할 수 있음
          • 가장 최근의 데이터만 관심있거나 단일 집계로 줄이면 시간에 따라 변하는 데이터의 다양한 정보 잃을 수 있음
        • 무한 이벤트 스트림에서 버킷(bucket)이라 부르는 이벤트의 유한 집합을 지속적으로 생성하고, 이 유한집합에 어떤 연산을 수행할 수 있게 해줌
        • 윈도우 정책
          • 언제 새 버킷을 생성하고, 어떤 이벤트를 어떤 버킷에 할당하며, 언제 버킷의 내용을 평가할 것인지 결정.
            • 윈도우 내용 평가 시점은 트리거(trigger)조건을 기반으로 결정. 트리거 조건 충족 시 버킷의 내용을 평가 함수로 전달해 각 버킷 이벤트에 연산 로직 적용
          • 시간(ex. 마지막 5초 안에 받은 이벤트)이나 개수(ex.마지막 100개 이벤트), 또는 데이터의 속성을 기준으로 삼기 가능
        • 일반적인 윈도우 시멘틱(semantic) 종류
          • 텀블링 윈도우(Tumbling Window)
            • 고정 길이에 서로 겹치지 않는(중첩되지 않는) 버킷으로 이벤트 할당.
            • 이벤트가 윈도우 경계를 넘으면 처리하고자 버킷의 모든 이벤트를 평가 함수로 보냄
            • 개수 기반(count-based) 텀블링 윈도우
              • 윈도우가 트리거링 되기 전에 얼마나 많은 이벤트를 모아야하는지를 정의
              • 그림 2-6. 개수 기반 텀블링 윈도우
            • 시간 기반(time-based) 텀블링 윈도우
              • 이벤트를 어떤 버킷으로 버퍼링할지를 시간 간격으로 정의
              • 그림 2-7. 시간 기반 텀블링 윈도우
            • 슬라이딩 윈도우(Sliding Window)
              • 서로 겹치는(중첩되는) 고정 길이의 버킷으로 이벤트 할당. 두 버킷에 포함되는 이벤트도 있을 수 있음
              • 길이와 슬라이드(slide)로 정의. 슬라이드 값은 새로운 버킷이 생성될 때까지의 간격 정의
              • 그림 2-8. 네 개의 이벤트 길이와 세 개의 이벤트 슬라이드로 정의한 개수 기반 슬라이딩 윈도우
            • 세션 윈도우(Session Window)
              • 텀블링이나 슬라이딩 윈도우로 적용할 수 없는 현실 세계 시나리오에서 유용
                • ex. 온라인 사용자 행동 분석 애플리케이션 - 동일 기간에 발생한 사용자 활동이나 세션 대상으로 이벤트 함께 모음
              • 세션이 종료됐다고 판단할 수있는 비활동 시간을 세션 격차(session gap)라는 값으로 정의해서 이벤트들을 세션으로 그룹화
              • 그림 2-9. 세션 윈도우
            • 병렬 텀블링 윈도우
              • 스트림을 여러 논리적 스트림으로 분할해서 병렬 윈도우(parallel window)로 정의 가능
                • ex. 서로 다른 센서 장비에서 데이터를 받을 때 스트림을 센서 식별자로 그룹핑해서 윈도우 계산 적용
              • 그림 2-10. 길이가 2인 개수 기반 병렬 텀블링 윈도우
            • 스트림 처리의 두 가지 핵심 개념인 시간과 상태 관리에 밀접한 연관 있음
              • 윈도우 연산의 진정한 가치는 빠른 분석 결과 이상
            • 네트워크 통신 채널 같은 현실 세계 시스템은 완벽하지 않음, 스트림 데이터는 지연되거나 순서가 바뀌어 도착 가능
              • 이런 상황에서 스트리밍 처리가 정확하고 결정적인 결과를 어떻게 생성하는지 반드시 이해해야 함
              • 이벤트 발생순으로 이벤트를 처리하는 애플리케이션은 이벤트 발생순으로 이력을 따라가며 이벤트 처리해야 함
                • 오프라인 분석이나 이벤트 시간 여행 분석(event time travel analysis) 가능해짐
                  • 장애 대비 상태 보호 필요 - 모든 윈도우 종류는 결과 생성 전 데이터 버퍼링 필요
            • 스트리밍 애플리케이션은 상태 관리 꼭 필요
              • 장애 상황에서 상태를 안정적으로 복구해 어떤 일이 벌어지더라도 스트리밍 애플리케이션이 정확한 결과를 낼 수 있다는 확신 필요

 

시간 시멘틱

  • 스트리밍 처리에서 1분
    • 매분 어떤 결과를 지속적으로 계산하는 스트리밍 애플리케이션을 가정해보자
      • 이 스트리밍 애플리케이션 문맥에서 1분이 의미하는 것은 실제 무엇일까?
      • 지하철에서 온라인 게임 플레이 시 네트워크가 끊겼다 안끊겼다 하는 상황 가정
      • 그림 2-11. 지하철에서 플레이한 온라인 모바일 게임 이벤트를 받는 애플리케이션은 네트워크가 끊길 때 시간 차이를 경험하게 됨. 그러나 이벤트는 핸드폰에 버퍼링돼 있고 네트워크가 다시 연결되면 애플리케이션으로 버퍼링한 이벤트를 보낸다.
    • 이벤트를 받은 시간이 아닌, 이벤트가 실제 발생한 시간이 연산자 시멘틱에 어떤 영향을 미치는지 보여주는 단순 시나리오
      • 1분 안의 이벤트양을 정의하는 것은 처리 시간이 아닌 데이터 자체의 실제 시간
      • 처리 시간(processing time)이나 이벤트 시간(event time)을 이용해 연산 수행
    • 처리 시간
      • 스트림 처리 연산자가 실행 중인 장비의 시계에서 측정한 로컬 시간
        • 로컬 시간을 기준으로 일정 시간 동안 윈도우 연산자에 도달한 모든 이벤트는 처리 시간 윈도우(processing-time window)안으로 들어감
        • 그림 2-12. 앨리스 핸드폰 네트워크가 끊긴 후에도 처리 시간 윈도우의 시간은 계속 흘러감
    • 이벤트 시간
      • 이벤트가 실제 발생한 시간. 이벤트 내용 안에 포함된 타임스탬프(timestamp)를 기반으로 함
        • 타임스탬프는 보통 스트리밍 처리 파이프라인에 도착하기 전에(ex. 이벤트 생성 시간) 생성돼 이벤트 데이터 안에 존재
        • 이벤트 시간 윈도우는 이벤트의 일부가 지연되더라도 발생했던 일을 제대로 반영
        • 그림 2-13. 이벤트 시간은 윈도우 안에 이벤트를 정확히 넣는다. 이 윈도우는 발생한 이벤트를 제대로 반영
      • 처리 결과를 처리 속도와 완전히 분리. 연산의 예측이 가능하고 결과는 결정적
      • 스트림을 얼마나 빨리 처리하고 이벤트가 연산자에 언제 도착하든 간에 이벤트 시간 윈도우는 항상 동일한 결과 생성
      • 데이터의 순서가 바뀌더라도 결과의 정확성 보장
      • 재생(replay)가능한 스트림 로그와 결합하면 시간이 항상 동일한 것을 보장하므로(타임스탬프 결정성) 과거 이벤트도 빠르게 되돌려 볼 수 있음
        • 과거의 이력 데이터도 마치 실제시간에 발생한 것처럼 분석 가능
          • 현재 시간까지 빠르게 따라잡으면 완전히 동일한 프로그램 로직으로 실시간 애플리케이션 계속 이어나갈 수 있음
      • 워터마크
        • 이벤트가 더 지연되지 않고 도착할 것이라고 확신할 수 있는 시점을 가리키는 메트릭으로, 전체 진행 시간을 나타냄
        • 스트리밍 시스템에 현재 이벤트 시간을 알려주는 논리적인 시계 제공
        • 순서가 바뀐 이벤트를 처리하는 이벤트 윈도우와 연산자 모두에게 꼭 필요함
        • 연산자가 워터마크를 수신하면 일정 기간동안 발생한 모든 이벤트의 시간이 감지됐다는 것을 알게되고 수신한 이벤트를 대상으로 계산을 시작하거나 이벤트 정리
        • 결과의 신뢰성과 지연사이의 균형을 맞출 수 있는 설정 제공
          • 너무 빠듯하게 발생시키면 짧은 지연 보장 가능, 낮은 신뢰성
            • 워터마크를 먼저 도착한 이벤트의 시간에 가깝게 맞춘다는 것을 의미.
            • 워터마크 이후 늦게 도착한 이벤트를 처리하는 별도 코드 제공해야 함
          • 너무 느슨하게 생성 시 높은 신뢰성, 불필요한 처리 지연
            • 첫 번째 이벤트의 시간보다 늦게 워터마크를 발생시켜 늦게 도착하는 이벤트도 가능한 많이 같은 윈도우에 포함시킴
        • 워터마크를 사용자가 정의하든 자동으로 생성하든 분산 시스템에서 뒤처진 작업이 존재하는 한 전체 진행 상황을 완전하게 추적하는 것 쉽지 않음
          • 워터마크보다 늦게 도착한 이벤트 처리 방법
            • 애플리케이션의 요구 사항에 따라 워터마크보다 늦게 도착한 이벤트 무시 가능
            • 이전 결과를 보정하는 데이터로 사용 가능
      • 처리 시간과 이벤트 시간
        • 이벤트 시간으로 모든 문제를 해결할 수 있는데 왜 처리 시간도 고민해야 할까?
        • 처리 시간이 쓸만할 때
          • 정확성보다 속도가 더 중요한 애플리케이션에서는 처리 시간이 유용
            • 늦게 도착한 이벤트나 이벤트 순서 고려하지 않을 때 윈도우는 단순히 이벤트를 버퍼링, 지정 윈도우에 이벤트 도착하는 즉시 계산 동작
          • 정확도가 크게 중요하지 않은 실시간 보고서를 주기적으로 생성해야 할 때
            • 이벤트가 도착하는 대로 집계해서 보여주는 실시간 모니터링 대시보드 애플리케이션
          • 처리 시간 윈도우도 스트림 자체의 특성을 충분히 표현 가능
            • 정전 감지하고자 스트림 애플리케이션이 스트림에서 초당 얼마나 많은 이벤트 발생하는지 관찰 가능
        • 처리 시간은 짧은 지연을 제공하지만 결과는 처리 속도에 따라 다르고 결정적이지 않음
          • 이벤트 시간은 결정적 결과를 보장하고, 늦게 도착하거나 순서가 바뀐 이벤트도 처리할 수 있게 해줌

 

 

상태와 일관성 모델

  • 상태(state) : 데이터 처리 어디에나 존재. 거의 모든 계산에서 필수.
  • 함수는 일정 기간이나 일정 개수의 이벤트를 대상으로 상태(ex. 집계, 패턴 감지)를 누적해 결과 생성
  • 상태가 있는 연산자는 수신한 이벤트와 내부 상태를 사용해 연산 결과를 생성
    • ex. 롤링 집계 연산
      • 이 연산자는 내부 상태로 현재까지 합계 값을 보관하고 새로운 이벤트를 받을 때마다 이 값 갱신
    • ex. '높은 온도' 이벤트 감지 후 '연기' 이벤트가 10분 안에 발생할 것을 감지할 때 알람 보내는 연산자 가정
      • '연기' 이벤트가 도착하거나 10분이 지날 때까지 '높은 온도' 이벤트를 내부 상태에 보관해야 함
  • 상태의 중요성은 배치 처리 시스템으로 무한 데이터셋을 분석하는 것과 비교하면 더 명확해짐
    • 배치 처리 시스템
      • 작은 배치를 대상으로 잡(job)을 반복 스케줄링. 어떤 잡이 종료되면 결과를 영구적인 저장소로 전송하고 모든 연산자의 상태 사라짐
      • 다음 배치 처리에 스케줄돼 있는 잡은 이전 잡의 상태 접근 불가
        • 데이터베이스 같은 외부 시스템에 상태 관리를 위임해 문제 해결
    • 스트림 잡에서 모든 이벤트는 상태에 접근 가능, 이 상태를 프로그래밍 모델의 일급 시민(first-class citizen)으로 노출 가능
      • 추가 지연 시간이 발생할 수는 있지만 스트림 상태를 안전하게 관리하기 위해 외부 시스템 사용 가능
  • 스트림 연산자는 무한 데이터를 처리하므로 내부 상태가 무한으로 커지지 않도록 조심해야 함
    • 연산자는 지금까지 받은 이벤트들을 요약 정보나 개요(synopsis)같은 형태로 관리해 상태의 크기를 제한하는 것이 일반적
      • 카운트, 합계, 현재까지 받은 이벤트들에 대한 샘플, 윈도우 버퍼, 사용자 정의 데이터 구조를 사용
  • 상태가 있는 연산자를 사용하기 위한 극복 대상 도전 과제
    • 상태 관리(State management)
      • 시스템은 상태 관리를 효율적으로 해야 하고 동시에 상태를 갱신할 때 상태를 보호
    • 상태 분할(State partitioning)
      • 병렬로 처리할 때 처리 결과가 상태와 입력 이벤트 모두에 의존함으로 복잡해짐
        • 키(key)로 상태 분할 가능, 각 파티션 별로 상태 관리 가능
          • ex. 센서 측정하고 이 측정 값을 이벤트로 저장하는 스트림 처리 시 분할 상태를 사용해 센서별 독립적인 상태 유지 가능
    • 상태 복구(State recovery)
      • 상태를 복구하고 장애 시에도 정확한 결과를 내보내야 함

 

태스크 실패

  • 스트리밍 잡에서 연산자 상태는 매우 중요하고 장애에 대비해 보호해야 함
    • 장애 발생 시 상태 잃어버리면 복구 후 결과 부정확
    • 스트리밍 잡은 오랜 시간 동안 실행되므로 상태는 며칠이나 몇달동안 수집한 것일 수 있음
      • 장애로 유실한 상태 재생산하려 과거 입력을 모두 재처리하는 것은 매우 비용이 많이 들면서 많은 시간 소모
  • 실재 환경에서 병렬 태스크를 수백 개 실행하는 것이 일반적이며 각 태스크는 언제나 실패할 수 있음
  • 태스크 실패
    • 태스크란 입력 스트림의 각 이벤트를 대상으로 아래의 절차들을 수행하는 하나의 처리 단계
      1. 이벤트를 수신해 로컬 버퍼에 저장
      2. 경우에 따라 내부 상태 갱신
      3. 출력 레코드 생산
    • 실패는 위과정 어디에서나 발생 가능하며, 시스템은 장애 시나리오마다 어떻게 동작할지를 명확하게 정의해야 함
    • 배치 처리 시나리오에서는 배치 잡을 처음부터 다시 시작할 수 있기 때문에 어떤 이벤트도 유실되지 않고, 상태도 처음부터 다시 완전하게 만들 수 있음
    • 스트리밍 시스템은 실패가 발생할 때 결과를 보장할 수 있는 여러 방식 정의

 

결과 보장

  • 스트림 처리기 내부 상태의 일관성을 의미
    • 결과 보장의 관심사는 실패 복구 후 애플리케이션 코드가 바라보는 상태 값
    • 애플리케이션 상태 일관성 보장은 출력의 일관성 보장과 같지 않음
      • 결과를 한번 싱크로 보내면 싱크 시스템이 트랜잭션을 지원하지 않는 이상 결과의 정확성을 보장하기 어려움
  • 최대 한번(at-most-once)
    • 각 이벤트를 최대 한번 처리하는 것을 보장하는 낮은 수준의 보장 방법
      • 이벤트는 날아가고 결과의 정확성 보장을 위해 아무것도 하는 것이 없음
    • 무보장(no guarantee)이라고도 함
    • 대략적인 결과와 지연 시간 최소화에만 관심이 있다면 좋은 선택
  • 최소 한 번(at-least-once)
    • 모든 이벤트를 처리하지만 그중 일부는 한 번 이상 처리할 수 있음
    • 애플리케이션이 결과의 완결만 중요시한다면 중복 처리는 수용 가능한 조건
    • 결과의 정확성 보장하려면 소스나 어떤 버퍼에서 이벤트를 재생할 방법을 갖고 있어야 함
      • 지속성 이벤트 로그는 모든 이벤트를 신뢰할 수 있는 저장소에 저장하므로 태스크가 실패하더라도 이벤트 재생 가능
        • 파이프라인에 있는 태스크들이 이벤트를 모두 처리했다는 것을 이벤트 로그가 인식할 때 까지 모든 이벤트를 버퍼에 저장
        • 이벤트 로그는 이벤트가 모두 처리됐다고 인식하는 시점이 되면 해당 이벤트를 이벤트 로그에서 삭제 가능
  • 정확히 한번(exactly-once)
    • 단지 이벤트 유실이 없다는 것뿐만 아니라 이벤트마다 정확히 한 번씩만 내부 상태를 갱신
      • 마치 실패가 한 번도 없었던 것처럼 애플리케이션이 정확한 결과를 제공하리란 것 의미
    • 가장 엄격한 보장 방식이고 구현이 쉽지 않음
    • 최소 한 번 보장이 필요하고, 따라서 데이터 재생 기능 필수
    • 스트림 처리기는 내부 상태 일관성 보장해야 함
      • 장애 복구 후 어떤 이벤트가 상태에 이미 반영됐는지 알아야 한다는 것 의미
        • 트랜잭션 업데이트 방식 사용 가능하나 부가적인 성능 저하 발생 가능
        • 플링크는 경량 스냅샷(lightweight snapshot) 메커니즘을 사용해 정확히 한 번 결과 보장
  • 단대단 정확히 한 번
    • 단대단(end-to-end) 보장은 전체 데이터 처리 파이프라인에 걸친 결과의 정확성 의미
    • 각 컴포넌트가 각자 상태를 보장하는 방법을 완벽히 제공하더라도 전체 파이프라인의 단대장 보장 제공 쉽지 않음
    • 가끔 약한 상태 보장 방식으로 강한 상태 보장 얻을 수 있음
      • ex. 스트림 처리가 최댓값이나 최솟값 같은 멱등적(idempotent)연산을 수행할 때
        • 최소 한 번(at-least-once) 보장으로 정확히 한 번(exactly-once)보장 얻을 수있음
        • 멱등적 - 어떤 값을 여러 번 반복 연산해도 결과 같음

아파치 플링크(Apach Flink) : 분산 스트림 처리 소프트웨어.

  • 상태가 있는 스트림 처리(Stateful Stream Processing)
    • 실시간 데이터 처리를 위하여 이전에 분석된 데이터의 결과 사용. 이벤트를 처리하고 그 결과를 저장할 상태 저장소가 필요.
  • 애플리케이션을 구현하는데 필요한 직관적이고 표현력이 풍부한 API 제공

 

전통적인 데이터 인프라 아키텍처

트랜잭션 처리

  • 데이터 처리(애플리케이션)와 데이터 저장소(트랜잭션 데이터베이스 시스템)라는 두 계층 가지고 있는 아키텍처
  • 원격 데이터베이스 시스템에 데이터를 저장하는 트랜잭션 애플리케이션의 전형적인 설계
    • 그림 1-1.
  • 애플리케이션: 보통 외부 서비스나 사용자와 상호작용하면서 발생하는 주문서, 이메일이나 웹 사이트 클릭과 같은 이벤트 지속적 처리
    • 애플리케이션을 개선하거나 규모를 확장할 때 문제 발생 가능 - 여러 애플리케이션이 동일한 데이터 모델을 대상으로 작업 or 동일한 인프라를 공유해서 테이블 스키마 변경이나 데이터베이스 시스템 확장 시 문제 발생 가능
  • 마이크로서비스 설계 패턴 : 작고 자립적이며 독립적인 설계 방식. 잘 정의한 인터페이스로 서로 통신하게 강제하므로 마이크로서비스 간의 결합 완전히 분리.
    • 보통 마이크로서비스에 필요한 모든 소프트웨어와 서비스를 하나로 묶어 독립 컨테이너에 배포.
    • 그림 1-2. 마이크로서비스 아키텍처

 

 

 

 

 

분석 처리

  • 여러 트랜잭션 데이터베이스 시스템의 데이터 분석
  • 트랜잭션 데이터 대부분 서로 다른 데이터베이스 시스템에 분산돼 있으므로, 이를 통합 분석하면 더 가치있는 정보 얻을 수 있음
  • 분석 질의 시 분석 질의 전용 데이터 저장소인 데이터 웨어하우스에 데이터를 복제한 후 실행
    • ETL(Extract-추출, Transformation-변환, Load-적재)
      • 데이터를 트랜잭션 데이터베이스에서 추출하고 데이터 유효성 검사와 정규화, 인코딩, 중복 제거, 스키마 변경, 많이 사용하는 데이터 형식으로 변환 수행 등을 한 후 변환한 데이터를 분석 데이터베이스에 적재.
      • 데이터 웨어하우스와 데이터를 동기화하기 위해 ETL 처리 주기적 실행 필요
    • 데이터 웨어하우스에서 실행하는 질의 분류
      • 기업의 수익, 고객 유입 증가나 제품 출하량과 같은 비즈니스와 관련 있는 데이터 주기적으로 보고하는 질의
      • 애드혹(Ad-hoc)질의 : 특정 문의에 응답하거나 비즈니스와 관련해서 민첩한 결정이 필요할 때 사용
      • 그림 1-3. 데이터 분석을 위한 전통적인 데이터 웨어하우스 아키텍처
  • 아파치 하둡 생태계
    • 대용량의 데이터를 하둡 분산 파일 시스템(HDFS, Hadoop’s Distributed File System)이나 S3, 또는 아파치 HBase와 같은 벌크 저장소에 저장.
      • 벌크 저장소 : 저비용, 고용량의 저장소 제공.

 

 

 

상태가 있는 데이터 스트림 처리

  • 모든 데이터는 이벤트 스트림이 지속적으로 생성한 데이터라 가정할 수 있음.
  • 상태가 있는 스트림 처리는 무한 이벤트 스트림을 처리하는 애플리케이션 설계 패턴이며 여러 분야에 응용 가능.
    • 이벤트 수신 후 상태에서 데이터 읽거나 상태에 데이터 쓰는 연산 수행. 레코드, 중간 결과, 메타 데이터 등
    • 아파치 플링크 :
      • 애플리케이션 상태를 로컬 메모리나 임베디드 데이터베이스에 저장
      • 로컬의 상태를 원격의 신뢰성 있는 저장소에 애플리케이션 상태의 체크포인트(Checkpoint)를 주기적으로 기록
    • 그림 1-4. 상태가 있는 스트림 애플리케이션
  • 상태가 있는 스트림처리 애플리케이션은 주로 이벤트 로그에서 이벤트 가져옴.
    • 이벤트 로그: 이벤트 스트림 저장하고 분배
    • 이벤트 생산자(Producer)는 추가 전용(Append-only)로그에 이벤트 씀 - 이벤트 읽을 때 순서가 변경되지 않음(결정적)을 의미
    • 동일한 소비자(Consumer)나 다른 소비자가 이벤트 로그에 저장한 이벤트를 여러 번 읽을 수 있음
    • 로그의 추가 전용 특성 때문에 모든 소비자는 정확히 같은 순서의 이벤트 받아 볼 수 있음.
    • 이벤트 로그 시스템 : 아파치 카프카(Apache Kafka), 클라우드 컴퓨팅 회사가 제공하는 이벤트 로그 서비스.
  • 플링크로 실행하는 상태가 있는 스트리밍 애플리케이션과 이벤트 로그의 결합
    • 이벤트 로그는 들어오는 이벤트를 저장하고 항상 같은 순서로 애플리케이션에 보냄
    • 장애 발생 시 플링크는 직전 체크포인트에서 애플리케이션 상태 복구 및 이벤트 로그의 읽기 위치를 이전 위치로 재설정해 애플리케이션의 상태 원상 복구
    • 애플리케이션은 이벤트 스트림의 끝에 도달할 때까지 이벤트 로그를 재생(또는 빨리 감기)

 

이벤트 주도 애플리케이션(Event-Driven Application)

  • 이벤트 스트림을 입력으로 받아 특정 비즈니스 로직을 처리하는 ‘상태가 있는 스트리밍 애플리케이션’
    • 실시간 추천
    • 패턴 감지나 복합 이벤트 처리 (CEP, Complex Event Processing)
    • 이상 탐지
  • REST 호출 대신 이벤트 로그를 통해 서로 통신하고, 애플리케이션 상태는 로컬에서 관리
  • 그림 1-5. 이벤트 주도 스트리밍 애플리케이션
    • 한 애플리케이션이 이벤트 로그에 결과 출력하면 다른 애플리케이션은 이를 소비
    • 이벤트 로그는 이벤트 전송과 수신을 분리하고 비동기, 논블록킹(non-blocking)으로 이벤트를 전송
    • 각 애플리케이션은 상태가 있을 수 있으며 이를 외부 데이터베이스가 아닌 로컬에서 자신의 상태를 관리
    • 애플리케이션의 동작과 수평 확장은 각 애플리케이션이 독립적으로 수행
  • 이벤트 주도 애플리케이션과 트랜잭션 애플리케이션, 마이크로서비스와의 차이점
    • 로컬 상태 접근 - 원격 데이터 저장소에서 읽고 쓰는 것보다 훨씬 빠른 성능
    • 수평 확장과 장애 극복은 스트림 처리기가 관리
    • 이벤트 로그를 입력 소스로 사용함으로써 애플리케이션 입력 데이터를 안정적으로 저장
    • 이벤트의 순서를 보장해서 이벤트 여러번 처리 가능
    • 플링크는 애플리케이션의 상태를 이전 세이브포인트(Savepoint)로 설정해 상태를 잃지 않고 애플리케이션을 업그레이드하거나 수평 확장할 수 있게 함
  • 이벤트 주도 애플리케이션을 실행하려면 스트림 처리기의 기능이 굉장히 높은 수준에 있어야 함.
    • 비즈니스 로직의 구현과 실행은 스트림 처리기의 API 표현력과 상태 관리의 품질, 이벤트 시간(Event-Time)지원 등이 결정.
  • 정확히 한번(Exactly—once) 수준의 상태 일관성과 애플리케이션 수평 확장 지원

아파치 플링크는 위의 기능 모두 포함.

 

 

 

 

 

데이터 파이프라인

  • 데이터 파이프라인(Data Pipeline) : 짧은 지연으로 데이터를 가져와 변환, 삽입하는 종류의 애플리케이션
  • 데이터 접근 성능을 향상하고자 동일 데이터를 여러 데이터 저장 시스템에 저장하는 것은 일반적
    • 이런 데이터 복제의 필요성 때문에 데이터를 각 데이터 저장소에서 반드시 동기화해야 함
  • 데이터 동기화 방법
    • 주기적 ETL 작업 수행 - 짧은 지연 시간을 필요로 하는 최근 서비스의 요구 사항 만족시키지 못함
    • 이벤트 로그 사용해 데이터 변경 내용 분산

 

스트리밍 분석

  • 분석 ETL 작업은 주기적으로 데이터 저장소에 데이터를 적재한 후 애드혹이나 예약한 질의를 이용해 처리 - 배치 처리
    • 분석 파이프라인에 상당히 긴 지연 시간 발생시키는 원인
    • 데이터 저장소에 넣을 때 데이터 파이프라인 애플리케이션을 실행하면 어느 정도의 지연 시간은 줄일 수 있으나 실시간 데이터 수집 및 즉시 반응해야 할 때도 지연 발생
  • 스트리밍 애플리케이션의 장점
    • 지속적으로 이벤트 스트림을 가져와 짧은 지연 시간으로 최신 이벤트를 처리한 후 결과 갱신. 짧은 시간 안에 이벤트를 분석 결과에 반영 가능
      • 일반적으로, 스트림 애플리케이션은 업데이트 성능이 좋은 데이터베이스나 키-값 저장소와 같은 외부 데이터 저장소에 처리 결과 저장
      • 1-6. 스트리밍 분석 애플리케이션
  • 스트림 처리기가 지속적으로 이벤트를 가져오고, 상태를 관리하며, 연산한 결과를 갱신하는 모든 절차를 관리
    • 전통적 분석 파이프라인의 경우 ETL처리, 저장시스템, 여러 개의 개별 컴포넌트 가지고 있음
    • 정확히 한 번(exactly-once)의 일관성이 보장되는 애플리케이션 상태를 이용해 장애에서 복구 가능
    • 애플리케이션 연산에 필요한 자원 조절 가능

 

오픈소스 스트리밍 처리의 진화

최근 오픈소스 스트림 처리의 기술적 성숙은 스트리밍 처리 기술의 대규모 도입 이끌어냄

  1. 오픈소스 스트림 처리 소프트웨어는 모든 사람이 무료로 평가해보고 사용 가능
  2. 오픈소스 커뮤니티의 노력으로 확장 가능한 스트림 처리 기술이 빠른 속도로 성숙

 

스트림 처리의 역사

  • 1세대(2011) : 밀리초 단위의 지연 시간으로 이벤트를 처리하는 데 집중했으며, 장애 시 유실 허용
    • 저수준의 API, 스트림 처리 결과가 시간과 이벤트의 도착 순서에 좌우됨
    • 장애 시 이벤트를 유실하지 않더라도 이벤트를 한 번 이상 처리 가능
    • 짧은 지연 시간 > 정확한 결과
    • 람다(Lambda) 아키텍처 : 배치 분석 아키텍처 결과의 늦은 지연 시간을 보완하기 위함
      • 그림 1-7. 람다 아키텍처
        • 주기적으로 배치 처리를 수행하는 전통적인 아키텍처에 짧은 지연시간을 제공하는 스트림 처리 기반의 스피드 계층(Speed Layer)을 추가한 변형
          • 데이터가 도착하면 스트림 처리기와 배치 저장소로 데이터 전송
          • 스트림 처리기는 근실시간으로 연산을 수행해 대략적 결과 도출, 스피드 테이블(Speed Table)에 저장
          • 배치 처리기: 주기적으로 배치 저장소에 있는 데이터 처리, 정확한 결과를 배치 테이블(Batch Table)에 쓰고, 관련 있는 스피트 테이블의 부정확한 결과는 버림
          • 스피트 테이블의 대략적인 결과와 배치 테이블의 정확한 결과를 병합해 소비
        • 단점:
          • 서로 다른 이벤트 처리 시스템이 각각의 API를 이용해 의미적으로 동일한 애플리케이션을 두 벌 구현 필요
          • 스트림 처리기가 생성한 결과는 대략적인 결과 뿐
          • 람다 아키텍처를 설치하고 유지 보수하기 어려움
  • 2세대(2013년) : 몇 밀리초에서 몇 초 단위의 처리 지연 시간 보장, 처리 결과는 여전히 시간과 이벤트 도착 순서에 달림
    • 이전 보다 향상된 장애 복구 기능 지원
    • 실패 발생하더라도 각 코드가 결과에 정확히 한번만 반영 보장
    • 고수준 API로 진화
  • 3세대(2015년): 시간과 이벤트의 도착 순서에 따라 결과 달라지는 문제 다룸
    • 정확히 한 번 장애 복구와 결합한 시스템은 일관성 있고 정확한 결과를 만들어내는 최초의 오픈 소스 스트림 처리기
    • 실시간 데이터를 처리해 결과 생성하기도 하지만, 과거 데이터도 '라이브'데이터와 같은 방식으로 처리 가능
    • 짧은 지연 시간과 처리율 간의 상충 문제 제거

 

 

플링크 빠르게 살펴보기

  • 아파치 플링크 : 강력한 기능으로 무장한 3세대 분산 스트림 처리기.
  • 대규모 환경에서 높은 처리율과 짧은 지연으로 정확한 스트림 처리 결과 제공
    • 이벤트 시간과 처리 시간 시멘틱
      • 이벤트 시간 시멘틱은 순서가 바뀐 이벤트가 들어오더라도 일관성 있고 정확한 결과 제공
    • 상태 일관성 보장
      • 초당 수백만 이벤트 처리하면서 밀리초 단위의 지연 시간 보장. 플링크 애플리케이션을 수 천대의 클러스터 환경으로 확장 가능
    • 표현력과 사용 편리성에 따라 선택 가능한 계층적 API : DataStream API, 처리함수. 관계형 API(SQL, LINQ스타일의 테이블 API)
    • 아파치 카프카, 아파치 카산드라, 일래스틱 서치, HDFS, S3 등 저장 시스템에 연결하는 여러 종류의 커넥터 제공
    • 쿠버네티스, YARN, 아파치 메소스와의 강력한 통합, 빠른 장애 복구, 동적인 규모 확장이 가능한 고가용성(단일 실패 지점 없음) 덕분에 매우 짧은 타임으로 스트리밍 애플리케이션을 중단없이 24/7로 실행 가능
    • 애플리케이션 상태를 잃어버리지 않고 다른 플링크 클러스터로 잡 코드 업그레이드하거나 잡을 마이그레이션 할 수 있는 기능 제공
    • 사전에 문제 인지, 사용자 정의가 가능한 시스템과 애플리케이션 매트릭 수집
    • 최신의 완전한 배치 처리기
    • 사용하기 쉬운 API
    • 임베디드 실행 모드 : 애플리케이션과 전체 플링크 시스템을 하나의 JVM 프로세스에서 동작하게 해줌
      • IDE에서 플링크 잡 실행, 디버깅 가능
    •  

+ Recent posts