내 고객은 주어진 샘플에 대해 다양한 측정을 수행하고 그 결과를 데이터베이스에 기록하는 의료 기기를 제조합니다. 생성되는 데이터의 양은 상대적으로 적습니다.
현재 구성에서는 각 장치에 자체 컴퓨터가 있으며 해당 컴퓨터는 데이터베이스 서버의 인스턴스를 실행합니다. 장치가 네트워크에 연결되어 있지 않습니다.
클라이언트는 대략 50개의 장치가 LAN에 연결될 수 있도록 장치를 수정하려고 합니다.
이 장치는 로트 번호가 매겨진 다양한 소모품을 사용하며 한 번 사용하면 다시 사용할 수 없습니다. 이러한 로트 번호는 샘플을 측정할 때 데이터베이스에 기록됩니다. 현재 구성에서는 장치가 소모품이 다른 장치에서 사용되었는지 알 수 없기 때문에 이 요구 사항은 주목할 만합니다. 제안된 네트워크 구성에서는 각 장치가 다른 장치에서 사용하는 소모품에 대한 정보에 즉시 액세스할 수 있을 것으로 기대됩니다.
또한 장치는 테스트 과정에 사용되는 다양한 화학 물질의 양을 추적해야 합니다. 각 화학물질 병에는 로트 번호와 바코드가 표시되어 있습니다. 병이 기계에 삽입되면 기계는 데이터베이스를 읽어 병에서 소비된 액체의 양을 결정합니다. 로트 번호가 매겨진 병은 어떤 기계에도 삽입될 수 있고 기계는 병 안의 액체 양을 정확하게 평가할 수 있을 것으로 기대됩니다.
클라이언트는 두 가지 아키텍처 중 어떤 아키텍처를 사용해야 하는지에 대한 권장 사항을 원합니다.
1.) 각 장치는 지금처럼 자체 로컬 데이터베이스에 데이터를 씁니다. 각 장치에는 동기화 소프트웨어가 설치되며 실시간으로 동기화가 수행됩니다. 각 장치는 주기적으로 하트비트(1~5분 간격 제안)를 브로드캐스트하며 이 하트비트에는 CRC 체크섬이 포함됩니다. 네트워크의 모든 장치는 하트비트를 수신합니다. 하트비트 CRC가 자체 CRC와 다른 경우 장치는 동기화를 시작합니다. 동기화 소프트웨어는 테스트를 실행하는 소프트웨어 외부에 있으며 독립적입니다. 따라서 이론적으로는 네트워크 연결이 끊어졌거나 동기화 소프트웨어가 실행되지 않는 동안 장치가 실행될 가능성은 있지만 가능성은 없습니다.
2.) 각 장치의 데이터베이스 서버가 제거되고 대신 데이터베이스 서버가 사용됩니다.
클라이언트는 데이터베이스 서버를 사용하는 경우 서버 오류가 발생하면 네트워크의 모든 장치를 사용할 수 없게 될 것을 우려합니다. 피어 토폴로지를 사용하면 이러한 위험이 효과적으로 완화됩니까? 즉, 네트워크의 한 피어에 장애가 발생하면 다른 모든 피어도 정상적으로 작동합니까? 두 가지 접근 방식과 관련된 데이터 무결성 위험이나 이점이 있습니까?
iag 및 MikeyB의 답변에 대한 응답으로 편집:
내 질문이 모호함의 여지를 남기는 것을 볼 수 있으므로 여기에 다시 한 번 더 의미 있는 방식으로 표현되기를 바랍니다.
클라이언트-서버 환경에서는 서버 장애가 발생하면 모든 클라이언트가 종료되기 때문에 서버 장애는 치명적입니다. 이러한 설계 기능을 고려할 때 일부 매우 중요한 정보, 재고, 금융 및 의료 시스템이 P2P가 아닌 클라이언트-서버 아키텍처를 구현하는 이유는 무엇입니까?
"위험 서버 오류를 어떻게 완화합니까?"라고 묻는 것이 아닙니다. 저는 "P2P 아키텍처가 서버 장애 위험을 완화하는 효과적인 방법입니까?"라고 묻고 있습니다. 그 이유는 무엇? 네트워크의 토폴로지가 애플리케이션 설계에 영향을 줍니까? P2P 방식에서는 데이터 손상이나 모호한 결과가 발생할 가능성이 있습니까?
다음은 P2P 네트워크 토폴로지에서 발생할 수 있는 상황에 대한 현실적인 예입니까?
DeviceA, DeviceB 및 DeviceC는 에이전트 R이라는 공통 에이전트를 공유하는 피어 네트워크의 컴퓨터입니다. 피어는 사용 가능한 R의 양을 확인해야 할 때마다 다른 피어와 동기화하고 가용성을 계산합니다. 어느 날 오후 1시경, 연구실 기술자는 R 한 병을 DeviceB에 삽입합니다. DeviceB는 즉시 DeviceC와 동기화하고 DeviceC가 해당 병에서 R을 소비한 적이 없음을 확인합니다. 그러나 DeviceA는 정오부터 ping에 응답하지 않았습니다. DeviceB는 병에 들어 있는 R의 양을 안정적으로 계산할 수 있습니까?
저는 소프트웨어 엔지니어이고 이러한 장치가 네트워크를 통해 데이터를 공유할 수 있도록 하는 애플리케이션을 작성할 예정입니다. 솔직히, 나는 내가 묻는 질문에 대해 의견이 있지만 내 고객은 내 경험을 신뢰하지 않습니다. 동료들의 경험을 알고 싶어서 여기에 글을 올렸습니다. 나는 다른 사람의 입에 말을 넣고 싶지 않기 때문에 가능한 한 일반적이지 않고 문제를 설명하려고 노력하고 있습니다.
답변1
P2P 소프트웨어 아키텍처는 기본 네트워크에 이미 중복성이 있다는 가정 하에 노드 간에 정보를 전파하는 효율적이고 내결함성 있는 방법이 될 수 있습니다.
P2P 아키텍처는 여러 노드가 데이터를 보관하는 경우 데이터 손실로부터 사용자를 보호할 수도 있습니다. 일반적인 P2P 시스템에서는 노드가 자신의 이익을 위해 데이터를 보관합니다. 개인의 이익보다는 정책 준수로 인해 데이터를 보관하기를 원하기 때문에 원하는 것이 다릅니다.
지금까지 본 모든 것을 저장하는 각 노드는 데이터 양이 제한되어 있는 한 간단합니다. 그러나 모든 것을 저장하는 것은 저장 공간으로 인해(또는 법적 요구 사항으로 인해 일부 시나리오에서) 실용적이지 않을 수 있습니다. 그러면 무엇을 삭제할지, 무엇을 유지할지 신중하게 생각해야 합니다. 이것은 주요 함정 중 하나입니다.
그러나 이 모든 것은 데이터 무결성 및 데이터 일관성 문제를 해결하는 데 아무런 도움이 되지 않습니다. 데이터의 정확성을 고려하지 않고 단순히 P2P 아키텍처로 전환하면 해당 측면에서 시스템의 견고성이 저하됩니다. 부패가 유입될 수 있는 곳이 더 많습니다.
이러한 솔루션을 구현하려면 데이터 조각의 무결성을 검증하는 방법을 파악해야 합니다.
시스템의 특정 노드에서만 업데이트할 수 있는 데이터 조각이 처리하기 가장 쉽습니다. 하지만 해당 노드가 오작동하기 시작하면 시스템의 허용 가능한 동작이 무엇인지에 대해 여전히 질문해야 합니다. 노드가 각 업데이트에 암호화 방식으로 서명하는 것만으로는 충분하지 않습니다. 이전에 작성한 모든 내용을 삭제하기 위해 서명된 업데이트를 잘못 보낼 수 있거나 데이터의 새 값이 무엇인지에 동의하지 않는 여러 개의 서명된 업데이트를 보낼 수 있는 경우에는 충분하지 않습니다. 간단한 접근 방식은 모든 것을 저장하고 충돌하는 업데이트가 나타날 경우 수동 개입을 요구하는 것입니다. 그러나 데이터를 기반으로 어떤 종류의 자동화된 결정을 내려야 한다면 그것만으로는 충분하지 않습니다.
하나의 노드만 데이터를 업데이트할 수 있지만 다른 모든 사람이 해당 노드가 수행한 업데이트에 동의해야 한다는 엄격한 요구 사항이 있는 경우 문제는 약간 더 어려워집니다.
이 문제에 대한 해결책은 아직까지 그다지 복잡하지 않으며, 그러한 데이터 무결성 문제를 해결하는 데 사용되는 방법의 종류에 대한 좋은 아이디어를 제공합니다.
- 노드를 업데이트하면 업데이트된 데이터에 서명하고 이를 P2P 네트워크를 통해 배포합니다.
- 수신 노드는 수신된 첫 번째 버전에 서명하고 이를 업데이트 노드로 다시 보냅니다.
- 업데이트 노드가 전체 노드(자신 포함)의 2/3 이상으로부터 서명을 받으면 서명을 수집하여 다시 P2P 네트워크를 통해 데이터를 배포합니다.
- 2/3의 서명으로 검증된 이 버전을 수신하는 모든 노드는 데이터의 최종 버전을 영구적으로 저장했는지 아직 확인하지 않은 모든 노드에 계속 재전송합니다(지수 백오프 사용).
처음에 업데이트를 보내도록 허용된 노드는 데이터가 다시 업데이트되지 않도록 하는 방식으로 실패할 수 있습니다. 그러나 일관된 업데이트를 보내는 한 P2P 네트워크 전체에 일관되게 저장됩니다.
모든 데이터에 필요한 많은 수의 서명에는 많은 저장 공간이 필요한 것처럼 들릴 수 있습니다. 다행히 이는 임계값 서명이라는 방법을 통해 피할 수 있습니다.
그러나 데이터베이스를 교체하려는 경우 하나의 노드가 데이터 조각을 업데이트하는 것만으로는 충분하지 않습니다. 동일한 데이터 조각을 업데이트할 수 있는 여러 노드가 있지만 누가 먼저 업데이트했는지에 대해 전체 네트워크가 동의해야 합니다. 이것이 비잔틴 합의가 등장하는 곳입니다.
이에 대한 해결책은 위에서 설명한 것보다 훨씬 더 복잡합니다. 하지만 알아야 할 몇 가지 주요 결과를 언급할 수 있습니다.
두 가지 실패 모델 중에서 선택해야 합니다. 실패한 노드는 단순히 통신을 중단하고 손상된 메시지를 하나도 보내지 않는다고 가정할 수 있습니다. 이 모델에는 더 적은 하드웨어가 필요하지만 시스템을 중단시키는 데 단 한 번의 플립 비트만 있으면 됩니다.
또는 실패한 노드가 무엇이든 할 수 있도록 허용하는 비잔틴 실패 모델을 선택할 수 있으며 시스템은 계속 유지됩니다. 이 모델에서 장애를 허용하려면 총 노드가 t필요합니다 . 3t+1즉, 단일 장애가 발생한 노드를 허용하려면 4개의 노드가 필요합니다. 총 10개의 노드가 있다면 3개 노드의 장애를 견딜 수 있습니다.
또한 동기식 또는 비동기식 통신 모델 중에서 선택해야 합니다. 동기식 통신은 통신 타이밍을 가정한다는 의미입니다. 패킷이 목적지에 도달하는 데 예상보다 오랜 시간이 걸리면 시스템이 중단됩니다. 게다가 노드가 충돌하는 경우 시스템이 계속되기 전에 허용되는 최대 지연까지 기다려야 합니다.
비동기식 모델은 소프트웨어 설계를 더 복잡하게 만들지 만 몇 가지 분명한 장점이 있습니다. 시간 초과를 기다릴 필요가 없으며 계속하기 전에 노드의 2/3 이상으로부터 응답을 들을 때까지 기다려야 합니다. 이는 큰 시간 초과가 필요한 동기식 모델보다 훨씬 빠를 수 있습니다.
비동기식 모델의 또 다른 단점은 무작위화되어야 한다는 것입니다. 알고리즘의 실행 시간은 최악의 경우에 국한되지 않는 확률적 변수가 됩니다. 업데이트에 무한한 시간이 걸릴 것이라는 이론적 가능성이 있지만 그럴 확률은 0으로 표시될 수 있습니다. 그리고 실제로 평균 통신 왕복 횟수는 일정하다는 것을 알 수 있습니다. 나에게 이것은 통신이 지연될 경우 고장날 수 있는 동기식 모델에 비해 훨씬 유리해 보입니다.
상상할 수 있듯이 이러한 시스템을 올바르게 구축하는 것은 쉬운 일이 아닙니다. 이를 구현하려면 헌신적인 개발 노력이 필요합니다. 게다가 소프트웨어 버그로 인해 시스템이 다운될 수도 있습니다. 노드의 1/3 미만이 실패하더라도 시스템은 유지됩니다. 그러나 소프트웨어에 버그가 있는 경우 노드의 1/3 이상에 버그가 있는 소프트웨어를 설치할 수도 있습니다.
답변2
여기서 가능한 문제가 많이 보입니다.
첫째, 제시된 대로 관리하기 어렵고 내결함성이 없는 두 가지 설익은 솔루션을 고려하여 제공했습니다.
둘째, 데이터 서비스 구축 방법에 대해 혼란스러워하는 것 같습니다. 이것이 더 우려스럽습니다.
설명된 환경에서 귀하의 참여 상황이 어떤지 잘 모르겠지만 백업(라이브 또는 기타) 없이 많은 데이터베이스를 실행하는 무작위 상자보다 아무것도 하지 않고 더 나은 요구 사항을 정의하고 이를 달성하기 위한 더 나은 계획을 세우는 것이 좋습니다.
귀하의 우려 사항이 실험실 재고에 관한 것이라면 다음과 같은 사항이 있습니다.많이이 문제를 해결하는 소프트웨어가 있습니다. 공급업체의 독점적인 이상한 점을 가지고 작업하는 경우 환경 요구 사항을 설정하고 일정 수준의 확신을 가지고 이 데이터에 액세스하고 보관할 수 있는 방법을 찾으십시오. 나는 그것이 이전에 이루어졌음을 확신합니다.
이 포럼에만 모호한 질문을 게시한다고 해서 이런 일이 발생하지는 않습니다. 너무 어렵다고 느끼면 몇 시간 동안 컨설턴트의 도움을 받아야 합니다.
답변3
주어진 환경에서는 데이터에 대한 단일 정보 소스가 있어야 합니다. 그게 사실인가요? 우리는 말할 수 없습니다.
항상 실패 지점이 있기 마련입니다. 허용 가능한 수준을 중심으로 설계해야 합니다.
시스템 주변의 제약 조건을 생각해 내야 합니다. 단일 데이터 소스가 있어야 합니까? 장치가 오프라인 상태에서도 인벤토리를 사용할 수 있나요? 단일 서버 장애가 허용될 수 있습니까? 시스템이 잠시 동안 읽기 전용 모드로 작동할 수 있습니까?
이러한 제약 조건이 있으면어떻게시스템 설계의 한계는 제약에서 비롯됩니다.