クラウド内のトラックおよび冷蔵トラック

この記事では、ゲートウェイの基本的なプロトタイプを作成し、SaaS（Software as a Service）モデルを使用してMicrosoft Azureクラウドプラットフォームに転送するというストーリーを共有したいと思います。



以下で議論されることを明確にするために-小さな助け：

• Quarta Technologiesは、基本的なITインフラストラクチャの分野におけるソリューションのプロバイダーであり、Microsoft Windows Embeddedに基づく組み込みシステムのテクノロジーに関する完全な情報および技術サポートの分野でロシアのIT市場のリーダーです。
• TechnoComは、輸送、産業、農業のあらゆる企業や産業向けに、輸送、人員、燃料制御センサー、ソフトウェアの衛星監視用のGLONASS / GPSシステムの開発と生産に取り組んでいます。 同社の最も有名な製品は、AvtoGRAFシリーズのナビゲーション端末です。
• iQFr​​eezeは、貨物と輸送の状態に関する情報をリアルタイムで収集、処理、送信するQuart Technologyのソリューションです。

基本的なゲートウェイプロトタイプの作成

AutoGRAFシステムは、データアクセスおよび分析機能を備えた古典的なクライアントサーバーアプリケーションです。 現在のアーキテクチャは、拡張にコストがかかります。 そのため、コラボレーションの重要なアイデアは、アーキテクチャを再考し、SaaSモデルに導いてスケーラビリティの問題を解決し、市場に革新的なオファーを作成するという試みでした。



プロジェクトの開始前は、モノのインターネットのパラダイムにおける技術的相互作用は、Azureサービスを既存のソフトウェアに統合することに加えて、車両に搭載された機器からのデータ受信に関連する問題-衛星端末を含むため、非常に難しいタスクになる可能性があることは明らかでしたトランスポートAvtoGRAFの監視（以下、「SMT端末」と呼びます）。 そして、適切な準備のみがタスクを大幅に簡素化します。 そのため、イベントの約1か月前に準備が始まりました。 その結果、いくつかの重要な質問が議論され、それらに対する回答とともに以下に示されます。

システムは稼働していますか？ デバイスの状態は何ですか、デバイスは何をするのか、何を知らないのですか？

今日、このシステムは数年間機能しています。 さまざまなメーカー/パートナーの車両での使用を目的としていたため、機器に違いがあります。 ほとんどすべてのデバイスは1つの点で類似しています。少数のデバイスでもファームウェアを変更することは、生産的な環境での作業のため不可能です。 このため、フィールドゲートウェイモデルを使用する（デバイスの近くにゲートウェイを配置またはインストールする）ことはできません。

サーバー側との通信にデバイスが使用するプロトコルは何ですか？

テクノコム社の自社開発のバイナリプロトコル。

進行中のプロセスを中断せずにサーバー側の新しいバージョンを作成し、古いバージョンからそこにリダイレクトすることは可能ですか？

難しいが、本物。 しかし、そのようなアプローチには深刻で長期的なテストと開発が必要なため、この反復から除外することが決定されました。

デバイスをリモートで管理する必要がありますか？

おそらく将来ではありますが、現在ではありません。

計画プロセス中に、収集されたデータを処理するためのコンポーネントシステムへの追加に関連して、タスクのリストを拡張することが決定されました。 したがって、現在のモノリシックアーキテクチャはモジュールに分割されていました。 AvtoGRAFからの着信データストリームが編成されたため、デバイスエミュレーションに関する質問は終了しました。

TCPポートをリッスンし、データ処理サブシステムにデータを転送するゲートウェイをホストするために、 Microsoft Azureクラウドサービスが選択されました。

プロトタイプを実装するために、チームには6つのタスクに5時間と3人の開発者がいました。

1. 現在のアーキテクチャを評価し、PaaSを使用して再考します。
2. テストゲートウェイ（コンソールアプリケーション）を実装して、動作を確認します。
3. クラウドゲートウェイ（Azure IoTゲートウェイ、クラウドサービスなど）を作成するための既存のオプションを評価します。
4. ゲートウェイをクラウドに移行します。
5. ゲートウェイをデータ処理サブシステムに接続します（つまり、このためのコードを記述します）。
6. Application Insightsの監視機能をプロトタイプに追加します。

最初に、モノリシックアプリケーションをコンポーネントに分割する方法の問題に集中することにしました。

前のアーキテクチャ

古いアーキテクチャは、C ++で記述され、Windows Server環境で実行されるモノリシックアプリケーションである、従来の2層アーキテクチャ「クライアント-サーバー」でした。 彼の仕事は、デバイスにインストールされた監視システムからデータパケットを受信し、これらのパケットをローカルストレージに保存し、外部ユーザーのデータにアクセスするためのフロントエンドになることでした。 アプリケーション内には、ネットワーク、データストレージ、データ復号化、およびデータベースの操作といういくつかのモジュールがありました。

サーバーとデバイス間のデータは、独自のバイナリTCPプロトコルを使用して送信されました。 接続を確立するために、クライアントはハンドシェイクパケットを送信し、サーバーはそれに確認パケットで応答する必要がありました。



その作業では、アプリケーションは一連のWin32APIシステムコールを使用しました。 データはファイルとしてバイナリ形式で保存されます。

このようなスケーリングの問題は、サーバーリソースの増加/新しいリソースの追加とロードバランサーのセットアップと他のタスクの実行という、限られた実装方法にあります。

建築後

新しいアーキテクチャを適用した後、アプリケーションは実際にはゲートウェイであり、いくつかのサービスタスク（たとえば、データを変更せずに保存する）を実行したため、関連性が失われました。 新しいアーキテクチャでは、これらすべてがAzureサービスに置き換えられました（開発者は、Azure IoTゲートウェイまたは手書きゲートウェイのどちらを選択するほうがよいかを評価し、Azure Cloud Servicesでホスティングする2番目のオプションを選択しました）。



新しいシステムの機能の原則は、古いシステムの原則と似ていますが、スケーリング（自動を含む）の追加の機会を提供し、たとえばロードバランサーを構成するためのインフラストラクチャタスクを削除します。 ゲートウェイを備えたいくつかのCloud Serviceインスタンス（インスタンス）は、特別なポートでリッスンし、デバイスを接続し、処理サブシステムにデータを転送します。

Software as a Service（SaaS）モデルを使用して、プロトタイプをMicrosoft Azureクラウドプラットフォームに移植する

小さなステップから始めて、クラウドにすべてを一度に実装しないことが重要です。 クラウドには、プロトタイピングを複雑にする独自の利点と機能があります（たとえば、ポートのオープン、リモートプロジェクトのデバッグ、デプロイなど）。 したがって、この場合、開発の最初の段階は、ゲートウェイのローカルバージョンを作成することでした。

• ゲートウェイは、TCPポートでリッスンし、デバイスからハンドシェイクパケットを受信すると接続を開始します。
• ゲートウェイはACKパケットで応答し、接続を確立します。 データパケットを受信すると、仕様に従って、これらのパケットは既製のコンテンツに分解されます。
• ゲートウェイはデータをさらに転送します。

プロトタイプを作成する過程で問題が発生しました。開発者はマイクロソフトオフィスで働いていました。そこでは、ネットワークセキュリティ境界には特定の数の異なる種類のポリシーがあり、ローカルゲートウェイのプロトタイピングが複雑になる可能性があります。 ポリシーを変更する機会がなかったため、チームはngrokを使用しました 。これにより、localhostで安全なトンネルを作成できます。

開発中に、さらに深く取り組むことが決定されたいくつかの問題がありました-ローカルストレージへの書き込み、ゲートウェイが動作するインスタンスのアドレスとポートの取得。 クラウドでは多くの変数が動的に変化するため、これらの問題は次のステップに進む前に解決することが重要でした。

Cloud Serviceオンプレミスストレージへの記録

もちろん、インスタンス上のデータのローカルストレージと比較して、 Azureには情報を保存するより良い方法がありますが、古いアーキテクチャはローカルストレージを暗示していたため、システムがこのモードで動作できるかどうかを確認する必要がありました。 デフォルトでは、クラウドサービスで機能するすべてのものはファイルシステムにアクセスできません。つまり、うまく機能せず、c：/ tempに情報を書き込みません。 これはPaaSであるため、クラウドサービス構成でローカルストレージと呼ばれる特別なスペースを構成し、cleanOnRoleRecycleフラグを設定する必要があります。これにより、ある程度の確実性で、ロールの再起動時にローカルストレージからの情報が削除されません。 以下は、この問題を解決するために使用されたコードです。

const string azureLocalResourceNameFromServiceDefinition = "LocalStorage1"; var azureLocalResource = RoleEnvironment.GetLocalResource(azureLocalResourceNameFromServiceDefinition); var filepath = azureLocalResource.RootPath + "telemetry.txt"; Byte[] bytes = new Byte[514]; String data = null; while (true) { TcpClient client = server.AcceptTcpClient(); data = null; int i; NetworkStream stream = client.GetStream(); while ((i = stream.Read(bytes, 0, bytes.Length)) != 0) { … System.IO.File.AppendAllText(filepath, BitConverter.ToString(bytes)); … } client.Close(); } 

テスト後、データがストレージに残っていることが判明したため、これは一時データを保存するのに適した方法です。

インスタンスのアドレスとポートの取得

実行時にデータを取得するには、クラウドサービスの構成内でエンドポイントを定義し、コードでアクセスする必要があります。

 IPEndPoint instEndpoint = RoleEnvironment.CurrentRoleInstance.InstanceEndpoints\["TCPEndpoint"\].IPEndpoint; IPAddress localAddr = IPAddress.Parse(instEndpoint.Address.ToString()); TcpListener server = new TcpListener(localAddr, instEndpoint.Port); 

これで、自動構成されたロードバランサーはインスタンス間のリクエストを管理し、開発者はこれらのインスタンスの数をスケーリングでき、各インスタンスは実行時に必要なデータを受け取ります。

そのため、ローカルゲートウェイが起動され、クラウドサービス（ローカルでエミュレート可能）でテストされました。今度は、プロジェクトをクラウドにデプロイする番です。 Visual Studioツールキットを使用すると、数回クリックするだけでこれを実行できます。



ゲートウェイインスタンスからのさらなるデータ転送の問題は、公式コードサンプルを使用して正常に終了しました。

結論

計画時に、チームは、特にさまざまな環境、デバイス、および要件（廃止されたデバイス、プロトコル、モノリシックC ++アプリケーション）が存在する場合、システムの実用的なプロトタイプを開発するのに十分ではないことを心配していました。 何かする時間がなかったのですが、基本的なプロトタイプが作成されて機能しました。

この種のタスクにPaaSモデルを使用するのは素晴らしい方法です。

• ラピッドプロトタイピングソリューション。
• サービスと設定を使用して、ソリューションを最初からスケーラブルで柔軟にします。

数時間で、実際のデータを使用してIoTパラダイムでエンドツーエンドソリューションを開発するための基盤を作成することができました。 将来の計画には、機械学習を使用してデータを最大限に活用し、新しいプロトコルに移行し、Azure Service Fabricプラットフォームでソリューションをテストすることが含まれます。

Alexander BelotserkovskyとQuart Technologyのチームによる資料の作成にご参加いただきありがとうございます。