Tarantool IIoTプラットフォームとは何ですか？

最近、プレスリリースで、産業用モノのインターネットのプラットフォームであるTarantool IIoTの立ち上げについて話しました。 ニュースは多くの電子出版物に広がりました。 しかし、Tarantool IIoTとは何か、どのように機能するかについては、トピックは完全には明らかにされていません。 修正することにしました。 カットの下の詳細。

そして、一般的にIIoTとは何ですか？

最初に、IIoTは産業用のモノのインターネットであることを思い出します。 これは、産業施設がネットワークとしてインターネットにアクセスし、インターネットサービス（データセンター-データセンターで機能する）にアクセスできる場合の概念です。 写真を見てみましょう：

ここで何が見えますか？ 写真は、「中央」と「地上」の2つの部分に分かれています。

「センター」とは、データセンターまたはクラウド、つまり、ITインフラストラクチャ（Amazon、Azureなど）を展開できるクラウドベースのIaaSサービスです。

「地上」-正直に言うと、ここでどの用語を使用するのかわかりません。 読者が私を修正し、美しい定義を提供してくれると確信しています。 「地上」とはどういう意味かをお伝えしたいと思います：畑（文字通りの意味-農業分野）、生産現場（工場、工場、金属加工、鉱業、石油およびガス施設）、修理現場、輸送中（車、トラック、鉄道車両、機関車）、都市インフラ施設（電気と水の消費に関する情報を収集する場所、下水道、道路沿い、照明施設）、長距離インフラ施設（高速道路、鉄道に沿って）多分行e 送電）。 一般に、「地上」は、インターネットの手がちょうど得られ始めているところです。 あなたはまだ「フィールドで」と言うことができますが、それから農業のフィールドだけに産業のモノのインターネットの輪を狭める危険があります。

Tarantool IIoTとは何ですか？ 彼はどのような問題を解決しなければなりませんか？

Tarantool IIoTは、センサーから情報を収集し、センターおよびローカル制御システムに送信するための分散ソフトウェアプラットフォームです。 Tarantool IIoTは、「中心部」と「現場」の両方で機能し、それらを単一の情報ネットワークに接続します。 このネットワークでは、最大のロジックがソフトウェアで持ち去られているため、鉄の観点からは、コモディティコンポーネントから組み立てることができます。つまり、閉じたプロプライエタリなソフトウェアおよびハードウェアプラットフォームの特別なサプライヤは必要ありません。 明確になりましたか？ そうでない場合は、読んでください:-)

コモディティコンポーネントとは、簡単に交換可能な安価なコンポーネントを意味します。 たとえば、データセンターを思い出すと、ハードウェア商品の観点から見ると、たとえばスーパーマイクロまたは完全に組み立てられたサーバーなどの安価なサーバーです。 「現場」のハードウェアの観点から見ると、これらは最も安価なセンサーとIoTハブ（つまり、小型のARMベースのコンピューター）になる可能性があります。

Mail.Ru Groupのデータセンター内では、かなり長い間、ほぼ完全に商品鉄に切り替えました。 ブランドブランドの保証とサポートがない場合もありますが、安価で互換性があります。 同時に、信頼性とパフォーマンスはソフトウェアレベルで提供されます。 何かが壊れても、すべてがソフトウェアレベルで複製および複製されるため、サービスにとってこれは重要ではありません。私たちは静かに修理のために鉄を送ります。 タイミングと一般的に鉄を固定する可能性は、ビジネスの継続性に影響しません。 アメリカの大規模なIT企業は長い間同じ道をたどっています。すべての複雑さはソフトウェアに移され、ハードウェアは可能な限り標準化され、安価になります。 そして今、このアプローチをIoTの世界に拡張することを提案します。

問題は、なぜ場所とセンターを単一の情報ネットワークに接続するのかということです。 答えは：

1. 地上には情報源（温度、振動、地理的位置、湿度、電圧、圧力など）があります。 生産中の損失の数とポイント、原材料と燃料の消費、現場の性能、メンテナンス期間、機械とデバイスの故障の可能性などについて結論を引き出すために、この情報を分析センターに収集、集約、送信することは良いことです。
2. 地上にはインフラストラクチャがあり、以前に取得した分析に基づいたものも含め、センターから管理するのに便利な場合があります。 制御とは、ローカルオブジェクトをアクティブ化（オフ、オン、減少、増加、減速、加速）する場所（APIを呼び出す）にコマンドをセンターから送信することを意味します。 私の意見では、センターからの生産の完全かつ普遍的な管理について話すのは時期尚早です（ネットワーク接続がハングしたために15トンの印刷機が落ちることを望む人はいません）が、多くの重要でないことを行うことができます たとえば、機器の振動センサーからのデータの分析に基づいて、機器がすぐに故障することが明らかになった場合は、赤い点滅ライトを点灯するコマンドを中央から工場に送信できます（はい、そうです：このイベントをタブレットにローカルにプッシュした場合従業員、それから彼は彼が忙しいので彼に単に気づかない。 電球が点滅するのを見て、従業員は壊れた機械を停止し、早期メンテナンスを注文します。

地上では、ご存じのように、データセンターとは異なる特異性があります。 Mail.Ru GroupがIIoT戦略の開発の初期段階にあることをすぐに予約します。それほど前ではないが、IIoT市場をテストしているため、すべての微妙な点を完全に理解していない可能性があります。 これが、現在私たちが詳細について考えていることです。 これは：

• 広大なエリア（中規模のプラントを利用する-エリアに関しては、大規模なデータセンターよりも数百倍も大きい場合があります）;
• 過酷な条件（熱、寒さ、湿度）;
• ITインフラストラクチャの損傷のリスクの増加。
• ITインフラストラクチャ施設を交換するための高コスト（1000マイルのオフロードでフィールドに入り、そこから100平方キロメートルを移動するため-モスクワのデータセンターに引っかかることはありません）。
• 温度、湿度、密度、ジオロケーション、重量、電圧などのセンサーを使用して収集する必要があるITインフラストラクチャの外部の情報

この特異性はすべてどういう意味ですか？ 工場、野原、船、街路、その他のオブジェクトで構築できないのは、データセンターで構築するものです。つまり、光ファイバーを介して接続されたサーバーを備えた同一のラックの列です。 それはめちゃくちゃ高価になります。

そして、他に何ができないのでしょうか？ IoTの世界では、サーバーの役割はIoTハブ（マイクロコンピューター（Raspberry PIの工業用アナログ））によって果たされます。マイクロコンピューターは、何キロメートルものサイトに散在しています。 繊維を引っ張るのは高価です。 また、それらをラックに組み立てるのは高価です。なぜなら、距離が非常に長いためにIoT Hubが多すぎ、経済的に制限された企業が多数のIoT Hubからローカルクラスターを形成できないからです。 つまり、ローカライズされたラックはありません。 周辺には鉄が点在しています。 さらに、企業/オブジェクトには何百万ものセンサーが至る所に散らばっていて（上記参照、どのセンサーについて話しているか）、そこからIoT Hubが情報を収集します。 再び-それを収集する方法？ センサーが少ない場合は、有線で。 そして、それらが100万個ある場合、無線チャネルを介して（センサーからのワイヤを介して100万本のワイヤ-どのボールを想像できますか？）

その結果、ソリューションの費用対効果を多かれ少なかれするために、この設計全体は次のようになります。

センサーは情報を収集してハブに送信します（これらはネットワークハブではなく、単に同じものです。小さなマザーボード、プロセッサ、メモリ、オペレーティングシステムを備えたマイクロコンピューターです）。ハブは情報をインターネットに送信します（モバイル通信、Wi-Fi、衛星、イーサネット経由）など）、データセンターに到達します。 データセンターからハブ、ハブからセンサー（またはローカルプログラマブルロジックコントローラー）に至るまで、逆の流れはまったく同じです。

さらに進みます。 IIoTの世界の詳細を覚えていますか？ この構造全体にスペースコストがかからないように、次のことを行います。

• IoT Hubは潜在的に交換可能な鉄で構成されていたため、ベンダーのロックインの可能性と鉄の価格が低下します。
• 一番上はオープンOS（たとえば、Linuxの亜種-OpenWrt）です。
• あらゆる種類のセンサーとの相互作用およびプロトコルの分析のすべてのロジックは、OS上のソフトウェアレベルに移行しました（高価なブラックブランドボックスに依存しないように）。
• センサーや機器に信号を送信するロジック全体もIoT Hubのローカルソフトウェアのレベルに達し、ベンダーの鉄の箱にハードコーディングされていません（物理的なデータ転送ではなく、処理ロジックを意味します）。
• IoT Hubで実行されるソフトウェアは非常に高速でした。 IoTハブは、多くを必要とするため安価で安価であるため、遅くなります。また、詳細のために多くが必要です（上記を参照）。 また、熱、寒さ、湿度、振動の形で詳細を覚えておいてください。つまり、これらのハブには特別な建物が必要です。 しかし、価格を上げることはできません。 そのため、技術スタッフィングをさらに安くする必要があるため、さらに遅くする必要があります。 借金の借方が収thatするように、ソフトウェアがどれほど速く音を立てるべきかを想像できますか？

つまり、換言すれば、データセンターで見慣れているもの、つまり交換可能な低コストのハードウェア、ソフトウェアレベルのすべてのロジック、ソフトウェアレベルのすべてのフォールトトレランスがあればいいのです。

次に、データセンターのソフトウェアを見てみましょう。 そこでは、OS以外にも、DBMS、アプリケーションサーバー、監視システム、DevOpsスクリプト、システムなど、ほとんどの場合、他の多くのコンポーネントが使用されます。 そして、すでにこのインフラストラクチャの上にビジネスロジックが記述されています。 良い方法では、説明されているインフラストラクチャ全体が、ハードウェア側の障害の主な問題を自動的に（十分にまたは半自動的に）構成します（マスターコピーが利用できない場合、データベースレプリカの負荷を切り替え、アプリケーションサーバーの複数のノード間で負荷を分散し、自動的にアップロードします）クラスターに接続されているクリーンなマシンなど）。

つまり、いくつかの専門分野が登場しました。 ビジネスロジック開発者（製品開発者）は、良い意味で、主にビジネスロジックについて考え、ビジネス上の問題に集中します。 そして、氷山の巨大な水中部分である残りのエンジニアと開発者もいます-DevOps、システム管理者、DBMS開発者、アプリケーションサーバーの開発者、監視システム、その他（インフラストラクチャと呼びます）コンポーネント。

地上ではそうでしょう。 かっこいい？ IoT Hubの開発が同じように専門化されたことを願っています。

Tarantool IIoT-ボンネットの下

そして、Tarantool IIoTにスムーズにアプローチします。 上記のインフラストラクチャのすべてをIoT Hubに置き換えることを意図しているとは言いませんが、部分的にはできます。 写真を見てください：

Tarantool IIoTは通常のTarantoolですが、ARMおよびx86向けに組み立てられ、テストされています（MIPSのバージョンが現在作成されています）。 さらに、MQTTおよびMRAAプロトコルの自動サポートが内部に組み込まれています-これらはセンサーを操作するための主要なプロトコルです。 Tarantool IIoTはIoT Hubsに直接インストールします。 センサーとハブ（フィールドマップ内）の間でデータを転送するには、特別な機器LORAまたは6LoWPANが必要であることをここに追加することもできます。 これは悪いように思えます（一意のベンダーボックスは必要ないことを思い出してください）。 しかし、全体のポイントは、この機器は多くのセンサーのプロトコルを理解する必要がないということです。 そのタスクは、ハブが理解できるプロトコルでプロトコルをラップすることだけです（通常、これは私たちの愛する古き良きTCP / IPです）。 残りの解析は、IoT Hubで直接動作するスクリプトを使用してTarantool IIoTで実行できます。

これは、ソフトウェアプラットフォームが鉄製プラットフォームより優れている点です。ベンダーなしで、あらゆる機器とプロトコルを個別にサポートできます。 技術的な詳細、その仕組み、およびTarantoolを使用したプログラミング方法については、記事「 すべてのIoTデバイスとクラウド間でのアプリケーションのマスターマスターレプリケーションとスケーリング 」を参照してください。

他のすべての点で、Tarantool IIoTはフル機能のTarantoolです。つまり、組み込みのアプリケーションサーバー、同期トランザクションログ、ノード間のレプリケーション、2つのエンジン（メモリ内-memtxおよびディスク上-vinyl）、ストアドプロシージャ、非同期ワークロードを備えたDBMSです。キューのサポートと他のパイ。

Tarantool IIoTは開発者に何を提供しますか？

Tarantool IIoTはIoT Hubsにインストールされます。 それは何を与えますか？

1. Tarantool IIoTでは、センサーから情報を受信し、解析してTarantool IIoT内のローカルデータベースに直接保存するスクリプトを記述できます（IoTハブのフラッシュメモリに保持されます）。
2. IoT Hubに保存された情報は、信頼性のために複数のIoT Hub間でローカルに複製されます（そのため、1つ以上のハブに障害が発生した後でもシステム全体が機能し続けます）。 Tarantoolにはすぐに複製できる機能があります。つまり、独自のキューシステムを作成する必要はありません。 ところで、ここで重要なポイントがあります。Tarantoolはアプリケーションサーバーであるだけでなく、DBMSでもあります。 したがって、データを永続化し、ノード間でデータを複製できます。 上記の観点から非常に重要な特性。 そして、そのままで機能し、長年にわたってテストされていることが非常に重要です（Tarantoolコアは通常の非IoTサービスとまったく同じであるため）。
3. IoTハブに保存された情報は、Tarantoolの組み込みツールを使用してデータセンターに複製されます。 そして、その一部またはレプリケートする集約のみ（構成はプログラミングされ、IoT Hubで直接動作します）。
4. コードとストアドプロシージャをローカルで自動的にタランチュラにアップロードできます。つまり、現場に行かずに、データセンターからローカル集約のロジックを変更できます（つまり、データセンターへのアクセスがどこからでも：オフィスまたはVPN経由）。
5. データセンターから（そして、世界中のあらゆるデバイスからアクセスできる権限を持つWebインターフェースから）1つのボタンでセンターへの情報配信の詳細レベルを変更し、ローカル、ローカルで、できるだけ多くの情報を受信できます。必要に応じて、データセンターに転送せずに処理します。

その結果、製品開発者は、データセンターで動作するソフトウェアを作成するときに存在する快適度の方向へのステップを受け取ります。 ハブ間のローカルチャンネルとハブとデータセンター間のチャンネルが信頼できず破れているという事実を考慮する必要はありません。複製は、損失や重複なしに双方向にデータを配信します。 開発者は、クライアントサーバーアーキテクチャ、ファイル、データ損失、ハブの障害に関する頭痛の種が少なくなります。このすべてのTarantool IIoTは、通常のTarantoolを使用する場合のデータセンターとまったく同じように処理します。 開発者は、ビジネスロジックに集中できます。

また、ここでは、データ配信がノード間の通常のレプリケーションメカニズムによって処理されることも追加します。これは過去9年間Tarantoolでテストされています。 つまり、メカニズムの信頼性は非常に高いです。

実際、Tarantool IIoTは完全にプログラム可能なオープンプラットフォームであり、ローカルデバイスでIIoT用のアプリケーションを開発するだけでなく、ベストプラクティスをデータセンターから現場のIoTデバイスに転送することもできます。

それでも、このプラットフォームは、機器メーカーが以前にあなたに結び付けていたという意味で、あなたの手を引き離します。 たとえば、既製の実用的な鉄のIoTインフラストラクチャがすでにあり、すべてのセンサーをデータセンターに自動的に配信します。 現在のハードウェアでサポートされていない安価なセンサーの新しいバッチを購入しました。 機器のベンダーが大きなお金のためにそこに変更を加えるように、あなたは機器のベンダーの足にふらふらしなければなりません。 さて、または単に新しいバージョンの機器を購入してください。 または安価なセンサーを放棄します。 そして、これらの変更はすべて、ソフトウェアではなく鉄です。つまり、ダウンタイム、フィールドトリップ、インストール、およびその他のトラブルです。

Tarantool IIoTを使用すると、これらの新しい安価なセンサーからデータを簡単に受信して解析し、目的の形式で機器またはローカルソフトウェアに転送できます。 ダウンタイムと大きな費用なし。

Tarantool IIoTだけでは十分ではないことは明らかです。 完全な快適さのために、監視、リモートソフトウェアアップグレード（同じTarantoolをアップグレードする必要があります）、自動Linuxロード、およびその他の喜び-他のインフラストラクチャシステムも必要です。 しかし、私たちに思われるように、これは正しい方向への一歩です。

タランツールIIoTが一般的であり、$ any_other_ IIoTテクノロジーではないのはなぜですか？

結論として、タランツールをIIoT製品の基盤として採用した理由をお伝えしたいと思います。 IoTハブの詳細に戻りましょう：これらのデバイスには、少数のコア（通常は1つまたは2つのコア）を備えた低速のプロセッサ、わずかなRAM、わずかなフラッシュメモリがあり、これも低速で信頼性が低いです。 なんで？ デバイスは非常に安くなければなりません（価格範囲はおよそ30〜100ドルです）。多くのデバイスがあるためです。インフラストラクチャは何キロメートルにもわたって分散しているためです。 覚えておいて、私は詳細について話しましたか？ 彼女を離れないでください。 これは一方でです。 一方、センサーは膨大な量の情報を生成します（1秒あたり数百および数百のパラメーターが1つのセンサーから取得でき、ハブあたりのセンサー数は数百および数千になることもあります）。 厳しい条件であり、非常に高速な機器ではないにもかかわらず、すべての情報は時間内に管理する必要があります。

したがって、このようなデバイスには、非常に高速なソフトウェア、非常に高速なDBMS、および1つのプロセッサコアで動作し、メモリをできるだけ効率的に使用し、ディスクに負担をかけない非常に高速なアプリケーションサーバーが必要です。

そして、これらすべての制限に直面して、Tarantoolはテストで最高の結果を示しました。 速度の最も近い競合相手はRedisです（残念ながら、CouchBaseとAerospikeでは成功しませんでした。シングルコアマシンでは非常に遅いですが、調理方法がわからないだけかもしれません）。 IoTでの適用性の観点から見たRedisの主な欠点：十分に開発されたアプリケーションサーバーがない、ストアドプロシージャがない（実行時にDBMS内のコードを更新できない）、ジョブがない、マスターレプリケーションマスターがない、トランザクションがない-データ損失の可能性が高い さらに、製品の作成者がこの方向で開発する予定があるかどうかはまったくわかりません。 以下は、 TarantoolとRedisの 2つの製品を比較する例です。 PythonとRedisの組み合わせは、ある意味でTarantoolに取って代わる可能性がありますが、速度は大幅に低下するでしょう。 すぐに予約します。まだ比較テストはありません。さらに、ケースごとに作業速度を比較することをお勧めします。

もう1つの重要なニュアンス：IoTデバイスでは、DBMSとアプリケーションサーバーを組み合わせた場合（およびTarantoolでは、それらを組み合わせて同じプロセスで動作します）、互いに通信するオーバーヘッドは明らかにはるかに小さくなります（オーバーヘッドについては、これは、高速DBMSと対話する場合でも巨大です。 インメモリデータベースを使用した非同期処理、または単一のCPUコアで1秒間に100万トランザクションを処理する方法 ）。 さらに、異なるプロセス間で情報を転送するためのオーバーヘッドは、デバイスの生産性が低く、処理する必要がある膨大な量の情報を考慮すると、非常に大きくなります。

SQLite、それは優れた高速ですが、残念ながら、すぐに使用できるレプリケーションとアプリケーションサーバーはありません。つまり、タンバリンを使用してその上で踊る必要があります。 従来のDBMSの残りの部分（名前は付けませんが、ここに尊敬される製品の大きなリストがあり、誰もが完全にそれらを知っています）、私たちは小さなIoTの鉄片で正常に開始しなかったか、センサーからの負荷を処理することさえできませんでした。 ただし、IoTデバイスで他のDBMSを使用した経験がある場合は、共有していただければ幸いです。

Tarantool IIoTについてお伝えしたかったのはそれだけです。 私たちはすでに、さまざまな生産、輸送、および他の企業とのパイロットのプロセスにいます。 生産が開始され次第、詳細に説明します。 ニュースをフォローしてください！