ヤフーで Apache NiFi を利用したデータ連携用プラットフォームの開発運用を担当している寺田です。
本記事では、ヤフーでの Apache NiFi の活用スタイルと OSS コミュニティとの関わり方、プロダクトの最新動向を紹介します。アドベントカレンダーらしく2021年のまとめを意識して今年の動向を中心にまとめました。
ヤフーでの Apache NiFi の活用
Apache NiFi とは
Apache NiFi とは、データを扱う多種多様なシステム間でデータ連携するためのデータフローをグラフィカルに作成・管理し、実行を自動化できるソフトウェアです。Apache Software Foundation (ASF) で OSS (オープンソースソフトウェア) として公開 されています。
Apache NiFi の公式ページでもソフトウェアの特徴が紹介されていますが、ソフトウェアを利用している立場も踏まえて改めて紹介すると以下の特徴が挙げられます。
- ユーザインタフェースは Web UI で完結するため、ウェブブラウザから手軽に利用できる。
- フローは用意されたコンポーネント(プロセッサ・コントローラサービス)を組み合わせるだけで設計可能なため、実現したい動作のためのコードを書く必要がない。
- 標準で用意されているプロセッサが400を超える種類があり、メジャーなプラットフォームとはほぼ手を加えることなく接続が可能である。さらにカスタムプロセッサを開発して独自のプロセッサを利用することも可能である。
- UI 上でフローを設計したらそのまますぐに動かせる。
- Apache NiFi サーバーを複数台構成にしてクラスタ化できるため、スケールアウトによる分散処理やサービスの可用性を高めることも可能である。また、処理キューにバックプレッシャーなどの機能も備わっていて、作成したフローを安定して動かすことが可能である。
- 複数のユーザ認証方法に対応していることに加え、操作権限を細かく設定することが可能なのでセキュリティ面で優れている。
ヤフーでの活用スタイル
ヤフーでは Apache NiFi を継続して活用しています。約2年前に公開した 前回の Apache NiFi に関する記事 のときには社内に Apache NiFi を導入して活用を始めているという段階でしたが、その後引き続きサービスでのデータ活用用途や社内業務の用途等で活用されています。現在、ヤフー社内で運用している NiFi クラスタの数 (= 利用しているサービス数) は55になりました (2021年11月末時点)。
ヤフーは100を超える多数のサービスを提供しています。それを支えるために、自社でデータ分析環境やオブジェクトストレージ、データベース等をオンプレミスなプラットフォームとして持っています。
- ビッグデータ分析環境・データウェアハウス: Apache Hadoop(関連記事), Trino (Presto), Teradata
- 分散オブジェクトストレージ: Dragon
- 分散メッセージキュー: Apache Pulsar
- データベース: MySQL, NoSQL (Apache Cassandra)(関連記事)
このような多様なプラットフォームを保有している背景から、サービスや案件個別にさまざまなプラットフォーム間でデータを連携したいという需要が発生します。細かなデータ連携を実現するためには、利用者がカスタマイズできる形でプラットフォームを展開することが必要です。その面で Apache NiFi は都合がよく使い勝手が良いプロダクトです。コードを書かなくて済むケースがほとんどですので、社内のエンジニアだけでなく、データアナリストやビジネスサイドの業務の担当者も活用されています (ただし SQL が理解できる程の知識は必要です)。
より詳細な情報は 前回の記事 も合わせてご参照ください。
OSS コミュニティとの関わり
Apache NiFi は、それ自体をクラウドサービスとして提供している企業やユーザとしてソフトウェアを利用している企業等のソフトウェアエンジニアが中心となって OSS 上で日々開発が進められています。私たちのチームも単に利用するだけではなく、OSS 活動に参加しています。
社内利用では、ライセンスが Apache License 2.0 である OSS 版 Apache NiFi をフォークし、公式のリリースバージョンに対して社内向けの独自修正を追加したパッケージを作成して利用しています。この方法を採用している理由は、前述した社内独自のプラットフォームにつなぐためのコード修正やコード追加が必要な箇所があり、OSS 版のプロダクトを直接利用することができないためです。
修正・追加したコードの中でも、ヤフー以外にも広くメリットがあるような修正内容については、例えば次のようにフィードバックもしています。
- RPM パッケージに関わること (例: NIFI-5886, NIFI-6827)
- マルチドメイン証明書やワイルドカード証明書に起因する不具合の修正 (例: NIFI-7730, NIFI-5752)
- Toolkit をより便利にする (例: NIFI-6112, NIFI-7681)
- 依存ライブラリの更新等のセキュリティに関することの修正
- Prometheus メトリクスに関する不具合の修正や改善 (例: NIFI-6715, NIFI-6716, NIFI-6723)
その他のコミュニティ活動と、参加のメリット
その他 OSS コミュニティ活動として、次のようなことにも取り組んでいます。
- 新しいバージョンのリリース時に実施される Release Vote への積極的な参加
- OSS コミュニティの Slack やメーリングリスト でのヘルプやコメント対応も多くはありませんが機会があるときにやっています。
開発者としては、社外の優れたエンジニアからコメントをもらえるのでモチベーションが向上し、また英語の勉強にもなっています。また、会社の制度として「OSSデベロッパー認定制度」があり、個人に対して活動を支援してもらうことで、開発しやすく助けられています。
Apache NiFi の2021年の最新動向と将来について
ここまで、ヤフーでの Apache NiFi の活用スタイルと OSS コミュニティとの関わり方を説明しました。最後に、今年 (2021年) 1年間の Apache NiFi の最新動向を振り返り、将来どのようなプロダクトの発展が期待されるかを紹介します。
2021年の公式リリース
2021年の1年間では、Apache NiFi 1.13 (2021年3月), 1.14 (2021年7月), 1.15 (2021年11月) の3つのバージョンがリリースされました (厳密には修正バージョンも入れるともう少しあります)。最新動向として、最近追加された注目すべきアップデートや将来についての期待をいくつか紹介します。
注目すべきアップデート
以下に挙げる項目は私が注目している最近のアップデートのトピックです。これらは一部なので興味がある方はぜひ リリースノート を見てください。
セキュリティの向上
パブリッククラウド環境で Apache NiFi が利用される場面も増加した背景から、セキュリティ面が最近特に強化されています。特に注目されるアップデートを以下で紹介します。
- 初期構築時のデフォルトがセキュア (https) 構成になり、ユーザ認証が必須になった (NIFI-8220)。
- Apache ZooKeeper の TLS 化に対応した (外部・内蔵 ZooKeeper どちらも) (NIFI-7203)。
ヤフーでは、活用スタイルで記述したように複数サービスがマルチクラスタ・マルチテナントで NiFi クラスタや ZooKeeper を利用している背景から、適切な権限管理やアクセス制限を実施しています。そのセキュリティをさらに強化する目的でこれらの機能を社内クラスタにも取り入れることを検討しています。
コードベースの統合
これまで分割され管理されていた Apache NiFi, Apache MiNiFi, Apache NiFi Registry のコードが1つのリポジトリに統合されました (NIFI-8798)。
これにより次のようなメリットが生まれました。
- 開発面: 開発の効率が向上する。Apache NiFi と Apache NiFi Registry 間にあった重複コードの統合や、データモデルを共用して利用することで相互連携のスピードアップが図れる。
- 利用面: リリースサイクルが同期するようになることでどのバージョンを利用すれば良いかが一目瞭然になる。
ヤフーでは Apache NiFi と Apache NiFi Registry を合わせて活用してフローの設計・管理やデプロイの効率化を図っている背景から、このアップデートにより Apache NiFi Registry がより使いやすいプロダクトになることで利用効率の面で大きな恩恵を得られると期待されます。
ユーザインタフェースの改善
ユーザインタフェース (UI) もアップデートが加えられています。特に注目される機能改善を以下で紹介します。
- プロセッサのプロパティに依存関係が設定され、特定のオプションが選択されているときにのみ必要なプロパティが出現するようになり、設定画面がわかりやすくなった (NIFI-1121)。
- パラメータコンテキストが継承関係を持てるようになり、共通のパラメータを管理しやすくなった (NIFI-8487)。
- フローの途中のプロセッサに「Primary Node Only」の実行スケジュールを指定したときに警告が出るようになった (NIFI-8300)。
- プロセッサのメニューから「Run Once」の実行が可能になり、フロー開発時のデバッグが便利になった (NIFI-8188)。
ヤフー社内でより多くの開発者に Apache NiFi の操作に慣れ親しんで正しく利用してもらうためにも、ユーザインタフェースの継続的な改善はとても重要です。また、長い期間使うにつれて多くの種類のフローや類似したフローが生まれる状況は防ぐのが難しいと思うので、特にそのような場面で継承化されたパラメータコンテキストを便利に利用できる場面も考えられます。これらの新機能を取り入れて社内でも多くの人がより便利でわかりやすく Apache NiFi を利用できることが期待されます。
Stateless 実行エンジン
Apache NiFi フローの実行エンジンとして Stateless NiFi と呼ばれる新しいランタイムエンジンで実行する機能にもアップデートが加わっています。これは、従来の Apache NiFi で設計したフローを Stateless なランタイムエンジンで実行できるようにする試みです。Stateless エンジンの特徴として、通常の Apache NiFi と異なり基本的にデータはメモリ上に載っていたり、実行エンジンを NiFi クラスタ全体のリソースから分離することでクラスタ内の他フローの影響を受けにくかったり、取得するデータソースの特性を理由にデータが永続化されないことによるメリットを受けたいとき (例えば Apache Kafka からの Exactly Once セマンティクスを利用した consume 等) に利用可能、といった特徴があります。Stateless エンジンを動かすプラットフォームとして、専用のサーバや Kubernetes も想定できますが、Apache NiFi バージョン 1.15 から Stateless エンジンを呼び出すための専用プロセッサ (ExecuteStateless) が作成されたのでより便利に利用できるようになりました (NIFI-9239)。
Kubernetes での実行
Apache NiFi のクラスタそのものを Kubernetes 環境で実行する試みも注目されるトピックです。
従来の Apache NiFi サーバーは実機サーバーまたは仮想マシンで動かすことが前提でした。しかし、クラスタ管理やスケールアウトに柔軟に対応するためにモダンな環境である Kubernetes の恩恵を受けたい需要も高まっていて、特に最近は Kubernetes での Apache NiFi 環境構築の話が増えています。Slack やメーリングリストで Apache NiFi を Kubernetes クラスタ上で動かすためのディスカッションやアドバイスが頻繁にされているのを見かけたり、 Kubernetes 化に関するブログ記事も増え始めている印象です。NiFi はアプリケーションの特性上、ローカルディスクに永続データを持つようなステートフルが前提になっているアプリケーションなので工夫が必要なところに課題があります。NiFi で利用するデータを可能な限りインメモリか外部ストレージに寄せるか、永続ストレージが利用可能なマネージド Kubernetes クラスタを活用していく等の手段が考えられます。
Apache NiFi の将来
特に Apache NiFi の Kubernetes 化と、Stateless 実行エンジンに関する領域で新しい活用のチャンスが広がっていないか興味を持っています。
ヤフー社内では Kubernetes クラスタを利用した NiFi クラスタ構築の検証やパフォーマンス検証を開始している段階です。既存の機能を生かしながらより便利な実行環境に進化していくところは今後期待できそうなところであるし、私たちも便利な使い方を探しながら開発もしていきたいです。検証やサービスを稼働させていく過程で、OSS に貢献できる部分を見つけながら、ヤフー社内でより便利に使えるデータ連携の環境を整備していきたいと考えています。
また、Apache NiFi の次のメジャーバージョンアップの動きもあります。現在バージョン1系を提供している Apache NiFi を、メジャーバージョンアップとして Apache NiFi 2.0 をリリースする動きです。2.0 のゴールとして次のような要素がすでにプロポーザルとして挙げられています。
- 互換性の問題で残っている古い機能や、重複している類似機能の削除
- Java 11 が要件になる (現在は Java 8 と Java 11 で利用可能)
- NiFi Registry や Stateless NiFi で標準的に利用されている Versioned Component モデルをデータフローを表現するモデルとして統一して採用
- これにより類似機能の XML でのフロー表現やテンプレート機能を削減し、管理が容易にすることを目指す
より詳細な情報は以下のドキュメントをご参照ください。
https://cwiki.apache.org/confluence/display/NIFI/NiFi+2.0+Proposed+Release+Goals
おわりに
本記事では、ヤフーでの Apache NiFi の活用スタイルと OSS コミュニティとの関わり方、プロダクトの最新動向を紹介しました。
私自身はまだ OSS 貢献の量や質としては自慢できるほどできていないので、引き続きモダンな環境を取り入れながら社内プラットフォームやプロダクト自体を改善していきたいと思っています。
Apache NiFi, Apache Hadoop, Apache Pulsar, Apache Cassandra, Apache Kafka は、The Apache Software Foundation の米国およびその他の国における登録商標または商標です。
こちらの記事のご感想を聞かせください。
- 学びがある
- わかりやすい
- 新しい視点
ご感想ありがとうございました