시스템의 회복 능력

시스템의 회복 능력

여기에서는 다음의 내용들에 대하여 알아본다.

• 회복 능력(Resiliency)이란
• 가용성 측정
• 시스템 다운 측정
• 잘못될 수 있는 환경적인 부분

일반적으로 회복 능력을 '고 가용성(high Availability)'라는 용어와 비슷하게 생각을 한다. 그러나, 실제로는 고 가용성이 갖는 여러 의미 중 하나가 바로 회복 능력이 된다. 이것은 고 가용성이 회복 능력을 포함한다는 의미이다. 즉, 고 가용성이 회복 능력보다 상위 개념이라는 뜻이다.

고 가용성은 서로의 상태를 확인(Monitor)하고 보호(Protect)하는 두 시스템을 연결을 시키고 이와 시스템설정과 관련된 상당히 제한적인 범위를 말한다.

그러나, 최근에는 회복 능력과 고 가용성이란 의미를 거의 비슷하게 사용한다. 여기에서는 이 두가지 의미를 '네트워크 및 응용프로그램을 포함한 모든 시스템 고장'을 얼마나 빠른 시간 안에 복구 할 수 있는가와 같은 기준으로 설명이 된다.

일반적으로 시스템에 문제가 발생하여 다운이 되었다면, 정확한 고장원인이 분석되어야 하며, 바른 시간에 복구 할 수 있는 복구(Recovery) 방법에 대해서도 알고 있어야 한다. 그리고, 복구를 할 수 없을 때를 대비해서 백업 계획도 세워야 할 것이다. 그러나, 회복능력을 갖춘 시스템 이라면 중요한 부품에 문제가 생겨도 빠른 시간 안에 원 상태로 복구가 되게끔 준비가 되어 있어야 할것이다.

[1] 가용성의 측정

프로젝트 책임자나 여러 구성원들과 가용성의 제반조건에 대해 논의할 때, '우리가 진행하고 있는 프로젝트는 매우 중요한 것이므로 절대로 시스템이 다운되어서는 안된다'면서 100% 완벽한 가용성을 요구하는 경우가 있다. 하지만100%의 가용성을 달성하기 위해 수반되는 비용이 엄청나다는 것을 알면 이러한 요구는 수그러들게 되며 가용성은비용과 협상의 문제가 되게 마련이다.

[표1]에서 보면, 대부분의 응용프로그램은99%정도의 가용성만으로도 충분하다. 시스템다운 시간이 일주일에 1시간30분 가량이라면 그것은 만족할 만한 것이다. 물론 시스템다운의 시간대가 매우 중요하지만, 목요일아침 10시에서 11시 30분 또는 오후 2시에 15 ~ 20분 가량이 다운보다는 일요일새벽 3시부터 4시 30분까지의 시스템다운이 휠씬 더 대수롭지 않게 넘어 갈 수 있는 문제이다.

'어느 시간대에 100%의 가용성을 달성 할 수 있는가?'의 문제는 협상의 한 요소이다. 하루에 수 시간 동안만 필요하다면 그 목적은 충분히 달성 가능하다. 예를 들어, 부동산 중개업자가 오전 9시 30분부터 오후 4시까지 영업을 한다면 그 시간 동안 만큼은 100%의 안정성을 보장해 주어야 한다. 또 한 예로 신문사의 경우 신문 발행시간 외의 나머지 시간에는 굳이 100%의 안정성이 요구될 필요는 없는 것이다. 만약 365일 * 7*24시간 동안 100%의 안정성을 원한다고 해도 엄청난 비용이 소요되기 때문에 가장 높은 이윤을 내는 사업체나 대기업만이 이러한 가요성을 고려해 볼 수 있을 것이다.

가동 시간 비율	다운 시간 비율	연간 다운 시간	주당 다운 시간
98%	2%	7.3일	3시간 22분
99%	1%	3.65일	1시간 41분
99.8%	0.2%	17시간 30분	20분 10초
99.9%	0.1%	8시간 45분	10분 5초
99.99%	0.01%	52분 30초	1분
99.999%	0.001%	5분 25초	6초
99.9999%	0.0001%	31.5초	0.6초

[표1] 가용성 측정

가용성 단계가 높아질수록 그에 따른 비용 또한 급격히 증가하게 된다. 서버의 예를 보자. 'abbott'서버는 데이터 유실을 막기 위한 디스크 미러링과 백업 장치를 제외하면 시스템 문제를 대비한 다른 장치를 갖추지 않아 99%의 가용성을 가진다. 만약 abbott 서버에 문제가 생겼을 때 abbott 서버를 대신 할 수 있는 'costello' 서버를 갖추더라도 가용성은 여전히 99%이다. 어떤 이는 2대의 서버로 운영을 하기 때문에 서버의 가용성은 99.99%가 되는 것이 아니냐고 반문할 수 있다. 수학적으로 abbott에 문제가 생기는 1%와 costello의 99%를 곱하고, 이 두 서버를 함께 쓰면 0.99%가 향상되어 costello는 abbott의 문제가 되는 1%의 가용성에만 사용될 것이므로 이론적으로는 두 개의 연결된 시스템으로 99.99%의 가용성을 얻을 수 있을 것처럼 보인다.

하지만 단순히 두 개의 통합된 서버를 운영한다고 해서 실제로 99.99%의 가용성을 얻을 수 있는 것은 아니다. 가용성은 선형적으로 증가하지 않으며, 일명 페일오버(Failover)라 불리는 스위치 오버(Switch over)에 걸리는 시간과 관련된 문제이다. 게다가 네트워크 연결 문제나 전원 부 현상 등의 외적장애 요인도 큰 비중을 차지하며, 두 개의 서버에 접속하는 것과 관계된 이러한 문제들은 전반적인 가용성 수치를 믿을 수 없을 정도로 떨어드릴 것이다.

표에서 알 수 있듯이 위험 요소를 한 단계 낮추려면 5~10배의 비용이 들고 표에서 아래쪽으로 내려 갈수록 지불해야 하는 비용도 기하 급수적으로 증가하게 됨을 알 수 있다.

[2] 서버 다운의 정의

다운이라는 말은 여유 있는 상황에서부터 긴박한 상황까지, 또 단순한 의미에서부터 복잡한 의미까지 다양하게 사용된다. 가장 흔한 다운의 정의는 서버 자체나 디스크, 네트워크, 운영체제, 주요 응용프로그램등의 서버를 이루고 있는 구성 요소에 문제가 생겼을 때를 말한다. 반면 엄밀히 따져보면 서버 및 네트워크의 속도 저하, 백업 시스템의 고장, 일부 데이터를 읽을 수 없는 상황도 다운에 해당된다. 이 책에서는 '사용자가 예정된 시간 안에 작업을 마칠 수 없을 때, 이를 시스템 다운으로 정의한다.' 라는 엄밀한 의미의 다운에 대해 논의하고 있다.

시스템은 사용자가 원하는 작업을 효율적인 방법으로 적절한 시간 안에 처리해 주어야 하며, 어떤 이유에서든지 컴퓨터가 이 같은 역할을 제대로 할 수 없다면 그 컴퓨터는 다운된 것으로 볼 수 있다.

2-1. 다운의 원인

[그림1]은 시스템 다운을 일으 킬 수 있는 여러 원인을 보여주고 있다. 그래프에서 가장 많은 비중을 차지하고 있는 것은 예정된 다운(Planned Downtime)이다. 예정된 다운이란 시스템 관리자가 서버의 중요 부품이나 중요한 소프트웨어를 업그레이드하기 위해 일부러 시스템을 중단하거나, 때로는 로그 파일을 지우거나 임시 디렉토리와 메모리를 정리하기 위해 시스템을 재부팅 하는 경우이다. 이 같은 예정된 다운은 쉽게 줄일 수 있다.

요즘은 시스템 관리를 위해 일부러 시스템을 멈추지 않아도 된다. 핫 플러깅(Hot pulling)을 활용해 시스템을 재부팅 하지 않고도 디스크 드라이브를 설치 할 수 있으며 시스템을 운영하면서도 작업을 할 수 있다. 또한 대부분의 주요 소프트웨어 업그레이드 역시 서비스를 중지하지 않고도 가능하다. 물론 모두 그런 것은 아니다. 나중에 좀더 자세히 다루겠지만 안정적인 환경은 시스템을 두 개로 구성하거나 클러스터로 구성하여 작업을 멈추지 않고도 시스템을 업그레이드 할 수 있다. 하나의 시스템이나 클러스터를 업그레이드 하는 동안 다른 시스템이 대신 수행하고, 업그레이드가 끝나면 다시 시스템을 복구하여 나머지 시스템을 업그레이드 한다. 시스템 작업은 오직 작업을 바꾸는 과정 중간에만 잠깐 중단될 뿐이다. 현재 대부분의 제조사에서는 자사의 디스크나 저장장치 및 볼륨(Volume) 관리 소프트웨어를 어떤 상황에서도 시스템 중단 없이 작업 할 수 있도록 자료의 형태나 양을 온라인으로 관리할 수 있게 제품을 생산하고 있다.

[그림1] 다운 원인(자료: IEEE Computer 1995년 4월)

시스템 다운의 또 다른 큰 원인은 바로 사람이다. 사람들은 밀접하게 연관된 두 가지 이유로 인해 시스템 다운을 야기한다. 첫 번째 이유는 사람들의 부주의나 직무 태만으로 인한 실수이며, 두 번째는 시스템 운영 방법을 완벽하게 숙지 하지 않아서 생기는 문제이다. 이렇게 사람으로 인한 시스템 다운을 예방할 수 있는 방법은 지속적인 교육과 기능적이고 간단한 시스템 구성에 있다. 최신 기술 습득을 위해 시간을 할애하여 운영자들을 교육시키고, 그에 맞는 완벽한 설명서를 익히게 하면 사람으로 인한 시스템 다운은 크게 줄일 수 있을 것이다.

[그림1]에서 가장 놀랄 만한 것은 하드웨어의 비중이다. 시스템 다운의 원인 중 하드웨어로 인한 것은 오직 10%정도 이다. 이는 최고의 RAID 디스크 시스템과 대체 네트워크가 시스템 다운 원인 중 단지 10%만 해결 할 수 있다는 의미이다. 사실 디스크 문제, 네트워크의 고장 외에 전원 공급장치, CPU 및 메모리 문제, 내부 냉각 시스템 고장 등의 하드웨어 불량으로 일어나는 시스템 다운은 10%에 머문다.

시스템 다운의 가장 큰 원인은 소프트웨어 문제일 것이다. [그림1]에 따르면 소프트웨어로 인한 시스템 다운은 40%나 된다. 소프트웨어의 버그는 시스템 안정성을 다루는데 있어 가장 해결하기 힘든 부분일 것이다. 하드웨어가 보다 안정적인 부품으로 교체되고 예정된 다운을 감소시키기 위한 방법을 취함으로써 이와 관련된 문제점은 감소되겠지만, 상대적으로 소프트웨어로 인한 다운이 비중은 더욱 증가하게 된다. 또한 소프트웨어가 점점 더 복잡해지면서 소프트웨어 자체 문제로 인한 장애가 더 많이 발생 할 수 있다. 물론 소프트웨어 개발이나 디버깅 기술 또한 이에 발맞추어 발전해 감에 따라 소프트웨어 관련 문제가 줄어들 수도 있다. 소프트웨어로 인한 시스템 다운이 증가할 것인지 아니면 감소할 것인지 시간을 두고 지켜보는 것은 매우 흥미로운 일일 것이다.

2-2. 가용성이란 무엇인가 ?

간단히 말하면 서버의 가용성의 높 낮음이나 중간 단계인지 등에 상관없이 그 상태와 무관하게 서버와 정상적으로 동작하는 시간의 단위이다. 가용성을 계산할 수 있는 다음과 같은 간단한 공식을 보자.

[그림2] 가용성을 구하는 식

여기서 A는 가용성을 퍼센트로 나타낸 것이다. MTBF는 Mean Time Between Failures, MTTR은 Mean Time To Recover를 의미한다. 여기서 주목해야 할 부분은 다음과 같다.

• MTTR이 0이 된다면 A는 100%가 된다.
• MTBF가 커질수록 MTTR이 A에 끼치는 영향력은 작아진다.

예를 들어, 어떤 시스템의 MTBF가 100,000시간이고, MTTR이 1시간이라면 앞의 공식에 따라 이 시스템의 가용성은 99.999%가 된다. 만약, 이 시스템의 MTTR을 앞에 나온 예의 10%에 지나지 않는 6분으로 낮춘다면 이 시스템의 가용성은 99.9999%가 될 것이다. 하지만 경우 6분 동안만 다운되는 정도의 가용성을 달성하기 위해서 11년도 넘는 100,000시간 동안 지속적으로 동작할 수 있는 부품을 써야 하는 것이다.

앞의 내용에 따르면 99.9999%의 가용성을 이루기 위해서는 11.4년 동안 고작 6분간만 다운되어야 한다. 그러나, 서버는 한 개의 부품이 아닌 여러 개의 부픔으로 이루어져 있다. 결국 99.9999%의 가용성을 이루기 위해서는 전체 부품이 11.4년 동안 통틀어 6분간만 고장이 나야 한다는 말이다. 현 기술을 놓고 볼 때 이는 매우 비현실적이며 달성 불가능한 이야기이다. 현재로선 1년에 최대 10분 정도의 다운 타임(약 99.998%)이라면 가능할 수도 있겠지만, 이것도 그리 쉽지는 않다. 또한 잘 설계된 시스템뿐만 아니라 상당한 운이 따라야 하지만, 운을 기대하고 계획을 수립할 수는 없는 일이다.

운은 매우 다양하다. 회사의 최고 개발자가 밤늦도록 응용프로그램을 개발하다가 중요한 서버를 다운 시켰지만 곧바로 복구 했다거나, 수도관에서 물이 새어 미러링 디스크가 젖었음에도 불구하고 다른 영역에는 별다른 피해를 입지 않았을 때 이것을 행운이라고 할 수 있겠다. 반대로 불운이란 데이터 센터 주변을 어슬렁거리던 사람이 우연히 생산라인 서버의 전원 스위치에 기댔다거나, 지나가던 차가 갑자기 돌진해서 회사에서 사용하는 전기를 공급하는 전봇대를 들이 받는다거나 전기 공사를 위해 땅을 파헤치다가 여러분이 쓰는 광케이블을 건드렸다는 불운을 만났다고 할 수도 있다.

2-3. 'M'의 의미

MTBF의 핵심은 평균 시간이다. 시스템에 고장이 생길 때까지 걸리는 평균 시간은 단순히 평균을 의미한다. 디스크 드라이브의 MTBF가 200,000시간, 즉 거의 23년 정도라고 해서 모든 공장에서 생산된 디스크 드라이브가 정확하게 23년 동안만 제대로 돌다가 갑자기 멈춘다고 할 수는 없다. 이는 마치 미국 정부가 평균 수명을 발표할 때, 모든 미국인이 79.6년을 살면 죽는다는 의미가 아닌 것과 같다. 어떤 사람은 50살도 넘기지 못하는 반면 또 어떤 사람은 놀랍게도 100년을 살기도 하는 것이다.

M은 평균적인 추세를 의미한다. 일정 기간 동안 작동하는 디스크를 볼 때, 평균적인 디스크 드라이브의 기대 수명 기간이 23년이라는 것이다. 물론 어떤 디스크는 동작하자마자 바로 고장 나는 경우도 있으며 또 다른 디스크는 40년 동안 아무런 공장 없이 돌아가는 것도 있다. 이는 500개 정도의 디스크가 장착된 대형 서버의 경우 평균적으로 200,000/500(매 400시간)마다 이 서버의 디스크가 고장 날 것이라는 의미도 된다. 400시간이란 16.5일 이므로 이럴 경우 평균 2.5주마다 디스크를 교체해야 한다.

통계적인 평균만으로 특정 집단을 설명 할 수 없다. 예를 들어 8,9,10,11,12의 평균 값은 10이다. 한편 1,1,1,1과 46의 평균도 10이다. 12,345, -12,345, 47,000,000, -47,000,000, 50의 평균 역시 마찬가지이다.

또, 다른 핵심 요소는 표준 편차(Standard Deviation) 또는 시그마(Sigma)이다. 길고 지루한 표준 편차의 설명은 그만 두고 라도 시그마는 집단에서 각 변수들이 평균에서 어느 정도로 떨어져 분포해 있는 지를 말해준다. 앞의 세 가지 예에서 시그마(Sigma)는 1,414214, 19.6과 29,725,411이다.

완벽한 이해를 돕기 위해 하나의 예를 더 들어 보겠다. 9.99, 10.01, 9.999, 10.002, 9.999의 평균은 여전히 10이다. 그리고, 이 집합의 각 원소들이 평균과 비슷하게 배치되어 있다면 시그마 값이 작아진다는 것을 보여주고 있다. 또, 달리 표현하면 시그마 값이 작다는 것은 각 원소들이 평균치에 근접해 있다는 것을 의미한다.

따라서, 여러분은 MTBF 요소들이 낮은 편차를 가지고 있기를 원할 것이다. 하지만 제조사에서는 이런 수치가 MTBF의 중요한 요소임에도 잘 알려지지 않는다. 여러분이 이런 정보에 대해 요구한다면 제조사들은 이런 정보대신 자사 제품의 성능에 대한 정보만 줄 것이다.

MTBF에 적용되는 지침이 MTTR에도 동일하게 적용된다. 만약 특정 문제가 발생했을 때 관리자가 이를 복구하는 데 15분이 걸렸다고 해서 매번 15분이면 문제를 복구할 수 있다는 의미는 아니다. 복구 작업의 난이도에 따라 시간 역시 다르게 소요되기 때문이다. 또한 사람이 바뀐다면 그 사람은 새로 와서 현재 시스템에 대해 잘 알지 못하므로 복구 시간은 더 길어지게 된다.(반대로 관리자가 오랫동안 같은 시스템을 다루다 보면 특정 문제에 잘 적응하게 되어 복구하는 데 걸리는 시간을 줄일 수도 있다.) 또한 부팅할 때 체크되는 시스템의 하드웨어가 추가됨에 따라 시스템 전체를 재 부팅하는 시간 역시 증가 할 수 있다.

MTTR을 조절할 수 없을 때도 많다. 예를 들어, 시스템에 중요한 부품이 고장 나서 제조사에 이 부품을 요청했을 때 실제로 여러분에게 배달되기까지 몇 일 혹은 몇 주가 걸려도 이는 여러분이 어떻게 할 수 있는 일이 아니다. 게다가 대체 부품이나 이 부품을 받을 수 있는 다른 제조사가 없다면 여러분이 관리할 수 있는 일은 시스템이 다운된 채로 기다리는 일 밖에 없다. 또한 대부분 시스템 관리는 네트워크 관리와 별개의 작업 이고, 전혀 다른 조직에 의해 그 임무가 찾아내 해결할 때까지 마냥 기다리는 부밖에 없다.

일반적으로 허용되는 시스템 다운 시간은 요구되는 가용성의 단계에 따라 결정된다. 일반적으로 대부분의 사용자의 경우 지역 전화망 고장에 대해서는 알 수 없다. 이는 대부분의 전화 사업자들이 전화 서비스에는 별다른 문제가 일어나지 않도록 조치를 취해 둔 뒤에 선로 업그레이드 등의 작업을 하기 때문이다. 전화 네트워크의 허용 가능한 다운은 초를 다투는 수준이다.

상거래에 있어서는 몇 분 정도의 문제는 허용된다. (항상 그런 것은 아니지만) 일반적으로 실시간 거래를 주요시하는 주식거래에서는 2분 안에 거래가 종료된다. 시장은 매 초마다 매우 빠르게 변하므로 순식간에 이윤이 달라지기도 한다. 일부지만 그리 중요한 거래가 아닐 경우에는(물론 이는 시장 상황에 따라 다르다) 하루나 이틀가지 거래가 밀려 있어도 된다. 여러분은 시스템 가동이 중단되는 것이 어떤 것인지 정확하게 이해하고 있어야 한다. 그리고 이에 따라서 정확하게 시스템을 설계하고 비용을 지불해야 한다.

때때로 사용자들은 공식에 대입하는 것을 좋아하는 경우가 있다. 사용자들이 문제가 발생한 시스템을 고치는 데 1시간이 소요된다고 가정 했을 때, 만약 여러분이 이를 20분 만에 고쳤다면 여러분은 영웅 대접을 받을 것이다. 하지만 반대로 10분이면 고칠 수 있을 것으로 생각했던 문제를 여러분이 20분만에 고친다면 여러분은 비난 받을 것이다. 따라서 사용자들이 1시간이면 고칠 수 있을 것이라고 믿고 있다면 여러분도 정확히 1시간 뒤에 수리를 마치면 된다.

[3] 고장을 일으키는 부분

이 부분에서는 컴퓨터 시스템에 있어 잘못되거나 고장을 일으킬 수 있는 원인에 대해 살펴볼 것이다. 이 원인들 중에는 하드웨어 처럼 정확히 원인을 찾아낼 수 있는 것도 있지만 그렇지 않은 것들도 있다.

3-1. 하드웨어

하드웨어의 고장은 그 원인을 정확히 찾아 낼 수 있다. 그러나, [표1]에서 보듯이 실제 하드웨어로 인한 시스템 고장은 전체의 10%에 지나지 않는다. 일단 하드웨어에 문제가 생겼을 경우 대부분의 사람들이 고장 난 하드웨어를 대체할 부품을 가지고 있지않으므로 시스템은 오래도록 다운되어 있기 마련이다. 이 때 시스템이 다운되는 시간은 하드웨어 서비스 업체에서 대체 부품을 보내주는 시간에 따라 달라질 수 있다.

하드웨어로 인한 고장 중 가장 많은 비중을 차지하는 부분은 구동부(Moving Part)이다. 특히 구동부 중에서도 고속에다가 복잡하며 내구성이 약한 구동부를 가진 부품에서 고장이 잦다. 디스크는 이런 특징을 모두가진 부품으로서 시스템 고장을 일으키는 주범이다. 디스크는 컨트롤러나 케이블과 함께 쓰이는데 이것들 역시 부서지거나 고장 날 수 있다. 따라서 대다수의 디스크 어레이들은 캐시메모리나 하드웨어 미러링, 스트라이핑 등 장애에 대처할 수 있도록 구성되어 있다.

테이프 드라이브나 그 구성 요소들은 특히(DLT 테이프) 동작과 멈춤을 반복하는 모터와 충격에 매우 약한 구동부를 가지고 있다. 테이프 시스템 또한 컨트롤러를 비롯하여 디스크 드라이브와 유사한 여러 가지 요소를 가지고 있다.

구동부를 가진 또 다른 부품은 팬(Fan)이다. 팬이 고장 났을 때는 디스크가 고장 났을 때처럼 즉각적인 문제가 생기지는 않는다. 하지만 팬이 고장 나서 시스템 전체의 냉각에 문제가 생긴다면 그것이 시스템에 얼마나 나쁜 영향을 끼칠지는 아무도 예측할 수 없다. 만약 CPU나 메모리가 과열된다면 제대로 동작하지 않을 것이며 심지어는 각 부품이 고장 나게 된다. 대부분의 시스템은 냉각 시스템을 관리하지 않아서, 고장이 난 후에야 비로서 시스템이 고장 났음을 알게 된다.

팬(Fan)이나 전원 공급 장치가 전체 시스템의 MTBF에 가장 나쁜 영향을 끼친다. 전원 공급 장치에 문제가 생기면 그 파급 효과는 빠르게 나타난다. 바로 시스템 전체가 다운되거나 각 시스템에서 단계별로 문제가 생긴다. 전원 공급 장치에 문제가 생기면 이는 시스템의 CPU나 메모리, 대체 시스템에 이르는 매우 심각하고도 막대한 피해를 입힌다. 전원 공급장치를 망가뜨리는 원인으로는 전기선으로 공급되는 전압에 문제가 있거나 시스템을 켜고 끌 때 발생하는 높은 전압 등 여러 가지를 생각 할 수 있다. 이러한 단점을 보완하기 위해 요즘의 시스템은 팬(Fan)을 별도로 가지고 있으며 전원 공급장치를 빠른 시간 안에 각 부분의 상태를 진단하고 문제를 알릴 수 있는 뛰어난 하드웨어 진단 장치를 가지고 있다.

또한, 이런 시스템들은 하드웨어 문제가 생기면 자동으로 서비스 센터나 관리팀에게 알려서 대부분 단 시간 내에 수리 할 수 있다.

시스템 메모리나 CPU처럼 아주 중요한 부분에도 문제가 발생할 수 있지만 요즘의 시스템은 재부팅 없이 고장난 부품을 즉시 교체할 수 있다. 메모리나 CPU의 장애와는 별도로, 이런 기능을 가지고 있다는 것은 결과적으로 전체 시스템의 가용성을 봎여준다. 이외에도 자주 발생하지는 않지만 시스템 내의 다른 하드웨어에도 문제가 생길 수 있다. 이러한 것으로는 백플레인(Backplane) 다양한 메인 보드, 캐비닛(Cabinet), 마운트 랙(Mount Rack) 및 시스템 패키지와 같은 것이 있다.

3-2. 주변 환경 및 물리적인 고장

시스템 고장은 시스템 내부만큼이나 외부에서 일어날 확률도 높다. 고장의 직접적인 요인으로 간주되는 일은 드물지만 시스템 다운을 일으킬 수 있는 주변 환경 요인들이 많다. 그러나, 이들 요소는 그렇게 심각하게 여길 필요는 없다. 시스템 고장을 일으킬 수 있는 주변 요소 중 대부분은 데이터 센터와 연관되어 있으며, 주변 환경과 관계 있는 경우에는 대체 서버가 있다고 해도 큰 도움이 되지 못한다.

가장 대표적인 주변 요인은 전기가 들어오지 않는 것이다. 전력 회사나 지역적 요인에 의해 전기가 들어오지 않을 수 있고 지나가던 차가 빌딩의 전봇대를 들이 받을 수도 있다. 또한 차단기나 퓨즈에 문제가 생기면 여러분의 시스템은 그대로 다운 될 것이다. 야간에 청소부가 진공 청소기의 플러그를 뽑으려고 하다가 실수로 중요한 시스템의 전원 플러그를 뽑을 수도 있고, 진공 청소기의 플러그가 콘센트의 과열을 야기할 수도 있는 것이다.

시스템을 보관하는 곳의 냉각 시스템이 고장 난다면 그 방에 있는 모든 시스템이 과열될 것이다. 또한 전산실이 너무 건조해서 시스템이 고장 날 수도 있다(냉각 시스템 고장으로 인한 전산실의 시스템 고장처럼 직접적인 고장을 일으키지는 않을 수도 있지만)

대부분의 데이터 센터는 바닥 밑에서부터 차곡차곡 여러 시스템에 연결된 케이블로 가득 차 있다. 케이블은 끊어지거나 잡아당겨져서 빠질 수 있으며 물론 물리적인 특성에 따라 구리선의 변화로 인하여 전기를 더 이상 전달하지 않을 수도 있다.(만약케이블에 문제가 생긴다면 더욱 심각한 문제가 발생할 것이다.)

대부분의 데이터 센터는 소방 시설을 갖추고 있다. 그러나 소방 시설이 있다고 해도 위험한 건 여전하다. 진짜 중요한 문제는 화재가 발생하지 않았을 때 일어난다. 불이 나면 소방 시설이 작동되어 물이나 소화물질이 나오며 관리자들은 박으로 대피하게 된다. 산소 대신 방안 가득 할론(Halon)을 채워 불을 유지시켜줄 산소를 차단함으로써 불을 끄게 된다. 물론 산소가 대체되기는 하지만 방안에 있는 사람에게 필요한 충분한 양이 남아 잇다. Inergen System은 산소 호흡을 하는 곳에 친근해 널리 퍼져 있다. 그리고 불을 끄는 데 도움을 준다. 실제로 불이 났다면 소방 시설이 작동해야 하지만 간혹 불이 나지 않았을 때도 소방 시설이 작동하는 경우가 있어 정말로 비상 사태가 아닐 때는 소방 시설을 꺼두는 고도 있다. 그러나, 이러한 실수로 인해 데이터 센터는 큰 피해를 입을 수 있다.

이와 같이 화재가 났을 때 소방 시설이 제대로 작동하지 않으면 막대한 피해를 입게 된다. 좋은 것은 물을 비롯한 소방 시설의 잔재가 없는 것이며, 나쁜 것은 데이터 센터가 비었거나 물에 탄 것들로만 잔뜩 쌓여 있다는 것이다.

환경적 요소 중 또 다른 잠재적인 문제 발생 요인은 컴퓨터 랙(Rack)이나 캐비닛 같은 구조적 문제이다. 랙은 제대로 맞춰 놓지 않으면 무너지거나 넘어질 수 있으며 선반을 잘 조여 주지 않으면 느슨해져서 아래로 떨어질 수도 잇다. 데이터 센터는 어두 침침한 캐비닛 위는 먼지 투성인데, 어떤 케이블들은 이곳을 지나가게 된다. 그러다. 천장이 떨어지면서 이 케이블들을 통해 시스템에 먼지를 비롯한 여러 가지 오물이 들어가게 되는 것이다.

데이터 센터 중에는 운영 중인 시스템 근처에서 공사를 하는 경우가 종종 있다. 공사 인부들은 중장비를 지니고 다니면서 운영 되고 있는 시스템을 고려하지 않은 채 작업하다가 케이블들을 발로 차거나 해서 끊을 수도 있으며 캐비닛을 밀거나 흔들어 놓을 수도 있다. 경우에 따라서 이러한 것을 방지하기 위하여 비닐 커버로 시스템을 덮어둘 경우 오히려 통풍이 안되어 시스템이 과열될 염려가 있다.

그리고, 환경적 요소에는 천재지변이나 재앙도 포함된다. 여기에는 지진, 폭풍, 홍수, 폭탄 및 테러, 전쟁으로 인한 피해, 동식물에 의한 피해까지도 포함된다.

위험에 대해 대비를 아주 철저히 한 시스템이라도 전원이나 환경적 요소에 의한 문제에 있어서는 일반적인 시스템과 다를 바 없다는 것을 명심해야 한다.

3-3. 네트워크 문제

네트워크는 여러 가지 부품으로 이루어져 있으므로 이 부품들 간의 구성으로 인해 문제를 일으킬 수 있다. 따라서 어디서 끊어졌는지, 시스템의 어떠한 네트워크 인터페이스 카드에 문제가 생겼는지, 어떤 장치가 부서졌는지를 정확하게 집어내기 힘들다.

네트워크 역시 시스템 설정으로 인한 문제에 영향을 받는다. 재대로 되지 않은 라우팅 정보, 중복된 호스트 이름 또는 IP 주소, 잘못된 광대역 주소에 의한 목적지 없는 패키 등 대체 네트워크가 고장 나거나 잘못된 위치 데이터를 가지고 있다면 그 네트워크는 끊어질 것이다.

믿을 수 있는 네트워크가 믿을 수 없거나 제대로 관리되자 않는 네트워크에 연결 될 때는 서비스 공격이나 침투를 막을 수 있어야 한다는 위험 부담을 안게 된다. 이러한 종류의 공격은 잘 운영되고 있는 네트워크에도 적용된다. 보안 전문가인 Bill Cheswick는 자신의 강의를 들으러 온 사람들에게 질문을 한다. 그들의 지갑을 열어둔 채 사무실에다 내버려 두겠느냐고, 이 질문에 손을 들어 대답하는 사람들은 거의 없지만, 대신 TP(Twist Pair) 연결용 잭처럼 얼마나 많은 사람들이 보안 장치가 전혀 되어 있지 않은 네트워크의 접속 지점들을 그냥 방치해 두는 냐는 그의 질문에는 주춤하며 손들이 올라가는 것을 볼 수 있다. 그는 네트워크에 접속한다는 것은 가치 있는 일이며, 불필요한 네트워크 트래픽을 막기 위해 인증된 사용자만 쓸 수 있게 해야 한다고 이야기 한다.

결국 네트워크를 통하여 다양한 '핵심 서비스'나 네트워크의 한 부분을 이루는 기본적인 정보 서비스를 제공 받을 수 있다. NIS나 DNS 같은 네이밍 시스템, 보안과 인증 서버, 네트워크를 구성하기 위한 DHCP 서버 등이 제대로 동작하지 않으면 네트워크는 다운된다. 이 부분은 회복 능력을 갖춘 네트워크 구축 작업의 복잡성과 비용 대비 효과와 관련하여 많은 선택이 요구됨을 다음 기회에 설명하기로 하겠다.

3-4. 데이터베이스 시스템의 고장

복잡한 응용프로그램처럼 데이터베이스 시스템 역시 구동부(Moving Part)를 가지고 있다. 그러나 이 구동부는 디스크나 팬(Fan)에서는 찾을 수 없는 대형 데이터베이스를 구성하는 여러 개의 보조 응용프로그램이다. 데이터 베이스 시스템의 핵심은 데이터를 배치하거나 질의에 올바른 응답을 하는 등의 데이터를 관리하고 디스크에서 데이터를 읽거나 기록하는 데이터베이스 엔진이다. 만약 이 부분에 문제가 생긴다면 데이터베이스를 쓰는 모든 사용자는 데이터에 접근할 수 없게 될 것이다. 데이터 베이스 엔진은 디스크 I/O로부터 데이터를 읽고 쓰고, 블록 관리 등 데이터베이스가 동작하면서 필요한 작업에 대한 도움을 받는다.

클라이언트와 데이터베이스 서버 사이에는 Listener 서버가 있다. 이 Listener 서버는 클라이언트로부터 들어오는 질의를 미리 받아 데이터베이스가 수행 할 수 있는 형태로 바꿔주는 역할을 한다. 그리고 서버가 응답하면 이를 다시 Listener 서버가 받아서 질의를 보낸 클라이언트에게 전송한다

사용자의 컴퓨터에서 엔드유저(End-User)용 응용프로그매을 쓸 때는 대부분 실제 SQL(Simple Query Language)에서 한 단계 낮아진다. 엔드유저용 응용프로그램은 사용자의 요구를 네트워크를 지나 Listener 서버를 통해 네트워크로 SQL에 보내게 된다. 잘 만들어진 엔드유저용 응용프로그램은 SQL에서 요구하는 문법처럼 매우 복잡한 데이터나 서버의 다운 등과 같은 데이터베이스와 연관된 문제들로부터 사용자들을 자유롭게 해 준다.

확실히 데이터베이스의 이런 프로세스들이 얽히게 되면 결국은 사용자가 데이터베이스에 접근 할 수 없게 되며, 예측되는 현상은 다음과 같다

• 응용 프로그램 손상
  응용 프로그램이 에러 메시지를 남기고 완전히 멈춰버렸을 경우에는 관리자가 문제의 원인을 찾을 수 있을 것이다.
  
  
• 응용 프로그램 중지
  약간 고치기 힘든 문제로 응용프로그램의 내부 코드만 표시하고 멈춰버리는 상태인데, 이는 Listener나 읽기/쓰기 과정 관리, 데이터베이스 커널의 문제 또는 시스템 리소스가 반환될 때까지 운영체제가 대기하고 있기 때문에 발생한다. 혹은 대형 데이터(각 레코드를 업데이트 하거나 검색할 때)가 처리중일 때 이처럼 시스템이 잠시 중단되는 경우도 있다.
  
  
• 리소스 부족
  데이터베이스에 있어 리소스 부족이 일어나는 원인 중 하나는 디스크 공간이 부족하기 때문이다. 만약 데이터베이스가 쓰는 디스크가 꽉 차면 데이터베이스 엔진이 고장나거나 멈추게 되며, 새로운 데이터를 입력 할 수 없다. 이는 데이터베이스로서 쓸모가 없어지게 되는 것이다. 만약 디스크 공간 부족이 아니라면 로그 파일이 초과된 것으로 로그 파일 역시 데이터베이스가 기록되는 영역에 저장되며, 기존의 파일 시스템 공간에도 다른 내용들이 저장되어 있을 수도 있다. 데이터가 로그 파일 형태로 읽히지 않을 경우, 데이터베이스는 적절히 돌지 않게 되어 멈추거나 고장나거나 계속되는 지시를 받지 못하여 오류를 일으키게 된다.
  
  
• 데이터베이스 색인 문제
  데이터베이스 서버는 테라바이트(Terabyte) 정도의 데이터를 관리한다. 방대한 양의 데이터에서 자료를 찾기 위해 데이터베이스 서버(파일 시스템도)는 복잡한 포인터(Pointer)나 링크(Link)를 사용한다. 이때 각 지점의 위치가 잘못 기록되어 있을 수도 있다. 이렇게 잘못된 데이터는 불러오거나 잘못된 공간에서 데이터를 불러오려는 시도로 인하여 응용프로그램이나 시스템을 손상시킬 수 있다. 대부분의 시스템은 데이터베이스를 검색해 잘못된 부분을 찾아주는 뛰어난 RDBMS을 가지고 있기 때문에 이런 문제는 잘 일어나지 않는다.
  
  
• 소프트웨어 문제
  확실히 소프트웨어는 버그를 가지고 있다. (옛날에 모든 프로그램운 꼭 한 가지씩 버그가 있다고 했다. 이 말은 어떤 경우든 프로그램에는 버그가 있기 마련이라는 뜻이다.)

소프트웨어는 사람에 의해 만들어지며, 무엇보다도 사람은 때때로 실수를 하게 된다. 버그는 단순한 오타에서부터 시스템을 완전히 고장 내는 것에 이루기 까지 다양한 피해를 입힌다. 시스템에 문제가 발생하면 그 문제가 소프트웨어 버그로 인한 것인지 아닌지를 반드시 고려해야 한다. 모든 문제의 원인이 버그라고 볼 수는 없지만 그 반대로 모든 문제가 버그와 전혀 무관하다고도 볼 수 없다. 게다가 버그는 서버 프로세스나 Listener 프로세스, SQL 사용자 엔진, 사용자 프로그램 등과 같이 어떠한 다양한 곳에서 언제 어디서 나타날지 알 수 없다.

3-5. 웹 서버의 고장

버그는 데이터베이스뿐만 아니라 웹 서버에도 피해를 입힐 수 있다. 물론 대부분의 웹 서버들은 사용자가 요구하는 질의를 마지막에 있는 데이터베이스로 전달하는 클라이언트/서버 프로그램을 담당한다. 따라서 데이터베이스에 영향을 미치는 요소라면 웹 서버에도 나쁜 영향을 미치게 되는 것이다. 또한 웹 서버 자체 내에서도 문제가 될 수 잇는 요소는 이 외에도 다양하다.

CGI, Perl, Java, Active X 코드 등 웹 페이지를 관리하는 방법에서 버그는 더 많이 나타나게 된다. CGI(Common Gateway Interface)의 변수가 잘못 설정되어 웹 페이지가 무한 루프에 빠지게 된다면 사용자들은 웹 페이지를 볼 수 없어 다른 사이트로 가게 된다.

전세계 웹 서버에는 새로운 기술이 도용되고 있다. 대부분의 새로운 기술은 일부 사용자에게 짧은 기간동안 테스트되고, 이 중 일부는 꽤 뛰어난 안정성을 보여준다. 하지만 웹 서버는 여러 응용프로그램의 집합체이다. httpd나 웹 서버가 웹 페이지에서 요청을 받아 이에 맞는 HTTP나 이미지 파일을 보내고, CGI 스크립트는 페이지를 만들거나 필요한 형태를 만들어 준다. 그러면 마지막으로 데이터베이스나 파일 서버가 웹 사이트의 컨텐츠나 각 내용을 관리한다. 이런 웹 서버 구성과 관련된 여러 구성 중 하나라도 문제가 생기면 이는 곧 웹 서버의 문제로 이어진다.

여러 개 또는 하나의 웹 사이트는 로그 밸런싱 하드웨어나 소프트웨어를 통해 사용자들의 요구를 적절히 배분 받는다.또, 클라이언트와 서버 사이에 잇는 프락시 캐시 서버는 클라이언트 측에서 들어온 요청이 사용자의 네트워크 밖으로 나갈 필요가 없도록 항상 접속되는 페이지들을 저장(Cache) 하게 된다. 결국 이런 시스템이 오류를 일으키게 되면, 전체 웹 서버에 문제가 있는 것으로 나타나는 것이다.

일반적인 데이터베이스 서버처럼 디스크, 파일 시스템, 그리고 로그가 꽉 차는 경우가 생긴다. 또한 메모리와 CPU를 비롯한 여러 자원이 바닥사서 고장나거나 응답하지 않는 등 비 정상적으로 동작할 수도 있다. 여러분이 CGI 프로그램이 파일에 기록할 수 없거나 상부의 응용프로그램에 반응하지 않을 경우를 위해 CGI 프로그램이 제대로 돌아가고 있는지 확인해 볼 필요가 있다.

3-6. 파일 서버와 프린터 서버의 고장

사용 도중 파일 및 프린터 서버에 문제가 생기면 사용자는 작업이 중단되거나 응답이 없는 상태를 경험하게 된다. 타임아웃(Time Out)이란 요청한 프린터나 파일 작업을 수행할 수 없음을 의미하며 또한 잘못된 응답이나 데이터를 받았음을 뜻할 수도 있다. 예를 들어, NFS(Network File System)를 이용하여 마운트 할 때는 타임아웃(Time Out)된 스기 작업이 반복되지 않는다. 이는 파일이 읽힐 때만 데이터 파일에 문제가 있음을 알게 되기 때문이다.

프린터 서버의 고장은 작업을 손상(Damaged) 또는 분실(Lost) 시키거나, 작동불능(Hung) 상태에 빠지게 한다. 작업을 요청한 사용자가 아무런 결과를 받지 못하게 된다면, 이는 앞에서 정의한 다운의 의미에 따라 프린터 서버는 사용자를 다운시키게 된다.

[4] 비용, 위험 요소의 상관관계

투자자나 경영자로 하여금 시스템 운용 시간의 중요성을 인식하게 하는 유일한 방법은 제대로 동작하는 시스템에 문제가 생겼을 때의 피해를 돈으로 환산해서 보여주는 것이다. 이 장에서는 고집 센 상사에게 대응할 수 있는 방법에 대해 알려줄 것이다.

4-1. 다운타입(Down-time)의 비용

다운으로 인한 비용은 값으로만 측정되지 않는다. 다운으로 인하여 잃게 되는 것은 사용자를 잃는다는 것과 함께 사용자가 어떠한 작업을 하다가 손해를 입었는가에 달려 있다.

만약 사용자가 개발자라면 다른 비용보다는 개발자를 고용하고 개발 기간에 든 비용이 더 클 것이다. 물론 거대한 개발 조직이라면 비용은 상당할 수 있다. 개발자들은 경우에 따라 일당 5백 ~ 1천 달러를 받게 되므로 따라서 50명의 개발자로 이루어진 그룹에는 매주 25만 달러가 든다는 결론이 나온다. 그러나 25만 달러가 개발자들에 대한 모든 비용은 아니다. 시스템 다운으로 작업할 수 없었던 부분을 보충하기 위해서 필요했던 야근 수당 등은 여기에서 빠져 있는 것이다.

개발자가 컨설턴트이거나 시간당 비용을 계산하는 근로자라면 야근 수당은 37만 5천 달러를 휠씬 웃돌 수도 있다. 게다가 이 같은 수치는 야근으로 인한 육체적, 정신적 피로는 고려하지 않은 숫자이다.

한편, 초과 수당 지불보다 더 정신을 번쩍 들게 하는 것은 프로젝트의 마감일이 일주일보다 휠씬 늦어지는 것이다. 마감일을 넘기는 것은 인건비처럼 더 명확하고 간단한 문제가 아니며, 장난이 아닌 현실 그 자체인 것이다.

산업별	비즈니스 운영	시간당 평균 다운타임 비용
금융	증권거래	$6.45M
금융	신용카드 인증	$2.6M
미디어	유료 영화 시청	$150K
유통	TV 홈쇼핑	$113K
유통	홈 카탈로그 쇼핑	$90K
교동	비행기 예약 시스템	$89.5K
미디어	전화 티켓 예매 시스템	$69K
교통	택배 사업	$28K
금융	현금 자동 인출기 수수료	$14.5K

[표2] 다운에 따른 비용(소스:데이터베이스, 펄스펙티브, 1996년 9월 30일)

어떠한 결과를 얻고자 하는 사용자의 경우에는, 고장난 서버에서 수행되던 일의 종류에 따라 그에 따를 비용은 매우 차이가 난다. 월 스트리트에 잇는 대형 증권거래소에서는 거래가 있는 날 시스템이 다운되면 20분마다 2백만 달러식 손해를 보는 것과 같다고 한다. 2백만 달러란 숫자는 모든 거래에서 이득을 봤을 때 가능한 금액이며, 사실 시스템의 다운으로 인해 거래소에서 손해를 보거나 돈을 잃을 수 있는 거래를 막을 수 있지만 이상하게도 월 스트리트는 이러한 가능성을 배제해 버린다.

물론 트레이더들의 급여나 운영비 역시 손해를 보게 된다. 많은 트레이더들이 막대한 돈을 벌기는 하지만 매 20분 동안 2백만 달러를 버는 사람은 드물 것이다. 증권회사의 손해는 개발 조직의 손해에 양적으로 비교될 수 없는데, 이는 증권회사의 손해가 일어버린 기회비용(Opportunity Losses)에서 산출되기 때문이다.

'잃어버린 기회비용'이란 결과에 상관없이 어떤 것에 대한 기회를 잃었다는 것을 말한다. 그 어떤 것이란 증권거래일 수도 있고, 신용카드 거래 인증일 수도 있으며, 인터넷에서 상품을 파는 행위와 같이 지극히 일상적인 것일 수도 있다. 상세하게 고찰해 보지 않으면 시스템 다운 시 기회비용이 얼마나 될 것인지 알기란 거의 어렵다.

그러나, 관리자가 정확히 얼마만큼의 손해를 입었는지 반드시 계산해야 하는 것은 아니다. 여러분이 홈쇼핑, 전화나 인터넷을 통해 80달러짜리 스웨터를 구입하려 한다고 가정해 보자. 스웨터를 구입하기 위해 전화를 걸었을 때 안내원이 "지금은 시스템이 다운되어 어떤 주문도 받을 수 없습니다. 몇 시간 뒤에 다시 걸어 주세요"라고 한다면 여러분은 어떻게 하겠는가? 물론 여러분은 지금 당장 스웨터를 주문하고 싶을 것이므로 기다리지 않고 다른 홈 쇼핑 회사에 전화를 해서 주문할 것이다.

시스템이 다운된 스웨터 가게는 스웨터 값 만큼만 손해를 본 것일까? 그렇지 않다. 그 회사는 시스템 다운으로 인해 잠재 고객을 다른 회사에 빼앗김으로써 직접적으로는 스웨터 한 벌 정도의 손해를, 간접적으로는 미래에 발생될 보다 많은 매출 기회를 잃은 것이다. 또한 다른 사람들이 어디에서 물건을 샀냐고 물을 때, 시스템이 다운된 회사가 아닌 스웨터를 구입한 두 번째 회사를 주위 사람들에게 추천할 것이다. 표면적으로는 첫 번째 회사가 80달러를 손해보고 두 번째 회사가 80달러의 이득을 취했지만, 정확한 피해액을 파악할 수 없을 만큼 그 차이는 갈수록 커지게 될 것이다.

4-2. 관리 문제에 대한 설명

이제 여러분은 시스템 다운으로 인한 직접 혹은 간접적인 손해 비용을 이해하게 되었다. 따라서 구매 결정자가 아닐지라도 주변 환경에 존재하는 잘못된 점을 시정하기 위하여 무엇이 필요한지를 경영진에게 설명해야 할 필요가 있다.

우선 경영진에게 가용성의 수준을 정하게 하고 이를 위해 어떻게 비용을 배분해야 하는지에 대한 설명할 필요가 있다. 전체 윤곽을 그린 후 완벽한 시나리오를 계획하라.

일어날 수 있는 시스템 문제를 생각해 보고, 앞을 내다보는 넓은 식견을 가지고 연구해야 한다. 극단적인 예이지만 여러분이 물 속에 건물을 세운다면 이 건물을 쓰는 사람들은 책상, 전화기를 비롯하여 컴퓨터 시스템도 쓸 수 없을 것이다. 이렇듯 건물을 지을 때도 여러 가지 상황을 고려해야 하듯 시스템을 구축할 때도 계획을 잘 세워야 한다.

다음으로는 위험을 감수할 만한 가치가 있는 것을 정확히 해 두어야 한다. 이는 보다 이득이 될 만한 것들과 자주 발생할 것 같은 것을 정확하게 파악해야 하고, 비용을 현명하게 지불해야 한다는 뜻이다.

마지막으로 추천 사항을 준비하는 것이다. 경영진 나름대로의 특별한 의견이 없는 이상, 경영진측에서는 경제적인 측면을 잘 반영한 기술진의 추천 사항에 대해 진지하게 고려해 졸 것이다.

여러분의 경영진에게 비용과 위험 부담을 설명 할 때 부딪히게 되는 부분 중 하나는 모든 일이 벌어지고 난 결과를 보고 판단하지 않도록, 즉 소 잃고 외양간 고치는 격이 되지않도록 그들을 설득시키는 일이다. 벌어질 수 있는 일을 자세히 설명해야 하는데, 실제 문제가 생기면 일어날 수 있는 위협적인 일과 이로 인하여 발생할 비용을 적절한 균형을 맞추어 이야기하도록 한다. 많은 회사들은 문제가 생겨 손해를 보고 나서야 이에 대한 구체적인 대비책을 세우며, 경영진은 이제서야 비로서 문제에 따른 엄청난 비용을 깨닫게 된다. 새로운 장애 발생하면 회사는 다시 한 번 이데 대한 대비책을 세운다는 것이다. 이런 과정은 계속해서 되풀이 되는데 일어나지 않은 일에 대한 대비책은 없으며, 사후 처방에 끌려가는 회사들이 계속적으로 속수무책으로 당할 수 밖에 없다는 것은 최악의 시나리오이다. 미리 계획을 세우지 않는 것은 인간의 본성이라 할 수 있기 때문이다.

이러한 예는 또한 노트북과 다른 소형 컴퓨터기기의 백업 과정에서 볼 수 있다. 대부분의 회사에서 노트북 백업을 별로 중요시 하지 않다가 CIO의 노트북 디스크에 문제가 생긴 후에야 노트북 백업이 중요한 문제로 대두되는 것이다. 그러므로 어떤 일이 일어나는지를 세세히 설명해야 하고 실제 문제가 생겼을 때 일어날 수 이는 위협적인 일과 이로 인한 비용을 설명해야 한다. 그러나 많은 업체에서는 문제가 생겨 손해를 보고 나서야 이에 대한 구체적인 대비책을 세우는 게 현실이다.

장애가 언제 어디서 어떻게 일어날지는 아무도 모른다. 어느 날 갑자기 백업 시스템이 잇는 곳에 천재 지변이 일어날 수도 있고, 갑자기 중요한 내용을 담은 디스크가 고장 날 수도 있는 것이다. 그리고 많은 사람들이 그러한 사태가 일어날 수도 있고, 갑자기 중요한 내용을 담은 디스크가 고장날 수도 있는 것이다. 그리고, 많은 사람들이 그러나 사태가 일어나고 나서야 백업이 얼마나 소중한 지를 깨닫게 된다. 따라서 넓은 관점에서 각 부분을 다루고 관리해야 하며, 일어날 수 있는 모든 문제에 대해서 효과적인 방법을 세워서 대비해야 한다.

4-3. 가용성의 단계(가용성의 연속)

여기서 이야기 하는 가용성의 각 단계가 본질적으로 명확히 구분해 낼 수 있는 것이 아니라는 사실은 매우 중요하다. 일반적인 시스템 가용성을 증가시키기 위해서는 수 많은 단계와 함께 결집된 기술이 필요 하며, 다음 각 단계는 실제 시나리오를 반영하여 인위적으로 나눈 것이다.

단계 1 : 일반적인 가용성 : 평범함
가장 기본적인 시스템 보호법은 아무런 보호 장치를 하지 않는 것이다. 시스템이나 디스크를 보호하기 위한 장치는 전혀 없으며, 1단계에서는 백업 이외에는 별 다른 것이 없다. 시스템이 다운되면 이전에 준비된 특별한 계획 없이 그대로 부딪칠 따름이다. 일반적인 응용프로그램을 수행하기에는 충분하지만 어느날 갑자기 문제가 발생하여 데이터를 잃을 수도 있다. 백업을 해 두기도 전, 업무 종료 시간 즈음에 디스크 에러가 나면 그 날 작업한 모든 일은 고장난 디스크와 함께 날아갈 버릴 것이다. 도 이 시스템이 직접적이든 간접적이든 수익 창출에 어떻게든 연관되어 있다면 이런 시스템은 절대로 만족스럽지 못한 것이다.

단계 2 : 기용성 증가 : 자료 보호
2단계는 1단계와 비교 했을 때 온라인 데이터 보호 부분만 빼고는 별로 다를 것이 없다. 이는 RAID-5(Parity RAID)처럼 낮은 수준의 보호에 불과하다. RAID 기술을 채용해 디스크 미러링을 하고 있지만 이 역시 완벽한 방법은 아니다. 디스크 하나가 망가졌다면 미러링한 다른 디스크가 있기 때문에 모든 데이터는 안전하다. 그리고, 정기적으로 백업을 수행할 경우, 두 개의 디스크가 모두 날아갔다고 해도 데이터의 손실을 가져오지는 않는다. 백업은 사용자의 실수로 인한 데이터 소실을 막을 수 있을 것이다. 시스템의 다른 부분에 문제가 생기면 시스템 전체는 다운되어도 중요 데이터만큼은 보호되지만, 시스템에 있는 모든 디스크가 망가졌다면 데이터는 모두 소실된다. 백업은 사용자로 인한 데이터 오염을 막을 수 있어야 한다. 시스템의 다른 부분에 문제가 생기면 시스템 전체 다운은 수 일간 계속 될 수는 있지만 중요 데이터만큼은 보호 받을 수 있다.

단계 3 : 고가용성 : 시스템 보호
3단계는 흔히 이야기 하는 고가용성(Higv Availability:HA)과 같다. HA 구성은 두 대의 서버를 클러스터 형태로 연결한다. 이렇게 할 경우 디스크를 비롯한 서버의 각 부분들이 중복되는 대체 부품들을 갖는 것과 같은 효과를 얻을 수 있다. 만약 한쪽 부품에 문제가 생기면 자동 또는 수동으로 같은 기능을 수행하는 다른 쪽 부품이 이를 대체하게 된다.

HA 구성을 했음에도 불구하고 시스템이 다운 될 수 있는데, 대부분의 경우 한계가 있기는 하지만 계속 동작한다. 3단계에서는 시스템 가동 시간을 99.98%보다 더 높일 수 있으며, 보조 장치를 추가해 더 넓은 단계로 만든다면 그 이상의 가동 시간을 보장할 수도 있다. End-to-End로 HA 시스템을 디자인하려면 네트워크 연결을 고려해야 한다.

한편 이 정도의 시스템을 꾸밀 때 감안하여 할 점은 주변 상황까지 고려해야 한다는 것과 이로 인하여 시스템 관리가 쉽지 않게 된다는 것이다. 또 한가지 문제라면 바로 비용이다. 이렇듯 여분의 시스템을 구축하기 위해서는 시스템의 각 부품이나 네트워크, 기술 지원을 위한 시간과 인건비가 소요된다.

단계 4 : 재해 대비 복구 시스템 : 시스템 자체를 보호
재해에 대비한 복구 시스템은 시스템 보호 단계 중 가장 높고 가장 많은 비용이 들어가는 단계이다. 건물 붕괴나 천재지변 같은 재해로부터 시스템을 보호하기 위해서 메인 시스템이 있는 곳에서 떨어진 다른 곳에 동일한 시스템을 갖추고, 메인 시스템에 문제가 생기면 곧바로 백업용 시스템이 이를 대체할 수 있도록 메인 시스템과 동일한 하드웨어를 가진 시스템이 네트워크로 데이터를 원격으로 항상 백업 할 수 있도록 한다.

단계 5 : 무정지 시스템
시스템 보호 단계의 또 다른 부분은 무정지 시스템(Fault Tolerant System)이다. 이런 서버는 한 시스템 안에 두 세 개의 대체 부품을 장착한다. 따라서 특정 부분에 문제가 생기면 서버는 중단되지 않고 곧바로 병렬로 연결된 대체 부품이 동작하게 된다. 보통 이런 경우 각 부품이 병렬로 동작한다. 여러 부품이 동작하다가 시스템에서 쓰고 있는 부품과 대체 부품들 사이의 출력 값을 비교 했을 때 시스템에 쓰인 부품이 비정상적인 동작을 할 경우, 이를 정상적으로 동작하는 다른 부품이 내놓은 값으로 대체하게 되는 것이다. 그리고, 비 정상적인 동작을 한 부품은 곧바로 제거된다.

실제로 잘 된 무정지 시스템은 하드웨어 고장으로 인한 다운타임을 초래하지는 않는다. 다시 말해 시스템은 하드웨어가 아닌 소프트웨어적인 요인에 의해서 다운되는 것이다. 주요 프로그램이나 운영체제의 버그로 인하여 시스템이 다운 될 수 있으며, 오랜 기간 동안의 정전이나 화재 등의 환경적 요인과 같이 외부 요소에 의해서도 다운될 수 있다.

무정지 시스템에서 이론적으로는 하드웨어로 인한 다운은 있을 수 없지만, 이러한 시스템이 그 값어치를 제대로 하느냐에 대해서는 여전히 의문이다. 중복된 하드웨어를 가지는 시스템을 만들기 위해서는 수백만 달러가 들어간다. 이러한 시스템은 조금 오래됐어도 안정성을 위해서 일반 시스템을 쓰는 것보다는 성능이 뒤진 부품들을 사용한다.

4-4. 위험 요소와 그에 대한 비용의 창출

문제를 해결하기 위해 무조건 돈을 투자할 수는 없는 노릇이다. 어느 정도의 위험 부담과 이 위험 부담을 줄이기 위해 투입할 수 있는 자원을 조절하는 일은 반드시 필요하다. 어떤 부품에 우선적으로 자원을 투자해야 할지를 간단한 기준을 통해 알아보자.

• 잦은 고장
  확실히 이 부품은 시스템은 다운시켜 서비스를 중단시키는 일등 공신이 될 것이다. 이 부품은 MTBF 수치가 낮고, 구동성(Moving Part) 부품인 경우가 많다.
  
  
• 교체하기 어려움
  자동차 깊숙이 박혀 있는 가스켓은 20만 마일을 달리고 나면 교체해 줄때가 되며 가격은 69센트 이다. 그러나 가스켓을 교체하려면 자동차에서 엔진을 뜯어내고 이를 반으로 갈라 가스켓을 찾아야 한다. 그리고 나선 고장난 가스켓을 교체하고 엔진을 다시 조립해서 자동차에 부착해야 한다. 자동차 제조사의 가격은 몇 배 비사더라도 수리가 필요 없는 수명이 두 배로 긴 가스켓을 만들거나 25달러가 들더라도 위의 복잡한 과정 없이 가스켓을 교체할 수 있는 방법을 개발해 낸다면 운전자는 시간, 교체 비용, 그리고 노력을 줄일 수 있을 것이다. 앞의 예는 컴퓨터에서도 똑같이 적용된다. 고장난 부품 하나를 교체하는 데 많은 시간이 걸린다면 수명이 길고 교체가 손쉬운 부품을 선택해야 한다.
  
  
• 고장 나면 피해가 심각한 부품
  이런 부품을 소개하는 가장 좋은 방법은 실제 예를 드는 것이다. 과거에는 시스템 냉각팬이 고장 났을 때 그 시스템은 어떤 경고도 없이 어느 순간 과열로 인해 다운 되었다. 그리고 이렇게 다운된 시스템은 식을 때까지 기다리는 방법 밖에 없었다. 그러나 요즘 시스템은 여분의 냉각 시스템이 장착되어 있어서 이 냉각팬 중 하나에 문제가 생긴다면 다른 팬이 더 빠른 속도로 동작해 시스템이 과열되는 것을 막아준다. 또 팬이 고장난 것을 관리자에게 알여 그로 하여금 적절한 조치를 취할 수 있게 한다. 이처럼 일단 고장나면 대처하기가 힘들고 문제가 커지는 부품은 신중하게 선택해야 한다.

시스템을 보호하려는 목적으로 고장 났을 때 다른 것에 비해 피해가 더 크고 수리하는 데도 시간이 많이 걸리는 부품에 여러분이 더 많은 비용을 투자한다면 반드시 그에 따른 보상을 받게 될 것이다. 어떤 부분이 자주 고장나든지, 그리고 자주 고장나서 여러 번 고쳐야 하는 부분이 어디인지를 자세히 살펴보고 그 부분에 우선적으로 투자하라. 일반적으로 데이터의 보호가 우선이며, 데이터로의 접근은 그 다음이다. 많은 회사들에게 있어서 주요 데이터를 잃는다는 것은 회사문을 닫아야 함을 의미하므로 비용에 관계 없이 데이터는 반드시 보호 되어야 한다고 생각한다. 일부 문제와 특정 시스템을 고장낼 만한 요소에 대해 균형적으로 보호해야 하지만, 개발 시스템 보호를 위해서는 백만 달러 이상을 투자하면서 주변 환경이나 다른 요소는 뒷전 것이 현실이다.

4-5. 낭비하지 마라

좋은 충고란 말로 하기는 쉽지만 실천하기는 어려운 것들이 대부분이다. 낭비하지 마라. 사고를 막기 위한 한정된 자금을 헤프게 쓰면 안된다. 불능한 상황에 맞서지 마라. 예를 들어 판매원이 와서 아무리 감언이설로 설득한다 해도 데이터 센터 주위에 고질라에 대비한 오백만 달러 짜리 보호 장치를 달지 말라. 고질라가 공격하는 것은 현실에서는 있을 수 없는 일이며, 매우 극단적인 상황이지만 다운 타임을 야기할 수 있는 여러 이벤트를 역시 이와 같다. 여러분이 시스템을 보호하기 위한 비용을 지불해야 할 시점에 있을 때 한쪽 끝에 고질라에 대비한 보호장치가, 다른 한쪽 끝에 데이터 백업이 있다면 어떠한 보호 장치를 채택할 것인지에 대해 결정을 내려야 한다.

또, 일어날 수 있는 모든 재해를 결합하는 것 역시 경계해야 한다. 기술진들은 '혹시 ~ 라면?'과 같은 일에 대해 이야기하기를 좋아하지만, 그러한 일들은 현실성이 없다. 여러분도 폭풍우가 몰아치는 일요일 오전 테러리스트들이 건물을 공격함과 동시에 시스템의 디스크가 고장나고 중요한 데이터베이스 테이블이 지워지는 일이 한꺼번에 일어날 수 있다고 생각하겠는가 ? 각각의 사건으로 본다면 흥미로운 시나리오지만 이 두세 가지의 일이 동시에 일어나는 일은 거의 없을 것이다. 차라리 각각의 사건이 발생 했을 때를 대비해서 시나리오를 짜고 이에 대비하는 편이 휠씬 현명할 것이다.

주위를 둘러보고 정말로 문제가 생길만한 것이 어떤 것인지 살펴보라. 그리고 시스템 고장이 미치는 영향이 어떤지 생각해 보고 실제 일어날 만한 일로 인해 시스템이 다운되는 것을 막을 수 있는 방법을 찾아보아야 할 것이다.

• 부품 고장
  현실을 직시하고 계획을 세운 후 시스템에서부터 디스크, 응용 프로그램에 이르기까지 일어날 수 있는 모든 문제에 대비하라.
  
  
• 평균치를 최고치라고 생각하지 마라
  시스템 다운의 가장 긴 시간과 문제 해결을 위하여 소요될 수 있는 최대한의 시간을 생각해 두어라.
  
  
• 다운을 막기 위한 비용과 다운으로 인한 비용
  대체 시스템을 두어 위험 부담을 줄이는 데 필요한 비용과 시스템 다운으로 인해 입는 피해를 잘 생각해서 적절한 타협점을 찾아라.