[Nifi] Administration Guide 공부 필기

 

아래 가이드에서 현재 나에게 중요하거나 알아둬야겠다고 생각하는 부분만 여기 적는다.

 

 

nifi.apache.org/docs/nifi-docs/html/administration-guide.html

NiFi System Administrator’s Guide

 

 

NiFi 에서 사용하는 HTTP, HTTPS port 는 다음과 같으며, nifi.properties 에서 수정 가능

 

HTTP : nifi.web.http.port : 8080

HTTPS : nifi.web.https.port : 9443

 

 

 

 

NiFi 는 많은 수의 파일을 열고, 또 많은 수의 threads 를 생성하기 때문에

Linux 에서 NiFi 사용시, /etc/security/limits.conf 의 nofile, nproc 값을 늘리는 것이 좋다고 함.

*  hard  nofile  50000 *  soft  nofile  50000 *  hard  nproc  10000 *  soft  nproc  10000

여기서 말하는 nproc 과 nofile 은 다음을 의미함

- nproc : User당 사용할 수 있는 프로세스 최대 개수
- nofile : User당 오픈할 수 있는 파일 개수 (리눅스에서는 모든 개체를 파일로 봅니다.)

(출처 : www.cubrid.com/blog/3825019 )

 

또한 NiFi 가 사용중인 메모리가 swapping 되지 않도록 /etc/sysctl.conf 의 vm.swappiness 를 0으로 두는 것이 좋다.

vm.swappiness 에 대한 설명은 다음 링크 참고.

brunch.co.kr/@alden/14

간단하게 정리하면, 메모리 요청이 왔을 때, linux 에 유휴 메모리가 부족하다면

다른 곳에서 메모리를 가져오는데(이것을 메모리 재할당이라고 부름) 이 때 두 가지 방법을 통해 메모리를 가져온다.

1. page cache memory 를 가져옴

2. 기존 프로세스 (inactive process) 에 할당된 memory 를 가져옴

2번의 경우 swapping 이 발생하기 때문에 성능에 영향을 줄 수 있다.

2번 방법을 최대한 줄이고 1번 방법을 최대로 사용하도록 하는 것이 vm.swappiness 를 0으로 두는 것.

 

이 외에 NiFi 최적화(best practice)를 위한 정보들을 아래 문서에서 확인 가능

nifi.apache.org/docs/nifi-docs/html/administration-guide.html#configuration-best-practices

 

 

 

 

만약 백신을 사용한다면, 백신 검사할 때 NiFi 에서 사용하는 directories 는 제외하는 곳이 좋음.

왜냐하면 백신 검사시 해당 directory 를 잠그게 되는데

잠긴 동안 NiFi 가 해당 directory 에 접근할 수 없어 성능 및 안정성 문제가 발생하기 때문.

아래 directories 는 백신에서 제외시키자.

- content_repository - flowfile_repository - logs - provenance_repository - state

 

 

 

 

NiFi는 사용자 인증을 위해, 사용자 이름과 암호, OpenId Connect 또는 Apache Knox 을 구성할 수 있음.

대신 이들을 동시에 적용할 순 없음.

만약 위의 어느 것도 구성되지 않은 경우, HTTPS를 통해 사용자를 인증하기 위해 클라이언트 인증서를 요구한다고 함.

 

처음으로 보안 NiFi 인스턴스를 설정하는 경우, authorizers.xml 파일 에서 "Initial Admin Identity"를 수동으로 설정해야 함

설정된 Initial Admin 에게 WebUI에 대한 접근 권한이 부여되고,

추가적으로 사용자, 그룹 및 정책을 생성 할 수 있게 됨.

authorizers.xml 에 수동으로 설정 후, NiFi 재시작하면 Initial Admin Identity 설정한 부분을 기반으로

users.xml 과 authorizations.xml 에 내용이 추가됨.

 

자세한 내용은 아래 문서 참고

nifi.apache.org/docs/nifi-docs/html/administration-guide.html#initial-admin-identity

 

 

 

 

 

< Zero Leader Clustering >
NiFi는 Zero-Leader Clustering 패러다임을 사용함.

클러스터의 각 노드에는 동일한 Flow가 정의되고,

각 노드가 갖는 데이터에 대해 (Flow 대로) 동일한 작업을 수행

각각 다른 데이터 집합에서 작동함.

클러스터는 모든 활성 노드에 데이터를 자동으로 배포.

내가 이해하기로는 클러스터에 포함된 모든 활성 노드에 Flow 가 동기화되고,

그 Flow 대로 데이터를 움직이고 수정되고 작성되는 작업이 각 모든 활성 노드에서 일어남.

Apache ZooKeeper를 통해 노드 중 하나는 자동으로 클러스터 코디네이터로 선택.

클러스터의 모든 노드가 하트 비트 / 상태 정보를 코디네이터 노드로 보냄.

만약 코디네이터가 자신에게 일정 시간 동안 하트 비트를 보내지 않는 노드를 발견하면

해당 노드를 클러스터에서 끊어버림(연결을 끊음)

끊는 이유는, 클러스터 내 모든 노드가 동기화되어 있는지 확인해야하기 때문.

하트 비트가 오지 않는다? 이런 경우 노드 하나가 죽었다고 봄.

죽은 노드다? 그 죽은 노드는 동기화가 되지 않음.

동기화되지 않는다? 모든 노드간 데이터 및 flow 가 일정해지지 않음. 그래서 끊어버림.

 

반대로, 새로운 노드가 클러스터에 참여하려면, 먼저 코디네이터 노드에 연결을 함

그리고 나서 코디네이터가 "그래 들어와" 라고 허락해주면 (노드 참가를 결정하면)

현재 flow 가 새로운 노드에 제공됨.

코디네이터에 의해 제공된 flow 가 (만약 새로운 노드가 이미 flow 를 갖고 있다면) 새로운 노드의 flow 와 일치하면 클러스터에 참가됨.

반대로 코디네이터에 의해 제공된 flow 와 새로운 노드가 갖고 있는 flow 의 버전이 일치하지 않으면 참가가 안 됨(....)

(그럼 노드내 flow를 다 지우고 참가시켜야하나??

어디서 읽었는진 기억 안 나는데, 이런 경우 투표를 한다는 식으로 말하던데....)

 

참고 dzone.com/articles/apache-nifi-100-zero-master-clustering

 

 

 

 

 

< 왜 클러스터를 사용해야 하는가? >
eyeballs.tistory.com/311

 

 

< Primary Node >

primary node 는 독립 프로세서를 실행 가능한 노드임.

Zookeeper 에 의해 클러스터 내의 노드들 중 하나가 primary node 로 선출됨.

독립 프로세서는 일반 프로세서처럼 모든 노드에서 실행되지 않음.

독립 프로세서는 primary node 에서만 실행됨.

대개 독립 프로세서가 외부에서 데이터를 받아오고, 로드 밸런싱을 통해 받은 데이터를 각 노드로 뿌려주는 식으로 처리함.

 

어떤 프로세서들은 Primary 에서만 동작하도록 만드는 것이 추천되기도 함.

예를 들어 GetSFTP 의 경우, 모든 노드에서 실행되면, 모든 노드에서 경쟁적으로 외부서버로부터 데이터를 가져오게 되므로

바라지 않는 그림이 그려지게 됨.

따라서 Primary node 에서만 실행시키고,

가져온 데이터는 로드밸런싱을 하여 나머지 노드들에 뿌려주는 방법이 일반적으로 사용됨.

 

어떤 프로세서들은 무조건 Primary node 에서만 동작하도록 기본 설정이 되어있음.

 

 

 

 

< 클러스터 내 통신 >

 

노드들은 Zookeeper 의 ZNode 를 읽고 어떤 노드가 코디네이터인지 알게 됨.

그래서 코디네이터에게 하트비트를 보낼 수 있음.

 

사용자가 여러 노드 중 하나의 인터페이스에 접근하고, flow 를 변경을 요청하면,

변경 요청 내역이 모든 노드로 전달됨(아마 이때도 Zookeeper 가 도와주지 않을까 싶다)

그리고 모든 노드가 변경 요청 내역을 기반으로 업데이트를 진행하면

그제서야 사용자가 요청한 변경이 적용되어 사용자 눈에 변경된 것으로 보여지게 됨.

즉, nifi 변경은 모든 노드에서 동기화가 끝난 이후에 적용됨.

 

 

 

< 노드 관리 >

 

하트 비트가 오지 않는 등의 이유로 노드가 끊어질 수 있는데,

끊어진 동안에는 DFM 이 Flow 를 변경할 수 없음(동기화 문제 때문)

 

하지만 끊어진 동안에도 클러스터 내의 남아있는 노드들은 자기 할 일을 계속 함.

 

 

 

DFM 이 노드 연결을 임의로 해제 가능.

NiFi Cluster 에서 노드의 아래 아이콘을 클릭하면

노드 연결이 수동으로 끊어짐

끊어진 후에는 연결(콘센트 모양), 오프로드(나가는 모양), 삭제(휴지통 모양) 의 아이콘이 대신 생김

연결을 누르면 해당 노드가 다시 클러스터에 join 됨

오프로드를 누르면 모든 프로세서가 중지되고 종료되며, 모든 RPG 에서 전송이 중지되고 다른 연결된 노드로 FlowFile 균형이 재조정된다고 함. 

NiFi 를 재시작하면 Offload 된 노드가 Cluster에 다시 연결되어 join 가능

삭제를 누르면 해당 노드를 클러스터에서 완전히 삭제함.

그 후에서야 DFM 이 Flow 를 수정 가능.

 

 

A 노드가 offload 되었다고 하자.

그럼 A 노드가 처리하고 있던 Flowfile 은 offloading 을 통해 다른 살아있는 노드로 가서

작업을 계속하게 된다고 함.

offload 아이콘을 클릭하면 해당 노드가 offload 됨.

그러면 모든 프로세서가 중지된 후 종료됨

또한 원격 프로세스 그룹에서 전송이 중지됨.

그리고 클러스터 내의 다른 살아있는 노드로 Flowfile 이 뿌려지게 됨.

문서를 보면 Flowfile의 재조정(rebalancing)한다고 써있는데, 이게 round robin 처럼 균등하게 나눠진다는건지,

아니면 그냥 잘 동작하는 노드 하나에 몰빵한다는 건지 어떤게 맞는 건지는 아직 모르겠음.

 

 

 

 

NiFi 는 CLI 명령어를 통해서 노드 검색이나 노드 목록 쿼리, 노드 연결/해제/오프로드/삭제 등의 작업을 수행할 수 있음.

자세한 내용은 다음 문서 참고

nifi.apache.org/docs/nifi-docs/html/toolkit-guide.html#nifi_CLI

 

 

 

클러스터 내에 a,b,c,d 노드가 있고, e 노드가 새로 join 한다고 하자.

근데 e 노드는 이미 flow 를 가지고 있는 상태이다.

그럼 join 하기 전에 a,b,c,d 노드들의 flow 와 비교하게 됨.

a,b,c,d 노드들이 '올바른' flow 를 갖는 경우와 갖지 않는 경우가 있는데

만약 올바른 flow 를 이미 갖고 있다면 e 노드는

자신의 flow, 사용자/그룹 및 정책을 백업한다(flow.xml.gz.2021-01-01-..., users.xml, authorizations.xml 을 백업)

만약 올바른 flow 를 갖고있지 않다면, e 노드의 flow와 a,b,c,d 노드의 flow를 두고

투표를 하여 '올바른' flow 를 선정한다.

(내가 잘못이해하고 쓴 것일수 있으니 공식 문서를 다시 보자)

여기서 '올바른' flow 라고 하는 것은.. 아마 가장 최근에 업데이트된 flow? 혹은 사용자가 원하는 flow이지 않을까? 싶음.

 

 

 

 

 

아래 부분 이해 안 되서 넘어감

nifi.apache.org/docs/nifi-docs/html/administration-guide.html#state_management

 

 

 

bootstrap.conf 편집을 하여, NiFi 시작 방법을 설정할 수 있음

예를 들면 Java 힙크기, 실행할 Java 명령, Java 시스템 속성같은 매개 변수 등등.

 

NiFi 시작 또는 중지, 예기치 못한 종료 등의 상황을 감지하면 알람을 주도록 설정 가능.

알람은 email 과 http post 알림 두 가지 뿐임(....)

conf/bootstrap-notification-services.xml 혹은 conf/bootstrap.conf 파일에서 설정 가능

자세한 내용은 아래 문서 참고.

nifi.apache.org/docs/nifi-docs/html/administration-guide.html#notification_services

 

 

 

 

NiFi 업그레이드하는 방법 아래 링크 참고

Apache NiFi 업그레이드 : eyeballs.tistory.com/373

Docker NiFi 업그레이드 : eyeballs.tistory.com/374

 

 

 

사용자가 직접 만든 Processor 를 설치하고 자동으로 로드하는 방법은 아래 문서 참고

nifi.apache.org/docs/nifi-docs/html/administration-guide.html#processor-locations

이거 보기 전에 Processor 만드는 방법부터 알아야겠다...