テクニカルサポート
発行済み 2026-01-19
これを想像してください。各関節が独立したサーボ モーターによって制御されるロボット アームをデバッグしているとします。これらのモーターはリアルタイムで連携する必要がありますが、指示はさまざまなマイクロサービスから来ます。1 つは軌道を計算し、1 つはセンサーのフィードバックを処理し、もう 1 つは安全ロジックを管理します。突然、特定のサービスが高負荷のために数ミリ秒間速度が低下し、操作全体がフリーズし始めたり、同期が取れなくなったりすることがあります。このとき、これらのサービスで会話がもっと「スムーズ」になればいいのに、と思いましたか？
実はこれは機械制御だけが直面する問題ではありません。マイクロサービスに分割されたシステムはどれも同様の課題に直面します。サービス間で確実かつ効率的に通信するにはどうすればよいでしょうか?データが失われないこと、順序が崩れないこと、そして突然のトラフィックに耐えられることをどのように保証するか?
数年前、自動選別ラインをアップグレードしていたときにこの壁にぶつかりました。直接 HTTP 呼び出しなどの従来の方法は、サービスが増加するにつれて脆弱になります。 1 つのサービスがダウンすると、リンク上の他のサービスも影響を受けます。ピークリクエストが来るとすぐにシステムはキューイングを開始し、リアルタイムのパフォーマンスは問題外になります。もっと「ベルトコンベア」のようなメカニズムが必要です。データをその上に置き、必要な場所がお互いをブロックすることなく、自分のペースでアクセスできるようにします。
そこで私たちは探し始め、最終的に Kafka を導入しました。
よく知られたシーンで例えると、カフカは工場の終わりのないベルトコンベアのようなものです。各マイクロサービスはワークステーションとみなすことができます。ステーション A は半製品 (メッセージ) をコンベア ベルトに置き、ステーション B と C は必要に応じていつでも処理できるようそれらを持ち帰ります。ベルトコンベア自体は動き続けます。たとえ特定の駅が一時的に改修されたとしても、半製品は消えることはなく、駅が引き継ぐまで線路上で静かに待つだけです。
これにより、いくつかの問題が解決されます。
当初、チーム内の何人かは「これは複雑すぎませんか? 新しいミドルウェアのセットを保守する必要があります。」と心配していました。しかし、実際にやってみると、それは超高層ビルを建てるというよりも、積み木を積み上げるようなものであることがわかりました。
私たちは完全な見直しから始めたわけではありません。代わりに、水をテストするための最も明白な問題点、つまりロボット アームのステータス監視を伴うリンクを選択しました。ステータス データはあるサービスから別のサービスにプッシュされ、ネットワークのジッターにより失われることが多く、その結果、監視パネルが時々「断片化」することが判明しました。 Kafka トピック (専用のコンベア ベルトとして理解できます) を確立し、ステータス発行サービスにここにデータを書き込ませ、監視サービスがそれをサブスクライブするだけです。ほぼ即座に、断片化の問題は解消されました。監視サービスが一時的にオフラインであっても、再起動後にブレークポイントから未処理のステータス更新をすべて読み取ることができるためです。
この小さな成功が私たちに自信を与えてくれました。その後、注文指示フローとアラームイベントフローを段階的に移行していきました。リアルタイムの物流地図を見るように、システム全体のデータの流れが徐々に明確に見えるようになります。どの回線が混雑しており、どの回線が空いているかが一目でわかります。
もちろん、その過程ではいくつかの探索がありました。例えば、「ベルトコンベア（トピックス）を何本に分けるか？」と悩んだことがあります。その後、ワークショップと同様に、すべての部分が 1 行に混在することはなく、データ ドメインと緊急度によって分けて管理する方が合理的であることがわかりました。モーター制御命令には低遅延が必要であり、別の高速ラインが必要です。ログおよび監査データは容量が大きいですが、リアルタイム性の要件が低いため、別の大容量回線を使用します。それぞれがお互いに干渉することなく、独自の道を進みます。
「ベルトコンベア自体が壊れたらどうするの？」と尋ねる人もいます。 Kafka の分散設計は本質的に冗長性を持っています。データは複数のノードにバックアップされます。 1 つのノードに障害が発生した場合、他のノードがすぐに引き継ぎ、サービスはほとんど認識されなくなります。トランスミッションに予備のエンジンを搭載するようなものです。
今振り返ってみると、Kafkaの導入はシステムを「複雑」にしたのではなく、本来見えなかった混沌を秩序立てたものにしました。マイクロサービス間の緊張した直接結合関係が緩和されました。各サービスは独自のロジックにさらに重点を置くことができ、アーキテクチャ全体の柔軟性が大幅に向上しました。生産ラインを拡張して新しい検査ステーションを追加する必要がある場合、対応するトピックに新しいサービスを登録するだけで済みます。これは、他の部分にまったく影響を与えることなく、コンベア ベルトの隣に新しいステーションを追加するのと同じくらい簡単です。
市場には多くのメッセージ キュー ツールがありますが、なぜ Kafka を選択するのでしょうか?私たちは、高スループット、永続性、シーケンス保証におけるバランスのとれたパフォーマンスを重視しています。最も派手な機能を備えたものではないかもしれませんが、データ ストリームの安定した処理を必要とする産業シナリオには十分な堅牢性を備えています。もちろん、どのツールも特効薬ではなく、その学習曲線と運用保守コストに投資が必要です。ただし、通信の問題によりマイクロサービスも「協調性のない動作」をし始めた場合は、そのような「インテリジェント コンベア ベルト」のセットをシステムにインストールすることを検討する価値があるかもしれません。
結局のところ、優れたテクノロジーは信頼性の高い機械伝達のようなものでなければならず、静かで正確で、複雑なコラボレーションを簡単に行うことができます。
2005年に設立され、キロパワーは、中国広東省東莞に本社を置く、コンパクトモーションユニットの専門メーカーです。モジュラードライブテクノロジーのイノベーションを活用し、キロパワー高性能モーター、精密減速機、マルチプロトコル制御システムを統合し、効率的でカスタマイズされたスマート ドライブ システム ソリューションを提供します。キロパワーは、スマート ホーム システム、自動エレクトロニクス、ロボティクス、精密農業、ドローン、産業オートメーションなどのさまざまな分野をカバーする製品で、世界中の 500 を超える企業クライアントにプロフェッショナルなドライブ システム ソリューションを提供してきました。
更新時間：2026-01-19
