Azure의 Apache NiFi

이 예제 시나리오에서는 Azure에서 Apache NiFi를 실행하는 방법을 보여줍니다. NiFi는 데이터를 처리하고 배포하는 시스템을 제공합니다.

Apache®, Apache NiFi® 및 NiFi®는 미국 및/또는 기타 국가에서 Apache Software Foundation의 등록 상표 또는 상표입니다. 이러한 표시의 사용은 Apache Software Foundation에 의한 보증을 암시하지 않습니다.

아키텍처

이 아키텍처의 Visio 파일을 다운로드합니다.

워크플로

• NiFi 애플리케이션은 NiFi 클러스터 노드의 VM에서 실행됩니다. VM은 구성이 가용성 영역에 배포하는 가상 머신 확장 집합에 있습니다.

• Apache ZooKeeper는 별도 클러스터의 VM에서 실행됩니다. NiFi에서 ZooKeeper 클러스터를 사용하는 용도는 다음과 같습니다.

  • 클러스터 코디네이터 노드를 선택하는 경우
  • 데이터 흐름을 조정하는 경우

• Azure Application Gateway는 NiFi 노드에서 실행되는 사용자 인터페이스에 대해 계층 7 부하 분산을 제공합니다.

• Monitor 및 해당 Log Analytics 기능은 NiFi 시스템에서 원격 분석을 수집, 분석 및 작동합니다. 원격 분석에는 NiFi 시스템 로그, 시스템 상태 메트릭 및 성능 메트릭이 포함됩니다.

• Azure Key Vault는 NiFi 클러스터에 대한 인증서와 키를 안전하게 저장합니다.

• Microsoft Entra ID는 SSO(Single Sign-On) 및 다단계 인증을 제공합니다.

구성 요소

• NiFi는 데이터를 처리하고 배포하는 시스템을 제공합니다.
• ZooKeeper는 분산 시스템을 관리하는 오픈 소스 서버입니다.
• Virtual Machines는 IaaS(Infrastructure-as-a-Service) 제품입니다. Virtual Machines를 사용하여 확장 가능한 주문형 컴퓨팅 리소스를 배포할 수 있습니다. Virtual Machines는 가상화의 유연성을 제공하지만 물리적 하드웨어의 유지 관리 요구를 제거합니다.
• Azure Virtual Machine Scale Sets는 부하가 분산된 VM 그룹을 관리하는 방법을 제공합니다. 집합의 VM 인스턴스 수는 수요 또는 정의된 일정에 따라 자동으로 증가하거나 감소할 수 있습니다.
• 가용성 영역은 Azure 지역 내의 고유한 물리적 위치입니다. 이러한 고가용성 제품은 데이터 센터 오류에서 애플리케이션 및 데이터를 보호합니다.
• Application Gateway는 웹 애플리케이션에 대한 트래픽을 관리하는 부하 분산 장치입니다.
• Monitor는 환경 및 Azure 리소스에 대한 데이터를 수집하고 분석합니다. 이 데이터에는 성능 메트릭 및 활동 로그와 같은 앱 원격 분석이 포함됩니다. 자세한 내용은 이 문서의 뒷부분에 있는 모니터링 고려 사항을 참조하세요.
• Log Analytics는 Monitor 로그 데이터에 대한 쿼리를 실행하는 Azure Portal 도구입니다. Log Analytics는 쿼리 결과를 차트로 작성하고 통계적으로 분석하는 기능도 제공합니다.
• Azure DevOps Services는 코딩 프로젝트 및 배포를 관리하기 위한 서비스, 도구 및 환경을 제공합니다.
• Key Vault는 API 키, 암호, 인증서 및 암호화 키와 같은 시스템의 비밀 정보에 대한 액세스를 안전하게 저장하고 제어합니다.
• Microsoft Entra ID는 Azure 및 기타 클라우드 앱에 대한 액세스를 제어하는 클라우드 기반 ID 서비스입니다.

대안

• Azure Data Factory는 이 솔루션에 대한 대안을 제공합니다.
• Key Vault 대신 비슷한 서비스를 사용하여 시스템 비밀 정보를 저장할 수 있습니다.
• Apache Airflow. 자세한 내용은 Airflow와 NiFi가 어떻게 다른지 참조하세요.
• Cloudera Apache NiFi와 같은 지원되는 엔터프라이즈 NiFi 대안을 사용할 수 있습니다. Cloudera 제품은 Azure Marketplace를 통해 사용할 수 있습니다.

시나리오 정보

이 시나리오에서 NiFi는 Azure Virtual Machines에서 확장 집합의 클러스터형 구성으로 실행됩니다. 그러나 이 문서의 권장 사항 대부분은 단일 VM(가상 머신)에서 단일 인스턴스 모드로 NiFi를 실행하는 시나리오에도 적용됩니다. 이 문서의 모범 사례는 확장 가능하고 고가용성이며 안전한 배포를 보여 줍니다.

잠재적인 사용 사례

NiFi는 데이터를 이동하고 데이터 흐름을 관리하는 데 적합합니다.

• 클라우드에서 분리된 시스템 연결
• Azure Storage 및 기타 데이터 저장소 내/외부로 데이터 이동
• 에지-클라우드 및 하이브리드-클라우드 애플리케이션을 Azure IoT, Azure Stack 및 AKS(Azure Kubernetes Service)와 통합

결과적으로 이 솔루션은 다음과 같은 여러 영역에 적용됩니다.

• MDW(최신 데이터 웨어하우스)는 구조화되고 구조화되지 않은 데이터를 대규모로 결합합니다. 다양한 원본, 싱크 및 형식에서 데이터를 수집하고 저장합니다. Azure 기반 MDW로 데이터를 수집할 때 NiFi가 탁월한 이유는 다음과 같습니다.

  • 데이터를 읽고, 쓰고, 조작하는 데 사용할 수 있는 프로세서가 200개가 넘습니다.
  • 이 시스템은 Azure Blob Storage, Azure Data Lake Storage, Azure Event Hubs, Azure Queue Storage, Azure Cosmos DB 및 Azure Synapse Analytics와 같은 Storage 서비스를 지원합니다.
  • 강력한 데이터 출처 기능을 통해 규정 준수 솔루션을 구현할 수 있습니다. Azure Monitor의 Log Analytics 기능에서 데이터 출처를 캡처하는 방법에 대한 자세한 내용은 이 문서의 뒷부분에 있는 보고 고려 사항을 참조하세요.

• NiFi는 공간이 작은 디바이스에서 독립 실행형으로 실행할 수 있습니다. 이러한 경우 NiFi를 사용하면 에지 데이터를 처리하고 해당 데이터를 클라우드의 더 큰 NiFi 인스턴스 또는 클러스터로 이동할 수 있습니다. NiFi는 동작 중인 에지 데이터를 필터링하고, 변환하고, 우선 순위를 지정하여 안정적이고 효율적인 데이터 흐름을 보장합니다.

• IIoT(산업용 IoT) 솔루션은 에지에서 데이터 센터로의 데이터 흐름을 관리합니다. 이러한 흐름은 산업 제어 시스템 및 장비에서 데이터를 획득하는 것으로 시작합니다. 그런 다음 데이터는 데이터 관리 솔루션 및 MDW로 이동합니다. NiFi는 데이터 획득 및 이동에 적합한 기능을 제공합니다.

  • 에지 데이터 처리 기능
  • IoT 게이트웨이 및 디바이스에서 사용하는 프로토콜 지원
  • Event Hubs 및 Storage 서비스와 통합

  예측 유지 관리 및 공급망 관리 영역의 IoT 애플리케이션은 이 기능을 사용할 수 있습니다.

권장 사항

이 솔루션을 사용할 때 다음 사항에 유의하세요.

NiFi의 권장 버전

Azure에서 이 솔루션을 실행하는 경우 1.13.2 이상의 NiFi 버전을 사용하는 것이 좋습니다. 다른 버전을 실행할 수 있지만 이 가이드의 구성과 다른 구성이 필요할 수 있습니다.

Azure VM에 NiFi를 설치하려면 NiFi 다운로드 페이지에서 편리한 이진 파일을 다운로드하는 것이 가장 좋습니다. 소스 코드에서 이진 파일을 빌드할 수도 있습니다.

ZooKeeper의 권장 버전

이 예제 워크로드의 경우 ZooKeeper 버전 3.5.5 이상 또는 3.6.x 버전을 사용하는 것이 좋습니다.

공식 편의 이진 파일 또는 소스 코드를 사용하여 Azure VM에 ZooKeeper를 설치할 수 있습니다. 둘 다 Apache ZooKeeper 릴리스 페이지에서 사용할 수 있습니다.

고려 사항

이러한 고려 사항은 워크로드의 품질을 향상시키는 데 사용할 수 있는 일단의 지침 원칙인 Azure Well-Architected Framework의 핵심 요소를 구현합니다. 자세한 내용은 Microsoft Azure Well-Architected Framework를 참조하세요.

NiFi 구성에 대한 자세한 내용은 Apache NiFi 시스템 관리자 가이드를 참조하세요. 또한 이 솔루션을 구현할 때는 이러한 고려 사항을 염두에 두어야 합니다.

비용 최적화

비용 최적화는 불필요한 비용을 줄이고 운영 효율성을 높이는 방법을 찾는 것입니다. 자세한 내용은 비용 최적화 핵심 요소 개요를 참조하세요.

• Azure 가격 계산기를 사용하여 이 아키텍처의 리소스 비용을 예측합니다.
• 사용자 지정 경고 솔루션을 제외하고 이 아키텍처의 모든 서비스를 포함하는 예상 비용은 이 샘플 비용 프로필을 참조하세요.

VM 고려 사항

다음 섹션에서는 NiFi VM을 구성하는 방법에 대한 세부 윤곽을 제공합니다.

VM 크기

이 표에는 시작할 권장 VM 크기가 제시되어 있습니다. 대부분의 범용 데이터 흐름에서 Standard_D16s_v3가 가장 좋습니다. 그러나 NiFi의 각 데이터 흐름에는 서로 다른 요구 사항이 있습니다. 흐름의 실제 요구 사항에 따라 흐름을 테스트하고 필요에 따라 크기를 조정합니다.

네트워크 성능을 높이기 위해 VM에서 가속화된 네트워킹을 사용하도록 설정하는 것이 좋습니다. 자세한 내용은 Azure 가상 머신 확장 집합에 대한 네트워킹을 참조하세요.

VM 크기	vCPU	메모리(GB)	MBps당 IOPS(초당 I/O 작업 수)에서 캐시되지 않은 최대 데이터 디스크 처리량*	최대 NIC(네트워크 인터페이스)/예상 네트워크 대역폭(Mbps)
Standard_D8s_v3	8	32	12,800/192	4/4,000
Standard_D16s_v3**	16	64	25,600/384	8/8,000
Standard_D32s_v3	32	128	51,200/768	8/16,000
Standard_M16m	16	437.5	10,000/250	8/4,000

* NiFi 노드에서 사용하는 모든 데이터 디스크에 대해 데이터 디스크 쓰기 캐싱을 사용하지 않도록 설정합니다.

** 대부분의 범용 데이터 흐름에 이 SKU를 사용하는 것이 좋습니다. 유사한 vCPU 및 메모리 구성을 사용하는 Azure VM SKU도 적절해야 합니다.

VM 운영 체제(OS)

다음 게스트 운영 체제 중 하나에서 Azure에 NiFi를 실행하는 것이 좋습니다.

• Ubuntu 18.04 LTS 이상
• CentOS 7.9

데이터 흐름의 특정 요구 사항을 충족하려면 다음 사항을 비롯한 여러 OS 수준 설정을 조정해야 합니다.

• 최대 포크된 프로세스입니다.
• 최대 파일 핸들입니다.
• 액세스 시간, atime.

예상된 사용 사례에 맞게 OS를 조정한 후 Azure VM Image Builder를 사용하여 튜닝된 이미지의 생성을 코드로 만듭니다. NiFi와 관련된 지침은 Apache NiFi 시스템 관리자 가이드의 구성 모범 사례를 참조하세요.

스토리지

세 가지 주요 이유로 OS 디스크가 아닌 데이터 디스크에 다양한 NiFi 리포지토리를 저장합니다.

• 흐름에는 단일 디스크가 충족할 수 없을 정도로 높은 디스크 처리량이 요구 사항에 있는 경우가 많습니다.
• NiFi 디스크 작업을 OS 디스크 작업과 분리하는 것이 가장 좋습니다.
• 리포지토리는 임시 스토리지에 있으면 안 됩니다.

다음 섹션에서는 데이터 디스크를 구성하기 위한 지침을 간략하게 설명합니다. 이러한 지침은 Azure에만 적용됩니다. 리포지토리 구성에 대한 자세한 내용은 Apache NiFi 시스템 관리자 가이드의 상태 관리를 참조하세요.

데이터 디스크 유형 및 크기

NiFi에 대한 데이터 디스크를 구성할 때 다음 요소를 고려합니다.

• 디스크 유형
• 디스크 크기
• 총 디스크 수

다음 표에서는 현재 Azure에서 사용할 수 있는 관리 디스크 유형을 보여 줍니다. 이러한 디스크 유형에 NiFi를 사용할 수 있습니다. 그러나 처리량이 높은 데이터 흐름의 경우 프리미엄 SSD를 권장합니다.

	Ultra Disk Storage(NVM Express(NVMe))	프리미엄 SSD	표준 SSD	표준 HDD
디스크 유형	SSD	SSD	SSD	HDD
최대 디스크 크기	65,536GB	32,767GB	32,767GB	32,767GB
최대 처리량	2,000MiB/초	900MiB/초	750MiB/초	500MiB/초
최대 IOPS	160,000	20,000	6,000	2,000

데이터 흐름의 처리량을 늘리려면 세 개 이상의 데이터 디스크를 사용합니다. 디스크에서 리포지토리를 구성하는 모범 사례는 이 문서의 뒷부분에 있는 리포지토리 구성을 참조하세요.

다음 표에는 각 디스크 크기 및 유형에 대한 관련 크기 및 처리량 수치가 나와 있습니다.

	표준 HDD S15	표준 HDD S20	표준 HDD S30	표준 SSD S15	표준 SSD S20	표준 SSD S30	프리미엄 SSD P15	프리미엄 SSD P20	프리미엄 SSD P30
디스크 크기(GB)	256	512	1,024	256	512	1,024	256	512	1,024
디스크당 IOPS	최대 500	최대 500	최대 500	최대 500	최대 500	최대 500	1,100	2,300	5,000
디스크당 처리량	최대 60MBps	최대 60MBps	최대 60MBps	최대 60MBps	최대 60MBps	최대 60MBps	125MBps	150MBps	200MBps

시스템이 VM 제한에 도달하면 디스크를 더 추가해도 처리량이 증가하지 않을 수 있습니다.

• IOPS 및 처리량 제한은 디스크 크기에 따라 달라집니다.
• 선택하는 VM 크기는 모든 데이터 디스크에서 VM에 대한 IOPS 및 처리량 제한이 설정되어 있습니다.

VM 수준의 디스크 처리량 제한은 Azure에서 Linux 가상 머신에 대한 크기를 참조하세요.

VM 디스크 캐싱

Azure VM에서 호스트 캐싱 기능은 디스크 쓰기 캐싱을 관리합니다. 리포지토리에 사용하는 데이터 디스크의 처리량을 늘리려면 호스트 캐싱을 None으로 설정하여 디스크 쓰기 캐싱을 해제합니다.

리포지토리 구성

NiFi에 대한 모범 사례 지침은 별도의 디스크를 사용하거나 각 리포지토리에 대해 디스크를 사용하는 것입니다.

• 콘텐츠
• FlowFile
• 출처

이 방법을 사용하려면 최소 3개의 디스크가 필요합니다.

NiFi는 애플리케이션 수준의 스트라이프도 지원합니다. 이 기능은 데이터 리포지토리의 크기 또는 성능을 향상합니다.

다음은 nifi.properties 구성 파일에서 발췌한 내용입니다. 이 구성은 VM에 연결된 관리 디스크에서 리포지토리를 분할하고 스트라이프합니다.

nifi.provenance.repository.directory.stripe1=/mnt/disk1/ provenance_repository
nifi.provenance.repository.directory.stripe2=/mnt/disk2/ provenance_repository
nifi.provenance.repository.directory.stripe3=/mnt/disk3/ provenance_repository
nifi.content.repository.directory.stripe1=/mnt/disk4/ content_repository
nifi.content.repository.directory.stripe2=/mnt/disk5/ content_repository
nifi.content.repository.directory.stripe3=/mnt/disk6/ content_repository
nifi.flowfile.repository.directory=/mnt/disk7/ flowfile_repository

고성능 스토리지용 디자인에 대한 자세한 내용은 Azure Premium Storage: 고성능을 위한 설계를 참조하세요.

보고

NiFi에는 Log Analytics 기능에 대한 출처 보고 작업이 포함되어 있습니다.

이 보고 작업을 사용하여 비용 효율적이고 지속성 있는 장기 스토리지에 출처 이벤트를 오프로드할 수 있습니다. Log Analytics 기능은 개별 이벤트를 보고 그래프로 표시하기 위한 쿼리 인터페이스를 제공합니다. 이러한 쿼리에 대한 자세한 내용은 이 문서의 뒷부분에 있는 Log Analytics 쿼리를 참조하세요.

이 작업을 휘발성인 메모리 내 출처 스토리지와 함께 사용할 수도 있습니다. 많은 시나리오에서 처리량 증가를 달성할 수 있습니다. 그러나 이벤트 데이터를 보존해야 하는 경우 이 방법은 위험합니다. 휘발성 스토리지가 출처 이벤트에 대해 내구성 요구 사항을 충족하는지 확인합니다. 자세한 내용은 Apache NiFi 시스템 관리자 가이드의 출처 리포지토리를 참조하세요.

이 프로세스를 사용하기 전에 Azure 구독에서 Log Analytics 작업 영역을 만듭니다. 워크로드와 동일한 지역에 작업 영역을 설정하는 것이 가장 좋습니다.

출처 보고 작업을 구성하려면 다음을 수행합니다.

1. NiFi에서 컨트롤러 설정을 엽니다.
2. 보고 작업 메뉴를 선택합니다.
3. 새 보고 작업 만들기를 선택합니다.
4. Azure Log Analytics 보고 작업을 선택합니다.

다음 스크린샷은 이 보고 작업의 속성 메뉴를 보여줍니다.

두 가지 속성이 필요합니다.

• Log Analytics 작업 영역 ID
• Log Analytics 작업 영역 키

Log Analytics 작업 영역으로 이동하여 Azure Portal에서 이러한 값을 찾을 수 있습니다.

시스템에서 보내는 출처 이벤트를 사용자 지정하고 필터링하는 다른 옵션도 사용할 수 있습니다.

보안

우수한 보안은 중요한 데이터 및 시스템에 대한 고의적인 공격과 악용을 방어합니다. 자세한 내용은 보안 요소의 개요를 참조하세요.

인증 및 권한 부여 관점에서 NiFi를 보호할 수 있습니다. 다음을 비롯한 모든 네트워크 통신에 대해 NiFi를 보호할 수도 있습니다.

• 클러스터 내.
• 클러스터와 ZooKeeper 사이.

다음 옵션을 켜는 방법에 대한 지침은 Apache NiFi 관리자 가이드를 참조하세요.

• Kerberos
• LDAP(Lightweight Directory Access Protocol)
• 인증서 기반 인증 및 권한 부여
• 클러스터 통신을 위한 양방향 SSL(Secure Sockets Layer)

ZooKeeper 보안 클라이언트 액세스를 사용하는 경우 관련 속성을 bootstrap.conf 구성 파일에 추가하여 NiFi를 구성합니다. 다음 구성 항목은 예제를 제공합니다.

java.arg.18=-Dzookeeper.clientCnxnSocket=org.apache.zookeeper.ClientCnxnSocketNetty
java.arg.19=-Dzookeeper.client.secure=true
java.arg.20=-Dzookeeper.ssl.keyStore.location=/path/to/keystore.jks
java.arg.21=-Dzookeeper.ssl.keyStore.password=[KEYSTORE PASSWORD]
java.arg.22=-Dzookeeper.ssl.trustStore.location=/path/to/truststore.jks
java.arg.23=-Dzookeeper.ssl.trustStore.password=[TRUSTSTORE PASSWORD]

일반적인 권장 사항은 Linux 보안 기준을 참조하세요.

네트워크 보안

이 솔루션을 구현할 때 네트워크 보안에 대한 다음 사항에 유의하세요.

네트워크 보안 그룹

Azure에서 네트워크 보안 그룹을 사용하여 네트워크 트래픽을 제한할 수 있습니다.

관리 작업을 위해 NiFi 클러스터에 연결하기 위해 jumpbox를 사용할 것을 권장합니다. JIT(Just-In-Time) 액세스 또는 Azure Bastion에 보안 강화 VM을 사용합니다. jumpbox 또는 Azure Bastion에 대한 액세스 권한을 부여하는 방법을 제어하도록 네트워크 보안 그룹을 설정합니다. 아키텍처의 다양한 서브넷에서 신중하게 네트워크 보안 그룹을 사용하여 네트워크 격리 및 제어를 달성할 수 있습니다.

다음 스크린샷은 일반적인 가상 네트워크의 구성 요소를 보여 줍니다. jumpbox, 가상 머신 확장 집합 및 ZooKeeper VM에 대한 공통 서브넷을 포함합니다. 이 간소화된 네트워크 토폴로지에서는 구성 요소를 하나의 서브넷으로 그룹화합니다. 업무 분리 및 네트워크 설계에 대한 조직의 지침을 따릅니다.

아웃바운드 인터넷 액세스 고려 사항

Azure의 NiFi를 실행하려면 공용 인터넷에 액세스할 필요가 없습니다. 데이터 흐름에서 데이터를 검색하는 데 인터넷 액세스가 필요하지 않은 경우 다음 단계에 따라 아웃바운드 인터넷 액세스를 사용하지 않도록 설정하여 클러스터의 보안을 개선합니다.

1. 가상 네트워크에 추가 네트워크 보안 그룹 규칙을 만듭니다.

2. 사용할 설정

   • 원본: Any
   • 대상: Internet
   • 작업: Deny

이 규칙을 적용하면 가상 네트워크에서 프라이빗 엔드포인트를 구성하는 경우 데이터 흐름에서 일부 Azure 서비스에 계속 액세스할 수 있습니다. 이를 위해 Azure Private Link를 사용합니다. 이 서비스는 트래픽이 다른 외부 네트워크에 액세스하지 않고도 Microsoft 백본 네트워크에서 이동하는 방법을 제공합니다. NiFi는 현재 Blob Storage 및 Data Lake Storage 프로세서에 대한 프라이빗 링크를 지원합니다. NTP(네트워크 시간 프로토콜) 서버를 프라이빗 네트워크에서 사용할 수 없는 경우 NTP에 대한 아웃바운드 액세스를 허용합니다. 자세한 내용은 Azure에서 Linux VM의 시간 동기화를 참조하세요.

데이터 보호

유선 암호화, IAM(ID 및 액세스 관리) 또는 데이터 암호화 없이 NiFi를 보호되지 않은 상태로 작동할 수 있습니다. 그러나 다음과 같은 방법으로 프로덕션 및 퍼블릭 클라우드 배포를 안전하게 보호하는 것이 가장 좋습니다.

• TLS(전송 계층 보안)를 통한 통신 암호화
• 지원되는 인증 및 권한 부여 메커니즘 사용
• 저장 데이터 암호화

Azure Storage 서버 쪽 투명한 데이터 암호화를 제공합니다. 그러나 1.13.2 릴리스부터 NiFi는 기본적으로 유선 암호화 또는 IAM을 구성하지 않습니다. 이 동작은 향후 릴리스에서 변경될 수 있습니다.

다음 섹션에서는 안전하게 배포하는 방법을 보여 줍니다.

• TLS를 통해 유선 암호화 사용
• 인증서 또는 Microsoft Entra ID를 기반으로 하는 인증 구성
• Azure에서 암호화된 스토리지 관리

디스크 암호화

보안을 향상하려면 Azure 디스크 암호화를 사용합니다. 자세한 절차는 Azure CLI를 사용하여 가상 머신 확장 집합에서 OS 및 연결된 데이터 디스크 암호화를 참조하세요. 해당 문서에는 사용자 고유의 암호화 키를 제공하는 방법에 대한 지침도 포함되어 있습니다. 다음 단계에서는 대부분의 배포에서 작동하는 NiFi에 대한 기본 예제를 간략하게 설명합니다.

1. 기존 Key Vault 인스턴스에서 디스크 암호화를 켜려면 다음 Azure CLI 명령을 사용합니다.

   az keyvault create --resource-group myResourceGroup --name myKeyVaultName --enabled-for-disk-encryption
   

2. 다음 명령을 사용하여 가상 머신 확장 집합 데이터 디스크의 암호화를 켭니다.

   az vmss encryption enable --resource-group myResourceGroup --name myScaleSet --disk-encryption-keyvault myKeyVaultID --volume-type DATA
   

3. 필요에 따라 KEK(키 암호화 키)를 사용할 수 있습니다. 다음 Azure CLI 명령을 사용하여 KEK로 암호화합니다.

   az vmss encryption enable --resource-group myResourceGroup --name  myScaleSet  \
   --disk-encryption-keyvault myKeyVaultID \
   --key-encryption-keyvault myKeyVaultID \
   --key-encryption-key https://<mykeyvaultname>.vault.azure.net/keys/myKey/<version> \
   --volume-type DATA
   
   

전송 중 암호화

NiFi는 전송 중 암호화를 위해 TLS 1.2를 지원합니다. 이 프로토콜은 UI에 대한 사용자 액세스를 보호합니다. 클러스터를 사용하면 프로토콜로 NiFi 노드 간의 통신을 보호합니다. ZooKeeper와의 통신을 보호할 수도 있습니다. TLS를 사용하도록 설정하면 NiFi는 상호 인증을 위해 mTLS(상호 TLS)를 사용합니다.

• 이 유형의 인증을 구성한 경우 인증서 기반 클라이언트 인증입니다.
• 모든 클러스터 내 통신.

TLS를 사용하도록 설정하려면 다음 단계를 수행합니다.

1. 클라이언트-서버 및 클러스터 내 통신 및 인증을 위한 키 저장소 및 신뢰 저장소를 만듭니다.

2. $NIFI_HOME/conf/nifi.properties 구성. 다음 값을 설정합니다.

   • 호스트 이름
   • 포트
   • 키 저장소 속성
   • 신뢰 저장소 속성
   • 클러스터 및 ZooKeeper 보안 속성(해당하는 경우)

3. $NIFI_HOME/conf/authorizers.xml 인증에서는 일반적으로 인증서 기반 인증 또는 다른 옵션이 있는 초기 사용자로 인증을 구성합니다.

4. 필요에 따라 NiFi와 프록시, 부하 분산 장치 또는 외부 엔드포인트 간에 mTLS 및 프록시 읽기 정책을 구성합니다.

전체 연습은 Apache 프로젝트 설명서의 TLS를 사용하여 NiFi 보호를 참조하세요.

인증서, 키 및 키 저장소

TLS를 지원하려면 인증서를 생성하고, Java 키 저장소 및 신뢰 저장소에 저장하고, NiFi 클러스터에 배포합니다. 인증서에는 두 가지 일반 옵션이 있습니다.

• 자체 서명된 인증서
• CA(인증 기관)에서 서명하는 인증서

CA에서 서명한 인증서를 사용하는 경우 중간 CA를 사용하여 클러스터의 노드에 대한 인증서를 생성하는 것이 가장 좋습니다.

키 저장소 및 신뢰 저장소는 Java 플랫폼의 키 및 인증서 컨테이너입니다. 키 저장소는 클러스터에 프라이빗 키와 노드 인증서를 저장합니다. 신뢰 저장소는 다음 유형의 인증서 중 하나를 저장합니다.

• 키 저장소의 자체 서명된 인증서에 대한 모든 신뢰할 수 있는 인증서
• 키 저장소의 CA 서명 인증서에 대한 CA의 인증서

컨테이너를 선택할 때 NiFi 클러스터의 확장성을 염두에 두어야 합니다. 예를 들어 나중에 클러스터의 노드 수를 늘리거나 줄일 수 있습니다. 이 경우 키 저장소에서 CA 서명된 인증서와 해당 사례의 신뢰 저장소에서 하나 이상의 CA 인증서를 선택합니다. 이 옵션을 사용하면 클러스터의 기존 노드에서 기존 신뢰 저장소를 업데이트할 필요가 없습니다. 기존 신뢰 저장소는 다음과 같은 유형의 노드에 있는 인증서를 신뢰하고 수락합니다.

• 클러스터에 추가하는 노드
• 클러스터의 다른 노드를 대체하는 노드

NiFi 구성

NiFi에 TLS를 사용하도록 설정하려면 이 표의 속성을 구성하는 데 $NIFI_HOME/conf/nifi.properties을(를) 사용합니다. 다음 속성에 NiFi에 액세스하는 데 사용하는 호스트 이름이 포함되어 있는지 확인합니다.

• nifi.web.https.host 또는 nifi.web.proxy.host
• 호스트 인증서의 지정된 이름 또는 주체 대체 이름

그렇지 않으면 호스트 이름 확인 실패 또는 HTTP 호스트 헤더 확인 오류가 발생하여 액세스를 거부할 수 있습니다.

속성 이름	설명	예제 값
nifi.web.https.host	UI 및 REST API에 사용할 호스트 이름 또는 IP 주소입니다. 이 값은 내부적으로 확인할 수 있어야 합니다. 공개적으로 액세스할 수 있는 이름을 사용하지 않는 것이 좋습니다.	nifi.internal.cloudapp.net
nifi.web.https.port	UI 및 REST API에 사용할 HTTPS 포트입니다.	9443(기본값)
nifi.web.proxy.host	클라이언트가 UI 및 REST API에 액세스하는 데 사용하는 대체 호스트 이름을 쉼표로 구분한 목록입니다. 이 목록에는 일반적으로 서버 인증서에 SAN(주체 대체 이름)으로 지정된 호스트 이름이 포함됩니다. 목록에는 부하 분산 장치, 프록시 또는 Kubernetes 수신 컨트롤러에서 사용하는 호스트 이름 및 포트가 포함될 수도 있습니다.	40.67.218.235, 40.67.218.235:443, nifi.westus2.cloudapp.com, nifi.westus2.cloudapp.com:443
nifi.security.keystore	인증서의 프라이빗 키가 포함된 JKS 또는 PKCS12 키 저장소의 경로입니다.	./conf/keystore.jks
nifi.security.keystoreType	키 저장소 유형입니다.	JKS 또는 PKCS12
nifi.security.keystorePasswd	키 저장소 암호입니다.	O8SitLBYpCz7g/RpsqH+zM
nifi.security.keyPasswd	(선택 사항) 프라이빗 키의 암호입니다.
nifi.security.truststore	신뢰할 수 있는 사용자 및 클러스터 노드를 인증하는 인증서 또는 CA 인증서가 포함된 JKS 또는 PKCS12 신뢰 저장소의 경로입니다.	./conf/truststore.jks
nifi.security.truststoreType	신뢰 저장소 형식입니다.	JKS 또는 PKCS12
nifi.security.truststorePasswd	신뢰 저장소 암호입니다.	RJlpGe6/TuN5fG+VnaEPi8
nifi.cluster.protocol.is.secure	클러스터 내 통신의 TLS 상태입니다. nifi.cluster.is.node이(가) true인 경우 클러스터 TLS를 사용하도록 이 값을 true로 설정합니다.	true
nifi.remote.input.secure	사이트 간 통신에 대한 TLS의 상태입니다.	true

다음 예제에서는 이러한 속성이 $NIFI_HOME/conf/nifi.properties에 어떻게 표시되는지 보여 줍니다. nifi.web.http.host와 nifi.web.http.port 값은 비어 있습니다.

nifi.remote.input.secure=true
nifi.web.http.host=
nifi.web.http.port=
nifi.web.https.host=nifi.internal.cloudapp.net
nifi.web.https.port=9443
nifi.web.proxy.host=40.67.218.235, 40.67.218.235:443, nifi.westus2.cloudapp.com, nifi.westus2.cloudapp.com:443
nifi.security.keystore=./conf/keystore.jks 
nifi.security.keystoreType=JKS          
nifi.security.keystorePasswd=O8SitLBYpCz7g/RpsqH+zM                  
nifi.security.keyPasswd=
nifi.security.truststore=./conf/truststore.jks                                   
nifi.security.truststoreType=JKS
nifi.security.truststorePasswd=RJlpGe6/TuN5fG+VnaEPi8
nifi.cluster.protocol.is.secure=true

ZooKeeper 구성

쿼럼 통신 및 클라이언트 액세스를 위해 Apache ZooKeeper에서 TLS를 사용하도록 설정하는 방법에 대한 지침은 ZooKeeper 관리자 가이드를 참조하세요. 버전 3.5.5 이상만 이 기능을 지원합니다.

NiFi는 0 리더 클러스터링 및 클러스터 조정에 ZooKeeper를 사용합니다. 버전 1.13.0부터 NiFi는 ZooKeeper의 TLS 사용 인스턴스에 대한 보안 클라이언트 액세스를 지원합니다. ZooKeeper는 클러스터 멤버 자격 및 클러스터 범위 프로세서 상태를 일반 텍스트로 저장합니다. 따라서 ZooKeeper에 대한 보안 클라이언트 액세스를 사용하여 ZooKeeper 클라이언트 요청을 인증하는 것이 중요합니다. 또한 전송 중인 중요한 값을 암호화합니다.

ZooKeeper에 대한 NiFi 클라이언트 액세스를 위해 TLS를 사용하도록 설정하려면 다음 속성을 $NIFI_HOME/conf/nifi.properties로 설정합니다. 속성을 구성 nifi.zookeeper.security 하지 않고 설정하는 nifi.zookeeper.client.secure true 경우 NiFi는 사용자가 지정한 키 저장소 및 신뢰 저장소로 nifi.securityproperties돌아갑니다.

속성 이름	설명	예제 값
nifi.zookeeper.client.secure	ZooKeeper에 연결할 때 클라이언트 TLS의 상태입니다.	true
nifi.zookeeper.security.keystore	인증을 위해 ZooKeeper에 표시되는 인증서의 프라이빗 키가 포함된 JKS, PKCS12 또는 PEM 키 저장소의 경로입니다.	./conf/zookeeper.keystore.jks
nifi.zookeeper.security.keystoreType	키 저장소 유형입니다.	JKS, PKCS12, PEM 또는 확장별 자동 검색
nifi.zookeeper.security.keystorePasswd	키 저장소 암호입니다.	caB6ECKi03R/co+N+64lrz
nifi.zookeeper.security.keyPasswd	(선택 사항) 프라이빗 키의 암호입니다.
nifi.zookeeper.security.truststore	ZooKeeper를 인증하는 데 사용되는 인증서 또는 CA 인증서가 포함된 JKS, PKCS12 또는 PEM 신뢰 저장소의 경로입니다.	./conf/zookeeper.truststore.jks
nifi.zookeeper.security.truststoreType	신뢰 저장소 형식입니다.	JKS, PKCS12, PEM 또는 확장별 자동 검색
nifi.zookeeper.security.truststorePasswd	신뢰 저장소 암호입니다.	qBdnLhsp+mKvV7wab/L4sv
nifi.zookeeper.connect.string	ZooKeeper 호스트 또는 쿼럼에 대한 연결 문자열입니다. 이 문자열은 쉼표로 구분된 host:port 값 목록입니다. 일반적으로 secureClientPort 값은 clientPort 값과 동일하지 않습니다. 올바른 값은 ZooKeeper 구성을 참조하세요.	zookeeper1.internal.cloudapp.net:2281, zookeeper2.internal.cloudapp.net:2281, zookeeper3.internal.cloudapp.net:2281

다음 예제에서는 이러한 속성이 $NIFI_HOME/conf/nifi.properties에 표시되는 방식을 보여줍니다.

nifi.zookeeper.client.secure=true
nifi.zookeeper.security.keystore=./conf/keystore.jks
nifi.zookeeper.security.keystoreType=JKS
nifi.zookeeper.security.keystorePasswd=caB6ECKi03R/co+N+64lrz
nifi.zookeeper.security.keyPasswd=
nifi.zookeeper.security.truststore=./conf/truststore.jks
nifi.zookeeper.security.truststoreType=JKS
nifi.zookeeper.security.truststorePasswd=qBdnLhsp+mKvV7wab/L4sv
nifi.zookeeper.connect.string=zookeeper1.internal.cloudapp.net:2281,zookeeper2.internal.cloudapp.net:2281,zookeeper3.internal.cloudapp.net:2281

TLS를 사용하여 ZooKeeper를 보호하는 방법에 대한 자세한 내용은 Apache NiFi 관리 가이드를 참조하세요.

ID 및 액세스 제어

NiFi에서 ID 및 액세스 제어는 사용자 인증 및 권한 부여를 통해 수행됩니다. 사용자 인증의 경우 NiFi는 단일 사용자, LDAP, Kerberos, SAML(Security Assertion Markup Language) 및 OIDC(OpenID Connect)와 같은 여러 옵션에서 선택할 수 있습니다. 옵션을 구성하지 않으면 NiFi는 클라이언트 인증서를 사용하여 HTTPS를 통해 사용자를 인증합니다.

다단계 인증을 고려하는 경우 Microsoft Entra ID와 OIDC의 조합을 사용하는 것이 좋습니다. Microsoft Entra ID는 OIDC를 사용하여 클라우드 네이티브 SSO(Single Sign-On)를 지원합니다. 이 조합을 사용하면 사용자는 다음과 같은 많은 엔터프라이즈 보안 기능을 활용할 수 있습니다.

• 사용자 계정에서 의심스러운 활동에 대한 로깅 및 경고
• 비활성화된 자격 증명에 액세스하려는 모니터링 시도
• 비정상적인 계정 로그인 동작에 대한 경고

인증 시 NiFi는 사용자, 그룹 및 액세스 정책을 기반으로 적용할 수 있습니다. NiFi는 UserGroupProviders 및 AccessPolicyProviders를 통해 적용할 수 있습니다. 기본적으로 공급자에는 파일, LDAP, Shell 및 Azure Graph 기반 UserGroupProviders가 포함됩니다. AzureGraphUserGroupProvider를 사용하면 Microsoft Entra ID에서 사용자 그룹을 원본으로 만들 수 있습니다. 그런 다음 이러한 그룹에 정책을 할당할 수 있습니다. 구성 지침은 Apache NiFi 관리 가이드를 참조하세요.

파일 및 Apache Ranger를 기반으로 하는 AccessPolicyProviders는 현재 사용자 및 그룹 정책을 관리하고 저장할 수 있습니다. 자세한 내용은 Apache NiFi 설명서 및 Apache Ranger 설명서를 참조하세요.

프런트 엔드

애플리케이션 게이트웨이는 NiFi 인터페이스에 대해 관리형 레이어 7 부하 분산 장치를 제공합니다. NiFi 노드의 가상 머신 확장 집합을 백 엔드 풀로 사용하도록 애플리케이션 게이트웨이를 구성합니다.

대부분의 NiFi 설치의 경우 다음 Application Gateway 구성을 사용하는 것이 좋습니다.

• 계층: Standard
• SKU 크기: 중간
• 인스턴스 수: 둘 이상

상태 프로브를 사용하여 각 노드의 웹 서버 상태를 모니터링합니다. 부하 분산 장치 회전에서 비정상 노드를 제거합니다. 이 방법을 사용하면 전체 클러스터가 비정상일 때 사용자 인터페이스를 더 쉽게 볼 수 있습니다. 브라우저는 현재 정상이며 요청에 응답하는 노드로만 안내합니다.

고려해야 할 두 가지 주요 상태 프로브가 있습니다. 둘 다 클러스터에 있는 모든 노드의 전반적인 상태에 대해 정기적인 하트비트도 제공합니다. 경로 /NiFi를 가리키도록 첫 번째 상태 프로브를 구성합니다. 이 프로브는 각 노드에서 NiFi 사용자 인터페이스의 상태를 결정합니다. 경로 /nifi-api/controller/cluster에 대한 두 번째 상태 프로브를 구성합니다. 이 프로브는 각 노드가 현재 정상 상태이고 전체 클러스터에 조인되었는지 여부를 나타냅니다.

애플리케이션 게이트웨이 프런트 엔드 IP 주소를 구성하는 두 가지 옵션이 있습니다.

• 공용 IP 주소
• 개인 서브넷 IP 주소

사용자가 공용 인터넷을 통해 UI에 액세스해야 하는 경우 공용 IP 주소만 포함합니다. 사용자에 대한 공용 인터넷 액세스가 필요하지 않은 경우 가상 네트워크의 jumpbox에서 또는 개인 네트워크에 대한 피어링을 통해 부하 분산 장치 프런트 엔드에 액세스합니다. 공용 IP 주소를 사용하여 애플리케이션 게이트웨이를 구성하는 경우 NiFi에 대한 클라이언트 인증서 인증을 사용하도록 설정하고 NiFi UI에 대해 TLS를 사용하도록 설정하는 것이 좋습니다. 위임된 애플리케이션 게이트웨이 서브넷에서 네트워크 보안 그룹을 사용하여 원본 IP 주소를 제한할 수도 있습니다.

진단 및 상태 모니터링

Application Gateway의 진단 설정 내에 메트릭 및 액세스 로그를 보내기 위한 구성 옵션이 있습니다. 이 옵션을 사용하여 부하 분산 장치에서 다양한 위치로 이 정보를 보낼 수 있습니다.

• 스토리지 계정
• Event Hubs
• Log Analytics 작업 영역

이 설정을 사용하도록 설정하면 부하 분산 문제를 디버깅하고 클러스터 노드의 상태에 대한 인사이트를 얻는 데 유용합니다.

다음 Log Analytics 쿼리는 Application Gateway 관점에서 시간 경과에 따른 클러스터 노드 상태를 보여 줍니다. 유사한 쿼리를 사용하여 비정상 노드에 대한 경고 또는 자동화된 복구 동작을 생성할 수 있습니다.

AzureDiagnostics
| summarize UnHealthyNodes = max(unHealthyHostCount_d), HealthyNodes = max(healthyHostCount_d) by bin(TimeGenerated, 5m)
| render timechart

다음 쿼리 결과 차트는 클러스터의 상태에 대한 시간 보기를 표시합니다.

가용성

이 솔루션을 구현할 때 가용성과 관련한 다음 사항에 유의하세요.

부하 분산 장치

노드 가동 중지 시간 동안 UI 가용성을 높이려면 UI에 대한 부하 분산 장치를 사용합니다.

별도의 VM

가용성을 높이려면 NiFi 클러스터의 VM에서 별도의 VM에 ZooKeeper 클러스터를 배포합니다. ZooKeeper 구성에 대한 자세한 내용은 Apache NiFi 시스템 관리자 가이드의 상태 관리를 참조하세요.

가용성 영역

크로스 영역 구성 시 NiFi 가상 머신 확장 집합과 ZooKeeper 클러스터 둘 다 배포하여 가용성을 최대화합니다. 클러스터의 노드 간 통신이 가용성 영역에서 이루어지는 경우 약간의 대기 시간이 발생합니다. 그러나 이 대기 시간이 클러스터의 처리량에 미치는 전반적인 영향은 일반적으로 최소화됩니다.

가상 머신 크기 집합

사용 가능한 경우 가용성 영역에 걸쳐 있는 단일 가상 머신 확장 집합에 NiFi 노드를 배포하는 것이 좋습니다. 이러한 방식으로 확장 집합을 사용하는 방법에 대한 자세한 내용은 가용성 영역을 사용하는 가상 머신 확장 집합 만들기를 참조하세요.

모니터링

NiFi 클러스터의 상태 및 성능을 모니터링하려면 보고 작업을 사용합니다.

보고 작업 기반 모니터링

모니터링을 위해 NiFi에서 구성하고 실행하는 보고 작업을 사용할 수 있습니다. 진단 및 상태 모니터링에서 설명한 대로 Log Analytics는 NiFi Azure 번들에 보고 작업을 제공합니다. 이 보고 작업을 사용하여 Log Analytics 및 기존 모니터링 또는 로깅 시스템과 모니터링을 통합할 수 있습니다.

Log Analytics 쿼리

다음 섹션의 샘플 쿼리는 시작하는 데 도움이 될 수 있습니다. Log Analytics 데이터를 쿼리하는 방법에 대한 개요는 Azure Monitor 로그 쿼리를 참조하세요.

Monitor 및 Log Analytics의 로그 쿼리는 Kusto 쿼리 언어 버전을 사용합니다. 그러나 로그 쿼리와 Kusto 쿼리 간에는 차이가 있습니다. 자세한 내용은 Kusto 쿼리 개요를 참조하세요.

보다 구조화된 학습은 다음 자습서를 참조하세요.

• Azure Monitor에서 로그 쿼리 시작
• Azure Monitor에서 Log Analytics 시작

Log Analytics 보고 작업

기본적으로 NiFi는 메트릭 데이터를 nifimetrics 테이블로 보냅니다. 그러나 보고 작업 속성에서 다른 대상을 구성할 수 있습니다. 보고 작업은 다음 NiFi 메트릭을 캡처합니다.

메트릭 유형	메트릭 이름
NiFi 메트릭	FlowFilesReceived
NiFi 메트릭	FlowFilesSent
NiFi 메트릭	FlowFilesQueued
NiFi 메트릭	BytesReceived
NiFi 메트릭	BytesWritten
NiFi 메트릭	BytesRead
NiFi 메트릭	BytesSent
NiFi 메트릭	BytesQueued
포트 상태 메트릭	InputCount
포트 상태 메트릭	InputBytes
연결 상태 메트릭	QueuedCount
연결 상태 메트릭	QueuedBytes
포트 상태 메트릭	OutputCount
포트 상태 메트릭	OutputBytes
JVM(Java 가상 머신) 메트릭	jvm.uptime
JVM 메트릭	jvm.heap_used
JVM 메트릭	jvm.heap_usage
JVM 메트릭	jvm.non_heap_usage
JVM 메트릭	jvm.thread_states.runnable
JVM 메트릭	jvm.thread_states.blocked
JVM 메트릭	jvm.thread_states.timed_waiting
JVM 메트릭	jvm.thread_states.terminated
JVM 메트릭	jvm.thread_count
JVM 메트릭	jvm.daemon_thread_count
JVM 메트릭	jvm.file_descriptor_usage
JVM 메트릭	jvm.gc.runs jvm.gc.runs.g1_old_generation jvm.gc.runs.g1_young_generation
JVM 메트릭	jvm.gc.time jvm.gc.time.g1_young_generation jvm.gc.time.g1_old_generation
JVM 메트릭	jvm.buff_pool_direct_capacity
JVM 메트릭	jvm.buff_pool_direct_count
JVM 메트릭	jvm.buff_pool_direct_mem_used
JVM 메트릭	jvm.buff_pool_mapped_capacity
JVM 메트릭	jvm.buff_pool_mapped_count
JVM 메트릭	jvm.buff_pool_mapped_mem_used
JVM 메트릭	jvm.mem_pool_code_cache
JVM 메트릭	jvm.mem_pool_compressed_class_space
JVM 메트릭	jvm.mem_pool_g1_eden_space
JVM 메트릭	jvm.mem_pool_g1_old_gen
JVM 메트릭	jvm.mem_pool_g1_survivor_space
JVM 메트릭	jvm.mem_pool_metaspace
JVM 메트릭	jvm.thread_states.new
JVM 메트릭	jvm.thread_states.waiting
프로세서 수준 메트릭	BytesRead
프로세서 수준 메트릭	BytesWritten
프로세서 수준 메트릭	FlowFilesReceived
프로세서 수준 메트릭	FlowFilesSent

클러스터의 BytesQueued 메트릭에 대한 샘플 쿼리는 다음과 같습니다.

let table_name = nifimetrics_CL;
let metric = "BytesQueued";
table_name
| where Name_s == metric
| where Computer contains {ComputerName}
| project TimeGenerated, Computer, ProcessGroupName_s,  Count_d, Name_s
| summarize sum(Count_d) by bin(TimeGenerated, 1m),  Computer, Name_s
| render timechart 

이 쿼리는 이 스크린샷의 차트와 같은 차트를 생성합니다.

NiFi 인프라 모니터링

보고 작업 외에도 NiFi 및 ZooKeeper 노드에 Log Analytics VM 확장을 설치합니다. 이 확장은 로그, VM 수준의 추가 메트릭 및 ZooKeeper의 메트릭을 수집합니다.

NiFi 앱, 사용자, 부트스트랩 및 ZooKeeper에 대한 사용자 지정 로그

더 많은 로그를 캡처하려면 다음 단계를 수행합니다.

1. Azure Portal에서 Log Analytics 작업 영역을 선택한 다음, 작업 영역을 선택합니다.

2. 설정 아래에서 사용자 지정 로그를 선택합니다.

   

3. 사용자 지정 로그 추가를 선택합니다.

   

4. 다음 값을 사용하여 사용자 지정 로그를 설정합니다.

   • 이름: NiFiAppLogs
   • 경로 유형: Linux
   • 경로 이름: /opt/nifi/logs/nifi-app.log

   

5. 다음 값을 사용하여 사용자 지정 로그를 설정합니다.

   • 이름: NiFiBootstrapAndUser
   • 첫 번째 경로 형식: Linux
   • 첫 번째 경로 이름: /opt/nifi/logs/nifi-user.log
   • 두 번째 경로 형식: Linux
   • 두 번째 경로 이름: /opt/nifi/logs/nifi-bootstrap.log

   

6. 다음 값을 사용하여 사용자 지정 로그를 설정합니다.

   • 이름: NiFiZK
   • 경로 유형: Linux
   • 경로 이름: /opt/zookeeper/logs/*.out

   

다음은 첫 번째 예제에서 만든 NiFiAppLogs 사용자 지정 테이블의 샘플 쿼리입니다.

NiFiAppLogs_CL
| where TimeGenerated > ago(24h)
| where Computer contains {ComputerName} and RawData contains "error"
| limit 10

이 쿼리는 다음 결과와 유사한 결과를 생성합니다.

인프라 로그 구성

Monitor를 사용하여 VM 또는 물리적 컴퓨터를 모니터링하고 관리할 수 있습니다. 이러한 리소스는 로컬 데이터 센터 또는 기타 클라우드 환경에 있을 수 있습니다. 이 모니터링을 설정하려면 Log Analytics 에이전트를 배포합니다. Log Analytics 작업 영역에 보고하도록 에이전트를 구성합니다. 자세한 내용은 Log Analytics 에이전트 개요를 참조하세요.

다음 스크린샷은 NiFi VM에 대한 샘플 에이전트 구성을 보여 줍니다. Perf 테이블은 수집된 데이터를 저장합니다.

NiFi 앱 Perf 로그에 대한 샘플 쿼리는 다음과 같습니다.

let cluster_name = {ComputerName};
// The hourly average of CPU usage across all computers.
Perf
| where Computer contains {ComputerName}
| where CounterName == "% Processor Time" and InstanceName == "_Total"
| where ObjectName == "Processor"
| summarize CPU_Time_Avg = avg(CounterValue) by bin(TimeGenerated, 30m), Computer

이 쿼리는 이 스크린샷의 보고서와 같은 보고서를 생성합니다.

경고

Monitor를 사용하여 NiFi 클러스터의 상태 및 성능에 대한 경고를 만듭니다. 경고 예제는 다음과 같습니다.

• 전체 큐 수가 임계값을 초과했습니다.
• BytesWritten 값이 예상 임계값 미만입니다.
• FlowFilesReceived 값이 임계값 미만입니다.
• 클러스터가 비정상입니다.

Monitor에서 경고를 설정하는 방법에 대한 자세한 내용은 Microsoft Azure 경고 개요를 참조하세요.

구성 매개 변수

다음 섹션에서는 ZooKeeper 및 Java를 비롯한 NiFi 및 해당 종속성에 대해 기본 구성이 아닌 권장 구성에 대해 설명합니다. 이러한 설정은 클라우드에서 가능한 클러스터 크기에 적합합니다. 다음 구성 파일에서 속성을 설정합니다.

• $NIFI_HOME/conf/nifi.properties
• $NIFI_HOME/conf/bootstrap.conf
• $ZOOKEEPER_HOME/conf/zoo.cfg
• $ZOOKEEPER_HOME/bin/zkEnv.sh

사용 가능한 구성 속성 및 파일에 대한 자세한 내용은 Apache NiFi 시스템 관리자 가이드 및 ZooKeeper 관리자 가이드를 참조하세요.

NiFi

Azure 배포의 경우 $NIFI_HOME/conf/nifi.properties에 대한 속성 조정을 고려해 보세요. 다음 표에서는 가장 중요한 속성을 나열합니다. 더 많은 권장 사항 및 인사이트는 Apache NiFi 메일링 목록을 참조하세요.

매개 변수	설명	기본값	권장
nifi.cluster.node.connection.timeout	다른 클러스터 노드에 대한 연결을 열 때 대기하는 기간입니다.	5초	60초
nifi.cluster.node.read.timeout	다른 클러스터 노드에 요청할 때 응답을 기다리는 기간입니다.	5초	60초
nifi.cluster.protocol.heartbeat.interval	클러스터 코디네이터에게 하트비트를 다시 보내는 빈도입니다.	5초	60초
nifi.cluster.node.max.concurrent.requests	REST API 호출과 같은 HTTP 호출을 다른 클러스터 노드에 복제할 때 사용할 병렬 처리 수준입니다.	100	500
nifi.cluster.node.protocol.threads	내부 클러스터/복제된 통신의 초기 스레드 풀 크기입니다.	10	50
nifi.cluster.node.protocol.max.threads	내부 클러스터/복제된 통신에 사용할 최대 스레드 수입니다.	50	75
nifi.cluster.flow.election.max.candidates	현재 흐름을 결정할 때 사용할 노드 수입니다. 이 값은 지정된 숫자의 선택을 단락합니다.	비어 있음	75
nifi.cluster.flow.election.max.wait.time	현재 흐름이 무엇인지 결정하기 전에 노드에서 대기하는 기간입니다.	5분	5분

클러스터 동작

클러스터 구성 시 다음 사항에 유의하세요.

제한 시간

클러스터 및 해당 노드의 전반적인 상태를 보장하기 위해 시간 제한을 늘리는 것이 도움이 될 수 있습니다. 이 사례는 일시적인 네트워크 문제 또는 높은 부하로 인해 오류가 발생하지 않도록 보장하는 데 도움이 됩니다.

분산 시스템에서는 개별 시스템의 성능이 달라집니다. 이러한 변화에는 노드 간, 클러스터 간 통신에 일반적으로 영향을 주는 네트워크 통신 및 대기 시간이 포함됩니다. 네트워크 인프라 또는 시스템 자체가 이러한 변화를 일으킬 수 있습니다. 결과적으로, 시스템의 대규모 클러스터에서 변화될 확률은 매우 높습니다. 로드 중인 Java 애플리케이션에서 JVM(Java 가상 머신)의 GC(가비지 수집)를 일시 중지하면 요청 응답 시간에도 영향을 줄 수 있습니다.

다음 섹션의 속성을 사용하여 시스템의 요구 사항에 맞게 시간 제한을 구성합니다.

nifi.cluster.node.connection.timeout 및 nifi.cluster.node.read.timeout

nifi.cluster.node.connection.timeout 속성은 연결을 열 때 대기하는 시간을 지정합니다. nifi.cluster.node.read.timeout 속성은 요청 간에 데이터를 받을 때 대기하는 시간을 지정합니다. 각 속성의 기본값은 5초입니다. 이러한 속성은 노드-노드 요청에 적용됩니다. 이 값을 늘리면 다음과 같은 몇 가지 관련 문제를 완화할 수 있습니다.

• 하트비트 중단으로 인한 클러스터 코디네이터의 연결 끊김
• 클러스터를 조인할 때 코디네이터에서 흐름을 가져오는 데 실패
• S2S(사이트 간) 및 부하 분산 통신 설정

클러스터에 3개 이하의 노드와 같은 매우 작은 확장 집합이 없으면 기본값보다 큰 값을 사용합니다.

nifi.cluster.protocol.heartbeat.interval

NiFi 클러스터링 전략의 일환으로 각 노드는 하트비트를 내보내 정상 상태를 전달합니다. 기본적으로 노드는 5초마다 하트비트를 보냅니다. 클러스터 코디네이터가 노드의 한 행에서 8개의 하트비트 실패를 감지하면 노드의 연결이 끊어집니다. 느린 하트비트를 수용하고 클러스터가 노드 연결을 불필요하게 끊지 않도록 nifi.cluster.protocol.heartbeat.interval 속성에 설정된 간격을 늘립니다.

동시성

다음 섹션의 속성을 사용하여 동시성 설정을 구성합니다.

nifi.cluster.node.protocol.threads 및 nifi.cluster.node.protocol.max.threads

nifi.cluster.node.protocol.max.threads 속성은 S2S 부하 분산 및 UI 집계와 같은 모든 클러스터 통신에 사용할 최대 스레드 수를 지정합니다. 이 속성의 스레드 기본값은 50개입니다. 대규모 클러스터의 경우 이러한 작업에 필요한 요청 수를 늘리려면 이 값을 늘입니다.

nifi.cluster.node.protocol.threads 속성은 초기 스레드 풀 크기를 결정합니다. 스레드의 기본값은 10개로 최솟값이며, 필요에 따라 nifi.cluster.node.protocol.max.threads의 최대 집합까지 증가합니다. 시작 시 대규모 확장 집합을 사용하는 클러스터의 nifi.cluster.node.protocol.threads 값을 늘립니다.

nifi.cluster.node.max.concurrent.requests

REST API 호출 및 UI 호출과 같은 많은 HTTP 요청을 클러스터의 다른 노드에 복제해야 합니다. 클러스터의 크기가 커지면 점점 더 많은 요청이 복제됩니다. nifi.cluster.node.max.concurrent.requests 속성은 미해결 요청 수를 제한합니다. 이 값은 예상 클러스터 크기를 초과해야 합니다. 기본값은 동시 요청 100개입니다. 노드가 3개 이하인 소규모 클러스터를 실행하지 않는 한 이 값을 늘려 실패한 요청을 방지합니다.

흐름 선택

다음 섹션의 속성을 사용하여 흐름 선택 설정을 구성합니다.

nifi.cluster.flow.election.max.candidates

NiFi는 리더가 없는 클러스터링을 사용합니다. 즉, 신뢰할 수 있는 특정 노드가 하나도 없습니다. 결과적으로 노드는 올바른 것으로 간주되는 흐름 정의를 선택합니다. 또한 클러스터에 조인하는 노드를 결정하도록 선택합니다.

기본적으로 nifi.cluster.flow.election.max.candidates 속성은 nifi.cluster.flow.election.max.wait.time 속성이 지정하는 최대 대기 시간입니다. 이 값이 너무 높으면 시작 속도가 느려질 수 있습니다. nifi.cluster.flow.election.max.wait.time의 기본값은 5분입니다. 대기 시간이 더 이상 필요하지 않도록 최대 후보 수를 비어 있지 않은 값(예: 1 이상)으로 설정합니다. 이 속성을 설정하는 경우 클러스터 크기 또는 예상 클러스터 크기의 일부 비율에 해당하는 값을 할당합니다. 노드가 10개 이하인 소규모 정적 클러스터의 경우 이 값을 클러스터의 노드 수로 설정합니다.

nifi.cluster.flow.election.max.wait.time

탄력적인 클라우드 환경에서 호스트를 프로비전하는 시간은 애플리케이션 시작 시간에 영향을 줍니다. nifi.cluster.flow.election.max.wait.time 속성은 흐름을 결정하기 전에 NiFi의 대기 시간을 결정합니다. 이 값은 클러스터의 전체 시작 시간을 시작 크기에 따라 조정합니다. 초기 테스트에서는 권장되는 인스턴스 유형을 사용하는 모든 Azure 지역의 경우 5분이 더 적합합니다. 그러나 정기적으로 프로비전하는 시간이 기본값을 초과하는 경우 이 값을 늘릴 수 있습니다.

Java

Java의 LTS 릴리스를 사용하는 것이 좋습니다. 릴리스 중 Java 11에서 가비지 수집 구현을 더 빠르게 지원하므로 Java 11이 Java 8보다 좀 더 좋습니다. 그러나 두 릴리스 모두 고성능 NiFi를 배포할 수 있습니다.

다음 섹션에서는 NiFi를 실행할 때 사용할 일반적인 JVM 구성에 대해 설명합니다. $NIFI_HOME/conf/bootstrap.conf의 부트스트랩 구성 파일에서 JVM 매개 변수를 설정합니다.

가비지 수집기

Java 11을 실행하는 경우 대부분의 경우 G1GC(G1 가비지 수집기)를 사용하는 것이 좋습니다. G1GC에서는 GC의 일시 중지 길이를 줄이기 때문에 ParallelGC에서의 성능이 향상되었습니다. Java 11에서는 G1GC이 기본으로 구성되지만 bootstrap.conf의 다음 값을 설정하여 명시적으로 구성할 수 있습니다.

java.arg.13=-XX:+UseG1GC

Java 8을 실행하는 경우 G1GC를 사용하지 마세요. 대신 ParallelGC를 사용합니다. 권장 리포지토리 구현할 때 Java 8을 사용하면 결함이 발생하기 때문에 G1GC는 사용하지 못합니다. ParallelGC는 G1GC보다 느립니다. 하지만 ParallelGC를 사용하면 Java 8을 사용하여 고성능 NiFi를 배포할 수 있습니다.

힙

bootstrap.conf 파일의 속성 집합은 NiFi JVM 힙의 구성을 결정합니다. 표준 흐름의 경우 다음 설정을 사용하여 32GB 힙을 구성합니다.

java.arg.3=-Xmx32g
java.arg.2=-Xms32g

JVM 프로세스에 적용할 최적의 힙 크기를 선택하려면 다음 두 가지 요소를 고려합니다.

• 데이터 흐름의 특징
• NiFi가 처리 과정에서 메모리를 사용하는 방식

자세한 설명서는 Apache NiFi in Depth를 참조하세요.

처리 요구 사항을 충족하는 데 필요한 만큼만 힙을 만듭니다. 이 방법은 GC 일시 중지의 길이를 최소화합니다. Java 가비지 수집에 대한 일반적인 고려 사항은 Java 버전에 대한 가비지 수집 튜닝 가이드를 참조하세요.

JVM 메모리 설정을 조정할 때 다음 중요한 요소를 고려하세요.

• 지정된 기간 동안 활성 상태인 FlowFiles 또는 NiFi 데이터 레코드의 수입니다. 이 수에는 역압력 또는 큐에 대기 중인 FlowFiles이 포함됩니다.

• FlowFiles에 정의된 특성 수입니다.

• 프로세서에서 특정 콘텐츠를 처리하는 데 필요한 메모리 양입니다.

• 프로세서가 데이터를 처리하는 방식:

  • 스트리밍 데이터
  • 레코드 지향 프로세서 사용
  • 모든 데이터를 한 번에 메모리에 보관

이러한 세부 정보는 중요합니다. 처리하는 동안 NiFi는 각 FlowFile에 대한 참조 및 특성을 메모리에 보유합니다. 성능이 최고 상태인 경우 시스템에서 사용하는 메모리 양은 라이브 FlowFiles의 수와 포함된 모든 특성에 비례합니다. 이 숫자에는 큐에 대기된 FlowFiles가 포함됩니다. NiFi는 디스크로 교환할 수 있습니다. 그러나 성능이 저하되므로 이 옵션을 사용하지 마세요.

또한 기본 개체 메모리 사용량에 유의하세요. 특히 메모리에 개체를 저장할 수 있을 만큼 힙을 크게 만듭니다. 메모리 설정을 구성하기 위한 팁은 다음과 같습니다.

• 설정 -Xmx4G부터 시작하여 필요에 따라 메모리를 보수적으로 늘려 대표 데이터 및 최소 역압력으로 흐름을 실행합니다.
• 설정 -Xmx4G부터 시작하여 필요에 따라 클러스터 크기를 보수적으로 늘려 대표 데이터 및 최대 역압력으로 흐름을 실행합니다.
• VisualVM 및 YourKit와 같은 도구를 사용하여 흐름이 실행되는 동안 애플리케이션을 프로파일합니다.
• 힙을 보수적 늘려 성능이 크게 향상되지 않는 경우 흐름, 프로세서 및 시스템의 다른 측면을 다시 디자인하는 것이 좋습니다.

추가 JVM 매개 변수

다음 표에는 추가 JVM 옵션이 나와 있습니다. 또한 초기 테스트에서 가장 잘 작동하는 값을 제공합니다. 테스트는 GC 활동 및 메모리 사용량을 관찰하고 신중한 프로파일링을 사용했습니다.

매개 변수	설명	JVM 기본값	권장
InitiatingHeapOccupancyPercent	표시 주기가 트리거되기 전 사용 중인 힙의 양입니다.	45	35
ParallelGCThreads	GC에서 사용하는 스레드 수입니다. 이 값은 시스템에 대한 전반적인 영향을 제한하기 위해 제한됩니다.	vCPU 수의 5/8	8
ConcGCThreads	병렬로 실행할 GC 스레드 수입니다. 이 값은 제한된 ParallelGCThreads를 고려하여 증가합니다.	ParallelGCThreads 값의 1/4	4
G1ReservePercent	예약 메모리를 사용 가능한 상태로 유지하기 위한 백분율입니다. 이 값은 전체 GC를 방지하는 데 도움이 되도록 공간 소모를 방지하려는 경우 증가합니다.	10	20
UseStringDeduplication	동일한 문자열에 대한 참조를 식별하고 중복을 제거할지 여부입니다. 이 기능을 켜면 메모리가 절약됩니다.	-	present

NiFi bootstrap.conf에 다음 항목을 추가하여 이러한 설정을 구성합니다.

java.arg.17=-XX:+UseStringDeduplication
java.arg.18=-XX:G1ReservePercent=20
java.arg.19=-XX:ParallelGCThreads=8
java.arg.20=-XX:ConcGCThreads=4
java.arg.21=-XX:InitiatingHeapOccupancyPercent=35

ZooKeeper

내결함성을 향상하려면 ZooKeeper를 클러스터로 실행합니다. NiFi 배포 대부분이 ZooKeeper에 상대적으로 적당한 부하를 가할지라도 이 방법을 사용합니다. ZooKeeper에 대한 클러스터링을 명시적으로 켭니다. 기본적으로 ZooKeeper는 단일 서버 모드에서 실행됩니다. 자세한 내용은 ZooKeeper 관리자 가이드의 클러스터형(다중 서버) 설정을 참조하세요.

클러스터링 설정을 제외하고 ZooKeeper 구성에 기본값을 사용합니다.

대규모 NiFi 클러스터가 있는 경우 더 많은 수의 ZooKeeper 서버를 사용해야 할 수 있습니다. 클러스터 크기가 작을수록 더 작은 VM 크기 및 표준 SSD 관리 디스크로 충분합니다.

참가자

Microsoft에서 이 문서를 유지 관리합니다. 원래 다음 기여자가 작성했습니다.

보안 주체 작성자:

• Muazma Zahid | 수석 PM 관리자

비공개 LinkedIn 프로필을 보려면 LinkedIn에 로그인합니다.

다음 단계

이 문서의 자료와 권장 사항은 다음의 여러 출처에서 제공되었습니다.

• 실험
• Azure 모범 사례
• NiFi 커뮤니티 정보, 모범 사례 및 설명서

자세한 내용은 다음 자료를 참조하세요.

• Apache NiFi 시스템 관리자 가이드
• Apache NiFi 메일링 목록
• 고성능 NiFi 설치를 설정하기 위한 Cloudera 모범 사례
• Azure Premium Storage: 고성능을 위한 설계
• Linux 또는 Windows에서 Azure Virtual Machines 성능 문제 해결

관련 참고 자료

• Apache NiFi용 Helm 기반 배포
• Azure Data Explorer 모니터링
• 최신 데이터 웨어하우스를 위한 DataOps
• 데이터 웨어하우징 및 분석