by Michael Kohs
この記事は、2022/06/17に公開された「Build Hybrid Data Pipelines and Enable Universal Connectivity With CDF-PC Inbound Connections」の翻訳です。
ユニバーサルデータ配信に関するブログの2つ目である前回は、Cloudera DataFlow for the Public Cloud（CDF-PC）が、データレイクハウスやデータウェアハウスの取り込み、サイバーセキュリティ、ログ最適化、さらにIoTやストリーミングデータ収集などのユースケースの実装にどのように役立つかを検証しました。これらのユースケースで重要な要件は、ソースシステムから能動的にデータを引き出すだけでなく、さまざまなソースから中央配信サービスにプッシュされるデータを受信する機能です。
ユニバーサルデータ配信に関するブログ記事の3つ目である今回は、CDF-PC の新機能である Inbound Connections がどのようにユニバーサルアプリケーション接続を可能にし、エッジ、データセンター、1つまたは複数のパブリッククラウドにまたがるハイブリッドデータパイプラインを構築できるのかを詳しく見ていきたいと思います。
インバウンド接続とは何か？
異なるアプリケーション／システム間でデータを移動させる方法には、プル型とプッシュ型の2つがあります。
データをプルする場合、アプリケーションやシステムから情報を取り出すことになります。ほとんどのアプリケーションやシステムは、そこから情報を抽出するための API を提供しています。データベースは JDBC エンドポイントを提供し、ウェブアプリケーションは REST API を提供し、業界特有のアプリケーションは独自のインターフェースを提供することがよくあります。インターフェースの種類に関係なく、NiFi のプロセッサ・ライブラリによって、あらゆるシステムからデータを取り出し、あらゆる宛先に届けることができます。
アプリケーションやシステムがデータを抽出するためのインタフェースを提供していない場合や、ネットワーク接続などの制約によりプル型のアプローチが使えない場合は、プッシュ型が向いています。データをプッシュするということは、ソースアプリケーションやシステムがターゲットシステムに情報を入れるということです。NiFi は、ListenHTTP、ListenTCP、ListenSyslog などの特定のプロセッサを提供し、他のアプリケーション／システムから NiFi にデータを送信し、そこから1つまたは複数のターゲットシステムにデータを配信することができるようにします。これにより、カスタムで管理しにくいアプリケーション間の1:1の統合を構築する必要がなくなります。
NiFi はプッシュパターンを実装するためのプロセッサを提供しますが、次のような確認すべき追加の質問もあります。
- 認証はどのように処理されるのか？誰が証明書を管理し、ソースシステムとNiFi を正しく構成するのか？
- 複数のノードからなる NiFi クラスタを実行する場合、ソースアプリケーションに安定したホスト名をどのように提供するのか？
- どのロードバランサーを選び、どのように設定すべきなのか？
CDF-PC では、Inbound Connections によってデータプッシュ型アプローチをサポートし、外部ソースアプリケーションからフローデプロイメントにデータをストリームすることができます。フローデプロイメントにインバウンド接続のエンドポイントを割り当てることにより、CDF-PC はデプロイメントの前面にあるロードバランサを含む安定したホスト名、ホスト名に対応するサーバ証明書、相互 TLS 認証のためのクライアント証明書を自動的に作成します。また、それに応じて NiFi を設定します。
つまり、データをプッシュするための安全、スケーラブル、堅牢なエンドポイントをセットアップするすべての作業を CDF-PC が行うのです。
図1：CDF-PC はロードバランサ、DNS エントリ、証明書、NiFi 設定等、安定したセキュアでスケーラブルなエンドポイントを提供するために必要なすべての作業を行います。
Inbound Connections を使ってハイブリッドデータパイプラインを構築する
Inbound Connections の一般的なユースケースは、ハイブリッドデータパイプラインです。データパイプラインがエッジデバイス、データセンターのデプロイメント、または複数のパブリッククラウドのシステムにまたがっている場合、ハイブリッドとみなすことができます。
例えば、パブリッククラウドとデータセンターにまたがるハイブリッドデータパイプラインでは、クラウドの NiFi デプロイメントがオンプレミスシステムからのデータ取得を制限されることがよくあります。Inbound Connections を使えば、データフローの方向を逆にし、オンプレミスのシステムから NiFi クラウドのデプロイメントにデータをプッシュすることができるようになります。
図2：オンプレミスとクラウドの NiFi デプロイメントを使ったハイブリッドデータパイプラインの構築
すべてのオンプレミスアプリケーションがクラウド NiFi デプロイメントにデータをプッシュするように設定する代わりに、最も効率的なアプローチは、オンプレミスで NiFi デプロイメントを確立し（Cloudera Flow Management などを使用）、それを使用してすべてのオンプレミスシステムからデータを収集することです。データをクラウドに送信する必要がある場合、Inbound Connectionsを使用してクラウドデプロイメントにデータをプッシュするようにNiFi フローを構成することができます。こうすることで、次のようなメリットを得ることができます。
- クラウドからの着信接続要求に対して、オンプレミスのファイアウォールがオープンになることを避ける
- オンプレミスからクラウドへデータを送信するための一貫したアプローチ
- オンプレミスおよびクラウドでのデータフィルタリング、ルーティング、変換機能
- ユースケースに応じて適切なプロトコルを選択する機能（HTTP、TCP、UDP）
Inbound Connectionsを利用したユニバーサルアプリケーション接続
Inbound Connections によってプッシュベースのデータ移動が可能になり、あらゆるアプリケーションを NiFi フローデプロイメントに接続できるようになり、CDF-PC をパブリッククラウドでのユニバーサルデータ配信ツールとして使うことができるようになりました。プッシュ型データ移動を活用できるユースケースはたくさんありますが、より詳しく調べるには、よく確立されたパターンがあります。
サイバーセキュリティのユースケースのための Syslog データパイプライン
Syslog は、ログメッセージの転送を行う規格標準であり、アプリケーション開発者が情報、障害、またはデバッグメッセージを記録するために使用することができます。ルーター、スイッチ、ファイアウォール、ロードバランサー、その他のネットワーク機器からのイベントメッセージを記録するために、ネットワーク機器メーカーにより広く採用されています。Syslogは通常、デバイスからイベントデータを収集し、Syslog サーバーにプッシュするSyslog クライアントのアーキテクチャに従います。
ネットワーク機器からのデータは、侵入検知や一般的なネットワーク脅威の検知といったサイバーセキュリティのユースケースで重要な役割を果たします。そのため、組織は、ネットワーク機器のイベントデータを SIEM セキュリティ情報およびイベント管理（SIEM）システムに移動するためのスケーラブルで堅牢なデータパイプラインを設定する必要があります。Inbound Connections と NiFi の ListenSyslog プロセッサにより、組織は CDF-PC NiFi をスケーラブルなsyslog サーバとして使用し、さらに処理するために生のイベントを受信することができるようになりました。NiFi の豊富なフィルタリング、ルーティング、処理機能を使用すると、不要なデータを簡単にフィルタリングして、SIEM の主なコスト要因の1つであるデータ量を削減することができます。フィルタリングに加えて、ユーザーは syslog イベントデータを、syslogデータを消費する必要のあるアプリケーションで必要とされる可能性のある任意の形式に変換することも可能です。
図3：CDF-PC のフローデプロイメントによるスケーラブルで堅牢な syslog データパイプラインとInbound Connections
ストリーミングデータのための Kafka REST プロキシ
Apache Kafka は人気のあるオープンソースのメッセージングプラットフォームで、プロデューサーからトピックにデータを取り込むためにプッシュモデルに基づいています。通常、プロデューサーは Kafka のプロデューサー APIを使用して Java で記述されますが、クライアントが Java を使用できず、REST API を通じてデータをポストする汎用的な方法が必要な場合があります。
Inbound Connections と NiFi の ListenHTTP プロセッサにより、ユーザーは、アプリケーションから Kafka にデータを送信するために使用できる安定したエンドポイントを通じて、任意の NiFi フローを公開できるようになりました。Inbound Connectionsの背後にある NiFi フローは、データを受信して Kafka トピックに転送するだけでなく、スキーマ検証、フォーマット変換、データ変換、さらにデータのルーティング、フィルタリング、リッチ化を実行することが可能です。CDF-PC の他のフローデプロイメントと同様、ユーザは自動スケーリングパラメータを設定し、主要なパフォーマンスメトリクスを監視して、デプロイメントがデータのバーストやアプリケーションの増加によるデータ量の増加に対応できることを確認することができます。
図4：CDF-PC のフローデプロイメントを Kafka RESTProxy として公開すると、宛先のKafkaトピックにイベントを送信する前に NiFi の豊富な変換機能を使用することができます。
Kafka REST Proxy のユースケースで CDF-PC を使い始めるには、ReadyFlow ギャラリーで公開されている構築済みの ReadyFlow を利用することができます。
図5：ReadyFlow ギャラリーで公開されている構築済みのReadyFlow
まとめとこれから
Inbound Connections を使うと、スケーラブルで堅牢な方法でプッシュ型を実装することができます。これにより、ハイブリッドデータパイプラインが解放され、開発者にユニバーサルアプリケーション接続を提供することができます。CDF-PCはインフラストラクチャの管理、セキュリティ証明書の生成、設定を行い、NiFiユーザはデータフローの開発と実行に専念することが可能となります。
Inbound Connectionsを体験するには、インタラクティブな製品ツアーをご利用いただくか、無償トライアルにご登録ください。
