aws でマイクロサービスを開発する

コードの中ではなく、ロボット アームが動くたびに、それが生き物であるように感じることがあります。彼らには気性があり、気温が高いと震えたり、負荷が重いと騒音を出したり、通信が遅れると空中で止まったりします。画面上のエラーログを見つめるあなたが思い浮かべるのは、作業場で停止した機械のこと。問題は決してコードだけではなく、ワイヤー、ギア、そして触れる可能性のある金属ケースにあります。

そこで誰かが、マイクロサービスを試して AWS を使ってみてはどうかと言いました。一瞬びっくりしてしまうかもしれません。これはサーボモーターとどのような関係があるのでしょうか?それはステアリングギアの精度とどのような関係があるのでしょうか？私たちはクラウド内の目に見えないコンテナについて話しているのではありませんか?

別の言い方をしましょう。複雑な機械システムを組み立てていると想像してください。各サーボは独立したマイクロサービスのようなものです。サーボは独自の角度のみを担当し、命令を受信して​​実行します。すべての制御ロジックを巨大なメイン​​制御ボードに詰め込むことはできません。それはかさばりすぎます。ジョイントに高速な応答が必要な場合は、その駆動回路を分離します。マイクロサービスは、クラウドで行われる点を除けば、このアイデアです。 AWS は、コンピューティング、ストレージ、メッセージ キューなどの既製の「ドライバー モジュール」を提供します。あなたのタスクは、機械システムの物理ロジックをクラウドのサービス ロジックに変換することです。

少し抽象的に聞こえますか？具体的なシナリオを見てみましょう。自動仕分けラインを設計しているとします。複数のサーボが連携して動作し、一部は識別を担当し、一部は掴みを担当し、一部は輸送を担当します。従来のモノリシック アプリケーションでは、識別モジュールを更新する必要があると、展開のためにシステム全体をシャットダウンする必要があります。しかし、マイクロサービスを使用するとどうなるでしょうか?機械システムのセンサー モジュールを 1 つだけ交換するのと同じように、認識サービスを交換するだけで、残りは通常どおり続行されます。 AWS の ECS または EKS は、さまざまな機械モジュールのタイミングの調整を支援する目に見えない技術者と同様に、これらのサービスのデプロイとスケジュールの管理に役立ちます。

これはどのような実際的な利点をもたらしますか?それは回復力です。サーボの過熱保護などのサービスクラッシュによって、生産ライン全体が停止することはありません。 AWS の負荷分散と自動拡張と縮小により、システムはローカル障害に耐えることができます。反復の速度です。新しいモーション コントロールをテストする必要がありますか?トライアル運用のためにマイクロサービスを独立してデプロイすることができ、既存の実稼働プロセスに影響を与えることなく、データが API ゲートウェイを介して流れます。それは珍しい透明度です。各マイクロサービスは 1 つのことだけを実行します。これは、機械設計における 1 つのモジュールと 1 つの機能に対応します。メンテナンスを行うときに、膨大なコードベースの干し草の山から針を探す必要はありません。

もちろん、物語には常に別の側面があります。マイクロサービスは魔法ではありません。システムを細分化しすぎると、サービス間のネットワーク呼び出しによって新たな遅延が発生する可能性があり、これはリアルタイム応答が必要なモーション コントロールにとって致命的となる可能性があります。このとき、AWS メッセージング サービス (SQS や Kinesis など) と Virtual Private Cloud (VPC) が鍵になります。これらは注意深く配置された制御線のようなもので、サービス間で命令が確実かつ迅速に受け渡されるようにします。機械システムの実際の応答時間要件に基づいて、サービスの通信粒度を設計する必要があります。薄すぎると遅れて重なってしまいます。厚すぎると柔軟性が失われます。

道具を選ぶときは、自分の手にどのようにフィットするかに注目してください。 AWS のスイートは包括的ですが、本来の目的は「機械システムに何が必要か?」ということです。データ フローが主にデバイス ステータスのレポートとコマンドの発行である場合は、Lambda を使用してイベントを処理するだけで十分な場合があります。長時間実行される複雑な制御ロジックが必要な場合は、EC2 または Fargate ホスティング コンテナの方が適しています。重要なのは、最新のサービス名を追うことではなく、現実世界でデバイスがどのように動作するかを理解し、そのデジタル イメージをクラウドに構築することです。

また、これは複雑すぎるのではないかと尋ねる人もいます。運用と保守の負担が増加しますか?実際、マイクロサービス アーキテクチャにはさまざまな考え方が必要です。機械エンジニアのモジュール的な考え方をソフトウェア分野に拡張する必要があります。しかし、長期的には、製品ラインが数から数十に拡大し、顧客がアクションの組み合わせをカスタマイズする必要がある場合、このアーキテクチャを使用すると、毎回最初からソリューションを書き直すのではなく、新しいソリューションをより迅速につなぎ合わせることができます。

結局のところ、テクノロジーは単なるツールにすぎません。マイクロサービスであれ AWS であれ、その究極の価値は、冷たい金属部品をより素直かつ確実に動作させることです。深夜にシステムをデバッグし、監視ダッシュボード上でさまざまなサービスがスムーズに動作し、対応するロボット アームが一連の複雑な動作をスムーズに完了するのを見たとき、そのスムーズな感覚と精密機械をチューニングした達成感は、実は同じ源から来ています。つまり、システムの本質を理解し、それに最適な表現を見つけ出すということです。

すべてのテクノロジーの最終目的は、作成を容易にすることです。スケッチ上の構造から、作業場の設備、クラウドに流れるデータに至るまで、私たちは実際に同じことを行っています。つまり、アイデアを安定した再現可能な現実に変えるということです。

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