エッジで Kafka をデプロイするためのユースケースとアーキテクチャ

[51CTO.com クイック翻訳] 現在では、IoT (Internet of Things) のエッジでのイベントストリーミングに Apache Kafka を使用することは、もはや高度な技術ではありません。汎用的なアプローチとして、Kafka はクラウドやデータセンターと同様に、エッジでもオープンで柔軟性があり、スケーラブルなアーキテクチャを提供します。これは、IoT と非 IoT (従来のデータセンターやクラウド インフラストラクチャなど) にまたがるストリーミング ナーバス システムの重要なコンポーネントです。実際、Kafka は小売店、携帯電話の基地局、電車、小規模工場、レストランなど、さまざまなエッジ ロケーションに導入できます。

この記事では、エッジ処理、統合、分離、低レイテンシ、コスト効率の高いデータ処理など、さまざまな業界のエッジにおける Kafka クライアントと Kafka ブローカーのユースケースとアーキテクチャを紹介することに重点を置いています。

エッジにおける Kafka のカテゴリとアーキテクチャ

ほとんどの IoT プロジェクトの構築は、データセンターやクラウド内の通常の Kafka プロジェクトとは根本的に異なります。信頼性の高い Kafka クラスターを提供したり、クラウド内で安定したネットワーク接続を確立したりすることはできませんが、次のエッジ機能があります。

• 中央データセンターやクラウドへの高可用性接続がないため、一部のローカル前処理、低遅延のリアルタイム分析、低帯域幅の断続的な接続などが利用できず、オフラインでのビジネス継続性が非常に重要になります。
• プロジェクトでは、小売店、電車、レストラン、携帯電話の基地局、小規模な工場など、数百の場所に Kafka ブローカーを展開する必要が生じることがよくあります。したがって、単一のプロキシは高可用性である必要はありませんが、バックプレッシャーに耐え、ローカル処理機能を提供できる必要があります。
• Kafka ブローカー (クライアントだけでなく) は、フットプリントが小さく、タッチが少なく、DevOps インストール要件が最小限である必要があります (つまり、Kafka を操作するオンサイトの IT スタッフはほとんど不要です)。したがって、エッジで Kafka をインストールして操作するには、認定された OEM ハードウェアを使用するのが最適です。
• 多くのエッジユースケースには、センサーとテレメトリデータが含まれます。すべてのトランザクション データを失うことのない電子商取引システムとは異なり、IoT アプリケーション シナリオでは、1 秒あたり数百万のメッセージを処理するアプリケーションで少数のメッセージが失われても、最終的な計算結果には影響しません。
• ハイブリッド クラウドまたは非クラウド: コンシューマー IoT (CIoT) には、スマート ホーム、シェア ライド、小売店などの環境が含まれますが、インダストリアル IoT (IIoT) には、自動車、食品、エネルギーなどの生産シナリオが含まれます。
• 通常、センサー、ホスト、モバイル デバイスなどの何千もの接続インターフェイスが含まれます。

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

一般に、エッジでの Kafka のアーキテクチャとデプロイメント シナリオには、データ統合、前処理、クラウド レプリケーション、エッジでの大規模 (小規模) データの処理と分析、接続が中断された場合のオフライン ソリューション、数百の場所を持つハードウェア スペース占有率が極めて低いソリューション、および非高可用性ソリューションが含まれます。次に、いくつかの代表的な業界のアプリケーションを見てみましょう。

• 公共サービス部門: 政府行政機関が主導する公共交通機関の管理、さまざまな自動車メーカーのさまざまなコネクテッドカー プラットフォームの統合、画像のキャプチャと処理、IoT セキュリティ、その他のスマート シティ プロジェクト。
• 運輸/物流/鉄道/航空: 鉄道では、オフライン処理とローカル ストレージ、旅行情報の追跡 (遅延やキャンセルの追跡を含む)、リアルタイムのユーザー ロイヤルティ プラットフォーム (キャビンのアップグレードやラウンジ アクセスを含む) に Kafka を使用できます。
• 自動車、航空宇宙、半導体、化学、食品などの製造業：IoT アフターサービス、機械や車両の OEM、組み込み標準ソフトウェア（ERP や MES システムなど）、設備・機械・生産ラインのデジタルツイン/プロセス、工場の生産ラインの監視による予知保全、品質管理、ダッシュボード/作業場/周辺機器の健全性状態の追跡など。
• エネルギー/公共事業/石油・ガス: スマートホーム/ビル/メーター、遠隔機器の監視 (掘削リグ、風車、採掘機械など)、パイプラインおよび精製作業の予測異常検出および障害診断。
• 通信/メディア：OSS（運用支援システム）のリアルタイム監視、指標レポート、問題分析、根本原因分析、ネットワーク機器およびインフラストラクチャ（ルーター、スイッチ、その他のネットワーク機器など）の応答、BSS（ビジネス支援システム）の顧客エクスペリエンス、OTTサービス（さまざまなサードパーティのモバイルアプリケーションの統合）、5Gエッジ（路上のセンサーなど）デバイスの状態。
• ヘルスケア：病院での追跡、遠隔監視、デバイスセンサー分析など。
• 小売/食品/レストラン/銀行: 顧客とのコミュニケーション、クロスセリング、ロイヤルティ分析、小売決済、在庫数え、POS マシンの統合、リモート CRM 統合、EFTPOS (販売時点情報管理における電子資金移動)。

私たちはかつて、小売ファーストフードチェーンブランドであるChic-fil-A向けにエッジコンピューティング関連のサービスを導入しました。当社では、2,000 軒のレストランすべてに Kubernetes クラスターを導入しました (https://www.infoq.com/presentations/chick-fil-a-k8-clusters/ を参照)。そのため、インターネット接続がなくても、エッジ コンピューティングを通じてリアルタイム分析を実現できます (https://medium.com/@cfatechblog/edge-computing-at-chick-fil-a-7d67242675e2 を参照)。下の写真は、見た目が非常に小さく、Intel クアッドコア プロセッサ、8 GB RAM、SSD を搭載したハードウェア エッジ デバイスです。

エッジアーキテクチャの例: 輸送と物流における Kafka

鉄道会社の具体的なケーススタディを通じて、エッジでの Kafka のハイブリッド ソリューションについて説明します。このソリューションは、オフライン エッジ処理を使用して、顧客とのコミュニケーション、クラウドベースのレプリケーション分析、サードパーティ パートナーのインターフェイスおよび API との統合を可能にします。これは鉄道および運輸業界の例ですが、他の業界にも簡単に当てはめることができます。

エッジからクラウドまでのハイブリッド アーキテクチャ

エッジでローカルに情報を処理している列車を想像してください。インターネット接続と空きネットワークリソースがある場合、列車は関連データをリアルタイムでクラウドにコピーします。また、列車の移動中にネットワーク接続が失われた場合、Kafka はバックプレッシャーを処理し、ネットワーク接続が回復したときにデータをクラウドに複製します。次の図は、エッジとクラウドで使用される Kafka のハイブリッド アーキテクチャを示しています。

エッジでの Kafka イベント ストリーミング

下の図に示すように、トレインはエッジで Apache Kafka を使用して、リアルタイムのメッセージ/イベント ストリームを配信し、バック プレッシャーを処理します。

オフライン/切断されたシナリオで Kafka を使用する

列車はトンネルを通過したり、インターネット接続のないエリアに到達したりするとオフラインになります。この時点では、列車のエッジ デバイスが引き続きローカル処理を実行できる必要があります。結局のところ、ビジネスの継続性は、顧客体験の向上と売上の増加における重要な要素です。列車がオフラインの場合でも、乗客はモバイル アプリを使用してスケジュール情報を確認したり、レストランで食べ物を購入したり、列車のローカル サーバーで映画を視聴したりする必要があります。同時に、列車がインターネット接続を再確立すると、乗客の購入取引はクラウド内のユーザー ロイヤルティ システムに転送され、クエリが必要な最新のメッセージもクラウドから取得され、列車のエッジ (Kafka ブローカー) に保存されます。次の図は、オフラインおよび切断モードで Kafka がエッジでデータを処理する方法を示しています。

会社全体での Kafka とエッジの統合

データ処理はエッジ（電車など）とクラウド システム（CRM、ロイヤルティ システムなど）間の統合システムで引き続き行われるため、さまざまなパートナーもこのような統合を実行する必要があります。 Kafka のネイティブ イベント ストリーム レプリケーション メカニズムを使用することは、スケーラブルでない同期 REST API 呼び出し/API 管理を介してパートナーと統合するよりも、より優れたスケーラブルなアプローチです。次の図は、パートナー間で企業間の Kafka レプリケーションと API 管理を実行する方法を示しています。

エッジに Kafka を導入するためのインフラストラクチャとハードウェアの要件

次に、エッジに Kafka をデプロイする方法について説明します。 Kafka では、ターゲット システムに一定の計算能力が必要であることに注意してください。これは、使用しているハードウェア ベンダー、インフラストラクチャ、特定の SLA、高可用性要件など、さまざまな要因によって異なります。幸いなことに、Kafka はベアメタル、仮想マシン、コンテナ、Kubernetes など、多くのインフラストラクチャにデプロイできます。現在メーカーが製造でき、エッジで使用できる最小のチップには、通常 4GB、8GB、または 16GB の RAM が搭載されています。

実際には、Kafka を実行するために必要な最小のハードウェア構成は、シングルコア プロセッサ + 数百 MB の RAM です。この構成により、単一の Kafka ノード (レプリケーション係数 = 1) で 100 Mb/秒を超えるスループットでエッジ処理を実行できるようになりました。もちろん、実際の値はパーティションの数、メッセージのサイズ、ネットワーク速度などのさまざまな要因によっても異なります。これは、データ センターやクラウドのパフォーマンスやスケーラビリティと比較することはできません。

したがって、Raspberry Pi に Kafka ブローカーをデプロイすることはできますが、Kafka クライアントを実行できる小型の組み込みデバイスにはデプロイできません。

エッジに Kafka を導入する「Confluent Way」

技術的な観点から見ると、エッジでの Kafka の導入は、環境と要件が異なることを除いて、データセンターやクラウドでの導入と似ています。さらに、いくつかの追加機能により、Kafka の導入と運用が容易になります。次に、Confluent のデプロイメント方法の革新的で差別化された機能を見てみましょう。

1. Confluent サーバーには、Kafka プロキシと、自己バランス クラスター、階層型ストレージ、組み込み REST API、サーバー側モード検証などのさまざまな拡張機能が含まれています。単一ノード (非常に軽量ですが、高可用性ではありません) として、またはクラスター モード (主にエッジでの高可用性に依存するミッション クリティカルなワークロード用) として展開できます。

2. この方法では、共同作業を実現するために ZooKeeper が追加コンポーネントとしてまだ必要ですが、2021 年には必要なくなると予想されます。その時点では、Kafka を搭載したスタンドアロンの単一プロセス エッジ ソリューションになります。

3. クラスター リンク (https://www.confluent.io/blog/kafka-cluster-linking-with-confluent-platform を参照) を使用すると、Confluent Replicator や MirrorMaker などの追加のツールやアーキテクチャを必要とせずに、すべての小規模な Kafka エッジ サイトが Kafka プロトコルを使用してデータ センターまたはクラウド内の大規模な Kafka クラスターに接続できるようになります。その結果、開発者はインフラストラクチャにかかるコストと作業負荷を大幅に削減できます。

4. 監視とプロアクティブなサポートには Confluent のツールセットを使用します (https://docs.confluent.io/5.4.0/proactive-support.html を参照)。たとえば、1 つのコントロール センターで複数の異なるリモート Kafka クラスターを監視できます。監視対象には、技術アーキテクチャだけでなく、アプリケーションやエンドツーエンドの統合も含まれます。 Confluent Telemetry Reporter (https://docs.confluent.io/current/kafka/telemetry.html#what-data-is-sent-and-how-it-is-used を参照) は、エッジ サイトから関連データを収集します。

5. 現在、Kubernetes (MicroK8s Kubernetes ディストリビューション、https://microk8s.io/ を参照) は、多くのエッジ デプロイメントで推奨されるオーケストレーション プラットフォームになりつつあります。 Confluent Operator は、エッジでの単一エージェントまたはクラスター展開のローリング アップグレード、および CRD (カスタム リソース定義、https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) の形式でのセキュリティ自動化やその他の運用機能を提供できます。前述の Chic-fil-A は、2,000 を超えるファーストフード レストランで Kubernetes を実行し (https://medium.com/@cfatechblog/edge-computing-at-chick-fil-a-7d67242675e2 を参照)、さまざまな低レイテンシのエッジ サービスを提供しています。これは、データセンター内の Confluent Cloud および Confluent Platform 上に Confluent Operator を大規模に実際に導入した成功事例です。もちろん、Kubernetes はオンデマンドで選択されます。一部のエッジ ロケーションで Kubernetes を使用すると、複雑さが増し、限られたリソースの消費が増加します。

6. データ統合とデータ処理はエッジ コンピューティングの鍵となるため、Confluent は、PLC、OPC-UA、IIoT 統合用の PLC4X (https://www.kai-waehner.de/blog/2019/09/02/apache-kafka-ksql-and-apache-plc4x-for-iiot-data-integration-and-processing/ を参照)、データベース CDC、MQ、MQTT 統合用のコネクタ、クラウド コネクタ、高セキュリティまたは「ダーティ環境」での単方向 UDP ネットワーク用のデータ ダイオード コネクタ (https://docs.confluent.io/current/connect/kafka-connect-data-diode/index.html を参照) など、新旧のシステム用のコネクタを提供しています。もちろん、Kafka Streams と ksqlDB を使用すると、軽量でありながら強力なイベント ストリーム処理が可能になります。

7. 軽量エッジ クライアント (組み込みデバイスなど) は、Kafka の C および C++ クライアント API と REST プロキシ (https://github.com/edenhill/librdkafka を参照) を活用して、任意のプログラミング言語で HTTP(S) 経由で通信できます。これは、コンピューティング機能が制限されている多くの低電力エッジ デバイスにとって非常に重要です。結局のところ、これらのデバイスに Java や同様の「リソースを大量に消費するテクノロジー」を展開することはできません。

8. 認定済みの事前構成済みの OEM ハードウェアをエッジに配置し、それを LAN または WiFi に接続し、ハードウェア ベンダーが提供するリモート ソフトウェアを使用してインフラストラクチャを管理および監視することもできます。ビデオ「Hivecell で実現可能な処理」では、Kafka クラスター、Kafka Streams アプリケーション、および画像認識用の組み込み機械学習モデルを使用してエッジ分析を実行する方法を説明します。

まとめ

理想的なエッジ ソリューションである Kafka を使用すると、エッジ、データ センター、クラウドに同じオープンで信頼性が高く、スケーラブルなテクノロジーを導入できます。上で説明したエッジでの Kafka のユースケースとアーキテクチャが、さまざまな業界でエッジからクラウドまでの IoT アーキテクチャを構築するためにイベント ストリームとツールを活用する方法の理解を深めるのに役立つことを願っています。

原題: Kafka at the Edge — ユースケースとアーキテクチャ、著者: Kai Wähner

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