NiFi

[NiFi]NiFi 개념 및 Clustering

heed159 2022. 4. 19. 09:57

 

 

NiFi란?

Apache NiFI는 데이터를 가져오고 이를 처리한 후 적재하기 위한 ETL Tools의 일종으로 분산환경에서 대량의 데이터를 수집, 처리하며 FBP 개념을 구현하여 만든 오픈소스이다.

FBP개념이란 흐름 기반 프로그래밍(Flow Based Programming)을 말하며 사전에 DATA FLOW를 정의한 후 이를 지속적으로 유지하면서 데이터를 교환하는 프로그래밍 패러다임을 말한다.

NiFi는 시스템 간의 '데이터 흐름'을 자동화하도록 구축되어 있으며 '데이터 흐름'이라는 용어는 다양한 맥락에서 사용되지만 여기서는 시스템 간의 자동화 되고 관리되는 정보 흐름을 의미한다.

장점

  1. 실시간 처리에 매우 적합 (파일 생성 시 실시간으로 다른 DB에 저장, FTP로 전송 가능)
  2. Zero Mastser 클러스터 환경을 제공하며 확장 쉬움
  3. 데이터 유실 없이 데이터 전송 가능
  4. HTTPS를 통한 통신보안
  5. 웹 기반의 직관적 UI
  6. 데이터 이동경로 추적 가능
  7. 여러 NiFi 시스템 간 통신을 지원해 클러스터간 Site-to-Site 데이터 교환이 가능

단점

  1. 배치 작업 효율이 떨어짐
  2. 원본 소스파일 누락 없이 전송이 되었는지 확인이 어려움
  3. 스케줄러는 배치 스케줄러가 아니라 실행되는 내용 확인 불가능
  4. 실행 후 성공, 실패, 출력 결과만을 알 수 있음
  5. 간단한 데이터 조작만 가능, 복잡한 연산 불가

주요 용어

용어 내용
Data Flow Manager
(DFM)		 NiFi 데이터 흐름의 구성 요소를 추가, 제거 및 수정할 수 있는 권한이 있는 NiFi 사용자
FlowFile NiFi에서 데이터를 표현하는 객체로, Key/Value 형태의 데이터(Content)와 데이터 속성(Attribute)을 포함.
데이터는 0바이트 이상의 데이터가 저장될 수 있고 FlowFile을 이용하여 여러 시스템 간의 데이터 이동이 가능
FlowFile Processor FlowFile은 여러 단계에 걸쳐 속성이 추가되거나 내용이 변경될 수 있는데 이 때 사용되는 것이 FlowFile Processor.
NiFi는 다양한 Processor를 제공하는데 이를 이용하여 FlowFile을 다양한 시스템으로부터 읽어와서 변경하고 저장 가능
Connection Processor 간의 연결을 말하고 NiFi의 Connection은 FlowFile의 대기열(queueing)뿐만 아니라 라우팅, 처리량 제한, 우선순위 제어, 모니터링 등의 강력한 기능을 제공
Flow Controller Processor가 어느 간격 또는 어떤 시점에 실행하는지 스케줄링 -> NiFi의 스케줄러
Process Group 특정 업무나 기능 단위로 여러 Processor를 묶을 수 있으며 Input과 Output 포트를 제공해 Process Group 간 데이터 이동이 가능

 

NiFi Architecture

 

 

위의 그림과 같이 NiFi는 호스트 운영 체제의 JVM 내에서 실행되며 Web Server, Flow Controller, Extension 그리고 세 개의 Repository 로 구성된다.

 

Web Server의 목적은 NiFi의 HTTP 기반 명령 및 제어 API를 호스팅하는데 있다. 사용자는 이를 이용해 Dataflow를 개발하고 제어하며 모니터링하게 된다.

 

Flow Controller는 Extension이 실행할 자원을 받는 일정을 관리하게 되고 스레딩을 통해 다수의 동시작업을 지원한다.

 

Extension은 매우 다양한 종류가 존재하며 제 각기 다른 기능을 가지고 있지만 하나 하나 설명하기엔 어려움이 있다. 따라서 실제로 NiFi를 통해 파이프라인을 구축할 때 그때그때 필요한 기능이 무엇인지 검색하면서 사용하는 것이 중요하다. 여기서의 핵심은 Extension이 JVM 내에서 작동하고 실행된다는 것이다.

 

FlowFile Repository는 Write-Ahead-Log로 FlowFile의 속성과 상태 값 등을 저장하는 곳을 말한다. Write-Ahead-Log란 데이터베이스 시스템에서 ACID의 특성 가운데 원자성과 내구성을 제공하는 기술의 한 계열. WAL을 사용하는 시스템에서는 모든 작업을 할 때 로그에 기록하기 때문에 예기치 않은 에러가 발생할 때 로그를 검사하여 효율적으로 일을 처리한다. 따라서 시스템 장애가 발생할 때 데이터가 유실되지 않도록 하는데 로그를 저장하고 가지고 있는 시간이 짧기 때문에 보통은 RDB에 로그까지 같이 적재해서 활용하게 된다.  (기본적으로 RDB에 로그까지 적재)

 

Content Repository는 모든 FlowFile의 콘텐츠가 존재하는 로컬 스토리지의 장소를 말한다. 단순히 모든 FlowFile의 콘텐츠가 존재하는 로컬 스토리지의 장소이며 일반적으로 세 개의 리포지토리 중 가장 크다. 이 리포지토리는 속도와 스레드 안전성을 최대화하기 위해 불변성과 Copy-On-Write 패러다임을 활용한다. Copy-On-Write란 수정 가능한 리소스에 대해서 복제 또는 복사 작업을 효율적으로 구현하기 위해 사용되는 리소스 관리 기술. 여기서의 핵심은 FlowFile의 콘텐츠를 디스크에 보관하고 필요할 때만 JVM 메모리로 읽어 들이는 것이다. 이를 통해 용량이 큰 데이터를 메모리 손상 없이 저장할 수 있게 된다.

 

Provenance Repository는 각 FlowFile의 history가 저장되는 곳이다. FlowFile을 생성하고 분기, 복제, 수정 등과 같은 FlowFile에 대한 이벤트가 발생할 때마다 새로운 Provenance 이벤트가 생성되는데 이러한 이벤트 데이터는 인덱싱되고 검색이 가능하다.

 

NiFi Clustering

 

등장 배경

  • 단일 서버에서 하나의 NiFi 인스턴스를 사용하는 것만으로는 다량의 데이터를 처리하기 어려움
  • 이를 해결하기 위해 여러 NiFi 서버에서 동일한 Data Flow를 실행하면 Data Flow를 변경하거나 업데이트 할 때마다 각 서버에 동일하게 적용시켜줘야 함 -> 각 서버를 개별적으로 모니터링해야 하기 때문에 관리 문제 발생

이러한 문제들을 해결하기 위한 기술이 바로 클러스터링이다.

클러스터링을 통해 단일 서버에서 처리하기 힘든 다량의 데이터를 병렬적으로 처리하게 되고 이를 손쉽게 관리할 수 있게 된다. 또한 단일 인터페이스로 DataFlow를 변경하고 모니터링해서 처리 능력도 향상되는 장점이 있다.

 

또한 Zero-Master Clustering을 채택해서 전체 클러스터가 동일한 작업을 수행하고 노드들에서 다루어지는 데이터는 Apache-Zookeeper를 통해 분산되어 처리된다. 이에 대한 설명은 밑에서 자세하게 설명하겠다.

 

그럼 여기서 'Clustering이 곧 HA인가' 라는 의문이 생길 수 있다. 내가 이해한 HA는 고장이 나도 계속 사용 가능하게 만드는 것인데, NiFi 클러스터에서는 노드 하나가 고장나면 해당 노드가 가지고 있던 FlowFile은 그대로 사라지게 때문에 클러스터링이 곧 HA는 아닌 것 같다. 하지만 만약 FlowFile을 저장하고 있는 Repository를 HDFS와 같은 외부의 분산 환경에 저장하고 FAILOVER 시 활용할 수 있도록 하면 HA를 할 수 있을 것 같다고 한다.

 
NiFi 클러스터링 구성

 

  • Cluster Coordinator : 각 NiFi 노드들의 정보(가동 여부, 상태)를 관리. 새로 추가된 노드들에게 최신의 flow 제공. DataFlow의 추가, 수정, 삭제 등의 변경을 클러스터에 등록된 다른 NiFi 노드들에게 복제
  • Primary Node : 모든 클러스터는 하나의 Primary Node를 가지며 이는 Zookeeper로부터 선출. 특정 프로세서를 여러 노드에서 동시에 실행되기를 원하는 않는 경우에는 특정 단일 노드에서만 실행 가능. 예를 들어 외부 네트워크로부터 데이터를 받아오는 Processor가 있다고 가정할 때, 모든 노드들이 해당 Processor를 실행하게 되면 경쟁 상태가 되는 문제가 발생할 수 있기 때문에 해당 Processor는 Primary Node에서만 사용할 수 있도록 하고 받은 데이터는 전체 노드에 나눠주어 병렬처리함
  • Zookeeper Server : Cluster Coordinator와 Primary Node는 Zookeepr Server에서 자동으로 선출. NiFi 1.0버전부터 Zero-Master Clustering이 적용되어 클러스터 내에서 NiFi 노드들 중 하나가 자동으로 Cluster Coordinator와 Primary Node가 되는데 이를 Zero-Master Cluster라고 함

 

  • Heartbeat : 각 노드들이 Coordinator에게 보내는 상태값. Coordinator가 클러스터에 여전히 연결되어 있고 정상적으로 작동하고 있음을 알려줌. 40초 동안 Heartbeat를 보내지 못하는 노드가 발생하면 Coordinator는 해당 노드를 클러스터에서 제외시킴. 각 노드별로 최신의 flow를 가지지 못하는 동기화 문제가 발생할 수 있기 때문. 만약 끊긴 노드가 다시 Hearbeat를 보내면 Coordinator가 해당 노드를 인식하고 다시 Cluster에 참여시킴.
  • Offload Nodes : 연결이 끊긴 노드에 남아 있는 FlowFile은 Offloading을 통해 클러스터의 다른 활성 노드로 재조정. Offloading 된 노드는 클러스터에 다시 연결하거나 삭제할 수 있음.

 

저작자표시 (새창열림)