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

지난 수 년 간 많은 자연재해들이 신문의 헤드라인을 장식했으며 그 피해들도 어마어마했습니다. 많은 생명들이 사라지고 보금자리가 파괴되는 가운데 기업들의 생존 또한 위협받게됩니다. 미시시피주의 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)을 가지고 있는 온큐에 많은 관심이 가는 이유입니다.