マイクロサービス間のkafka通信

その夜、再び組み立てラインのアラームが鳴りました。

あなたはワークショップに立ち、ロボットアームのバラバラなカチカチ音を聞いています。いくつかのサーボユニットのデータは、糸が切れた凧のようなものです。指示は送信されましたが、特定の関節が半拍遅れています。温度は異常ではなく、負荷も正常ですが、全体の動作軌道がわずかにずれているため、一連の部品を手直しする必要があります。

何度も確認した結果、問題はモーター自体ではなく、いくつかの制御モジュール間の通信にあることがわかりました。数ミリ秒間データが失われ、アクションが接続できなくなりました。

「マイクロサービス間の信頼性の低い通信」によって引き起こされるこのような制御の逸脱は、実際には機械システムや自動化システムでは非常に一般的です。特に複数のサーボ ユニット、センサー、PLC が連携して動作する必要がある場合、データ フローが遅延したり、失われたり、順序が乱れたりすると、システム全体で目に見える、または目に見えないジッターが発生する可能性があります。

このとき、誰も途中で「取り残されない」ように、リアルタイム データをベルトコンベア上の部品のように次々と安定して送信するには、より堅牢な通信アーキテクチャが必要になる場合があります。

そしてカフカが助けてくれるでしょう。

これは魔法ではなく、単なる設計上のアイデアです。データを継続的なフローで収集、分散、保持し、各マイクロサービスが相互にブロックすることなくオンデマンドでデータにアクセスできるようにします。これは、高速かつ整然としたコンベア ベルトと考えることができます。すべてのサーボ モーターの位置データ、トルク フィードバック、温度情報が 1 つずつ「データ パッケージ」に入れられます。このデータを必要とするモジュールは、他のモジュールの読み取りに影響を与えることなく、いつでも必要なパッケージをベルトコンベアから取り出すことができます。

このようにして、サービスが一時的にビジーになったり再起動されたりした場合でも、データ フローは中断されず、データが取得されるまでベルトコンベア上で静かに待機するだけです。

メリットは何ですか?それは明らかです。

たとえば、システムをより柔軟に拡張できます。再配線したり、既存の通信を中断したりせずに、同じデータ ストリームから情報の読み取りを開始するだけで監視ユニットを追加できます。または、特定の制御モジュールが履歴データを必要とする場合、システム全体を停止することなく、以前のデータ パケットを直接トレースバックできます。

もちろん、実装にはいくつかの設計上の考慮事項が必要です。たとえば、データ トピックの分割を計画する必要があります。各モーターを別個のトピックにする必要がありますか、それともデータ タイプごとに分割する必要がありますか?データ保持ポリシーは、実際のシナリオのリアルタイム要件に従って設定する必要があります。また、主要な制御サービスが最初に最新データを取得できるようにする一方で、分析サービスが既存のデータをゆっくりと消化できるようにするためのコンシューマ グループの構成もあります。

少し抽象的に聞こえますが、実際のシナリオに置き換えると、簡単に理解できるでしょう。

組み立てラインがあり、正確な動きを完成させるために 6 つのサーボ軸が連携する必要があるとします。従来のポイントツーポイント通信が使用されている場合、メイン制御 PLC と特定のドライバーの間でネットワークが不安定になると、アクション チェーン全体のバランスが崩れる可能性があります。 Kafka がデータセンターとして使用され、各軸が独自のステータス データをリアルタイムで発行する場合、メイン制御 PLC はこれらのデータ ストリームをサブスクライブするだけで次の命​​令をリアルタイムで計算できます。 1 つの軸のデータが数ミリ秒遅れても、他の軸は滞りません。最新の既存データに従って微調整を続け、遅れたデータが到着するとすぐに統合し、全体的な動作の一貫性が維持されます。

また、これによりシステムが複雑になるのではないかと疑問に思う人もいます。

はい、最初はデータ フローと展開アーキテクチャの設計により多くの時間を費やす必要があります。しかし、長期的には、通信の信頼性が「ネットワークの一時的な状態に依存する」ものから「永続的なデータ フローに依存する」ものに変わり、結果として散発的な障害のリスクが軽減されます。これは、作業員が部品を手から手へ運ぶ代わりにベルトコンベアを使用するようなものです。最初にトラックを敷設する必要がありますが、一度走り始めると、誰かの手が滑ったために生産を中断するのは簡単ではありません。

使用を開始するにはどうすればよいですか?

標準的な答えはありませんが、通常はサブシステムから試行できます。たとえば、まず温度監視とサーボ ステータス レポートを Kafka ストリーム経由で実行し、コア制御命令は引き続き元のリアルタイム チャネル経由で実行します。データ フローと監視ツールの特性を理解したら、中程度のリアルタイム要件を持つさらに多くのデータ モジュールを徐々に移行できます。重要なのは、データ フローに「ブロック」や「パケット リーク」があるかどうかを明確に確認できるように、十分なログと監視を確保することです。

これについて言うと、あなたはこう思うかもしれません - これはむしろ IT アーキテクチャの仕事のように聞こえますが、機械制御と何の関係があるのでしょうか?

実際、関係はますます緊密になってきています。今日のサーボ システムは、もはや単純な「命令実行」サイクルではありません。よりリアルタイムのフィードバック、環境データ、予知保全指標を統合する必要があります。これらのデータが従来の通信方法を介して 1 つずつ同期されている場合、効率と信頼性がボトルネックになります。 Kafka のようなストリーミング データ プラットフォームは、データを分散した水滴ではなく、継続的な水の流れとして扱うというアイデアを提供します。システムの各部分にはオンデマンドでアクセスできるため、分離できるだけでなく全体の同期を維持することもできます。

もちろん、これらすべては安定した信頼性の高いハードウェア基盤から切り離すことはできません。サーボ モーターとドライブの性能は、依然としてこれらすべての前提条件です。スムーズに動作するコンベア ベルトと同じように、ベルト上の部品自体が正確で強力でなければなりません。

したがって、マルチデバイスのコラボレーションにおいてもデータの遅延や損失に悩まされている場合は、単にハードウェアやネットワークだけを見るという観点を超えて、データ フロー自体のより堅牢な「伝送システム」を設計する必要があるかどうかを検討する必要があるかもしれません。

結局のところ、ロボットをスムーズに動かすには、モーターの回転速度だけでなく、データがいかに安定して実行されるかが重要です。

キロパワーサーボドライブとオートメーションに焦点を当て、ハードウェアからデータフローまで、より信頼性の高いモーションコントロール基盤を構築します。

2005年に設立され、キロパワーは、中国広東省東莞に本社を置く、コンパクトモーションユニットの専門メーカーです。モジュラードライブテクノロジーのイノベーションを活用し、キロパワー高性能モーター、高精度減速機、マルチプロトコル制御システムを統合し、効率的でカスタマイズされたスマート ドライブ システム ソリューションを提供します。 Kpower は、スマート ホーム システム、自動エレクトロニクス、ロボティクス、精密農業、ドローン、産業オートメーションなどのさまざまな分野をカバーする製品で、世界中の 500 を超える企業クライアントにプロフェッショナルなドライブ システム ソリューションを提供してきました。