[아이티데일리] x86 시스템을 기반으로 가상화 및 클라우드를 도입하는 기업들이 늘어나고 있다.

U2L(Unix to Linux)로 다운사이징 프로젝트를 진행하면서 많은 기업들이 처음에는 리눅스(Linux) 운영체제에 기본적으로 탑재돼 있는 오픈소스 기반의 백업 솔루션을 운영 환경에 적용하려 한다. 그러나 대 단위의 엔터프라이즈 환경에서는 결국 상용 솔루션인 이미지 백업 솔루션을 재도입하고 있는 실정이다. 이 경우 많은 시간과 비용 손실을 가져오게 된다.

또한 기존 유닉스(UNIX)를 중심으로 한 오픈시스템 환경에서 주로 구축했던 통합 백업 시스템의 연장선상에서 레거시 백업 솔루션의 다양한 멀티 백업 에이전트를 이용한 방법도 실패해 재구축을 하는 경우가 많다.

실제 기존의 레거시 방법으로 백업을 했다가 실패한 사례를 주변에서 쉽게 볼 수 있다. OS 복구를 하려 했으나 이기종 복원이 안되는 경우는 물론 가상화 환경으로 복원도 실패하는 등 연속된 오류로 인해 뒤늦게 이미지 백업 솔루션을 도입하는 경우를 심심찮게 볼 수 있다. 이러한 일이 일어날 경우 일정관리를 준수해야 하는 프로젝트에 큰 타격을 주게 된다.

메인프레임 중심의 전산 환경에서 오픈 시스템으로 전환되었을 때 백업 시스템도 그에 발맞추어서 다운사이징 되었듯이, 현재 x86 시스템(Windows, Linux)으로 다운사이징 되면서 x86의 물리서버와 가상화 및 클라우드 환경에 적합한 데이터 보호 시스템이 필요하다.

이번 기고에서는 자동차의 연비를 정의하는 것과 같이 현실에서 데이터 보호 시스템 도입 시 고려해야 할 ‘데이터 보호 시스템의 연비 등급’을 정의해 시스템 도입을 고려하는 많은 기업 및 조직에게 도움을 주고자 한다.

자동차의 연비는 아래와 같이 등급을 표시하고 있는데, 레거시 내연기관 자동차와 전기자동차로 구분된다.

① 도심 연비(도심주행 에너지소비효율)

- 도심주행 모드(FTP-75)로 측정한 에너지소비효율을 5-cycle 보정식에 적용하여 산출된 도심 연비이다.

② 고속도로 연비(고속도로주행 에너지소비효율)

- 고속도로주행 모드(HWFET 모드)로 측정한 에너지소비효율을 5-cycle 보정식에 적용하여 산출된 고속도로 연비이다.

③ 복합연비

- 도심연비와 고속도로주행 연비에 각각 55%, 45%의 가중치를 적용하여 산출된 연비로, 복합연비를 기준으로 자동차의 연비등급을 부여한다. 배기량에 상관없이 복합연비가 높은 차량에 높은 등급(1등급)을 부여하고 복합연비가 낮은 차량에는 낮은 등급(5등급)을 부여한다.

에너지소비효율(연비:km/l)은 1리터의 연료로 얼마의 거리(km)를 주행할 수 있는지를 표시하는 것으로, 숫자가 높을수록 연비가 우수한 자동차이다.

④ 복합 CO2배출량(g/km)

- 자동차가 1km를 주행할 때 배출하는 이산화탄소의 양을 그램(g)으로 표시한 것으로, 숫자가 낮을수록 환경 친화적인 자동차이다.

⑤ 1회 충전 주행거리(km)

- 전기자동차가 1회 충전했을 때 주행할 수 있는 거리를 의미한다.

- 전기자동자의 에너지소비효율(km/kWh)=1회 충전 주행거리(km)/차량 주행 시 소용된 전기에너지 충전량(kWh)를 의미하게 된다.

여기에서 한 가지 알 수 있는 것은 레거시 자동차에서는 내연기관인 자동차 엔진이 심장부였다면 전기자동차에서는 배터리가 심장부라는 점이다. 엔진의 역할이 배터리로 대체되고 있다는 것. 이는 엔진을 잘 만드는 기술을 가진 업체가 지금까지 자동차 산업을 선도했다면 앞으로는 배터리를 더욱 작게 만들고 배터리 용량과 충전효율을 높이는 기술을 가진 업체가 자동차 산업을 선도할 것이라는 사실을 보여주고 있다.

자동차에 연비 등급을 적용한 것처럼 데이터 보호 시스템도 등급을 나눌 수 있다. 데이터 보호 시스템(소프트웨어 또는 백업 어플라이언스)은 아래 7가지 기준을 적용해 등급을 결정할 수 있다.

1. 백업 시스템 에이전트

백업 시스템 에이전트는 단일 에이전트(Single Agent) 방식과 멀티 에이전트(Multi Agent) 방식으로 구분할 수 있다.

단일 에이전트(Single Agent)

- 서비스를 제공하는 시스템은 크게 OS(운영체제), 파일데이터, 데이터베이스(메일 등 트랜잭션 데이터 포함)로 구분되는데 시스템에서 이들 모두는 단일 에이전트로 백업하는 에이전트이다.

- 운영 시스템에 영향도를 최소화하며, 프로젝트 일정을 앞당길 수 있다.

멀티 에이전트(Multi Agent)

- 대표적으로 레거시 백업 소프트웨어들이 이와 같은 구조로 되어 있다. OS 백업 에이전트, 파일 백업 에이전트, 데이터베이스 백업 에이전트 등으로 구분되며 별도의 구매 및 설치 운영을 필요로 한다.

- 다수의 멀티 에이전트가 운영시스템에 설치 및 시스템 자원에 로드되어 자원 활용도를 낮추며 장애 요인을 가져오는데 장애 요인을 확인하는데 오랜 시간이 소요된다.

멀티 에이전트 방식은 한 개의 시스템에서 여러 개의 백업 스케쥴을 관리해야 한다. 즉 파일 데이터 백업 스케쥴, 데이터베이스 백업 스케쥴, OS 백업 스케쥴 등 다수의 백업 스케쥴을 별도로 관리해야 하며 백업 대상 서버 수가 증가할수록 백업 스케쥴 관리가 복잡해진다.

백업 대상 시스템 개수가 N개인 경우,

- 에이전트 백업 스케쥴 개수 = N개 X 1개 스케쥴

- 에이전트 백업 스케쥴 개수 = N개 X 3개 스케쥴

즉 레거시 백업 솔루션을 포함해 멀티 에이전트 방식은 단일 에이전트 방식보다 약 3배 이상의 백업 스케쥴 관리가 필요하다.

백업 시스템 에이전트는 에이전트 설치 방식에 따라 구분할 수 있다.

에이전트 방식(Agent Based)

- 물리서버/가상 게스트 VM에 에이전트를 직접 설치한다.

- 설치 후 서버 재시작 여부 확인 필요하다.

에이전트리스 방식(Agentless)

- 가상화 환경(MS Hyper-V, Nutanix, VMware 등)인 경우 운영 가상 게스트 VM에 에이전트를 설치하지 않는다.

- 전체 VM을 백업한 후에 개별적인 단위(OS, File, Folder, Database 등)의 복구가 가능해야 한다.

니어 에이전트리스 방식(Near-Agentless)

- 물리서버 환경에서도 가상화 환경의 에이전트리스 방식과 같이 운영 서버에 사전에 에이전트를 설치하지 않고, 백업 시작 시 에이전트가 자동 배포되는 방식으로 평상시 에이전트가 시스템 자원을 점유하지 않는다.

2. 백업 시스템 관리 콘솔

백업 대상 시스템은 온프레미스, 클라우드 환경으로 구분되며, 온프레미스는 물리환경과 가상화 환경으로 나뉠 수 있다. 또한 클라우드는 프라이빗 클라우드, 퍼블릭 클라우드와 하이브리드 환경으로 나뉜다.

이처럼 기업의 시스템 환경은 다양하며, 관리 측면에서 다양한 시스템 환경을 단일 콘솔에서 등록, 스케쥴, 모니터링해야 한다.

Single Management (Single Console)

- 물리, 가상화 환경, 클라우드 환경의 통합 관리

- 단일 정책 관리

Multi-Management (Multi-Console)

인수 & 합병을 통한 제품 간 통합이 어려움

- 물리 환경 별도 관리

- 가상화 환경 별도 관리

- 클라우드 환경 별도 관리

3. 중복제거 백업

1946년 최초로 진공관으로 만들어진 컴퓨터가 “애니악”이다. 그리고 바로 직전해인 1945년 그레이스 호퍼(Grace Murray Hopper)는 마크II 라는 컴퓨터 시스템의 계산 오류를 찾기 위해 컴퓨터 내부를 확인하던 중 부속 사이에 나방이 한 마리 끼워져 있었고, 나방을 조심스럽게 꺼내서 공책의 한 페이지에 스카치 테이프를 이용해서 붙여 놓은 다음 그 밑에 이렇게 적어 놓았다고 한다.

“First actual case of bug being found.” (버그가 발견된 첫번째 사례)

그 이후로도 따스한 컴퓨터 진공관에 벌레가 자주 끼는 이슈로 오류를 일으키는 사례가 잦았다고 한다. 이를 제거하는 작업이 바로 디버그(Debug)로 디버그의 유래가 여기에서 나왔다고 한다. 접두어 De- 가 붙게 되면 “제거한다”의 의미가 있다.

중복제거(De-Duplication)도 이와 같은 이유로 백업 시스템에서 중복된 백업본 데이터를 제거한다는 의미로 최근 들어 디스크 백업 장치를 널리 사용하면서 필수 기술이 되었다.

소스단위 중복제거(Source Level Deduplication)

- 백업 시간 및 백업 저장 공간을 절약한다.

- CBT(Changed Block Tracking), Hash 알고리즘 기술을 이용한다.

글로벌 중복제거(Global Level Deduplication)

- 백업 저장 공간을 절약한다.

- Hash 알고리즘 기술을 이용한다.

특히 글로벌 중복제거 기술은 일부 백업 솔루션에 적용되고 있으며, 단일 시스템 내에서 만이 아니라 전체 백업 대상 노드 간에 중복된 블록까지 중복제거 백업하여 데이터 감쇄율(Data Reduction Ratio)이 대단히 높다(최소 60% ~ 최대 90% 이상). 이런 이유로 백업 시스템을 도입할 때 솔루션 자체적으로 중복제거 기능을 탑재하고 있는지 확인해야 한다. 그렇지 못한 솔루션은 중복제거 기능을 제공하는 별도의 백업 하드웨어와 연동이 필요해 도입 비용이 늘어난다.

마지막으로 가끔은 압축(Compression) 기술을 중복제거 백업이라고 오해하거나 잘못 전달되는 경우가 있는데, 압축과 중복제거 기술은 확연히 다른 기술이다.

4. 백업 소요 시간

백업 윈도우(Backup Windows)는 특정 서비스 시스템에서 ‘백업에 할애할 수 있는 시간’ 또는 ‘백업 소요 시간’으로 해석된다.

레거시 백업 솔루션을 운영하던 때에는 백업 윈도우는 약 6시간 ~ 8시간(± 2시간) 이었다. 제한된 백업 윈도우내에서 모든 백업 스케쥴을 정상 종료하기 위하여 다양한 기술과 아키텍처를 구성하였으나 항상 만족스럽지는 못했다.

블록단위의 이미지 백업

- 레거시 백업 솔루션이 일반적으로 파일 단위의 백업을 지원했다면 최근의 X86 시스템에서 널리 사용되고 있는 솔루션은 이미지 단위 백업을 지원한다. 물론 이미지 단위 백업이라고 하여 모두 블록단위 백업을 지원하는 것은 아니다. 일부 솔루션들은 Snapshot 이미지를 생성하여 백업장치에 저장 시, 파일단위로 전송하여 백업 시간 감소 효과가 적을 수 있다.

위 표는 한 공공기관의 Linux 기반 메일 시스템 백업을 한 사례인데, 이 기관은 기존 레가시 백업 솔루션을 이용, 주기적으로 파일단위 백업을 했다. 초기에는 백업 데이터 양이 적어서 문제가 없었으나 데이터 양의 증가로 전체 백업 시(실제 운영 데이터는 7TB) 3일 이상이 소요됐다. 그러나 위의 표에서 알 수 있듯이 블록단위의 이미지 백업 솔루션은 7TB 전체 백업 시 17시간 30분이 소요되어 기존 레거시 백업 솔루션 대비 1/4 수준의 백업 소요시간으로 단축된다.

5. 복구 소요 시간

사람들은 ‘백업(Backup)’을 ‘보험(Insurance)’에 비유한다.

지금은 일어나지 않았지만 미래에 언젠가는 일어날 사건을 대비하는 목적이 크다고 할 수 있기 때문이다.

위키피디아에 의하면 보험(Insurance)은 재정적 손실로부터 보호하기 위한 수단이다. 그것은 위험 관리의 한 형태이며, 우발적 또는 불확실한 손실 위험을 회피하기 위해 주로 사용된다.”라고 정의하고 있다.

그리고 ‘백업(Backup)은 정보 기술 측면에서 백업, 데이터 백업 또는 백업 프로세스는 보조 스토리지에 있는 컴퓨터 데이터의 아카이브 파일로 복사하는 것을 말한다. 데이터 손실 이벤트가 발생한 후에 원본을 복원할 수 있다.’고 정의하고 있다.

위의 두 정의에서 알 수 있듯이 보험은 ‘재정적인 손실’, 백업은 ‘데이터 손실’에 대비하기 위한 것으로 손실에 대비한다는 공통점이 있다.

백업 시스템은 데이터 손실 시 데이터 복원을 그 기본 전제로 하며, 데이터 복원을 위해서는 전통적으로 ‘리스토어’, ‘리커버리’ 절차가 있다. 그 외에 최근 가장 신속한 데이터 복원 또는 서비스 복원의 절차인 ‘마운트’와 ‘즉시 복구’ 개념이 도입되고 있다.

리스토어

- 리스토어(Restore)는 문자 그대로 백업 본으로부터 손실된 데이터를 디스크 백업장치, 테이프 백업 장치 등에서 다시 꺼내어 데이터 손실을 극복하는 절차이다. 주로 파일, 폴더, 데이터베이스 오브젝트 자체를 리스토어 한다.

- 파일, 폴더는 리스토어만으로 애플리케이션을 재구동 하는데 지장이 없지만, 데이터베이스 등 트랜잭션 기반의 데이터들은 단순하게 리스토어만으로 애플리케이션 재구동을 할 수 없다.

리커버리

- 위에서 언급한 데이터베이스 등 트랜잭션 형태의 데이터 복원을 위한 절차이며, 리스토어 한 후 각 애플리케이션 특성에 따라 리커버리 프로세스를 수행한 후, 정상적으로 애플리케이션을 구동하게 된다.

- 리커버리 절차를 통해 특정 시점의 레코드로 복원되며, 트랜잭션 애플리케이션 종류에 따라서 다양한 리커버리 프로세스가 있다.

- 즉 리스토어 + 리커버리 절차가 필요하며 손실 이전의 상태로 되돌리기 위해서는 시간이 많이 소요될 수 있다.

마운트

- 별도의 리스토어 절차 없이 백업 본을 파일시스템으로 즉시 마운트 한다. (Windows 인 경우 Z: Drive Letter에 마운트 하거나 Linux 인 경우 /Mount_Point 에 마운트 한다.)

- 마운트하여 복구해야 할 데이터가 적합한지 확인한 후, 바로 ‘복사’ & ‘붙여넣기’ 형태로 데이터를 복원한다. 만일 복구해야 할 데이터가 아니라면 다른 백업 본을 즉시 마운트 하여 손실된 데이터를 신속하게 복원한다.

- 레거시 백업 솔루션에서는 리스토어 및 리커버리 절차에 많은 시간이 소요된다. 데이터 리스코어 및 리커버리 한 후 손실된 데이터가 아니라면 다시 많은 시간을 기다려야 해 장애 복구에 어려움이 따른다.

즉시 복구(Instant VM/Instant BMR)

- X86 시스템으로 다운사이징 되면서 물리, 가상화, 클라우드 다양한 환경으로 구성되는데, 기존의 UNIX 환경의 레가시 시스템에서는 제공할 수 없는 중요한 기술들이 적용되고 있다.

- 기업/조직의 다양한 시스템 환경에서 서비스 장애 시, 이전과 같이 리스토어, 리커버리 절차 없이 전체 시스템을 백업 이미지를 이용하여 바로 또 다른 물리서버, 가상화서버 그리고 클라우드 환경으로 ‘즉시 복구’하여 서비스를 재 구동할 수 있다.

- 레가시 시스템에서는 수 시간에서 수일이 소요되던 복구 프로세스를 단 몇 분 안에 할 수 있다. 백업 솔루션의 고가용성(High Availability)을 확보할 수 있는 것이다.

6. 랜섬웨어 방지

“랜섬웨어는 IT 조직에 가장 위협적인 위험이다. 전 세계적으로 바이러스로 인한 전염병 비율에 도달했다.”

그러나 IT 전문가와 비즈니스 의사 결정자에게는 이 뉴스에 대해 끔찍하게 느낄 필요는 없다. 사이버 범죄자들이 여전히 기승을 부리지만 사이버 퇴치 및 재난 복구 기술이 발전되고 있으며 이들 기술이 건전한 IT 관리 관행과 결합해 사이버 범죄자들을 물리치고 있기 때문이다.

랜섬웨어는 기업들의 비즈니스에 큰 위협을 주고 있지만 여기에 대응하는 기술이 출현해 두려워할 필요는 없다는 얘기다.

1. 진보된 백업, 재난 복구, 고 가용성 및 사이버 보안을 위한 통합 심층 보호 솔루션을 적용한다.

2. ROI(Return on Investment)를 실현하는 효과적인 사용자 참여, 데이터 관리 및 재해 복구를 통해 사이버 위협에 대응할 수 있다.

3. 위협 탐지를 가속화하고 백업된 데이터를 즉시 복원할 수 있는 첫 번째 방어 라인을 제공한다.

많은 솔루션에는 실제로 필요한 중요한 기능이 없을 수 있다.

익스플로잇(Exploit, 착취)이 시그니처 기반 안티 바이러스 기술을 적용할 때 악성 코드 문제를 해결하는 것이 더 쉬워졌다. 위협이 진화하고 일반적인 취약점에 대한 고유한 공격이 포함됨에 따라 서명 기반 기술을 사용하여 위협을 식별하기가 더욱 어려워졌다.

또한, 많은 데이터 보호 솔루션 업체가 랜섬웨어 대항마를 상대로 실제로 사이버 보안 기능을 강조하여 실제로 랜섬웨어와 관련이 있거나 그렇지 않을 수 있는 데이터 오류를 탐지할 수 있다. 그리고 이상 징후를 감지한 후에는 문제를 해결하기 위한 조치를 취하기보다는 경고만을 제공하는 경우가 많다.

이제는 근본적으로 외부 칩임자가 백업 본을 변조하지 못하도록 특정 명령어나 스크립트 수행을 차단해야 하는 방식으로 진화해야 한다.

7. 백업 카탈로그

전통적인 레거시 백업 솔루션에는 백업 수행을 하면서 기록되어야 할 모든 오브젝트가 ‘백업 카탈로그’ 라는 곳에 저장된다. 그래서 백업 수행 마지막 절차에는 ‘백업 카탈로그’ 백업 절차가 추가로 수행된다. 기록해야 할 양이 많게 되면 백업 소요 시간도 증가한다. 이는 복구 시 매우 유용하게 사용되며, 만일 백업 시스템에 장애가 발행하게 되면 ‘백업 카탈로그’ 부터 복원을 해야만 손실된 데이터를 복원할 수 있다. 백업 시스템에서는 백업본과 더불어 반드시 백업 미디어에 별도로 저장을 해 두어야만 한다.

‘백업 카탈로그’가 유실되고 별도의 카탈로그 백업이 되어 있지 않은 경우 전체 백업 본을 스캔하여 ‘백업 카탈로그’를 재 생성하거나, 이마저 불가능 한 경우 일부 데이터만이라도 백업 미디어에서 직접 불완전 복구하게 된다.

백업 솔루션마다 다르겠지만 일반적으로 B-tree 구조 또는 RDBMS 형태의 백업 카탈로그를 생성하며, 특히 B-tree 구조의 백업 카탈로그는 신속한 조회의 장점도 있지만 크기가 커지게 되면 정합성 오류가 발생되어 정합성 보정을 위한 시간이 추가로 필요하다. 백업 시스템 운영자가 ‘백업 카탈로그’ 관리에 특히 주의를 기울여야 하는 이유이다.

A. No-Catalog

- 최근의 백업 솔루션은 ‘백업 카탈로그’를 생성하지 않아도 된다.

- 백업 본만 있으면 별도의 백업 솔루션을 설치하지 않고도 어느 시스템이든 파일/폴더/전체 이미지 단위로 복원할 수 있다.

- 재해복구 센터 구축이 용이하다.

- 가상화 환경, 클라우드 환경으로의 이전이 용이하다.

데이터 보호 솔루션 연비 1등급 기준

기업의 환경에 따라서 백업에 대한 다양한 기준을 고려할 수 있다. 그러나 최소한의 등급 결정을 위하여 위에서 언급된 7가지의 기준을 표로 정리하면 다음과 같다.

기존 레거시 보호 시스템으로 구축되었다면, 이제 새로운 기준을 적용해야만 급속하게 변화하는 시스템 환경에 대응할 수 있다.