다이하드 의료정보시스템

점점 더 심해질 것으로 많이들 예견하고 있습니다만 전세계적으로 많은 기상이변들이 일어나고 있습니다. 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)을 가지고 있는 온큐에 많은 관심이 가는 이유입니다.

댓글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다.

다음의 HTML 태그와 속성을 사용할 수 있습니다: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>