私のクライアントは、特定のサンプルのさまざまな測定を行い、その結果をデータベースに書き込む医療機器を製造しています。生成されるデータの量は比較的少量です。
現在の構成では、各デバイスには独自のコンピュータがあり、そのコンピュータはデータベース サーバーのインスタンスを実行します。デバイスはネットワーク化されていません。
クライアントは、約 50 台のデバイスをローカル エリア ネットワークに接続できるようにデバイスを変更したいと考えています。
デバイスはロット番号の付いたさまざまな消耗品を使用し、一度使用すると再利用できません。これらのロット番号は、サンプルの測定時にデータベースに書き込まれます。現在の構成では、デバイスは消耗品が別のデバイスで使用されたかどうかを知る方法がないため、この要件は重要です。提案されているネットワーク構成では、各デバイスが他のデバイスで使用されている消耗品に関する情報にすぐにアクセスできることが期待されます。
また、デバイスは、テスト プロセスで使用されるさまざまな化学物質の量を追跡する必要があります。化学物質の各ボトルにはロット番号とバーコードが付けられています。ボトルがマシンに挿入されると、マシンはデータベースを読み取り、ボトルから消費された液体の量を判断します。ロット番号の付いたボトルはどのマシンにも挿入でき、マシンはボトル内の液体の量を正確に評価できると予想されます。
クライアントは、次の 2 つのアーキテクチャのどちらを使用するかについての推奨事項を求めています。
1.) 各デバイスは、現在と同様に、独自のローカル データベースにデータを書き込みます。各デバイスに同期ソフトウェアがインストールされ、同期はリアルタイムで実行されます。各デバイスは定期的にハートビートをブロードキャストし (1 ～ 5 分の間隔が提案されています)、このハートビートには CRC チェックサムが含まれます。ネットワーク上のすべてのデバイスはハートビートをリッスンします。ハートビートの CRC が自身のものと異なる場合、デバイスは同期を開始します。同期ソフトウェアは、テストを実行するソフトウェアの外部にあり、独立しています。したがって、デバイスがネットワークから切断されている間、または同期ソフトウェアが実行されていない間にデバイスが実行される可能性は理論的にはありますが、可能性は高くありません。
2.) 各デバイス上のデータベース サーバーが削除され、代わりにデータベース サーバーが使用されます。
クライアントは、データベース サーバーを使用すると、サーバー障害時にネットワーク上のすべてのデバイスが使用できなくなることを懸念しています。ピア トポロジを使用すると、このリスクは効果的に軽減されますか? つまり、ネットワーク上の 1 つのピアに障害が発生した場合、他のすべてのピアは通常どおり動作しますか? どちらのアプローチにも、データ整合性に関する危険性や利点はありますか?
iag と MikeyB からの回答に応じて編集:
私の質問には曖昧さが残っていることが分かりましたので、より意味のある言い回しにして再度質問させていただきます。
クライアント サーバー環境では、サーバーに障害が発生するとすべてのクライアントがシャットダウンされるため、サーバー障害は壊滅的です。このような設計上の特徴を考慮すると、なぜ一部の極めて重要な情報、在庫、財務、医療システムではピアツーピアではなくクライアント サーバー アーキテクチャが実装されるのでしょうか。
ここで質問しているのは、「サーバー障害のリスクを軽減するにはどうすればよいか」ではなく、「ピアツーピア アーキテクチャはサーバー障害のリスクを軽減するのに効果的な方法か」です。その理由を教えてください。ネットワークのトポロジはアプリケーションの設計に影響しますか。ピアツーピアは、データの破損やあいまいな結果をもたらす可能性がありますか。
以下は、ピアツーピア ネットワーク トポロジで発生する可能性のある現実的な例ですか?
DeviceA、DeviceB、および DeviceC は、エージェント R と呼ばれる共通エージェントを共有するピア ネットワーク上のコンピューターです。ピアは、使用可能な R の量を確認する必要があるときはいつでも、他のピアと同期して、使用可能量を計算します。ある日の午後 1 時頃、ラボの技術者が DeviceB に R のボトルを挿入します。DeviceB はすぐに DeviceC と同期し、DeviceC がそのボトルから R を消費したことがないことを確認します。ただし、DeviceA は正午から ping に応答していません。DeviceB は、ボトル内の使用可能な R の量を確実に計算できますか?
私はソフトウェア エンジニアで、これらのデバイスがネットワーク経由でデータを共有できるようにするアプリケーションを作成する予定です。正直なところ、私が尋ねている質問については意見がありますが、クライアントは私の経験を信用していません。同僚の経験を知りたいので、ここに投稿しました。誰かの口から言葉を奪いたくないので、できるだけ一般的な表現を避けながら、問題を説明するようにしています。
答え1
ピアツーピア ソフトウェア アーキテクチャは、基盤となるネットワークに既に冗長性があることを前提として、ノード間で情報を配信するための効率的でフォールト トレラントな方法になります。
ピアツーピア アーキテクチャは、複数のノードがデータを保持している場合にも、データ損失から保護できます。一般的なピアツーピア システムでは、ノードは自身の利益のためにデータを保持します。個人の利益ではなくポリシーの遵守のためにデータを保持したいので、必要なことは異なります。
各ノードがこれまでに見たすべてのデータを保存するのは、データ量が限られている限り簡単です。しかし、ストレージ容量の都合上（または、一部のシナリオでは法的要件のため）、すべてのデータを保存するのは現実的ではない場合があります。その場合、何を削除し、何を保持するかについて注意する必要があります。これが大きな落とし穴の 1 つです。
しかし、これらすべては、データの整合性と一貫性の問題に対処するものではありません。データの正確さを考慮せずに、単にピアツーピア アーキテクチャに切り替えると、その点におけるシステムの堅牢性が低下します。破損が発生する場所が単純に増えるだけです。
このようなソリューションを実装するには、データの整合性を検証する方法を理解する必要があります。
システム内の特定の 1 つのノードによってのみ更新できるデータは、最も扱いやすいものです。しかし、そのノードが不正な動作を始めた場合、システムの許容可能な動作は何かという疑問は依然として残るでしょう。ノードが各更新に暗号署名を行うだけでは不十分です。署名された更新を誤って送信して、以前に書き込んだ内容をすべて削除したり、データの新しい値が一致しない複数の署名された更新を送信したりする可能性があるからです。この場合も、すべてを保存しておき、競合する更新が見つかった場合は手動で介入するというシンプルなアプローチがあります。しかし、データに基づいて何らかの自動決定を行う必要がある場合は、それでは不十分です。
1 つのノードだけがデータを更新できるが、他のすべてのノードがその更新内容に同意するという厳格な要件がある場合、問題は少し難しくなります。
この問題の解決方法はまだそれほど複雑ではなく、このようなデータ整合性の問題を解決するために使用される方法の種類についての良いアイデアを提供します。
- 更新ノードは更新されたデータに署名し、ピアツーピアネットワークを通じて配布します。
- 受信ノードは受信した最初のバージョンに署名し、更新ノードに送り返す
- 更新ノードが全ノードの 2/3 以上 (自身を含む) からの署名を取得すると、署名のコレクションとともにピアツーピア ネットワークを介してデータを再度配布します。
- 2/3 からの署名によって検証されたこのバージョンを受信するすべてのノードは、データの最終バージョンを永続的に保存したことをまだ確認していないすべてのノードに (指数バックオフを使用して) 再送信を続けます。
最初に更新を送信することを許可されたノードが、データが二度と更新されないように失敗する可能性があります。ただし、一貫性のある更新を送信する限り、ピアツーピア ネットワーク全体で一貫性のある形で保存されることになります。
各データに多数の署名が必要なので、大量のストレージ スペースが必要になると思われるかもしれません。幸いなことに、しきい値署名と呼ばれる方法によってこれを回避できます。
しかし、データベースを置き換えたい場合、1 つのノードがデータの一部を更新できるだけでは不十分です。複数のノードがあり、同じデータの一部を更新できますが、ネットワーク全体で誰が最初に更新したかについて合意する必要があります。ここでビザンチン合意が登場します。
この解決策は、上で説明したものより桁違いに複雑です。しかし、知っておくべき重要な結果をいくつか挙げることはできます。
2 つの障害モデルから選択する必要があります。障害が発生したノードは通信を停止するだけで、破損したメッセージを 1 つも送信しないと想定できます。このモデルでは必要なハードウェアは少なくなりますが、1 つのビットが反転するだけでシステムがダウンします。
あるいは、ビザンチン障害モデルを選択することもできます。このモデルでは、障害が発生したノードが何でも実行でき、システムは存続します。tこのモデルで障害を許容するには、3t+1合計でノードが必要です。つまり、1 つのノードの障害を許容するには、4 つのノードが必要です。合計で 10 個のノードがある場合は、3 つのノードの障害を許容できます。
また、同期通信モデルと非同期通信モデルのどちらかを選択する必要があります。同期通信とは、通信のタイミングについて想定することを意味します。パケットが宛先に到達するのに想定よりも長い時間がかかる場合、システムは機能しなくなります。さらに、ノードがクラッシュした場合、システムを続行するには最大許容遅延時間だけ待機する必要があります。
非同期モデルではソフトウェア設計がより複雑になりますが、明らかな利点がいくつかあります。タイムアウトを待つ必要がなく、2/3 以上のノードから応答が返ってくるまで待ってから続行するだけで済みます。これは、大きなタイムアウトが必要な同期モデルよりもはるかに高速です。
非同期モデルのもう 1 つの欠点は、ランダム化する必要があることです。アルゴリズムの実行時間は、最悪のケースの境界のない確率変数になります。更新に無限の時間がかかる可能性は理論的にはありますが、その確率はゼロであることがわかります。実際、通信の平均ラウンドトリップ数は一定であることがわかります。私にとっては、これは、通信が遅れると機能しなくなる可能性がある同期モデルに比べて、はるかに好ましいように見えます。
ご想像のとおり、このようなシステムを正しく構築するのは簡単な作業ではありません。これを実装するには、専用の開発作業が必要です。さらに、ソフトウェアのバグによってシステムがダウンする可能性もあります。ノードの 3 分の 1 未満に障害が発生した場合、システムは存続します。しかし、ソフトウェアにバグが存在する場合、そのバグのあるソフトウェアをノードの 3 分の 1 以上にインストールする可能性もあります。
答え2
ここでは多くの問題が発生する可能性があります。
まず、検討対象として、提示されたとおりには管理が難しく、フォールト イントレランスも備えていない、未完成のソリューションが 2 つ提示されました。
第二に、データ サービスの構築方法について混乱しているようです。これはさらに懸念すべきことです。
説明されている環境でのお客様の関与状況がどのようなものかはわかりませんが、バックアップ (ライブまたはそれ以外) なしで多数のデータベースを実行するランダム ボックスよりも、何もせずに、より適切な要件を定義し、それを達成するためのより適切な計画を立てることをお勧めします。
ラボの在庫が心配な場合は、たくさんこれに対処するソフトウェアは世の中にたくさんあります。ベンダー独自の奇妙な機能を扱う場合は、環境要件を確立し、ある程度の保証をもってこのデータにアクセスし、保持する方法を見つけてください。これはこれまでにも行われてきたことだと思います。
このフォーラムに漠然とした質問を投稿するだけでは、何も解決しません。手に負えないと感じたら、コンサルタントに数時間相談して支援してもらってください。
答え3
与えられた環境では、データの情報源が 1 つだけであることが不可欠であるように思われます。それは本当でしょうか? わかりません。
失敗のポイントは常に存在します。許容できる範囲で設計する必要があります。
システムに関する制約を考え出す必要があります。データのソースは 1 つにする必要がありますか? デバイスはオフラインでもインベントリを使用できますか? 1 つのサーバー障害は許容できますか? システムは短時間、読み取り専用モードでの動作を許容できますか?
これらの制約が分かれば、どうやってシステム設計の問題は制約から生じます。