質問: いつもお世話になっております。 タイトルも含めて上手く説明できているかわかりませんが、宜しくお願い致します。 ### 前提・実現したいこと 以下のような機器がある新システムの設計に関わっています。 * 機器A * 機器B * DB * 機器C(顧客が使用する機器) 機器Aと機器Bにはそれぞれ端末機器が多数接続されており、この2つの機器に載るアプリケーションがそれぞれシステムの頭脳としての役割を持っています。 機器Aと機器Bは都合上1つに統合できない前提です。 機器Aと機器Bのアプリケーションはそれぞれが自律的に動作しながらもお互いの状態に応じて処理をシーケンシャルに行っていきます。 機器Aと機器Bは1対多の関係になることもあります。 機器Cには機器Aと機器Bの状態をモニタリングする機能があります。 機器Aと機器Bからは機器Cの状態を知る必要はありません。 ### 直面している問題 旧システムでは DB がなく、アプリケーション間は以下のように TCP/IP で接続して独自プロトコルで通信を行い、それぞれの状態を通知したり指示を送ったりしていました。 (機器Cは機器Aを介して機器Bの状態を取得していました。) 機器C - 機器A - 機器B 今回の新システムでは、機器の状態や指示などをどのように伝えるかということで悩んでいます。 現在挙がっている案は以下です。 #### 案1 機器間の状態や指示は DB を介して取得する 各機器の状態は全て DB に載せ、他の機器は DB を参照して互いの状態を取得し、それに応じて処理を行うようにします。 この場合に懸念しているのは以下の点です。 * 状態が更新されたことを知るために、定期的に DB の状態を取得しないといけない? * 相手の機器に障害が発生した場合、それをどうやって検知するか? * 一時的なデータも DB に書き込まれるため、DB の更新が頻繁に行われる (ストレージが SSD なので、書き込み回数の制限は大丈夫か?) * 結合度が強すぎる気がする 他のチームから来た人に聞くと、そのチームではこの方法で情報のやり取りをしていたとのことでした。 #### 案2 通信を行う 旧システムと同じく、アプリケーション間で直接通信を行うようにします。 この場合に懸念しているのは以下の点です。 * プロトコルどうする? 双方向にリアルタイム通信を行う必要がある 独自プロトコルでもよいが、個人的には好ましくないと考えている 例えば WebSocket のようなプロトコルをアプリケーション間の通信で使用するのはありなのか? * マスターデータを取得するために結局 DB にアクセスするので、DB へのアクセスと通信によるやり取りと2つの処理を実装しないといけない * 機器Cから機器Bの状態を取得する場合、旧システムと同じく機器Aを経由するのか? この場合、機器Aに障害が発生すると機器Bの状態も取得できない それぞれが相互に接続すると複雑になるのでやりたくない ### 補足情報(言語/FW/ツール等のバージョンなど) 機器Aと機器Bには OS として Windows 10 IoT が載る予定です。 DB は SQL Server 2016 Express です。 開発環境は以下です。 * IDE: Visual Studio 2017 Professional * 言語: C# * ランタイム: .NET Framework or .NET Core (検討中) ### 最終的に知りたいこと このようなシステムの場合、どのような手法を取るのが一般的なのか? がわからずに悩んでいます。 ですので、そういった観点から回答をいただけると助かります。 宜しくお願い致します。
回答: 要件によって異なります。機器が増設される際にシームレスに対応したいのであればDBが望ましいと思います。 各機器は1台のDBサーバの状態テーブルを一定間隔でポーリングしつつ、状態が変われば処理する様にします。 ただしこの場合、イベントのトリガが状態の変化であり、例えばテーブルのあるフィールドが 1 -> 2 -> 3 と推移した際、2 への変化を漏らす事があります。 この様なケースを救いたいのであればメッセージキューを選定されるのが良いと思います。MQTT 等を使うと、MQTTサーバに subscribe した機器に対してメッセージを分配したり A から B に対するメッセージをMQTTサーバを経由して送れます。またブロードキャストの様な事も出来ます。