IIoTシステムの一貫性を同期する時間

分散システム設計における重要な（そして熱く議論されている）トピックは、どの整合性モデルを使用するかです。整合性モデルはシステム設計の多くの部分に影響を与え、一方を選択すると、システムの可用性やネットワーク障害に対する堅牢性などに影響を与えます。このブログは、一貫性があるかどうかの意味をよりよく理解したいシステムアーキテクトを対象としています。

まず、このブログはACID（https://en.wikipedia.org/wiki/ACID）の「C」に関するものではないことを明確にしましょう。 ACIDの一貫性により、一連の制約に従ってデータストアへの更新が有効になります。このブログは、分散ストア間でデータが複製されたときに何が起こるかを説明する種類の一貫性に焦点を当てています。結局のところ、ACIDはします それについて何か言いますが、それは「C」ではなく「I」（分離）です。紛らわしい？少しだけですが、我慢してください。

分離は、強一貫性とも呼ばれます。 。システムの一貫性が高い場合、分散ストア間のすべての書き込みと読み取りは、そのシステム内のすべてのアプリケーションに対して同じ順序で実行されます。これは、1つのアプリケーションが何かを書き込むときに、後を読み取るすべてのアプリケーションを読み取るという複雑な言い方です。 書き込みは、新しいデータを表示することが保証されています。

これは、多くのシステムで非常に便利なプロパティであることがわかりました。まったく同時に購入した場合でも、2人がショッピングサイトから同じ冷蔵庫を注文できないようにします。強一貫性により、グローバルに同じ順序の操作が実行されます。 、したがって、2つの購入は常に同じ順序で全員によって処理されます。実際には、これは、2回目の購入で、冷蔵庫の在庫がないことを確認できることを意味します。

強一貫性は非常に優れているように思えますが、なぜすべてのシステムでそれを使用しないのでしょうか。これは、CAP定理（https://en.wikipedia.org/wiki/CAP_theorem）と呼ばれるものが原因です。まず、簡単なメモ：CAPは、複雑な分散システムの動作を説明するのは単純すぎるため、多くの人から正当に批判されています。したがって、CAPを使用するときは注意が必要ですが、整合性モデルを議論するための有用なフレームワークを提供します。 CAPの詳細については説明しません。インターネットには、ここで期待するよりもはるかに優れた仕事をするためのリソースがたくさんあるからです。

要約すると、CAPは、アプリケーションが一時的に「話す」能力を失ったとき、つまりネットワークがダウンしたときに分散システムで何が起こるかを教えてくれます。システムが強く一貫していることは不可能であることが判明しました 接続が失われた場合でも、常に稼働時間を保証します。バマー。

それは複雑に聞こえますが、実際には非常に直感的です。強一貫性には、システム内のすべての操作に対するグローバルな順序が必要であることを覚えていますか？つまり、読む必要があります みんなからの以前のすべての書き込みを参照してください。すべてのアプリケーションが接続されていない場合、これを保証することは不可能になります。 1つのアプリケーションが冷蔵庫を注文した可能性がありますが、すべてのアプリケーションがこの注文をまだ受け取っていない場合、新しい注文を行うことはできません。その結果、ショッピングWebサイトのダウンタイムが発生します！

ダウンタイムは、データベースレプリケーションの実行（より多くのストレージ）や冗長Webサーバーの展開（より多くのコンピューティング）など、問題により多くのリソースを投入することで軽減できます。今日、これはパブリッククラウドインフラストラクチャで行うのはほとんど簡単ですが、マイクロサービスアーキテクチャのように、システムに多くの可動部分がある場合、非常に高価で複雑になります。システムがクラウド上で実行されていない場合、ストレージ、コンピューティング、および帯域幅はすべて非クラウド環境ではるかに制約されるため、リソースを追加することは簡単ではありません。

したがって、強一貫性はアプリケーションにとって便利ですが、インフラストラクチャ（およびウォレット）に負担がかかります。これらの問題を回避するために、賢い人々は、一貫性に関してはそれほど衒学的ではないが、アプリケーションの観点からはまだ実行可能な解決策を考え出しました。私たちが話しているのは「結果整合性」です。別の定義の時間です。

特定のアイテムの更新がない場合、すべてのアプリケーションが最終的に同じ値を参照する場合、システムは結果整合性があります。または、素人の言葉で言えば、十分に長く待つと、最終的には全員が同じデータを見ることになります。これは、アプリケーションが同時に読み取りと書き込みを行うことができ、ネットワークがダウンしているときでもそうすることができることを意味します。最終的に、システムのインフラストラクチャはすべての更新をアプリケーションに配信します。

アプリケーションは相互に待機する必要がないため、アプリケーションがクラッシュしたり停電が発生したりしない限り、結果整合性のあるシステムの稼働時間は理論的には無限です。ただし、無限大は実用的ではありません。しばらくすると、アプリケーションが再接続することを期待します。したがって、結果整合性のあるシステムでは、通常、整合性を保つのにかかる時間に制限があります。その制限が期限切れになり、アプリケーションが同期する機会がなくなった場合、障害回復が行われます。

結果整合性システムの利点は、可用性だけではありません。強一貫性のあるシステムの場合のように、読み取りと書き込みは同期を必要としないため、はるかに高速です。同期がないため、直接ピアツーピア通信も可能になり、単一障害点をもたらす集中型メッセージブローカーが不要になるため、パフォーマンスがさらに向上し、堅牢性も向上します。

ショッピングWebサイトでは結果整合性は機能しませんが、その利点（可用性、パフォーマンス、堅牢性、リソース効率）を考慮すると、ミッションクリティカルなシステムで多く使用されていることは当然のことです。

RTI Connext Product Suiteは、OMG DDS標準の主要な実装であり、ミッションクリティカルな産業用IoTシステムのプロトコルとして広く展開されています。 OMG DDSと他の接続プロトコルの大きな違いは、DDSがアプリケーション間で継続的に同期される分散データベースのように動作するのに対し、他のプロトコルは通常、メッセージを送信して状態管理をアプリケーションに任せるためのインターフェイスを提供することです。

分散データベースが一貫性に対処しなければならないもののように聞こえると思うなら、あなたは正しいです。 RTI Connext DDSは、最も要求の厳しいミッションクリティカルな環境で機能するために、可用性とパフォーマンスと一貫性のバランスを常にとる必要があります。デフォルトでは、RTI Connext DDSは結果整合性を使用して、ネットワークに障害が発生したときにRTI Connext DDSで構築されたアプリケーションが動作を停止しないようにすると同時に、すべてのアプリケーションが最終的に「世界」の同じビューを共有するようにします。

これで、「一貫性」のように抽象的なように聞こえる何かが広範囲にわたる結果をもたらし、初期のシステム設計で重要なトピックとして扱われるべきであることがわかります。残念ながら、「強一貫性」または「結果整合性」のいずれかになるほど単純になることはありません。ラムダアーキテクチャ（https://en.wikipedia.org/wiki/Lambda_architecture）は、強力な整合性と結果整合性の両方を使用して両方の世界を最大限に活用する1つの例にすぎません。一貫性の色合いが非常に多いため、システムアーキテクトは、システムがどの程度の一貫性を実現できるかについて複雑な決定を下す必要があります。

RTIの専門サービスチームは、お客様がこれらの決定を下し、結果を推論し、お客様に適した一貫性のあるソリューションを作成するように製品を構成するのを支援します。

RTIサービスの詳細については、https：//www.rti.com/services

をご覧ください。