01. 상태가 있는 스트림 처리 소개

아파치 플링크(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에서 플링크 잡 실행, 디버깅 가능

• •