IoT のエッジコンピューティングで Kafka を使用する方法

[51CTO.com クイック翻訳] エッジテクノロジーの分野では、製造、自動化、航空、物流、小売などの業界のアプリケーションに取り組んでいる開発者は、Apache Kafka をエッジに展開するべきか、「実際の」データセンターに展開するべきか、それともパブリッククラウドインフラストラクチャに展開するべきかという疑問を頻繁に考えます。

この記事では、エッジコンピューティング分野の開発者に、モノのインターネット (IoT) のエッジにおける Kafka のさまざまなユースケースとアーキテクチャの使用方法を紹介します。記事の最後では、イベントストリーミングプラットフォームとしての Kafka が、エッジにある他の IoT フレームワークや製品を補完して、大規模なリアルタイムデータ統合とエッジ処理を実現する方法についても説明します。

複数の Kafka クラスターの正規化

現在、Apache Kafka のマルチクラスターおよびデータセンター間の展開は、業界では一定の標準となっています。エッジの Kafka はスタンドアロンプロジェクトとしてデプロイできますが、ほとんどの場合、全体的な Kafka アーキテクチャの一部になります。多くの企業は、次の理由から複数の Kafka クラスターを作成します。

独立したプロジェクト要件。
ハイブリッド統合アプローチ。
エッジコンピューティング。
コンポーネントの集約。
プラットフォームの移行。
災害復旧。
地域または大陸間の通信に必要なグローバルアーキテクチャ。
企業間のコミュニケーション。

「エッジ」または「エッジコンピューティング」とは何ですか?

Kafka をエッジに導入することを検討する前に、まず「エッジテクノロジー」の定義を理解しましょう。 Wikipedia には、「エッジコンピューティングは、コンピューティングとデータストレージを必要な場所に近づけることで、応答時間を短縮し、帯域幅を節約する分散コンピューティングパラダイムです。」と記載されています。同時に、コストの削減、システムの柔軟性の向上、懸念事項の分離などの利点もあります。

エッジにおける Apache Kafka

現在、エッジコンピューティングに Kafka を適用する方法については、業界では次のようなさまざまな見解があります。

エッジクライアントのみ: Kafka クライアントはエッジで実行されます。 Kafka クラスターは、データセンターまたはパブリッククラウド環境にデプロイされます。
すべてがエッジにあります: Kafka クラスターと Kafka クライアントはエッジ (たとえば、工場内のさまざまなセンサー) にデプロイされます。
エッジとリモート: Kafka クラスターはエッジにデプロイされます。一方、Kafka クライアント (そのエリア内のスマートフォンなど) はエッジ近くで実行されます。

エッジの Kafka には、次のような比較的柔軟で幅広い用途があることがわかります。

産業用 IoT (IIoT) 現場のエッジにある Kafka クライアントは、C で記述してセンサーのマイクロコントローラーにデプロイできます。このようなセンサーは通常、数千バイトのメモリしか持たず、一定期間使用できます。
通信ビジネスのエッジでは、完全な分散型 Kafka クラスターを StarlingX (https://www.starlingx.io/) 上で実行できます。 StarlingX は、Kubernetes をベースとしたオープンソースのプライベートクラウドアーキテクチャスタックであり、IIoT、通信、ビデオ配信、および超低レイテンシなどの厳しい要件を持つその他のエッジ環境で使用できます。
展開を通じて、従来の銀行や保険会社のコアハードウェアとエッジハードウェアが接続されます。

ほとんどの場合、エッジ Kafka はシステムのエッジにデプロイされた Kafka クラスターを指すことがわかります。対応する Kafka クライアントプログラムは、ローカルまたは近くで実行できます。もちろん、場合によっては「近く」が数マイル離れた場所を意味することもあります。

エッジでの Kafka のユースケース

以下では、さまざまな企業でエッジの Kafka が運用されているユースケースについて説明します。

産業用 IoT: リアルタイムのエッジ統合と処理は、最新の IoT アーキテクチャの成功の鍵となります。インダストリー 4.0 では、予知保全、品質保証、プロセス最適化、サイバーセキュリティなど、このようなユースケースが豊富にあります。その中で、Kafka を使用してデジタルツイン (Digital Twin、訳者注: 対応する物理デバイスのライフサイクル全体を仮想空間でシミュレート、マッピング、反映すること) を構築することは、最も一般的なシナリオの 1 つです。
小売業: ウォルマートのような小売業者、スターバックスのようなコーヒーショップ、Amazon Goのような流行の店など、デジタル変革はさまざまな面で革新をもたらします。これらには、顧客向けの 360 度エクスペリエンス、販売業者と消費者間のクロスセル、他のパートナーサプライヤーとのコラボレーションが含まれます。
物流: 大規模なリアルタイムデータの相関関係は、あらゆる物流シナリオを変える重要な要素です。これらには、エンドツーエンドの荷物追跡と配送、地元のセルフサービスステーションとのドローン（または自律型）通信、物流センターでの処理の高速化、共有車両の調整と計画、スマートシティでの信号管理などが含まれます。

上記のユースケースに関係なく、エッジでの Kafka の一般的なアーキテクチャは次のようになります。

エッジコンピューティングの課題

企業が工場、小売店、コーヒーショップなどのシナリオにさまざまな革新的なリアルタイムアプリケーションを導入し、エッジサイトにデータを配信しようとすると、次のような課題に直面することがよくあります。

ネットワークの状態が悪く、その他多くの制限があるため、エッジにあるさまざまなハードウェア、マシン、デバイスをスムーズに統合することは困難です。
多くのユースケースでは、大規模かつリアルタイムの処理が必要です。そして、このすべての処理は、リモートデータセンターや数百マイル離れたクラウドではなく、オンサイトエッジで実行する必要があります。
さまざまなテクノロジーとプロトコルをエッジで統合する必要があります。さらに、反対側のビッグデータツールと通信するには、さまざまな従来のプロトコルや独自のプロトコルがトンネルを通過する必要があります。
ハードウェアリソースと人員が限られています。コスト上の理由により、IT 専門家がすべてのエッジサイトにアクセスしてハードウェアの操作とメンテナンスを実行することはできません。
あらゆる種類のデータを大規模かつリアルタイムでローカルに保存し、処理する必要があります。同時に、このデータは、さらに集約、処理、分析するためにデータセンターまたはクラウドにコピーする必要があります。さらに、コマンドやイベントを送信することで単一のノードによる各エッジサイトの制御を実現するために、各種通信は双方向であることが望ましい。

エッジコンピューティングのための Kafka アーキテクチャ

エッジでの Kafka のデプロイメントソリューションについて説明する前に、高可用性エッジアーキテクチャが必要かどうかという 1 つの質問を事前に明確にする必要があります。

実際、エッジコンピューティングでは必ずしも高い可用性が求められるわけではありません。本当に必要な場合は、従来の Kafka クラスターをデプロイします。そうでない場合は、エッジにシンプルで低コストの Kafka ブローカーを設定するだけです。また、数百のサイトで展開する必要がある場合は、既製のハードウェア機器の実装が容易になります。

次の図は 3 つのエッジの位置を示しています。各サイトに Kafka クラスターがデプロイされ、各クラスターには異なる Kafka コンポーネントが含まれます。

3 つ以上の Kafka Broker を使用したエッジでの回復力のあるデプロイメント

Kafka とそのエコシステムは、単一のノードに障害が発生した場合でも高可用性とゼロダウンタイムを保証するように設計されています。次の図に示すように、分散システムをデプロイするには、少なくとも 3 つの Kafka ノードと 3 つの Zookeeper ノードが必要です。その他のコンポーネントでは、運用の信頼性を確保し、データ損失を防ぐために、少なくとも 2 つのノードが必要です。

デプロイメントのベストプラクティスについては、Apache Kafka および Confluent Platform リファレンスアーキテクチャの記事を参照してください。もちろん、エッジではトラフィックの負荷とスループットは通常低いため、SLA が許せばメモリとディスク容量が少なくても十分な場合があります。

Kafka ブローカーを使用したエッジでの非弾性デプロイメント

エッジに「軽量 Kafka クラスター」を展開し、より大きな中央の Kafka クラスターとデータを同期または複製する必要性が高まっています。ただし、ハードウェア自体の制限と高可用性に対する SLA 要件の低さにより、エッジには 1 つの Kafka Broker と 1 つの Zookeeper のみがデプロイされます。下の図に示すように、Kafka 環境全体を 1 台のサーバーにデプロイすることもできます。

ただし、この展開ソリューションには明らかな欠陥があります。データ間のレプリケーションがないため、ノードまたはネットワークに障害が発生してダウンタイムが発生すると、データが失われるリスクがあります。もちろん、この単一ノードの Kafka デプロイメントソリューションには、次のような利点があります。

生産者と消費者の分離を実現します。
バックプレッシャーを効果的に処理できます。
ブローカーが 1 つしかない場合でも、大量のデータをリアルタイムで処理できます。
ディスクに保存します。
データを再処理する機能。
統合には Kafka Connect を、ストリーム処理には Kafka Streams または ksqlDB を、管理には Schema Registry を使用できます。これはまさに、Kafka ローカルコンポーネントの「ファミリーバケット」です。

ZooKeeperを削除するとエッジのKafkaが役立つ

Hadoop や Spark などの他の分散システムと同様に、Kafka は操作が難しいだけでなく、ZooKeeper に過度に依存しているため、スケーラビリティも低くなります。ほとんどの IoT プロジェクトでは、全体的な展開に長い時間がかかることから、Kafka を軽量化して操作しやすくするために ZooKeeper を削除することをお勧めします。

エッジデバイスとクラウドサービス間のゲートウェイとして Kafka を使用する

構成によっては、エッジデバイスをローカルゲートウェイと通信させたい場合があります。この時点で、ゲートウェイスタイルの Kafka アーキテクチャソリューションを使用できます。たとえば、工場では、複数のマシンまたは生産ラインがエッジデバイスと見なされます。ゲートウェイとして機能する Kafka クラスターにデータを送信するには、それぞれの Kafka クラスターと統合する必要があります。これに基づいて、Kafka クラスターゲートウェイで、ローカルで直接分析を実行し、データをフィルター処理または変換し、最終的にリモートの大規模な Kafka クラスターに送信して集約することができます。

上の図に示すように、まず、2 つの独立した工場が、ローカルデータ処理を実現するために、各場所に非弾性の単一の Kafka Broker を展開しました。次に、弾力性のある Kafka クラスターゲートウェイが 3 つの Kafka ブローカーを集約し、ファクトリ内でローカルにデータを処理します。その後、重要な前処理済みのデータのみがリモート Kafka クラスター (図の Confluent Cloud) に転送されます。最後に、クラウド内の Kafka クラスターは、さまざまなプラントからのデータを集約し、他のビジネスアプリケーションや分析ツールと統合します。

OEM またはハードウェアコンポーネントとしてのエッジでの Kafka

企業にとって、エッジにハードウェアをインストールするのは、ローカルデータセンターやパブリッククラウドにインストールするよりもはるかに複雑で面倒です。エッジで標準化された Kafka コンポーネントのインストール方法を採用すると、作業負荷と潜在的なリスクが大幅に軽減されます。

現在、OEM ハードウェアデバイスの構築を支援できるハードウェアサプライヤーが数十社あります。もちろん、リモート管理や DevOps ツールを使用して、必要なソフトウェアコンポーネントをすべてインストールすることもできます。

エッジでの Kafka クラスターのインストールと操作を簡素化するために、同社は Hivecell (https://hivecell.io/) に代表される製品ボックスをリリースしました。これには Kubernetes、Kafka エコシステム、Confluent Operator (https://www.confluent.io/confluent-operator/) ツール、およびその他のビジネスアプリケーションがプリインストールされています。エッジの Kafka 環境での操作を簡素化および自動化します。ユーザーは、1 つまたは複数の製品ボックスをエッジロケーションに発送するだけです。ローカル WiFi に接続すると、他のすべての操作をリモートで実行できます。同社は、顧客が技術者を必要とせずにエッジでソフトウェアを導入および保守できるようになるとも主張している。

通信、接続、統合、データ処理

上の図に示すように、Kafka 環境には Kafka Broker と Zookeeper だけが含まれるわけではありません。クラウド、オンプレミス、エッジのいずれの場合でも、通信、接続、統合、データ処理は Kafka インフラストラクチャの重要なコンポーネントです。

具体的には、エッジからリモートまでの Kafka Broker と Kafka クライアント間の通信プロセスは、デバイス -> エッジの Kafka -> レプリケーション -> データセンターとクラウドの Kafka クラスター -> データ分析とリアルタイム処理です。通常、このような通信は双方向で行われます。 Kafka のネイティブコンポーネントごとに、大規模なリアルタイム通信、統合、およびデータ処理を実行するために、Kafka バックエンドを管理するだけで済みます。以下の側面が関係します。

Kafka Connect: MQTT (メッセージキューテレメトリトランスポート)、OPC-UA、FTP、CSV、PLC4X (Modbus、Siemens S7、Beckhoff、Allen Bradley の 4 つのプログラマブルコントローラー (PLC) などの従来の独自の IIoT プロトコルのセット) が含まれます。
ミラーメーカーと Confluent Replicator: 2 つの Kafka クラスター間で一方向または双方向のレプリケーションを実装します。
Kafka クライアント (プロデューサー/コンシューマー): Java、Python、C++、C、Go、Javascript などの言語をサポートします。
データ処理: ストリーム処理 (ステートレスストリーム ETL やその他のステートフルアプリケーションを含む) には、Kafka Streams または ksqlDB を使用します。
プロキシ: HTTP(S) 通信には REST プロキシを使用し、MQTT 統合には MQTT プロキシを使用します。
スキーマレジストリ: ガバナンスとスキーマの適用を担当します。

エッジのハードウェアリソースが限られているため、Kafka フルスタックがエッジのニーズを真に満たせるように、最初に全体的なアーキテクチャとデータ通信を計画する必要があることがわかります。

ハイブリッドアーキテクチャ

モノのインターネットの実際のニーズは多岐にわたります。 24 時間 365 日のリアルタイム展開、データ損失ゼロ、遅延のないリアルタイム処理を前にすると、Kafka アーキテクチャだけに頼ることができない場合があります。この時点で、Kafka とのエンドツーエンドの統合を実現するには、他の IoT フレームワークまたはソリューションを組み合わせる必要があります。

上の図に示すように、Siemens MindSphere (強力で広範囲にわたるが、複雑で高価な IoT ソリューション) を工場現場でのゲートウェイまたはプロキシとして使用できます。もちろん、HiveMQ をスケーラブルな MQTT クラスターとして展開して、マシンやデバイスに接続することもできます。

場合によっては、Kafka を IoT のゲートウェイまたはプロキシとして直接使用して、PLC または分散制御システム (DCS) に接続することもできます。同時に、Kafka は AWS IoT や Google Cloud の MQTT Bridge などの IoT ソリューションに接続して、さらに処理や分析を行うこともできます。

データ通信は双方向であることが多いため、どのアーキテクチャを選択するかに関係なく、作業現場や他の IoT デバイスからデータを抽出し、それをリアルタイムで処理して相関させ、最終的に制御イベントをマシンに送り返すことができる必要があります。たとえば、予測分析では、まず TensorFlow などのクラウドツールを使用して分析モデルをトレーニングし、次にエッジに分析モデルをデプロイしてリアルタイム予測を行う必要があります。

他の IoT フレームワークやソリューションと組み合わせることで、Kafka エコシステムが効果的に補完されるだけでなく、それぞれが異なる機能的なユースケースに焦点を当てることもできることがわかります。たとえば、Kafka はデバイス管理とモデルのトレーニングに重点を置くことができます。主要なクラウドプロバイダーは、デバイス管理用の IoT サービス、クラウドエージェント、分析ツールを提供できます。オープンソースフレームワーク Eclipse を使用してデジタルツインを構築できます。

分散システムの組み合わせが多すぎる場合は注意が必要

もちろん、ダウンタイムやデータ損失のない、エッジコンピューティングとハイブリッドアーキテクチャ向けのスケーラブルで信頼性の高いストリーミング構造を構築したい場合、複数のミドルウェアツールを統合した環境でこれを実現するのは実際には困難です。つまり、組み合わせるツールの数が増えるほど、サービス中断やデータ損失のリスクが高まります。たとえば、NiFi (翻訳者注: Apache の NiFi プロジェクトはリアルタイムデータストリーム処理システムです) には独自の分散インフラストラクチャがあるため、プロデューサーから NiFi および Kafka を経由したプロセス全体が、24 時間/7 日間のエンドツーエンドの稼働時間で最終的にコンシューマーに到達できるようにする必要があります。同様に、Kafka Connect や Kafka Streams などのネイティブツールが Kafka Topics を使用してバックグラウンドで高可用性を提供する場合も、ダウンタイムやデータ損失なしで 24 時間 365 日これを保証する必要があります。したがって、データ損失のない大規模なリアルタイム処理には、「センサー ABC -> NiFi (キャプチャ) -> Kafka トピック A -> NiFi (変換) -> Kafka トピック B -> NiFi (ロード) -> アプリケーション XYZ」などのパイプラインアーキテクチャを慎重に使用してください。

要約する

エッジコンピューティングは、多くの場合、アーキテクチャ全体の一部に過ぎませんが、この分野の「ダークホース」として、エッジの Kafka は、ハイブリッドアーキテクチャの展開を通じてデータ処理速度を向上させ、ネットワーク伝送コストを削減し、システム全体に優れたスケーラビリティ、信頼性、堅牢性をもたらすことができます。

原題: Apache Kafka は IoT プロジェクトのエッジにおける新たなトレンド、著者: Kai Wähner

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。

<<: 2,500億ドル！ GoogleはAmazon AWSをターゲットにSalesforceを買収したい

>>: 私たちは本当にKubernetesを理解しているのでしょうか?