[소프트웨어공학] 중대한 시스템3 (가용성과 신뢰성)

 3.3 가용성과 신뢰성

 시스템의 가용성과 신뢰성은 수학적 확률로 표현될 수 있는 밀접한 관계를 가진 특성이다. 시스템의 신뢰성은 시스템의 서비스가 지정한 대로 올바르게 전달될 확률을 의미한다. 시스템의 가용성은 사용자가 서비스를 요청했을 때 시스템이 계속 돌아가고 서비스를 제공할 수 있는 확률을 의미한다.

 이 두 특성은 밀접한 관계가 있지만 신뢰할 수 있는 시스템은 늘 사용가능하고, 사용가능한 시스템은 신뢰할 수 있다고 가정할 수 없다. 예를 들어, 어떤 시스템은 매우 높은 가용성을 요구하지만 매우 낮은 신뢰성을 요구할 수 있다. 만약 사용자가 계속적인 서비스를 요구하면 가용성 요구는 높다. 그러나 만약 고장의 결과가 미약하고 시스템이 빨리 복귀될 수 있다면 그 시스템은 매우 낮은 신뢰성을 요구하는 것이다.

 가용성이 신뢰성보다 중요한 시스템의 예로서 전화 교환기가 있다. 사용자가 전화기를 들었을 때 신호를 기대하기 때문에 시스템은 매우 높은 가용성을 요구한다. 그러나 시스템의 고장 때문에 통화가 안 된다고 하더라도 그것은 바로 복구될 수 있다. 교환기는 시스템을 초기화하고 연결을 재시도할 수 있는 수리 기능이 있다. 이것은 매우 빨리 이루어질 수 있으며 전화 사용자는 고장이 일어났는지도 모르는 경우가 있다. 그러므로 이러한 시스템에 대해 가용성은 신뢰성보다 더 중요한 확실성의 한 가지 특성이다.

 이러한 특성을 좀 더 명확하게 구분해 보면 가용성은 단순히 시스템 자체에 의존하지 않을 뿐만 아니라 고장을 수리하는 데 걸리는 시간에 의존한다는 것이다. 그러므로 시스템 A가 일 년에 한 번 고장 나고 시스템 B가 한 달에 한 번 고장 나면 A가 B보다는 더 믿을 수 있다. 그러나 시스템 A를 수리하는 데 3일이 걸리는 반면, 시스템 B는 10분이 걸린다면 시스템 B의 가용성(120분간의 다운 시간)이 A의 가용성(4,320분간의 다운시간) 보다 훨씬 좋다.

 시스템의 신뢰성과 가용성은 다음과 같이 더 정확하게 정의할 수 있다.

 

 1. 신뢰성 : 주어진 환경에서 특정 목적을 위해 지정된 시간 동안에 고장 없이 운영될 수 있는 확률

 2. 가용성 : 시스템이 주어진 시점에서 요청된 서비스가 제공되고 운영될 수 있는 확률

 

 

 신뢰할 수 있는 시스템을 개발하는 데 실질적인 문제 중 하나는 우리가 직관적으로 생각하는 신뢰성과 가용성이 위의 정의보다는 더 광범위하다는 것이다. 신뢰성의 정의에는 시스템이 사용될 환경과 그것이 사용될 목적이 반드시 고려되어야 한다고 기술 되어 있다. 만약 시스템 신뢰성을 하나의 환경에서 측정한다면, 신뢰성은 시스템이 다른 방법으로 사용되는 다른 환경에서도 같다고 가정할 수 없을 것이다.

 예를 들어, 워드 프로세서의 신뢰성을 대부분의 사용자가 소프트웨어의 사용에 관심이 없는 사무실 환경에서 측정한다고 가정하자. 그들은 그것을 사용하기 위해서 명령대로 따라하며 시스템을 실험하려고 하지 않는다. 만약 같은 시스템을 대학 환경에서 측정한다면, 신뢰성은 달라질 것이다. 학생은 시스템의 경계가 어디인지를 알기 위해서 시스템을 이상한 방법으로도 사용하려고 한다. 이런 경우에 제한된 사무실 환경에서는 일어나지 않았던 시스템 고장이 일어날 수도 있다.

 사용하는 것에 대한 사람의 인식과 패턴은 매우 중요하다. 예를 들어, 폭우 시에 제대로 작동하지 않는 와이퍼 시스템이 있다고 가정하자. 이 시스템의 신뢰성은 운전자가 살고 있는 곳과 자동차를 사용하는 장소에 따라 다르다. 시애틀(비 내리는 기후)의  운전자는 라스베이거스(건조한 기후)의 운전자에 비해 아마도 이러한 고장에 더 큰 영향을 받을 것이다. 시애틀의 운전자는 와이퍼 시스템을 믿을 수 없다고 하는 반면에, 라스베가스에 사는 운전자는 와이퍼 시스템의 문제를 알지 못할 것이다.

 이러한 정의에 대한 추가적인 어려움은 비가용성의 결과 혹은 고장의 정도를 고려하지  않았다는 것이다. 사람은 자연적으로 심각한 결과를 초래하는 시스템에 더 관심을 가지고 시스템 신뢰성에 대한 인지도는 이러한 결과에 영향을 받는다. 예를 들어, 엔진 관리 소프트웨어의 초기화의 실패는 출발 후에 즉각 엔진이 멈추게 하지만 재시동 후에는 제대로 작동하게 된다. 이것은 거의 정상적인 운행에 영향을 주지 않으며 많은 운전자들은 수리가 필요하다고 생각하지 않는다. 반대로 대부분의 운전자들은 한 달에 한 번 정도로 고속 주행 시 엔진이 멈출 경우에 믿을 수 없으며 수리가 필요하다고 생각한다.

 신뢰성의 정확한 정의는 시스템의 구현 및 그것의 요구사항과 관계가 있다. 즉, 시스템은 그 행동이 요구사항에 정의된 대로 작동하면 믿을 수 있다고 한다. 하지만 인지된 대부분의 비신뢰성의 주요 원인은 시스템 요구사항이 시스템 사용자의 기대에 미치지 못할 경우이다. 불행히도 많은 요구사항은 불완전하고 부정확하며 시스템이 어떻게 행동해야 하는지에 관한 것은 소프트웨어 엔지니어의 몫으로 남겨진다. 그 사람들은 그 분야의 전문가가 아니기 때문에 사용자가 기대한느 행동을 구현하지 못할 수도 있다.

 신뢰성과 가용성은 시스템 고장에 의해 손상될 수 있다. 서비스를 제공하지 못하는 고장, 지정된 대로 서비스를 제공하지 못하는 고장 혹은 서비스가 불안전하고 보안되지 않은 상태로 제공되는 고장이 있을 수 있다. 그러한 고장은 시스템 요구사항의 오류 이거나 혹은 통신 시스템과 같은 관련 시스템의 고장 결과일 수도 있다. 신뢰성을 논의 할 때 결함(fault), 오류(error), 고장(failure)의 명확한 구분이 필요하다. 

용어	설명
시스템 고장	시스템이 사용자가 기대하는 서비스를 제공하지 못할 때 일어나는 사건
시스템 오류	시스템 사용자가 예기치 못한 시스템 행동으로 이끄는 시스템의 상태
시스템 결함	시스템 오류로 이끄는 소프트웨어 시스템의 특성. 예를 들어, 변수 초기화를 싪패하면 그것이 잘못된 값을 가질 수 있게 된다.
사람의 실수 혹은 오류	시스템 결함에 이르게 하는 사람의 행동

 사람의 오류는 시스템 고장을 유발하지는 않는다. 결함은 전혀 사용하지 않았던 시스템 부분에서 일어날 수 있다. 결함의 상태가 순간적이고 생기자마자 바로 수정될 수 있기 때문에 필연적으로 시스템 오류까지 이르지는 않는다. 시스템 오류는 그 행동이 순간적이고, 관찰될 만한 영향을 갖지 않기 때문에 시스템 서비스가 영향을 받기 전에 잘못된 행동이 발견되고 교정되도록 하는 보호 장치를 포함한다.

 위 테이블표에 있는 이러한 구분은 시스템의 신뢰성을 증진시키기 위해서 사용될 세 가지 보완적인 접근 방법을 알 수 있게 해 준다.

 

 1. 결함 회피 : 시스템이 결함이 이르기 전에, 실수를 하거나 그 가능성을 최소화할 수 있도록 하는 개발 기술을 사용한다. 이러한 기술의 예는 포인터나 프로그램 이상을 발견하기 위한 정적 분석의 사용과 같은 프로그래밍 언어 구조를 사용하는 것이다.

 2. 결함 탐지와 제거 : 결함을 발견하고 시스템을 사용하기 전에 제거할 수 있는 기회를 향상시키는 증명과 검증 기술을 사용한다. 체계적인 시스템 시험과 디버깅이 결함 탐지 기술의 예이다.

 3. 결함 내성 : 시스템에 있는 결함이 시스템 오류에 이르지 않거나 시스템 오류가 시스템 고장이 되지 않도록 하는 기술이다. 시스템의 자체 점검 기능과 중복 시스템 모듈을 통합하는 것이 결함 내성 기술의 에이다.

 

 소프트웨어는 결함이 있는 부분의 코드가 소프트웨어 결함을 보이는 입력 데이터를 실행했을 때, 그 결함이 소프트웨어 고장을 유발한다. 대부분의 입력에 대해서는 그 코드가 제대로 작동한다. 아래 그림은 리틀우드로부터 나온 것으로 입력과 출력의 대응 관계로 시스템을 나타낸 것이다. 주어진 입력과 입력의 집합에 대해 해당되는 산출물을 생산함으로써 프로그램은 반응한다. 예를 들어, URL의 입력에 대해 웹 브라우저는 요청한 웹 페이지를 화면에 출력한다.

 

입/출력 대응 관계로서의 시스템

 어떤 입력 혹은 입력 조합은 타원 안에 있는 잘못된 산출물을 생산한다. 소프트웨어 신뢰성은 프로그램의 특정 부분 실행 시 시스템 입력이 잘못된 출력이 생기도록 하는 입력 집합의 부분이 될 확률과 관계가 있다. 그러나 만약 그것이 거의 사용되지 않는 코드라면, 사용자는 거의 그 고장을 볼 수 없다.

소프트웨어 사용 패턴

 

 시스템의 각 사용자는 시스템을 상이한 방법으로 사용한다. 한 사용자가 경험한 시스템의 신뢰성에 영향을 미치는 결함은 다른 사람이 사용할 경우에 전혀 드러나지 않을 수도 있다. 잘못된 입력 집합은 그림의 타원에 해당된다. 2번 사용자가 제공한 입력이 잘못된 입력과 관계가 있다. 그러므로 2번 사용자는 시스템 고장을 경험했을 것이다. 하지만 1번과 3번 사용자는 그 잘못된 집합에서 입력을 전혀 사용하지 않았다. 그들에게 이 소프트웨어는 믿을 수 있는 것이다.

 그러므로 대부분의 사용자에 의한 시스템의 정상적인 사용 기간 동안에 프로세스의 전체 신뢰성은 잘못된 출력의 원인이 되는 입력의 수에 좌우된다. 예외 상황에서만 일어날 수 있는 소프트웨어 결함은 시스템의 신뢰성에 거의 영향을 미치지 않는다. 시스템에서 거의 사용하지 않는 소프트웨어 결함을 제거하는 것은 시스템의 사용자 측면에서는 신뢰성에 거의 차이가 없다. 밀스 등은 자신들의 소프트웨어에서, 60%의 알려진 오류를 제거했더니 3%의 신뢰성이 증가했다는 것을 발견하였다. 애덤스는 IBM 소프트웨어 제품에서 제품의 많은 결함은 제품 사용 후 수백 혹은 수천 개월이 지나야 고장을 일으킨다는 것을 알았다.

 사회-기술적 시스템에서 사용자는 알려진 결함을 가진 소프트웨어에 잘 적용하여 어떻게 그 문제를 피해 가는지에 관한 정보를 공유한다. 그들은 문제를 일으킨다고 알려진 입력 사용을 피해서 프로그램 고장이 전혀 일어나지 않도록 한다. 더군다나, 경험이 있는 사용자는 고장을 일으키는 소프트웨어 결함을 피해 나간다. 그들은 문제를 야기할 수 있다고 알고 있는 시스템 특성을 의도적으로 사용하지 않는다.