엣지 컴퓨팅 환경에서 DR은 왜 더 어려운가 — DR 설계 여정 #2

지난 포스트에서는 CDC + Kafka 기반 데이터베이스 DR의 본질과, 활성/대기(active/standby) 교차 운영 방식을 다뤘다. 이번에는 그 위에 얹힌 더 까다로운 계층을 이야기하려 한다. 현장 단말이 클라우드와 통신하는 엣지 컴퓨팅 환경에서 재해복구(DR)는 어떻게 달라지는가.

결론부터 말하면, 엣지가 끼어드는 순간 DR은 "데이터 복제" 문제에서 "현장 단말이 재연결되는가" 문제로 바뀐다. 데이터는 잘 복제해 두었어도 단말이 재연결되지 않으면 DR이 완료되지 않는다. 이 포스트에서는 그 간극을 어떻게 메웠는지, 그리고 왜 두 개의 DR 계층을 겹쳐 쌓는 설계에 도달했는지를 공유한다.

비유로 시작하자: 지점과 본사

상황을 일상에 빗대어 보자. 어떤 프랜차이즈가 본사와 여러 지점으로 이루어져 있다고 상상하자.

지점은 현장에서 직접 거래를 처리한다. 손님이 와서 계산하고, 물건을 건네는 일은 지점 안에서 완결된다. 본사가 통신 장애로 연락이 끊겨도 지점의 거래는 계속된다. 이것이 엣지 자율(autonomy)이다.

하지만 본사가 며칠 동안 연락이 안 되면 문제가 생긴다. 새로운 상품 가격표, 직원 스케줄, 프로모션 지시를 전달받지 못한다. 지점은 "있던 대로"는 일하지만, "새로운 지시"를 받을 수 없다.

재해 상황을 생각해 보자. 본사 건물에 화재가 났다. 지점은 당분간 자율적으로 거래를 이어가지만, 언젠가는 본사 기능을 어딘가에서 복구해야 한다. 이때 두 가지 질문이 나온다.

• 지점은 새로운 본사(임시 본사 등)에 어떻게 다시 연결되는가?
• 본사 데이터(가격표, 직원 정보 등)는 어떻게 새 본사로 옮겨오는가?

엣지 컴퓨팅 환경의 DR은 본질적으로 이 두 질문이다. 클라우드라는 "본사"가 재해로 멈췄을 때, 현장 단말이라는 "지점"이 새 클라우드(재해복구 사이트)에 어떻게 재연결되고, 데이터는 어떻게 이어지는가.

왜 엣지 DR이 더 어려운가

단순한 데이터베이스 DR이라면, 운영 데이터베이스의 변경을 DR 사이트 데이터베이스로 복제해 두면 끝이다. 운영이 멈추면 DR 사이트를 승격시켜 서비스를 이어간다.

엣지가 끼면 이야기가 달라진다. 현장 단말은 보통 아웃바운드 연결로 클라우드 제어 서비스에 접속해 있다. 그런데 단말 설정에는 최초 접속 주소가 고정되어 있는 경우가 많다. 연결이 끊겨도 같은 주소로만 재시도한다. 클라우드가 DR 사이트로 옮겨가면, 단말은 여전히 구 주소만 바라보고 있어 새 클라우드를 찾지 못한다.

이것을 엣지 재연결 문제라고 부른다. 데이터는 완벽하게 복제해 두었어도, 단말이 DR 사이트로 재연결되지 않으면 서비스가 실제로는 복구되지 않는다. DR을 "데이터 관점"에서만 보면 이 함정을 놓친다.

더 골치 아린 것은 단말이 한두 개가 아니라는 점이다. 프랜차이즈 지점이 수백 개일 수 있듯, 현장 단말도 수십~수백 대로 퍼져 있다. 재해 상황에서 일일이 주소를 바꿔주는 것은 현실적으로 불가능하다.

두 계층으로 쪼개어 생각하다

고민 끝에 우리는 DR을 두 계층으로 분리하기로 했다. 각 계층이 대응하는 장애 범위가 다르기 때문이다.

flowchart TB
    subgraph PRIMARY["1계층 — 같은 데이터센터 (HA)"]
        NA["인프라 노드 A"]
        NB["인프라 노드 B"]
        SVC["핵심 서비스 (엣지 통신)<br/>각 노드에 1 replica"]
    end

    subgraph EDGE["엣지 단말 (현장, 다수 분산)"]
        DT1["단말-1"]
        DT2["단말-2"]
        DTN["단말-N"]
    end

    subgraph DR["2계층 — 외부 DR 사이트 (재해 대비)"]
        MOM["재연결 중계 서비스"]
        DRC["DR 클라우드 제어"]
        DRS["DR 핵심 서비스 (대기)"]
    end

    SVC <-->|"정상 운영"| EDGE
    EDGE -.->|"데이터센터 재해 시<br/>① 자율로 서비스 유지<br/>② 중계 서비스에 재연결 요청"| MOM
    MOM -.->|"접속 정보 발급"| DRC
    DRC <-->|"재연결 완료"| EDGE
    DRC --> DRS

    style PRIMARY stroke-dasharray: 5 5, fill:none

1계층 (HA, 고가용성) 은 같은 데이터센터 안의 노드 장애에 대응한다. 두 대의 인프라 노드를 하나의 쿠버네티스 클러스터로 묶고, 핵심 서비스를 각 노드에 하나씩 띄워 둔다(DaemonSet). 한 노드가 멈춰도 다른 노드의 replica가 서비스를 이어간다. 이 계층은 HA이지 DR이 아니다. 데이터센터 자체가 재해를 만나면 두 노드가 함께 멈춘다.

2계층 (DR, 재해복구) 은 데이터센터 재해에 대응한다. 외부에 DR 사이트를 구축해 두고, 재해 시 현장 단말이 이 DR 사이트로 재연결되도록 한다. 핵심은 "재연결 중계 서비스"가 단말과 DR 사이트 사이에서 접속 정보를 발급해 준다는 점이다. 단말이 구 주소만 바라보는 문제를 이 중계 서비스가 풀어준다.

왜 이렇게 나누었는가. 1계층(HA)은 빠르지만 같은 데이터센터라는 한계가 있고, 2계층(DR)은 데이터센터 재해까지 커버하지만 전환에 시간이 걸린다. 이 둘은 서로 다른 범위의 장애를 담당하므로, 하나로 합치기보다 겹쳐 쌓는 것이 자연스럽다. 1계층이 흔들릴 일이 거의 없는 일상 장애를 잡아주고, 정말 데이터센터가 날아가는 재해는 2계층이 이어받는다.

핵심 서비스와 보조 서비스의 분리

여기서 한 가지 더 결정한 것이 있다. 현장 단말과 직접 통신하는 핵심 서비스와, 그렇지 않은 보조 서비스의 배치를 분리한 것이다.

핵심 서비스는 클라우드 제어와 엣지 단말 사이의 게이트웨이다. 이것이 멈추면 모든 단말과의 통신이 끊기므로 절대 중단되어서는 안 된다. 그래서 1계층의 HA 클러스터에 DaemonSet으로 배치했다.

반면 보조 서비스들은 핵심 서비스와 분리된 독립된 애플리케이션이다. 이들은 자체 데이터베이스를 가지고 동작하므로, 핵심 서비스와 무관하게 자체적인 데이터베이스 DR을 구축할 수 있다. 보조 서비스들은 활성/대기 교차 배치로 운영하되, 데이터베이스 DR은 앞선 포스트들에서 다룬 CDC + Kafka 양방향 복제를 그대로 적용했다.

이 분리의 의미는 장애 전파 경로를 끊는다는 데 있다. 핵심 서비스에 문제가 생겨도 보조 서비스는 자체 데이터베이스로 동작하고, 반대 방향도 마찬가지다. 모든 것을 한 덩어리로 묶으면 한쪽 장애가 전체로 번진다. 서비스의 의존성 구조를 따라 배치를 분리하면 장애 파급이 최소화된다.

2계층 전환이 작동하려면

2계층 DR 사이트로의 전환은 단말의 자율과 중계 서비스의 중계가 맞물려 작동한다.

데이터센터가 멈추면 단말은 즉시 클라우드 제어와 단절된다. 이때 단말은 자율 모드로 전환하여 기존 상태를 로컬에 유지한 채 현장 서비스를 계속한다. 이것이 버티는 시간이다. 프랜차이즈 지점이 본사와 연락이 끊겨도 "있던 대로" 거래를 계속하는 것과 같다.

단절을 감지한 단말은 중계 서비스에 재연결을 요청한다. 중계 서비스는 DR 사이트에서 접속 토큰을 발급받아 단말에 전달하고, 단말은 그 토큰으로 DR 사이트에 재가입한다. 이 과정이 끝나면 DR 사이트의 핵심 서비스가 활성화되어 관제를 이어받는다.

여기서 놓치면 안 되는 전제가 있다. DR 사이트는 단순히 빈 클러스터가 아니어야 한다는 점이다. 운영 클러스터의 상태(어떤 애플리케이션이 배포되어 있는지, 단말이 어떤 그룹으로 묶여 있는지)를 etcd 스냅샷으로 정기 백업해 두어야 DR 사이트에서 복원할 수 있다. 인증 기관(CA) 키도 마찬가지다. 이 키를 잃어버리면 모든 단말의 인증서를 다시 발급해야 하는데, 재해 상황에서 그것은 사실상 불가능하다. "DR 사이트를 지었다"는 것과 "DR 사이트가 실제로 작동한다"는 다른 말이다.

그래서 얻은 교훈

이 설계를 진행하면서 얻은 교훈을 정리하면 세 가지다.

첫째, DR은 "데이터 복제"와 "서비스 재연결"의 합이다. 데이터를 완벽히 복제해도 서비스가 재연결되지 않으면 DR은 완료되지 않는다. 엣지가 있는 환경에서는 재연결 문제가 데이터 복제보다 더 까다롭다.

둘째, DR은 계층으로 쪼개어 생각하라. 하나의 거대한 DR 체계로 모든 장애를 담으려 하면 어디선가 균열이 생긴다. 대응하는 장애 범위가 다르면 계층을 분리하는 것이 더 단숸하다. HA와 DR은 서로 다른 질문에 답하는 별개의 계층이다.

셋째, 서비스 의존성 구조를 따라 배치를 분리하라. 모든 서비스를 동일한 DR 패턴으로 묶으려 하지 말자. 현장 통신에 직결된 서비스는 HA가 필수고, 독립적인 서비스는 자체 DR 패턴을 가질 수 있다. 서비스마다 DR 요구사항이 다르면 배치도 다르게 하는 것이 자연스럽다.

DR은 한 번 설계해 두고 잊을 수 있는 것이 아니다. 2계층 전환이 실제로 작동하는지, etcd 백업이 주기적으로 잘 되고 있는지, CA 키는 안전한 곳에 백업되어 있는지, 정기적으로 점검하고 실제로 전환해 보아야 한다. "설계해 두었다"와 "재해 때 돌아간다"는 다른 말이라는 것을, 이 연재 전체에 걸쳐 반복해 강조하고 싶다.

이 포스트에서는 엣지 컴퓨팅 환경의 DR이라는 새로운 축을 살펴보았다. 데이터베이스 DR의 기술적 실체와 장애 전환 절차는 이후 포스트에서 다룰 예정이다.