[소프트웨어 공학] 10. Dependable Systems

System Dependability

• 많은 컴퓨터 기반 시스템에서 가장 중요한 시스템 속성은 시스템의 신뢰성(dependability)이다.
• 시스템의 신뢰성은 사용자가 해당 시스템에 대한 신뢰의 정도를 반영한다.(The dependability of a system relfects the user's degree of trust in that system)
  • 이는 사용자가 시스템이 사용자가 기대하는 대로 작동(it will operate as users expect)하고, 정상 사용 중에 '실패'하지 않을 것(it will not 'fail' in normal use)이라는 확신의 정도를 반영한다.
  • 사용자가 이 시스템을 얼마나 믿을 수 있는가?
  • 실패 예시) 과제 마감 2분 전 트래픽이 몰려서 제출하지 못함
• 신뢰성은 신뢰성(reliability), 가용성(availability), 보안(security)과 같은 관련 시스템 속성을 포괄한다.
  • 이들은 모두 상호 의존적이다.

Importance of Dependability

• 시스템 실패는 큰 수의 사람들에게 영향을 미치는 광범위한 영향을 미칠 수 있다.
• 신뢰할 수 없고, 불안정하거나 안전하지 않은 시스템은 사용자에게 거부당할 수 있다.
• 시스템 실패 비용은 실패가 경제적 손실이나 신체적 손상으로 이어지면 매우 높을 수 있다.
  • ex) 자율주행 시스템 -> physical damage 를 입을 수 있음.
• 신뢰할 수 없는 시스템은 정보 손실을 초래하고, 이에 따른 회복 비용이 높을 수 있다.

The Principal Dependability Properties

• 가용성(Availability): 요청 시 서비스를 제공할 수 있는 시스템의 능력
  • 원할 때 시스템을 사용할 수 있을까?
• 신뢰성(Reliability): 지정된 대로 서비스를 제공할 수 있는 시스템의 능력
  • 원하는 대로 시스템이 작동하는가?
• 안전성(Safety): 치명적인 실패 없이 작동할 수 있는 시스템의 능력
  • 이 시스템이 안전한가?
  • ex) 자율주행 시스템
• 보안(Security): 의도적이거나 우발적인 침입으로부터 시스템을 보호할 수 있는 능력
• 복원력(Resilience): 손상된 사건으로부터 저항하고 회복할 수 있는 시스템의 능력
• 위에 4개가 중요함!

Other Dependability Properties

• 복구 가능성(Repairability): 실패 시 시스템을 복구할 수 있는 정도를 반영한다.
  • 실패가 발생했을 때 얼마나 쉽게 복구할 수 있는가?
• 유지보수성(Maintainability): 새로운 요구 사항에 맞게 시스템을 적응시킬 수 있는 정도를 반영한다.
• 오류 허용성(Error Tolerance): 사용자 입력 오류를 피하고 허용할 수 있는 정도를 반영한다.
  • 에러가 발생했을 때 적절히 처리하여 system failure가 발생하지 않게 해주는 부분

Dependability Attribute Dependencies

시험에 나올 수 있는 중요한 부분!

• 안전한 시스템 운영은 시스템이 가용하고 신뢰성 있게 작동하는지에 달려 있다.
  • 가용성, 신뢰성 → 안전성
  • ex) 자율 주행 시스템
    • Availability
      • 충돌 감지 시스템이 작동하지 않아, 자동으로 감속하는 기능이 작동하지 않음.
      • 자율 주행 시스템 자체가 죽어버리는 경우
    • Reliability
      • 시스템이 브레이크를 밟아야 하는데 Accelerator를 밟음
• 시스템이 불안정할 수 있는 이유는 데이터가 외부 공격으로 손상되었기 때문이다.
  • 서비스 거부 공격(DDOS)은 시스템을 이용할 수 없게 만들려는 의도이다.
  • 또한, 시스템이 바이러스에 감염되면 신뢰성이나 안전성을 신뢰할 수 없다.
  • Security에 문제가 있어서 해킹을 당하는 경우
  • 보안 → 신뢰성, 가용성, 안전성
• 신뢰성 속성들이 상호 의존적이라는 많은 다른 예들이 있다.
• 발표 예시) 핵(미사일) 시스템, 원자로 시스템, 결제 시스템, 병원 시스템, 시스템 펌웨어

Dependability Achievement

• 시스템 개발 시 실수 도입을 피한다.
• 남은 오류를 발견하는 데 효과적인 검증 및 확인(V & V) 프로세스를 설계한다.
• 오류 발생 시 계속 작동할 수 있도록 시스템을 내결함성으로 설계한다.
• 외부 공격을 방어하는 보호 메커니즘을 설계한다.
  • ex) layered architecture
• 시스템을 운영 환경에 맞게 올바르게 구성한다.
• 사이버 공격을 인식하고 저항할 수 있는 시스템 기능을 포함한다.
• 실패 후 정상 시스템 서비스 복구를 돕는 복구 메커니즘을 포함한다.

Dependability Costs

• 높은 수준의 신뢰성이 요구됨에 따라 신뢰성 비용은 기하급수적으로 증가하는 경향이 있다.
• 이 두 가지 이유가 있다:
  • 더 높은 수준의 신뢰성을 달성하기 위해 필요한 더 비싼 개발 기술 및 하드웨어의 사용(The use of more expensive development techniques and hardware).
  • 요구되는 신뢰성 수준이 달성되었음을 시스템 클라이언트와 규제 기관에게 입증하기 위한 증가된 테스트 및 시스템 검증(The increased testing and system validation).

Dependability Economics

• 신뢰성 달성 비용이 매우 높기 때문에 신뢰할 수 없는 시스템을 수용하고 실패 비용을 지불하는 것(accept untrustworthy systems and pay for failure costs)이 더 비용 효과적일 수 있다.
  • ex) 시스템이 해킹당했을 때 법적으로 책임을 별로 묻지 않음
• 그러나 이는 사회적, 정치적 요인에 따라 달라진다.
  • 신뢰할 수 없는 제품에 대한 평판은 미래의 비즈니스를 잃을 수 있다.
• 시스템 유형에 따라 다르다.
  • 특히 비즈니스 시스템의 경우, 적당한 수준의 신뢰성으로 충분할 수 있다.

Systems and Software

• 소프트웨어 공학은 고립된 활동이 아니라 더 넓은 시스템 공학 프로세스의 일부이다.
• 따라서 소프트웨어 시스템은 고립된 시스템이 아니라 인간, 사회, 조직적 목적을 가진 더 넓은 시스템의 필수 구성 요소이다.

The Socio-Technical System (STS) Stack

• 사회(Society)
• 조직(Organization)
• 비즈니스 프로세스(Business Processes)
• 애플리케이션 시스템(Application System)
• 통신 및 데이터 관리(Communications and Data Management)
• 운영 체제(Operating System)
• 장비(Equipment)

Holistic system design

전체적인 것을 고려해서 시스템 디자인을 하는게 중요하다.

ex) 리뷰(별점) 시스템의 어뷰징 문제 --> 결국에 비지니스 프로세스를 제대로 하지 않으면 쓸모 없어진다.

• 시스템의 각 계층 간에는 상호작용과 의존성이 있으며, 한 계층에서의 변화가 다른 계층에 파급 효과를 미친다.
• 신뢰성을 위해 시스템 관점이 필수적이다.
  • STS stack의 포괄적인 계층 내에서 소프트웨어 실패를 포함시킨다.
  • 인접 계층의 결함과 실패가 시스템 내 소프트웨어에 어떻게 영향을 미치는지 이해한다.
    • 예: 배달, 모빌리티, 콘텐츠 추천, 리뷰 등을 위한 앱

Regulation and compliance

• 세계적으로 거의 보편화된 경제 조직의 일반 모델은 사유 기업이 상품과 서비스를 제공하고 이익을 내는 것이다.
• 시민의 안전을 보장하기 위해 대부분의 정부는 사유 기업의 자유를 제한하여 제품이 안전하고 보안이 유지되도록 특정 기준을 준수하도록 규제한다.

Regulated systems

• 많은 중요한 시스템들은 규제 시스템(Many critical systems are regulated systems)이며, 서비스에 들어가기 전에 외부 규제 기관의 승인을 받아야 한다.
  • 원자력 시스템
  • 항공 교통 관제 시스템
  • 의료 기기
• 안전성과 신뢰성 사례는 규제 기관의 승인을 받아야 한다.
  • 따라서 중요한 시스템 개발은 시스템이 신뢰할 수 있고 안전하며 보안이 유지된다는 것을 규제 기관에 입증하기 위한 증거를 만들어야 한다.

Safety regulation

• 규제 및 준수(룰을 따르는 것)는 시스템의 소프트웨어 요소가 아니라 전체 사회기술 시스템에 적용된다.
• 안전 관련 시스템은 규제 기관에 의해 안전하다고 인증되어야 할 수 있다.
• 인증을 받기 위해 안전 중요한 시스템을 개발하는 회사(companies that are developing safety-critical systems)는 규정과 규칙을 준수했음을 보여주는 포괄적인 안전 사례를 제시해야 한다. (have to produce an extensive safety case)
  • safety case : 안전함을 증명하는 문서
• 인증을 위한 문서를 개발하는 것은 시스템 자체를 개발하는 것만큼 비용이 많이 들 수 있다.

Redundancy and diversity

• Redundancy(중복성)
  • 중요한 구성 요소의 단일 버전 이상을 유지하여 하나가 실패하면 백업이 가능하게 한다.
  • ex) 클라우드 서비스에서 1, 2를 둬서 1이 죽으면 2로 복구
• Diversity(다양성)
  • 서로 다른 구성 요소에서 동일한 기능을 다른 방식으로 제공하여 동일한 방식으로 실패하지 않도록 한다.
    • 완전히 동일한 꼴을 가진 기능을 제공하는데, 기능의 implementation 방식이 완전히 다름
    • ex) 하나는 bubble sort, 하나는 insertion sort, 하나는 merge sort
  • 중복되고 다양한 구성 요소는 독립적이어야 하므로 공통 모드('common-mode') 실패로부터 영향을 받지 않도록 한다.
    • 예: 다른 프로그래밍 언어로 구현된 구성 요소는 컴파일러 오류가 모두에게 영향을 미치지 않음을 의미한다.

Process diversity and redundancy

• 검증과 같은 프로세스 활동은 시스템을 검증하기 위해 단일 접근 방식(예: 테스트)에 의존해서는 안 된다.
• 중복되고 다양한 프로세스 활동은 특히 검증 및 확인을 위해 중요하다.
• 상호 보완하는 여러 가지 다른 프로세스 활동은 교차 확인을 가능하게 하여 프로세스 오류를 피하고 소프트웨어 오류로 이어질 수 있는 상황을 방지한다.

Problems with redundancy and diversity

• 시스템에 다양성과 중복성을 추가하면 시스템 복잡성이 증가한다.
• 이는 중복 시스템 구성 요소 간의 예상치 못한 상호작용 및 의존성으로 인해 오류 가능성을 증가시킬 수 있다.
• 따라서 일부 엔지니어는 단순성과 광범위한 검증 및 확인(V&V)을 소프트웨어 신뢰성 확보의 더 효과적인 경로로 옹호한다.
  • 예: Airbus FCS 아키텍처는 중복/다양성이 있지만 Boeing 777 FCS 아키텍처는 소프트웨어 다양성이 없다.
  • FCS(fly control system)의 경우 문제가 크게 발생할 수 있기 때문에 redundancy와 diversity를 확실히 신경써야 한다.

Dependable processes

• 최소한의 소프트웨어 결함을 보장하기 위해 명확하게 정의된 반복 가능한 소프트웨어 프로세스가 중요하다.
  • 명확하게 정의된 반복 가능한 프로세스는 전적으로 개인의 기술에 의존하지 않으며(A well-defined repeatable process is one that does not depend entirely on individual skills), 다른 사람들이 실행할 수 있다.
  • 즉, 개인의 스킬이 부족해도, well-defined repeatable process를 사용하면 dependability를 확보할 수 있다.
• 규제 기관은 프로세스에 대한 정보를 사용하여 좋은 소프트웨어 엔지니어링 관행이 사용되었는지 확인한다.
• 결함 탐지를 위해 프로세스 활동에는 검증 및 확인에 상당한 노력을 기울여야 한다.

Dependable process characteristics

• 명확하게 정의된(Explicitly defined)
  • 소프트웨어 생산 과정을 주도하는 정의된 프로세스 모델을 가진다.
  • 개발 팀이 프로세스 모델에 정의된 대로 프로세스를 따랐음을 입증하는 데이터를 수집해야 한다.
• 반복 가능한(Repeatable)
  • 개인의 해석과 판단에 의존하지 않는 프로세스.
  • 개발에 누가 참여했는지와 관계없이 프로젝트 전반에 걸쳐 반복될 수 있는 프로세스.
  • 다른 SW를 개발할 때도 이 프로젝트의 프로세스가 반복되도록

Dependable process activities

• 요구사항 검토(Requirements review): 요구사항이 가능한 한 완전하고 일관성(complete and consistent) 있는지 확인.
• 요구사항 관리(Requirements management): 요구사항 변경이 통제되고 제안된 변경의 영향이 이해되도록 보장.
• 정형 명세(Formal specification): 소프트웨어의 수학적 모델을 생성하고 분석.
• 시스템 모델링(System modeling): 소프트웨어 설계가 명확히 문서화되어 그래픽 모델 세트로 요구사항과 이들 모델 간의 연결이 문서화됨.
• 설계 및 프로그램 검토(Design and program inspections): 시스템의 다양한 설명을 서로 다른 사람들이 검사하고 확인하는 활동.
• 정적 분석(Static analysis): 프로그램의 소스 코드에 대해 자동화된 검사를 수행하는 활동.
• 테스트 계획 및 관리(Test planning and management): 포괄적인 시스템 테스트 세트를 설계하는 활동.
  • 테스트 프로세스는 이러한 테스트가 시스템 요구사항을 충족하고 테스트 과정에서 올바르게 적용되었음을 입증하기 위해 신중하게 관리되어야 한다.

Dependable processes and agility

• 신뢰할 수 있는 소프트웨어는 종종 인증을 필요로 하며, 따라서 프로세스 및 제품 문서화(process and product documentation)가 작성되어야 한다.
• 사전 요구사항 분석(Up-front requirements analysis)은 시스템의 안전성과 보안을 위협할 수 있는 요구사항 및 요구사항 간 충돌을 발견하는 데 필수적이다.
• 이러한 요구는 요구사항과 시스템의 공동 개발 및 문서화를 최소화하는 애자일 개발(agile development)의 일반적인 접근 방식과 충돌한다.
  • Dependable process는 document를 필요로 하는데, 문서를 최소화 하는 애자일과 안맞는 부분이 있다.

• 반복 개발(iterative development), 테스트 우선 개발(test-first development), 개발 팀의 사용자 참여(user involvement)와 같은 기술을 포함하는 애자일 프로세스가 정의될 수 있다.
• 팀이 그 프로세스를 따르고 그들의 행동을 문서화하는 한(So long as the team follows that process and documents their actions), 애자일 방법론은 사용할 수 있다.
• 그러나 추가 문서화 및 계획이 필수적이므로 순수 애자일(pure agile)은 신뢰할 수 있는 시스템 엔지니어링에는 실용적이지 않다.('pure agile' is impractical for dependable systems engineering.)
  • 애자일이 완전히 불가능한 것은 아니지만, 퓨어 에자일은 현실적이지 않다

 

Attribute 의미, 연관관계, Dependability를 확보하기 위해 어떤 전략을 취할 수 있는지를 중점적으로 보자