개요

회사에서 사용하는 NIFI에 대한 소개글 원문 을 구글번역 후 포맷을 정리하여 포스팅 한다.

번역 중 너무 이상한 부분은 수정하였다. 또한 이미지는 원본글을 참조하였다.

내용중 추가 설명이 필요한 부분은 [] 표시로 원본글이 글 맨 하단에 References로 정리되어 있다.

What is Apache NiFi?

NiFi는 시스템 간의 데이터 흐름을 자동화하기 위해 만들어졌습니다. 데이터 흐름이라는 용어는 다양한 문맥에서 사용되지만 여기서는 시스템간에 자동화되고 관리되는 정보의 흐름을 의미합니다. 이 문제는 기업이 하나 이상의 시스템을 보유하고있어 시스템의 일부가 데이터를 생성하고 일부 시스템은 데이터를 사용했기 때문에 그 어느 때보 다 많은 문제가있었습니다. 출현 한 문제와 해결 방안은 광범위하게 논의되고 명확하게 논의되었습니다. 엔터프라이즈 통합 패턴 [eip]에는 포괄적이며 쉽게 사용되는 양식이 있습니다.

데이터 흐름의 상위 과제 중 일부는 다음과 같습니다.

시스템 실패

네트워크가 실패하고, 디스크가 실패하고, 소프트웨어가 충돌하고, 사람들이 실수를 저 지르게됩니다.

데이터 액세스가 소비 할 수있는 용량을 초과합니다.

때로는 주어진 데이터 소스가 처리 또는 전달 체인의 일부를 초과 할 수 있습니다. 단 하나의 약 링크 만 있으면 문제가 발생할 수 있습니다.

경계 조건은 단순한 제안 일뿐입니다.

여러분은 너무 크거나, 너무 작거나, 너무 빠르거나, 너무 느리거나, 부패하거나, 잘못되었거나 틀린 형식의 데이터를 일정하게 얻습니다.

언젠가는 소음이 신호가됩니다.

조직의 우선 순위가 빠르게 바뀝니다. 새로운 플로우를 활성화하고 기존 플로우를 변경하는 것이 빠 르다.

시스템은 다른 속도로 발전합니다.

주어진 시스템에서 사용되는 프로토콜 및 형식은 언제든지 변경할 수 있으며 종종 주변 시스템과 관계없이 변경 될 수 있습니다. 본질적으로 거대하게 분산 된 구성 요소 시스템을 연결하기 위해 데이터 흐름이 존재합니다. 느슨하게 또는 전혀 작동하지 않도록 설계되었습니다.

규정 준수 및 보안

법률, 규정 및 정책이 변경됩니다. B2B 계약이 변경됩니다. 시스템 대 시스템 및 시스템 간 상호 작용은 안전하고 신뢰할 수 있으며 책임이 있어야합니다.

지속적인 개선이 생산에서 발생합니다.

이제는 실험적으로 상용 환경을 복제하는 것조차 거의 불가능합니다.

수년에 걸쳐 데이터 흐름은 아키텍처에서 필요한 악의 하나였습니다. 이제는 데이터 흐름을 훨씬 더 흥미롭고 특정 기업의 성공에 훨씬 더 중요하게 만드는 많은 활동적이고 빠르게 진화하는 움직임이 있습니다. 여기에는 다음과 같은 것들이 포함됩니다. API [api] [api2], Internet of Things [iot], 빅 데이터 [bigdata]의 등장 인 서비스 지향 아키텍처 [soa]. 또한 규정 준수, 개인 정보 보호 및 보안에 필요한 엄격함 수준이 끊임없이 증가하고 있습니다. 이러한 새로운 개념이 모두 등장하더라도 여전히 데이터 흐름의 패턴과 요구 사항은 거의 동일합니다. 가장 큰 차이점은 복잡성의 범위, 적응에 필요한 변화율, 규모면에서 엣지 케이스가 공통적으로 발생한다는 것입니다. NiFi는 이러한 최신 데이터 흐름 문제를 해결할 수 있도록 제작되었습니다.

The core concepts of NiFi

NiFi의 근본적인 설계 개념은 Flow Based Programming [fbp]의 주요 아이디어와 밀접한 관련이 있습니다. 다음은 주요 NiFi 개념과 FBP에 매핑되는 방법입니다.

[seda]와 유사한 디자인 모델은 NiFi가 강력하고 확장 가능한 데이터 흐름을 구축하는 데 매우 효과적인 플랫폼이 될 수 있도록 많은 유익한 결과를 제공합니다. 몇 가지 이점은 다음과 같습니다.

• 프로세서의 방향 그래프의 시각적 생성 및 관리에 도움이됩니다.

• 본질적으로 비동기식으로 프로세싱 및 유량이 변동하더라도 매우 높은 처리량과 자연적 버퍼링을 허용합니다.

• 개발자가 동시성의 일반적인 복잡성에 대해 걱정할 필요없이 고도의 동시 모델을 제공합니다.

• 응집력이 있고 느슨하게 결합 된 구성 요소의 개발을 촉진하여 다른 상황에서 재사용 할 수 있으며 시험 가능한 단위를 촉진합니다.

• 리소스가 제한된 연결로 인해 배압 및 압력 방출과 같은 중요한 기능이 매우 자연스럽고 직관적입니다.

• 오류 처리는 거칠게 모든 예외를 다 잡아버리는 방법보다는 좀 더 자연스럽게 처리됩니다.

• 데이터가 시스템으로 들어오고 나가는 지점과 흐름을 잘 이해하고 쉽게 추적 할 수 있습니다.

NiFi Architecture

NiFi는 호스트 운영 체제의 JVM 내에서 실행됩니다. JVM에서 NiFi의 기본 구성 요소는 다음과 같습니다.

웹 서버

웹 서버의 목적은 NiFi의 HTTP 기반 명령 및 제어 API를 호스팅하는 것입니다.

유량 컨트롤러

흐름 컨트롤러는 작업의 두뇌입니다. 확장 기능을위한 스레드를 제공하고 확장 기능이 실행될 일정을 관리합니다.

확장 기능

다른 문서에 설명 된 다양한 유형의 NiFi 확장이 있습니다. 요점은 확장이 JVM 내에서 작동하고 실행된다는 것입니다.

FlowFile 저장소

FlowFile Repository는 NiFi가 흐름에서 현재 활성화되어있는 특정 FlowFile에 대해 알고있는 상태를 추적하는 곳입니다. 저장소의 구현은 플러그 가능합니다. 기본 접근 방식은 지정된 디스크 파티션에있는 영구 Write-Ahead Log입니다.

컨텐츠 저장소

컨텐츠 저장소는 주어진 FlowFile의 실제 컨텐츠 바이트가있는 곳입니다. 저장소의 구현은 플러그 가능합니다. 기본 접근법은 파일 시스템에 데이터 블록을 저장하는 매우 간단한 메커니즘입니다. 단일 볼륨에서의 경합을 줄이기 위해 다른 물리적 파티션을 사용하기 위해 둘 이상의 파일 시스템 저장 위치를 ​​지정할 수 있습니다.

Provenance Repository

Provenance Repository는 모든 출처 이벤트 데이터가 저장되는 곳입니다. 저장소 구조는 하나 이상의 실제 디스크 볼륨을 사용하는 기본 구현과 함께 플러그 가능합니다. 각 위치 이벤트 내에서 데이터가 색인되고 검색 가능합니다.
NiFi는 클러스터 내에서 작동 할 수도 있습니다.

NiFi 1.0 릴리스부터 Zero-Master Clustering 패러다임이 채택되었습니다. NiFi 클러스터의 각 노드는 데이터에 대해 동일한 작업을 수행하지만 각각 다른 데이터 집합에서 작동합니다. Apache ZooKeeper는 단일 노드를 클러스터 코디네이터로 선택하고 장애 조치는 ZooKeeper에 의해 자동으로 처리됩니다. 모든 클러스터 노드는 하트 비트 및 상태 정보를 클러스터 코디네이터에게보고합니다. 클러스터 코디네이터는 노드의 연결을 끊고 연결합니다. 또한 모든 클러스터에는 ZooKeeper가 선출 한 하나의 기본 노드가 있습니다. DataFlow 관리자는 모든 노드의 사용자 인터페이스 (UI)를 통해 NiFi 클러스터와 상호 작용할 수 있습니다. 변경 한 내용은 클러스터의 모든 노드에 복제되므로 여러 개의 진입 점이 허용됩니다.

Performance Expectations and Characteristics of NiFi

NiFi는 작동중인 기본 호스트 시스템의 기능을 최대한 활용하도록 설계되었습니다. 이러한 리소스의 최대화는 CPU 및 디스크와 관련하여 특히 강력합니다. 추가 세부 사항은 관리 안내서의 모범 사례 및 구성 팁을 참조하십시오.

IO 용

예상되는 처리량 또는 대기 시간은 시스템 구성 방법에 따라 크게 달라집니다. 주요 NiFi 하위 시스템의 대부분에 대해 플러그 방식으로 접근 할 수 있다고 가정하면 성능은 구현에 따라 다릅니다. 그러나 구체적이고 광범위하게 적용 할 수있는 것이면 즉시 사용할 수있는 기본 구현을 고려하십시오. 이것들은 모두 배달 보장으로 영구적이며 로컬 디스크를 사용합니다. 보수적이기 때문에 일반 서버의 적당한 디스크 또는 RAID 볼륨에서 약 50MB / s의 읽기 / 쓰기 속도를 유지하십시오. 데이터 흐름의 대형 클래스를위한 NiFi는 초당 100MB 이상의 처리량에 효율적으로 도달 할 수 있어야합니다. 이는 NiFi에 추가 된 각 물리적 파티션과 콘텐츠 저장소에 대한 선형 성장이 예상되기 때문입니다. 이것은 FlowFile 저장소와 출처 저장소의 어느 지점에서 병목 현상을 일으킬 수 있습니다. 우리는 빌드에 포함 할 벤치 마크 및 성능 테스트 템플릿을 제공하여 사용자가 자신의 시스템을 쉽게 테스트하고 병목 현상이 발생한 지점과 중단 지점을 파악할 수 있도록 할 계획입니다. 또한이 템플리트는 시스템 관리자가 변경하고 영향을 확인하기 쉽도록해야합니다.

CPU의 경우

플로우 컨트롤러는 특정 프로세서에 실행할 스레드가 주어질 때 엔진이 지시하는 역할을합니다. 프로세서는 태스크 실행이 끝나자 마자 스레드를 리턴하도록 작성됩니다. 플로우 컨트롤러는 유지하는 다양한 스레드 풀에 대해 사용 가능한 스레드를 나타내는 구성 값을 제공받을 수 있습니다. 이상적인 스레드 수는 코어 수, 시스템이 다른 서비스를 실행 중인지 여부, 플로우에서의 처리 특성과 관련하여 호스트 시스템 자원에 따라 다릅니다. 일반적인 I / O 흐름의 경우 수십 개의 스레드를 사용할 수있는 것이 합리적입니다.

RAM의 경우

NiFi는 JVM 내에 존재하므로 JVM이 제공하는 메모리 공간으로 제한됩니다. JVM 가비지 콜렉션은 전체 실제 힙 크기를 제한하고 시간이 지남에 따라 애플리케이션이 얼마나 잘 실행되는지를 최적화하는 데 매우 중요한 요소가됩니다. 동일한 컨텐츠를 정기적으로 읽을 때 NiFi 작업은 I / O 집중적 일 수 있습니다. 성능을 최적화 할만큼 충분한 디스크를 구성하십시오.

High Level Overview of Key NiFi Features

이 섹션에서는 NiFi의 기본 원리에 대해 2 만 피트 뷰를 제공하므로 Apache NiFi의 큰 그림과 그 중 가장 흥미로운 기능을 이해할 수 있습니다. 주요 기능 범주에는 흐름 관리, 사용 편의성, 보안, 확장 가능 아키텍처 및 유연한 확장 모델이 포함됩니다.

흐름 관리

보장 된 배달

NiFi의 핵심 철학은 매우 높은 수준에서도 보장 된 배송이 필수적이라는 것입니다. 이는 특수 목적으로 작성된 영구적 인 미리 쓰기 로그 및 컨텐츠 저장소를 효과적으로 사용하여 수행됩니다. 이들은 매우 높은 트랜잭션 속도, 효과적인로드 분산, 카피시 쓰기 및 기존 디스크 읽기 / 쓰기의 강점을 고려한 방식으로 설계되었습니다.

배압 및 압력 해제 기능이있는 데이터 버퍼링

NiFi는 대기중인 모든 데이터의 버퍼링과 대기열이 지정된 제한에 도달 할 때 역 압력을 제공하거나 지정된 연령 (값이 소진 됨)에 도달하면 데이터를 제거하는 기능을 지원합니다.

우선 순위 대기열

NiFi는 대기열에서 데이터를 검색하는 방법에 대한 하나 이상의 우선 순위 체계를 설정할 수있게합니다. 기본값은 가장 오래된 것이 가장 오래되었지만 가장 먼저 데이터를 가져온 후 가장 먼저 데이터를 가져 오거나 다른 사용자 정의 구성표를 가져와야하는 경우가 있습니다.

플로우 특정 QoS (대기 시간 v 처리량, 손실 허용 등)

데이터가 절대적으로 중요하고 손실을 견디지 않는 데이터 흐름 포인트가 있습니다. 또한 처리해야하고 몇 초 안에 전달되어야하는 경우도 있습니다. NiFi를 사용하면 이러한 문제에 대한 세분화 된 흐름 특정 구성이 가능합니다.

사용의 용이성

시각적 명령 및 제어

데이터 흐름이 상당히 복잡해질 수 있습니다. 이러한 흐름을 시각화하고 시각적으로 표현할 수 있다면 복잡성을 줄이고 단순화해야 할 영역을 식별하는 데 크게 도움이 될 수 있습니다. NiFi는 데이터 흐름을 시각적으로 설정할 수있을뿐만 아니라 실시간으로도 가능합니다. 디자인과 배치보다는 점토 성형과 훨씬 비슷합니다. 변경 한 데이터 흐름을 즉시 변경하면 즉시 적용됩니다. 변경 사항은 세분화되어 영향을받는 구성 요소로 격리됩니다. 특정 변경을하기 위해 전체 플로우 또는 플로우 세트를 중지 할 필요는 없습니다.

흐름 템플릿

데이터 흐름은 패턴 지향적 인 경향이 있으며 문제를 해결할 수있는 여러 가지 방법이 있지만 그 모범 사례를 공유하는 것이 크게 도움이됩니다. 템플리트를 사용하면 주제 전문가가 흐름 설계를 작성하고 게시하고 다른 사람들이 혜택을 얻고 협업 할 수 있습니다.

데이터 출처

NiFi는 팬 인 (fan-in), 팬 아웃 (fan-out), 변환 (transformations)을 넘어서도 객체를 통해 시스템이 흐름에 따라 자동으로 기록, 색인 생성 및 사용 가능한 데이터를 생성합니다. 이 정보는 규정 준수, 문제 해결, 최적화 및 기타 시나리오 지원에 매우 중요합니다.

세밀한 기록의 롤링 버퍼 복구 / 기록

NiFi의 컨텐츠 저장소는 역사의 롤백 버퍼 역할을하도록 설계되었습니다. 데이터는 컨텐츠 저장소가 오래되거나 공간이 필요할 때만 제거됩니다. 데이터 출처 기능과 결합 된이 기능은 클릭주기, 콘텐츠 다운로드 및 재생을 가능하게하는 매우 유용한 기초를 제공합니다. 모든 부분은 세대 간 스팬 할 수있는 개체 라이프 사이클의 특정 시점에 있습니다.

보안

시스템 대 시스템

데이터 흐름은 보안 수준만큼 우수합니다. 데이터 흐름의 모든 지점에서 NiFi는 양방향 SSL과 같은 암호화 된 프로토콜을 사용하여 안전한 교환을 제공합니다. 또한 NiFi는 흐름을 통해 콘텐츠를 암호화 및 해독하고 공유 키 또는 다른 메커니즘을 보낸 사람 /받는 사람 방정식의 양쪽에서 사용할 수 있습니다.

사용자 대 시스템

NiFi는 양방향 SSL 인증을 가능하게하고 사용자의 액세스 및 특정 수준 (읽기 전용, 데이터 흐름 관리자, 관리자)을 적절하게 제어 할 수 있도록 플러그 가능한 권한을 제공합니다. 사용자가 암호와 같은 민감한 속성을 흐름에 입력하면 즉시 서버 측에서 암호화되고 암호화 된 형식으로도 클라이언트 측에서 다시 노출되지 않습니다.

다중 사용자 인증

주어진 데이터 흐름의 권한 수준은 각 구성 요소에 적용되므로 관리자는 세분화 된 수준의 액세스 제어 권한을 가질 수 있습니다. 즉, 각 NiFi 클러스터는 하나 이상의 조직의 요구 사항을 처리 할 수 ​​있습니다. 격리 된 토폴로지와 비교할 때 멀티 테넌트 권한 부여는 데이터 흐름 관리를위한 셀프 서비스 모델을 가능하게하므로 각 팀 또는 조직은 액세스 권한이없는 나머지 흐름을 완전히 인식하여 흐름을 관리 할 수 ​​있습니다.

확장 가능한 아키텍처

신장

NiFi는 확장을 위해 구축 된 핵심 부분이며 데이터 흐름 프로세스가 예측 가능하고 반복 가능한 방식으로 실행되고 상호 작용할 수있는 플랫폼입니다. 확장 포인트에는 프로세서, 컨트롤러 서비스,보고 작업, 우선 순위 지정자 및 고객 사용자 인터페이스가 포함됩니다.

클래스 로더 격리

구성 요소 기반 시스템의 경우 종속성 문제가 신속하게 발생할 수 있습니다. NiFi는 맞춤 클래스 로더 모델을 제공하여이 문제를 해결하여 각 확장 번들이 매우 제한된 종속성 집합에 노출되도록합니다. 따라서 확장 프로그램이 다른 확장 프로그램과 충돌 할 수 있는지에 대한 염려없이 확장 프로그램을 빌드 할 수 있습니다. 이러한 확장 번들의 개념을 NiFi Archives라고하며 Developer ‘s Guide에서 더 자세히 설명합니다.

사이트 간 통신 프로토콜

NiFi 인스턴스간에 선호되는 통신 프로토콜은 NiFi 사이트 투 사이트 (S2S) 프로토콜입니다. S2S를 사용하면 하나의 NiFi 인스턴스에서 다른 인스턴스로 데이터를 쉽고 효율적으로 안전하게 전송할 수 있습니다. NiFi 클라이언트 라이브러리는 S2S를 통해 NiFi와 다시 통신 할 수 있도록 다른 응용 프로그램이나 장치에 쉽게 구축하고 번들로 제공 할 수 있습니다. 소켓 기반 프로토콜과 HTTP (S) 프로토콜 모두 S2S에서 기본 전송 프로토콜로 지원되므로 프록시 서버를 S2S 통신에 내장 할 수 있습니다.

유연한 확장 모델

스케일 아웃 (클러스터링)

NiFi는 위에서 설명한대로 여러 노드를 함께 클러스터링하여 확장 할 수 있도록 설계되었습니다. 하나의 노드가 프로비저닝되어 초당 수백 MB를 처리하도록 구성된 경우 겸손한 클러스터가 초당 GB를 처리하도록 구성 될 수 있습니다. 그러면 NiFi와 데이터를 가져 오는 시스템간에로드 밸런싱 및 페일 오버의 흥미로운 문제가 발생합니다. 메시징 서비스, 카프카 (Kafka) 등과 같은 비동기 대기열 기반 프로토콜을 사용하면 도움이됩니다. NiFi의 사이트 투 사이트 기능은 NiFi와 클라이언트 (다른 ​​NiFi 클러스터 포함)가 서로 대화하고, 로딩에 대한 정보를 공유하고, 인증 된 특정 포트에서 데이터를 교환 할 수있게 해주는 프로토콜이기 때문에 매우 효과적입니다.

스케일 업 & 다운

NiFi는 또한 매우 유연하게 스케일 업 및 스케일 다운하도록 설계되었습니다. NiFi 프레임 워크의 관점에서 처리량을 증가시키는 관점에서, 구성시 스케줄링 탭에서 프로세서의 동시 작업 수를 늘릴 수 있습니다. 이를 통해 더 많은 프로세스를 동시에 실행할 수 있으므로 처리량이 향상됩니다. 다른 측면에서, 하드웨어 리소스가 제한되어 있기 때문에 작은 풋 프린트가 필요한 에지 장치에서 NiFi를 완벽하게 확장하여 사용할 수 있습니다. 첫 번째 마일 데이터 수집 과제 및 엣지 유스 케이스를 구체적으로 해결하기 위해 Apache NiFi, MiNiFi의 자식 프로젝트 노력에 대한 자세한 내용은 https://cwiki.apache.org/confluence/display/NIFI/MiNiFi에서 확인할 수 있습니다.

References

• [eip] Gregor Hohpe. Enterprise Integration Patterns [online]. Retrieved: 27 Dec 2014, from: http://www.enterpriseintegrationpatterns.com/
• [soa] Wikipedia. Service Oriented Architecture [online]. Retrieved: 27 Dec 2014, from: http://en.wikipedia.org/wiki/Service-oriented_architecture
• [api] Eric Savitz. Welcome to the API Economy [online]. Forbes.com. Retrieved: 27 Dec 2014, from: http://www.forbes.com/sites/ciocentral/2012/08/29/welcome-to-the-api-economy/
• [api2] Adam Duvander. The rise of the API economy and consumer-led ecosystems [online]. thenextweb.com. Retrieved: 27 Dec 2014, from: http://thenextweb.com/dd/2014/03/28/api-economy/
• [iot] Wikipedia. Internet of Things [online]. Retrieved: 27 Dec 2014, from: http://en.wikipedia.org/wiki/Internet_of_Things
• [bigdata] Wikipedia. Big Data [online]. Retrieved: 27 Dec 2014, from: http://en.wikipedia.org/wiki/Big_data
• [fbp] Wikipedia. Flow Based Programming [online]. Retrieved: 28 Dec 2014, from: http://en.wikipedia.org/wiki/Flow-based_programming#Concepts
• [seda] Matt Welsh. Harvard. SEDA: An Architecture for Highly Concurrent Server Applications [online]. Retrieved: 28 Dec 2014, from: http://www.eecs.harvard.edu/~mdw/proj/seda/