Apache NiFiとは？FlowFile中心の設計と2系移行の判断を実装者目線で解説【2026年版】

Apache NiFiは、システム間のデータ移動を画面上のフロー図として組み立て、そのまま常時稼働させるデータフロー基盤です。2026年8月時点の最新リリースは2026年6月18日公開の2.10.0で、実行にはJava 21が必要になります。1系は1.28.1で打ち止めとなり、サポートは2024年12月8日に終了しました。この記事では、FlowFileと3つのリポジトリからなる実行モデル、初回起動の設定、バックプレッシャーの調整、Python Processor APIによる拡張、そして2系への移行時に確認すべき互換性を扱います。パイプライン全体の設計論はデータパイプラインの構成要素をまとめた記事に譲りました。

まとめ｜Apache NiFi採用を分ける3条件と2系移行の判断ライン

NiFiが効いてくる条件は3つあります。連携先が多様で、ファイル・データベース・HTTP API・メッセージキューが混在すること。データが常時流れ続け、日次バッチでは遅延が許されないこと。そして「どのレコードがいつどこを通ったか」を後から追跡する要求があること。3つ目が不要なら、コードで書くETLのほうが保守は軽く済みます。

NiFiの中心にあるのはFlowFileという単位です。属性のマップと実データの本体が対になって流れ、プロセッサが1件ずつ処理してコネクションのキューへ渡します。この「1レコード1ファイル」のモデルが来歴追跡とバックプレッシャーを成立させている反面、小さなレコードを大量に流すとオーバーヘッドが無視できません。逃げ道はレコード指向プロセッサでまとめて扱うことです。

移行判断はもっと単純です。1系はサポートが切れており、新規構築なら2系一択になります。既存の1系フローを持ち込む場合は、2.0.0で削除されたコンポーネントを使っていないかを先に洗い出してください。採用を見送るラインは第8章に条件付きで示しました。

FlowFileと3つのリポジトリで構成されるNiFiのデータフロー実行モデル

NiFiの設定項目がどこに属するかを取り違えると、動かない設定を延々と直すことになります。登場人物を分けて押さえます。

属性マップとコンテンツの2部構成で流れるFlowFileの実体

公式のOverviewはFlowFileを「キーと値の属性文字列のマップと、それに紐づく0バイト以上のコンテンツ」と定義しています。属性にはファイル名・取得元パス・UUID・独自に付けたメタデータが入り、コンテンツには実データのバイト列が入ります。保存される場所は別々です。属性はメモリとFlowFileリポジトリに、コンテンツはコンテンツリポジトリへ置かれます。

属性だけを見て分岐するルーティングは、コンテンツを読まずに済むため軽く動きます。RouteOnAttributeで振り分け、EvaluateJsonPathで本文から属性を抜き出してから振り分ける。この順序を守るだけで、大きなファイルを何度もディスクから読み直す無駄が消えます。

FlowFile・コンテンツ・プロヴェナンスの3リポジトリの役割分担

NiFiは3つのリポジトリを持ちます。FlowFileリポジトリはwrite-ahead logで各FlowFileの現在地と属性を保持し、プロセス障害からの復帰を支えます。コンテンツリポジトリは実データを格納し、複数の物理パーティションに分散配置できる設計です。プロヴェナンスリポジトリは来歴イベントを記録して索引化します。

ディスク設計で失敗しやすいのが、3つを同じボリュームに置くパターンでした。コンテンツの書き込みとプロヴェナンスの索引更新がI/Oを奪い合い、スループットが頭打ちになります。本番では最低でもコンテンツとプロヴェナンスを別ディスクに分けてください。

フローコントローラによるスレッド配分とプロセスグループの再利用

フローコントローラは、公式定義で「プロセスの接続関係を把握し、スレッドとその割り当てを管理する」役割を担います。個々のプロセッサはスレッドを自前で持たず、コントローラから借りて動く構造です。だからプロセッサを増やしても、同時実行スレッドの総量を超えて並列化されることはありません。

プロセスグループは、プロセッサとコネクションをまとめた再利用単位です。入力ポートと出力ポートで外部とつながるため、内部を差し替えても呼び出し側の接続は変わりません。2系ではプロセスグループごとに実行エンジンを選べるようになり、常時稼働のTraditional（Standard）と、1件ずつトランザクション的に処理するStatelessの2種類から指定します。既定は親グループからの継承です。

プロセッサとコネクションで組むフロー構築の初期設定と実装の手順

NiFiは起動してブラウザを開けば触れますが、2系は初回の認証まわりが1系と違います。順に見ていきます。

初回起動時のHTTPS 8443接続と単一ユーザー認証の資格情報

Administration Guideによれば、HTTPSポートの設定キーはnifi.web.https.portで既定値は8443です。セキュリティ設定を与えないまま起動した場合、NiFiは127.0.0.1にバインドします。リモートのサーバーに入れて手元のブラウザから開こうとして接続できない、という詰まり方はここが原因になります。

単一ユーザー認証では、初回起動時に資格情報が自動生成されます。ユーザー名は36文字のランダムなUUID、パスワードは32文字のランダム文字列で、保存時はbcryptでハッシュ化されます。生成された値は起動ログに出るため、コンソール出力を流してしまうと再取得できません。検証環境ならnifi.shのset-single-user-credentialsで自分で決めた値に置き換えるほうが手戻りが減ります。

プロセッサの配置からリレーション設定までの最小フローの構築手順

最小構成のフローは、次の順で組みます。

1. キャンバスにプロセッサをドラッグし、種類を選ぶ（取得系ならGetFileやInvokeHTTP）
2. プロパティタブで接続先やパスなど必須項目を埋める
3. 2つ目のプロセッサを置き、1つ目からドラッグしてコネクションを張る
4. コネクションのダイアログで、渡すリレーション（successやfailureなど）にチェックを入れる
5. 未処理のリレーションを自動終了に設定し、警告アイコンを消す

4番目と5番目を飛ばすと、プロセッサに警告が出たまま起動できません。NiFiは全リレーションの行き先が決まっていることを起動条件にしています。failureを握りつぶすか、リトライ用のループへ戻すか。この判断をフロー設計の最初に決めておくと、後から全プロセッサを開き直す作業が消えます。

コントローラサービスとパラメータコンテキストによる設定の外出し

データベース接続プールやレコードの読み書き定義は、プロセッサに直接書かずコントローラサービスとして定義します。1つのサービスを複数プロセッサから参照できるため、接続先の変更が1箇所で済む構造です。JDBC接続ならDBCPConnectionPool、JSONの読み取りならJsonTreeReaderが代表格になります。

環境ごとに変わる値はパラメータコンテキストへ逃がします。開発と本番でホスト名やパスが違う場合、フロー本体は同じままコンテキストだけ差し替えられる設計です。2.10.0では継承したパラメータの値を別のパラメータから参照できるようになり、共通部分を親コンテキストに置いて環境固有の値だけ子で上書きする構成が組みやすくなりました。

バックプレッシャーとスケジューリングで決めるスループットの設計指針

NiFiのチューニングは、キューの詰まりをどこで止めるかという話に集約されます。

オブジェクト閾値10,000件を起点にしたキュー滞留の設計判断

コネクションにはバックプレッシャーの閾値があり、User Guideではオブジェクト数の既定を10,000 FlowFilesとしています。キューがこの件数に達すると、上流のプロセッサはスケジュールされなくなります。データを捨てるのではなく、流入そのものを止める仕組みです。

この既定値をそのまま使ってよいかは、1件あたりのサイズで決まります。数KBのJSONを流すフローなら10,000件で数十MB程度に収まり、そのままで困りません。数百MBのファイルを扱うフローで10,000件まで溜め込むと、コンテンツリポジトリが先に枯渇します。大きいファイルを扱うコネクションでは、件数ではなくデータサイズ側の閾値を主軸にして、件数を数十件まで絞ってください。

同時実行タスク数とスケジューリング戦略の決め方と観測すべき指標

プロセッサごとに同時実行タスク数を指定できますが、増やせば速くなるとは限りません。全プロセッサの合計がフローコントローラの持つスレッド数を超えると、互いにスレッドを奪い合ってレイテンシが跳ねます。まず全体のスレッド上限を決め、そのうえでボトルネックのプロセッサにだけ配分するのが順序です。

スケジューリング戦略は、外部を叩く系のプロセッサでタイマー駆動、上流から流れてくる処理でイベント駆動という切り分けになります。ListFileのような一覧取得を短い間隔で回すと、同じファイルを何度も検出して重複を生みかねません。観測すべきはコネクションの滞留件数と、プロセッサの平均タスク実行時間の2つです。滞留が単調増加するコネクションが見つかれば、その直下のプロセッサが律速だと判断できます。

Python Processor APIとレコード指向処理で広げる拡張実装の選択肢

標準プロセッサで届かない処理をどう書くか。2系では選択肢が増えました。

Pythonで書く3つのプロセッサ基底クラスと対応バージョン

Python Developer Guideは「Python API は NiFi を動かすマシン上に Python 3.10、3.11、3.12 のいずれかが必要」と記載しています。3.13以降は対象外なので、コンテナイメージを新しくしすぎると読み込みに失敗します。基底クラスは3つです。

FlowFileTransformはFlowFile単位で属性とコンテンツを変換し、RecordTransformはJSONやAvroのレコード1件ずつを扱い、FlowFileSourceは入力コネクションなしに新しいFlowFileを生成します。配置先はnifi.python.extensions.source.directory.defaultが指すextensionsディレクトリで、作業領域はnifi.python.working.directoryに作られます。

レコード指向プロセッサとPython実装の使い分けを決める基準

CSVをJSONへ変換する、特定カラムだけ抜き出す、スキーマを付け替える。この程度の加工にPythonを書く必要はありません。RecordReaderとRecordWriterのコントローラサービスを定義し、ConvertRecordやQueryRecordに任せるほうが速く、1ファイル内の複数レコードをまとめて処理できるぶんFlowFileのオーバーヘッドも減ります。QueryRecordはSQL文でフィルタや集計を書けるため、条件分岐の大半はここで吸収できます。

Pythonへ倒すのは、外部ライブラリが要る処理に限ります。機械学習モデルの推論、独自フォーマットのパース、社内APIのSDK呼び出しといった領域です。判断基準は「標準プロセッサの組み合わせが4つを超えるか」。それ未満なら画面で組んだほうが後任も読めます。なお、外部システムとの単純な入出力だけならNiFiではなくKafka Connectのコネクタ運用をまとめた記事の方式が向く場面もあります。

NiFi 2系移行で確認する互換性とRegistry非推奨後の構成管理

1系から持ち込むフローがある場合、確認の順番を間違えると移行が長引きます。

Java 21要件と1.28.1で終了した1系サポートの現在地

Administration Guideは実行要件を「Requires Java 21」と明記しています。1系はJava 8や11でも動いていたため、既存サーバーのJDKを上げるところから始まる案件が大半でした。アプリケーションサーバーと同居している環境では、この時点でホストを分ける判断が要ります。

1系の最終版は1.28.1で、End of Supportは2024年12月8日でした。公式ダウンロードページも1.28を1系最後のマイナーリリースと位置づけ、2系への移行を推奨しています。セキュリティ修正が出ない状態が1年半以上続いているため、外部公開しているNiFiを1系のまま置いておく判断は取りづらくなりました。

2.0.0で削除されたプロセッサ群の棚卸しと代替手段の洗い出し

2.0.0は2024年11月4日公開で、Breaking Changesに多数のコンポーネント削除が並びます。移行前に既存フローで使っていないか確認したいのは次の面々です。

• PutIceberg プロセッサと関連サービス
• HBase系のプロセッサとサービス一式
• Kafka 2.6系のプロセッサ
• ListenBeats・ListenRELP・ListenSMTP・ListenTCPRecord
• DecryptContent・PutKudu・Yandex系・QueryDNS・QueryWhois・ExtractTNEFAttachments

加えてリポジトリ暗号化のサポートとShell User Group Providerも削除され、Distributed Cache Servicesは名称から「Distributed」が外れました。Kafka連携は新しい世代のプロセッサへ置き換えれば済みますが、HBaseやKudu向けの連携は代替が標準に無いため、フロー外の手段を検討することになります。棚卸しは移行作業の最初に済ませてください。ここを飛ばすと、2系で起動した瞬間に大量のプロセッサが読み込み失敗になります。

NiFi Registry非推奨後に選ぶGitベースの構成管理

フローのバージョン管理を担ってきたNiFi Registryは、2.8.0のリリースノートで非推奨と明示されました。推奨される代替は、GitをFlow Registry Clientとして直接指定する方式です。別サービスを立てずに、フロー定義をリポジトリへコミットする構成になります。

2.10.0ではRegistry Clientからのブランチ作成に対応し、gitベースのクライアントがauthorとcommitterの両方の情報を扱えるようになりました。これから構成管理を組むなら、Registryを新規に立てる選択はしないでください。既にRegistry運用がある環境でも、フロー定義のエクスポート先をGitへ寄せる移行計画を先に描いておくほうが安全です。

Airflow・Kafka Connect・Airbyteとの守備範囲の切り分け基準

「NiFiとAirflowはどちらを使うべきか」という問いは、実行モデルの違いを見れば大半が解けます。

ワークフローオーケストレータとNiFiの守備範囲を並べた比較

両者は競合ではなく、担当する時間軸が違います。

日次で動く集計ジョブの依存関係を管理したいならApache Airflowの仕組みを解説した記事の方式が合います。逆に、届いたファイルを即座に振り分けて複数の宛先へ送り続けるならNiFiです。

Kafka Connect・Airbyte・Debeziumと重なる領域の切り分け

データ連携ツールとしては近い位置にいるものの、前提はそれぞれ別です。Kafka Connectはクラスタが既にあることが前提で、Kafkaを中心に据えた入出力に特化しています。Airbyteのコネクタとスケジュール実行を整理した記事で扱ったELTツールは、SaaSやデータベースからDWHへ定期的に同期する用途に寄っています。

データベースの変更を追いかけたいだけなら、Debeziumのコネクタ設定を解説した記事の方式が最短です。NiFiが選ばれるのは、連携先の種類が多く、途中でフォーマット変換や条件分岐が挟まり、しかもその内容が運用中に変わり続ける場合。フローを画面で組み替えられる利点が、他の選択肢を上回るのはこの条件下に限られます。

Apache NiFiを採用しない条件と運用が破綻する失敗パターン

導入判断を曖昧にしたまま入れると、運用フェーズで持て余します。ここは条件を切って言い切ります。

Apache NiFiの採用を見送るべき3つの条件と代替の選択肢

次のいずれかに当てはまるなら、NiFiは見送ってください。第一に、連携先が1〜2系統で、加工内容も固定されている場合。cronで回すスクリプトかマネージドのELTサービスで足ります。JVMとリポジトリ3種を抱える運用コストが見合いません。

第二に、扱うデータが1件あたり数KB未満で、秒間数万件を超える場合。FlowFile単位の管理コストがそのまま効いてきます。レコード指向プロセッサで束ねる手はありますが、それでも足りない規模ならストリーム処理エンジンを選ぶほうが素直です。第三に、フロー定義をコードレビューの対象にしたい組織。NiFiの定義はJSONで出力できるものの、GUIで組んだ差分をレビューする体験はコードほど良くありません。

運用が破綻する3つの失敗パターンと導入前に決めておくべき回避策

よく見る破綻の1つ目は、キャンバスが数百プロセッサの一枚絵になり、誰も全体を把握できなくなるパターンでした。プロセスグループで機能単位に切り、入出力ポートだけを外に見せる規約を最初に決めてください。2つ目は、failureリレーションを全部自動終了にして、データが静かに消えるパターンです。失敗したFlowFileは専用のグループへ集約し、件数を監視対象に入れておきます。

3つ目はディスク枯渇です。バックプレッシャーの閾値を上げたまま下流を止めると、コンテンツリポジトリが埋まってNiFi全体が停止します。閾値の見直しとディスク使用率の監視はセットで設計してください。こうした基盤の設計と運用設計をまとめて外部に任せたい場合は、データ分析基盤構築・MLOps構築支援で要件整理から構築までを承っています。

よくある質問

Apache NiFiの導入検討で実際に挙がる質問を5つ取り上げます。

Apache NiFiは無料で使えますか？

Apache License 2.0で公開されているオープンソースソフトウェアのため、ライセンス費用はかかりません。自前でサーバーを用意して運用する形になり、発生するコストはインフラ費と運用工数です。商用サポートが要る場合は、NiFiをベースにしたディストリビューション製品を検討する選択肢もあります。

NiFiを動かすのに必要なJavaのバージョンは何ですか？

2系はJava 21が必要です。公式のAdministration Guideに「Requires Java 21」と明記されています。1系はJava 8や11でも動作しましたが、1.28.1でサポートが終了したため新規構築の選択肢にはなりません。

NiFiとApache Airflowの違いは何ですか？

NiFiは常時稼働してデータを流し続けるデータフロー基盤で、FlowFile 1件ずつを処理します。Airflowはスケジュールに従ってタスクの依存関係を実行するワークフローオーケストレータです。リアルタイム性が要るデータ移動はNiFi、日次バッチの依存関係管理はAirflowという切り分けになり、両方を併用してNiFiの取り込み結果をAirflowが加工する構成も取れます。

NiFi Registryは今も使えますか？

2.8.0のリリースノートでNiFi Registryは非推奨と明示され、GitをFlow Registry Clientとして直接指定する方式が推奨されています。既存環境が即座に止まるわけではないものの、新規にRegistryを立てる判断は避けてください。2.10.0はRegistry Clientからのブランチ作成にも対応しました。

1系のフローを2系にそのまま持ち込めますか？

使用しているコンポーネント次第です。2.0.0のBreaking ChangesでHBase系・Kafka 2.6系・PutIceberg・ListenRELPなど多くのプロセッサが削除されました。これらを含むフローは読み込みに失敗するため、移行前の棚卸しと代替手段の決定が要ります。検証環境で一度通してから本番へ進めてください。

関連記事

• ETLとは：ELTとの違いとツール選定の観点から、NiFi以外の選択肢を整理しています
• Dagsterとは：アセット指向のオーケストレータとして、NiFiとは別の管理単位を解説しています
• CDC（Change Data Capture）とは：データベースの変更を捕捉する仕組みそのものをまとめています
• ストリーム処理とは：連続的に流れるデータをどう処理するか、バッチとの使い分けを扱っています
• Cloud Composerとは：マネージドのワークフロー基盤として、自前運用との比較材料になります