[NiFi] NiFi는 어떻게 데이터를 저장하나? (NiFi Repository)

nifi.apache.org/docs/nifi-docs/html/nifi-in-depth.html#repositories

Apache NiFi In Depth

 

NiFi에는 3가지 저장소Repository가 존재한다. 각각의 저장소는 OS/Host 레벨의 파일시스템에 저장이 되고, 특정한 데이터들을 저장하게 된다. FlowFile 에 대한 이해가 바탕이 되어야지만 이러한 저장소들의 역할들에 대해 완벽히 이해할 수 있다. 

NiFi Repository 종류

항상 나오는 NiFi 아키텍쳐. 하나의 JVM안에 WebServer, FlowController, Repository가 있다. 각 Repository는 local storage에 저장된다. 

1. FlowFile Repository : 현재 Flow 안에 존재하는 FlowFiles들에 대한 메타 정보들을 가지고 있음 
2. Content Repository : 현재/과거 FlowFiles 에 대한 데이터(contenets)를 가지고 있음 
3. Provenance Repository : FlowFiles들에 대한 이력정보를 가지고 있음 

---

FlowFile Repository 

NiFi에서 처리되고 있는 flowfile들은 Hash Map 형태로 JVM 메모리에 존재하게 된다. (nifi.apache.org/docs/nifi-docs/html/nifi-in-depth.html#DeeperView). 메모리에서 처리하는 것은 빠르고 효율적임이지만, 장애 발생 시 데이터에 대한 지속성을 보장하지 않아 데이터 손실을 가져온다. (durability 를 보장할 수 없다). 이러한 문제를 해결하기 위해서 FlowFile Repository는 현재 시스템에서 처리되고 있는 FlowFile의 메타정보/데이터에 대한 WAL(Write-Ahead Log)역할을 수행한다.  FlowFile의 메타 정보는 FlowFile과 관련된 모든 속성들을 가지고 있는데,  실제 FlowFile에 데이터의 위치(실제 데이터는 Content Repository에 존재), FlowFile의 상태(어떤 connection/queue에 존재하는지) 등을 포함한다. WAL과 같은 기능을 제공함으로써 FlowFile Repository를 통해 시스템 장애로 인한 지속성을 제공하게 된다. 

FlowFile이 NiFi의 여러 Processor를 통해 처리됨에 따라 WAL과 동일하게 변경사항들이 FlowFile Repository에 저장이 되고 트랜잭션이 처리가된다. (WAL 저장 후 트랜잭션 처리, 이슈 발생 시 WAL 을 이용한 데이터 복구 수행). 이렇게 생성되는 로그(WAL)은 변경사항들에 대한 순차적인 모음임으로 NiFi는 이를 통해서 Repository가 check-point 될 때 생성되는 snapshot을 기준으로 로그에 기록된 작업을 수행하여 장애 시점의 FlowFile을 복구할 수 있게된다. 

FlowFile Snapshot은 시스템에 의해서 주기적으로 생성되는데 nifi.properteis 파일을 통해서 checkpoint에 대한 설정을 할 수 있다. checkpoint 시점에 시스템은 FlowFile의 HashMap을 직렬화 하여 새로운 생성하는데, 이는 *.partial 확장자를 갖는 파일로 생성된다. checkpoint 작업이 완료되면 오래된 snapshot 파일은 삭제되고 *.partial 파일이 snapshot으로 이름이 변경된다. 

---

Content Repository 

Content Repository는 단순하게 시스템에 존재하는 모든 FlowFile들에 대한 데이터(content)를 저장하고 있는 로컬 스토리지라고 생각하면 되는데, 실제 FlowFiles에 대한 데이터를 저장하기 때문에 위에서 언급한 3개의 저장소 중에 가장 큰 저장 공간을 사용하게 된다. 이 저장소는 처리 속도 극대화/thread 처리에 대한 안정성을 위해 불변성immutability과 copy-on-write 패러다임을 사용한다. Content Repository의 핵심 디자인은 Flowfile에 대한 데이터를 disk에 유지하면서 JVM 메모리에서 요청할 때만 read only로 적재하게 된다. 이러한 구조는 처리하고자 하는 object의 크기의 크기와 상관 없이 처리할 수 있게 되는데, 모든 데이터를 memory에 올리기 위한 pub/sub 이 필요하지 않기 때문이다. 결과적으로 매우 큰 object에 대해서 splitting, aggregating, transforming 작업을 수행할 때 메모리 사용량과 무관하게 처리할 수 있게 된다. (대신에 content repository에 대한 disk I/O 성능이 더 중요해질 것으로 생각된다.) 

NiFi는 사용하지 않는 FlowFile에 대한 데이터는 GC를 통해 JVM heap에서 제거하는 작업을 수행하며, 이를 위해 별도의 GC collection 프로세스가 존재하며, 사용하지 않는 content를 분석하기 위한 thread가 별도로 존재한다. ( Deeper View: Deletion After Checkpointing" section) 이러한 작업들을 통해 FlowFile의 contents 가 더이상 필요하지 않다고 판단되면 삭제되거나 아카이빙된다. 아카이빙archiving 관련 설정은 nifi.properties에서 활성화 시킬 수 있다. archiving처리된 content는 Content Repository에 정의된 life-cycle(age)만큼 존재하다가 삭제가 되거나, Content Repository가 너무 많은 데이터를 사용하고 있다고 할 때에는 바로 삭제가 될 것이다. ("nifi.content.repository.archive.max.retention.period", "nifi.content.repository.archive.max.usage.percentage")

---

Provenance Repository 

Provenance Repository는 FlowFile에 대한 이력 정보를 위한 저장소이다. 이력정보는 각 데이터에 대한 Data Lineage를 제공하기 위해서 사용된다. FlowFile에 대한 이벤트가 발생할 때마다 새로운 provenance event(기원 이벤트..) 가 생성된다. Provenance event 또한 FlowFile의 특정 시점의 정보를 보여주는 snapshot로 생각할 수도 있다. provenance event가 생성되면 FlowFile의 모든 속성값과 content를 가리키는 포인터,  FlowFile의 상태 정보에 대한 집계정보가 Provenance Repository의 하나의 위치에 저장이 된다. 이러한 provenance event(=snapshot)은 변경되지 않으며 nifi.properties 에 명시된 일정이 지난 후에 삭제된다. 

FlowFile의 모든 속성들과 content 포인터는 Provenance Repository에 저장되기 때문에 DataFlow Manager는 단순히 lineage를 보는 것이 아니라 데이터에 대한 처리이력을 확인할 수 있다. 이를 통해 특정 시점의 데이터를 확인할 수 있을 뿐 아니라 어떠한 위치에서든 다시 실행할 수 있다. 일반적으로 usecase는 데이터를 전송 받는 시스템(down-stream system)이 데이터를 받지 못한 경우인데, 목적 시스템에 데이터가 전송 될때 정확히 데이터가 어떠한 모습인지 파일이름은 무엇인지, URL은 무엇인지 확인이 가능하다. 또는 전송 이벤트가 다시 실행될 수 있어 목적시스템에서 데이터를 받게 처리할 수 있다. 만약 데이터가 원하는데로 처리되지 않았다면, flow를 수정한 뒤에 다시 데이터를 수정된 flow로 흘리는것도 가능하다. 

Provenance Repository를 통해서 특정 시점의 FlowFile의 데이터를 확인 가능하지만, Content Repository에 대한 데이터를 복사하는 것은 아니다. 단지 FlowFile의 content에 대한 포인터를 복사하여 가지고 있는 것이다. 따라서 Provenance event에서 참조값을 가지고 있는 상태에서 content가 삭제될 수도 있다. 이런 경우에는 앞서 말했던 특정 시점의 FlowFile의 데이터를 본다던가 FlowFile을 재처리하는 작업들이 수행 불가능하게된다. 하지만 사용자는 FlowFile에 대한 lineage 자체는 조회가 가능함으로 데이터가 처리된 프로세스들은 확인할 수 있다. 예를들어, 이 경우 사용자는 실제 데이터는 확인하지 못하지만 데이터가 사용한 고유 식별자 및 파일 명과 같은 데이터는 확인할 수 있음으로 그것의 목적 시스템으로의 전송여부를 확인할 수 있다. 또한 다른 FlowFile에 대한 메타 정보는 가지고 있음으로 속성값을 통한 디버깅 작업을 수행할 수도 있다. 

참고. Provenance event는 FlowFile의 snapshot과 같은 역할을 하기 때문에 현재 flow에 존재하는 FlowFile에 대한 변경은 provenance event를 나중에 재수행할 때 영향을 끼치게 된다. (FlowFile의 데이터가 같다고 하더라도 flow가 변경되면 당연히 처리 결과가 달라짐을 인지하고 있어야 한다) 

 

---

대략적인 NiFi에 대한 이해를 돕기 위해 NiFi에 존재하는 저장소를 확인해 보았다. 이를 통해 실제로 FlowFile에 대한 이해가 더 넓어진 것 같은 느낌이 든다. 각 Repository에서 수행되는 NiFi 메커니즘에 대해서 더 깊게 확인해 볼 필요가 있을 것으로 보인다.