[컴퓨터월드] 이율곡(이이)선생은 어머니 신사임당과 함께 모자(母子)가 화폐 모델인 된 인물이다. 한국 역사상 현인의 경지에 근접한 인물을 꼽으라면 관점의 차이는 있겠지만 율곡 이이 선생을 꼽는데 누구도 주저하지는 않을 것이다.

우리역사상 전무후무한 일이며 또한 예언자적 능력도 뛰어나 임진왜란을 미리 예견하고 10만 양병설을 주장했으며 정치, 경제, 국방 등 모든 분야에 식견이 탁월한 정치가요 사상가이며 교육자였고 철학자였다.

그는 신사임당을 어머니로 둔 뿌리깊은 천재가문의 집안에서 태어났으며 한국판 제갈공명, 한국정신사의 큰 산맥, 성리학의 대가, 등 여러 가지 수식어가 따라 다녔다.

이율곡의 이름 앞에는 늘 ‘구도장원공(九度壯元公)’이란 수식어가 붙는다. 아홉 번(九度)이나 장원을 한 분(公)이란 말이다. 이때의 장원은 과거 시험을 뜻한다. 조선시대를 통틀어 그런 기록 보유자는 율곡 한 사람뿐이다.

여기서 이런 의문이 든다. ‘과거 시험은 한 번만 보면 될 텐데, 왜 9번이나 봤을까? 실력 자랑을 하고 싶어서인가?’ 그 까닭을 살펴보려면 당시의 과거 제도에 대한 이해가 필요하다. 정리하자면 29살 때 한꺼번에 단계적으로 치른 6단계 모두를 수석으로 합격했고[장원급제], 13세 ~ 23세 시절에 치른 3번의 하급 시험에서 장원을 했는데, 그걸 모두 합쳐서 ‘9도장원공(九度壯元公)’이라 하게 되었다.

실력을 과시 삼아 같은 시험을 9번이나 치른 것은 결코 아니었으나 많은 사람들은 이 부분에서 동일한 시험을 9번이나 치뤄 다른 급제자들의 기회를 박탈하였다는 오해 또는 곡해가 있었다.

위의 일화에서 알 수 있는 내용은 많은 사람들은 천재든 아니든 자신의 관점에서 현상을 이해하려고 한다는 것이다.

소프트웨어의 오류/결함(Error/Defect)을 ‘버그(Bug)’라고 한다. ‘벌레’라는 뜻이다. 그 이유는 자못 역사적이다. 프로그래밍 언어 코볼(COBOL)의 어머니이자 전설적인 프로그래머였던 그레이스 호퍼(Grace Hopper)가 1947년 초창기 전자계산기의 모델 중 하나인 MARK II의 오동작 원인을 찾던 중 발견한 ‘나방(MOTH)’이 그것이다. 그 이후로 컴퓨터 프로그램의 오류를 찾아서 제거하는 작업인 ‘디버깅(DEBUGGING)’이라는 용어가 사용되기 시작한 것이다. 재미있는 얘기이긴 하지만 이것 때문에 소프트웨어 결함과 오류를 나타내는 ‘버그’는 낯선 전문용어로 부르면서 실수와 착오를 부드럽게 포장하는 경향이 생긴 건 아닌지 의구심이 든다.

소프트웨어의 품질과 연관된 얘기라면 빠질 수 없는 것이 소프트웨어 품질평가로 국제표준(ISO 9126)에서는 다음 6가지 요소를 제시한다.

1. 기능성
2. 신뢰성
3. 사용성
4. 효율성
5. 유지보수성
6. 이식성

중요한 순서를 생각해보니, 위에 나열한 순서가 대략 맞다, 기능성이 제일 중요하다, 뭔가 유용해야 하니까. 그 다음 신뢰성이다. 원하는 데로 오류 없이 잘 작동되어야 한다. 다음은 사용성, 사용하기 편해야 한다. 그리고 효율성, 자원 낭비적이면 안 된다. 속도로 빨라야 한다. 적은 메모리와 CPU 자원을 소모해야 한다. 마지막으로 유지보수성과 이식성이 좋으면 정말 좋다.

많은 기업의 운영자들이 관리하는 시스템을 보면 메인프레임, 유닉스, X86 기반의 리눅스(Linux), 윈도(Windows) 운영체제다. 아직까지 일부 산업계에서 여전히 유닉스 플랫폼을 운영하고 있지만 선도적인 기업은 X86 기반의 Linux/Windows 운영체제로 플랫폼 전환을 완료했거나 서두르고 있다. 메인프레임은 이미 많은 고객들이 유닉스로 다운사이징을 했다. 메인프레임을 운영하던 고객은 X86기반의 리눅스(Linux)로 다운사이징을 하는 등 메인프레임은 점차 영향력이 줄어들고 있음을 알 수 있다.

기업이 운영하는 플랫폼의 변화가 이러한 소프트웨어 솔루션 기업의 생사를 좌우할만큼 영향을 미치는 것을 우리는 직접 목격하고 있다.

이러한 변화 속에서 백업 시스템 또한 시류의 흐름에 편승을 하면서 기존의 백업서버, 백업소프트웨어, 백업장치, 백업 네트워크(IP, SAN 등) 각 구성 요소를 도입하던 데서 벗어나 단일 통합 장치인 ‘백업 어플라이언스’ 형태의 구축추세로 변화하고 있다. 이런 상황에서 백업 시스템 도입 시 고려해야할 요소, 즉 시스템이 갖추어야 할 6가지 항목을 알아본다. 여기에 추가적으로 고려할 사항인 보안성까지 추가해 7가지 각각의 특징을 살펴본다.

1. 기능성

엔터프라이즈 시스템 백업을 위한 기본 기능성을 만족해야 한다. 운영자들이 관리하는 시스템(흔히 서버라고 부름)을 크게 4가지 레이어로 나누게 되면, 운영체제, 파일 데이터, 데이터베이스 데이터, 애플리케이션으로 구분된다. 애플리케이션에 기업의 비즈니스 로직이 담겨져 있으며 수많은 비즈니스 데이터를 산출하는 역할을 한다.

최근 백업의 주요 대상은 운영체제(OS), 파일 데이터, 데이터베이스 등이다. ‘백업’에 대해 정의를 할 필요가 있다.

● 백업 : 논리적/물리적 장애에 대비해 운영데이터를 제2의 저장소, 또는 제3의 저장소에 복사본을 두는 것을 의미한다. 백업 이미지는 백업 주기와 보관 주기에 따라 관리된다. 많은 사람들이 백업과 아카이빙과 복제에 대해 정확히 이해하지 못하고 있는데 여기에서 ‘아카이빙’과 ‘복제’에 대해 정의를 해본다.

● 아카이빙 : 데이터를 중/장기간 운영매체가 아닌 다른 비용 효율적인 매체에 이동해 두었다가 특별한 목적을 위해 조회할 수 있는 시스템을 의미한다. 운영데이터를 제2 또는 제3의 매체에 저장해야 하는데 이 때 아키이빙 데이터의 손쉬운 조회와 CONTEXT 수준의 신속한 조회를 위한 메타데이터 관리가 필요하다.

● 복제 : 흔히들 ‘백업’과 혼돈을 하는 용어이기도 하다. 복제는 운영데이터를 동일한 속성을 가지고 운영 데이터와 별도의 매체에 로컬 사이트 또는 원격지 사이트에 동일한 운영데이터를 복사해 두었다가 운영데이터 유실/손실 시 바로 접근하여 서비스를 재개할 수 있다. 그러나 운영데이터가 실시간으로 복사되고 있어서 바이러스가 침투되거나 논리적인 장애에 대비가 없다.

● 백업본 복제 : 복제와 백업본 복제는 구분이 필요한데, 백업본을 과거에는 테이프 소산으로 제2의 장소에 백업본 테이프를 보관해 왔으나 최근에는 백업 어플라이언스에서 원격지 백업 어플라이언스로 백업본을 즉시 복제하는 방식으로 구축된다.

이처럼 백업/아카이빙/복제는 구분되어서 구축되며 데이터의 종류 및 기업의 SLA(Service Level Agreement)에 따라서 적용방법이 다르다.

일반적으로 레거시 백업 즉, 메인프레임 중심의 플랫폼에서 유닉스 플랫폼으로 전환되면서 대다수의 기업이 구축하여 운영하던 백업 아키텍처를 ‘레거시 백업 아키텍처’라고 부른다. 이러한 솔루션은 파일 백업 에이전트, 데이터베이스 에이전트 및 다양한 형태의 에이전트를 별도로 설치해 운영해야 했다. 물론 통합 관리를 위해 백업 서버를 별도로 구축해야 했다.

● 파일 백업 에이전트 : 운영체제 파일 시스템의 파일 데이터 백업을 위하여 별도로 설치되는 에이전트

● 데이터베이스 백업 에이전트 : Oracle, My-SQL, MS-SQL 등 다양한 온라인 트랜잭션 데이터베이스를 백업하기 위해 별도로 설치되는 에이전트

● 운영체제 백업 에이전트 : Windows, Linux, 등 다양한 운영체제의 온라인 백업을 하여 동일한 기종 또는 다른 서버에 운영체제 복구를 위하여 별도로 설치되는 에이전트

● 애플리케이션 백업 에이전트 : ERP, SharePoint Server, Exchange 등 다양한 애플리케이션의 온라인 백업을 위한 별도로 설치되는 에이전트

그러나 백업 어플라이언스는 이처럼 별도로 설치 및 구성되던 절차를 단일화해준다. 단일 백업 어플라이언스 구축으로 운영체제, 파일데이터, 데이터베이스, 애플리케이션 모두를 보호할 수 있다.

2. 신뢰성

백업은 복구를 위해 존재한다. 장애 발생시 매일 백업해 두었던 백업본을 활용하여 시스템을 복구할 수 없다면 아무런 의미가 없다. 여기에서 고려해야 할 요소는 라이선스다.

일반적으로 백업 어플라이언스는 용량단위 라이선스 방식을 제공하고 있으며, 크게 어플라이언스 일체형 라이선스와 분리형 라이선스로 구분된다. 분리형인 경우 백업대상 운영데이터 용량 기준으로 보통 Front-end Capacity(1TB) 라이선스를 필요한 용량만큼 어플라이언스 하드웨어와 별도로 구매하게 된다. 일체형인 경우에는 어플라이언스 하드웨어에 라이선스가 포함되어 있으며 백업대상 운영데이터 용량은 무제한으로 제공되며 서버 수, 가상서버의 CPU 수 등 무제한이다. 백업 어플라이언스의 사용 용량만큼 백업 받을 수 있다.

일체형 라이선스인 경우는 매우 단순하다. 고객이 구입한 백업 어플라이언스 가용 용량 범위 내에서 백업 본을 보관할 수 있기 때문이다. 그러나 분리형 라이선스의 경우에는 세밀히 따져보아야 한다. 백업 대상 운영 데이터 용량을 산정하고 백업 주기와 보관주기를 고려하여 필요한 백업 어플라이언스 가용 용량을 산정하여 Font-end Capacity(TB) 라이선스를 필요한 용량만큼 구매해야 한다. 즉, 고객이 산정한 백업 대상 운영 데이터 용량이 20TB라면, Font-end Capacity(TB) X 20 Copy 라이선스를 구매해야 한다.

또한 주요 운영플랫폼이 X86 서버 시스템으로 변화하면서 Linux, Windows의 운영체제 백업 요건이 필수로 되어가고 있다. 이런 상황에서는 백업 어플라이언스 도입 시 반드시 ‘OS 백업 기능’을 고려해야 한다.

3. 사용성

백업 어플라이언스 시스템을 구축하고 운영할 때 사용성과 관련해 고려해야 할 체크리스트가 있다. 바로 백업 에이전트의 ‘운영 자원 점유율’과 ‘백업 윈도우(Backup Windows)’ 확보다. 이 두가지는 모두 기업의 운영 시스템의 자원과 제한된 운영 시간 자원을 소모하는 요소로 재 정의할 수 있다.

간단한 예를 들어보자. 중요 데이터베이스 서비스를 운영하는 경우 파일 백업과 데이터베이스 및 운영체제 백업을 위해서는 최소한 3가지 종류의 에이전트를 설치해야 한다. 그리고 각 에이전트가 평균 5%의 시스템 운영 자원을 사용한다면 최대 약 15%의 기업 운영시스템 자원이 백업을 위해 소모된다고 할 수 있다.

야간에 백업 작업을 수행한다면, 파일 백업을 위한 정책(스케쥴), 데이터베이스 백업을 위한 정책(스케쥴)과 운영체제 백업을 위한 정책(스케쥴) 등 한 개의 서버내에서 최소 3가지 종류의 백업 정책을 스케쥴해야 한다. 이러한 시스템이 100대일 경우 최소 300개 이상의 정책(스케쥴)이 적용되어야 한다.

U2L(Unix to Linux)로 다운사이징 한 기업이라면 일반적으로 최소 500 ~ 3,000여대 이상의 서버를 운영하고 있다. 이러한 환경에서 기업이 기존 레거시 방식의 백업 정책을 고집한다면 구축한지 얼마되지 않아서 다양한 이슈에 마주칠 것이다.

아래 그림은 약 100대 시스템을 사용하고 있는 모 기업의 레거시 백업의 진단을 했을 때, 백업 대기시간 현황을 보여주고 있다. 다수의 백업 정책을 적용으로 ‘백업 대기 시간’이 매우 길다는 것을 알 수 있다.

4. 효율성

백업 어플라이언스를 구축하면서 효율성을 높이기 위해 여러가지 사항을 고려해야 한다. 우선 백업저장공간의 효율적인 관리가 중요하다. 백업 프로세스는 말 그대로 중복된 데이터의 반복적인 저장을 요구하는 작업이기 때문에 비 효율적인 저장공간을 관리해야 한다. 이런 이유로 중복제거 백업 기술과 압축 기술이 중요하다.

백업 저장 공간 절감 율은 중복제거 율 + 압축 율로 정의할 수 있다.

VTL과 같은 백업 저장장치는 하드웨어 컨트롤러의 펌웨어 수준에서 중복제거 기술을 제공하며, 백업 어플라이언스는 탑재된 백업 소프트웨어가 제공하는 중복제거 기술을 적용하게 된다. 위의 표에서 알 수 있듯 각각의 특징과 장점이 있으며 시스템 요구사항에 자장 적합한 저장 기술과 저장 방식을 채택해야 한다.

데이터 유형에 따라 중복제거 율과 압축율은 다르게 나타나는 데, 일반적으로 운영체제는 95% 이상 백업저장공간 절감 율을 제공하며, 일반 데이터 백업은 평균 60% 이상의 백업저장공간 절감 율을 갖는다.

5. 유지보수성

어느 시스템이든 구축 후 고려해야 할 사항은 ‘유지보수성’이다. 여기에서는 얼마나 운용 효율적이며, 비용 효율적인지가 중요하다.

● 온라인 설치 : 백업 에이전트 초기/재 설치 시, 윈도(Windows), 리눅스(Linux) 환경에서 운영 시스템의 재시작 없이 서비스를 유지하고 에이전트를 설치 및 구성할 수 있어야 한다.

● 소프트웨어 업그레이드 및 패치 : 소프트웨어는 시간이 지나면 패치가 필요하고 새로운 버전으로 업그레이드를 해야한다. 엔터프라이즈 환경에서는 수백대의 백업 대상 서버의 에이전트를 업그레이드해야 하는 수고를 감수해야 한다. 그러나 백업서버 또는 콘솔 업그레이드만으로 백업 대상 서버의 에이전트까지 자동으로 온라인으로 업그레이드된다면 운영자 입장에서 참으로 편리할 것이다.

● 확장성 : 하드웨어 관점에서 백업 어플라이언스의 용량 확장성을 제공하여야 하며, 인프라 관점에서 백업 시스템에서 재해복구 및 고가용성(HA, High Availability) 시스템으로 확장할 수 있는지를 살펴야 한다.

6. 이식성

기업의 시스템 환경은 참으로 다양하다. 물리서버/가상화/클라우드 등 다양한 운영 환경을 지니고 있다. 또한 다양한 종류와 버전의 Linux/Windows 운영체제와 데이터베이스를 운영하고 있다. 도입하는 백업 어플라이언스는 아래와 같은 다양한 인프라 환경에서 유연하게 적용할 수 있어야 한다.

솔루션에 따라 물리환경과 가상화 환경 및 클라우드의 통합 관리를 지원하지 못해 별도의 관리콘솔을 운영해야 할 수도 있다. 또한 운영체제 백업, 파일 백업, 데이터베이스 백업을 위해 별도의 에이전트를 각각 설치해 운영해야 할 수도 있다.

때문에 기업들이 백업 어프라이언스를 도입할 때 다양한 구축 환경을 모두 유연하게 지원하는 지 확인이 필요하다.

7. 보안성

백업 어플라이언스는 운영 시스템에 장애가 발생해 가용 데이터가 분실, 유실 또는 변조됐을 때 문제를 해결할 수 있는 최후의 보루이다. 블랙해커들이 백업본을 랜섬웨어를 이용한 주요 공격 대상으로 삼는 것도 이런 이유에서이다.

실제 랜섬웨어는 비즈니스의 가장 큰 위험으로 자리잡았으며 IT 조직에 가장 큰 위협이 되고 있다. 이에 대응하는 사이버 퇴치 및 재난 복구 기술의 발전 속도 또한 매우 빠르게 이루어지고 있다. 랜섬웨어가 비즈니스에 중대한 위협으로 작용하고 있지만 크게 걱정할 필요가 없는 것이다.

오늘날 기업들은 랜섬웨어등 각종 위협에 대응하기 위해 다음을 수행해야 한다.

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

2. ROI(Return on Investment)와 데이터 관리 및 재해 복구 실현

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

위협이 고도로 진화하면서 위협을 식별하는 것이 과거보다 어렵게 됐다. 이런 상황에서 많은 데이터 보호 솔루션 공급 업체들이 랜섬웨어에 대응하기 위해 사이버 보안 기능을 강조하면서 데이터 오류를 탐지할 수 있는 방안을 마련하고 있다. 그러나 이들 데이터보호업체들은 문제 해결을 위한 조치보다 이상 징후 발견시 경고를 하는데 그치는 경우가 많다.

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

맺음말

지금까지 백업 어플라이언스 도입 시 고려해야 할 주요 7가지 항목에 대해 알아봤다. 기능성, 신뢰성, 사용성, 효율성, 유지보수성, 이식성, 보안성이 그것이다.

아크서브사의 어플라이언스 9000 시리즈(Appliance 9000 Series)는 단일 백업 에이전트로 구축 및 운영할 수 있도록 해준다.

최근 X86서버의 물리 및 가상화 환경에서 백업 시스템을 구축할 때 여전히 UNIX 플랫폼 환경에서 운영되던 레거시 백업 솔루션을 도입하는 경우도 많다. 기존 운영환경을 유지하기 위한다는 명목으로 기존의 레거시 백업 아키텍처를 아무 고민 없이 채택하는 것이다.

그러나 X86 환경에서는 다른 접근 방법이 필요하다. 대용량의 파일 백업을 위해 파일 단위의 레거시 백업은 여전히 해결해야 할 문제가 많다. 최근 트렌드인 이미지 백업은 그동안의 고민을 해결해줄 것이다. 또한 단일 에이전트로 구축되는 최근 트렌드의 백업 아키텍처는 운영서버 자원 사용율을 최소화하며, 단순한 ‘백업 윈도우(Backup Windows)’ 정책을 지원할 수 있다.