Walkaway DR — 스마트폰 한 대로 죽은 서버를 복원하는 방법

아무도 대비하지 않는 시나리오

엔터프라이즈 소프트웨어의 재해 복구란 페일오버 클러스터, 복제된 데이터베이스, 24시간 운영 팀을 의미합니다. 데이터센터, 네트워크 엔지니어, 그리고 예산이 있다고 가정합니다.

이제 그 모든 것을 제거하십시오. 재난 지역에서 Raspberry Pi 하나로 의료 스테이션을 운영하고 있습니다. 전원 어댑터가 발에 걸려 빠졌습니다. SD 카드가 손상되었습니다. 여진으로 접이식 테이블에서 장치가 떨어졌습니다. 장치가 완전히 작동을 멈췄습니다.

지난 72시간 동안의 모든 환자 기록이 그 장치에 있었습니다. 트리아지 분류. 투약 기록. 혈액 제제 관리 체인. 진행 중인 수술 사례. 전부입니다.

기존 재해 복구는 백업에서 복원하라고 합니다. 그러나 백업 서버는 방금 고장 난 바로 그 장치입니다. 클라우드가 없습니다. 두 번째 데이터센터도 없습니다. IT 팀도 없습니다.

있는 것은 5분마다 백그라운드에서 데이터를 동기화해 온 스마트폰을 가진 간호사뿐입니다.

구명정 프로토콜

이것을 구명정 프로토콜이라고 부릅니다. 비유가 정확하기 때문입니다. 배가 침몰할 때 구명정이 승객을 운반합니다. 서버가 다운되면 스마트폰이 데이터를 운반합니다.

xGrid 함대의 모든 PWA(Progressive Web App)는 Lifeboat Client라는 백그라운드 프로세스를 실행합니다. 5분마다 Raspberry Pi에서 새로운 데이터를 조용히 가져와 브라우저의 IndexedDB에 로컬 저장합니다. IndexedDB는 앱 재시작, 스마트폰 재부팅, 심지어 비행기 모드에서도 살아남는 영속적 데이터베이스입니다.

백업은 파일이 아닙니다. 서버에서 발생한 모든 변경 사항을 포함하는 구조화된 이벤트 저장소이며, 모든 중요 테이블(환자 기록, 혈액 제제, 수술 사례, 투약 일정, 케어 플랜)의 현재 상태에 대한 주기적 스냅샷도 포함합니다.

서버가 죽어도 스마트폰은 즉시 알지 못합니다. 다음 동기화를 시도할 때 서버가 사라졌다는 것을 인식합니다. 새 Raspberry Pi가 네트워크에 나타나면 스마트폰이 자동으로 감지합니다. 서버의 ID가 변경되었고 데이터베이스가 비어 있다는 것을 확인합니다.

그것이 복원을 시작하는 트리거입니다.

3분 만에 완전 복구

복구 흐름은 엔지니어가 아니라 간호사를 위해 설계되었습니다:

1단계

감지

스마트폰이 빈 데이터베이스를 가진 새 서버를 감지합니다. 배너가 나타납니다: "새 서버가 감지되었습니다. 데이터를 복원하시겠습니까?"

2단계

인증

간호사가 관리자 PIN을 입력합니다. 이것은 무단 복원을 방지합니다. 코드 없이는 서버 데이터를 덮어쓸 수 없습니다.

3단계

복원

스마트폰이 캐시된 모든 이벤트와 스냅샷을 배치로 전송합니다. 서버가 트랜잭션으로 처리합니다. 일반적인 복원 시간: 3분 이내.

스냅샷이 현재 상태를 즉시 복원하므로 대시보드가 몇 초 만에 사용 가능해집니다. 이벤트가 전체 히스토리를 재생하여 모든 감사 추적이 온전하게 보존됩니다.

스냅샷만이 아닌 이벤트가 필요한 이유

스냅샷은 현재 상태를 알려줍니다. 이벤트는 그 상태에 어떻게 도달했는지를 알려줍니다.

스냅샷만 복원하면 환자 A에게 혈액 2단위가 배정되어 있다는 것은 알 수 있습니다. 그러나 누가 배정했는지, 언제, 왜 배정했는지는 알 수 없습니다. 환자가 출혈 중이고 의사가 다른 환자를 수술 중이었기 때문에 새벽 2시에 긴급 오버라이드로 배정되었다는 사실도 알 수 없습니다.

xGrid는 모든 상태 변경을 불변의 이벤트로 기록합니다. 누가, 언제, 어떤 장치에서, 어떤 근거로 수행했는지. 이벤트 저장소는 추가 전용이며, 이벤트는 삭제되거나 수정되지 않습니다. 각 이벤트는 콘텐츠의 암호화 해시를 포함합니다.

스마트폰이 새 서버로 복원할 때 완전한 이벤트 체인을 전송합니다. 서버는 현재 상태뿐 아니라 모든 결정, 모든 오버라이드, 모든 인수인계의 전체 히스토리를 재구성할 수 있습니다.

체인 해시 검증

복원된 데이터가 완전하고 변조되지 않았다는 것을 어떻게 확인합니까?

각 엔터티 유형(혈액 제제, 수술 사례, 환자 기록)은 롤링 체인 해시를 유지합니다:

chain[i] = SHA-256(chain[i-1] + event_id + payload_hash)

개념적으로 블록체인과 유사하지만 오버헤드가 없습니다. 원본 서버에 500건의 혈액 제제 이벤트가 있어 체인 해시 a3f2...를 생성했다면, 복원 서버가 동일한 500건의 이벤트를 처리할 때 동일한 체인 해시 a3f2...를 생성해야 합니다.

어떤 이벤트라도 누락, 수정, 또는 순서가 다르면 체인 해시가 분기됩니다. 시스템이 이를 플래그 처리합니다. 누군가 데이터를 사용하기 전에 문제가 있다는 것을 알 수 있습니다.

멱등성: 불안정한 네트워크를 위한 안전망

간호사의 스마트폰이 복원 도중에 WiFi를 잃으면 어떻게 됩니까? 다시 연결하고 "복원"을 다시 누릅니다. 모든 것이 중복됩니까?

아닙니다. 모든 이벤트에는 고유 ID와 콘텐츠 해시가 있습니다. 서버가 이미 처리한 이벤트를 수신하면 다음을 확인합니다:

같은 ID, 같은 해시: 이미 존재합니다. 건너뜁니다. 중복 없음.
같은 ID, 다른 해시: 충돌입니다. 거부하고 조사를 위해 로그 기록.
새 ID: 정상적으로 삽입.

간호사가 "복원"을 10번 누를 수 있습니다. 결과는 한 번 누른 것과 동일합니다. 이것은 편의 기능이 아닙니다. 중요한 안전 속성입니다. 불안정한 연결의 스트레스 환경에서 사람들은 재시도합니다. 시스템은 재시도를 우아하게 처리해야 합니다.

복원되는 내용

라이프보트 스냅샷은 20개의 중요 테이블을 포괄합니다:

핵심 의료

마취 사례, 장비 상태, 혈액 단위 및 관리 체인

LSCO 모듈

PFC 케어 플랜, 활력 징후, 중재, 투약 일정, 임상 경고

야전 운영

TCCC 부상자 카드, MEDEVAC 요청, DCS 단계 로그, 연기된 시술

거버넌스

승인 요청, 투표, 에스컬레이션 로그, 권한 모드, 사전 승인

환자 안전에 중요한 모든 테이블이 포함됩니다. 임상 결정에 영향을 미치는 것이라면 복원을 통해 보존됩니다.

SD 카드의 현실

Raspberry Pi 장치는 SD 카드를 저장 매체로 사용합니다. SD 카드는 마모됩니다. 데이터베이스 서버의 쓰기 패턴을 위해 설계되지 않았습니다. 24시간 가동되는 현장 배치에서 SD 카드 고장은 발생 여부가 아니라 시기의 문제입니다.

이것이 구명정 프로토콜이 존재하는 이유입니다. 발생 가능성이 낮은 이벤트에 대한 보험이 아니라, 시스템 운영 가정의 일상적인 부분으로서 존재합니다. 시스템은 하드웨어 장애를 전제로 설계되었습니다.

복원 프로세스는 새 SD 카드도 보호합니다. 수천 개의 개별 데이터베이스 작업을 기록하는 대신, 각 이벤트 배치가 단일 트랜잭션으로 처리됩니다. 쓰기 작업이 적다는 것은 SD 카드 마모가 줄어들어 교체 장치의 수명이 연장된다는 것을 의미합니다.

12단계 검증

당사의 엔드투엔드 DR 테스트는 12단계로 실행됩니다:

원본 서버에 환자, 혈액 제제, 수술 사례, LSCO 데이터 투입
활력 징후, TCCC 부상자 카드, MEDEVAC 요청이 포함된 PFC 케어 플랜 생성
모든 이벤트 및 스냅샷 내보내기 (페이지네이션, 커서 기반)
원본 서버의 체인 해시 핑거프린트 기록
빈 데이터베이스로 새 서버 시작
배치 1 복원: 스냅샷 + 첫 번째 이벤트 배치
나머지 배치 복원
원본 서버와 복원 서버 간 체인 해시 비교
모든 이벤트 재전송 (멱등성 테스트) -- 중복 제로 검증
모든 LSCO 데이터 생존 검증: PFC 플랜, TCCC 카드, MEDEVAC 요청
복원 히스토리 확인: 거부된 이벤트 제로
완전한 감사 추적 무결성 확인

12단계 모두 통과합니다. 복원된 서버는 원본과 구별할 수 없습니다. 같은 데이터, 같은 히스토리, 같은 체인 해시입니다.

실무적 의미

야전 병원 팀은 Raspberry Pi 장치 2대와 예비 부품 상자를 가지고 배치됩니다. 장치가 고장 나면(반드시 고장 납니다) 교체 작업은 몇 시간이 아니라 몇 분 안에 완료됩니다. 엔지니어가 필요 없습니다. 명령줄 접근도 필요 없습니다. "스마트폰이 요청하면 PIN을 입력하라"는 것 이상의 특별한 교육도 필요 없습니다.

데이터는 서버에 존재하는 것이 아닙니다. 서버에 연결된 적 있는 모든 스마트폰과 태블릿에 존재합니다. 서버는 진실의 원천이 아닙니다. 편리한 집계 지점일 뿐입니다. 스마트폰이 구명정이며, 항상 준비되어 있습니다.

이것이 실무에서 Walkaway가 의미하는 바입니다. 개발자가 떠날 수 있다는 것만이 아닙니다(떠날 수 있습니다 -- The Walkaway Test 참조). 하드웨어도 떠날 수 있다는 것입니다. 테이블에서 떨어집니다. 밟힙니다. 여진으로 불탑니다. 데이터는 살아남습니다. 데이터가 결코 한 곳에만 있지 않았기 때문입니다.