서비스장애 발생 원인 조사 보고서

지난 수 년 간 많은 자연재해들이 신문의 헤드라인을 장식했으며 그 피해들도 어마어마했습니다. 많은 생명들이 사라지고 보금자리가 파괴되는 가운데 기업들의 생존 또한 위협받게됩니다. 미시시피주의 Small Business Development Center의 관계자에 따르면 태풍들(카트리나와 리타)이 지나가고 나서 미시시피지역에 있던 작은 회사들 중 60%가 사라졌다고 합니다.

그러나 이러한 재난들이 중소기업에게는 태풍이나 지진, 폭풍 같은 자연재해만을 의미하지 않습니다.

지금부터 하드웨어 고장 같은 ‘재앙, 재난’이 얼마나 자연재해를 능가하는 피해를 줄 수 있는지 살펴보겠습니다.

재난(재앙)을 어떻게 정의하는가와 관계없이 한가지는 분명합니다. 재난으로 인해 발생하는 시스템의 다운타임은 중소기업에게 심각한 상황을 가져올 수 있다는 것입니다. 실제로 HP와 SCORE의 보고서를 보면 소규모 회사들의 경우 재난을 겪고나면 약 25% 정도가 문을 닫는다고 합니다. 흔히 인용되는 Aberdeen Group의 리포트에서는 중견기업의 경우 1시간 정도의 서버 다운만 있어도 약 9천만원($74,000)의 손실을 입습니다.  IDC의 경우도 시간 당 손실을 약8천5백만원($70,000) 정도로 비슷하게 잡고 있습니다.

그런데 불행하게도 시스템이 죽는 다운타임은 보통 1시간으로 끝나지 않습니다. 실제로 Harris Interactive사의 조사에서 IT담당자들은 시스템 복구하는데 보통 30시간 정도 걸린다고 말합니다. (기껏해야 10시간 정도로 생각하는 경영진들에게는 놀라운 일일겁니다.)

각종 재난들을 완전히 없애버릴 수는 없지만 피해는 줄일 수 있습니다. 지속적으로 시스템 상태를 테스트하면서 유사시에는 시스템의 데이터와 애플리케이션, OS를 즉시 복구할 수 있는 재난복구기술이야말로 기업의 이익과 고객, 신뢰를 지키는 유일한 안전장치입니다.

본 보고서에서는 하드웨어고장에서 자연재해에 이르는 다양한 재난들이 얼마나 자주 발생하는지그 동안의 조사 결과를 정리합니다.

Quorum사 고객지원센타의 고객들을 통해 수집한 실제 사례들이 생생하게 와 닿을 것입니다.

 

한 눈에 보는 조사결과

다음 그림은 시스템의 다운타임을 빈번하게 일으키는 4가지 주요 요인을 정리한 것입니다.

재난발생순위그림

하드웨어 고장

55%로 하드웨어 고장이 시스템 다운타임의 원인 중 가장 큰 비중을 차지합니다. 전원공급장치나 네트워크 컨트롤러, 하드디스크 등 많은 자원들을 여분으로 준비하고 있으므로 하드웨어 관점에서 안전할 것으로 생각할 수 있습니다만 여전히 빈틈이 많습니다. 요즘같이 매섭게 뜨거운 날 냉방장치가 고장난다면, 국가적으로 대규모 정전사태를 걱정하고 있는 이 때 전원이 끊어진다면, 생각지도 못하게 쥐 같은 것들이 어디 케이블이라도 뜯어먹었을 때 무슨 일이 생길지는 아무도 모릅니다.

많은 중소기업들이 SAN(Storage Area Network) 고장을 경험합니다. 대규모로 SAN을 구성하고 모든 스토리지서버들을 가상화해서 SAN 영역에 두는 것이 일반적입니다만, 불행하게도 이로 인해 SAN에 문제가 생기면 회사전체가 문제가 됩니다.

캘리포니아은행인연합회(CBA ; California Bankers Assoc.)의 IT매니저인 랜디 마테오(Randy Mateo)씨도 이런 하드웨어 고장을 크게 경험한바 있습니다. 2010년 어느날 CBA의 SAN에 있는 하드드라이브가 몇 개 고장난걸 알게되었습니다. 가상서버들이 죽기 시작했죠. 원래대로라면 가상서버들이 서비스를 대신하기위해 기동(failover)해야했습니다만 그렇지 못해서 더욱 낭패였습니다. 하드디스크가 고장나면 기본 SAN서버가 모든 가상서버들과 데이터에 영향을 준다는 것을 알게되었습니다. “ 말할 필요도 없이 엄청난 일이었습니다. 가상서버들을 다시 살릴 수도 없어서 모두 새로 구성해야했습니다. “

마테오씨는 다행히도 가상화 플랫폼에서 제공하는 수동 백업기능으로 대부분의 가상서버들을 백업해두고 있었습니다. 그러나 Exchange 서버는 또 다른 문제였습니다.

“ Exchange 서버는 너무 커서 복구에 시간이 걸려서 최소 하루정도는 서비스를 못할 것 같았습니다. 그런데 복구하는데 실패하고 다시 세팅해야했습니다. 꼬박 사흘 반을 복구하는데 썼고 당연히 서비스를 못했습니다. “

 

인적 오류

모든 재난상황이 기술적인 부분에서 발생하지 않습니다. 재난원인의 22% 정도는 인적오류가 차지합니다. 실수로 서버의 파일시스템을 지워버리는 것 등이 여기에 해당됩니다.

ooops이런 인적요류는 흔히 신입사원이나 초보자들에게 일어난다고 생각할 수 있지만 꼭 그렇지만은 않습니다. 플로리다의 어떤 회사 임원의 경우 메일박스를 모조리 날려버리는 실수를 몇 번이나 했습니다. 주기적으로 서버를 백업하는 재난복구시스템을 사용하고 있었던 덕분에 중요한 메일들을 지킬 수 있었던 것이 다행입니다.

 

소프트웨어 오작동

소프트웨어 문제가 3번째 주요 원인으로 꼽혔습니다. 이는 패치가 얼마나 자주 일어나는가를 생각해보면 놀랄 일도 아닙니다. 이 소프트웨어와 관련된 문제는 패치를 적용하기 전에 제대로 테스트를 해보지 않기 때문에 주로 일어납니다. 패치로 인해 애플리케이션이 손상되고 이는 전체 시스템을 다운시키거나 접속을 못하게 됩니다.

운영체제(OS)의 경우 조금씩 제성능을 발휘하지 못하다가 결국 작동을 멈추게 되는 경우가 많습니다. 그리고 바이러스와 악성코드도 무시할 수 없습니다. 실제로 2012년 상반기에 36%의 소프트웨어 공격이 중소기업을 대상으로 이루어졌고 이는 2011년도 같은 기간에 비하면 두 배로 늘어난 숫자입니다. 이런 공격으로 네트워크 전체가 영향을 받고 결국은 회사업무가 마비됩니다.

소프트웨어 고장은 다양한 형태로 일어납니다. Sente Mortgage사의 IT임원인 Brent Schlueter씨는 최근 시스템 다운타임을 일으키는 소프트웨어 고장을 또 경험했습니다. 일상적인 소프트웨어 업그레이드를 하는 중이었는데 이전 버전으로 돌아가야할 필요가 생겨 작업하던 중에 SQL 데이타가 손상되었다는 것을 알게되었습니다. 이게 결국은 근본적인 파일구조에 까지 영향을 주게되어 최소 4시간의 시스템 다운타임이 발생하게 되었습니다. 덕분에 직원들은 빨리 평소보다 빨리 퇴근했습니다.

 

자연재해

태풍우리는 보통 재난, 재해라는 말을 들으면 우선 지진이나 태풍 같은 것을 떠올리게 됩니다. 반면에 자연재해가 전체 재난발생 원인의 5% 정도만 차지하고 있는 것을 보면 의외이긴 합니다만 그 파괴력에서는 비교할 수 없습니다.  HP와 SCORE의 보고서를 보면 자연재해로 인해 대규모로 데이터를 잃어버린 기업들의 70% 정도는 1년 안에 없어집니다.

유명한 인력채용회사인 24 Seven의 경우 일찌감치 재난복구시스템을 구축하고 주기적으로 실전사태에서 제대로 잘 동작할 수 있을지, 재난대비훈련을 해왔습니다. 덕분에 2012년 10월 초대형 태풍인 샌디가 공격했을 때 뉴욕의 본사는 근무를 할 수 없었지만 중요 업무들은 평소대로 운영할 수 있었습니다.

 

결론

재난이란 단순히 자연재해만을 말하는 것이 아니며 따라서 언제든지 일어날 수 있습니다. 그렇기때문에 대비해야 합니다. 그리고 적절한 관련 제품을 선택해야합니다. 실제 상황이 벌어졌을 때 제대로 다운타임을 줄일 수 있어야하기 때문입니다.

평소에 정기적인 테스트 또한 매우 중요합니다. IT관리자들은 번거롭고 복잡할 뿐만 아니라 시간도 많이 걸려서 이런 테스트를 싫어합니다. 따라서 관련 제품을 고를 때는 자동으로 간단하게 재난상황테스트를 할 수 있어서 재난상황에 대한 자신감을 심어줄 수 있는 제품이 좋습니다.

다이하드 의료정보시스템

점점 더 심해질 것으로 많이들 예견하고 있습니다만 전세계적으로 많은 기상이변들이 일어나고 있습니다. 1년 전 이맘때쯤 미국 미주리주에서는 토네이도 태풍으로 140명 이상이 사망하고 그 지역 대표 병원 중 하나인 세인트존스병원(St. John’s Regional Medical Center)의 시설 또한 대부분이 파손되는 큰 피해를 입었습니다. 병원 일부 건물이 약 10㎝ 정도 움직이고 110㎡ 정도 규모로 운영하던 데이터센터(Data Center) 또한 완전 붕괴되었습니다.

우리나라도 기상이변이 가져오는 예상하지 못한 위험들에서 자유롭지 않습니다. 가공할 위력의 지진이나 다른 나라에서 볼 수 있는 블록버스터급 토네이도 같은 재앙은 드물지만 집중호우 만큼은 매년 그 위력이 커지는 것 같습니다. 작년에는 60여 년의 역사를 지닌 국내 최대 규모의 재활병원이 설립 이래 처음으로 경안천 범람으로 물난리를 겪고 병원업무가 마비되는 초유의 사태를 겪기도 했습니다.

여기에 더해 우리나라의 경우는 자연재해와 더불어 경계해야하는 정치적, 군사적 위험요인도 있습니다. 누구도 예상하지 못했던 마른 하늘의 날벼락 같은 연평도 포격사태 같은 망연자실이 그것입니다.

비상대책위원회를 꾸며 보겠습니다.

세인트존스병원

 

 

 

 

 

    <토네이도로 완파된 세인트존스병원, 2011>

 

비상대책위원회

등장인물 : 챠트맨, IT맨1, IT맨2, 경비원

챠트맨 : 지금부터 완전통뼈병원의 비상대책회의를 시작하겠습니다. 현재 범인은 우리 병원의30대 서버 중 한대에 폭탄을 설치하였으며 10시간 안에 현금 100억을 가져오지 않으면 폭파시키겠다고 합니다. 서버를 열거나 움직이면 바로 터집니다. 우선 10시간 안에 모든 시스템을 다른 곳에서라도 정상 동작할 수 있도록 하는 것이 급선무입니다.

IT맨1 : (탕!) 야 안돼~ 생각을 해봐, 우리 서버들 그거.. 서버 회사 다 다른거 알지? 전화해서 10시간 안에 우리 서버들과 똑같이해서 운영할 수 있게 만들어주세요… 그러면.. 아, 네, 기다리고 있었습니다. 내일 바로 해 드리겠습니다. 그럴꺼 같애? 아, 네.. 그런데 그거 서버가 모델이 바뀌어서요.. 그거랑 같은 걸로 이중화로 구성하시려면 좀 찾아봐야 되는데요… 미국도 좀 갔다와야되고.. 이번 기회에 전부다 바꾸시죠? 그러지.. 거기다가 이거 저거 프로그램 깔다가 뭐가 있니.. 없니.. 되니.. 안되니.. 돈은 돈대로 꼽배기로 들건데.. 그런데 어떻게 10시간 안에 한다는거야… 안되에~

IT맨2 : (탕!) 야 나도 안돼~ 시간 안에 어찌어찌 똑같이 만들었다 치자. 10시간 지나면 터질거 아냐? 그럼 우리 시스템들 다시 가장 최신 상태로 만들어야 되는데.. 그게 보통일이냐? 동종 서버 구해서… 진단검사파일 같은거, 환자들 의료정보, 진료예약정보, 맞춰야지.. 처방프로그램 제대로 살려야지.. 수납데이타랑 사용인증서버 동작도 아무일 없었단듯이 정상화 해야하는데.. 너랑 나랑 다 붙어도 그거 하는데만 100시간도 더 걸리겠다.. 범인을 빨리 잡는게 낫겠다.. 이거 사람 불러야되.. 범인 잘 잡는 사람으로다.. CIS 불러.

경비원 : 지금 뭐 하시는 겁니까? 째깍째깍 폭탄 시계가 돌아가고 있는데.. 지금 부턴 내 지시에 따른다. 빨리 폭탄을 찾아서 해체하는 것이 급선무다. 개는 사람 보다 청각이 5배 이상 뛰어나다. 우리집 뽀삐를 서버실에 풀어서 폭탄부터 찾는다. 알겠나?

챠트맨 : 전자시곕니다.

경비원 : 구뤠? 요샌 전자 아닌게 없더라..이거 안돼..

 

재난대비시스템(Disaster Recovery) 선택 기준 3가지

과장된 상황이긴 합니다만 중단없는 안심의료정보서비스를 위해 재난대비시스템을 준비할 때 고려해야 할 주요 사항들이 거의 언급되었습니다. 이제 재난대비시스템을 구축할 때 도움이 될만한 3가지 기준을 살펴보겠습니다.

  1. 어떻게 보다 경제적으로 재난대비시스템을 구축할 것인가

언제 써먹을지도 모를 재난대비시스템의 존재이유를 고려한다면 비용요인이 큰 비중을 차지하게 됩니다. 그러다 보면 예산을 아끼기 위해 좀 덜 중요한 서버를 가려내고 재난대비계획에서 제외합니다. 미국기업의 경우에 운영 중인 서버자원의 20%만이 보호되고 있는 것이 이런 이유 때문일 것입니다. 반면에 의료정보서비스를 운영하는 입장에서 보면 중단 없이 원활하게 서비스를 운영하는데 크든 작든 기여하고 있으므로 모든 서버시스템들은 보호받을 가치가 있습니다.

예산에 맞추어서 어떤 서버는 재난상황에 대비하고 어떤 서버는 제외할까요?

애정남에게 물어봐야 할까요?

유사시에 서버를 보호하고 정보서비스를 유지하기 위한 산업계의 움직임은 크게 2가지 방향으로 발전해왔습니다.

첫번째 방향은 여유로 하나 더 시스템을 준비해두거나 똑 같이 복사해두는 것입니다(infrastructure mirroring). 서버자원들을 몽땅 똑같이 하나 더 만들어두고 계속 복사한다면 최고 수준의 재난대비상태일 것입니다.

두번째 방법은 서비스 구성요소 중에서 데이터만 따로 다른 저장공간에다 복사해두는 백업(backup)개념의 기술입니다.

서버자원을 몽땅 똑같이 하나 더 만들어두는 개념은 최상의 성능과 안전을 보장하겠지만 예상하시는 것과 같이 비용에 큰 결심이 필요합니다. 본능적으로 원래 구축비용의 두 배를 산정하게 됩니다만, 설계와 이행에 들어가는 부가 비용과 유지보수 비용을 감안하면 쉽게 결정할 비용에서 멀어집니다.

거기에 비해 백업 기술 진영은 예전의 테잎 장치에서 점점 저렴해지고 있는 디스크로 매체를 옮겨가며 발전하고 있습니다. 비용이 매우 저렴하다는 장점이 있으나 복구(recovery) 성능이 좋지 않은 단점이 있습니다. 테잎이나 디스크에서 데이터를 추출하고 서비스할 서버에다가 설치하고 서비스할 수 있도록 구성하는데 복잡한 절차를 거치게 되므로 시간이 많이 걸립니다. 그리고 데이터 손실 또한 발생합니다. 복구율이 채 70%도 안되는 경우도 종종 있는 듯 합니다.

 

  1. 재난대비 성능이 좋은가?

재난복구에 요구되는 기능은 크게 3가지입니다. 복제성능(replication)과 장애서버대체성능(failover), 장애서버복구성능(failback)으로 살펴볼 수 있습니다.

돌이켜보면 비상시의 서비스 복구와 관련한 대부분의 관련 기술들은 서비스 중인 서버를 어떻게 효과적으로 복제(replication)할 것인가에 중심을 두고 발전해 온 듯 합니다.

이러한 기술은 매일 테잎으로 백업하는 제품들부터 더 복잡한 SAN(Storage Area Network)기술을 이용한 제품까지 다양하게 소개되고 있습니다만, 현실에서 대부분의 정보시스템 운영담당조직은 다른 두 가지 성능요소인 장애서버대체성능(failover)과 장애서버복구성능(failback)에 더 큰 관심을 보입니다.

좋은 장애서버대체성능(failover)나 훌륭한 장애서버복구성능(failback) 기술이라면 그 기반에는 탁월한 복제(replication) 성능이 뒷받침 되어야 할 것이므로 당연하다고 생각됩니다.

 

여기서 장애서버대체(failover)와 장애서버복구(failback)가 무엇인지 간단하게 되짚어 보겠습니다.

장애서버대체(failover)는 서버의 장애가 발생했을 때 유사시를 대비해 준비 중이던 보조 시스템을 가동하여 중단 없이 계속 정보서비스를 제공하는 일입니다.

장애서버복구(failback)는 서버 장애로 발생한 비상 운영 상황이 종료되어서 정상적인 서버 운영 상태로 되돌려 놓는 일로 요약할 수 있습니다. 망가진 원래 서버를 고치거나 새로운 서버를 도입하고 나면 장애 중에도 발생한 운영상황을 반영하여 정상적으로 서버가 동작하도록 하는 것에 많은 노력이 요구됩니다.

장애서버대체(failover)를 위해서 소개되고 있는 제품들을 보면 대부분 여분으로 별도 장비를 사용하는 접근방식을 취합니다. 그러다 보니 구조적으로 좀 더 복잡해지고 비용이 높아지는 현상이 발생합니다. 이를 피하기 위해 비용효율이 좋은 백업(backup) 기술을 많이들 사용하게 됩니다만 장애서버대체(failover) 시간이 오래 걸리고 오류 발생 빈도도 높습니다. 아마도 원시 데이터(raw data)를 서버에서 서비스 가능하도록 변환하는 데서 발생하는 단점이라고 생각이 됩니다만, 어쨌거나 적당한 비용에 납득할 만한 장애서버대체(failover) 기능을 구현하는 것에 많은 관심들이 모아지고 있습니다.

장애서버복구(failback)는 재난대비절차의 마지막 단계입니다만 흔히들 재난상황을 가정하고 수립하는 계획에서 많이 빠뜨리게 됩니다. 많은 관련 제품들, 특히 백업 기반 제품들을 중심으로 계획을 수립하다 보면 장애가 발생하여 중단된 서비스를 빨리 재개하는 쪽으로만 관심을 두게 됩니다. 그러다 보니 중단된 서비스를 복구하고 나서는 다시 원래의 정상 운영 구조로 돌아가기가 어려워집니다. 수리가 끝난 장애서버를 현재 시점으로 재설치하는 일이나 혹은 완전히 새로운 서버를 도입하면서 발생하는 예상하지 못했던 어려움들을 겪게 됩니다.

  1. 평상 시에도 재난대비시스템의 테스트가 쉬워야한다

재난대비시스템을 구축하고 나면 이 시스템이 잘 동작하고 있는지 확인할 필요가 있습니다. 이를 위해 재난 대비 훈련을 하기 마련입니다만 보통 연중 1~2회로 그치는 경우가 많습니다. 이러한 재난 대비 훈련 횟수는 기술의 발전 추이나 기업 및 조직의 경영 변화와 이에 따라 진화하는 정보 시스템의 잦은 변경에 비추어 볼 때 터무니 없이 낮은 수치입니다. 안하는거 보다는 나은 수준입니다만 자주 많이 하고 싶어도 하지 못하는데는 이유가 있습니다. 많은 관련 기술들이 장애서버대체(failover)를 어떻게 효과적으로 할 것인가, 에만 관심을 두는 것이 중요한 이유 중 하나입니다. 재난 상황으로 서버의 동작이 멈추었을 때를 가정하고 테스트하는데 따르는 실제 서비스 장애 가능성 등을 미리 염두에 두지 않은 시스템이라면 동작 테스트의 시행에 적지 않은 용기가 필요할 것입니다.

결론적으로 재난발생과 정상운영상태 복귀에 이르는 전 과정의 성능과 동작 상황이 확인이 된 재난복구기술을 채택하는 것이 바람직합니다. 너무 자주 테스트를 해야 하는 것도 적절하지 않지만, 비상시를 대비한 점검 작업을 수행해보지 않고서는 사용하고 있는 재난복구 기술의 문제점을 파악할 수도 없습니다. 일이 터지고 문제점이 보인다면 이미 늦었겠지요.

DRscheme_kor

1대로 서버 40대까지… 단숨에 재난에 대비한다

서버의 백업과 이중화 등으로 많은 제품들이 소개되고 있으나 최근 미국 쿼럼(Quorum)사의 온큐(onQ)에 많은 관심이 쏠리고 있습니다. 온큐는 가상화 기술을 기반으로 서버의 운영체제(OS), 애플리케이션 그리고 데이터까지 모두 통합해서 한번에 백업한 후 필요할 때 단숨에 복구하므로 재난상황에도 서비스를 빠르게 재개할 수 있습니다. 온큐 한 대로 대상 서버 40대까지.. 또는 그 이상도 간편하게 자동화된 툴로 보호할 수 있다는 점이 인상적입니다. 전통적인 하드웨어 기반 서버는 물론 VM웨어, MS하이퍼V, Citrix 젠서버 등 모든 가상화 플랫폼을 지원합니다. 또한 온큐는 서버 하드웨어와 재난대비기능 발휘를 위한 소프트웨어가 최적으로 통합된 장비(appliance) 제품이므로 다양한 서버환경에서도 쉽고 간단하게 재난대비시스템을 구축할 수 있습니다. 서비스되고 있는 운영시스템에 영향을 미치지 않고 재난복구 테스트를 할 수 있으며 사용에 필요한 모든 소프트웨어 라이선스가 포함되어 있으므로 비용적인 면에서도 부담이 없습니다.

QuorumLogoonQ

 

 

 

 

한국과학기술정보연구원(KISTI)의 김주영 정보시스템운영팀장은 ‘재난대비시스템을 구축할 때 고려해야 하는 점이 매우 많습니다. 주센터에 맞는 하드웨어 사양부터 네트워크 확장, 백업과 복구 환경 설정, 재난대비시스템 관리인력 등 세밀한 부분까지 감안해야합니다. 재난대비시스템은 가급적 자동화되고 단순화된 환경을 만드는 것이 좋다고 생각합니다. 이러한 점에서 볼 때 하나의 장비에서 모든 프로세스가 자동으로 이루어지는 어플라이언스가 좋은 선택이 될 수 있습니다.’라고 조언합니다.

 

OS 패치만 달라도 재난대비시스템은 제대로 동작하지 않는다

2001년 9월 11일 오전9시 뉴욕 국제무역센터, 당시 미국의 기업 중 전산시스템 복구에 4일이상 걸린기업은 90%가 폐업한것으로 전해지고 하루 이상 걸린 기업 중에서도 많은 업체가 문을 닫았다고 합니다. 이후 재난대비시스템에 대한 관심이 높아지면서 많은 투자들이 이루어졌으나 정합성 불일치 등의 문제로 재난대비시스템의 정상적인 작동을 기대하기 어려운 경우가 많다고 합니다. 컴퓨터월드(2011.9.)에 따르면 재난대비시스템의 정합성에 문제를 일으키는 요인들은 패치버전의 불일치와 같은 아주 사소한 것인 경우가 많다고 합니다. 원격지 복제를 했는데 복제가 제대로 안 되고 있다거나, 복제를 해서 넘기려고 하는데 DB버전이 다르다거나, 하는 등의 사소함이 형식적인 모의훈련으로 인해 바로 시정이 되지 않고 있다는 것입니다.

주기적으로 대상 서버의 데이터는 물론 OS와 애플리케이션 까지 일치시켜주고 클릭 한 번으로 손쉽게 정상 동작 여부를 테스트해볼 수 있으며 강력한 장애서버복구성능(failback)을 가지고 있는 온큐에 많은 관심이 가는 이유입니다.

나는 돌았다

푸헐.. 뉴욕타임즈에 대충 이런 기사가 있네요..

시내 중심가 쇼핑몰 주자창 3층에서 쇼핑카트를 아래로 집어 던졌다고 하는군요.

또 어떤 12살 먹은 녀석들이 4층에서 쇼핑카트를 아래층으로 살포시 집어 던지는 일도 있었다고 합니다. (www.nytimes.com/2012/02/01/nyregion/hurled-shopping-carts-at-new-york-malls-worry-shoppers.html)

당연 아래쪽에 있던 수많은 사람들이 공포에 질려 안구들이 블링블링했답니다.

택도 없이 가당찮게 성질 부리는 사람들이 여기저기 많네요.

 

멀쩡하던 사람들에게 갑자기 내면의 그분이 나타나서 주변을 싸늘하게하는 경우가 왕왕 있는거 같습니다. 내 옆에 저 친구는 괜찮을려나..

오늘 아침에는 사무실에서 안하던 물구나무를 서던데…

혹시 서버실에 들어간다고 하면 말려야겠습니다…

 

휴먼웨어가 돌아버리면 온갖 보안시스템과 DR 체계가 무슨 소용이 있겠습니까..

A양 동영상과 백업의 위력

잊을만하면 터지는 유명인의 살색 진한 동영상이 삶의 활력(?)을 준다.

2012년 12월은 A양의 동영상이 음지의 박스오피스1위를 차지할 듯 하다.

지명도 있는 주연 여배우와 아주 낯선 남자조연을 캐스팅하고

비정규적으로 비주류 매체를 통해

발표되는 것이 이런 영상의 주요 특징이리라.

 

반면 O양과 오늘 아침 신문의 A양을 제외하면 별 기억이 나지 않는 것은

아마도 최고 보다는 최초와 최근만 기억하는 태음인(?, 혹은 O형?)의 특징인가보다..ㅋㅋ

 

사랑의 시간들을 백업하려고, 추억이라는 이름으로 복구하려고 한 것이 이런 사단을 불러온 걸 보면

백업의 위력을 새삼 느끼게된다.

사건과 행위(데이타)만 백업하지 말고 사람 까지,

속살을 부비던 아름답던 호모사피엔스까지

그대로 백업해두었다면 좋았을것을..

재해복구시스템은 제대로 동작하고 있는가?

다음은 컴퓨터월드(2011.9.) 기사를 가져온 것입니다.

———————————————–

요약

최근 은행권의 전산시스템 문제로 인한 서비스 중단사태 등으로 DR 시스템의 중요성이 부각되고 있다. DR시스템은 여러가지 이유로 전산 시스템에 장애가 발생할 때 업무의 연속성을 보장해 준다. 이런 이유 로 현재 금융권 등 민감한 정보를 다루고 있는 대부분의 업체들이 DR 시스템을 운용하고 있다. 그러나 정합성 등의 문제로 재해 발생 시 데 이터의 복구가 제대로 이루어지지 않는 등 문제가 많다는 지적이 제 기되고 있다. 정합성의 문제는 DR센터 내의 1·2차 데이터센터 간 네트워크 대역 폭 문제 및 전체 인프라의 정합성을 비교할 수 있는 방법이 없다는 데 있다. 사실 DR시스템의 문제를 일으키는 요인들은 패치 버전의 불일 치와 같은 아주 사소한 것인 경우가 많다. 농협 사태와 같은 경우도 DR시스템을 제대로 갖춰 활용했다면 그와 같은 일 은 벌어지지 않았다는 게 전문가들의 지적이다. 한편 지난 2000년을 전후로 국내 각 금융기관을 비롯한 정부 부처, 그리고 대다수의 대기업들은 수억 원의 자금을 투 자해 재해복구 시스템을 구축한 바 있다. 그러나 재해복구 시스템을 제대로 운영 및 관리하는 곳은 그렇게 많지 않다는 게 현실이다. 심지어 어떤 금융기관은 재해복구 시스템에 있는 서버를 빼서 다른 용도로 전용 하기도 했다고 한다. 더욱 이 재해복구 관리직은 한직으로 생각해 업무를 서로 맡지 않으려는 경향이 짙어 재해복구 시스템은 그야말로 허울뿐이 라는 것이다. 우리나라는 어떤 사건이 터져야만 호들갑을 떨면서 대응책 마련에 급급하다. ‘사후약방문’이겠지만 그것 만이라도 제대로 한다면 어떤 사건이 터져도 크게 문제 될 게 없을 것이다. 수억 원을 투자해 구축해 놓은 재해복구 시 스템을 제대로 활용할 방안부터 마련하는 게 우선이다.

 

시스템복구 늦어지면 회사 문 닫을 수도

금융권을 비롯해 일정 규모 이상의 기업, 특히 민감한 정보를 다루는 기업들은 대부분 DR시스템을 구축해 재 해발생 등 만일의 사태에 대비하고 있다. 이런 DR시스템 구축에는 고가의 장비들이 사용되기 때문에 엄청난 비용 이 들어간다. 그런데 이런 DR시스템이 관리의 문제로 인 해 제 기능을 다하지 못한다는 지적이 제기되고 있다. 최근 발생한 금융권의 잇따른 사고들의 1차적인 원인 은 보안이었다. 하지만 사고 발생 후 DR시스템을 이용해 빠른 시간 안에 복구되었어야 함에도 그렇지 못한 경우가 많았다. DR시스템이 제 기능을 못한 것이다. DR시스템이 필요한 때에 제 기능을 하지 못한 이유로업계 관계자들은 데이터센터 간의 정합성 불일치를 들 고 있다. 1차 데이터센터와 2차 데이터센터 간의 구성환 경 및 데이터의 정합성이 일치해야 복구가 가능한데 두 데이터센터 간의 오차로 인해 정합성의 문제가 발생해 데이터의 복구가 어려웠다는 것이다. 2001년 9월 11일에 발생한‘911미국대폭발테러사건’ 은 DR시스템 구축에 대한 필요성을 인식하는 계기가 되 었다. 당시 미국의 기업 중 전산시스템 복구에 4일 이상 걸린 기업은 90%가 폐업한 것으로 전해진다. 하루 이상 걸린 기업 중에서도 많은 업체가 문을 닫았다고 한다. 이처럼 기업의 전산시스템 복구 문제는 회사의 존속과 직결되는 민감한 사항이다. 그러나 국내에서는 이에 대 한 인식이 부족하다는 지적이다. 이에 따라 금감원은 RTO(복구목표시간 : Recovery Time Objective)를 3시 간으로 규정하는 등 DR시스템에 대한 가이드라인을 구 체화 하며 문제해결에 적극 나서고 있다. DR시스템은 두 데이터센터 간에 패치 버전, 디렉토리 구조 하나만 달라도 복원이 불가능 하다. 그렇기 때문에 지속적인 관리를 통해 두 데이터센터 간의 정합성을 유 지시키는 게 무엇보다 중요하다. DR센터가 구축된 2000년 대 초기에는 시스템에 저장되는 데이터의 양이 적어 수작업으로도 정합성을 유지할 수 있었다. 하지만 데이터의 양이 폭발하면서 DR센터의 규모 또한 커지자 그 동안의 방법으로는 정합성 유지가 힘들어지게 됐다.

 

정합성 불일치가 문제

정합성을 유지하지 못하는 이유는 크게 ▲수작업을 통한 정합성 유지 ▲네트워크 인프라 취약 ▲DR센터에 대한 관심 부족 등을 들 수 있다. DR시스템의 데이터센터 간 정합성 검사는 스토리지, 서버, DB 등의 영역에서 정밀하게 이루어진다. 하지만 인프라 전체에 대한 정합성 검사는 이루어지지 않고 있 다고 한다. 많은 문제가 이런 인프라 사이의 관계에서 발생하지만, 기존 수작업을 통해서는 이 부분에 대한 정 합성을 확인할 방법이 없었다고 한다. 예를 들면 스토리지를 추가할 경우 1차 센터와 2차 센 터 간 동일한 스토리지를 추가한다. 하지만, 추가 후 장 착된 스토리지가 같은 모델인지, 같인 구조로 구성이 되 었는지 확인이 어렵다는 것이다. DR센터의 규모가 작을 때는 관리자가 이러한 관리를 할 수 있지만 규모가 일정 이상이 되면 불가능하다. 또한 네트워크와 관련된 문제 도 있다. 데이터를 저장하는 것이 주목적인 DR센터는 당연히 스토리지, 서버, DB 등이 중요시 된다. 상대적으 로 두 데이터센터를 연결하는 네트워크의 중요성은 소 홀하기 쉽다. 이런 이유로 네트워크 업그레이드 부분을 간과하는 경우가 많다는 것이다. 그 결과 대역폭의 부족 으로 데이터센터 간 전송되는 데이터를 제 시간에 전송 하지 못하는 문제가 발생한다. 전송이 완료되더라도 적 정 RPO(복구목표시점: Recovery Point Objectives)인 5분을 넘기게 된다. 이처럼 DR센터 관리에 문제가 발생하고 있지만, 기업 들은 이에 대한 인식이 부족한 실정이다. DR센터는 문 제가 생겨야 진가를 발휘하는 데 문제가 발생하지 않을 경우 돈만 들어가는 시스템으로 인식되는 것이다. 당연 히 DR센터 시스템 확장에 소극적이 되고, 특히 예산 부 족을 이유로 네트워크 업그레이드는 거의 생각조차 않 는 경우가 많다고 한다. 업계 관계자는“2000년 대 초 금감원의 지침에 따라 은행권에서 DR센터를 구축했지만, 사용되는 곳이 없어 그 중요성을 제대로 인식하지 못하고 있다. 특히 시스템 에 문제가 생겨 발생하는 손해비용이 DR시스템을 구축 하고 유지하는데 드는 비용보다 적어 DR시스템을 소홀 히 하는 경향이 있다”며“DR시스템 구축은 회사의 신뢰 성과 직결되는 등 직접적인 비용으로 설명할 수 없는 부 분이 있는데, 이 부분에 대해서는 생각하지 않는다”고 지적했다.

 

형식적인 모의훈련은 무의미

DR시스템의 정합성을 유지하기 위해서는 부분별 비 교와 함께 인프라 전체를 비교할 수 있는 통합 모니터링 솔루션이 필요하다. 아직까지 국내에는 DR센터 전체 인 프라에 대한 정합성을 검사할 수 있는 방법이 없는 것으로 전해진다. 기존에는 DR센터 규모가 통합 모니터링 솔루션이 필요할 수준이 아니었기 때문에 괜찮았지만, 이제는 솔루션을 이용하지 않고서는 인프라 전체에 대 한 정확한 정합성 검사가 어렵다고 한다. 인프라 전체에 대한 정합성 검사를 할 수 있는 방법을 찾아야 한다는 얘 기이다. 업계 관계자들은 DR시스템에 대한 형식적인 모의훈 련도 문제점이라고 지적했다. 금융권 DR의 경우 업무의 특성상 모든 시스템을 대상으로 DR훈련을 실시할 수 없 고, 사전에 마련된 계획에 따라 진행된다는 것이다. 이런 모의훈련으로는 돌발 상황에 적절히 대처할 수 없다는 것이다. 또한 모의훈련 때 정합성이 일치하더라도 데이 터와 환경은 지속적으로 바뀌기 때문에, 조금만 시간이 지나면 데이터센터의 정합성 여부를 장담할 수 없다고 한다. 한 관계자는“중국에서는 전산시스템의 안정성을 보 여주기 위해 은행의 주요 고객을 대상으로 시스템 전체 를 다운시키고 몇 시간 안에 복구시킬 수 있는지를 보여 준다. 중국이라는 특수성 때문에 할 수 있는 퍼포먼스 일 수 있지만, 국내 DR센터의 모의훈련과 비교되는 부분이 다”며“정말 돌발 상황에 대비하기 위한 모의훈련이라면 중국처럼 모든 시스템을 다운시킨 후 복구시켜야 하며, 또한 사전에 강조했다.

 

사소한 문제가 취약점의 원인

DR과 관련 컨설팅 전문업체인 인포트릭은 금융기관 한 곳과 해운업체 한 곳을 각각 컨설팅을 한 바, 두 곳 모 두 정도의 차이는 있지만 취약점이 발견되었다고 한다. 대표적으로 클러스터 내에서 스토리지 공유의 불완전함 과 DR시스템의 가동시스템 간의 로그인 셀 및 DB 홈 디 렉터리 설정이 서로 다른 점이 발견됐다는 것이다. 스토리지 공유의 경우 볼륨을 찾아 다시 업데이트를 하면 해결될 문제이지만, 이 과정에서 시스템의 재부팅 을 해야 하고 결과적으로 RTO와 RPO가 늘어나게 된다 는 것이다. 로그인 셀 및 홈 디렉토리 역시 마찬가지다. 사소한 문제지만 이런 사소한 문제가 모여 결국 적정 RPO를 초과하는 원인이 되는 것이다. 문제는 모두 두 번씩 작업을 하게 돼 그만큼 시간과 비 용 낭비는 물론 고객들에 대한 서비스에도 큰 차질을 빗 게 된다는 것이다. 인포트릭의 한 관계자는“장애 발생 의 원인은 대부분 사소한 데서 시작된다. 리모트 복제를 했는데 복제가 제대로 안 되고 있다거나, 복제를 해서 넘 기려고 하는데 DB버전이 다르다거나. 또는 OS패치가 빠져있는 등 알기만 하면 모두 해결 가능한 것들이다”고 지적했다. 또한 그는“이런 사소한 문제들은 사람이 파 악하기가 힘들지만 방법은 얼마든지 있다. 문제는 해결 을 하려는 의지와 있는 자원을 제대로 활용하려는 인식 이다”고 주장했다.

재해복구시스템에 투자가 필요한 이유

전자신문(2012.5.20)에서 가져왔습니다.

—————————————————-

EMC가 지난해 6월 IDC에 의뢰해 발표한 `디지털 유니버스 보고서`에 따르면 2011년 한해 생성 및 복제된 디지털 정보량이 약 1.8제타바이트(ZB)에 이르는 것으로 조사됐다. 세계 디지털 정보량은 매 2년마다 2배씩 증가해 2020년에는 현재의 50배로 증가할 것으로 전망됐다. 이러한 `데이터 빅뱅` 시대는 기업 데이터 관리에 새로운 패러다임을 요구한다. 데이터 관리의 효율성과 안전성이 기업 경쟁력과 직결되기 때문이다.

하지만 데이터는 각종 바이러스나 하드웨어 고장 및 소프트웨어 장애, 관리자의 실수, 자연재해 등의 요인에 매우 취약하다. 유실될 우려도 매우 높다. 따라서 오늘날 기업들이 데이터 관리와 관련해 직면하고 있는 가장 큰 이슈 중 하나는 비즈니스 연속성과 매출 증대를 위한 정보 관리와 보호다. 기업 정보시스템이 어떠한 원인으로 작동을 멈출 경우, 서비스 중단으로 고객 불신을 초래할 뿐만 아니라 기업 생존까지 위협하는 원인으로 발전할 수 있기 때문이다.

◇국내 기업 재해복구계획 수립 필요성 못느껴=비즈니스 연속성 체계는 백업과 같은 단순 복구 수단 도입만을 의미하지는 않는다. 고객 서비스의 지속성 보장, 핵심 업무 기능을 지속하는 환경을 조성해 기업 가치를 극대화하는 것을 의미한다. 기업 입장에서는 언제 발생할지 모를 예측 불가능한 위기상황에 대비해 비즈니스 연속성 보장을 위한 재해복구(DR)시스템 구축에 선뜻 투자하기가 쉽지 않다. 하지만 위기발생 후 직면하게 될 충격과 파급효과, 수습비용까지 고려한다면 투자가치는 매우 높다.

문제는 국내 기업들이 여전히 백업 및 DR시스템 구축에 제대로 투자를 하지 않고 있다는 점이다. EMC가 국내 제조, 통신, 금융, 공공, 의료 등 산업별 250여기업을 대상으로 실시한 설문조사에 따르면, 작년 한해 동안 절반 이상인 55%가 데이터 손실과 시스템 다운타임을 경험한 것으로 나타났다. 또 기업의 93%가 `재해시 완벽하게 시스템 및 데이터를 복구할 수 있다`는 확신을 갖지 못하는 것으로 나타났다. 이는 81%인 아태지역 기업 평균과 비교해 우려할 만한 수준이다.

대부분 기업들이 재해에 따른 완벽한 시스템 및 데이터 복구에 어려움이 있음을 높게 인식하고 있었다. 하지만 백업 및 복구 IT 예산 할당(8.42%)은 아태지역 기업들의 평균(10.48%)과 비교해 낮게 책정돼 있었다. 더욱 주목해야 할 결과는 `재해 복구 계획 수립이 필요하다`라고 응답한 기업은 39%에 불과해 아태지역 기업 평균(55%) 수준에도 못 미치는 것으로 나타났다.

다시 말해 국내 기업들은 데이터 손실 관련 재난과 자연재해에 크게 노출되고 있음에도 불구하고 방재 능력은 매우 취약하다는 얘기다.

 

◇백업 인프라도 가상화 소프트웨어와 연계돼야=현재 많은 국내 기업들은 재난재해를 비롯해 예산 부족, 데이터 폭증 등 다양한 비즈니스 도전과제에 직면해 있다. 여기에 가상화된 클라우드와 고성능 애플리케이션 도입이라는 IT 환경 변화까지 동시에 맞닥뜨렸다. 전통적 테이프 중심 백업 및 복구 방식으로는 이와 같은 비즈니스 문제를 해결하기는 역부족이다.

점차 도입이 늘고 있는 가상화 기술은 물리적 서버 자원의 효율성을 극대화한다. 하지만 전통적 백업 인프라로는 가상 환경 데이터의 백업이 불가능한 상황이다. 운영 인프라와 동일하게 백업 인프라도 가상화 소프트웨어와 백업 및 운영기능 통합이 전제돼야 실질적인 백업과 복구가 가능하다.

또 백업 인프라는 데이터베이스, 메시지, 콘텐츠, 전사자원관리(ERP) 등 다양한 애플리케이션과의 애플리케이션프로그래밍인터페이스(API)를 통한 사전 통합 기능도 고려해야 하는 상황이다.

◇DR 계획 수립이 기업 생존율 높여=미국 IT전문지 컴퓨터월드 조사에 따르면 재해 발생으로 인해 24시간 넘게 정보 데이터에 접근하지 못하는 기업들은 1년 후 생존율이 0%에 가까운 것으로 나타났다. 또 IT 재해대비 계획을 세우고 있는 기업은 그렇지 않은 기업보다 4배 이상 생존율이 높은 것으로 조사됐다. 기업 경쟁력 확보에 IT DR시스템이 결정적인 역할을 하고 있음을 보여준다.

이 이사는 “지속가능 경영을 위해서는 현실성이 가미된 업무 연속성 보장 및 DR 정책을 마련하고 체계적인 운영과 문제에 대응 할 수 있는 항시 대응체계를 갖추어야 한다”고 강조했다. 그는 이런 대응체계에는 플랫폼과 데이터, 애플리케이션, 그리고 원격 사이트까지 아우르는 각 단계별 안정성 확보 기술이 필요하다고 덧붙였다.

데이터 빅뱅 시대 불의의 재난으로 인한 피해는 물리적 인프라보다 복구가 어려운 데이터의 경우 더욱 치명적이다. 재난재해로 인한 IT 인프라의 피해를 최소화하고 지속적인 기업 활동을 보장하기 위해서, DR시스템에 대한 올바른 정보 공유와 적극적인 투자가 필요한 시점이라고 전문가들은 강조한다.