Walkaway DR — スマートフォン1台で壊れたサーバーを復元する方法

誰も想定しないシナリオ

エンタープライズソフトウェアにおける災害復旧とは、フェイルオーバークラスタ、レプリケーションデータベース、24時間365日の運用チームを意味します。データセンター、ネットワークエンジニア、そして予算があることが前提です。

それらをすべて取り除いてください。災害地域のRaspberry Piで医療ステーションを運営しています。電源アダプタが蹴り飛ばされました。SDカードが破損しました。余震で折りたたみテーブルからデバイスが落下しました。デバイスは完全に動作不能です。

過去72時間のすべての患者記録がそのデバイスにありました。トリアージ分類。投薬記録。血液製剤の管理チェーン。進行中の手術症例。すべてです。

従来の災害復旧は「バックアップから復元する」と言います。しかし、バックアップサーバーは今故障したデバイスそのものです。クラウドはありません。第二のデータセンターもありません。ITチームもいません。

あるのは、5分ごとにバックグラウンドでデータを同期してきたスマートフォンを持つ看護師だけです。

ライフボートプロトコル

私たちはこれをライフボートプロトコルと呼んでいます。比喩が正確だからです。船が沈むとき、救命ボートが乗客を運びます。サーバーが落ちるとき、スマートフォンがデータを運びます。

xGridフリートのすべてのPWA（Progressive Web App）は、Lifeboat Clientと呼ばれるバックグラウンドプロセスを実行しています。5分ごとに、Raspberry Piから新しいデータを静かに取得し、ブラウザのIndexedDBにローカル保存します。IndexedDBは永続的なデータベースで、アプリの再起動、スマートフォンの再起動、機内モードでも生き残ります。

バックアップはファイルではありません。サーバー上で発生したすべての変更を含む構造化されたイベントストアであり、さらにすべての重要テーブル（患者記録、血液製剤、手術症例、投薬スケジュール、ケアプラン）の現在の状態を定期的にスナップショットとして保存しています。

サーバーが故障しても、スマートフォンはすぐには気づきません。次に同期を試みたとき、サーバーが消えたことに気づきます。新しいRaspberry Piがネットワークに現れると、スマートフォンは自動的に検出します。サーバーのIDが変わり、データベースが空であることを認識します。

それが復元のトリガーとなります。

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回押すことができます。結果は1回押した場合と同一です。これは便利機能ではありません。重要な安全特性です。不安定な接続のストレスフルな環境では、人々はリトライします。システムはリトライを適切に処理しなければなりません。

復元される内容

ライフボートスナップショットは20の重要テーブルをカバーしています：

患者安全に関わるすべてのテーブルが含まれています。臨床判断に影響するものは、復元後も存続します。

SDカードの現実

Raspberry PiデバイスはSDカードをストレージとして使用しています。SDカードは摩耗します。データベースサーバーの書き込みパターン向けに設計されていません。24時間365日稼働するフィールド展開において、SDカードの故障は「起きるかどうか」ではなく「いつ起きるか」の問題です。

これがライフボートプロトコルが存在する理由です。発生しにくい事象に対する保険ではなく、システムの運用前提の日常的な一部として。システムはハードウェア障害を前提に設計されています。

復元プロセスは新しいSDカードも保護します。何千もの個別のデータベース操作を書き込む代わりに、イベントの各バッチが単一のトランザクションで処理されます。書き込み操作が少ないということは、SDカードの摩耗が少なくなり、交換デバイスの寿命が延びることを意味します。

12ステップ検証

当社のエンドツーエンドDRテストは12ステップで実行されます：

1. 元のサーバーに患者、血液製剤、手術症例、LSCOデータを投入
2. バイタルサイン、TCCC傷病者カード、MEDEVAC要請を含むPFCケアプランを作成
3. すべてのイベントとスナップショットをエクスポート（ページネーション、カーソルベース）
4. 元のサーバーのチェーンハッシュフィンガープリントを記録
5. 空のデータベースで新しいサーバーを起動
6. バッチ1を復元：スナップショット + 最初のイベントバッチ
7. 残りのバッチを復元
8. 元のサーバーと復元サーバー間でチェーンハッシュを比較
9. すべてのイベントを再送信（冪等性テスト）-- 重複ゼロを検証
10. すべてのLSCOデータが存続したことを検証：PFCプラン、TCCCカード、MEDEVAC要請
11. 復元履歴を確認：拒否されたイベントゼロ
12. 完全な監査証跡の整合性を確認

12ステップすべてが合格します。復元されたサーバーは元のサーバーと区別がつきません。同じデータ、同じ履歴、同じチェーンハッシュです。

実務における意味

野戦病院チームは2台のRaspberry Piデバイスと予備部品の箱を持って展開します。デバイスが故障したとき（必ず故障します）、交換作業は数時間ではなく数分で完了します。エンジニアは不要です。コマンドラインアクセスも不要です。「スマートフォンが求めたらPINを入力する」以上の特別な研修も不要です。

データはサーバーに存在しているのではありません。あらゆる場所に存在しています。サーバーに接続したことのあるすべてのスマートフォンとタブレットに。サーバーは真実の源ではありません。便利な集約ポイントです。スマートフォンこそが救命ボートであり、常に準備ができています。

これがWalkawayの実践的な意味です。開発者が離れられるということだけではありません（離れられます -- The Walkaway Test をご参照ください）。ハードウェアも離れられるのです。テーブルから落ちる。踏まれる。余震で燃える。データは生き残ります。なぜなら、データは決して一箇所だけにはなかったからです。

---

関連記事: The Walkaway Test · SQLite in the Battlefield · Hub-and-Spoke: Network Architecture for Disconnected Operations