Stateless NiFi 는 처리기(processor) 의 종류가 아니라 플로우를 돌리는 실행 엔진이 다른 것이다. 표준 NiFi 서버를 띄우지 않고, 데이터 흐름 하나를 하나의 라이브러리처럼 불러 한 번 실행한 뒤 끝낸다.
| 항목 | 표준 NiFi | Stateless |
|---|---|---|
| 실행 형태 | 상주 서버. 웹 UI 로 편집·감시 | 호출될 때 실행되고 끝난다. UI 없음 |
| FlowFile 저장 | 디스크 저장소(FlowFile · Content · Provenance Repository) | 메모리. 저장소를 쓰지 않는다 |
| 실패 처리 | 큐에 남아 있다가 재시도 | 트랜잭션 단위로 통째 성공 또는 통째 롤백 |
| 백프레셔 | 커넥션마다 임계치로 조절 | 큐가 디스크에 쌓이지 않으므로 해당 없음 |
| 확장 | 클러스터 노드를 늘린다 | 실행 인스턴스를 늘린다 |
| 어울리는 곳 | 장기 상주 수집·전송, 대용량 버퍼링 | 컨테이너·서버리스·Kafka Connect 형태의 단발 처리 |
여기서 "stateless" 는 처리 중간 상태를 디스크에 남기지 않는다는 뜻이다. UpdateAttribute 의 상태 저장이나 ListFile 의 커서 같은 컴포넌트 상태를 전혀 쓸 수 없다는 뜻은 아니다. 다만 상태 저장소를 외부에 두어야 하고, 실행이 끝나면 프로세스가 사라지므로 상태에 기대는 플로우는 잘 맞지 않는다.
표준 NiFi 에서는 처리기 사이의 큐가 중간 저장소 역할을 한다. 한 처리기가 실패해도 그 앞까지의 결과는 큐에 남아 있고, 실패한 FlowFile 만 failure 관계로 흘려보내면 된다.
Stateless 는 다르다. 데이터 하나를 입력에서 출력까지 끌고 가되, 중간에 실패하면 그 실행 전체를 되돌린다. 소스에서 읽은 내용을 커밋하지 않으므로 다음 실행에서 같은 데이터를 다시 읽는다. 결과적으로 "전부 처리되거나 아무것도 처리되지 않거나" 가 보장된다.
이 성질 때문에 Stateless 플로우는 짧고 단순하게 만든다. 한 실행에서 다루는 데이터량이 메모리에 들어가야 하므로, 대용량 파일을 한 덩어리로 밀어 넣는 용도에는 맞지 않는다.
NiFi 2 에서도 Stateless 는 별도 제품이 아니라 함께 배포되는 실행 방식이다. 쓰는 길이 세 가지다.
Stateless 쪽이 맞는 경우는 다음과 같다.
표준 NiFi 가 맞는 경우는 다음과 같다.