오픈스택 기반 클라우드 환경에 최적화된 재해복구(DR) 길라잡이

IT인프라 운영자의 핵심업무는 네트워크, 서버, 스토리지, 애플리케이션 같은 IT자원이 문제없이 연속적인 서비스가 가능하도록 지원하는 것이다. 하지만 완벽한 시스템이라도 장애·재해로 인한 서비스 중단 위험이 늘 존재한다. 

즉, 서비스 중단 가능성을 고려하고 최악의 상황 발생 시 완벽에 가까운 복구를 위한 체계적인 프로세스를 정립해야 한다. 

클라우드의 근간이 되는 인프라형 서비스(IaaS)를 구축할 때 가상화 솔루션, 하이퍼컨버지드(Hyper-converged) 인프라 등이 많이 채택·운영돼 왔다. 하지만 특정 솔루션을 사용할 경우 벤더에 종속(lock-in)되고 비용 부담도 커 프라이빗클라우드의 IaaS를 구축할 때 오픈소스 기반의 오픈스택이 현실적인 선택지로 많이 활용되는 추세다. 

IT산업에서 재해는 전쟁, 전염병, 경제 대공황 등 자연현상 또는 인위적인 사고로 비즈니스 수행에 차질이 발생하는 것은 물론, 하드웨어/소프트웨어(HW/SW) 오류로 생기는 시스템 불능 상태를 모두 포함하는 포괄적 개념이다. 

재해가 발생한다면 IT 관점에서 복구해야 할 범위는 어떻게 될까? 기반 시설과 사람/프로세스, 데이터가 복구 대상이 된다. 기반 시설과 사람 및 프로세스는 구성 정보와 복구 절차에 대한 매뉴얼만 잘 구비돼 있다면, 시간과 비용이 소요되더라도 복구에 어려움은 없다. 

반면 데이터는 유실되면 복구가 어렵기 때문에 간단한 문제가 아니다. 기업의 존폐 자체를 논할 수 있는 중대한 사항이기 때문에 많은 기업들이 데이터를 백업하고 관리하고 있다. 즉, 기술적인 관점에서 재해복구의 핵심은 ‘데이터의 복구’다.

데이터 복구와 실시간 동기화 방식
데이터는 크게 스테이트리스(Stateless)와 스테이트풀(Stateful) 데이터로 나눌 수 있다. 스테이트리스 데이터는 CPU 처리를 위해 휘발성 메모리에서 처리 중인 데이터나 내용이 변경되지 않는 리드 온리(read only) 데이터 형태로, 상대적으로 백업이 필요 없는 경우가 많다.

클라우드로 전환된 많은 워크로드의 경우 이런 애플리케이션에 해당되는 경우가 많다. 클라우드 구성정보와 가상머신(VM), 컨테이너 이미지 등은 리드 온리의 스테이트리스 데이터로 자동화된 방식으로 복구 및 빠른 배포와 재기동이 가능하다. 

최근에는 여기에서 더 나아가 사전에 정의된 조건에 따라 워크로드를 자동으로 확장·축소할 수 있는 오토스케일링 형태의 서비스도 있으며, 하나의 데이터센터가 아닌 멀티클라우드에서 온디멘드로 확장하는 방식으로 발전되고 있다.

스테이트풀 데이터는 수시로 업데이트 되거나 다수의 사용자가 동시에 레코드를 변경하는 경우가 많아, 제2의 지역에 데이터를 동기화 해놓지 않으면 재해 발생 시 데이터 불일치 현상이 발생할 수 있다.

가상머신이 사용하는 사용자 데이터 영역, 데이터베이스 등 스테이트풀 데이터는 오픈스택 환경에서 스토리지 용량을 많이 차지하는 부분이다. 실시간으로 변동되는 내용이 많으며 데이터 양도 수십 테라바이트(TB) 이상인 경우가 많아서 백업보다는 실시간 동기화를 고려해야 한다.

결국 재해복구(DR)를 위해서는 실시간으로 변경되는 데이터를 어떻게 실시간 동기화할 수 있는지가 중요한 과제라고 볼 수 있다. 

데이터 동기화 방식에는, 원본과 복제본에 대한 100% 동기화를 보장하는 싱크(Sync) 동기식 방식과 시간을 두고 스냅샷, 데이터나 로그 릴레이 방식을 이용하는 어싱크(Async) 비동기식 방식, 그리고 원본과 복제본을 구분하지 않고 어떤 볼륨이든 동시에 읽기 쓰기를 지원하는 액티브-액티브 미러링 방식이 있다.

재해복구센터 유형과 모의훈련의 필요성
현재 국내에서 IT재해복구센터는 크게 3개 형태로 구현되고 있다. 가장 많이 도입되고 있는 형태는 2개의 데이터센터를 동기식 혹은 비동기식 복제로 묶어 운영하는 방식으로, 주로 100km 이내 단거리에는 동기식, 100km 이상 장거리는 비동기식 복제 구성을 많이 사용한다. 

2개의 데이터센터에 액티브-액티브(Active-Active) 미러링을 도입하는 방식도 있다. 무중단 서비스가 중요한 병원, 제조 생산라인을 중심으로 최근 많이 적용되고 있다. 서버, 애플리케이션 단의 액티브-액티브 이중화 구성이 현실적으로 근거리에서만 구성가능함을 고려해 주로 10Km이내의 근거리에 2개 데이터센터를 구축해 운영한다. 

공공, 금융 핵심 업무에 많이 도입되고 있는 데이터센터 3중화 방식도 있다. 원본인 주 데이터센터와 더불어 2개 복사본을 둔다. 인하우스에 2개 스토리지를 구성해 스토리지의 물리적 장애에 대비하고, 원격 스토리지는 주센터의 장애에 대응하는 방식이다. 

오픈스택 환경은 지금까지 정보계성 업무, 개발 테스트, 개념검증(PoC) 용으로 주로 활용돼왔고 중요 업무에 적용된 사례가 아직 많지는 않다. 하지만 최근 공공기관이 주요 시스템 구축 시 오픈스택 기반 클라우드를 요구하는 사례가 증가하는 등 오픈스택 기반 환경이라도 기존 레거시 업무처럼 재해복구 구축이 필요한 시점이 왔다. 

공공기관용 클라우드 컴퓨팅 서비스 추가 보호조치에 따르면 클라우드 환경에서도 중요 장비 이중화와 백업 체계 구축이 필수로 요구된다. 

재해복구에 엄격한 금융권도 클라우드컴퓨팅 서비스 사용 시 기존과 동일하게 핵심업무 복구목표시간(RTO)을 3시간 이내로 요구한다. 매년 1회 이상 재해복구센터로 실제 전환하는 훈련을 실시하다는 지침을 클라우드컴퓨팅에 대해서도 동일하게 적용하고 있다. 

재해복구는 일반적으로 일어나는 상황은 아니다. 그럼에도 재해는 예기치 못한 상황에서 언제든 일어날 수 있어 재해복구가 가능한지, 복구 절차에 따라 제대로 수행되는지를 검증하는 모의훈련을 정기적으로 시행하는 것이 좋다. 

오픈스택 환경에서도 마찬가지다. 다만, 데이터 재해복구용 동기화 이미지를 가지고 모의훈련을 하다가 실제 재해 상황이 발생하면 해당 이미지로 복구를 하지 못할 수 있어, 반드시 모의훈련용 별도 복사본을 구성해 진행하는 것이 중요하다. 

모의훈련용 복사본은 스토리지 내부 복제 혹은 스냅샷 기능을 이용해 이미지를 간편하게 생성할 수 있다. 이 이미지를 이용해 복구 절차를 수행해 재해복구 시스템의 적합성을 검증할 수 있다. 

민첩한 IT환경에 최적화한 실시간 재해복구 프로세스 구현해야

오픈스택 기반의 클라우드 구축은 민첩한 IT환경 구현으로 비즈니스 요구사항을 실시간으로 반영할 수 있는 디지털전환(DT)을 실행한다는 의미이기도 하다.

클라우드 환경도 재해복구가 고려돼야 하는 시대다. 재해복구는 예전보다 더 민첩한 형태로 이루어져야 한다.

재해복구가 민첩해 지려면 더 많은 데이터가 실시간으로 백업되고 복구가 가능해야 한다. 여기서 중요한 점은 스테이트풀 데이터는 반드시 실시간 동기화가 돼야 한다는 점이다. 

추가적으로 클라우드를 구성하고 있는 각종 구성 정보가 실시간으로 동기화 혹은 백업돼야 하고, 복구 절차가 데이터화 되고 스크립트화 되어야 한다. 이로써 재해가 발생하면 사람의 개입이 최소화되고 실수가 줄어들면서 더 빠르게 재기동할수 있는 자동화 환경이 가능해진다. 

클라우드 시대가 가속화되면서 점차 개발자와 운영자의 경계가 모호해지고 있다. 모든 작업이 자동화에 초점이 맞춰지며, 이를 위한 개발자와 운영자의 소통 방식도 달라져야 한다.

각자가 새로운 영역을 이해하기 위해 노력하고 협업해야만 새로운 클라우드 환경에서 최적의 아키텍처를 구상할 수 있으며, 더 나아가 재해복구 자동화를 통한 더 민첩하고 안전한 오픈스택 기반 클라우드 환경을 누릴 수 있다.

글: 권 필 주 / SA팀 전문위원 / 효성인포메이션시스템