김수훈 코헤시티 한국 상무가 9월10일 <디지털데일리>가 서울 더 플라자에서 주최한 ‘금융 CIO 어젠다 나우: 백업 데이터 AI 활용과 데이터 보안 재정의’ 세미나에서 ‘클라우드 네이티브 PaaS 데이터 보호전략:백업을 넘어 사이버 레질리언스까지’를 주제로 발표 중이다.[사진=디지털데일리]

[디지털데일리 오병훈기자] 데이터 백업 성패는 ‘얼마나 빨리 업무를 다시 시작할 수 있느냐’로 결정된다. 수십·수백테라바이트(TB) 데이터를 모두 원래 위치로 되돌릴 때까지 기다리기 보다 서비스 재가동에 집중하고 데이터는 후순위로 복구하는 방식이 대표적이다.

코헤시티는 이 같은 ‘복구 우선’ 전략 기반으로 스케일아웃 아키텍처와 병렬 분산 데이터 처리 구조를 내세웠다. 실제 금융권 검증 사례에서는 193테라바이트(TB) 규모 오라클 데이터베이스(DB) 환경을 20분 만에 업무 가동 상태로 만들고 가상머신(VM) 50대는 약 1분 만에 서비스를 시작한 성과를 내세웠다.

김수훈 코헤시티 한국 상무는 10일 <디지털데일리>가 서울 더 플라자에서 주최한 ‘금융 CIO 어젠다 나우: 백업 데이터 AI 활용과 데이터 보안 재정의’ 세미나에서 “앞으로 데이터 보호 경쟁력은 외부·내부 공격이나 사고가 발생했을 때 얼마나 빠르게 복구할 수 있는가에 의해 결정될 것”이라며 “안전한 백업과 빠른 복구는 이제 선택이 아니라 필수”라고 말했다.

◆“백업됐다”로 끝 아냐…핵심은 ‘언제 업무 환경 돌아오나’

김 상무가 가장 먼저 짚은 것은 고가용성(HA)과 백업의 차이다. 금융권에서는 레드햇의 기업용 쿠버네티스 플랫폼인 ‘오픈시프트(OpenShift)’를 중심으로 쿠버네티스 기반 프라이빗 서비스형 플랫폼(PaaS) 도입이 확대되고 있다. 쿠버네티스는 파드(Pod)나 노드(Node)에 장애가 생기면 이를 자동으로 다시 기동해 서비스 가용성을 유지하는 데 강점이 있다.

하지만 플랫폼이 정상적으로 동작한다고 데이터까지 되돌아오는 것은 아니다. 사용자 실수로 데이터를 삭제했을 수 있다. 애플리케이션(앱) 오류, 랜섬웨어, 스토리지 손상이 발생하면 서비스 플랫폼은 살아 있어도 데이터는 사라진 상태일 수 있다.

김 상무는 “PaaS의 HA는 서비스를 살리는 것이고 백업은 데이터를 살리는 것”이라며 “서비스가 살아 있어도 데이터가 없으면 비즈니스는 멈춘다”고 강조했다.

문제는 백업본이 존재한다고 곧바로 업무 재개가 가능한 것도 아니라는 점이다. 데이터 규모가 커질수록 전체 데이터를 원래 저장소로 다시 이동하는 데 상당한 시간이 필요하다. 따라서 실제 복구 전략에서는 단순한 백업 성공률보다 ‘복구시간목표(RTO)’를 얼마나 줄일 수 있는지가 중요해진다.

특히 최근 랜섬웨어 공격에서는 복구 수단 자체를 없애려는 시도도 늘고 있다. 공격자가 내부에 침투한 뒤 관리자 권한을 확보하고 백업 서버·계정·스토리지를 먼저 공격한 다음 운영 데이터를 암호화하는 방식이다.

백업본에는 일정 기간 수정·삭제를 막는 불변(Immutable) 기능과 운영망에서 논리적으로 분리하는 에어갭(Air Gap), 중요 작업에 복수 승인을 요구하는 ‘MPA’ 등을 함께 적용해야 한다는 것이 김 상무 설명이다.

◆193TB를 다 옮길 때까지 기다리지 않는다…20분 만에 오라클 ‘업무 기동’

빠른 복구 전략이 가장 선명하게 드러난 사례는 대용량 오라클 DB다. 코헤시티가 소개한 금융권 사례는 오라클 엑사데이터 환경으로 전체 데이터 규모가 193TB에 달했다. 기존 환경에서는 DB를 다시 가동하기까지 24시간 이상 걸렸다. 코헤시티 적용 후에는 업무 가동 시간을 20분까지 줄였다는 설명이다.

여기서 중요한 것은 ‘193TB 전체 데이터 복사를 20분 만에 완료했다’는 의미가 아니라 업무를 수행할 수 있는 DB 상태를 20분 만에 기동했다는 점이다.

운영 절차도 단순화했다. 관리자가 백업 시점을 선택하고 필요한 정보를 입력한 뒤 복구 버튼을 누르면 DB를 기동하는 방식이다.

가상화 환경에서는 이 같은 방식이 더욱 직접적으로 나타났다. 한 고객 환경에서 코헤시티는 ‘IMR’ 기능을 이용해 VM 50대를 동시에 복구하는 테스트를 진행했다. 그 결과 VM 50대의 서비스 기동까지 약 1분, 이후 전체 데이터 마이그레이션 완료까지 2시간43분27초가 걸렸다.

핵심은 사용자가 2시간43분 동안 기다릴 필요가 없었다는 점이다. 우선 VM을 기동해 업무를 시작하고, 나머지 데이터는 백그라운드에서 자동으로 이동시키는 방식이다.

김 상무는 “업무는 먼저 재개시키고 데이터는 백그라운드에서 자동으로 동기화한다는 것이 차별점”이라며 “장애 상황에서는 시간이 곧 비용인 만큼 전체 데이터 이동이 끝날 때까지 기다리지 않고 서비스를 먼저 시작할 수 있다는 것이 중요하다”고 말했다.

대규모 DB와 다수 VM을 동시에 빠르게 기동할 수 있는 배경은 아키텍처다.

기존 레거시 백업 시스템 상당수는 스케일업 구조로 구성돼 있다. 데이터가 늘어날수록 특정 컨트롤러에 부하가 집중될 수 있다. 결국 대규모 복구가 필요한 시점에 해당 지점이 병목으로 작용할 수 있다.

이 문제를 해결하기 위해 코헤시티는 여러 노드를 추가해 처리량을 확장하는 스케일아웃 구조를 채택했다. 데이터 양이 증가하면 노드를 늘리고 여러 노드가 데이터를 병렬로 처리하는 방식으로 백업·복구 성능을 함께 확장한다.

김 상무는 “대용량 오라클 환경의 빠른 업무 가동과 VM 50대 동시 복구가 가능했던 이유도 이런 아키텍처에 있다”며 “데이터가 증가하면 노드를 추가하고 처리 성능도 함께 증가하는 구조이며, 병렬 분산 파일 처리 시스템을 통해 여러 노드가 동시에 데이터를 처리한다”고 설명했다.

빠른 복구는 운영 단순화도 뒷받침돼야 한다. 장애가 발생한 뒤 관리자가 여러 백업 제품과 콘솔을 오가며 복구 정책과 절차를 확인해야 한다면 기술적으로 복구 성능이 빨라도 실제 RTO는 길어질 수 있기 때문이다.

이에 코헤시티는 단일 관리 UI를 통해 백업 상태와 스토리지 사용량, 중복제거율 등을 확인하고 같은 환경에서 복구 작업까지 수행하도록 구성했다.

김 상무는 “아무리 좋은 기술이라도 운영이 복잡하면 지속적으로 사용하기 어렵다”며 “PaaS 전환 성공은 플랫폼 자체에 그치는 것이 아니라 실제 문제가 생겼을 때 안전한 데이터를 얼마나 빠르고 단순하게 복구해 업무를 재개할 수 있느냐에 달려 있다”고 강조했다.