Snowflake Summit 2025 最速レポート2日目②
-Tech Debt Reduction and Renovation in Apache NiFi 2-

DATUM STUDIOの原戸です。
Snowflake Summit 2025のDay2に開催された「Apache NiFi 2」のセッションに参加しましたので、ご紹介します。
本セッションでは、Snowflakeに新たに取り込まれたApache NiFi 2について、ロードマップ作成者が本バージョンでの目標と実装においてこれまでの経緯も踏まえて解説されたものです。

Apache NiFiの進化と技術的負債への取り組み

Apache NiFiは、2014年にApache Software Foundationへ寄贈され、2015年にトップレベルプロジェクトとして昇格したのち、2016年にバージョン1.0をリリースしました。その後も安定的な成長を遂げてきましたが、バージョン2.0への移行は2021年の議論開始から2024年の正式リリースまで約3年の期間を要しました。この長い期間を要した理由は、蓄積された技術的負債への対応でした。

NiFi 2の開発において重視されたのは、互換性と新機能追加のバランスです。具体的には、Javaのバージョンアップ、フレームワーク依存性の見直し、フロントエンドの再構築などが行われました。これに加えて言語機能の拡張、メジャーバージョン変更への対応、ユーザーインターフェースの改善も含まれました。

2023年11月から2024年7月までに行われた4回のマイルストーンリリースでは、約1,700件のJira Issueが対応され、最終的に2024年11月のNiFi 2.0.0の正式リリース時にはさらに358件が解決されました。このプロセスを通じてNiFiは技術的負債の整理を進め、新たな基盤を整えました。

 Apache NiFi 2では、最小JavaバージョンをJava 8からJava 21へと大幅に引き上げました。Java 21は、マイルストーンリリースの直前に登場した最新のバージョンであり、5年以上のセキュリティ更新が保証されていること、非同期処理を効率的に行う仮想スレッドが実装されていることなど、NiFi 2に最適な特性を備えていました。これらの改善によって、NiFiは長期的な安定性とパフォーマンス向上を達成しました。

また、技術的負債の削減に特に注力しました。主な取り組みとして、古いJava 8のサポート終了、非推奨となったコンポーネントやプロパティの削除、メンテナンスされていない統合機能の排除、XMLによるフローシリアライズ機能や重複する機能の撤廃など、抜本的な整理を行っています。

技術的負債の解消を目指し、コードベースや配布パッケージの大幅な整理を行いました。具体的には、NiFi 1.28.1から2.0.0への更新時に約70万行のコードを削除し、約41万行を追加することで、全体で28万8000行のコードを削減しました。また、配布パッケージのサイズを約1.2GBから683MBへと大幅に縮小し、NARバンドル数を135から109に、Mavenモジュール数を801から645に整理しました。

さらに、古くメンテナンス困難な機能も積極的に排除しました。削除された機能には、XMLフローシリアライゼーション、Apache Knoxでのシングルサインオン、Kerberos SPNEGO認証、RocksDBリポジトリ、TLSツールキットなどが含まれました。これにより、NiFiはメンテナンス性や配布の効率性が向上し、将来的な安定運用に向けた基盤を整えました。

 技術的負債の解消を進めていくために、内部の構造的な改善と機能の大幅な刷新を行いました。日付と時刻の処理をSimpleDateFormatからより現代的なDateTimeFormatterへ移行し、コンポーネント再構成を容易にするmigrateConfigurationおよびmigrateRelationshipsといった新しいメソッドを導入しました。

さらにPythonとの統合を強化し、ネイティブなPython 3プロセッサのサポートを開始しました。GitHubおよびGitLabを用いたフローのバージョン管理、Kubernetesでのクラスター構築の効率化、Angular 18を利用したフロントエンドの再構築やダークモード対応など、ユーザーインターフェースも全面的に刷新しています。また、Jetty 12およびSpring 6を導入することで、フレームワークの基盤を最新化し、保守性と拡張性を向上させています。

同時に、インフラと依存関係の全面的な刷新も進めました。Gitサービスを利用したフローバージョン管理を強化し、NiFi Registryに依存せずにGitHubやGitLabのブランチ管理を可能にしました。また、Kubernetesを利用したクラスタリング機能を導入し、ZooKeeperなしでのスケーラブルな展開を実現しました。

フレームワークの主要ライブラリの最新化も行われました（具体的なバージョン移行は、下記の表をご参照ください）。
ダークモードやライトモードなどのテーマ機能を追加し、ユーザー体験を改善しました。さらに、主要なライブラリを最新バージョンに更新することで、Jetty、Spring　Framework、Servlet APIなどを現代化し、全体的な保守性やパフォーマンスの向上を図りました。

 これまでの行いにより、技術的負債の削減と維持管理の最適化を行うことができました。未管理の機能を維持する際に発生する隠れたコストやフレームワークの変更に伴う大規模な更新、直接依存関係の異なるリリースサイクルへの対応などの問題を解決するため、積極的に不要な機能を削除しました。
また、不必要なコードや依存関係を削減することで、潜在的な脆弱性を減少させ、頻繁なアップデートによって迅速な脆弱性対応を可能にしました。コード量やモジュール数を削減することでビルドサイズを縮小し、ストレージや帯域幅の効率化を図り、全体的なライフサイクル運用を最適化しました。これらの施策により、セキュリティと運用効率が著しく向上しています。

今後のApache NiFi 2について

最後に、これからのApache NiFi 2について説明がありました。将来的な拡張性とメンテナンス性を考慮し、NiFi 2は継続的な改善とモダナイズを進める計画です。具体的には公開APIやNiFi改善提案の独立したバージョンを導入し、新機能と既存機能の間で明確な互換性を維持するように定めます。これによって段階的な変更が可能になり、ユーザーが安心して最新の機能を活用できるようになります。

また、設定の簡素化やクラスタリングの効率化、フローバージョニングおよびフロー開発プロセスのさらなる改善も計画されています。NiFiの利用者はより効率的にシステムを管理し、迅速に機能を展開できるようになります。

今後の大きな変更としては、NiFi改善提案プロセス（NiFi Improvement Proposal）を通じて公開APIへの追加機能に関する議論と合意を進めること、自動化されたコンポーネント移行機能を導入して手動による変更作業を減らすこと、小規模リリースの頻度を上げることで迅速な機能改善を図ることが挙げられます。

さらに、内部と外部の改善可能領域として、アプリケーション設定からXMLを完全に取り除き、プロパティ設定を簡潔化すること、スケーラブルなクラスタリングを実現するために通信プロトコルや実装を簡素化すること、そしてGitベースでのフロー開発を標準化してフロー作成プロセスをよりシンプルで効率的なものにすることなどが検討されています。これらの取り組みを通じて、Apache NiFi 2は継続的な進化と改善を続け、ユーザーの要求に柔軟に対応できるシステムを構築していきます。

まとめ

本セッションでは、Apache NiFi 2が技術的負債を削減し、継続的な近代化と効率化を進める方向性が明示されました。これからのApache NiFi 2の進化に期待ですね！