전기전자/정보통신

Nikkei Computer_2021.4.15 특집 (p24~35)

백업에 대한 새로운 상식
10년에 크게 변한 인프라 기술

최근 백업의 중요성이 전에 없이 높아지고 있다. 기업이 보호해야 할 데이터의 용량이 계속 늘어나고 있는 한편, 데이터를 암호화해 몸값을 요구하는 ‘랜섬웨어’ 등 사이버 공격이 확산되고 있기 때문이다. 다행히 백업 작업은 과거에 비해 훨씬 용이해졌다. 가상화 기술과 클라우드, 컨테이너 기술 등의 보급으로 데이터를 빠르고 확실하게 보호할 수 있게 되었다. 10년 전과는 전혀 달라진 백업의 새로운 상식을 이해하고 늦기 전에 데이터 보호를 강화하도록 하자.

Part 1. 랜섬웨어에 대항
다시 주목 받고 있는 '3-2-1 백업 룰'

최근 보안 대책의 마지막 보루인 백업의 중요성이 다시 부각되고 있다. 랜섬웨어에 대항하기 위해 ‘3-2-1 백업 룰’을 지켜 데이터를 보호. 3가지 IT 인프라 기술의 진화가 백업에 도움이 되고 있다.

미국의 대형 IT벤더나 일본 자동차 제조사, 시립 병원 등---. 전 세계적으로 수많은 기업과 단체들이 클라이언트 PC나 서버에 있는 데이터를 암호화해 몸값을 요구하는 랜섬웨어 피해를 겪고 있다.

-- 백업 데이터를 노리는 랜섬웨어 --
업무 데이터를 제대로 백업한다면 범죄자에게 몸값을 지불하지 않아도 백업 데이터를 사용해 원래대로 복원할 수 있다. 하지만 최근 랜섬웨어 중에는 백업 소프트웨어의 유력 벤더가 채택하고 있는 파일 형식을 파악해 백업 데이터를 기업 내 네트워크에서 찾아내어 그것을 파괴하려고 시도하는 것도 있다.

백업 소프트웨어 기업인 미국 베리타스테크놀로지스(Veritas Technologies) 일본법인의 다카이(高井) 상무는 “랜섬웨어가 백업 소프트웨어를 노리고 있는 것은 사실이다”라고 인정했다. 다시 말해 단순히 백업 소프트웨어를 사용해 업무 서버와 동일한 네트워크 내 파일 서버에 업무 데이터를 백업하는 것만으로는 랜섬웨어 대책으로 불충분해진 것이다.

이러한 상황 속에 다시 한번 주목 받고 있는 것이 ‘3-2-1 백업 룰’이다. 중요한 데이터를 보호할 경우, ‘파일 복사는 3개(프라이머리 1개와 백업 2개)를 보관하고, 파일을 보관하는 기록 매체는 서로 다른 2종류를 채택해 복사. 그 중 1개는 오프사이트(Off-site)에 보관해야 한다’라는 규칙이다.

이 3-2-1 백업 룰은 2012년, 미국 국토안보부의 사이버보안 및 인프라 보안청(CISA)의 보안조직인 US-CERT가 백업할 때 지켜야 할 규정으로서 제시한 것으로, 이후 수년 간은 너무 시간이 소요되어 현실적이지 않다는 견해가 지배적이었다고 한다.

하지만 랜섬웨어의 만연으로 인해 “3-2-1 백업 룰이 재평가되고 있다”(NEC의 다니구치 매니저). 랜섬웨어 대책을 위해 사내 네트워크에 침입한 랜섬웨어가 침투할 수 없는 ‘다른 미디어’나 ‘오프사이트’에 백업을 보관할 필요성이 생겼기 때문이다. 이러한 사정으로 인해 “최근에는 백업 소프트웨어 벤더들도 3-2-1 백업 룰을 이용자에게 다시금 추천하기 시작하고 있다”(다니구치 매니저)라고 한다.

이처럼 3-2-1 백업 룰이 재평가된 배경에는 US-CERT가 3-2-1 룰을 제창하기 시작한 2012년에 비해 오프사이트 백업이 쉬워졌다는 점도 있다. 크게 달라진 점은 클라우드의 보급. ‘Amazon S3’와 같은 클라우드 스토리지를 활용할 경우, 중소기업도 손쉽게 오프사이트에 보관할 수 있게 되었다.

오프사이트란 업무서버를 가동하는 사무실이나 데이터센터와는 다른 곳을 의미한다. 클라우드 이전 시대에는 이용자 기업이 백업을 오프사이트에 보관하기 어려웠다. 중요한 업무 데이터를 보관할 수 있는 안전한 장소를 사무실이나 데이터센터와는 별도로 확보해 데이터를 거기까지 안전하게 전송할 필요가 있었기 때문이다. 전국에 거점을 둔 대기업이 아니면 백업 데이터의 오프사이트 보관이 어려웠다. 하지만 지금 그 장벽은 크게 낮아졌다.

-- 백업의 상식, 10년 만에 크게 달라져 --
업무 시스템의 백업 절차는 한번 결정하면 나중에 수정하는 경우는 드물다. 이 때문에 많은 기업들은 지금도 시스템을 설계한 10년 전의 발상에 근거한 백업을 시행하고 있다.

하지만 과거 10년 간 IT 인프라를 둘러싼 상황은 크게 달라졌다. 2010년 전후에는 서버 가상화 기술을 이용하는 것이 보편화되었고, 2010년대 중반부터는 클라우드로의 전환이 가속화되었다. 2010년대 후반에는 컨테이너를 비롯한 클라우드 네이티브 아키텍처가 등장. 이러한 IT 인프라의 진화에 발맞춰 백업 기술도 크게 변화했다.

예를 들면 서버 가상화 소프트웨어가 백업에 관련된 ‘중복 배제 기술’을 탑재함으로써 백업에 필요한 스토리지 용량이나 네트워크 대역이 대폭 축소되었다. 대기업의 공공 클라우드에서는 사용자가 이전처럼 백업 시스템을 구축하지 않아도 확실하게 업무 데이터를 백업할 수 있게 되었다.

백업의 중요성은 전에 없이 높아진 반면, 백업 자체는 훨씬 용이해졌다. 지금이 백업 체제를 재정비해 만약을 대비할 수 있는 최적의 시기이다.

Part 2. 가상화 소프트웨어가 주역
최신 백업 기술

‘하루에도 몇 번씩 백업하고 손쉽게 복원할 수 있다’. ‘중복 배제’나 ‘영구 증분’에 의해 백업은 현격히 손쉬워졌다. 최근 10년 간 기술을 일변시킨 것은 가상화 소프트웨어이다.

백업 소프트웨어 대기업인 미국 베리타스테크놀로지스 일본법인의 다카이 상무는 “가상화 기술의 보급으로 백업 구조는 크게 바뀌었다”라고 지적한다. 미국 VM웨어의 ‘vSphere’와 같은 가상화 플랫폼이 고도의 백업 기능을 갖추면서 IT 인프라스트럭처와 백업 소프트웨어의 관계가 바뀌었다. 이로 인해 백업의 대상이나 단위, 방법 등도 일변했다.

가상화 이전의 세계에서 백업의 주역은 ‘NetBackup’이나 ‘Arcserve’와 같은 백업 소프트웨어가 제공하는 에이전트였다. 백업 대상 서버에 에이전트를 설치하면 서버 상의 데이터 갱신 등을 에이전트가 감시하며 백업 관리 서버에 데이터를 복사했었다.

한편, vSphere 등 가상화 플랫폼은 가상 머신의 데이터를 보호하는 고도의 백업 기능을 탑재. 이러한 기능을 API(Application Programming Interface)로 외부에서도 이용이 가능하게 만들었다. vSphere의 경우에는 ‘vSphere Storage APIs’. 가상화 플랫폼의 백업 기능이 매우 강력해졌으며 백업 소프트웨어는 가상화 플랫폼의 API를 이용하게 되면서 백업의 주역이 교체되었다.

백업의 주역이 가상화 플랫폼으로 교체되면서 2가지 포인트가 크게 달라졌다. 먼저 백업 대상이 물리적 머신에서 가상 머신 VHD(가상 하드 디스크) 파일로 바뀌었다. 또한 백업 단위가 파일에서 블록 스토리지 볼륨으로 변화했다.

-- '영구 증분'이 일반화 --
가상화 이전의 백업에서는 백업의 단위가 파일이며, 동일한 파일이 여러 번 갱신될 경우 백업 때마다 파일 전체를 복사했다. 이에 비해 가상화 이후의 백업의 단위는 파일보다 입자 크기가 작은 블록이다. 동일 파일이 여러 번 갱신되는 경우에도 파일 전체가 아니라 갱신되는 블록만을 복사해 백업 세대 간의 중복 배제가 가능하다.

이 중복 배제 기능으로 인해 백업 세대 관리도 크게 달라졌다. 가상화 이전의 백업에 서는 세대 관리가 '풀(완전)' '차분(差分)' '증분'으로 실시하는 것이 일반적이었다. 그에 비해 가상화 이후의 백업에서는 ‘영구 증분’이 일반화되었다.

영구 증분 시스템에 대해 알아보자. 가상화된 환경에서는 백업 대상인 VHD 파일을 한 번 복사한 후에는 파일 내 변경된 블록만 복사한다. 즉, 증분 백업을 실시하는 것이다. 그리고 복원할 때는 최초로 백업한 VHD 파일에 변경된 블록을 통합한다. 블록의 통합 작업은 파일 덮어쓰기에 비해 단시간에 완료된다. 다시 풀 백업을 할 필요가 없기 때문에 ‘영구 증분’이라고 한다.

파일 단위로 백업하던 기존에는 증분 백업을 늘리면 복원 시간이 길어지기 때문에 주 1회 풀 백업을 다시 하는 등의 번거로운 운용이 필요했다. 하지만 영구 증분을 통해 증분 백업을 여러 번 실시해도 운용 부담이 증가하지 않아 하루에 몇 번씩 백업하고 신속하게 데이터를 복원할 수 있게 되었다.

가상화 플랫폼에서의 중복 배제에는 또 하나의 측면이 있다. 1대의 물리 서버로 여러 대의 가상 머신을 운용하는 경우, 가상 머신 간에 공통되는 파일이나 블록은 1회만 백업하면 되는 것이다. 세대 간이 아닌 가상 머신 간에서의 중복 배제를 ‘글로벌 중복 배제’라고 부른다.

이러한 강력한 백업 기능은 vSphere뿐만 아니라 ‘Nutanix’와 ‘OpenStack’ 등 새롭게 등장한 가상화 플랫폼이 모두 갖추고 있다. 백업 소프트웨어는 가상화 플랫폼의 API를 호출해 데이터를 취득하고, 추출한 데이터를 보관하거나 저장할 때 사용하기 편한 사용자 인터페이스(UI)를 제공하는 것이 주요 역할이다.

-- 컨테이너 기술로 백업 간소화 --
-- 백업하는 곳에 클라우드를 활용 --
-- 백업 데이터를 2중으로 --

Part 3. 누구나 동서(東西) DR
클라우드의 능력을 활용

클라우드로 전면 전환하면 백업도 단번에 현대화된다. 최신 백업 기술이 서비스로서 갖춰져 있기 때문이다. 도쿄와 오사카를 이용한 재해 복구 대책도 용이하다.

시스템을 클라우드로 전환하면 얼마나 백업이 심플해지는지 실제 사례를 살펴보자. 회계 업무의 비즈니스 프로세스 아웃소싱(BPO)를 추진하는 비즈니스브레인 오타쇼와(太田昭和)는 자사에서 판매하는 패키지를 이용한 기간계 시스템을 ‘Oracle Cloud Infrastructure(OCI)’에 구축했다. 패키지 벤더가 스스로 보여준 클라우드 백업의 좋은 예라고 할 수 있다.

비즈니스브레인 오타쇼와는 올 1월부터 Java에서 개발한 업무 패키지 ‘ACT-MBB’를 사용하는 기간계 시스템을 OCI에서 가동했다. Apache Tomcat이 가동하는 애플리케이션(AP) 서버와 Oracle Database Enterprise Edition(EE)이 가동하는 데이터베이스(DB) 서버로 구성된 단순한 구성 시스템이다.

가동계의 AP서버와 DB서버는 OCI의 도쿄 리전에서 운용, 대기계(待機系)의 DB서버는 OCI의 오사카 리전에서 운용한다. 가동계 DB서버의 데이터는 Oracle DB EE에 탑재된 데이터 보호 기능 "Oracle Data Guard"를 이용해 대기계 DB 서버에 동기화 한다. 최초로 모든 데이터를 복사한 후에는 갱신 정보만 대기계에 전송하는 구조이다. 구체적으로는 Oracle DB 로그 라이터가 데이터 갱신 시 REDO 로그를 가동계와 대기계의 REDO 로그파일에 동시에 입력한다.

오사카에 있는 대기계 DB서버는 OCI가 제공하는 오브젝트 스토리지에 1일 1회 정기적으로 백업한다. 비즈니스브레인 오타쇼와가 OCI에서 이용하는 DB는 클라우드 서비스로서 제공되고 있는 ‘Oracle Enterprise Database Service’. 이용 기업은 자체적으로 Oracle DB를 가상 머신에 설치하거나 운영할 필요가 없다. 백업도 Oracle DB 관리 콘솔에서 설정하기만 하면 작업이 완료된다.

AP서버가 가동하는 가상 머신의 디스크 이미지는 OCI가 보유한 표준 백업 기능을 사용해 오사카 리전의 오브젝트 스토리지에 백업한다. 백업과 복원 모두 OCI의 관리 콘솔에서 설정을 선택하면 된다.

-- 시스템은 오사카에서 복원 --

-- 백업 통합을 추진 --
대기업의 공공 클라우드에서는 현재 백업 기능 통합이 추진되고 있다. 예를 들어 AWS는 통합 백업 서비스인 AWS Backup을 2019년 1월부터 제공. AWS 재팬 기술총괄본부의 다키자와(瀧沢) 본부장은 “기존에는 각 서비스가 각각 다른 자동 백업 기능을 갖추고 있었지만, AWS Backup으로 백업 정책을 일원적으로 관리할 수 있게 되었다”라고 설명한다.

구체적으로 AWS Backup은 'Backup Vault'라 부르는 백업 관련 정책 관리 기능을 갖추고 있다. 이것을 이용하면 백업 대상 설정이나 백업 데이터로의 사용자 액세스 설정 등을 일괄 관리할 수 있다. 일본 마이크로소프트도 동일한 통합기능 Azure Backup을 제공하고 있다.

클라우드 상에서의 SI(System Integration)에 강한 서버워크스의 사이틀리어빌리티엔지니어링부에 소속된 이토(伊藤) 씨는 “공공 클라우드에서 장애가 발생했을 때는 급하게 복원하지 말고 우선은 사업자가 제공하는 정보에 주목해야 한다”라고 지적한다. 지역이나 AZ(Availability Zone) 전체가 불안정해져 신규 가상 머신을 바로 만들지 못하는 경우가 있기 때문이다.

또한 “특히 AWS의 경우, 일시적인 장애가 풀리면 시스템이 장애 발생 직전 상태로 자동 복구되는 경우도 많다. 정말로 백업 데이터를 통한 복원이 필요하게 되는 경우에는 AWS가 그 취지를 고지한다”(이토 씨)라고 한다. 클라우드의 특성에 맞춘 복원 전략이 필요하다는 것이다.

클라우드의 이점을 최대한 이용하고 싶다면 SaaS(서비스형 소프트웨어)나 PaaS(서비스형 플랫폼)를 적극적으로 활용하는 것이 좋다.

IaaS(Infrastructure as a Service)에는 가상 머신의 가상 디스크 파일을 백업하는 기능 등이 탑재되어 있지만, 백업 계획은 사용 기업이 세울 필요가 있고 복원도 사용 기업이 작업해야 한다. 이에 반해 SaaS나 PaaS의 경우 백업이나 복원은 클라우드 사업자의 책임이다.

--DB 서비스는 백업이 자동 --

 -- 끝 --

Copyright © 2020 [Nikkei Computer] / Nikkei Business Publications, Inc. All rights reserved.