재해복구 체계 설계 — Active-Active 종속 4가지 해소

TL;DR — 가상화 Active-Active 가 Active-Standby 로 돌아간 까닭은 비용이 아니라 라이선스, IP, 공유 스토리지, 세션이라는 네 가지 종속이 서로를 조였기 때문이고, 쿠버네티스는 네 구조를 한 묶음으로 갖춰 이를 푼다.

공공기관의 프로덕션 운영 환경에서 재해복구 체계를 맡는 담당자가 클라우드 네이티브 도입을 검토하기 위해 가장 먼저 짚어야 할 것은 Active-Active 종속이 어떻게 생기느냐는 질문입니다. 왜 가상화에서는 두 사이트를 동시에 돌리기 어려웠고, 쿠버네티스는 그 방식을 어떻게 바꾸는지가 이 글의 주제입니다. 이 글은 클라우드네이티브TV 영상 ‘EP.02 · DR 구축 – 가상화 기술의 한계는 알아야 실패하지 않는다.'(7분 36초)의 내용을 캡처 8장과 함께 주장 단위로 풀어, 영상을 보지 않은 독자도 따라올 수 있게 정리했습니다.

클라우드네이티브TV의 이 영상은 클라우드 네이티브 재해복구 백서의 2장을 다룹니다. Active-Active 종속이 서로를 강화하는 모습을 먼저 보여 주고, 쿠버네티스가 그것을 네 가지 구조의 결합으로 푸는 방식, 그리고 복구 속도와 목표 복구 시간(RTO)의 기준이 바뀌는 이유로 이어집니다.

영상에서 다루는 순서는 다음과 같습니다.

• 가상화 Active-Active 를 묶는 네 가지 종속과 서로 조이는 구조 (2:33)
• 라이선스, 공유 스토리지, IP·세션 종속을 하나씩 짚기 (2:56, 3:18, 4:02)
• 쿠버네티스의 네 구조와 트래픽 분기 세 계층 (4:22, 5:27)
• Pod 부팅 속도와 RTO 를 정하는 기준의 이동 (6:09, 6:33)

Active-Active 종속에 관한 영상의 설명을 질문으로 바꾸면 여덟 가지입니다. 아래 여덟 개 절이 이 순서대로 답하고, 그 뒤에 영상 밖의 보충 두 절을 덧붙였습니다.

1. 가상화 Active-Active 는 왜 Active-Standby 로 돌아갔는가?
2. 라이선스는 어떻게 두 번 청구되는가?
3. 공유 스토리지는 왜 스플릿 브레인을 부르는가?
4. IP 고정성과 세션은 장애 범위를 어떻게 넓히는가?
5. 쿠버네티스는 이 종속을 어떤 구조로 푸는가?
6. 트래픽은 어떤 계층으로 나뉘는가?
7. Pod 는 왜 VM 보다 빨리 복구되는가?
8. RTO 를 정하는 기준은 왜 운영 규칙으로 옮겨지는가?

가상화 환경의 Active-Active 가 실무에 자리 잡지 못한 까닭은 비용이 비싸서가 아닙니다. 영상은 흔한 통념을 먼저 짚고, 진짜 이유는 따로 있다고 말합니다. 네 가지 종속이 서로 얽혀 있었기 때문입니다.

가상화로 Active-Active 를 해 보려는 시도는 꽤 많았지만 대부분은 결국 Active-Standby 로 돌아갔습니다. 라이선스, VM 의 IP, 공유 스토리지, 사용자 세션이 네 개의 축이 되어 하나를 풀면 다른 하나가 더 조이는 관계를 만들었습니다. 영상은 이를 한 줄에 엉킨 네 개의 매듭에 빗댑니다. 하나를 당기면 다른 매듭이 더 조여 오기 때문에 어느 하나도 혼자서는 풀 수 없습니다.

▲ 가상화 Active-Active 를 묶는 네 가지 종속 (영상 2:33)

캡처 제목은 ‘가상화 Active-Active 가 안착하지 못한 4가지 종속’입니다. 위쪽 노란 띠에는 4중 종속이 서로를 강화하며 어느 하나도 단독으로 해결할 수 없고, 대부분 Active-Standby 로 회귀했다는 요지가 적혀 있습니다. 가운데 주황색 원이 ‘가상화 AA 강결합’이고, 위에는 라이선스 이중 지불, 오른쪽에는 VM IP 고정성, 아래에는 공유 스토리지 쿼럼 락, 왼쪽에는 세션 어피니티 종속이 놓여 있습니다.

이 구조에서 읽어야 할 점은 Active-Active 종속이 개별 결함이 아니라 서로 강화하는 묶음이라는 것입니다. 영상은 예전에 이런 경험이 있는 기관이라면 그때 Active-Standby 로 돌아간 이유를 떠올려 보라고 권합니다. 네 가지와 나란히 놓으면 원인이 분명해진다는 설명입니다. 자기 기관이 왜 회귀했는지를 비용 탓이 아니라 구조 탓으로 다시 읽는 일이 이 영상의 출발점입니다.

첫 번째 종속은 라이선스입니다. 영상은 이렇게 설명합니다. 양쪽 사이트가 모두 돌면 코어 단위 요금이 두 번 나갑니다. 두 사이트가 모두 정상 가동 상태이므로 양쪽에 정상 요금이 붙습니다.

▲ 첫 번째 종속, 라이선스 이중 지불 (영상 2:56)

이 장면에서는 위쪽 라이선스 이중 지불 카드에 파란 테두리가 쳐지고, 위쪽 노란 띠의 문장 일부가 형광으로 강조됩니다. 카드 설명은 ‘코어·소켓 단위 양쪽 사이트 정상 청구’입니다. 가상화 환경에서는 CPU 코어나 소켓을 기준으로 값을 매기는 소프트웨어가 많아 사이트 수가 곧 비용의 배수가 됩니다.

라이선스는 비용으로 바로 드러나는 종속이라 회귀의 원인을 비용으로 오해하기 쉽습니다. 영상이 비용 때문이 아니라고 먼저 선을 그은 것도 이 때문입니다. 라이선스만 바꿔서는 나머지 세 종속이 그대로 남아 Active-Active 가 안정되지 않습니다.

세 번째로 영상이 짚는 종속은 공유 스토리지입니다. 두 사이트가 같은 데이터를 보려면 스토리지를 동기화해야 하는데, 그 동기화가 끊기는 순간 문제가 생깁니다. 영상은 한쪽이 읽기 전용으로 내려간다고 설명하고, 양쪽이 서로 주인이라고 나서는 스플릿 브레인도 생길 수 있다고 덧붙입니다.

▲ 세 번째 종속, 공유 스토리지와 스플릿 브레인 (영상 3:18)

캡처 아래쪽 카드에는 ‘공유 스토리지 쿼럼 락’이라는 이름 아래 파란 상자로 ‘한쪽 읽기 전용 강등 · split-brain’이 강조됩니다. 쿼럼 락은 어느 쪽이 쓰기 권한을 가질지 정하는 장치인데, 두 사이트 사이의 통신이 끊기면 이 합의가 깨질 수 있습니다.

운영자에게 이 문제가 무서운 까닭은 데이터의 일관성이 걸려 있기 때문입니다. 한쪽을 읽기 전용으로 내리면 Active-Active 라는 이름이 무색해지고, 내리지 않으면 양쪽이 서로 다른 값을 쓸 위험이 생깁니다. 어느 쪽을 택해도 Active-Active 의 이점이 줄어드는 구조입니다.

나머지 두 종속은 VM 의 IP 고정성과 세션입니다. 영상은 이렇게 말합니다. VM 의 IP 가 고정되어 있으면 사이트를 넘나들기 위해 넓은 L2 네트워크가 필요하고, 그만큼 장애가 번지는 범위도 넓어집니다. 세션은 트래픽을 나누는 순간 사용자 세션이 끊길 위험이 있다는 문제입니다.

▲ IP 고정성과 세션이라는 나머지 두 종속 (영상 4:02)

이 캡처에서는 왼쪽 세션 어피니티 종속, 오른쪽 VM IP 고정성 카드에 붉은 테두리가 쳐져 있습니다. 카드 설명은 각각 ‘트래픽 분기 시 세션 유실 위험’, ‘광역 L2 전제 → 장애 도메인 확장’입니다.

IP 와 세션, 두 Active-Active 종속의 공통점은 트래픽을 자유롭게 옮길 수 없다는 점입니다. IP 가 사이트에 묶여 있으면 요청을 다른 사이트로 보내기 어렵고, 세션이 특정 서버에 붙어 있으면 요청을 나누는 순간 로그인이 풀리거나 작업이 끊깁니다. 이 두 종속이 앞의 라이선스, 스토리지와 맞물려 있어서 영상이 말한 매듭 비유가 성립합니다. 네트워크를 넓히면 장애 범위가 커지고, 스토리지를 묶으면 스플릿 브레인이 생기고, 둘 다 라이선스 비용을 키웁니다.

여기까지가 문제이고, 이제부터 해법입니다. 영상은 쿠버네티스가 이 문제를 푸는 것은 기능 하나가 아니라고 못 박습니다. 네 가지 구조가 하나로 묶여 움직여야 하며, 그 넷은 선언적 배포, 상태 저장·비저장 분리, 서비스 메시, GitOps 입니다.

▲ 성공의 4구조와 선언적 배포 (영상 4:22)

캡처 제목은 ‘성공의 4구조와 트래픽 분기 3계층’입니다. 위쪽 노란 띠는 4구조가 한 묶음일 때만 안정되고 하나라도 빠지면 4중 종속이 부활한다는 요지를 담고 있고, 강조된 상자에는 ‘reconcile 루프가 두 클러스터를 동일 desired state 로 수렴’이라고 적혀 있습니다. 오른쪽 도식은 가상화 Active-Active 의 실패 패턴과 쿠버네티스 Active-Active 의 성공 패턴을 나란히 대조합니다.

네 구조는 각각 앞의 Active-Active 종속 하나씩에 대응합니다. 선언적 배포는 원하는 상태를 적어 두면 양쪽 클러스터가 스스로 그 상태에 맞춰 가므로, 사이트마다 따로 손으로 맞추던 일이 사라집니다. 상태 저장·비저장 분리는 데이터베이스 쿼럼을 요청이 오가는 길 밖으로 빼내어 공유 스토리지가 스플릿 브레인을 부르는 문제를 줄입니다. 서비스 메시는 트래픽 비율을 조정해 IP 에 묶이는 문제를 흡수합니다. GitOps 는 설정이 어긋나면 자동으로 되돌리고 모든 변경을 기록으로 남깁니다.

영상이 강조하는 마지막 문장은 이것입니다. 하나라도 빠지면 앞서 본 종속 하나가 다시 살아납니다. 식탁 다리 네 개와 같아서 하나만 짧아도 식탁 전체가 흔들린다는 비유가 따라붙습니다. 그래서 도입 담당자는 네 구조 중 일부만 골라 쓰는 방식을 경계해야 합니다.

트래픽을 나누는 단계도 겹겹이 쌓여 있습니다. 영상은 DNS 에서 한 번, 로드밸런서에서 한 번, 서비스 메시에서 또 한 번 나눈다고 설명합니다. 계층마다 특성이 달라서, 한 계층만 믿지 않고 세 계층을 함께 설계하라는 취지입니다.

▲ 트래픽 분기 3계층 (영상 5:27)

캡처 왼쪽 아래 표가 세 계층을 비교합니다. 읽히는 내용은 다음과 같습니다.

위로 갈수록 운영은 쉽지만 전환이 느리고 세션 정합이 약합니다. 아래로 갈수록 전환은 빠르고 세션을 잘 지키지만 운영 부담이 큽니다. 한 계층이 모든 것을 잘하지 않기 때문에 계층별로 역할을 나누는 설계가 필요하고, 이 표가 영상의 4구조 중 서비스 메시가 왜 세션 종속을 푸는 열쇠인지를 보여 줍니다. 영상은 이 대목에서 운영 중인 서비스마다 네 구조를 어디까지 갖췄는지 표로 그려 보라고 권하고, 비어 있는 칸이 다음에 검증할 순서라고 말합니다.

재해가 나면 결국 얼마나 빨리 다시 띄우느냐가 중요합니다. 영상은 여기서 VM 과 Pod 의 차이가 크게 벌어진다고 말합니다. VM 은 부팅할 때 일곱 단계를 거치고, 하드웨어 점검부터 운영체제와 미들웨어까지 차례로 올라옵니다. Pod 는 이 가운데 다섯 단계를 건너뜁니다. 호스트의 커널을 함께 쓰기 때문입니다.

▲ VM 은 분 단위, Pod 는 초 단위 (영상 6:09)

캡처 제목은 ‘이미지 불변성과 Pod 부팅 — RTO 하한을 분 단위로’입니다. 위쪽에는 패치 의존성 제거, 신뢰 모델 강화, 감사 가능성 향상 세 카드가 있고, 아래에는 같은 가로 폭에 그린 VM 부팅과 Pod 부팅의 시간 축이 있습니다. VM 쪽에는 BIOS 부팅, 게스트 OS 부팅, 미들웨어 시작, 애플리케이션 ready 가 늘어서 있고 ‘분~10분 단위’라는 상자가 붙어 있습니다. Pod 쪽은 image pull, 컨테이너 start, 애플리케이션 ready 만 있고 ‘초 단위’로 표시됩니다.

그래서 VM 은 몇 분에서 십 분까지 걸리고 Pod 는 한 자릿수 초 안에 올라옵니다. 영상은 VM 부팅을 꺼진 자동차에 시동부터 거는 일에, Pod 부팅을 이미 시동이 걸린 차에 올라타는 일에 빗댑니다. Pod 부팅이 빠르다는 사실은 Active-Active 종속을 푼 뒤에야 의미가 생기는 숫자이기도 합니다. 복구 단위가 이렇게 가벼우면 한쪽 사이트가 멈춰도 남은 사이트가 새 Pod 를 금방 띄워 부하를 받아낼 수 있습니다.

영상이 말하는 더 큰 변화는 속도 자체가 아니라 기준입니다. 목표 복구 시간, 즉 RTO 를 정하는 기준이 달라진다는 것입니다. 예전에는 부팅 시간이 복구 시간의 바닥을 정했습니다. 이제는 언제 전환을 결정하고 트래픽을 어떻게 옮기느냐가 좌우합니다.

▲ RTO 하한이 부팅 시간에서 운영 규칙으로 (영상 6:33)

캡처의 주황색 상자에는 ‘RTO 하한 = 부팅 시간’이라는 옛 공식이 표시됩니다. 영상은 이 공식이 더는 맞지 않는다고 말합니다. 부팅이 초 단위로 줄면 부팅은 병목이 아닙니다. 남는 것은 사람이 판단하고 결정하는 시간과 트래픽을 옮기는 규칙입니다.

영상은 이미지를 고치지 않고 통째로 바꾸는 방식이 주는 효과를 세 가지로 정리합니다. 첫째, 패치 작업 대신 새 이미지로 다시 배포하면 됩니다. 둘째, 무엇으로 되살릴지가 분명해져 믿고 복구할 수 있습니다. 셋째, GitOps 커밋 기록이 그대로 감사 증거가 되어 따로 변경 관리 시스템을 둘 필요가 없습니다. 영상의 결론은 이렇습니다. RTO 를 줄이는 일은 인프라 투자보다 운영 규칙을 다듬는 일입니다.

네 구조 가운데 가장 설계 판단이 많이 필요한 것이 상태 저장·비저장 분리입니다. 쿠버네티스는 두 부류를 서로 다른 오브젝트로 다룹니다. 상태를 갖지 않는 서비스는 디플로이먼트(Deployment)로, 고정된 이름과 저장소가 필요한 서비스는 스테이트풀셋(StatefulSet)으로 배포하는 것이 공식 문서의 구분입니다. 자세한 내용은 스테이트풀셋 문서와 디플로이먼트 문서에서 볼 수 있습니다.

영상의 말대로 데이터베이스 쿼럼을 요청이 오가는 길 밖으로 빼내면 공유 스토리지라는 Active-Active 종속이 풀립니다. 그러려면 서비스마다 상태를 어디에 두는지부터 점검해야 합니다. 상태를 Pod 안에 둔 채 Active-Active 를 시도하면 세션 종속이 그대로 되살아나기 때문입니다. 쿠버네티스 기본기를 먼저 다지려면 쿠버네티스 아키텍처 완벽 정리와 쿠버네티스(Kubernetes)란 무엇인가가 도움이 됩니다.

영상이 권한 대로 서비스마다 네 구조를 어디까지 갖췄는지 표로 그려 보면, 비어 있는 칸이 곧 다음에 검증할 순서가 됩니다. 아래 표는 영상의 네 구조를 점검 질문으로 옮긴 것입니다.

네 구조 가운데 하나라도 비어 있으면 앞서 본 종속 하나가 되살아나므로, 빈 칸이 있는 상태에서 Active-Active 종속이 풀렸다고 판단해서는 안 됩니다. GitOps 의 구현 방식은 Argo CD 문서에서, 서비스 메시의 트래픽 제어는 Istio 트래픽 관리 문서에서 확인할 수 있습니다. 도입 전후 변화는 쿠버네티스 도입 전후 비교, 도입을 망설이게 하는 오해는 쿠버네티스 도입을 막는 오해와 장벽 12가지에 정리돼 있고, 이 영상이 속한 백서의 전문은 클라우드 네이티브 DR 구축 계획 발표 자료에서 볼 수 있습니다.

Active-Active 종속은 라이선스, VM IP, 공유 스토리지, 세션 네 가지가 서로를 강화하는 강결합이고, 쿠버네티스는 네 구조를 한 묶음으로 갖춰 이를 푼다는 것이 영상의 결론입니다.

Active-Active 종속이란 무엇인가요?

라이선스, VM IP, 공유 스토리지, 세션 네 가지가 서로를 강화해 하나만 따로 풀 수 없게 만든 강결합입니다. 영상은 이를 한 줄에 엉킨 네 개의 매듭에 빗대며, 하나를 당기면 다른 매듭이 더 조여 온다고 설명합니다.

가상화 Active-Active 가 Active-Standby 로 돌아간 이유는 비용 때문인가요?

아니요. 비용은 네 가지 종속 중 하나일 뿐이고, 진짜 이유는 종속들이 서로 얽혀 있다는 구조에 있습니다. 영상은 흔히 비용이 비싸서라고 생각하지만 진짜 이유는 따로 있다고 말하며, 라이선스를 바꿔도 IP, 스토리지, 세션 종속이 남는다고 짚습니다.

공유 스토리지는 왜 문제가 되나요?

동기화가 끊기면 한쪽이 읽기 전용으로 내려가고, 양쪽이 서로 주인이라고 나서는 스플릿 브레인이 생길 수 있습니다. 어느 쪽을 택해도 Active-Active 의 이점이 줄어드는 구조라는 점이 문제입니다.

쿠버네티스는 이 종속을 어떻게 푸나요?

선언적 배포, 상태 저장·비저장 분리, 서비스 메시, GitOps 네 구조를 한 묶음으로 갖춰 풉니다. 영상은 기능 하나가 아니라 네 구조가 함께 움직여야 하고, 하나라도 빠지면 예전의 종속 하나가 되살아난다고 말합니다.

Pod 는 VM 보다 얼마나 빨리 복구되나요?

VM 부팅은 몇 분에서 십 분까지 걸리지만 Pod 는 한 자릿수 초 안에 올라옵니다. Pod 는 호스트의 커널을 함께 쓰기 때문에 VM 부팅 일곱 단계 가운데 다섯 단계를 건너뜁니다.

RTO 를 정하는 기준은 무엇이 달라지나요?

부팅 시간이 복구 시간의 바닥을 정하던 방식에서, 전환을 언제 결정하고 트래픽을 어떻게 옮기느냐의 운영 규칙으로 옮겨집니다. 영상은 RTO 를 줄이는 일이 인프라 투자보다 운영 규칙을 다듬는 일이라고 결론짓습니다.

Active-Active 종속을 더 깊이 살펴볼 때 볼 원 영상과 이어서 읽을 글, 공식 문서를 모았습니다.

• 클라우드 네이티브 DR 구축 계획 발표 자료 — 이 영상이 속한 백서 전문
• 쿠버네티스(Kubernetes)란 무엇인가 — 개념과 도입 이유
• 쿠버네티스 아키텍처 완벽 정리 — 컨트롤 플레인부터 워커 노드까지
• 쿠버네티스 도입 전후 비교 — 운영자가 알아야 할 변화
• 쿠버네티스 도입을 막는 오해와 장벽 12가지
• 쿠버네티스 운영 자동화 — 이해해야 신뢰할 수 있는 이유
• 3.4.2 쿠버네티스가 제공하는 선언적 API와 자동화의 힘 — 선언적 API와 자동화
• EP.02 · DR 구축 – 가상화 기술의 한계는 알아야 실패하지 않는다. — 클라우드네이티브TV, 이 글이 정리한 원 영상
• 쿠버네티스 공식 문서: StatefulSet — 상태 저장 서비스 배포
• 쿠버네티스 공식 문서: Deployment — 상태 비저장 서비스와 롤링 업데이트
• Argo CD 공식 문서 — GitOps 기반 자동 동기화
• Istio 공식 문서: Traffic Management — 서비스 메시의 트래픽 분기