モノリシックおよびマイクロサービス アーキテクチャ

機械プロジェクトが「話し始め」るとき: モノリシック アーキテクチャとマイクロサービス アーキテクチャの間の秘密の対話

複雑なロボット アームを構築していると想像してください。サーボモーターは正確に反応し、ステアリングギアは柔軟に回転し、すべてが計画どおりに進んでいるように見えました。しかし、特定のモジュールを調整しようとすると、システム全体が接着剤で固定されているのと同じくらい硬くなり、1 つの部品を変更するとすべてに影響します。これは機械的な故障ではなく、設計の奥深くに隠されたアーキテクチャ上のジレンマです。すべての機能をまとめた「モノリシック」アーキテクチャが、イノベーションのペースを密かに制限しています。

なぜ私たちは常に「縛られている」のかという疑問が生じます。

伝統的なモノリシック構造は、昔ながらの時計のようなものです。すべてのギアがしっかりと結合されており、安定して動作しますが、調整が難しいです。機械およびオートメーションの分野では、この種の設計はかつて非常に一般的でした。つまり、制御ロジック、通信インターフェイス、およびデータ処理がすべて 1 つのコア プログラムに詰め込まれていました。最初はスムーズに動作していましたが、機能が増えるにつれて大きくなり、脆くなりました。サーボ制御を更新しますか?システムの半分を書き直す必要がある場合があります。新しいセンサープロトコルに参加したいですか?数週間にわたるリファクタリングとテストが待っているかもしれません。

さらに厄介なのは、このアーキテクチャではスケーリングが贅沢になってしまうことです。プロジェクトでは、最初は 3 つのサーボ モーターの制御のみが必要ですが、後で視覚認識、多軸同期、またはリアルタイム データ分析を組み込む必要が生じる場合があります。モノリシック建築では、多くの場合、すべてのニーズを事前に予測する必要がありますが、これは建築家に、基礎を築くときに 10 年後の各部屋のコンセントの位置を決定するように依頼するのと同じくらい非現実的です。

別の考え方はありますか？

視点を変えてみましょう。プロジェクト全体をバンドとして見た場合、モノリシック アーキテクチャとは、1 人がすべての楽器を演奏することを意味します。一方、マイクロサービス アーキテクチャにより、各ミュージシャンは自分のパートに集中し、暗黙の協力によって交響曲を完成させることができます。技術レベルでは、これはシステムを一連の小さな独立したサービスに分割することを意味します。1 つのサービスはサーボ角度校正専用で、別のサービスはモーター トルクの監視を処理し、さらに別のサービスはホスト コンピューターとの通信を担当します。各サービスは個別に開発、展開、拡張でき、さらには異なる言語で記述することもできます。

このような変化は単なる柔軟性以上のものをもたらします。通信モジュールの脆弱性により、生産ライン全体で誤警報が発生したことはありますか?マイクロサービス アーキテクチャでは、問題のあるサービスを分離して修正し、残りのサービスは実行し続けることができます。全身に影響を及ぼす突発的な故障が発生した場合、深夜まで残業して修理するという経験は過去のものになるかもしれません。

キロパワー観察: 機械分野におけるアーキテクチャの進化は、ソフトウェアの世界よりも数歩遅いことがよくあります。

これはテクノロジーが遅れているからではなく、物理世界の複雑さが人々をより保守的にしているからです。サーボ モーターの応答遅延、サーボの機械的磨耗、リアルタイム制御の決定的な必要性など、これらの要因が多くのチームのアーキテクチャの革新を妨げています。しかし興味深いのは、こうした厳しい制約があるからこそ、適切なマイクロサービス設計がさらに重要になるということです。

たとえば、ある自動仕分けプロジェクトでは、チームは当初シングルチップ コントローラーを使用してすべてのモーターを管理しました。視覚的な品質検査モジュールを追加する必要がある場合、システム全体のアップグレードを 2 週間一時停止する必要がありました。その後、マイクロサービスベースのアーキテクチャに切り替えたところ、同様の機能拡張は 3 日間に短縮され、古いモーター コントロール ユニットにはまったく影響がなくなりました。この種の変更は、マシンを打倒することではなく、新しい組織インテリジェンスをマシンに注入するようなものです。つまり、各部分が独立して機能すると同時に、シームレスに連携できるようになります。

よくある質問: これによりシステムはさらに複雑になりますか?

初期設計で考える量が確実に増えます。しかし、楽譜と同じで、初期段階でのアレンジが細かくできていればいるほど、後の段階での演奏がスムーズになります。マイクロサービス アーキテクチャでは、境界をより明確に定義する必要があります。どの機能が独立したサービスに値するか?サービスはどのように相互に通信するのでしょうか?データの一貫性はどのように保たれていますか?これらの考え自体が、プロジェクト ロジックの重要な見直しになります。

機械プロジェクトの場合、実際的な開始点は、変更される可能性が最も高いモジュールから始めることです。たとえば、モーター制御で頻繁なデバッグが必要な場合は、それを独立したサービスにしたほうがよいでしょう。将来的に通信プロトコルがアップグレードされる可能性がある場合は、分離することもできます。一つのステップを追求する必要はなく、積み木のように段階的に再構築できます。

キロパワーアーキテクチャの移行が成功することは「革命」ではなく「進化」であることを発見しました。

ロボット開発に携わる友人はこう例えました。モノリシック建築は石の彫刻のようなものです。一度形成されると、修正は引き算になります。マイクロサービス アーキテクチャは粘土を形作るようなものです。全体に影響を与えることなく、いつでも部分を調整できます。リファクタリング後、彼のチームはメンテナンスのプレッシャーを軽減しただけでなく、過去に結合ロジックによって隠蔽されていたいくつかの点を予期せず発見しました。たとえば、特定のサーボの応答遅延は、実際には誤って共有されたデータ処理キューに起因していました。

このアーキテクチャには暗黙の利点もあります。チームは各機能モジュールを「サービス」の観点から見る必要があります。 「このモーター制御サービスはどのようなインターフェイスを提供すべきか」、「どのようにして障害を適切に報告できるか」を考え始めると、設計思考は「機能の実装」から「信頼性の高いコンポーネントの構築」に移行します。この考え方の変化により、多くの場合、より堅牢で保守が容易なシステムが生まれます。

では、この変革をどのように始めればよいのでしょうか?

普遍的なレシピはありませんが、インスピレーションのポイントがいくつかあります。現在のシステムのどの部分が最も頻繁に変更されるのか、どの障害が最も大きな影響を与えるのか、そしてどのパフォーマンスのボトルネックが最も明らかなのかを調べます。これらは多くの場合、マイクロサービスの優先候補となります。 「エッジ」で実験することから始めます。コアの制御フローを妨げることなく、新しいサブ機能でマイクロサービスの設計を試します。監視とログに注意してください。サービスが増加するにつれて、明確な可観測性がこれまで以上に重要になります。

機械とオートメーションの分野では、アーキテクチャの選択は、純粋に技術的な決定ではありません。不確実性の中でチームがどのように変化に対応し、複雑さを管理し、システムの回復力を維持するかが重要です。モノリシック アーキテクチャはシンプルさと決定性を提供し、マイクロサービス アーキテクチャは柔軟性と進化の余地を提供します。多くの場合、実用的な設計はその中間に位置します。つまり、適度に分離された「マイクロモジュール」の集合体であり、おそらくバランス ポイントにすぎません。

結局のところ、すべてのアーキテクチャは同じ質問に答えます。今日確実に実行でき、明日も適応できるシステムを構築するにはどうすればよいでしょうか?サーボモーターのハム音とステアリングギアの柔らかな音が、その背後にある精巧なソフトウェアアーキテクチャと共鳴するとき、プロジェクトはもはや単なる機械ではなく、成長することができる生命体となります。

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