케이블을 뽑고 출발 — 단절을 위해 태어난 Hub-Spoke 설계

이미 알고 계신 Hub-Spoke부터 이야기해 봅시다

"Hub-Spoke 토폴로지"라는 용어를 들어본 적이 없을 수도 있지만, 당신은 매일 그것을 사용하고 있습니다.

아무 항공사의 노선도나 펼쳐 보십시오. 몇 개의 거대한 노드 — 인천, 나리타, 싱가포르 창이 — 가 보이고, 그 노드에서 수십 개의 작은 도시로 빽빽한 노선이 뻗어 나갑니다. 큰 노드가 Hub(허브)이고, 작은 도시가 Spoke(스포크)입니다.

항공사는 왜 이렇게 설계할까요? 모든 도시가 다른 모든 도시로 직항한다면, 30개 도시에는 435개의 노선이 필요합니다. 하지만 모든 도시가 먼저 Hub로 날아간 뒤 Hub에서 환승하면, 30개의 노선만 있으면 됩니다. Hub는 조정자로서 스케줄링, 환승, 자원 배분을 집중적으로 처리합니다.

이 패턴은 정보 시스템에서도 흔히 볼 수 있습니다. 하나의 중심 노드가 여러 엣지 노드를 조정하는 것입니다. 데이터는 Hub에 집중되고, Spoke는 일선 작업을 담당합니다.

그러나 전통적인 Hub-Spoke에는 치명적인 가정이 하나 있습니다. Hub가 항상 온라인이라는 것입니다.

항공편은 Hub 공항이 다시 열릴 때까지 기다릴 수 있습니다. 패키지는 분류 센터가 처리할 때까지 기다릴 수 있습니다. 하지만 재난 현장에서 Hub가 다운되면, 환자는 기다릴 수 없습니다.

xGrid의 Hub-Spoke는 두 가지 핵심적인 관념 수정을 가합니다. 모든 Spoke는 단순한 단말기가 아니라 완전한 시스템입니다. 그리고 — 어떤 Spoke든 현장에서 새로운 Hub로 그 역할을 넘겨받을 수 있습니다.

단절은 장애가 아니라 예상된 상태입니다

전통적인 시스템은 네트워크 단절을 "장애"로 처리합니다 — 단절을 감지하고, 경보를 울리고, 복구를 기다립니다.

xGrid는 단절을 "정상"으로 보고 설계합니다. 모든 장치가 완전한 시스템입니다 — 자체 자원 시스템, 자체 데이터베이스를 가집니다. 단절은 단지 동기화 능력을 잠시 잃은 것일 뿐, 운영 능력을 잃은 것이 아닙니다.

바로 이것이 xGrid 버전 Hub-Spoke와 항공 버전의 가장 큰 차이입니다. Spoke는 Hub의 지시를 기다리는 단말기가 아니라, 독립적으로 운영할 수 있는 완전한 시스템입니다. Hub가 제공하는 것은 조정이지 능력이 아닙니다.

모든 노드가 완전한 시스템입니다

이것이 전체 설계에서 가장 핵심적인 관념입니다. 모든 장치는 출고 시점에 그 자체로 하나의 완전한 의료 스테이션입니다.

역할은 하드웨어가 결정하지 않습니다. 같은 기계가 Hub가 될 수도, Spoke가 될 수도 있습니다 — 차이는 그것이 맡은 역할에 있지, 그것이 어떤 부품인가에 있지 않습니다. 이는 곧 "Hub 전용기"와 "Spoke 전용기"를 따로 준비할 필요가 없다는 뜻입니다. 창고에 두는 것은 "두 종류의 부품"이 아니라 "동일한 예비품 한 무더기"입니다. 어느 한 대가 고장 나면, 상자에서 새 것 한 대를 꺼내 연결하고, 계속 진행합니다.

최소 규모의 배치는 단 한 대의 기계만 있으면 되며, 어떤 네트워크 인프라도 필요하지 않습니다 — 전원 하나, 태블릿 한 대면 그것이 완전한 의료 스테이션입니다. 규모를 늘려야 하나요? 다른 한 대를 가져와 연결하면, 그것이 새로운 Spoke가 됩니다. 한 대의 기계로 전방 의료 스테이션을 지탱할 수 있고, 한 묶음의 기계로 의학 센터를 지탱할 수 있습니다. 같은 설계가 규모에 따라 늘었다 줄었다 합니다.

두 겹의 독립된 네트워크 — 한 겹이 끊겨도 다른 한 겹이 버틴다

xGrid의 배치는 각자 독립된 두 겹의 네트워크가 겹쳐진 것입니다. 한 겹은 작업을 담당하고(각 기계가 자체적으로 무선 커버리지를 제공하며, 태블릿은 가장 가까운 기계에 연결하면 바로 작동), 다른 한 겹은 스테이션 간 동기화를 담당합니다.

핵심은 이 두 겹이 완전히 독립적이라는 점입니다. 동기화를 담당하는 겹이 끊겼다면? 각 스테이션의 태블릿은 계속 작업하고, 단지 스테이션 사이의 동기화만 잠시 멈출 뿐입니다. 어떤 기계의 무선 커버리지가 고장 났다면? 동기화는 그대로 돌아가고, 그 구역의 태블릿은 인근의 커버리지로 바꿔 연결하면 됩니다.

한 겹이 끊기면 다른 한 겹이 버팁니다. 이것이 "단절은 예상된 상태"라는 원칙이 네트워크 설계로 구현된 모습입니다.

어떤 Spoke든 역할을 넘겨받을 수 있다

이것은 전체 설계에서 가장 강력한 능력이며, 두 가지 모습을 가집니다.

능동적으로 가지고 떠나기. 대량 사상자 사건에서 지휘 본부가 10킬로미터 떨어진 곳에 두 번째 사상자 집중 지점이 생겼다고 통보하며, 즉시 두 번째 의료 스테이션을 개설해야 한다고 합니다. 당신은 Spoke 중 하나로 걸어가, 그것을 배터리, 태블릿과 함께 배낭에 넣고, 새 장소에 도착해 전원을 연결합니다 — 그것은 곧 완전하고 독립적으로 운영되는 새 의료 스테이션이 되며, 원래 Hub가 얼마 전까지 가지고 있던 모든 환자 데이터를 그대로 지니고 있습니다. 사전 계획도, 특수한 기계도 필요하지 않습니다.

수동적으로 넘겨받기. Hub의 하드웨어가 고장 났습니다 — 전원이 타버렸거나, 떨어진 천장에 맞았습니다. 모든 Spoke는 Hub가 아직 살아 있는지 지속적으로 모니터링합니다. Hub가 정말 오프라인이 되었음을 확인한 뒤, 운영자가 그중 한 대의 Spoke를 지정해 역할을 넘겨받게 합니다. 모든 Spoke가 거의 실시간에 가까운 백업 한 부를 손에 들고 있기 때문에, 넘겨받은 뒤 환자 데이터 손실에는 명확한 상한이 있습니다. 부상자가 밀려드는 정점에서는, 운영자가 이 상한을 수동으로 더 낮게 눌러둘 수도 있습니다.

역할을 넘겨받는 승격은 전체가 성공하거나 전체가 실패하는 동작입니다 — 완전히 넘겨받거나, 아니면 원래 상태로 되돌아가거나, 둘 중 하나입니다. "승격이 절반쯤에서 멈춘" 어중간한 상태는 발생하지 않습니다.

왜 기계의 자동이 아니라 사람의 결정인가? 단절된 환경에서는 Hub가 정말 고장 난 것인지, 아니면 단지 네트워크 케이블이 헐거워진 것인지 확신할 수 없기 때문입니다. 만약 두 대의 Spoke가 동시에 자동으로 역할을 넘겨받는다면, 당신은 각자 환자를 받는 두 개의 Hub를 갖게 됩니다 — 이것을 split-brain(스플릿 브레인)이라 하며, 사후에 데이터를 병합하는 일은 한바탕 재앙이 됩니다. 그래서 역할 인수는 반드시 사람의 의도적인 결정이어야 합니다.

좀비 Hub와 스플릿 브레인 방어 — 자율이 아니라 메커니즘으로

"두 대를 동시에 승격시키지 말 것"은 하나의 규칙입니다. 하지만 규칙은 재난 현장에서 깨지기 마련입니다 — 만약 누군가 혼란 속에서 한 번 더 눌러버린다면요?

그래서 자율에만 의존해서는 충분하지 않습니다. xGrid의 설계는 오래된 Hub가 스스로 자리를 내어주도록 합니다. 고장 났다가 다시 전원에 연결된 옛 Hub가 재부팅되면, 그것은 현장에 이미 "한 단계 더 새로운" Hub가 운영 중임을 발견합니다 — 그것은 주도권을 되찾으려 하지 않고, 자동으로 Spoke로 물러납니다. 사람이 그것을 끌 필요가 없습니다.

마찬가지로, 어떤 Spoke가 재연결 시 서로 모순되는 두 개의 "주 스테이션"을 동시에 보게 된다면, 그것은 제멋대로 하나를 고르지 않고, 멈춰 서서 사람에게 확인을 요청합니다. 각 배치 또한 서로 격리되어 있어, 당신의 Spoke가 옆 배치의 Hub에 실수로 연결되는 일은 없습니다.

이 메커니즘이 스플릿 브레인을 100% 예방할 수는 없습니다 — 만약 완전히 단절된 두 하위 그룹이 각자 하나의 Hub를 넘겨받았다면, 당신은 분명히 독립된 두 개의 Hub를 갖게 됩니다. 하지만 이 메커니즘은 보장합니다. 두 하위 그룹이 다시 네트워크에 연결되는 그 순간, 더 오래된 쪽이 자동으로 자리를 내어준다는 것을. 문제는 결코 "어떻게 스플릿 브레인을 영원히 막을 것인가"가 아니라, "스플릿 브레인이 발생한 뒤 어떻게 가장 빠르게 자동으로 바로잡을 것인가"입니다.

충돌 해결: 데이터의 성질에 달려 있다

두 장치가 단절 기간 동안 각자 같은 데이터를 수정했다면, 다시 연결되었을 때 어떻게 해야 할까요?

답은 그 데이터가 무엇이냐에 달려 있습니다. 누적할 수 있는 것은 누적합니다 — 주 스테이션이 거즈 5개를 소비하고 위성 스테이션이 3개를 소비했다면, 정답은 8개가 소비된 것이지 "더 새로운 쪽을 기준으로" 하는 것이 아닙니다(그렇게 하면 한쪽을 잃게 됩니다). 수정 불가능한 기록(생체 징후, 인수인계)은 양쪽 모두 보존합니다.

가장 중요한 것은 오류의 대가가 너무 커서 자동 해결을 허용하지 않는 데이터입니다. 혈액 백, 규제 약물이 그렇습니다. 한 백의 혈액이 두 스테이션에서 동시에 "발급됨"으로 표시되는 것은 타임스탬프로 해결할 수 있는 문제가 아닙니다. 시스템은 그것을 충돌로 표시하고, 담당자가 직접 확인할 때까지 기다립니다.

"사람의 판단"을 어떤 상황에서는 제거해야 할 결함이 아니라 정답으로 보는 것 — 이것이 고위험 환경을 위해 설계할 때의 핵심적인 분기점입니다.

설계 철학: 단절을 위해 태어나다

대부분의 시스템은 "네트워크는 신뢰할 수 있다"는 전제에서 설계를 시작하고, 신뢰할 수 없는 경우에 대해 예외 처리를 합니다.

xGrid는 "네트워크는 신뢰할 수 없다"는 전제에서 설계를 시작하고, 신뢰할 수 있는 경우에 대해 최적화를 합니다.

이 뒤집힘이 완전히 다른 설계 결정을 낳습니다.

• 모든 노드가 완전한 시스템(화면만 표시할 수 있는 단말기가 아님)
• 역할은 맡은 바로 결정되지 하드웨어로 결정되지 않음("특수한 Hub 기계"가 필요 없음)
• 동기화는 주기적인 배치 작업(실시간 지속 연결이 아님)
• 충돌 해결은 기본 동작(예외 처리가 아님)
• 사람의 판단은 어떤 상황에서는 정답(제거해야 할 결함이 아님)
• 역할 인수는 사람의 의도적인 결정(split-brain이 기다림보다 더 위험하기 때문)
• 그러나 오래된 Hub는 자동으로 자리를 내어줌(이것은 사실이지 자율이 아니기 때문)

네트워크 케이블이 차여 빠지는 것은 장애가 아닙니다. 스위치가 부서지는 것은 종말이 아닙니다. Hub가 타버리는 것은 끝이 아닙니다.

그것들은 단지 토폴로지가 재구성되는 계기일 뿐입니다.

---

더 읽어보기: 「오프라인 우선」은 「오프라인이라도 그럭저럭」이 아니다 · ISBAR는 단순한 인수인계 양식이 아니다 — 구두 전통이 구조화된 데이터와 만날 때