まず、すでにご存じのHub-Spokeの話
「Hub-Spokeトポロジー」という用語は聞いたことがないかもしれませんが、あなたは毎日それを使っています。
任意の航空会社の路線図を開いてみてください。いくつかの巨大なノード——桃園、成田、シンガポール・チャンギ——から、数十の小さな都市へと密集した航路が放射状に伸びているのが見えます。大きなノードがHub（ハブ）、小さな都市がSpoke（スポーク）です。
ポイント・ツー・ポイント（上）対 Hub-Spoke（下）：中央ノードを経由した転送により、接続数を大幅に削減。出典: Wikipedia（パブリックドメイン）
なぜ航空会社はこのように設計するのでしょうか。なぜなら、もしすべての都市が他のすべての都市へ直行便を飛ばすなら、30都市で435路線が必要になるからです。しかし、すべての都市がまずHubへ飛び、そこから乗り継ぐなら、必要なのは30路線だけです。Hubは調整役であり、スケジューリング、乗り継ぎ、リソース配分を集中して処理します。
このパターンは情報システムでもよく見られます。1つの中央ノードが複数のエッジノードを調整するのです。データはHubに集中し、Spokeが第一線の業務を担います。
しかし、従来のHub-Spokeには致命的な前提があります。Hubは常にオンラインである。
フライトはハブ空港の再開を待てます。荷物はソーティングセンターの処理を待てます。しかし災害現場では、Hubがダウンしたら、患者は待てません。
xGridのHub-Spokeは、2つの重要な観念の変更を加えています。すべてのSpokeは単なる端末ではなく、完全なシステムである。そして——どのSpokeも現場で引き継いで新しいHubになれる。
切断は障害ではなく、想定された状態である
従来のシステムは、ネットワークの切断を「障害」として処理します——切断を検知し、アラートを発し、復旧を待つ。
xGridは切断を「正常」として設計します。どのデバイスも完全なシステムです——自前のリソースシステム、自前のデータベースを持っています。切断とは、同期する能力を一時的に失ったにすぎず、動作する能力を失ったわけではありません。
これがxGrid版Hub-Spokeと航空版との最大の違いです。Spokeは、Hubの指示を待つ端末ではなく、独立して動作できる完全なシステムである。Hubが提供するのは調整であって、能力ではない。
どのノードも完全なシステムである
これは設計全体で最も重要な観念です。どのデバイスも、出荷時点で1つの完全な医療ステーションである。
役割はハードウェアによって決まるのではありません。同じ機器が、Hubにもなれば、Spokeにもなる——違いはそれが演じる役割であって、それがどんな部品であるかではありません。これは、「Hub専用機」と「Spoke専用機」を用意する必要がないことを意味します。倉庫に置かれているのは「2種類の部品」ではなく、「同一の予備品の山」です。どれか1台が壊れたら、箱から新しいものを1台取り出し、つないで、業務を続けるだけです。
最小のデプロイメントに必要なのは1台の機器だけで、ネットワーク基盤は一切要りません——電源1つ、タブレット1台、それで1つの完全な医療ステーションです。増強が必要ですか。もう1台を持ってきてつなげば、それが新しいSpokeになります。1台の機器で前方医療ステーションを支えられ、1組の機器で1つの医療センターを支えられます。同じ設計が、規模に応じて伸縮するのです。
2層の独立したネットワーク — 一方が切れても、もう一方が支える
xGridのデプロイメントは、それぞれ独立した2層のネットワークが重なり合っています。一方は操作を担い（各機器がそれぞれ無線エリアを提供し、タブレットは最寄りの機器につなげば業務できる）、もう一方はステーション間の同期を担います。
肝心なのは、この2層が完全に独立していることです。同期を担う層が切れた？各ステーションのタブレットは操作を続け、ただステーション間の同期が一時的に失われるだけです。ある機器の無線エリアが故障した？同期はそのまま走り続け、その区域のタブレットは近隣のエリアへつなぎ直せばよいだけです。
一方の層が切れても、もう一方が支える。これが、「切断は想定された状態である」をネットワーク設計にまで落とし込んだ姿です。
どのSpokeも引き継げる
これは設計全体で最も強力な能力であり、それには2つの様相があります。
能動的に持ち去る。大量傷病者発生事案で、指揮センターが10キロ離れた場所に第2の傷病者集中点が現れたと通知し、すぐに2つ目の医療ステーションを開設する必要が生じます。あなたはSpokeの1台のところへ歩いて行き、それをバッテリーとタブレットと一緒にバックパックに詰め、新しい場所で電源につなぐ——するとそれは、つい先ほどまで元のHubが持っていたすべての患者データを携えた、完全で独立して動作する新しい医療ステーションになります。事前の計画も、特別な機器も要りません。
受動的に引き継ぐ。Hubのハードウェアが故障します——電源が焼け、落ちてきた天井に押し潰される。どのSpokeも、Hubがまだそこにいるかを継続的に監視しています。Hubが本当にオフラインだと確認できたら、オペレーターがSpokeの1台を指定して引き継がせます。どのSpokeも手元にほぼリアルタイムのバックアップを持っているため、引き継ぎ後に失われる患者データには明確な上限があります。そして傷病者が殺到するピーク時には、オペレーターはこの上限を手動でさらに低く抑えることもできます。
引き継ぎへの昇格は、全体として成功するか、全体として失敗するかの動作です——完全に引き継ぐか、元の状態に戻るかのどちらかであり、「昇格の途中で止まってしまう」中途半端な状態は生じません。
なぜ機械の自動ではなく、人の判断なのか。なぜなら、切断された環境では、Hubが本当に壊れたのか、それともケーブルがただ緩んだだけなのかを、確かめようがないからです。もし2台のSpokeが同時に自動で引き継いだら、それぞれが患者を受け入れる2つのHubができてしまいます——これをスプリットブレインと呼び、事後のデータ統合は大惨事になります。だからこそ、引き継ぎは人の意図的な判断でなければなりません。
ゾンビHubとスプリットブレイン防護 — 自律ではなく、機構に頼る
「2台を同時に昇格させるな」は1つのルールです。しかしルールは災害現場で破られます——混乱の中で誰かがもう一度ボタンを押してしまったら？
ですから、自律だけでは不十分です。xGridの設計は、期限切れのHubが自ら身を引くようにできています。壊れて電源につなぎ直された古いHubが再起動すると、それは現場にすでに「1世代新しい」Hubが動作していることに気づきます——主権を取り戻そうとはせず、自動的にSpokeへと退位するのです。誰かがそれを止めに行く必要はありません。
同様に、あるSpokeが再接続時に、互いに矛盾する2つの「主ステーション」を同時に見つけた場合、それは自分で適当に1つを選ぶのではなく、立ち止まって人に確認を求めます。各デプロイメントも互いに隔離されており、あなたのSpokeが隣のデプロイメントのHubに誤ってつながることはありません。
この機構はスプリットブレインを100%防げるわけではありません——完全に切断された2つのサブグループがそれぞれHubを引き継いだら、確かに2つの独立したHubができてしまいます。しかしこの機構は保証します。2つのサブグループがネットワークに再接続したその瞬間、より古いほうが自動的に身を引く。問題は、もとより「いかにスプリットブレインを永遠に防ぐか」ではなく、「スプリットブレインが起きたあと、いかに最速で自動修正するか」だったのです。
コンフリクト解決：データの性質しだい
2台のデバイスが切断中に、それぞれ同じデータを修正した——再接続したとき、どうするのか。
答えは、そのデータが何であるかによります。足し合わせられるものは足し合わせる——主ステーションがガーゼを5個、衛星ステーションが3個消費したなら、正解は「より新しいほうを採る」（それでは一方が失われる）ではなく、8個が消費された、です。修正できない記録（バイタルサイン、引き継ぎ）は両方を保持します。
最も重要なのは、誤りの代価が高すぎて、自動解決を許さないデータです。血液製剤、規制薬品。1袋の血液が2つのステーションで同時に「発行済み」とマークされた——これはタイムスタンプで解決できる問題ではありません。システムはそれをコンフリクトとしてマークし、責任者が自ら確認するのを待ちます。
「人の判断」を、排除すべき欠陥としてではなく、ある状況における正しい答えとして扱う——これが、高リスク環境のために設計するときの決定的な分かれ目です。
設計思想：切断のために生まれた
ほとんどのシステムは「ネットワークは信頼できる」という前提で設計され、その後、信頼できない場合のための例外処理を加えます。
xGridは「ネットワークは信頼できない」という前提で設計され、その後、信頼できる場合のための最適化を加えます。
この逆転が、まったく異なる設計判断を導きます。
- どのノードも完全なシステムである（画面を表示することしかできない端末ではない）
- 役割は演じることで決まり、ハードウェアでは決まらない（「特別なHub機器」は要らない）
- 同期は定期的なバッチ操作である（リアルタイムの常時接続ではない）
- コンフリクト解決はデフォルトの動作である（例外処理ではない）
- 人の判断はある状況における正しい答えである（排除すべき欠陥ではない）
- 引き継ぎは人の意図的な判断である（スプリットブレインは待機よりも危険だから）
- しかし期限切れのHubは自動的に身を引く（これは事実であって、自律ではないから）
ケーブルを蹴飛ばされても障害ではありません。スイッチを叩き壊されても末日ではありません。Hubが焼け落ちても終わりではありません。
それらはただ、トポロジー再編成の引き金にすぎないのです。
関連記事: 「オフラインファースト」は「オフラインで何とか使える」ではない · ISBARは単なる引き継ぎの形式ではない — 口頭の伝統が構造化データと出会うとき