소프트웨어 공학 - Chpater 11. 신뢰성 공학

신뢰성 공학에 대한 파트다.

가용성과 신뢰성은 소프트웨어 공학에서 꽤 많이 다뤄지기 때문에 외우기보단 이해하는 것이 필요했다.

기준은 한티 미디어 소프트웨어 공학 제 10판이다.

• 신뢰성 공학 목차
  • 가용성과 신뢰성
  • 신뢰성 요구사항
  • 결함 내성 아키텍처
  • 신뢰성을 위한 프로그래밍
  • 신뢰성 측정

System Reliability [316p]

• 사회의 많은 측면이 소프트웨어 시스템에 의존
  • 중대한 시스템은 신뢰성 요구사항이 매우 높다

• 결함-오류-고장 (Fault Error Failure) 모델

  • 사람의 오류 또는 실수 (Human Error or Mistake)
    • 시스템 결함이 생기게 하는 사람의 행동
  • 시스템 결함 (System Fault)
    • 시스템 오류로 이어질 수 있는 시스템의 특성
  • 시스템 오류 (System Error)
    • 예기치 못한 시스템 행동으로 이어질 수 있는 시스템의 잘못된 상태
  • 시스템 장애 (System Failure)
    • 사용자가 기대하는 서비스를 시스템이 제공하지 못하는 특정 시점의 사건

• 시스템 결함이 반드시 시스템 오류를 초래하지는 않고, 시스템 오류가 반드시 시스템 장애를 초래하지는 않는다.

• 시스템 결함이 시스템 오류를 반드시 초래하지는 않는 이유 3 가지
  • 프로그램의 모든 코드가 실행되는 것이 아니다.
  • 오류는 일시적이다
  • 시스템이 결함 감지 및 보호 메커니즘을 포함할 수 있다.

Reliability Achievement [317p]

• 결함,오류,고장의 구분은 시스템의 신뢰성을 향상시키기 위해서 사용될 세가지 보완적인 접근법

• 결함 회피 (Fault Avoidance)
  • 설계 및 프로그래밍 오류를 피하는 소프트웨어 개발 방식으로 시스템에 도입되는 결함을 최소화 함
  • 강한 자료형 언어 사용, 포인터와 같은 오류가 발생하기 쉬운 요소 사용 최소화
• 결함 감지 및 정정 (Fault Detection & Correction)
  • 검증 및 확인 (V&V) 프로세스를 통해 결함을 발견하고 제거함
  • 체계적인 테스팅, 디버깅, 정적 분석

*결함 내성 (Fault Tolerance)

• 실행 중에 결함이나 시스템의 예기치 못한 행동을 감지하여 시스템 장애가 일어나지 않도록 시스템을 설계
• 결함 내성 아키텍처

Availability and Reliability [319p]

• 신뢰성
  • 주어진 환경에서 특정 목적을 위해 지정된 시간 동안 고장 없이 운영될 확률
  • 주어진 기간 동안 시스템이 (정확하게) 서비스를 제공할 확률
• 가용성
  • 주어진 시점에서 시스템이 운영 중이고 요청된 서비스를 제공할 확률
  • 참고 : 어떤 시점에 시스템이 작동 (서비스를 제공)할 확률
• 신뢰성은 시스템의 환경에 따라 달라짐
  • 사용되는 장소, 사용하는 방법
• 고장 없는 운영 (Failure - free Operation)
  • 고장의 기술적 정의는 시스템 명세를 준수하지 않는 것
    • 엔지니어들은 시스템이 사용되는 분야의 전문가가 아니기 때문에 사용자가 기대하는 동작을 구현하지 않을 수 있다 이 소프트웨어는 명세서에 있는 대로 동작하지만 사용자에게는 여전히 장애가 발생한 것이다
    • 시스템 개발자를 제외하고 아무도 소프트웨어 명세서를 읽지 않는다. 따라서 사용자가 예상하는 소프트웨어의 동작은 명세서와 완전히 다른 방식일 수 있다.
  • 고장은 객관적 정의가 어려우며 시스템 사용자에 의해 판단됨
• 가용성과 신뢰성
  • 가용성은 장애 횟수뿐만 아니라 수리 시간의 영향을 받음
    • 수리시간이 적게 걸리는 시스템이 가용성이 더 좋은 시스템이다.
  • 시스템에 따라 가용성 또는 신뢰성이 더 중요함

Tip) 신뢰성과 가용성은 밀접하게 관련되어 있지만, 때로는 어떤 하나가 다른 하나보다 더 중요하다.

만약 사용자가 어떤 시스템으로부터 지속적인 서비스를 기대하는 경우 그 시스템은 고가용성 요구사항을 가진다.

그것은 수요가 있을 때 반드시 사용가능해야 한다.

그러나 만약 시스템이 사용자 데이터 손실 없이 장애로부터 빠르게 복구될 수 있다면 이러한 장애는 시스템 사용자들에게 큰 영향을 미치지 않을 것이다.

System Reliability Requirements [322p]

• 신뢰성 요구사항
  • 명세는 불완전하고 부정확할 수 있다
  • 소프트웨어 장애 뿐만 아니라 하드웨어 고장과 운영자의 오류도 고려해야 한다

• 확실성 요구사항의 유형

  • 기능적 요구사항
    • 시스템에 포함되어야 하는 점검 및 복구 기능
    • 시스템 장애 및 외부 공격에 대한 보호 기능
  • 비기능적 요구사항
    • 신뢰성과 가용성
  • 소프트웨어 시스템은 고립된 것이 아니라 인간, 사회, 조직의 목적이 있는 광범위한 시스템, 사람, 프로세스, 규정 등 비기술적 요소를 포함한다.

System Metrics [322p]

• 신뢰성 척도
  • 시스템이 주어진 운영 환경에서 시스템 장애가 일어날 확률
• 온 디맨드 고장 확률 (POFOD : Probability of Failure On Demand)
  • 시스템 서비스에 대한 요구가 시스템 장애를 일으킬 확률
• 고장 발생 비율 (ROCOF : Rate of Occurrence of Failure)
  • 어떤 시간 간격 (또는 시스템 실행 횟수) 동안 발생할 수 있는 시스템 장애 횟수
  • 고장 간 평균 시간 (MTTF : Mean Time To Failure) 의 역수
  • 이 척도는 특정 시간 간격(예를 들어, 1시간) 또는 시스템 실행 횟수에서 발생할 수 있는 시스템 장애의 확률수를 나타낸다. 위의 예에서, ROCOF는1/1000이다. ROCOF의 역수는 신뢰성 척도로 가끔 사용되는 고장 평균시간(MTTF)이다. MTTF는 시스템 장애 간의 시간 단위 평균이다. 한시간당 두번의 고장이 있을 때의 ROCOF는 고장 평균 시간이 30분임을 의미하다.
• 가용성 척도 (AVAIL : availability)
  • 서비스 요구가 있을 때 시스템이 운영 중일 확률
  • 가용성 = 운영시간 / 전체시간
  • AVAIL은 서비스에 대한 요구가 있을 때 시스템이 가동중일 확률이다. 따라서0.9999의 가용성은 평균적으로 시스템이 운영 시간의 99.99%동안 사용가능함을 의미한다.
• POFOD (요구에 대한 고장 확률)
  • 요구에 대한 실패가 심각한 시스템 장애로 이어지는 경우
  • 요구의 빈도와 관계 없이 적용됨
  • EX) 화학 반응기를 감시하고 과열되면 정지시키는 방호 시스템
• ROCOF (고장 발생 비율)
  • 요구의 빈도가 정기적일 때 사용
  • 요구의 빈도가 간헐적일 때보다 빈도가 정기적일 때 사용한다.
  • 하루에 10번 트랜잭션 실패, 1000개 트랜잭션 당 10개 실패
• MTTF
  • 고장 간 시간이 중요한 경우 사용
  • 긴 트랜잭션을 가지는 시스템은 MTTF 가 평균 트랜잭션 수행 시간 보다 길어야 한다
• 비기능적 신뢰성 요구사항은 신뢰성 척도를 사용

  Functional Reliability Requirements [327p]

• 검사 요구사항
  • 부정확하거나 범위를 벗어난 입력을 감지
• 복구 요구사항
  • 시스템과 데이터의 사본 관리
  • 장애 발생 후 시스템을 복원하는 방법
• 중복 요구사항
  • 시스템의 중복 기능을 명시
• 프로세스 요구사항
  • 개발 프로세스에 대한 요구사항

Fault Tolerance [327~328p]

• 결함 내성
  • 결함은 소프트웨어나 하드웨어에 내재되어 있는 특성이다
  • 실행 중에 소프트웨어나 하드웨어 결함이 발생하고 시스템 상태가 잘못된 경우에도 시스템이 동작을 계속
  • 결함 발생이 시스템 장애로 이어지지 않도록 잘못된 상태를 감지하고 정정함
• 결함 내성을 위한 아키텍처
  • 중복되고 다양한 하드웨어 및 소프트웨어를 포함
• 복제 서버를 이용한 아키텍처
  • 두 대 이상의 서버가 동일한 작업을 수행, 서버 관리 컴포넌트가 있음
  • 복제 서버는 중복성은 제공하지만 일반적으로 다양성은 제공하지 않음
    • 서버 하드웨어는 일반적으로 동일하고, 서버는 소프트웨어의 동일한 버전을 실행한다. 따라서 단일 기계에 국한된 하드웨어 및 소프트웨어 장애를 대처할 수 있으나, 동시에 소프트웨어의 모든 버전에 장애를 일으키는 소프트웨어 설계 문제에는 대처할 수 없다.

Tip) 참고만

• Active Standby 형식
  • Request 가 들어온다면 양쪽 서버에서 다 보내서 A 서버에서도 처리해주고 B 서버에서도 처리해준다.
    그리고 둘 다 Response 를 보내면 안 되니까 Active 된 서버에서 Response 를 보내준다.
• 다른 방법 = Primary, Back-Up 형식
  • Request 가 들어왔을 때 양쪽 (Active, Stand-By) 으로 다 신호가 간다.
    둘이 같이 죽을 수 있으니까 Request 가 들어오면 Primary, Back-Up 이라 나눠 Back-Up에는 Request 가 안 가고 Primary 에만 간다.
    Primary 는 상태만 Back-Up 에 건넨다.
    그러면 Primary 프로세스가 유지하는 어플리케이션의 상태는 넘기지만 Primary 는 Request 를 처리해 Response 를 처리하고 Back-Up 은 어플리케이션에서 중요한 내용을 넘겨받는다.
    그래서 만약 Primary 프로세스가 죽으면 Back-Up 프로세스가 이어받아서 Request 를 처리한다.

11.4. 신뢰성을 위한 프로그래밍

Guidelines for Reliability Programming [336~342p]

• 정보의 가시성을 제한
  • 변수와 데이터 구조에 대한 접근을 통제, 추상 데이터 타입 사용
• 모든 입력이 유효한지 검사
  • 범위 검사, 크기 검사, 표현 검사, 타당성 검사

• 모든 예외에 대해 처리기를 제공

• 오류가 발생하기 쉬운 구조의 사용을 최소화
  • 부동 소수점 정밀도에 의존, 동적 기억장소 사용

• 재시작 기능을 제공

• 자동 배열 경계 검사를 사용

• 외부 컴포넌트 호출 시 타임아웃 포함

• 실세계의 값을 나타내는 모든 상수에 이름 부여

• 결함
  • 결함 회피
  • 결함 감지
  • 결함 내성

Reliability Measurement [342~345p]

• 시스템 신뢰성 측정을 위한 데이터
  • 서비스 요청 횟수에 대한 시스템 장애 횟수 : POFOD
  • 시스템 장애 사이의 시간 간격 또는 트랜잭션 개수 : ROCOF, MTTF
    • 시간 단위는 실제 시간 또는 트랜잭션 개수를 사용
  • 시스템 장애가 발생한 후 수리 또는 재시작에 걸리는 시간 : AVAIL
• 운영 프로파일 (Operational Profile)
  • 시스템의 입력 유형과 해당 입력 유형 발생 확률
  • 시스템이 실제로 사용되는 방식을 반영
  • 기존 시스템을 대체하는 경우에는 사용되는 방식을 알기 쉬움
  • 새롭고 혁신적이 시스템 개발 시는 사용되는 방식을 예측하기 어려움

소프트웨어 시스템의 운영 프로파일은 그것이 실제로 사용되는 방식을 반영한다.

운영 프로파일은 입력 유형과 그 입력 유형의 발생 확률의 명세로 구성된다.

신뢰성뿐만이 아니라 성능 테스트를 할 때 일반적인 고객들이 사용하는 방법들과 비슷한 방법들을 이야기한다.

(어떤 트랜잭션이 시간마다 몇 개씩 들어오더라, 어떤 종료 액션이 들어오더라)

15 장 소프트웨어 재사용

Software Reuse [458~459p]

• 재사용의 이점
  • 신속한 개발
  • 높은 품질 (확실성)
  • 비용 절감
  • 리스크 감소
  • 표준 준수
• 재사용의 단위
  • 시스템 재사용
    • 여러 개의 애플리케이션으로 구성된 전체 시스템 재사용
  • 애플리케이션 재사용
    • 애플리케이션 변경 없이 다른 시스템에 통합시키거나 설정하여 재사용
  • 컴포넌트 재사용
    • 객체, 서브시스템 등 컴포넌트를 재사용
  • 객체와 함수의 재사용
    • 라이브러리 객체 및 함수

Software Reuse [459~460p]

• 개념 재사용
  • 코드를 재사용하는 대신 소프트웨어의 기본적인 아이디어를 재사용
  • 디자인 패턴, 아키텍처 패턴 등
• 재사용 문제점
  • 컴포넌트 라이브러리의 생성 및 관리 비용
  • 재사용 컴포넌트 검색, 이해, 변형
  • 재사용 컴포넌트의 소스코드가 없으면 유지 보수 비용 증가 가능
  • 지원 도구 부족
  • Not Invented Here 증후군 (남이 만든 것을 믿지 못함)

Approaches that supports Software Reuse 재사용 관점 [462p]

• 애플리케이션 프레임워크 (GUI 를 개발하기 위해서 사용하는 것, JAVA Swing)
  • 애플리케이션을 생성하기 위한 추상 클래스와 구체 클래스의 집합
  • 애플리케이션 시스템을 생성하기 위해 추상클래스들과 구체클래스들의 집합들이 적용되고 확장된다.
• 아키텍처 (서브시스템) 패턴
  • 애플리케이션의 공통적인 유형을 지원하는 표준 아키텍처
  • 애플리케이션 시스템의 일반(공통)적인 유형을 지원하는 표준 소프트웨어 아키텍처는 애플리케이션의 기초로 사용된다.
• 디자인 패턴
  • 추상 클래스와 구체 클래스의 상호작용으로 표현된 일반적인 추상화로 특정 상황에 활용할 수 있음
  • 여러 애플리케이션들에 걸쳐 발생하는 일반화된 추상 개념은 추상 객체, 구체 객체, 그리고 상호 작용을 보여주는 디자인 패턴으로써 표현된다
• 컴포넌트 기반 소프트웨어 공학
  • 컴포넌트 (객체의 집합)을 이용하여 시스템을 개발
• 서비스 지향 시스템
  • 외부에서 제공되는 서비스를 연결(사용)하여 시스템을 개발

Application Frameworks [464p]

• 애플리케이션 프레임워크
  • 유사한 형태의 애플리케이션에서 사용될 수 있는 일반 기능을 제공
  • 추상 클래스와 구체 클래스의 집합으로 구현되어 있음
    • 구현 언어에 종속, JAVA, C#, C+, C++, Python 등
  • 애플리케이션을 위한 핵심 아키텍처 제공
    • 객체 클래스와 객체 간의 상호작용으로 표현되는 아키텍처, 설계의 재사용

특정 애플리케이션을 위해 기능을 추가하여 이것들을 특화시키는 것이 전문가에게 남겨진다.

예를 들면, 사용자 인터페이스 프레임워크에서 개발자는 애플리케이션 구현에 적합한 디스플레이 레이아웃을 정의한다.

• 프레임 워크의 예시
  • Graphic User Interface (GUI) 프레임워크
    • 이벤트 처리 기능, 위젯 집합 등 기능 제공
  • Web Application Framework (WAF)
    • 보안, 동적 웹페이지, 데이터베이스 통합, 세션 관리, 사용자 상호작용 등 기능 제공
• 공통적으로 많이 사용하는 기능들을 모아 사용할 수 있도록 만든 것이 프레임워크다

WAF Features [465p]

• 보안 (Security) *사용자 인증 (로그인) 구현을 위한 클래스를 제공하고 허가된 기능만 접근 가능하도록 제어

• 동적 웹페이지
  • 웹페이지 템플릿 정의를 위한 클래스 제공
  • 동적으로 특정 데이터를 템플릿에 적용하는 것을 도와줌
• 데이터베이스 통합
  • 다양한 데이터베이스를 위한 추상 인터페이스를 제공
• 세션 관리
  • 세션의 생성과 관리를 위한 클래스 제공
• 사용자 상호 작용
  • Ajax, HTML5 등을 지원

Extending Frameworks [465p]

• 일반적인 (Generic) 프레임워크를 확장하여 구체적인 (Specific) 애플리케이션을 생성
  • 프레임워크가 제공하는 추상 클래스 (인터페이스)를 상속받아 구체적인 클래스를 구현 (추상 메소드 구현)
  • 이벤트가 일어나면 호출되는 콜백 (Callback) 메서드를 구현

Framework classes [466p]

• 시스템 기반 구조 프레임워크
  • 통신, 사용자 인터페이스, 컴파일러 등의 시스템 기반 구조 개발 지원
• 미들웨어 통합 프레임워크
  • 컴포넌트 통신과 정보 교환을 위한 표준과 이를 지원하는 클래스
  • 예 : Enterprise Java Beans (EJB) , .NET
• 엔터프라이즈 애플리케이션 프레임워크
  • 특정 애플리케이션 분야 (도메인) 의 애플리케이션 개발 지원
  • 소프트웨어 제품 라인으로 대체됨

용어 [467P]

• 소프트웨어 제품 라인 (Software Product Line)
  • 도메인 특화된 어플리케이션들을 재사용하기 위함 (학교, 병원 같은 경우)
  • 공통 아키텍처와 일반적인 기능을 제공하는 소프트웨어 애플리케이션 집합
  • 컴포넌트 설정, 구현, 변경 등으로 특정 고객의 요구에 맞출 수 있음
  • 여러 조직에서 사용하는 시스템이 유사할 때, 일반화된 소프트웨어 제품 라인을 만들어 비공식적으로 재사용한다.
• Commercial Off the shelf (COTS)
  • 판매되는 기성 소프트웨어 시스템
• 설정 가능한 애플리케이션 시스템 (Configurable Application System)
  • 특정 비즈니스 유형 또는 비즈니스 전체를 지원하기 위해 설계된 일반적 (Generic) 애플리케이션 시스템
  • 예 : SAP, Oracle 등에서 제공되는 ERP 시스템